Deployment Guide Series IBM Tivoli Provisioning Manager Version 5.1 Sg247261

Front cover
Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Learn best practices for planning, deploying and customizing TPM V5.1 All new features are explained with real life scenarios Also covers TPM for Software
Vasfi Gucer Alfredo Olivieri David Campbell Fabrizio Salustri Ghufran Shah Johan Raeymaeckers Marc Remes Murtuza Choilawala Philippe Hamelin Scott Berens Ignacio Fernandez
ibm.com/redbooks
International Technical Support Organization Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1 October 2006
SG24-7261-00
Note: Before using this information and the product it supports, read the information in Notices on page xxxiii.
First Edition (October 2006) This edition applies to IBM Tivoli Provisioning Manager Version 5.1 and IBM Tivoli Provisioning Manager for Software Distribution Version 5.1.
Copyright International Business Machines Corporation 2006. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxvii Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiv Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxv The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxv Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviii Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxix Part 1. IBM Tivoli Provisioning Manager V5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. Tivoli Provisioning Manager V5.1 overview . . . . . . . . . . . . . . . . 3 1.1 Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Service Oriented Architecture (SOA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1 Why IBM SOA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.2 The SOA lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Open Services Gateway Initiative (OSGi) . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 IBM Service Management Framework (SMF) . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Tivoli Provisioning family of products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5.1 IBM Tivoli Provisioning Manager for Software Version 5.1 . . . . . . . . . 8 1.5.2 IBM Tivoli Provisioning Manager Version 5.1 . . . . . . . . . . . . . . . . . . . 9 1.5.3 IBM Tivoli Provisioning Manager Express Version 4.1 . . . . . . . . . . . 10 1.5.4 IBM Tivoli Provisioning Manager OEM Edition . . . . . . . . . . . . . . . . . 10 1.5.5 IBM Tivoli Provisoning Manager for OS deployment Version 5.1 . . . 10 1.6 Tivoli Provisioning Manager V5.1 new features . . . . . . . . . . . . . . . . . . . . 12 1.6.1 Discovery and inventory management . . . . . . . . . . . . . . . . . . . . . . . 12 1.6.2 Compliance management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.6.3 Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.6.4 Notifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.6.5 Software distribution infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.6.6 Patch management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.6.7 Image management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.6.8 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.6.9 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Copyright IBM Corp. 2006. All rights reserved.
iii
1.6.10 User experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.6.11 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.7 IBM Tivoli Configuration Manager clients . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.7.1 Benefits of migrating to Tivoli Provisioning Manager V5.1 . . . . . . . . 20 1.7.2 Tivoli Provisioning Manager V5.1 concepts . . . . . . . . . . . . . . . . . . . 24 1.7.3 The data center model (DCM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.7.4 Security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Chapter 2. Product architecture planning and deployment best practices . 33 2.1 Tivoli Provisioning Manager V5.1 components . . . . . . . . . . . . . . . . . . . . . 34 2.1.1 Scalable Distribution Infrastructure (SDI) for provisioning . . . . . . . . 38 2.1.2 Supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.1.3 Supported prerequisite software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.2 Deployment scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.2.1 Demo installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.2.2 Small data center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.2.3 Small branch office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.2.4 Large data center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.2.5 Large branch office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.3 Systems management across firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.3.1 Ports used by Scalable Distribution Infrastructure components . . . . 53 2.3.2 Proxy relay collector for communication behind a firewall . . . . . . . . 55 2.4 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Chapter 3. Installing Tivoli Provisioning Manager V5.1 . . . . . . . . . . . . . . . 61 3.1 Topology Installer Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.2 New installation options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.3 Installation described in this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.3.1 Fast Start installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.3.2 Enterprise installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.4 Enterprise installation on AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.4.1 Hardware and software requirements for the Topology Installer Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.4.2 Hardware requirements for Tivoli Provisioning Manager server machine 69 3.4.3 Software requirements for Tivoli Provisioning Manager . . . . . . . . . . 70 3.4.4 Installing behind a firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.4.5 Preparing installation images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.4.6 Preparing AIX systems for installation . . . . . . . . . . . . . . . . . . . . . . . 77 3.4.7 Installing Tivoli Provisioning Manager step by step . . . . . . . . . . . . . 87 3.4.8 Installation log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 3.4.9 Time required to complete the installation . . . . . . . . . . . . . . . . . . . 115
iv
3.4.10 Starting the Tivoli Provisioning Manager graphical user interface 116 3.5 Unattended installation on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 3.5.1 Hardware and software requirements for the Topology Installer Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 3.5.2 Hardware requirements for Tivoli Provisioning Manager server machine 122 3.5.3 Software requirements for Tivoli Provisioning Manager . . . . . . . . . 123 3.5.4 Installing behind a firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.5.5 Preparing installation images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.5.6 Preparing Linux systems for installation . . . . . . . . . . . . . . . . . . . . . 127 3.5.7 Before you begin the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 3.5.8 Performing a silent installation step by step . . . . . . . . . . . . . . . . . . 133 3.5.9 Starting the Tivoli Provisioning Manager graphical user interface . 143 3.6 Enterprise installation on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 3.6.1 Pre-install Cygwin on the local and target systems. . . . . . . . . . . . . 144 3.6.2 Install Tivoli Provisioning Manager . . . . . . . . . . . . . . . . . . . . . . . . . 146 3.6.3 Backup the Tivoli Provisioning Manager databases . . . . . . . . . . . . 170 3.6.4 Change the default password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Chapter 4. Discovery mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 4.1 Introduction to discovery mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 4.2 Network discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 4.2.1 Discovering devices using SMB . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 4.2.2 Discovering devices using SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 4.2.3 Discovering devices using SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 192 4.3 Inventory discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 4.3.1 Configuring and running inventory scans . . . . . . . . . . . . . . . . . . . . 197 4.3.2 Custom software signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 4.3.3 Change policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 4.4 Microsoft Active Directory discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 4.4.1 Preparing Microsoft Active Directory environment for discovery. . . 219 4.4.2 Running Microsoft Active Directory discovery . . . . . . . . . . . . . . . . . 219 4.4.3 Visualizing Microsoft Active Directory data . . . . . . . . . . . . . . . . . . . 225 4.5 Discovering external resources with discovery library reader . . . . . . . . . 226 4.5.1 Exporting the CCMDB data in IDML format . . . . . . . . . . . . . . . . . . 227 4.5.2 Importing the CCMDB data in data center model . . . . . . . . . . . . . . 228 Chapter 5. Software management in Tivoli Provisioning Manager V5.1 235 5.1 Software management in Tivoli Provisioning Manager V5.1 . . . . . . . . . . 237 5.2 Components for software management . . . . . . . . . . . . . . . . . . . . . . . . . 237 5.3 File repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 5.4 Software Package Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 5.4.1 Installing and starting the Software Package Editor . . . . . . . . . . . . 239
Contents
5.5 Software catalog and software products . . . . . . . . . . . . . . . . . . . . . . . . . 244 5.5.1 Importing manually a software package block . . . . . . . . . . . . . . . . 244 5.5.2 Software product requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 5.5.3 Adding parameters to software packages . . . . . . . . . . . . . . . . . . . . 252 5.5.4 Adding software products into groups. . . . . . . . . . . . . . . . . . . . . . . 254 5.5.5 Software views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 5.5.6 Software stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 5.6 Tivoli Provisioning Manager dynamic content delivery service . . . . . . . . 258 5.6.1 The dynamic content delivery service Management Center . . . . . . 259 5.6.2 Depot server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 5.6.3 Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 5.6.4 Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 5.7 Device management service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 5.7.1 Device manager components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 5.7.2 Device management service concepts . . . . . . . . . . . . . . . . . . . . . . 269 5.8 Peer-to-peer file sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 5.8.1 Enabling peer-to-peer file sharing . . . . . . . . . . . . . . . . . . . . . . . . . . 272 5.9 Distributing software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 5.9.1 Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 5.9.2 Publishing to depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 5.9.3 Installing a software package or software stack . . . . . . . . . . . . . . . 278 5.9.4 Delivering before installing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 5.9.5 Scheduling and delivering before installing . . . . . . . . . . . . . . . . . . . 284 5.9.6 Installing by remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 5.9.7 Uninstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 5.10 Inside the distribution process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 5.10.1 Distribution process overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 5.10.2 Distribution process step by step . . . . . . . . . . . . . . . . . . . . . . . . . 288 5.11 Case study: A banking environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 5.11.1 The company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 5.11.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 5.11.3 Infrastructure component overview . . . . . . . . . . . . . . . . . . . . . . . . 296 5.11.4 Infrastructure component detail. . . . . . . . . . . . . . . . . . . . . . . . . . . 298 5.11.5 The logic behind this design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 5.11.6 Keeping the estate up to date . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Chapter 6. Common Agent Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 6.1 Common Agent Services overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 6.2 Agent manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 6.2.1 Ports used by the agent manager . . . . . . . . . . . . . . . . . . . . . . . . . . 311 6.2.2 Installing the agent manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 6.2.3 Troubleshooting the agent manager . . . . . . . . . . . . . . . . . . . . . . . . 314 6.3 Tivoli common agent (TCA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
vi
6.3.1 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6 6.3.7 6.3.8
The authority needed to install the common agent . . . . . . . . . . . . . 322 TCP/IP ports used by the common agent . . . . . . . . . . . . . . . . . . . . 322 Installing the common agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Starting and stoping the Tivoli common agent . . . . . . . . . . . . . . . . 332 Uninstalling Tivoli common agent . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Removing old agents from the registry . . . . . . . . . . . . . . . . . . . . . . 334 Running the common agent discovery and health status report . . . 335 Troubleshooting the common agent . . . . . . . . . . . . . . . . . . . . . . . . 339
Chapter 7. Compliance management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 7.1 Tivoli Provisioning Manager compliance management concepts . . . . . . 346 7.1.1 Compliance management process . . . . . . . . . . . . . . . . . . . . . . . . . 346 7.1.2 Compliance Management scenario. . . . . . . . . . . . . . . . . . . . . . . . . 346 7.2 Compliance checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 7.2.1 Software compliance checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 7.2.2 Security compliance checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 7.2.3 Creating compliance checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 7.2.4 Creating and configuring the Endpoint Agent compliance check . . 358 7.2.5 Creating and configuring Linux compliance checks . . . . . . . . . . . . 360 7.2.6 Creating Windows compliance checks . . . . . . . . . . . . . . . . . . . . . . 364 7.2.7 Creating Solaris compliance checks . . . . . . . . . . . . . . . . . . . . . . . . 369 7.3 Inventory and compliance check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 7.3.1 Inventory scan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 7.3.2 Compliance check scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 7.4 Managing non-compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 7.4.1 Viewing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 7.4.2 Automated remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 7.4.3 Managing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 7.5 Creating a custom remediation workflow . . . . . . . . . . . . . . . . . . . . . . . . 396 7.5.1 Creating a new workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 7.5.2 Compiling and testing a new workflow . . . . . . . . . . . . . . . . . . . . . . 404 7.5.3 Associating the custom workflow with the Recommendation Key . 407 Chapter 8. Patch management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 8.1 Introduction to patch management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 8.1.1 Patch management scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 8.1.2 Typical steps for patch management . . . . . . . . . . . . . . . . . . . . . . . 410 8.1.3 Tivoli Provisioning Manager V5.1 patch management . . . . . . . . . . 411 8.1.4 Scenario used to demonstrate patch management . . . . . . . . . . . . 411 8.2 Preparation required for the Tivoli Provisioning Manager server . . . . . . 412 8.2.1 Downloading the Windows Update Agent . . . . . . . . . . . . . . . . . . . . 412 8.2.2 Configuring the Microsoft Updates Discovery . . . . . . . . . . . . . . . . . 413 8.2.3 Initiating the Microsoft Updates Discovery . . . . . . . . . . . . . . . . . . . 415
Contents
vii
8.2.4 Imported Windows patches in the DCM . . . . . . . . . . . . . . . . . . . . . 419 8.3 Managing patches with the Deployment Engine (DE). . . . . . . . . . . . . . . 421 8.3.1 Creating computer groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 8.3.2 Ensure that an initial inventory is performed on targets . . . . . . . . . 423 8.3.3 Creating a security compliance check. . . . . . . . . . . . . . . . . . . . . . . 423 8.3.4 Installing a WUA agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 8.3.5 Microsoft WUA scan discovery configuration . . . . . . . . . . . . . . . . . 426 8.3.6 Running a compliance check for a group . . . . . . . . . . . . . . . . . . . . 428 8.3.7 Compliance reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 8.3.8 Viewing and approving recommendations . . . . . . . . . . . . . . . . . . . 432 8.3.9 Approving patches for installation . . . . . . . . . . . . . . . . . . . . . . . . . . 433 8.4 Managing patches with the scalable software distribution infrastructure 435 8.4.1 Scan for missing patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 8.4.2 Installing the missing patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 8.4.3 Detailed steps for patch management using the scalable software distribution infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 8.4.4 Creating a region, a depot and a zone . . . . . . . . . . . . . . . . . . . . . . 437 8.4.5 Downloading patches to Tivoli Provisioning Manager repository . . 439 8.4.6 Installing the Tivoli common agent on targets . . . . . . . . . . . . . . . . . 443 8.4.7 Creating an SOA-SAP for endpoint operations . . . . . . . . . . . . . . . . 444 8.4.8 Perform an initial inventory discovery for machines in the group . . 446 8.4.9 Repeating the compliance verification process . . . . . . . . . . . . . . . . 446 8.4.10 Generating the compliance report again . . . . . . . . . . . . . . . . . . . . 448 8.5 Workaround for the patch management workflows . . . . . . . . . . . . . . . . . 449 8.5.1 Applying the workaround to the MS_SOA_DiscoverWindowsUpdates workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 8.5.2 Applying the workaround to the WsusscanToDcm.sh script . . . . . . 450 8.5.3 Applying the workaround to the MS_SOA_DownloadWindowsUpdates workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 Chapter 9. Image management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 9.1 Introduction to image management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 9.1.1 Rembo Server boot process overview . . . . . . . . . . . . . . . . . . . . . . 456 9.1.2 Scenario used to perform image management . . . . . . . . . . . . . . . . 457 9.2 Ways to perform image management . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 9.2.1 Types of imaging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 9.2.2 Types of image restoration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 9.3 Installing a Boot Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 9.3.1 Getting ready to install the Boot Server . . . . . . . . . . . . . . . . . . . . . 459 9.3.2 Initiating the Boot Server installation . . . . . . . . . . . . . . . . . . . . . . . . 460 9.3.3 Selecting the Boot Server type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 9.3.4 Specifying the Boot Server name . . . . . . . . . . . . . . . . . . . . . . . . . . 461 9.3.5 Selecting targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
viii
9.3.6 Configuring the administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 9.3.7 Scheduling now. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 9.3.8 Finishing the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 9.3.9 Workflow execution log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 9.3.10 Starting the Rembo Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 9.3.11 Getting the right version of Sysprep . . . . . . . . . . . . . . . . . . . . . . . 467 9.4 Preparation required to capture an image . . . . . . . . . . . . . . . . . . . . . . . . 468 9.4.1 Ensure that the BIOS settings are properly set . . . . . . . . . . . . . . . . 468 9.4.2 Obtaining an IP address from a DHCP server . . . . . . . . . . . . . . . . 468 9.4.3 Performing an SMB or SSH discovery . . . . . . . . . . . . . . . . . . . . . . 469 9.4.4 Defining the operating system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 9.4.5 Discovering the operating system attributes . . . . . . . . . . . . . . . . . . 469 9.4.6 Discovering the local users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 9.4.7 Setting the administrator DCM password . . . . . . . . . . . . . . . . . . . . 472 9.4.8 Enable boot from Network Interface Card . . . . . . . . . . . . . . . . . . . . 472 9.5 Capturing the images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 9.5.1 Selecting the computer to be captured . . . . . . . . . . . . . . . . . . . . . . 473 9.5.2 Initiating the capture process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 9.5.3 Selecting the source computer and time-out. . . . . . . . . . . . . . . . . . 475 9.5.4 Selecting the Boot Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 9.5.5 Describing the image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 9.5.6 Schedule the image capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 9.5.7 Performing the actual capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 9.5.8 Booting the Rembo kernel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 9.6 Restoring the images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 9.6.1 Preparing the machine to be deployed . . . . . . . . . . . . . . . . . . . . . . 482 9.6.2 Preparing a Rembo Hardware Discovery Task . . . . . . . . . . . . . . . . 482 9.6.3 Identifying the machine to be installed . . . . . . . . . . . . . . . . . . . . . . 483 9.6.4 Selecting the image to be installed . . . . . . . . . . . . . . . . . . . . . . . . . 484 9.6.5 Selecting the targets to be installed . . . . . . . . . . . . . . . . . . . . . . . . 485 9.6.6 Customizing the image restoration . . . . . . . . . . . . . . . . . . . . . . . . . 486 9.6.7 Customizing the OS installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 9.6.8 Finalizing the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 9.7 Advanced topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 9.7.1 Cannot delete a computer that has an image associated to it . . . . 489 9.7.2 Booting from the Boot Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490 9.7.3 When trying to restore an image twice on the same computer . . . . 493 9.7.4 Re-activating Rembo Server license key . . . . . . . . . . . . . . . . . . . . 494 Chapter 10. Reporting and notification . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 10.1 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 10.2 Reporting actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 10.3 Creating reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Contents
ix
10.3.1 Adding report prompts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504 10.3.2 Creating a group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 10.4 Managing reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 10.4.1 Editing reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 10.4.2 Displaying reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509 10.4.3 Importing and exporting reports . . . . . . . . . . . . . . . . . . . . . . . . . . 512 10.4.4 Viewing report history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 10.4.5 Saving and printing report results . . . . . . . . . . . . . . . . . . . . . . . . . 514 10.5 Predefined reports examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516 10.5.1 Audit004 Who was notified about what event? . . . . . . . . . . . . . . . 516 10.5.2 Inventory004 What patches are in the data center? . . . . . . . . . . . 517 10.5.3 Compliance003 Do computers comply with their patch compliance checks?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 10.5.4 Deployment007 What patch deployment ran on which computers? . . 518 10.6 Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 10.6.1 Adding notification to software management tasks . . . . . . . . . . . . 523 10.6.2 Adding user notification for discovery . . . . . . . . . . . . . . . . . . . . . . 523 10.6.3 Adding user notification for reports . . . . . . . . . . . . . . . . . . . . . . . . 524 10.6.4 Adding user notification for favorite tasks . . . . . . . . . . . . . . . . . . . 525 10.6.5 Adding user notification for compliance checks . . . . . . . . . . . . . . 525 Chapter 11. User security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 11.1 User security concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 11.1.1 User authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 11.1.2 User authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 11.1.3 Access Permission group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530 11.1.4 Enable access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531 11.2 A case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532 11.2.1 Create the security role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532 11.2.2 Create the access group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 11.2.3 Create the permission group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535 11.2.4 Associate objects to the access group . . . . . . . . . . . . . . . . . . . . . 536 11.2.5 Create the user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 11.2.6 Assign the user a security role . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 11.2.7 Associate access and permission groups to the use . . . . . . . . . . 543 11.2.8 Enable access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 11.2.9 Validate the access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 Chapter 12. SOAP and command line interface . . . . . . . . . . . . . . . . . . . . 547 12.1 SOAP overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 12.1.1 Using SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 12.2 Location of SOAP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
12.2.1 Running a remote SOAP Client . . . . . . . . . . . . . . . . . . . . . . . . . . 550 12.3 Examples of using SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 12.3.1 Running the SOAP client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 12.3.2 Running the SOAP scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555 12.3.3 Running logical operations using SOAP . . . . . . . . . . . . . . . . . . . . 556 12.4 Tivoli Provisioning Manager V5.1 logical device operations . . . . . . . . . 561 12.5 Tivoli Provisioning Manager V5.1 scripts . . . . . . . . . . . . . . . . . . . . . . . 568 12.5.1 Starting Tivoli Provisioning Manager V5.1 on the command line . 569 12.5.2 Working with automation packages . . . . . . . . . . . . . . . . . . . . . . . 569 12.5.3 Retrieving information about DCM object definitions . . . . . . . . . . 577 12.5.4 Importing data center model definitions . . . . . . . . . . . . . . . . . . . . 578 12.5.5 Exporting data center model (DCM) into an XML file . . . . . . . . . . 579 12.5.6 Pinging the agent manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580 12.5.7 Checking the status of Tivoli Provisioning Manager V5.1 engines 581 Part 2. IBM Tivoli Provisioning Manager for Software V5.1 . . . . . . . . . . . . . . . . . . . . . . . 583 Chapter 13. Migrating Tivoli Configuration Manager to Tivoli Provisioning Manager for Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585 13.1 Tivoli Provisioning Manager for Software overview. . . . . . . . . . . . . . . . 587 13.2 Tivoli Provisioning Manager for Software architecture . . . . . . . . . . . . . 588 13.3 The migration process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591 13.3.1 Staged approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 13.3.2 Stage 1: Moving to a coexistence environment . . . . . . . . . . . . . . 594 13.3.3 Stage 2: Working in a coexistence environment . . . . . . . . . . . . . . 598 13.3.4 Stage 3: Moving to a full Tivoli Provisioning Manager for Software implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601 13.3.5 Migration complete: Working in parallel with the Tivoli Management Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604 13.4 Some typical migration scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606 13.4.1 Central managed nodes and gateways. . . . . . . . . . . . . . . . . . . . . 606 13.4.2 Distributed managed nodes and gateways . . . . . . . . . . . . . . . . . . 607 13.5 Creating coexistence between Tivoli Management Framework and Tivoli Provisioning Manager for Software environments . . . . . . . . . . . . . . . . . 610 13.5.1 Environment used for the integration . . . . . . . . . . . . . . . . . . . . . . 611 13.6 Install Tivoli Provisioning Manager for Software V5.1 . . . . . . . . . . . . . . 612 13.7 Setup the Tivoli Management Framework environment . . . . . . . . . . . . 613 13.7.1 Tivoli Configuration Manager V4.2.3 . . . . . . . . . . . . . . . . . . . . . . . 613 13.7.2 Installing required Interim Fixes on the Tivoli Management Framework environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616 13.8 Map to the Tivoli Management Framework . . . . . . . . . . . . . . . . . . . . . . 620 13.8.1 Adding the infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620 13.8.2 tcm.xml file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Contents
xi
13.9 Replicating the Tivoli Management Framework data . . . . . . . . . . . . . . 628 13.9.1 tcmLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628 13.9.2 tcmReplicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631 13.10 Tivoli Provisioning Manager for Software security overview . . . . . . . . 635 13.11 Configure user security settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636 13.12 Upgrading to the Tivoli Provisioning Manager for Software environment . 641 13.12.1 Upgrading a Tivoli management agent to a Tivoli common agent642 13.12.2 Installing the Tivoli common agent on the Tivoli management agent computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642 13.12.3 Verifying that the Tivoli common agent is running in the upgraded Tivoli management agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 13.12.4 Configuring Tivoli management agent computers to use the software distribution infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645 13.13 Tivoli Provisioning Manager for Software behind the scenes . . . . . . . 646 13.13.1 Database synchronization process . . . . . . . . . . . . . . . . . . . . . . . 646 13.13.2 Report Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652 13.13.3 InventoryConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661 13.13.4 Top level policy region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663 13.14 Mapping of resources and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 664 13.14.1 User interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664 13.14.2 Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software terminology for resource management . . . . . . . . . . . . . . 664 13.14.3 Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software terminology for hardware and group management . . . . . 666 13.14.4 Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software terminology for topology configuration. . . . . . . . . . . . . . . 668 13.14.5 Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software terminology for security . . . . . . . . . . . . . . . . . . . . . . . . . . 670 13.15 Migration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671 13.15.1 Supported functionalities in a coexistence environment . . . . . . . 672 13.15.2 Unsupported Tivoli Configuration Manager devices . . . . . . . . . . 673 13.15.3 Unsupported Tivoli Configuration Manager scenarios . . . . . . . . 673 13.15.4 Unsupported Tivoli Configuration Manager actions . . . . . . . . . . 674 13.15.5 Activity Planner unsupported options . . . . . . . . . . . . . . . . . . . . . 674 13.15.6 Software Package Editor unsupported options . . . . . . . . . . . . . . 676 13.15.7 Considerations on migrated activity plans. . . . . . . . . . . . . . . . . . 676 13.15.8 Considerations on migrated software packages . . . . . . . . . . . . . 677 13.15.9 Identifying reports after the migration process . . . . . . . . . . . . . . 677 13.16 Activity mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680 13.16.1 Software Distribution activities . . . . . . . . . . . . . . . . . . . . . . . . . . 681 13.16.2 Activity Planner activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681 13.16.3 Inventory activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
xii
Chapter 14. Tivoli Configuration Manager migration case studies . . . . 683 14.1 Introduction to case studies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684 14.2 Scanning Tivoli endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685 14.2.1 Running InventoryConfig scan from Tivoli Provisioning Manager V5.1 685 14.2.2 Running Tivoli Provisioning Manager hardware discovery on Tivoli endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693 14.3 ReportManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698 14.4 Distributing software to Tivoli endpoints . . . . . . . . . . . . . . . . . . . . . . . . 699 14.4.1 Tivoli Provisioning Manager concepts and Tivoli Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699 14.4.2 Distributing software package to Tivoli endpoint . . . . . . . . . . . . . . 701 14.4.3 Distributing a software product to a Tivoli endpoint . . . . . . . . . . . 709 14.5 Migrating the Tivoli environment to Tivoli Provisioning Manager . . . . . 717 14.5.1 Discovering the computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718 14.5.2 Creating the region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718 14.5.3 Creating zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719 14.5.4 Creating depots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721 14.5.5 Installing Tivoli common agents . . . . . . . . . . . . . . . . . . . . . . . . . . 725 14.5.6 Assigning new computers to a group . . . . . . . . . . . . . . . . . . . . . . 728 14.5.7 Creating SOA service access point on Tivoli Common Agents . . 729 14.6 Using Activity Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734 14.6.1 Activity Planner scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738 Appendix A. A sample data center model - venice.xml . . . . . . . . . . . . . . 757 A sample data center model - venice.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 Appendix B. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 System requirements for downloading the Web material . . . . . . . . . . . . . 836 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
Contents
xiii
xiv
Figures
1-1 1-2 1-3 1-4 2-1 2-2 2-3 2-4 2-5 2-6 2-7 2-8 2-9 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 The IBM SOA reference architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Service Oriented Architecture (SOA) lifecycle . . . . . . . . . . . . . . . . . . . . . . 6 Customer modelling in the DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Customer example in the DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Tivoli Provisioning Manager components . . . . . . . . . . . . . . . . . . . . . . . . . 34 Scalable Distribution Infrastructure components. . . . . . . . . . . . . . . . . . . . 39 Small data center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Small branch office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Large data center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Large Branch Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Port used by SOA components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Tivoli Provisioning Manager for Software proxy relay . . . . . . . . . . . . . . . . 56 Tivoli Provisioning Manager for Software proxy relay behavior . . . . . . . . 57 Enterprise single-node topology on AIX . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Enterprise two-node topology on AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Invoking the installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 InstallShield Wizard initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Tivoli Provisioning Manager splash screen . . . . . . . . . . . . . . . . . . . . . . . . 90 Preparing the environment splash screen. . . . . . . . . . . . . . . . . . . . . . . . . 91 Tivoli Provisioning Manager Product panel. . . . . . . . . . . . . . . . . . . . . . . . 92 Welcome to the Installation Wizard for Tivoli Provisioning Manager V5.1 panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 3-9 Software License Agreement panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 3-10 Specify the credential for the local system . . . . . . . . . . . . . . . . . . . . . . . 93 3-11 Server deployment configuration panel. . . . . . . . . . . . . . . . . . . . . . . . . . 94 3-12 Configure the target server panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 3-13 Target servers validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 3-14 Tivoli Provisioning Manager and Intelligent Orchestrator V5.1, Disk 2 . . 96 3-15 CIT install and discovery panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3-16 Validation summary panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3-17 Tivoli Provisioning Manager V5.1 tab - Tivoli Provisioning Manager configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3-18 Tivoli Provisioning Manager V5.1 tab - WAS configuration. . . . . . . . . . 100 3-19 Tivoli Provisioning Manager V5.1 tab - TDS configuration . . . . . . . . . . 101 3-20 Tivoli Provisioning Manager V5.1 tab - DB2 configuration . . . . . . . . . . 102 3-21 Tivoli Provisioning Manager Components Configuration tab . . . . . . . . 103 3-22 WebSphere Application Server tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 3-23 DB2 Universal Database tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
xv
3-24 Tivoli Directory Server tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 3-25 Validation summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3-26 Specify the location on the images required for the installation . . . . . . 110 3-27 Summary panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3-28 Installation in progress... - Installation Tasks tab . . . . . . . . . . . . . . . . . 111 3-29 Installation in progress... - Installation Logs tab . . . . . . . . . . . . . . . . . . 112 3-30 Installation summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 3-31 Installation is now complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 3-32 Digital certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 3-33 Log On page to IBM Tivoli Provisioning Manager . . . . . . . . . . . . . . . . . 119 3-34 Welcome page to IBM Tivoli Provisioning Manager . . . . . . . . . . . . . . . 120 3-35 Preparing the environment splash screen. . . . . . . . . . . . . . . . . . . . . . . 135 3-36 Installation is now complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 3-37 Use All packages from an already downloaded Cygwin repository . . . 145 3-38 Preparing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 3-39 Welcome message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 3-40 Administrator user name and password . . . . . . . . . . . . . . . . . . . . . . . . 147 3-41 Local system validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 3-42 One or two node configuration installation . . . . . . . . . . . . . . . . . . . . . . 149 3-43 Target servers configuration data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 3-44 CIT scanner on Disk 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 3-45 Validation summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 3-46 Tivoli Provisioning Manager configuration parameters . . . . . . . . . . . . . 153 3-47 Tivoli Provisioning Manager WAS configuration parameters . . . . . . . . 154 3-48 Tivoli Provisioning Manager TDS configuration data . . . . . . . . . . . . . . 155 3-49 Tivoli Provisioning Manager DB2 configuration data . . . . . . . . . . . . . . 156 3-50 Tivoli Provisioning Manager Components configuration . . . . . . . . . . . . 157 3-51 WAS configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 3-52 TDS configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 3-53 Parameter validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 3-54 Parameter validation summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 3-55 Installation images location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 3-56 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 3-57 Installation progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 3-58 Installation log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 3-59 Installation finished . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 3-60 Installation complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 3-61 Start and Stop TPM Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 3-62 TPM Logon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 3-63 Logged on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 3-64 Change tioappadmin password. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 4-1 Adding a new discovery configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . 178 4-2 Selecting a discovery method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
xvi
4-3 Providing discovery scope and credentials (SAP) . . . . . . . . . . . . . . . . . 180 4-4 Starting SMB discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 4-5 Tracking discovery process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 4-6 Discovery status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 4-7 Workflow execution log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 4-8 Workflow execution log (continued) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 4-9 Workflow execution log for a failed discovery . . . . . . . . . . . . . . . . . . . . . 186 4-10 Discovered computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 4-11 SMB discovered information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 4-12 Service Access Point added after an SMB discovery . . . . . . . . . . . . . . 189 4-13 SSH discovery configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 4-14 SSH Discovery Configuration (continued). . . . . . . . . . . . . . . . . . . . . . . 191 4-15 SSH connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 4-16 SNMP discovery configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 4-17 SNMP discovery configuration (continued) . . . . . . . . . . . . . . . . . . . . . . 194 4-18 Service access points after Tivoli common agent installation . . . . . . . 195 4-19 Base Inventory mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 4-20 Fan-in mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 4-21 Inventory discovery configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 4-22 Inventory discover configuration (continued) . . . . . . . . . . . . . . . . . . . . 199 4-23 Changing concurrency level value . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 4-24 Starting an inventory discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 4-25 Workflow log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 4-26 Discovery profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 4-27 Software signature mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 4-28 Workflow log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 4-29 Workflow log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 4-30 Service Access Point added for software distribution operations . . . . . 206 4-31 TCA-Subagent JES configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 4-32 Hardware Inventory results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 4-33 Software inventory results in Tivoli Provisioning Manager . . . . . . . . . . 210 4-34 Software inventory results in Tivoli Provisioning Manager for Software 211 4-35 Custom signature configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 4-36 Custom signature scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 4-37 Custom signature scan results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 4-38 Adding a discovery policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 4-39 Adding multiple discovery policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 4-40 Tracking changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 4-41 Update changes in data center model . . . . . . . . . . . . . . . . . . . . . . . . . 218 4-42 Microsoft Active Directory discovery configuration . . . . . . . . . . . . . . . . 220 4-43 Microsoft Active Directory discovery configuration . . . . . . . . . . . . . . . . 222 4-44 Microsoft Active Directory log: computers discovery. . . . . . . . . . . . . . . 223 4-45 Microsoft Active Directory log: organizations discovery . . . . . . . . . . . . 224
Figures
xvii
4-46 Microsoft Active Directory log: groups discovery . . . . . . . . . . . . . . . . . 224 4-47 Active Directory discovered computer. . . . . . . . . . . . . . . . . . . . . . . . . . 225 4-48 Active Directory discovered groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 4-49 Discovery library reader scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 4-50 Discovery library reader creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 4-51 Discovery library reader configuration. . . . . . . . . . . . . . . . . . . . . . . . . . 230 4-52 Discovery library reader execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 4-53 Discovery library reader discovered system . . . . . . . . . . . . . . . . . . . . . 232 4-54 Discovery library reader discovered data . . . . . . . . . . . . . . . . . . . . . . . 233 5-1 Setting Software Package Editor preferences . . . . . . . . . . . . . . . . . . . . 241 5-2 The Software Package Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 5-3 Saving a software package locally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 5-4 Importing software product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 5-5 Define software product stage 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 5-6 Set file name and location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 5-7 Select device driver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 5-8 Device driver properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 5-9 Review settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 5-10 Selecting upload package file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 5-11 Entering the oackage path and file name . . . . . . . . . . . . . . . . . . . . . . . 248 5-12 Review Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 5-13 Upload successful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 5-14 Checking SIE requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 5-15 Adding SIE requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 5-16 Adding a new configuration template parameter. . . . . . . . . . . . . . . . . . 253 5-17 Force parameter added. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 5-18 Adding a group of software packages. . . . . . . . . . . . . . . . . . . . . . . . . . 254 5-19 Creating a software view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 5-20 Using a software view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 5-21 Adding software to a stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 5-22 Reordering software in the stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 5-23 Depot creation dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 5-24 Depot creation initialized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 5-25 Viewing depot status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 5-26 Viewing files on Depot server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 5-27 Viewing regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 5-28 Adding a region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 5-29 Adding a zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 5-30 Checking SOA SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 5-31 Setting default peering option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 5-32 Publishing a software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 5-33 Tracking a Publish task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 5-34 Checking the files on a depot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
xviii
5-35 Selecting software packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 5-36 Selecting targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 5-37 Advanced options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 5-38 Installation submitted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 5-39 Tracking the installation task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 5-40 Depot and peer statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 5-41 Install without distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 5-42 Schedule an install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 5-43 Distribute prior to install. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 5-44 Tracking the two tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 5-45 Distribution process - high level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 5-46 Software Distribution step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 5-47 Software Distribution step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 5-48 Software Distribution step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 5-49 Software Distribution step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 5-50 Software Distribution step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 5-51 Software Distribution step 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 5-52 XYZ Corporation locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 5-53 Case study regions and zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 5-54 Compliance check results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 5-55 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 5-56 Standard compliance report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 5-57 Custom compliance report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 6-1 Common Agent Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 6-2 Install common agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 6-3 Track common agent install task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 6-4 Initiate Discovery page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 6-5 Discover all agents known to AgentManager . . . . . . . . . . . . . . . . . . . . . 337 6-6 Track task for discover all agents in the agent manager. . . . . . . . . . . . . 338 6-7 Endpoint status report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 7-1 The All_Computers group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 7-2 Creating compliance checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 7-3 Adding security compliance checks for the All_Computers group . . . . . 358 7-4 Assigning the endpoint agent compliance check . . . . . . . . . . . . . . . . . . 359 7-5 Configuring the endpoint agent compliance check . . . . . . . . . . . . . . . . . 359 7-6 Adding the security compliance checks for Linux . . . . . . . . . . . . . . . . . . 360 7-7 Assigning the security compliance checks . . . . . . . . . . . . . . . . . . . . . . . 360 7-8 Linux security compliance check added . . . . . . . . . . . . . . . . . . . . . . . . . 361 7-9 Accessing the settings of Unix services compliance check . . . . . . . . . . 361 7-10 Adding Unix Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 7-11 Specifying the name of the Unix service . . . . . . . . . . . . . . . . . . . . . . . . 362 7-12 Ftp Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 7-13 Linux compliance checks added . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Figures
xix
Adding software compliance checks . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Adding software compliance checks . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Adding the Windows Update Agent software product. . . . . . . . . . . . . . 366 Configuring the software compliance check . . . . . . . . . . . . . . . . . . . . . 366 Adding Windows security compliance checks. . . . . . . . . . . . . . . . . . . . 367 Windows firewall compliance check settings . . . . . . . . . . . . . . . . . . . . 368 Windows compliance checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Adding the Unix file permissions compliance check . . . . . . . . . . . . . . . 370 Adding files to the Unix file permissions compliance check . . . . . . . . . 370 Configuring file permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 Unix file permissions compliance check . . . . . . . . . . . . . . . . . . . . . . . . 371 Running the inventory scan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 Inventory scan task submitted. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 Inventory scan progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 Linux group: Inventory scan details. . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Security compliance scan workflow details . . . . . . . . . . . . . . . . . . . . . . 376 Scheduling the inventory scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Settings for the inventory scan schedule . . . . . . . . . . . . . . . . . . . . . . . 377 Running the compliance check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Compliance check launched . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Compliance check details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 Compliance tab for the XP_computers group . . . . . . . . . . . . . . . . . . . . 380 Scheduling the compliance check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Compliance check schedule settings . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Compliance check and Inventory scan schedule . . . . . . . . . . . . . . . . . 382 Track tasks windows for scheduled compliance check and inventory scan 382 7-40 Compliance tab for XP_Computers group . . . . . . . . . . . . . . . . . . . . . . 384 7-41 Patches and Updates recommendations . . . . . . . . . . . . . . . . . . . . . . . 385 7-42 Recommendations tab of the XP_Computers group. . . . . . . . . . . . . . . 386 7-43 Compliance global settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 7-44 Linux_Computers compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 7-45 Approving recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 7-46 Running compliance remediation for the XP_Computers group . . . . . . 390 7-47 Remediation task details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 7-48 Workflow details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 7-49 Failed compliance remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 7-50 Recommendation task details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 7-51 Workflow execution log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 7-52 XP_Computers compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 7-53 Unix file permissions recommendation . . . . . . . . . . . . . . . . . . . . . . . . . 397 7-54 Adding a new workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 7-55 Compiling a workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
7-14 7-15 7-16 7-17 7-18 7-19 7-20 7-21 7-22 7-23 7-24 7-25 7-26 7-27 7-28 7-29 7-30 7-31 7-32 7-33 7-34 7-35 7-36 7-37 7-38 7-39
xx
7-56 7-57 7-58 7-59 7-60 7-61 7-62
Wokflow compiled successfully. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 Running a workflow - Input parameters . . . . . . . . . . . . . . . . . . . . . . . . 405 Determining the compliance recommendation ID . . . . . . . . . . . . . . . . . 405 Workflow Deployment Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 Workflow execution details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 Global Settings Compliance Management . . . . . . . . . . . . . . . . . . . . . . 407 Changing the workflow for the UnixFileACLDesiredStateElement_Remediation_wf key . . . . . . . . . . . . 407 7-63 Changing the default workflow for UnixFileACLDesiredStateElement_Remediation_wf . . . . . . . . . . . . . . . 408 8-1 Scenario used to demonstrate patch management . . . . . . . . . . . . . . . . 412 8-2 Microsoft Updates Discovery configuration . . . . . . . . . . . . . . . . . . . . . . . 414 8-3 Microsoft Updates Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 8-4 Imported groups of Windows patches. . . . . . . . . . . . . . . . . . . . . . . . . . . 420 8-5 Managing Microsoft patches with the Deployment Engine . . . . . . . . . . . 422 8-6 Adding Security Compliance Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 8-7 Installing a WUA agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 8-8 Initiating a patch discovery using the WUA scanner . . . . . . . . . . . . . . . . 428 8-9 Security Compliance Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 8-10 Issues and recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 8-11 Task Details: Compliance Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 8-12 Running Compliance008 report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 8-13 Viewing and approving recommendations . . . . . . . . . . . . . . . . . . . . . . 433 8-14 Compliance Remediation for patches . . . . . . . . . . . . . . . . . . . . . . . . . . 435 8-15 Creating a region and a zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 8-16 Creating a depot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 8-17 Running MS_SOA_DownloadWindowsUpdates. . . . . . . . . . . . . . . . . . 441 8-18 Downloading Patches Workflow Execution Log . . . . . . . . . . . . . . . . . . 442 8-19 Reboots controlled within workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 8-20 Creating an SOA-SAP for endpoint operations. . . . . . . . . . . . . . . . . . . 444 8-21 Task details for ITSO Create SOA-SAP for clients . . . . . . . . . . . . . . . . 445 8-22 Checking the status of SOA-SAP for endpoint operations . . . . . . . . . . 445 8-23 Inventory Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 8-24 Security compliance check after applying patches . . . . . . . . . . . . . . . . 448 8-25 Assign Workflow to the Microsoft Updates Discovery . . . . . . . . . . . . . . 450 9-1 Rembo boot process chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 9-2 Used scenario for image management . . . . . . . . . . . . . . . . . . . . . . . . . . 458 9-3 Initiating the boot server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460 9-4 Choosing Rembo as a Boot Server type. . . . . . . . . . . . . . . . . . . . . . . . . 461 9-5 Specifying the Boot Server name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 9-6 Selecting targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 9-7 Configuring the administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 9-8 Scheduling now the Add Boot Server task . . . . . . . . . . . . . . . . . . . . . . . 465
Figures
xxi
9-9 Summary of the installation to be performed . . . . . . . . . . . . . . . . . . . . . 465 9-10 Workflow execution log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 9-11 Starting the Rembo Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 9-12 Defining the Operating System and the language . . . . . . . . . . . . . . . . 469 9-13 Windows Configuration Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 9-14 Discovering Local Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 9-15 Updating the DCM password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 9-16 Selecting Network Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 9-17 Selecting the machine to be captured. . . . . . . . . . . . . . . . . . . . . . . . . . 474 9-18 Initiating the Capture Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 9-19 Selecting the Source and time-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 9-20 Selecting the Boot Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 9-21 Providing image information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 9-22 Schedule now the image to be captured. . . . . . . . . . . . . . . . . . . . . . . . 478 9-23 Performing the actual capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 9-24 Rembo Kernel on the machine to be captured . . . . . . . . . . . . . . . . . . . 480 9-25 Creating a Rembo Hardware Discovery Task . . . . . . . . . . . . . . . . . . . . 483 9-26 Entering the serial number and host name . . . . . . . . . . . . . . . . . . . . . . 484 9-27 Selecting the image to be installed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 9-28 Select the targets to be installed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 9-29 Customizing the pristine installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 9-30 Customizing the OS installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 9-31 Proceeding with the restoration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 9-32 Rembo Server Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 9-33 Event Viewer error for expired license key . . . . . . . . . . . . . . . . . . . . . . 494 9-34 URL to generate activation token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 9-35 Generation of an activation token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 10-1 Create Report - Report Description page . . . . . . . . . . . . . . . . . . . . . . . 501 10-2 Create Report - Report Constraints page . . . . . . . . . . . . . . . . . . . . . . . 502 10-3 Create Report - Report Layout page. . . . . . . . . . . . . . . . . . . . . . . . . . . 503 10-4 Report output example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504 10-5 Audit004 Who was notified about what event? . . . . . . . . . . . . . . . . . . . 516 10-6 Inventory004 What patches are in the data center? . . . . . . . . . . . . . . . 517 10-7 Compliance003 Do computers comply with their patch compliance checks? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 10-8 Deployment007 What patch deployment ran on which computers? . . . 519 10-9 Discovery002 Input Parameter List . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 10-10 Discovery002 What objects were discovered by which discovery configuration? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 11-1 Pre-defined security user roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 11-2 Enable access control from the global settings page . . . . . . . . . . . . . . 531 11-3 ITSO Patchman security role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 11-4 Create access group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
xxii
11-5 List of access groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535 11-6 Create permission group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 11-7 Associate ITSO Windows group to ITSO PatchmanAG . . . . . . . . . . . . 537 11-8 Assign all computers to the ITSO PatchmanAG . . . . . . . . . . . . . . . . . . 538 11-9 ITSO PatchmanAG members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 11-10 Add new user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 11-11 Assign security role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 11-12 Assign access group and permission . . . . . . . . . . . . . . . . . . . . . . . . . 543 11-13 Logon patchman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544 11-14 Restricted computers and software products . . . . . . . . . . . . . . . . . . . 545 11-15 Restricted Inventory reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 12-1 Tivoli Provisioning Manager V5.1 supplied SOAP Scripts . . . . . . . . . . 549 12-2 Tivoli Provisioning Manager V5.1 SOAP Client JAR files . . . . . . . . . . . 551 12-3 Obtaining the Application Cluster ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 558 12-4 Workflow Execution Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558 12-5 Result of Cluster.AddServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559 12-6 Commands scripts located in $TIO_HOME/tools . . . . . . . . . . . . . . . . . 569 13-1 Adding SOA for Provisioning to Tivoli Configuration Manager . . . . . . . 589 13-2 Tivoli Provisioning Manager for Software V5.1 architectural view . . . . 590 13-3 TCM to TPM for Software 5.1: Historical background . . . . . . . . . . . . . . 592 13-4 Hub and spoke architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595 13-5 Coexistence between Tivoli Provisioning Manager for Software and Tivoli Management Framework topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596 13-6 Working on both Tivoli endpoints and Tivoli common agents . . . . . . . . 599 13-7 Moving to a Tivoli Provisioning Manager environment . . . . . . . . . . . . . 603 13-8 Computers running both the Tivoli common agent and the Tivoli management agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605 13-9 Central gateways / managed nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 607 13-10 Distributed gateways / managed nodes . . . . . . . . . . . . . . . . . . . . . . . 608 13-11 TCM integrated with TPM for Software using central gateways . . . . . 609 13-12 TPM for Software parallel to TCM Infrastructure. . . . . . . . . . . . . . . . . 610 13-13 Integration lab environment diagram. . . . . . . . . . . . . . . . . . . . . . . . . . 612 13-14 Add Database dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621 13-15 Add Hub dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623 13-16 Add Activity Plan Database dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . 625 13-17 Security actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635 13-18 Computer ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644 13-19 TCA_PingAgent workflow execution log . . . . . . . . . . . . . . . . . . . . . . . 645 13-20 Connections generic architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648 13-21 Database link diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650 13-22 Connections between endpoint and other resources inside Tivoli Provisioning Manager for Software DCM . . . . . . . . . . . . . . . . . . . . . . . . 651 13-23 Report Manager - internals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
Figures
xxiii
13-24 Report Manager - reports handling . . . . . . . . . . . . . . . . . . . . . . . . . . . 654 13-25 Migrated reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679 13-26 HDISK_QUERY report execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680 14-1 Case study environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684 14-2 Replicated InventoryConfig profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 686 14-3 Replicated scanned endpoint elpaso-ep Inventory data . . . . . . . . . . . . 687 14-4 Tivoli endpoint credentials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688 14-5 Initiate Tivoli inventory scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689 14-6 Track task details of the Inventory scan discovery . . . . . . . . . . . . . . . . 691 14-7 DCM data collected through Tivoli scan discovery . . . . . . . . . . . . . . . . 692 14-8 SOA Inventory discovery in progress . . . . . . . . . . . . . . . . . . . . . . . . . . 694 14-9 Software catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 14-10 Software definition page of replicated ITPMfSW_Beta_Viewlet . . . . . 703 14-11 Software installable page of replicated ITPMfSW_Beta_Viewlet . . . . 704 14-12 Variables tab of the ITPMfSW_Beta_Viewlet installable . . . . . . . . . . . 704 14-13 Submit install ITPMfSW_Beta_Viewlet software product . . . . . . . . . . 706 14-14 Track installation task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707 14-15 Task details ITPMfSW_Beta_Viewlet installation . . . . . . . . . . . . . . . . 708 14-16 Install software product from catalog . . . . . . . . . . . . . . . . . . . . . . . . . 710 14-17 Install Software products on Tivoli endpoints . . . . . . . . . . . . . . . . . . . 711 14-18 Advanced options to install software. . . . . . . . . . . . . . . . . . . . . . . . . . 712 14-19 Track AppA_v1.0 installation task . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713 14-20 Installation task details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714 14-21 Track task results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717 14-22 Create Europe region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719 14-23 Create Milan zone in Europe region . . . . . . . . . . . . . . . . . . . . . . . . . . 720 14-24 Create depot on milan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722 14-25 Task details result depot installation prov003 . . . . . . . . . . . . . . . . . . . 723 14-26 The depot servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724 14-27 Depot characteristics of milan.itsc.austin.ibm.com . . . . . . . . . . . . . . . 725 14-28 Install the AIX common agents in the Europe zone . . . . . . . . . . . . . . 726 14-29 Install the Windows common agents in the Antwerp data center . . . . 727 14-30 Create AntwerpComputerGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728 14-31 EuropeComputerGroup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729 14-32 Select SOA credential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730 14-33 Advanced Search by grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731 14-34 Specify targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732 14-35 Add Credential Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733 14-36 Set soahost as default endpoint-operations SAP . . . . . . . . . . . . . . . . 734 14-37 Activity Planner architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737 14-38 APM database properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739 14-39 Manage Activity Plans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740 14-40 Inoperative plan in the Activity Plan Editor . . . . . . . . . . . . . . . . . . . . . 741
xxiv
14-41 14-42 14-43 14-44 14-45 14-46 14-47 14-48 14-49
TPM_Plan1 layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745 Run TPM_Plan1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746 Track activity plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747 Activity Distribute targets and status . . . . . . . . . . . . . . . . . . . . . . . . . . 748 Activity Install not started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749 SoftwareModule.Install workflow arguments. . . . . . . . . . . . . . . . . . . . 750 Activity Install status and targets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751 Depot statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752 Activity Task status and targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Figures
xxv
xxvi
Tables
1-1 Comparison of products within the Tivoli Provisioning Manager (TPM) family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1-2 TCM 4.2.3 and TPM 5.1 user interface mapping . . . . . . . . . . . . . . . . . . . 23 2-1 Supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2-2 Supported prerequisite software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2-3 Ports used for communication between TPM SOA components . . . . . . . 53 2-4 Ports to be opened in a single firewall scenario . . . . . . . . . . . . . . . . . . . . 55 3-1 Tivoli Provisioning Manager Installation options . . . . . . . . . . . . . . . . . . . . 64 3-2 Hardware and software requirements for the Topology Installer . . . . . . . 67 3-3 Hardware requirements for Tivoli Provisioning Manager . . . . . . . . . . . . . 69 3-4 Disk space requirements for the prerequisite software . . . . . . . . . . . . . . . 69 3-5 Prerequisite software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3-6 Communication port used by Tivoli Provisioning Manager . . . . . . . . . . . . 72 3-7 Required directory structure for images . . . . . . . . . . . . . . . . . . . . . . . . . . 74 3-8 Default path locations for Tivoli Provisioning Manager components. . . . . 79 3-9 Required free space for custom file systems . . . . . . . . . . . . . . . . . . . . . 107 3-10 Required free space for default file systems . . . . . . . . . . . . . . . . . . . . . 108 3-11 Installation timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 3-12 Hardware and software requirements for the Topology Installer . . . . . 121 3-13 Hardware requirements for Tivoli Provisioning Manager . . . . . . . . . . . 123 3-14 Disk space requirements for the prerequisite software . . . . . . . . . . . . . 123 3-15 Prerequisite software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 3-16 Required directory structure for images . . . . . . . . . . . . . . . . . . . . . . . . 126 3-17 Default path locations for Tivoli Provisioning Manager components. . . 129 5-1 Depot configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 5-2 Zone configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 6-1 Ports used by the agent manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 6-2 TCP/IP ports used by common agent . . . . . . . . . . . . . . . . . . . . . . . . . . 322 6-3 Installation and uninstallation program return values.. . . . . . . . . . . . . . . 332 6-4 Installation logs for the Tivoli common agent . . . . . . . . . . . . . . . . . . . . . 340 6-5 Runtime logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 12-1 WSDL Service name and URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 12-2 SOAP Wrapper Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555 13-1 Tivoli Configuration Manager 4.2.x evolution . . . . . . . . . . . . . . . . . . . . 591 13-2 Upgrade strategy stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 13-3 Operating systems and supported databases. . . . . . . . . . . . . . . . . . . . 613 13-4 Replication settings summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634 13-5 Security roles mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
xxvii
13-6 REP_MANAGER table schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655 13-7 TCM V4.2.3 UIs versus TPM for Software V5.1 UIs . . . . . . . . . . . . . . . 664 13-8 Tivoli Configuration Manager versus Tivoli Provisioning Manager for SW 5.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665 13-9 TCM versus TPM for Software V5.1 Hardware and Group Management terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666 13-10 TCM versus TPM for SW 5.1 - Topology Configuration terminology . 668 13-11 TCM versus Tivoli Provisioning Manager for SW 5.1 - Security terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670 13-12 Functions unavailable on Tivoli Provisioning Manager for Software . . 672 13-13 Migrated reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678 13-14 Software Distribution activities mapping . . . . . . . . . . . . . . . . . . . . . . . 681 13-15 Activity Planner mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681 13-16 Inventory activities mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682 14-1 Tivoli Provisioning Manager discovery conversion to TCM InventoryConfig 697 14-2 Tivoli Configuration Manager/Tivoli Provisioning Manager operations mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 14-3 Activity Planner operation mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . 735 14-4 Supported operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
xxviii
Examples
3-1 Machines configuration used in the lab for the installation . . . . . . . . . . . . 70 3-2 Central image depot directory structure on AIX . . . . . . . . . . . . . . . . . . . . 74 3-3 Hardware and software requirements check. . . . . . . . . . . . . . . . . . . . . . . 78 3-4 File system structure used in lab environment . . . . . . . . . . . . . . . . . . . . . 80 3-5 Required packages installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3-6 Installation instructions for openSSL and openSSH . . . . . . . . . . . . . . . . . 82 3-7 Verify bash and expect locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 3-8 Command to verity the xlC.rte file package installation . . . . . . . . . . . . . . 86 3-9 log file directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 3-10 Checking the status of the Tivoli Provisioning Manager . . . . . . . . . . . . 117 3-11 /tivcode/cit directory content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 3-12 Installation invocation in record mode. . . . . . . . . . . . . . . . . . . . . . . . . . 134 3-13 Response file used for the installation. . . . . . . . . . . . . . . . . . . . . . . . . . 137 3-14 Installation invocation in silent mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 143 3-15 Installation_images contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 3-16 Backup the TC and LDAP database . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 5-1 Importing a SSL certificate for SPE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 5-2 jes.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 5-3 Running the workflow on device 2385 . . . . . . . . . . . . . . . . . . . . . . . . . . 270 5-4 Example cdsclient.properties file with peering disabled . . . . . . . . . . . . . 273 5-5 Example cdsclient.properties file after peering enabled . . . . . . . . . . . . . 274 6-1 Agent manager properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 6-2 HealthCheck script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 6-3 LogCollector script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 6-4 tcatemp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 6-5 Endpoint.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 6-6 jes.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 6-7 service.sh script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 7-1 The workflow code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 7-2 Define the name of the workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 7-3 Query the DCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 7-4 UnixFileACLRule object definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 7-5 File object definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 7-6 Using DCMQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 7-7 Log the message variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 7-8 Definition of a Perl scriptlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 8-1 Installing cabextract utility on the AIX Operating System . . . . . . . . . . . . 418 8-2 Content of /opt/ibm/tivoli/tpm/repository/wua/wsusscancab/update directory
xxix
420 8-3 Changes to the WsusscanToDcm.sh script . . . . . . . . . . . . . . . . . . . . . . 451 9-1 Message we get when trying to restore an image twice . . . . . . . . . . . . . 493 10-1 Text in the report.xml file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515 12-1 Sample output from browsing to a WSDL URL . . . . . . . . . . . . . . . . . . . 553 12-2 Using the soapcli.cmd to retrieve all deployment requests . . . . . . . . . . 554 12-3 Output of the findAllDeplotmentRequests operation . . . . . . . . . . . . . . . 554 12-4 Using soapcli to run a logical device operation . . . . . . . . . . . . . . . . . . . 557 12-5 Using soapcli to run the Cluster.AddServer Logical Device Operation . 557 12-6 The output of running the Cluster.AddServer executeDeploymentRequest 558 12-7 Using soapcli to view the completion status of a deployment request. . 559 12-8 Using soapcli to show deployments in progress . . . . . . . . . . . . . . . . . . 559 12-9 Using soapcli to show execution log details of a deployment request . 560 12-10 Logical device operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561 12-11 Starting Tivoli Provisioning Manager V5.1 on the command line . . . . 569 12-12 Listing status of Automation Packages . . . . . . . . . . . . . . . . . . . . . . . . 570 12-13 Installing an Automation package using tc-driver-manager.cmd . . . . 573 12-14 Retrieving information about data center objects . . . . . . . . . . . . . . . . 578 12-15 Importing a DCM Object XML file using xmlimport.cmd . . . . . . . . . . . 578 12-16 Exporting the DCM into an XML file . . . . . . . . . . . . . . . . . . . . . . . . . . 580 12-17 Pinging the agent manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580 12-18 Checking the status of Tivoli Provisioning Manager V5.1 engines . . . 581 13-1 Checking for installation of Tivoli Configuration Manager V4.2.3 Fix Pack 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614 13-2 Validating Inventory scripts for Tivoli Configuration Manager V4.2.3 Fix Pack 02. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615 13-3 Software Distribution, Version 4.2.3, Interim 4.2.3.2-TIV-SWDSRV-IF0002 617 13-4 rep_db2.sql script execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617 13-5 Inventory Server, Version 4.2.3, Interim Fix 4.2.3.2-TIV-INV-IF0002 . . 620 13-6 Checking the default port used by IBM DB2 . . . . . . . . . . . . . . . . . . . . . 622 13-7 Sample tcm.xml file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626 13-8 xmlimport command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627 13-9 sample milan.xml file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637 13-10 admin.ldif example file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639 13-11 Report Manager configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656 13-12 Trace showing a standard processing . . . . . . . . . . . . . . . . . . . . . . . . 657 14-1 Tivoli Provisioning Manager initiated Tivoli scan . . . . . . . . . . . . . . . . . 689 14-2 InventoryConfig profile created from Tivoli Provisioning Manager discovery configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694 14-3 REP_MANAGER table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698 14-4 Tivoli management region software package object id. . . . . . . . . . . . . 704
xxx
14-5 14-6 14-7 14-8 14-9
Tivoli Provisioning Manager initiated Software package installation . . 708 TMF activities when distributing and installing a software product . . . . 715 XML exported activity plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742 Excerpt of console.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753 A sample data center model - venice.xml . . . . . . . . . . . . . . . . . . . . . . . 758
Examples
xxxi
xxxii
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 illustrate 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.
xxxiii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Eserver Eserver Redbooks (logo)
The following terms are trademarks of other companies: Java and all Java-based trademarks are 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 logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. 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, or service names may be trademarks or service marks of others.
xxxiv
Preface
This redbook is a deployment guide for both Tivoli Provisioning Manager Version 5.1 and Tivoli Provisioning Manager for Software Version 5.1. The new version of Tivoli Provisioning Manager comes with two packaging options: Tivoli Provisioning Manager Version 5.1, which is the new version of Tivoli Provisioning Manager that includes also part of the services currently provided by Tivoli Management Framework plus most of the features formerly referred to as Tivoli Configuration Manager in the context of the Service Oriented Architecture (SOA) infrastructure. Tivoli Provisioning Manager for Software Version 5.1 which introduces coexistence with an existing Tivoli Management Framework installation and provides a natural progression path from Tivoli Configuration Manager 4.2.3. In this redbook we cover Tivoli Provisioning Manager Version 5.1 in Part 1 and Tivoli Provisioning Manager for Software Version 5.1 in Part 2. You can refer to Chapter 1 for detailed information about the packaging of these 2 products. The target audience of the redbook is Tivoli Configuration Manager Version 4.2.X and Tivoli Provisioning Manager Version 3.1 specialists. If your background is on Tivoli Configuration Manager, you might want to skip Part 1 and start from Part 2, where we discuss Tivoli Provisioning Manager for Software, migration and co-existence considerations with an existing Tivoli Configuration Manager environment. But to learn more about new capabilities of the Tivoli Provisioning Manager V5.1, we also suggest you read Part 1. If you are coming from the Tivoli Provisioning Manager Version 3.1 background, Part 2 of the book is probably not for you.
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center. Vasfi Gucer is an IBM Certified Consultant IT Specialist at the ITSO Austin Center. He has been with IBM Turkey for 10 years, and has worked at the ITSO since January 1999. He has more than 15 years of experience in teaching and implementing systems management, networking hardware, and distributed
xxxv
platform software. He actively presents at various Tivoli Technical User Conferences and User Group meetings. He has worked on various Tivoli client projects as a Systems Architect and Consultant. Vasfi is also a Certified Tivoli Consultant. Alfredo Olivieri is an IBM IT Specialist working for Italy IMT in IBM Lab Services within Software Group. He worked in IBM since 2000, and has extensive experience with many Tivoli products. Throughout his career, he has been involved in several project implementing Tivoli solutions for important clients in Italy, Israel, Portugal and Turkey. Before joining IBM Lab Services he worked for Rome Tivoli Laboratory in the Test team. In 2005 he got an IBM Tivoli Configuration Manager 4.2 Deployment Professional Certification and he is also ITIL Certified. David Campbell is a Technical Consultant for the IBM Software Group Services for Tivoli in the UK. He is a Senior IT Specialist and Tivoli Certified Consultant and has worked with Tivoli software both as a customer and within IBM for around 10 years. He has used many Tivoli products and now specialises in Tivoli Configuration Manager and has worked with many UK and international customers including several of the UK's largest financial institutions. He lives in deepest Essex in the UK with his very understanding wife and two beautiful daughters. Fabrizio Salustri is a Software Support Specialist working for Italy IMT in Tivoli Customer Support within IBM Global Services. He worked for IBM since 1996, and has extensive experience with Tivoli products suite. Throughout his career, Fabrizio has been involved in several projects implementing Tivoli solutions for important clients of IBM Italy. Before joining the Tivoli Support team, he worked as a Certified AIX System Administrator in AIX Technical Support. In March 2005 he got an IBM Tivoli Monitoring 5.1.1 Deployment Professional Certification and in April 2006 an IBM Tivoli Monitoring 6.1 Deployment Professional Certification. Ghufran Shah is a Tivoli Certified Enterprise Consultant and Instructor with os-security.com in the United Kingdom. He has eight years of experience in Systems Development and Enterprise Systems Management. He holds a degree in Computer Science from the University of Bradford. His areas of expertise include Tivoli Systems Management Architecture, Implementation, and Tivoli Training, together with Business Process Improvement and Return on Investment modeling. He has written extensively about event Management, Monitoring, and Business Systems Management integration and has taught Tivoli courses worldwide. Johan Raeymaeckers is an IT Consultant working for JorSy Systems Management in Belgium. He has six years of Enterprise Systems Management experience. He is a Certified Tivoli Consultant and Instructor. He has worked on
xxxvi
various large scale Tivoli projects and is involved in Tivoli course development for IBM. Marc Remes is an IT Specialist working for IBM Belgium. He has more than 10 years of experience in enterprise system management. Before entering the systems management field he did application development focusing on communication protocols and human-machine interface. He is a Tivoli Certified Consultant with expertise in Tivoli Framework and Deployment. He has worked in various large Tivoli customer projects, and is currently working in IBM Global Services. Murtuza Choilawala is a Senior Software Engineer with IBM Tivoli. He is a IBM Certified IT Specialist working with Tivoli Global Response Team (GRT) helping customers resolve critical situations and provide technical support on various Tivoli products. He actively presents at various Tivoli Technical User Conferences and User Group meetings. He has 13 years of experience in information technology and last 6 years have been with Tivoli. He has a Bachelors Degree in Computer Engineering, and a Diploma in Computer Engineering. Prior to joining Tivoli he was working with iSeries platform. He has also been a Product Manager for AS/400 systems as a Business Partner. Philippe Hamelin is a Canadian registered Professional Engineer and specializes in the discipline of Configuration and Provisioning Management. Philippe is also a Certified Tivoli Consultant & Instructor. During the past 15 years, he has worked with different IBM technologies, primarily, ITCM, NvDM, OS/2 CID and now TPM. He has developed many Configuration Management courses and workshops for IBM. Philippe lives in Canada and spends most of his time on the road carrying-out consulting work in the United States, Canada and Europe. Scott Berens is a Support Engineer at IBM working in Tivoli Support with ITIO and ITPM since July 2004. He recently worked 6 weeks in Component Verification and Test (CVT) for TPM 5.1 in Toronto, Canada. Prior to IBM he worked as a System Administrator for Applied Research Laboratories and graduated from the University of Texas in Austin. Ignacio Fernandez Gonzales is working for a major financial institution in the United Kingdom as a Senior Team member of the Systems Management and Monitoring Department in ISD-CIO Division. His current interests are IT Provisioning and Service Management . In the past he has worked as an IT Architect in Tivoli Services within the IBM Software Group for 10 years and has gained extensive experience with large deployments of the IBM Tivoli suite of products, playing a key role as the Systems Management Team Leader during Sydney 2000 Olympic Games. He holds a Masters Degree in Telecommunications Engineering from Universidad Politecnica de Madrid (UPM). Ignacio is a member of the Institute of Electrical and Electronic
Preface
xxxvii
Engineers, Inc., (IEEE) and has published two Patents by the US Patent and Trademark Office. Thanks to the following people for their contributions to this project: Arzu Gucer, Morten Moeller, Editors name International Technical Support Organization, Austin Center Emma Jacobs International Technical Support Organization, San Jose Center Paul Chen, Dan Constantinescu, Pablo Dely, Steve Haerte, Cindy Lee, Dejan Krzelj, Nicholas Kocsis, Gary G Lee, Maxim Marintchenko, Mike McIntyre, Jeff McRae, Mircea Mihaescu, George Sekulic, Laurentiu Tecsa, Helen Xu, Ting Xue, Paul Vytas, Joe Wigglesworth, Bill Wong IBM Canada Paul Casterlin, Peter Greulich, Wesley J Gyure, Doug Ledden, Edmund Troche, Patrick Woods IBM US Valory Batchellor IBM UK Gianluca Bernardini, Massimiliano Celli, Cristina Bonanni, Michele Crudele, Susan Chen, Anna Ciotti, Fabio De Angelis, Maria Gallo, Francesco Lupini, GianFilippo Maniscalco, Stefania Oliverio, Elisabetta Rinaldi IBM Italy
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll have the opportunity to team with IBM technical professionals, Business Partners, and Clients. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html
xxxviii
Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at: ibm.com/redbooks Send your comments in an email to: redbooks@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400
Preface
xxxix
xl
Part 1
Part
IBM Tivoli Provisioning Manager V5.1

In this section we will introduce IBM Tivoli Provisioning Manager V5.1.
Chapter 1.
Tivoli Provisioning Manager V5.1 overview

This chapter provides an overview of Tivoli Provisioning Manager V5.1, together with the new features in this release, and a summary of the changes between this version and the previous version, Tivoli Provisioning Manager V3.1. The following sections are covered in this chapter: Provisioning on page 4 Service Oriented Architecture (SOA) on page 4 Open Services Gateway Initiative (OSGi) on page 7 IBM Service Management Framework (SMF) on page 7 Tivoli Provisioning family of products on page 8 Tivoli Provisioning Manager V5.1 new features on page 12 IBM Tivoli Configuration Manager clients on page 19
1.1 Provisioning
Provisioning is the end-to-end capability to automatically deploy and dynamically optimize resources in response to business objectives in heterogeneous environments. Provisioning helps to respond to changing business conditions by enabling the ability to dynamically allocate resources to the processes that most need them, as driven by business policies. Provisioning of individual elements, such as identities, storage, servers, applications, operating systems and middleware, is a critical step to orchestrate the entire environment enabling it to respond to business needs on demand. Provisioning focuses on the self-configuring, dynamic allocation of individual elements of the IT infrastructure so that identities or storage or servers are provisioned as business needs dictate. These elements could be: a single software package a software stack, which consists of a group of software packages a server which conforms to a template, which is a defined set of software and hardware resources
1.2 Service Oriented Architecture (SOA)

A Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. SOA helps users build composite applications, which are applications that draw upon functionality from multiple sources within and beyond the enterprise to support horizontal business processes.
1.2.1 Why IBM SOA?

To help you achieve business flexibility through SOA, IBM has developed the IBM SOA Foundation an integrated, open-standard-based set of software, best practices and patterns that is designed to provide what you need to get started with your SOA. IBM SOA Foundation is not a replacement for your existing infrastructure or investments. Instead, IBM SOA Foundation is designed to help you extend the value of the applications and business processes that are running your business today. You can select components on a build-as-you-go basis as you need to address new requirements. And you can readily enhance IBM SOA Foundation with capabilities from the broader IBM software portfolio. The components that
comprise IBM SOA Foundation have been carefully selected to support each stage of the SOA life cycle. As illustrated in Figure 1-1 on page 5, the IBM SOA Foundation is more than just software. It offers SOA best practices through SOA-related guides, white papers and other resources based on extensive customer experience. And a variety of role-based education, including both in-person and Web-based distance learning, are available to help you develop skills that can help you build your SOA.
Figure 1-1 The IBM SOA reference architecture
1.2.2 The SOA lifecycle

As shown in Figure 1-2 below, the SOA life cycle includes four stages: model, assemble, deploy and manage. Underpinning all of these life-cycle stages are governance and processes that provide guidance and oversight for the SOA project.
Chapter 1. Tivoli Provisioning Manager V5.1 overview
Figure 1-2 Service Oriented Architecture (SOA) lifecycle
Model
You begin the model stage by gathering and analyzing business requirements that you then use to model, simulate and optimize your business processes. You can use this information to establish a common understanding between business and IT of your business processes, objectives and outcomes, as well as to help ensure that the resulting application meets your defined business requirements.
Assemble
During the assemble stage, you create services out of new and existing assets. After the required services are available, they are orchestrated to implement the business process. The SOA life cycle includes four stages: model, assemble, deploy and manage. Underpinning all of these life-cycle stages are governance and processes that provide guidance and oversight for the SOA project.
Deploy
During the deploy stage, you configure and scale the run-time environment to meet the service levels required by your business processes. Then you can deploy the process into a robust, scalable, highly secure services environment that is optimized to reliably run mission-critical business processes while providing the flexibility to make updates dynamically in response to changing business requirements.
Manage
The manage stage involves establishing and maintaining service availability and response times, as well as managing underlying services assets. You can
monitor key performance indicators (KPIs) in real time to get the information you need to prevent, isolate, diagnose and fix problems. This stage ultimately enables you to make better business decisions sooner than previously possible.
Governance and processes

Governance and processes are critical to the success of any SOA project. To help ensure success, you can create a center of excellence within your business to implement governance policies and to follow proven international governance standards of control objectives for information and related technology.
1.3 Open Services Gateway Initiative (OSGi)

OSGi specifications define "a standardized, component-oriented, computing environment for networked services." Using the OSGi Service Platform enables life cycle management of applications from anywhere in the network. Because of the network-centric environment, life cycle events, such as install, update, uninstall, and control, happen on the fly, without the need to interrupt device operation. This is especially critical when using OSGi components in embedded systems like oil pipelines or cars. For detailed information about OSGi, see http://www.osgi.org/ The OSGi platform is a component software standard for networked computers and devices. Software components are increasingly important in a range of networked devices: digital mobile phones, vehicles, embedded appliances, residential gateways, industrial computers, desktop PCs, and even high-end servers. The component approach is particularly vital because software components can be installed, assembled, updated, combined with other functions or removed on demand -- without disrupting the operation of a device. In other words, software changes dont need to shut down the device or reboot it.
1.4 IBM Service Management Framework (SMF)

IBM Service Management Framework (hereafter called SMF) is an IBM implementation of the OSGi Service Platform specification. IBM SMF provides for the network delivery and management of applications and services independent of operating system and instruction set architecture. SMF provides the ability to install, start, stop, update, and uninstall applications without affecting other applications executing within the framework. The framework supports fully-connected, intermittently-connected, and disconnected usage, and its main highlights are:
IBM Service Management Framework, an implementation of the OSGi Service Platform specification, provides for the network delivery and management of applications and services independent of operating system and instruction set architecture (ISA). An integral part of the IBM WebSphere Everyplace embedded software platform, it provides a comprehensive, scalable solution that can enable the deployment, maintenance, and removal of applications and runtime elements across millions of devices. An open software platform designed to meet the needs of device manufacturers, service providers, developers, and gateway operators in supporting the emerging new generations of smart devices. Designed to execute properly under all OSGi-defined execution environments; conforms to the specifications of the OSGi Alliance: Designed to be fully compliant with the OSGi Service Platform Release 3.0 specification (certification pending), includes the entire 3.0 framework. Certified to be fully compliant with OSGi Service Platform Release 3. Provides the ability to install, start, stop, update, and uninstall applications without affecting other applications executing within the framework. Supports fully-connected, intermittently-connected, and disconnected usage. Optimized for embedded use to enable deployment on resource-constrained devices.
1.5 Tivoli Provisioning family of products

Customers have a need to collect, store and maintain hardware, software and asset information; distribute software applications and patches; and ensure their systems are in compliance. There are several products that are available which will help customers address these challenges:
1.5.1 IBM Tivoli Provisioning Manager for Software Version 5.1

This product provides discovery, inventory, Microsoft Active Directory integration, desired state management, software distribution and multi-platform patch management, and allows co-existence with existing Tivoli Framework based customers. Tivoli Provisioning Manager V5.1 is a Service Oriented Architecture provides the flexibility to treat elements of business processes and the underlying IT infrastructure as secure, standardized components (services) that can be reused and combined to address changing business priorities.
Refer to Part 2, IBM Tivoli Provisioning Manager for Software V5.1 on page 583 for a detailed discussion of Tivoli Provisioning Manager for Software Version 5.1. Note: Tivoli Provisioning Manager for Software Version 5.1, based on IBM's SOA architecture, allows customers to enjoy the benefits of discovery, inventory, software distribution, compliance, and configuration management with less infrastructure than was previously needed with the Tivoli Framework.
1.5.2 IBM Tivoli Provisioning Manager Version 5.1

Tivoli Provisioning Manager Version 5.1 is targeted at large enterprise customers and is meant for both clients and servers. In addition to fulfilling requirements for network, storage, virtual server, composite application and operating system provisioning, Tivoli Provisioning Manager V5.1 will also provide all of the features provided with Tivoli Provisioning Manager V5.1. Significant improvements over the previous offerings will include a topology installer, a consistent and vastly improved user interface, and a web-based reporting tool with pre-defined reports.Tivoli Provisioning Manager V5.1 is the natural upgrade path for Tivoli Provisioning Manager 3.1, which was traditionally used for server provisioning in a data centre environment. Tivoli Provisioning Manager V5.1 provides all of the features of Tivoli Provisioning Manager for Software V5.1 (see the note below), and also the following features which will not be available in Tivoli Provisioning Manager V5.1 for Software: Composite Application Development Network Device provisioning Storage provisioning Virtual Server provisioning CPU provisioning Hardware (Blade Server) provisioning Important: The Tivoli Framework Management co-existence functionality, that is currently provided by Tivoli Provisioning Manager for Software Version 5.1, is not part of the Tivoli Provisioning Manager Version 5.1 general availability code. This functionality will be incorporated into the Tivoli Provisioning Manager Version 5.1 product in a future Fix Pack.
1.5.3 IBM Tivoli Provisioning Manager Express Version 4.1

This is a software distribution and inventory tool for Small-Medium Business (SMB) customers needing a solid solution for Windows clients and servers. Tivoli Provisioning Manager Express is not built upon the same SOA platform as Tivoli Provisioning Manager for Software V5.1 and Tivoli Provisioning Manager V5.1 and currently there is no migration path between those products. For more information on IBM Tivoli Provisioning Manager Express Version 4.1 you can refer to the redbook Deployment Guide Series: IBM Tivoli Provisioning Manager Express V4.1 for Software Distribution, SG24-7236.
1.5.4 IBM Tivoli Provisioning Manager OEM Edition

Also called Embedded IBM Tivoli Provisioning Manager, this the Deployment Engine functionality, without any of the GUI, and it ships with no GUI. It is currently used in the Tivoli Provisioning Manager Installer as the backend to run workflows and to perform the install. This is a subset of Tivoli Provisioning Manager V5.1 and can be used as an automation engine to install and patch business applications, and can be embedded into other products. This is ideal for deploying and driving automation by interfacing with Deployment Engine from the CLI, and be regarded as "The Gateway to Business Process Automation" based on SOA standards.
1.5.5 IBM Tivoli Provisoning Manager for OS deployment Version 5.1

Based on the Rembo technology, Tivoli Provisioning Manager for OS Deployment is a database-driven PXE-based deployment solution for Windows, Linux, and Solaris. Through a single user-friendly interface, Tivoli Provisioning Manager for OS Deployment provides Windows cloning, Windows unattended setup, Linux cloning, and Linux unattended setup, from a Windows or UNIX (Linux, Solaris, etc.) server. The deployment source can reside on the network with either unicast or multicast downloading, on a CD-ROM or DVD-ROM, or on a disk partition. Table 1-1 on page 11 shows a comparison of the several products in the Tivoli Provisioning Manager family.
10
Table 1-1 Comparison of products within the Tivoli Provisioning Manager (TPM) family Functionality Tivoli Provisioning Manager Express 4.1 Yes Yes Yes Yes Yes Yes Yes Yes No No No No No No No No No No No No Tivoli Provisioning Manager for Software 5.1 Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes No No No Tivoli Provisioning Manager 5.1 Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes Yes
Distribution of software to client machines Support for Microsoft Windows Non-SUS (Non-Automated) Patch Management Push and Pull distribution methods Distribute InstallShield packages Distribute files and .zips Hardware and Software Inventory Out-of-the-box reporting Multi-Platform Support (Windows, Unix, and Linux) Upgradeable to ITSMa and other offerings Package building/editing Bare metal OS & Personality Transfer Automated (WSUS-Server) patch management Compliance management Desired State management Dependent on other TME Products More than 5,000 endpoints Server, OS, Middleware App Provisioning Network and storage provisioning Need to virtualize and ultimately make devices available On-Demand
11
a. IBM Tivoli Service Management
1.6 Tivoli Provisioning Manager V5.1 new features

This section describes new features and enhancements to existing functionality in Tivoli Provisioning Manager V5.1 Enhancements have been made in the following areas: Discovery and inventory management Compliance management Groups Notifications Software distribution infrastructure Patch management Image management Reports Security User experience Web Services The changes in each of these areas are now summarized:
1.6.1 Discovery and inventory management

New discovery features in version Tivoli Provisioning Manager V5.1 allow you to immediately populate the data model with hardware and software information and the relationships between the components. Improved discovery capabilities include the following new or improved discovery methods:
Tivoli Provisioning Manager network discovery: Allows you to discover your

IT infrastructure over SSH, SMB, or SNMP protocols to find computers and network devices. This integrated discovery capability is provided with the product and easy to configure and use.
Microsoft Active Directory discovery: Allows you to discover computers by

organizational unit, computer attributes defined in Microsoft Active Directory and Microsoft Active Directory groups.
Tivoli Provisioning Manager Inventory discovery: Allows you to discover computer hardware, including printers, modems, mice, keyboards, monitors, BIOS, and LPARs. Inventory scans can also be run using the new group
12
feature, and over the new distribution infrastructure for large scale implementations. This discovery method allows you to scan computer groups using software signatures and the new software signature management user interface.
The discovery library reader that allows information from the DCM to be used
by the IBM Tivoli Configuration and Change Management Database. It is also used to import data to DCM from the IBM Tivoli Configuration and Change Management Database.
1.6.2 Compliance management

Recent data security compromises in government and business highlight the need to audit clients and servers on a continuous basis. More than ever, executives have to be assured that their procedures address desktop data security. They need to know that both their client and server environments are compliant. Compliance asks the question Is the device implementing our defined corporate policy? The new compliance management functionality in Tivoli Provisioning Manager V5.1 allow you to create compliance checks, which define your corporate security and software standards, and then compare the software and security set up on the clients and servers in your data center against those standards. If computers are not compliant, Tivoli Provisioning Manager provides recommendations on how to fix the noncompliance issues (remediation), which you can apply at your discretion. Remediation answers the question, What action should I take to remediate (correct) the compliance issue with the device? For more information on compliance management in Tivoli Provisioning Manager V5.1 refer to Chapter 7, Compliance management on page 345.
1.6.3 Groups
New to Tivoli Provisioning Manager V5.1 is the ability to organize devices and software using groups. You can create groups based on categories that make sense in your organization. Using a group is a convenient way to perform such operations as operating systems install, software distribution and running script and workflow tasks. You can select group members manually or dynamically using report queries. Groups selected manually are static; members are added or removed manually. Groups defined by reports queries change dynamically to include members matching the conditions of the report upon which they are based.
13
1.6.4 Notifications
Users often need an audible or visible indication that their task or workflow has started, finished, or has encountered an error. Such notifications allow the user to continue working on other tasks, rather than monitoring the progress of a software distribution or installation process. You can now configure Tivoli Provisioning Manager to send e-mail notifications to users, updating them on the status of a specific task or workflow. Notifications are available for the following features: Reports Software management activities such as publishing, distributing, and installing Discovery activities Compliance For more information on notification in Tivoli Provisioning Manager V5.1 refer to Chapter 10, Reporting and notification on page 497.
1.6.5 Software distribution infrastructure

Tivoli Provisioning Manager V5.1 includes a new scalable software distribution infrastructure. The new distribution infrastructure offers a flexible "manage to" infrastructure which supports a number of Tivoli Provisioning Manager services and enables the management of various endpoints, in a variety of topologies. The Tivoli Provisioning Manager V5.1 software distribution infrastructure includes the following main components: Tivoli Provisioning Manager V5.1 exploits the Tivoli Common Agent Services for software distribution and compliance. Tivoli Common Agent Services provides an infrastructure for managing the computer systems in your environment. The deployed agent software collects data from and performs operations on managed resources on behalf of a Tivoli management application. Tivoli Provisioning Manager V5.1 also supports managed environments where the Tivoli Common Agent Services are not available. The Tivoli Provisioning Manager dynamic content delivery service enables the efficient distribution of files and bulk content to large numbers of targets using distributed depot servers and peer to peer services.. Clients installed as subagents on all the managed systems or endpoints at the regional branch request to download files from depot servers or from other clients. A device manager federator is installed on the provisioning server at the enterprise and is configured to act as a federated server. The federator
14
implements a job distribution policy that pushes incoming jobs to all of the regional branch office agents. Currently, a two-tiered federated environment is supported. Clients are installed as device manager subagents on the endpoints at the branch and are used for receiving job tasks from and returning results to the agents. For more information on software management in Tivoli Provisioning Manager V5.1 refer to Chapter 5, Software management in Tivoli Provisioning Manager V5.1 on page 235.
1.6.6 Patch management

Patch management is used to deploy missing software patches to target computers or groups of computers that require them. It provides a quick way to check the software installation status of multiple target computers without having to examine them all manually. New with Tivoli Provisioning Manager V5.1 is the ability to manage patches using the scalable software distribution infrastructure. The distribution infrastructure enables the management of a large number of target computers in a variety of topologies, and provides a fast and reliable way to distribute and install patches on target computers or groups of computers that require them. You can perform patch management on Microsoft Windows, Red Hat Linux, AIX and Solaris operating systems. For more information on patch management in Tivoli Provisioning Manager V5.1 refer to Chapter 8, Patch management on page 409.
1.6.7 Image management

Tivoli Provisioning Manager V5.1 is designed to provide a flexible environment to manage and install operating system software. One of the most important functions of this feature is that it allows managing the most common requests related to a workstation life cycle, without requiring any on-site visit, thus reducing the total cost of ownership of each managed system. The operating system is installed by using images created using the boot server. An image is a representation of a computer program and its related data such as the kernel, file systems, libraries, and programs of the managed system at a given point in time. Tivoli Provisioning Manager provides the capability to discover, manage, and deploy images for new image installations and backup and recovery.
15
Using Tivoli Provisioning Manager, you can perform the following main tasks: Capture an image from a source system Deploy an image to one or more target systems Restore a snapshot image to recover a target system Tivoli Provisioning Manager V5.1 now includes Rembo - an IBM technology. The Rembo Boot Server is provided with Tivoli Provisioning Manager, allowing you to provision operating systems. When you use image management in Tivoli Provisioning Manager, target computers or workstations connect to the Rembo Boot Server during the boot phase and begin the installation of the operating system across the network. For more information on image management in Tivoli Provisioning Manager V5.1 refer to Chapter 9, Image management on page 455.
1.6.8 Reports
Reporting allows you to visualize the state of your enterprise and quickly summarize results for executive and operational decisions. New reporting features include: Additional predefined reports, reflecting new features in Tivoli Provisioning Manager. A new Web-based query builder, which allows you to easily customize existing reports or create new reports. Easier access to information in the data model through more than 40 high-performance views. Easier sharing of report definitions through enhanced import and export capabilities in the Web interface. Charts and graphs. The ability to schedule reports to run at a later time including repeating intervals. E-mail report distribution and notification. Integration with third-party reporting software. For more information on reporting in Tivoli Provisioning Manager V5.1 refer to Chapter 10, Reporting and notification on page 497.
1.6.9 Security
Security enhancements in Tivoli Provisioning Manager V5.1include:
16
Overall, this version has fewer and clearer permissions, making it easier for you to customize user roles and permissions. Version 3.1 included over 20 default user roles. Tivoli Provisioning Manager version 5.1 collapses the 20 different user roles from previous versions into the following nine roles: System Administrator: Access to everything Inventory Specialist: Manages all aspects of the inventory Network Administrator: Access to all network inventory Storage Administrator: Manages all aspects of storage Software Operator: Manages all aspects of software and deployment Change Approver: Approves compliance recommendations such as installing missing software Automation Package Developer: Develops automation packages and workflows Software Package Creator: Access to the Software Package Editor Service Subscriber - Manages services and subscriptions Easier access group management: An access group is a logical organization of data center model objects, devices, and software over which a user is granted access. New cascade rules set the inheritance of permissions for parent and child objects. You can also assign and clone instance access permissions from the user page in the Web interface. A user's access permissions can also be viewed and removed from the user page in the Web interface.
1.6.10 User experience

Tivoli Provisioning Manager V5.1 introduces a new user interface which has been redesigned to enhance the user's experience with Tivoli Provisioning Manager. Improvements have been made in the following areas: The user interface has been visually redesigned, greatly improving the usability of Tivoli Provisioning Manager. A consistent color scheme and style, simplified tool bars, and meaningful icons all help the user to complete tasks quickly and easily. Users can also collapse the navigation tree, allowing them to focus on the tasks they use most frequently. The new Welcome experience provides an introduction to Tivoli Provisioning Manager V5.1 through product tours and tutorials. The Welcome experience contains the following types of information. Product tour: Provides a short conceptual overview of the key functional components of Tivoli Provisioning Manager and how they work together.
17
Tutorials: Demonstrates how to do a particular task. User can watch a short "movie" of key tasks. Information center: Launches the product information center to access full product documentation. Web resources: Links various related online information, including software support, automation resources, training and certification, and Tivoli resources. Tivoli Provisioning Manager V5.1 introduces task and role-based views of the user interface, allowing users to see only authorized tasks and objects. The navigation pane, notebook tabs, and menu actions all display appropriately according to the user's role and permissions. For example, a user assigned the system administrator role will see all available tasks in Tivoli Provisioning Manager V5.1, while a user assigned the software operator role will see only tasks related to software management pages. The Web interface home page can be customized, allowing you to set your home page to your most commonly used task page. Tivoli Provisioning Manager V5.1 also has context-sensitive help for every page in the Web interface, helping users find information quickly and easily. The context-sensitive help provides page and field-level information and links directly to the appropriate task in the Tivoli Provisioning Manager information center.
1.6.11 Web Services

Tivoli Provisioning Manager V5.1 includes an enhanced Web Services component. Using the Web Services Resource Framework (WSRF) you can access, manipulate, or change objects directly in the data model. Web Services, including the Web Services Resource Framework (WSRF) services, allow you to access the Tivoli Provisioning Manager V5.1 data model objects remotely using Web Services APIs rather than launching the Web interface. For more information on the Web Services interface in Tivoli Provisioning Manager V5.1, refer to Chapter 1, Tivoli Provisioning Manager V5.1 overview on page 3.
18
1.7 IBM Tivoli Configuration Manager clients

For existing Tivoli Configuration Manager clients, Tivoli Provisioning Manager V5.1 provides an opportunity to further enhance their software deployment and provisioning solution. Tivoli Configuration Manager provides for a package-driven software installation to clients and servers across a network. Over many years, it has developed some key capabilities that provide significant value to its customers. It has been tested for distributing software to servers in a data center environment connected by high-speed networks and in a distributed client-server environment with slow and sometimes unreliable communication lines connecting thousands of remote sites. The objectives of this release of Tivoli Provisioning Manager V5.1 are: Demonstrate the strategic direction for configuration management. Provide a migration path from Tivoli Management Framework to the new Service Oriented Architecture (SOA) based Operations, Administration, Maintenance and Provisioning (OAMP) infrastructure. Provide new capabilities, including those suggested by current Tivoli Configuration Manager customers Scalable, flexible deployment infrastructure through Content Delivery Services (CDS) Improved Microsoft Active Directory (MSAD) integration Additional Software and Patch automation Enhanced OS Management Software Compliance Management Asset Handling Improvements Software Packages and Software Package Blocks Activity Plans Custom organization of managed resources (Policy Regions, Profile Managers) TMF Command Line Interface (can still be used on the existing environment)
Ease of Use Improvements Utilities (Software Package Editor, Activity Plans Editor) TMF Administrative User Interface
19
In an effort to reduce total cost of ownership, and to continue to evolve product and technology, a strategy should be put into place for an upgrade to Tivoli Provisioning Manager V5.1, which will provide focus on out of the box time to value, usability, simplicity and consumability value proposition. The emphasis should be on the complete provisioning solution which provides integration in a IBM Tivoli Change and Configuration Management Database (CCMDB) and IT Service Management solution, and at the same time having broad capabilities with heterogeneous coverage, managing the entire computer lifecycle This should all be underpinned with a preservation of the existing customer investment in their Tivoli Management Framework infrastructure. This can indeed be done, by reusing core Tivoli Configuration Manager assets for continued use in Tivoli Provisioning Manager V5.1 There is no rip and replace approach, and the initial period of co-existence and integration can be leveraged to provide a staged upgrade at a desired pace. For more information on the how you can migrate your Tivoli Configuration Manager environment to Tivoli Provisioning Manager V5.1, refer to Chapter 14, Tivoli Configuration Manager migration case studies on page 683.
1.7.1 Benefits of migrating to Tivoli Provisioning Manager V5.1

Tivoli Provisioning Manager V5.1 provides the following functional functional boost: Improved and consolidated style and look: One common interface Welcome documentation with product tour and tutorials New widgets such as advanced tables and date/time picker Role based views Clear separation of operations and configuration activities End-to-end provisioning scenario support New task based help Web based reporting: Predefined reports Audit, inventory, compliance, deployment, discovery HTML, PDF and Excel output Scheduled reports and email distribution
20
Customized report creation External views for 3rd party reporting integration Extensive discovery options: Out-of-the box network discovery Computers and network devices Computers and groups Upgraded to Common Inventory Technology 2.2 Enhanced software signature support Read/write to CCMDB Discovery library readers for Tivoli Application Dependency Discovery Manager (TADDM), Relicore, Cendura, nLayers Microsoft Active Directory discovery Advanced software and hardware discovery
Discovery Library enabled
Extensive support for Boot Servers: Integrated IBM boot server (IBM Rembo) Advanced image management for Windows and Linux Additional support with: Windows IBM Remote Deployment Manager Linux Kickstart, IBM Cluster System Manager, IBM Remote Deployment Manager AIX IBM Network Installation Manager (NIM) Solaris - Jumpstart
Enhanced Operating System management: Automation of boot server installation Capture/restore image complete, delta image, personality transfer (Windows) Replication of images between boot servers Image discovery from boot server Task-based user interface for common operators Software distribution and installation: Task-based distribution and installation operator UIs
21
Exploitation of TMF and Service Oriented Architecture (SOA) based distribution infrastructure SOA advantages (common agent service-CAS, content distribution service-CDS and job management services-DMS): Web based management interfaces Scalable 2-tier implementation Branch office and roaming support Peer-to-peer distribution and bandwidth throttling Integrated compliance management Detection with remediation Software and patch levels (Required, prohibited, one of a set)
Software security & configuration:
Configuration compliance - patches: Accurate patch recommendations for each system based on vendor scan technology Desired patch state maintained automatically based on approved patches Automated acquisition from vendor or local repositories One step remediation to achieve patch compliance for a computer or group of computers Scalable distribution through TMF or new distribution infrastructure Windows, Linux Red Hat, AIX and Solaris support Configuration compliance - security: Integrated collectors Set compliance policies for computers or groups Detect non-compliant computers and remediate Missing or disallowed software or services Password settings Missing or misconfigured antivirus Missing or misconfigured firewall Agent health
Task automation and notification: Out-of-the-box task wizards for common operations Discover, publish, distribute, install, capture image and more
22
Custom automation tasks and activity plans Consolidated task tracking user interface Drill down on distribution status, target status with visualization On task completion or error Notifications callable from workflows, e-mail notifications Notifications
User interface consolidation

As the Tivoli Configuration Manager product has evolved and matured, the number of User Interfaces for various features of the product has also increased. Migrating to Tivoli Provisioning Manager V5.1 will provide a consolidation of user interfaces into a single point of control, hence preserving skills and minimizing the need to re-train operations and administration staff in using difference interfaces. TheTivoli Configuration Manager interfaces functional area are mapped to Tivoli Provisioning Manager V5.1 features, as shown in Table 1-2 below.
Table 1-2 TCM 4.2.3 and TPM 5.1 user interface mapping Tivoli Configuration Manager V4.2.3 User Interface Software Package Editor Activity Plan Editor Change Manager Activity Plan Monitor Distribution Status Console Query Facility Action Consolidated Tivoli Provisioning Manager V5.1 User Interface Feature Eclipse Plug-in & standalone Web Applet Compliance Management Task Monitoring Task Monitoring Group Management & Reporting
Keep Keep Replace Replace Replace Replace
In summary, the key benefits of Tivoli Provisioning Manager V5.1 are: Improved time to value Significant usability improvements Expanded integration Path forward for all current TCM customers
23
1.7.2 Tivoli Provisioning Manager V5.1 concepts

This product introduces a number of new concepts and terms, which are explained here. Workflow A series of steps that are sequentially executed to accomplish a particular task. A step in a workflow is called a transition. Each workflow has a single compensating workflow that is executed if any transition fails.
Automation package Also referred to as TC driver, device driver, or simply driver, an automation package is a collection (or a container) of commands, shell scripts, workflows, logical operations, and Java plug-ins that applies to the operation of one specific type of software component or a physical device. It contains a grouping of tasks that corresponds to a physical or logical device. These tasks typically implement logical operations. A device could be a specific piece of hardware, an operating system, a service, or a cluster. Logical operation A task that is abstracted from its implementation. Logical operations are implemented via Enterprise Java Beans (EJB). They provide a common interface and can perform logic. An example is a data center task of adding an IP address. It is a logical operation in that it makes no assumptions about the implementation. (Note that adding an IP address to Linux is very different from adding an IP address to Windows.) A step in a workflow. This could be another workflow, a logical operation, a simple command, or a Java plug-in. A representation of all of the physical and logical assets under Tivoli Provisioning Manager management. A customer owns applications. Customers can be unique corporations or departments within a single corporation. A grouping of one or more clusters. Service level priority (Silver, Gold, Platinum) is assigned at this level. A grouping or container for like resources or servers that support an application. Automated resource allocation and deallocation occurs at the cluster level. A container of available (deallocated) servers that support one or more application clusters. Also referred to as a spare pool.
Transition Data center model Customer Application Application tier
Resource pool
24
Servers
Data center model objects that represent physical servers. They belong to or are assigned to pools and clusters. Either an image stack or product stack that contains an ordered list of software products, software stacks, or both. The attributes and the methods for deploying a piece of software on an asset. A software product can be user-written or COTS (commercial off-the-shelf). Identifies attributes of a piece of software that can be used for prerequisite and co-requisite validation. Defines dependencies on software or hardware. Requirements can be used to define different types of relationships, such as requirements that identify an installation mechanism, requirements to run the software, hosting requirements.
Software stack Software product
Capability Requirement
Service Access Point (SAP) A definition of the protocol and credentials used by or associated with an asset. The configuration data for a service access point includes the application protocol, network protocol, and the end point details (IP address, port...). An asset can have more than one SAP. Software Configuration Template (Software Resource Template (SRT))A software configuration template identifies software resources and associated configuration details that you want to represent in the data center model after the software is installed on a system. Each software configuration template is used to create a software resource on the target system.
1.7.3 The data center model (DCM)

The data center model is a model of physical assets in a data center with a logical organizational structure to give context. The logical organizational structure answers questions such as, What customer is using this server? and Which applications can use this server when their needs increase? The data center model is an internal representation of the data center including hardware, software, logical entities and customers. In order to make intelligent decisions about reallocating resources, the current state is always modeled. When changes are made, the ramifications of those changes must be completely understood. A server may belong to one resource pool, be assigned to a given application tier, be a member of a particular VLAN (virtual lan), and so on. All of
25
these relationships need to be understood so that when the server is moved, it is returned to the correct pool, it is changed to the correct VLAN if necessary and so on. The data center model captures all of these relationships and maintains them appropriately when reallocating resources. The data center model is implemented as the relational database. When Software is installed on a computer, using the Tivoli Provisioning Manager V5.1 interface, the software will be installed on the physical machine, and also the DCM will be updated to update the logical model in the DCM. If management operations such as software installs, computer network re-configuration, etc. are performed not using the Tivoli Provisioning Manager V5.1 environment, then the logical model in the DCM will no longer be a correct representation of the real physical environment. Hence, as part of defined business processes, one must ensure that all management operations are performed using the Tivoli Provisioning Manager V5.1 solution.
Data center model objects

Physical elements in the data center are modeled as DCM objects which are generic representations of the physical elements. A Cisco 2600 and a Cisco 3548 would each be modeled as a Switch DCM object, an xSeries server and pSeries server would each be modeled as a Computer DCM object, and an installation binary for Apache on Windows or Apache on Linux would each be modeled as a SoftwareInstallable DCM object. Configuration information is also modeled in the DCM. An example of this is information used to connect to remote systems. This connection information is modeled as a ServiceAccessPoint DCM object.
Management operations
Typical management operations are generalized and grouped by the sort of device that would be the target of the operation. Operations like turn port on and turn port off are most often run against switches, so those operations are grouped and associated with a logical device called Switch. Operations like execute command and copy file are so generic that they are grouped and associated with a logical device called Device. Since all of the generic operations are associated with logical devices, they are called logical device operations
(LDOs).
DCM objects can behave like one or more logical devices. It is possible to associate any LDO with any DCM object (using the worklflows tab when navigating to the device), but not all of these associations would make sense and not all LDOs would function (some validate the DCM object type before running).
26
Workflows
Workflows are the instructions that the deployment engine executes when it is carrying out a management task. These instructions are expressed in a script-like language and can call logical device operations (LDOs) and other workflows. Parameters can be passed to workflows at run time and parameters can be looked up by the workflow when it is running allowing for modular and reusable workflows. Using LDOs, a workflow can be written at a high level to carry out a complicated management task, and the LDOs can call other workflows to interact with specific hardware and software.
Customer topology
A typical data center will be used to provide to provide one or more services to one or more customers. When servers are being utilized to provide a management service such as Web Hosting to Application Hosting, the customer topology can be used to model this. As shown in Figure 1-3, A Customer can be defined, each with one or more Applications. Each Application can have one or more Application Tiers. Each Application Tier will have one more servers assigned to it. Application Tiers may have a number of dedicated servers, or a number of servers which have been assigned from a Resource Pool.
Figure 1-3 Customer modelling in the DCM
Resource pools are used to share resources (Servers) between different application tiers, and are defined to increase the utilization rates of servers in a
27
data centre. Increased utilization rates are the result of sharing processors among multiple applications. In order to realize these performance improvements, one must share the servers. Resource pools are unallocated resources which can be given to an application cluster in response to increased demand. Likewise, when demand declines, servers are returned to the resource pool by the applications. (Resource pools are also called spare pools.) An example is shown in Figure 1-4.
Figure 1-4 Customer example in the DCM
1.7.4 Security model

The goal of security is to adequately protect business assets and resources in the data center model with a minimal amount of administrative effort. A number of concepts are important in the Tivoli Provisioning Manager V5.1 security model, and these are discussed in this section. First, you must define what resources should be protected. These could be any hardware or software resources. Then, you must decide what users and groups of users should have access to these protected resources. You also need to decide what type of access should be permitted to those resources. Finally, you must apply the proper access controls on these resources to ensure that only the assigned users can access them. Tivoli Provisioning Manager V5.1 has a number of security features that allow you to protect your data center, such as: Secure communication within the data center with certificate authentication.
28
Credential creation for assets in the data center. Access role configuration and rights (permissions) for users. Tivoli Provisioning Manager V5.1 uses access groups and customizable security roles to centralize and facilitate administration and security policies. Different jobs require different sets of access control. For example, a project manager may not need access to update server information while a system operator does. The administrator oversees the access controls that apply to an entire site and can manage the access groups that apply to software and hardware resources. Access control can be defined as security guidelines that: Allow or deny a user of a system access to the resources managed by a system. Specify what actions the user can perform on each resource.
Access groups
An access group is a logical organization of data center model objects, devices, and software over which a user is granted access. A data center model object can be defined into multiple access groups. Changing a group enables you to customize access permissions for all the users who belong to the group. You can nest access groups.
Permission groups
A permission group identifies a set of related resources (DCM objects) and specifies the access privilege that applies to individual objects. It authorizes a group of users to perform particular actions on a group of resources.
Access permissions
Access permissions represent the relationship between access groups and permission groups, and determine "who can do what command on which resources" in the data center model. Access permissions grant authorization to a user to perform particular actions on resources in a specific access group as specified by the permission group. Users can be assigned one or more access permissions, and when a user attempts to perform an action on a protected resource, the access permissions first determine what access groups the resource belongs to and then, it determines if the user is allowed to perform the requested action on the particular resource. There are permissions to view and change individual data center model objects and there are permissions to execute device operation on individual objects.
29
Security roles
In Tivoli Provisioning Manager V5.1, there are two types of security roles: Role Based Instance Level Determines who can see what objects in the Graphical User Interfaces. For workflow and logical device operations.
Role based security

These roles that are stored in LDAP, and only users with the correct set of roles can logon and view the pages in Graphical User Interface. There are nine pre-defined roles (A detailed definition of each role can be found in the Tivoli Provisioning Manager V5.1 Reference Manual, which can be downloaded at http://publib.boulder.ibm.com/infocenter/tivihelp/v13r1/index.jspl.) System Administrator Inventory Specialist Software Operator Change Approver Service Subscriber Storage Administrator Network Administrator Software Package Creator Automation Package Developer Based on business requirements, new roles can also be developed.
Instance level security

Instance level security allows instances of DCM objects to be protected. Only users with the right permission can execute the workflows and logical device operations. Access group contains the instances of objects to be protected. Permission groups contains permissions that are associated with the objects in the access group. Permissions can be assigned to users by assigning them to permission groups. workflows and logical device operations can be written to have instance level security enabled, which enforces the workflow on its input parameters. For more information on Tivoli Provisioning Manager V5.1 security implementation, you can refer to Chapter 11, User security on page 527.
30
Summary
In Tivoli Provisioning Manager V5.1 access controls enable administrators to manage your data center model and ensure that users only carry out those operations that are appropriate with their roles and responsibilities. The access controls in Tivoli Provisioning Manager V5.1 authenticate each user who attempts to log on, and permits access based on the information in the profile of the user. The user profile includes logon information, personal information, the security role and the access groups and permission groups to which the user belongs, and the password of the user. A user can be assigned to a security role and access permissions. The security role defines "who can see what in the data center model" and access permissions define "who can do what command on each data center model resource.
31
32
Chapter 2.
Product architecture planning and deployment best practices

This chapter provides a description of Tivoli Provisioning Manager V5.1 architecture and how components interact each other. It also explores different scenarios based on number of agents, hardware availability and network restrictions providing advice about the configuration to choose depending on the size of the environment to be managed. In particular we will discuss the following: Tivoli Provisioning Manager V5.1 components on page 34 Deployment scenarios on page 44 Systems management across firewalls on page 52 Scalability on page 58
33
2.1 Tivoli Provisioning Manager V5.1 components

Tivoli Provisioning Manager V5.1 consists of a server, a web-based console, and an Automation Package Development Environment. Figure 2-1 illustrates the main components of Tivoli Provisioning Manager, and shows how they interact with your managed IT infrastructure and with each other.
Figure 2-1 Tivoli Provisioning Manager components
34
Tivoli Provisioning Manager includes the following main components: Provisioning server The provisioning server is the server on which Tivoli Provisioning Manager is installed. The provisioning server contains the following sub-components: Provisioning database The provisioning database is the physical database for Tivoli Provisioning Manager. It holds the data center model. Data center model The data center model is a representation of all of the physical and logical assets that Tivoli Provisioning Manager manages, such as computers, switches, load balancers, application software, VLANs, and security policies. It keeps track of the data center hardware and associated allocations to applications, as well as changes to configuration. When a workflow successfully completes a requested change, the data center model is updated to reflect the current data center infrastructure. It also stores information about allocated and unallocated servers in resource pools for tier management. This information can include server identifiers, resource pool size, the number of active and idle servers, server priority, and similar information. Discovery and configuration management features also use the data model to identify configuration changes that are made outside of Tivoli Provisioning Manager. You can review changes and use the change information to restore a data center asset to a previously known state. Automation An automation package is a collection of workflows, scripts, and other commands and tools that apply to the operation of a specific type of software component or a physical device. The deployment engine manages the deployment of workflows and associated components in an automation package. Tivoli Provisioning Manager provides automation packages to automate the provisioning of software, patches, images and operating systems, and devices, including servers, network devices, and storage. Compliance and remediation Compliance management allows you to examine the software and security setup you have on a target computer (or group of computers) in your managed infrastructure and then compare that setup to your desired configuration in order to determine if they match. If they do not match, noncompliance occurs, and recommendations (remediation) on how to fix the noncompliance issues are generated.
Chapter 2. Product architecture planning and deployment best practices
35
Reporting Reports allow you to retrieve current information about data center inventory, activity, and system compliance. Tivoli Provisioning Manager reporting functionality includes: Several predefined reports. A Web-based query builder, which allows you to easily customize existing reports or create new reports. Easier access to information in the data model through more than 40 high-performance views. Easier sharing of report definitions through enhanced import and export capabilities in the Web interface. Charts and graphs. The ability to schedule reports to run at a later time including repeating intervals. E-mail report distribution and notification. Integration with third-party reporting software.
Discovery Discovery provides automated processes that allow you to find resources, as well as any changes to existing resources, within your managed IT infrastructure. Tivoli Provisioning Manager provides the following discovery technologies: Microsoft Active Directory discovery This discovers computers by organizational unit, Microsoft Active Directory groups, and computer attributes defined in Microsoft Active Directory. Tivoli Provisioning Manager network discovery This discovers computers, their host name and networking information, as well as new devices and modifications of existing Tivoli Provisioning Manager managed devices. Tivoli Provisioning Manager Inventory discovery This discovers configuration changes and discovery of hardware or software or both on devices. IBM Discovery library reader This discovers new devices, modifications and removals of existing Tivoli Provisioning Manager managed devices, and discovery of configuration changes and discovery of software on devices and relationships between resources.
36
Deployment infrastructure Tivoli Provisioning Manager supports reconfiguring and reallocation of resources in your managed environment using two different deployment infrastructures: a scalable software distribution infrastructure and a deployment engine infrastructure: Scalable software distribution infrastructure The scalable software distribution infrastructure is based on Service Oriented Architecture (SOA). It provides standard services for performing software distribution and compliance activities in a scalable two or three tiers implementation that can also include branch office management. A deeper description of the Scalable Distribution Infrastructure implementation for Tivoli Provisioning Manager is provided in section 2.1.1, Scalable Distribution Infrastructure (SDI) for provisioning on page 38. Deployment engine infrastructure The deployment engine infrastructure is responsible for automated provisioning. It creates, stores, and runs workflows and communicates their success or failure in performing an operation. Workflows can be triggered by commands from an administrator, by external tools that send SOAP commands to Tivoli Provisioning Manager, or by recommendations from the policy engine. Web Services interface Web Services, including Web Services Resource Framework (WSRF) services, allow you to access the Tivoli Provisioning Manager data center model directly rather than launching the Web interface. Using the Web Services you can access, manipulate, or change objects directly in the data center model. The command-line interface provides access to Tivoli Provisioning Manager features with SOAP. Administrators have the flexibility to perform tasks such as creating scripts that run specific SOAP commands or setting up external tools to send SOAP commands in response to an event. Operator and administrator console The Web-based operator and administrator console allows you to interact with the Tivoli Provisioning Manager provisioning server. The operator and administrator console provides a graphical representation of the data center, includes wizards to simplify configuration, and other features such as reporting and task status tracking that are not available from the command-line interface.
37
Automation Package Developer Environment The Automation Package Developer Environment (APDE) is an Eclipse-based plug-in environment that automation package developers can use to customize existing automation packages or create new automation packages. IBM Open Process Automation Library The IBM Open Process Automation Library (OPAL) is an IBM managed shared library of process automation. It is a comprehensive online catalog, which contains over 500 IBM Tivoli and Business Partners Product Extensions including: automation packages, integration adapters, agents, documentation, and supporting information. User directory Tivoli Provisioning Manager integrates with several directory servers, allowing you to manage your user accounts and user authentication using a directory server of your choice.
2.1.1 Scalable Distribution Infrastructure (SDI) for provisioning

TheScalable Distribution Infrastructure for Provisioning, also known as OAMPi (Operations, Administration, Maintenance and Provisioning Infrastructure) provides a scalable infrastructure for implementing software distribution activities inside Tivoli Provisioning Manager. It includes the following main components: Tivoli Common Agent Services It provides an infrastructure for managing the computer systems in your environment, enabling secure connections between managed systems and storing information about the managed systems and the software running on them. Dynamic Content Delivery Service It enables the efficient distribution of files and content to large numbers of targets through intermediate depot components and/or peer-to-peer distributions between agents. Device Management Service It provides a solution for managing various devices by performing jobs, which can be targeted to individual Tivoli Common Agent devices or to groups of devices.
38
Each of them can perform its management activity through specific subcomponents installed on the Tivoli Provisioning Manager server and on the managed systems. Figure 2-2 shows a general view of these subcomponents and their interactions.
Figure 2-2 Scalable Distribution Infrastructure components
Device Management Service Federator

It is installed on the provisioning server and is configured to act as a federated server. It implements a job distribution policy that pushes incoming jobs to remote agents. Jobs are actually submitted into the Device Management Service
39
Federator to be sent to device manager subagents (installed on targets as a part on the Tivoli Common Agent) via intermediate Federating Agent components. Results are returned in the reverse direction.
Device Management Service Federating Agent

It periodically polls the federator server for jobs (default interval is 10 minutes), and results are passed up at the same time. Although Figure 2-2 shows a remote DMS Federating Agent to give a complete picture of the way this architecture will evolve, currently only a single federating agent is implemented on the Tivoli Provisioning Manager server, while the remote federating agent will be supported in next releases. Federating agents are also referred to as federated agents.
Device manager subagent

The device manager client component is implemented as subagent of the Tivoli Common Agent and communicates with federating agents, polling for new jobs, with a default value of 60 minutes. Device manager subagents are not shown in Figure 2-2 to avoid making it unreadable. They are actually installed on the target systems as part of the Tivoli Common Agent.
Dynamic content delivery services management center

It is the central component of the dynamic content delivery services and provides overall control of the other dynamic content delivery service components. In particular, it maintains a list of the files stored on each depot server and replicates files between depots. It also authorizes clients to download files and creates download plans.
Depot
A depot server is a system that stores files in a designated directory ready for distribution to target systems. Depot servers can also replicate these files to other depot servers to optimize network traffic. There must be at least one Upload Depot, which is also referred as Preferred Upload Server, that replicates files to the other depots. Since it is installed as a Tivoli Common Agent subagent and since Tivoli Common Agent is not supported on Tivoli Provisioning Manager server, a Tivoli Provisioning Manager installation will always need at least two separated systems in the central management environment, one for Tivoli Provisioning server and the other for the preferred upload server.
Dynamic content delivery services subagent

Clients are installed as Tivoli Common Agent subagents on all the target managed systems. They can request to download files from depot servers or from other clients (peers). In this case, they work as miniature depot servers, which means they can hold copies of distributed files in a cache and act as
40
sources for these files during downloads by their neighbors. Dynamic content deliver services subagents are not shown in Figure 2-2 to avoid making it unreadable. Although this subagent downloads files from depot or peers, Figure 2-2 also shows a two-way connection between Tivoli Common Agent and Management Center. In fact, dynamic content deliver service subagent installed on Tivoli Common agent has to contact Management Center to request and receive download plans and notify it when download from depot or peers is done.
Common Agent Services Agent Manager

It is installed on provisioning server and provides functions that allow clients to get information about agents and resource managers. It also includes a registration service, which provides authentication and authorization services and maintains a registry of configuration information about the managed computer systems in your environment. The registration service handles security certificates, registration, tracking of common agents, resource managers, status collection and forwarding.
Tivoli common agent

Tivoli common agent (TCA), installed on depot servers and on targets systems, is a common container for all the subagents. It provides shared system resources and secure connectivity. Tivoli common agent subagents allow actually to use it as an agent for several Tivoli products. Tivoli Provisioning Manager uses Tivoli common agent version 1.3. A detailed description of how Tivoli common agent subagents interact with dynamic content delivery services and device management service components is provided in Chapter 5, Software management in Tivoli Provisioning Manager V5.1 on page 235. Further information about Tivoli Common Agent Services is provided in Chapter 6, Common Agent Services on page 307. In the following section of this chapter, we will focus on implementation of this scalable distribution infrastructure for Tivoli Provisioning Manager, which is one of the main improvements in version 5.1 and provides powerful scalability features.
41
Note: In order to take advantage of the SOA infrastructure available in Tivoli Provisioning Manager, after you discover a new system to be managed, you should create a SOA-SAP service access point for it. This actually configures Tivoli Provisioning Manager to use SOA infrastructure when performing activities like software deployment or hardware and software inventory on the discovered system. Further information about how to create a SOA-SAP service access point is provided in Chapter 4, Discovery mechanism on page 175.
2.1.2 Supported platforms

Table 2-1 shows the supported platforms for Tivoli Provisioning Manager V5.1 and Tivoli common agent V1.3. Since depot is implemented as a subagent, it is supported on the same platforms as Tivoli common agent .
Table 2-1 Supported platforms Operating Systems IBM AIX Tivoli Provisioning Manager server 5.1 5L v5.2 64 bit ML7 5L v5.3 64 bit Power5 ML1 9 on Sun SPARC Server 10 on Sun SPARC Server Tivoli Common Agent 1.3 5L v5.1 (32 and 64 bit) 5L v5.2 (32 and 64 bit) 5L v5.3 (32 and 64 bit) 8 (32 and 64 bit) 9 (32 and 64 bit) 10(32 and 64 bit) 11i (32 and 64 bit) Professional SP2 Server SP4 Advanced Server SP2 Professional SP1 Professional SP2 Standard Edition Standard x64 Edition Enterprise Edition Enterprise x64 Edition RHEL 3.0 32 bit RHEL 4.0 32 bit SLES 8.0 32 bit SLES 9.0 32 bit
Sun Solaris
HP-UX Windows 2000
Windows XP Windows Server 2003
Professional SP1(fast start only) Professional SP2 (fast start only) Standard Edition SP1 Enterprise Edition SP1
Linux Intel Family
RHEL 4.0 32 bit update 3 SLES 9.0 32 bit SP3
42
Operating Systems Linux AMD64/EM64T Linux i/p Series Family (64-bit)
Tivoli Provisioning Manager server 5.1 -
Tivoli Common Agent 1.3 REHL 4.0 64 bit SLES 9.0 64 bit RHEL 3.0 RHEL 4.0 SLES 8.0 SLES 9.0 SLES 8.0 31 bit SLES 9.0 64 bit
Linux zSeries
Important: Always review the latest documentation released with Tivoli Provisioning Manager V5.1 for an updated platform matrix.
2.1.3 Supported prerequisite software

Tivoli Provisioning Manager V5.1 technology is based on an application server, a relational database and a directory server for authentication. Table 2-2 shows the supported versions for these components in Tivoli Provisioning Manager GA.
Table 2-2 Supported prerequisite software Database AIX - DB2 UDB ESE 8.2 fp 11 Application Server - Websphere App. Server fp 2 + latest interim fix - Websphere App. Server fp 2 + latest interim fix - Websphere App. Server fp 2 + latest interim fix - Websphere App. Server fp 2 + latest interim fix Directory Server - Tivoli Directory Server 6.0 fp 1 - Tivoli Directory Server 6.0 fp 1 - Tivoli Directory Server 6.0 fp 1 - Tivoli Directory Server 6.0 fp 1 - Microsoft Active Directory
Linux
- DB2 UDB ESE 8.2 fp 11
Sun Solaris
- DB2 UDB ESE 8.2 fp 11 - Oracle Database 10 G - DB2 UDB ESE 8.2 fp 11
Windows
43
2.2 Deployment scenarios

Deployment scenarios attempt to provide realistic understanding of architecture design. These scenarios should be used mainly for guidance to assist in the planning and deployment strategy used for a production installation, since every deployment strategy is unique and only proper planning can guarantee a successful implementation. In this paragraph, we cover five scenarios: Demo installation Small data center Small branch office Large data center Large branch office The next paragraph adds information about the management of some of these scenarios when there are firewall restrictions limiting communications between Tivoli Provisioning Manager and systems to be managed. Tivoli Provisioning manager actually provides two different installation infrastructures: Fast Start installation It installs the Light Stack Tivoli Provisioning Manager. It has the same capabilities as the full installation, but is based on Lightweight Infrastructure (LWI) acting as the application server, an embedded database server (Cloudscape) and utilizes OS based authentication. It is only supported on Windows. Full Enterprise installation It installs the Enterprise Stack Tivoli Provisioning Manager, based on Websphere as application server, DB2 or Oracle as database server, and Tivoli Directory Server or Microsoft Active Directory for authentication. For more information about Fast Start and Full Enterprise installation, please refer to Chapter 3, Installing Tivoli Provisioning Manager V5.1 on page 61.
2.2.1 Demo installation

For demonstration purposes, the Fast Start version of Tivoli Provisioning Manager V5.1 server can be installed on a single machine running Windows XP. In order to perform software deployment tasks, you will need a second system to use as upload depot. To minimize the number of involved systems, this second
44
machine can act both as depot and as target. This should allow to demonstrate main SOA infrastructure capabilities using only two systems. While performing our tests, we were able to achieve acceptable performance using a single laptop with 2 GB or RAM and a Pentium 4 processor, hosting 2 virtual machines, working one as Tivoli Provisioning Manager (1 GB RAM reserved for it) and the other as depot and agent. In order to describe a complete scenario, you can also have Tivoli Provisioning Manager server on the physical machine, plus two virtual machines hosting depot and agent. Attention: The Light Stack Tivoli Provisioning Manager should only be used for Test and POC environments. It is not recommended to run production environments on it.
2.2.2 Small data center

A small data center scenario consist of a single LAN hosting a limited number of servers to be managed. The number of servers for which this scenario makes sense actually depends on several parameters. Although the dynamic content delivery service technology available in depot has been proven to be able to manage large number of systems, (see paragraph 2.4, Scalability on page 58 for further information) a single depot solution does not get advantage of some features of this technology, for instance, the capability to download different pieces of the same package simultaneously from different depots. Therefore, when the number of systems raises over some hundreds and the size of packages is about hundreds of Mb, it can make sense to move out of this scenario to a depot hierarchy infrastructure. Figure 2-3 shows the physical systems involved in this scenario.
45
Figure 2-3 Small data center
It implies installation of Tivoli Provisioning Manager and Upload Depot in the same LAN where systems to be managed are placed. Each target will download files from the upload depot. As mentioned in previous sections, it will also need to connect to Tivoli Provisioning Manager to perform the following activities: Polling Device Manager Service Federating Agent for new jobs Requesting and receiving download plans from dynamic content delivery service management center Notifying completion of download to dynamic content delivery service management center
46
2.2.3 Small branch office

A small branch office scenario is part of a probably more complex scenario where Tivoli Provisioning Manager has to manage a large infrastructure, with systems spread across a geographic network. It typically applies to a company, for instance a bank, managing desktops in several branches spread in different towns across a country or a wider area with slow connections between the management center and the remote offices. Depending of the specific characteristics of the company, you may have a standard branch office environment with dozens of desktops, or an heterogeneous configuration where some branches are larger than others and you have to manage from one Tivoli Provisioning Manager branch office hosting dozens of systems together with other branch offices hosting hundreds of them. This scenario will show how Tivoli Provisioning Manager can interact with a small branch office. Section 2.2.5, Large branch office on page 50 provides advice about managing large branch office environments. A small branch office scenario usually involves software deployment to a very limited number of systems (dozens of desktops instead of hundreds). In this configuration, it does not make sense to have a depot installed in the remote branch office, especially when you have to dedicate a system, most likely with a large disk space, to manage less then ten. A peer-to-peer configuration, like the one showed in Figure 2-4, allows use of one of the managed systems as a peer, so that it performs the first download from the depot and the other ones can download the files from it. Of course, the main advantage of this configuration is having a single machine performing the download of large files across a slow link. Further information about peering mechanism is available in Peer-to-peer file sharing on page 271. Figure 2-4 also points out the two-way connections between each target agent and Tivoli Provisioning Manager server. As already mentioned in previous sections, they are used for polling, receiving download plans and notifying completion of download. Although this involves open connections between each agent in the branch and Tivoli Provisioning Manager server in the central LAN (to
47
consider when there is a firewall between Tivoli Provisioning Manager and target systems), it is actually a very limited amount of data.
Figure 2-4 Small branch office
2.2.4 Large data center

A large data center environment involves managing a large number of servers spread across different networks, which are both local and remote. Figure 2-5 shows an example of how this configuration can be handled with Tivoli Provisioning Manager. The provided example suggests installation of Tivoli Provisioning Manager and depot in the central management LAN. Depending on the number of systems to be managed in this local network, you can take in consideration a direct connection between local servers and the upload depot, or a local depot hierarchy. Figure 2-6 only shows the case of direct connection between local systems to be managed and upload depot. Remote systems connected across
48
slow links can be managed, depending on the size of the remote environment and on the available hardware, using peers or remote depots. Various combinations of the configuration in the example in Figure 2-5 can be explored depending on the specific environment to be managed.
Figure 2-5 Large data center
For the sake of readability, Figure 2-5 does not show connections between Tivoli Provisioning Manager server and each target or remote depot.
49
Note: When a three-tier architecture is available also for Device Management Service, the remote servers hosting depot will also be able to be used as Device Management Service Federating Agent. This should avoid polling from each agent in the remote network to Device Management Service Federating Agent on Tivoli Provisioning Manager. Each agent will poll a local system that opens a single connection across the slow link to the Tivoli Provisioning Manager.
2.2.5 Large branch office

A large branch office scenario involves interaction with a remote branch hosting a large number of systems to be managed (hundreds of desktop instead of dozens). The scenario in section 2.2.3, Small branch office on page 47 has showed that, when managing few desktops, peering mechanism allows you to avoid depot installation in branches, assuring optimization of file transfer between upload depot and target systems. When managing large numbers of desktops for each branch, having a depot hierarchy with one or more depot per branch, allows you to optimize software
50
deployment performance. Figure 2-6 shows the physical systems required for this configuration.
Figure 2-6 Large Branch Office
A Tivoli Provisioning Manager server and an Upload Depot are installed in the central management environment. One or more depots are installed in each remote branch office, managing software downloads from the upload depot. Each target in the branch office will receive software from its branch depot or depots. In this case you must take into consideration connections between each managed system in the branch (depot included) and Tivoli Provisioning Manager server.
51
Note: When a three-tier architecture is also available for Device Management Service, the branch server hosting depot will also be able to be used as Device Management Service Federating Agent. This should avoid polling from each agent in the branch to Device Management Service Federating Agent on Tivoli Provisioning Manager. Each agent will poll a local system that opens a single connection across the slow link to the Tivoli Provisioning Manager. Note that agents will still have to connect central Management Center even with eDMS servers.
2.3 Systems management across firewalls

Managing desktops or servers across firewalls is a common problem while performing software deployment. Typical requirements for a solution to manage system across firewalls are: Port consolidation, that is opening as few ports as possible to minimize impact on firewall configuration. Firewall transversal solution, that implies capability to operate across multiple firewall zones in such a way to permit a more secure network security configuration that one in which each firewall has open all ports needed by the product. Note: The Tivoli Provisioning Manager V5.1 general availability version does not provide port consolidation and firewall transversal solution to cross multiple firewalls. It is expected that this functionality will be added in Tivoli Provisioning Manager V5.1 fixpack 1, which is currently scheduled to be available in Dec 2006. In the following sections, we will discuss two options that manage agents across firewalls. In particular, section 2.3.1, Ports used by Scalable Distribution Infrastructure components on page 53 considers the solution available in Tivoli Provisioning Managed GA version. When requirements about port consolidation are loose and there is only one firewall, configuration described in this section can be a simpler alternative to the transversal solution that will be provided in the near future. In section 2.3.2, Proxy relay collector for communication behind a firewall on page 55 we will describe the transversal solution that should be available in Tivoli
52
Provisioning Manager V5.1 fixpack 1 and Tivoli Provisioning Manager for Software 5.1.
2.3.1 Ports used by Scalable Distribution Infrastructure components

Table 2-3 shows the main ports used for communication between Scalable Distribution Infrastructure components.
Table 2-3 Ports used for communication between TPM SOA components Source system TPM server Depot TCA Depot Source Component CDS Management Center CDS depot server CDS subagent CDS depot server DMS subagent CDS subagent Agent Manager Nonstop process TCA TCA Source port Any Destination system Depot Destination component CDS depot server CDS depot server CDS depot server CDS Management Center DMS federated agent CDS Management Center TCA TCA Agent Manager Agent Manager Agent Manager Destination port 2100 Connection security Secure SSL
Any Any Any
Depot Depot TPM
2100 2100 9045 9046 9045 9046 9010 9015 9510 9514 9515 9511 9512
Secure SSL Secure SSL Secure SSL
TCA
Any
TPM
Secure SSL
TCA
Any
TPM
Secure SSL
TPM TCA TCA TCA
Any Any Any Any
TCA TCA TPM TPM
Secure SSL Unsecure Secure SSL Secure SSL with Client Authentication Unsecure
TCA
TCA
Any
TPM
9513
53
For each connection, Table 2-3 specifies the configuration that should be performed on a firewall between the involved components to allow them to communicate successfully. The Source system and Target system columns show the physical system involved. The Source component and Target component columns contain the name of the Scalable Distribution Infrastructure components involved. The Any value for source port means that connection uses an ephemeral port and therefore the firewall must be configured so that the source port can have any value. Figure 2-7 gives a graphical idea of the port used by each connection.
Figure 2-7 Port used by SOA components
54
The picture omits ports used in communication between Device Management Service Federator and Device Management Service Federating Agent, since the only supported configuration at the moment expects that they are both on Tivoli Provisioning Manager server. In a typical single firewall scenario, the firewall is between the central management environment and a separate network, either a remote office branch or a De-Militarized Zone. In these cases, the firewall is between Tivoli Provisioning Manager server and the upload server on the secure side, and the depot and Tivoli Common Agent is on the unsecure side. Firewall configuration for successful connection in this case is depicted in Table 2-4.
Table 2-4 Ports to be opened in a single firewall scenario Source system TPM server Upload Depot TCA Source port Any Any Any Destination system Depot in unsecure zone Depot in unsecure zone TPM Server Destination port 2100 2100 9045 9046 9010 9511 9512 9513 9015 9510
TPM
Any
TCA
2.3.2 Proxy relay collector for communication behind a firewall

Tivoli Provisioning Manager for Software and Tivoli Provisioning Manager V5.1 fixpack 1 provides a built-in proxy relay collector for scenarios where servers (managers) are separated from destination clients (agents) by one or more intermediary networks because of firewall policies or address space concerns. The proxy relay is used to tunnel traffic between network zones. Proxy relays can be chained together to allow for multiple hops. The proxy relay enables the Tivoli Provisioning Manager server to successfully connect to and communicate with remote destination client systems across multiple network boundaries. Because the proxy relay can also be used to bypass a sites security, the proxy relay must possess a method to prevent abuse. The proxy relay enforces a security policy through the use of configurable Access Control Lists (ACLs). The proxy relay collector permits a client to act as an intermediary, or proxy, between the agent and a number of managers behind a firewall. The collector does not collect data in the usual sense, but does gather statistics on the clients using the proxy relay
55
and the amount of data being transferred. Figure 2-8 shows a high-level overview of the proxy relay function.
Figure 2-8 Tivoli Provisioning Manager for Software proxy relay
1. An agent connects to gateway service and sends a command to connect to registered manager A. 2. The gateway service sends a command to the gateway manager. 3. The gateway manager creates connection to the manager. 4. The gateway manager creates a connection to the gateway service through the proxy relay. 5. The gateway manager ties connections 3 and 4 to form a virtual connection from the manager to the gateway service.
56
6. The gateway service ties connections 4 and 6 to form a virtual connection from the manager to the agent.
Proxy relay
The proxy relay collector operates by opening default port 1960 on the proxy relay system, and then listening on it for routed traffic. When a connection is made to this port, the proxy relay expects control information to be sent, which instructs the relay to create a new TCP/IP connection to the specified address and port. Once the new connection is created, the two input and output stream connections are joined together using a thread that reads data from an input stream and writes data to another output stream. Each proxy relay is configured with an access control list (ACL) which determines which incoming and outgoing connections to allow.
Gateway manager and service

The gateway includes the gateway manager and the gateway service. The gateway is used to tunnel TCP/IP traffic from point 1 through the gateway service and gateway manager to the final destination 2 in Figure 2-9. Each gateway manager can connect to and manage one or more gateway services. In turn, each gateway service can be managed by one or more gateway managers. For gateway communications, all connections are created from the gateway manager to the gateway service.
Figure 2-9 Tivoli Provisioning Manager for Software proxy relay behavior
For example, endpoint 1 illustrated in Figure 2-9 must create a TCP/IP connection to resource 2. Because of unidirectional firewall rules, connections
57
can only originate from the network where resource 2 resides. Using the gateway, endpoint 1 creates a connection to the gateway service 3, which is allowed as they are in the same network. Gateway manager 4 creates a connection to resource 2, which resides in the same network. Next, the gateway manager 4 creates a new connection to gateway service 3. Then, using the input and output streams, the original connection from endpoint 1 to gateway service 3 acts as though it is connected directly to resource 2. When the gateway manager and gateway service are operating correctly, there is a persistent TCP/IP from the gateway manager to the gateway service. This command channel allows the gateway service to alert the gateway manager when it receives a new connection request. A periodic heartbeat signal is sent to keep the connection alive. If the command channel is closed, the gateway manager will attempt to reconnect periodically. The gateway service will automatically stop listening on that particular gateway managers service ports when the connection is broken. The gateway service can be configured to advertise a particular service. To utilize this feature, user datagram protocol (UDP) broadcasting must be enabled for the local subnet. An endpoint can discover a service by sending a broadcast UDP packet containing the services name. If the gateway service receives the UDP packet and it currently advertises that service name, then it will respond back with an addressed UDP packet, which contains the port number that service is listening on. The endpoint can then use the source address of the UDP packet and the port contained within the packet to connect to the given service.
2.4 Scalability
A distributed networking infrastructure inherits scalable characteristics by design. It should be stated that scalability is not the same as performance tuning. Performance tuning deals with increasing output from current capacity without adding additional resources. No single analysis of scalability and performance can determine the absolute hard limits of a distributed product. A distributed system in theory should extend to infinity. However, as distributed systems increase in scalability, performance loss may increase to an unsustainable boundary. Tivoli Provisioning Manager follows the basic scalable characteristic in this design. Adding hardware capacity in the form of remote depots (and remote Federating Agents, when the three-tier infrastructure for Device Management Service will be available) distributes the load and allows more connected agents. From a design point of view, Tivoli Provisioning Manager for Dynamic Content Delivery (providing the dynamic content delivery service component) has been embedded into Tivoli Provisioning Manager to provide a highly scalable and reliable infrastructure for software and patch distribution. Dynamic Content
58
Delivery Service component has been in fact proven to be able to manage large infrastructure with optimal performance. The following features of Dynamic Content Delivery Service component contribute efficiently to scalability and reliability of Tivoli Provisioning Manager V5.1: Dynamic Content Delivery Service can be configured to be peer-based or hierarchical. In most client-based scenarios, for example, retail, the customer does not need a server-per-branch for distributions. Customers can potentially save money on hardware as they do not need per-branch servers. Dynamic Content Delivery Service supports a dynamic environment with roaming endpoints. When you take your laptop to another location, the dynamic content delivery service sub-agent searches for the nearest local distribution points based on subnets and domains or user-defined regions. There is no single point of failure if the environment is properly configured. Even if network connectivity to the Tivoli Provisioning Manager server is lost, distributions in process can continue. Note: When link to Tivoli Provisioning Manager server is lost, distribution will complete, but TCA will be able to report the status after the connection is restored. Dynamic Content Delivery Service can handle large files. This may be important to customers in scenarios such as upgrading entire operating systems. It has adaptive bandwidth control that works. This reduces performance problems related to network overload. Dynamic Content Delivery Service supports checkpoint or restart in case of an interrupted distribution. In Tivoli Provisioning Manager V5.1, the dynamic content delivery service infrastructure can be configured to allow each endpoint to be downloading a file from up to four servers simultaneously. This speeds up the file transfer and makes the process faster and easier for the user. From a scalability standpoint, the Dynamic Content Delivery Service component plays therefore a key role. Device Management Service components also some configurable parameters that might impact the performance. For example, the polling mechanism for new jobs between agents and Tivoli Provisioning Manager has a random time interval that is added to the polling frequency. Therefore, job requests coming from the agent do not all arrive at the same time. In some way this mechanism allows the management of large software deployment and inventory scenarios. However,
59
you have to be careful when setting this polling time to avoid having too much load on Device Management Service federating agent. As the architect of an Tivoli Provisioning Manager implementation, consider the following factors: Number of physical systems and platform types to be managed Average size and frequency of packages to be distributed Geographical topology of the environment Network topology and firewall restrictions Estimated number of users and consoles Note: Extensive scalability tests are being performed for Tivoli Provisioning Manager V5.1 and results will be documented as a whitepaper. At the time of writing this redbook, the whitepaper (currently scheduled to be available in Dec 2006) was not complete.
60
Chapter 3.
Installing Tivoli Provisioning Manager V5.1

In this chapter we will discuss different installation scenarios for the Tivoli Provisioning Manager V5.1. This chapter has the following sections: Topology Installer Launcher on page 62 New installation options on page 62 Installation described in this chapter on page 63 Enterprise installation on AIX on page 65 Unattended installation on Linux on page 120 Enterprise installation on Windows on page 143
61
3.1 Topology Installer Launcher

Tivoli Provisioning Manager V5.1 introduces an important enhancement regarding the installation mechanism. It provides an unified installer that allows you to install Tivoli Provisioning Manager and the required prerequisite software on multiple computers in a distributed topology using a single Topology Installer Launcher (TIL). The TIL is a wizard that prompts you for all the information required for the installation. It can install and configure the following prerequisite software: DB2 Universal Database WebsSphere Application Server Tivoli Directory Server The following core components are also installed on the Tivoli Provisioning Manager server: Tivoli Provisioning Manager for Dynamic Content Delivery Tivoli Common Agent Services, such as Agent Manager Job Management Service (DMS Federator) The TIL can also configure an existing installation of Microsoft Active Directory in a Windows topology or Oracle Database in a Solaris topology. When you install software to multiple nodes, the TIL can perform installation on each node in parallel.
3.2 New installation options

These are the methods that you can use for installation: Tivoli Provisioning Manager Topology installer An installation with flexible options Install all components on a single node, or install the directory server on a separate node. Install components on the same computer as the installer, or install them on a remote computer. Choose the middleware that you want to use for Tivoli Provisioning Manager, including more powerful database, application server, and authentication server options. This type of installation is recommended for
62
environments with many users or a large amount of data for better performance and load balancing. Note: The above options can vary by operating systems. Refer to hardware and software requirements chapter for every operating system Installation Guide for more details. Silent installation Silent installation provides you with the ability to predefine your installation options and run an unattended installation. It is also useful for deploying the same installation to multiple environments. Fast Start A basic installation for a single server Windows environment without clustering, and without centralized administration of multiple server instances. A Fast Start installation uses a lightweight database, authentication server, and application server to support Tivoli Provisioning Manager. You can also install a demo server which is a single server installation that uses the internal database and user directory that come with Tivoli Provisioning Manager.
3.3 Installation described in this chapter

In this chapter we discuss the following installation scenarios: Enterprise installation on AIX on page 65 Unattended installation on Linux on page 120 Enterprise installation on Windows on page 143
3.3.1 Fast Start installation

The Fast Start installation is an easy way to install Tivoli Provisioning Manager V5.1, with minimum number of prompts. It is only supported on Windows Operating Systems and provides: fast installation, in about 30 minutes small footprint, about 1 GB of memory and 5 GB of diskspace required very simple to install.
Chapter 3. Installing Tivoli Provisioning Manager V5.1
63
The Fast Start installs the Light Stack Tivoli Provisioning Manager. It has the same capabilities as the enterprise installation, but is based on Lightweight Infrastructure (LWI) acting as the application server, an embedded database server (Cloudscape) and utilizes Operating System based authentication. The Light Stack Tivoli Provisioning Manager should only be used for test and proof of concepts (POC) environments. It is not recommended to run production environments on it. We will not cover Fast Start installation in this chapter, since it is very straightforward, but you can refer to Tivoli Provisioning Manager Version 5.1, Fast Start Installation Guide for Windows, SC32-2206 for more information on Fast Start installation.
3.3.2 Enterprise installation

The Enterprise installation is performed with the Topology Installer Launcher. TIL installs the Enterprise Stack locally or remotely, based on Embedded Tivoli Provisioning Manager (eTPM) and Automation Packages. It installs Tivoli Provisioning Manager and all the prerequisite middleware software from a single node to one or more target systems, based on the supported installation topology. When installing a multi node topology, the installation is run in parallel. Table 3-1 on page 64 shows the supported installation options:
Table 3-1 Tivoli Provisioning Manager Installation options Fast Start Installation Deployment Nodes Application Server Database 1 LWI 7.0 Cloudscape 10.1.2.5 Enterprise Installation 1 or 2 WAS 6.0.2 FP11 DB2 8.2 FP11, Oracle 10.2.0.1 g (Solaris only) ITDS 6.0 FP1, MSAD 2003 (Windows only)
Authentication/ Authorization
OS based
64
Fast Start Installation Operating System Windows XP, 2003
Enterprise Installation Windows 2003 Enterprise/Standard, Linux SLES9/RH4 IA32, AIX 5.2, 5.3, Solaris 9, 10 Agent Manager, CDS Management Server, DMS Server Eclipse 3.1.2, Cygwin V1.5.10 or higher (Windows only), Java 1.4.2 JRE
Agent Components
Agent Manager, CDS Management Server, DMS Server Eclipse 3.1.2, Cygwin 1.5.10 or higher (Windows only), Java 1.4.2 JRE
Runtime
3.4 Enterprise installation on AIX

In this chapter we discuss a single node installation on an AIX node. This installation is called Enterprise or Heavy, compared to Fast Start or Light installation allowed on Windows platforms. At the moment, the only supported topology with Tivoli Provisioning Manager V5.1 on AIX is the so called local single-node topology as described in Figure 3-1 on page 66. In a local single-node topology, all the software is installed on the same computer. Local means that also the TIL must reside on the machine that will host the Tivoli Provisioning Manager server and all its components.
65
Figure 3-1 Enterprise single-node topology on AIX
A new topology is supported by Tivoli Provisioning Manager for Software V5.1 and allows you to install the IBM Tivoli Directory Server on a separate machine, as shown in Figure 3-2 on page 67. Note:This is expected to be supported by Tivoli Provisioning Manager V5.1, as well in a future fix pack or release. In a two-node topology, the Directory server is installed on one computer, and the remaining prerequisite software and Tivoli Provisioning Manager are installed on another computer.
66
Figure 3-2 Enterprise two-node topology on AIX
3.4.1 Hardware and software requirements for the Topology Installer Launcher
With the Tivoli Provisioning Manager for Software V5.1 a remote installation is also supported. This allows you to run the TIL on a separate machine than the Tivoli Provisioning Manager server target machine. Table 3-2 on page 67 details the requirements for the Topology Installer Launcher:
Table 3-2 Hardware and software requirements for the Topology Installer Operating System AIX 5.2 AIX 5.3 Server type IBM pSeries Processor speed 1GHz CPU Minimum free disk space 7 GB in the /var file system 8 GB in the /tmp file system RAM Minimum 2 GB
67
Note: The above requirements assume that you are using a CD media to perform the installation. In this case the TIL will use the /tmp and /var directories to copy and uncompress the images before install them. If you are using a local file repository, you must grant the following minimum free disk space: 5 GB for /tmp file system 5 GB for /var file system There are some additional requirements for the Topology Installer Launcher: Ping localhost Verify that you can successfully run the command ping localhost on the computer. The file /etc/hosts must include the IP address 127.0.0.1 for localhost and the correct IP address and host name for the computer where you are running the installer. The following example shows settings for localhost and a computer with the host name tpm.example.com 10.0.0.12 tpm.example.com 127.0.0.1 localhost X Window System connections If you are running the installer on a UNIX or Linux computer, but you want to remotely run the installation using an X session from a Windows computer, verify that the X application supports display of the topology installer: The Cygwin X server does not support display of the installer. Exceed can be used for an X session, but it does not support display of double-byte characters. If you need to run the installer in a language with double-byte characters, you must perform the installation on a local computer. If the DISPLAY variable is exported to an Exceed X window server, to install Tivoli Provisioning Manager, the label and the progress bar of the first product being installed, disappears, when the installation is started. After the first product is installed, the progress bar is displayed again, but the label will not appear. Expect Expect 5.32 or later is required on the computer where you are running the installer. You can obtain the Expect package from the following link: http://www.ibm.com/servers/aix/products/aixos/linux/download.html The Expect files should be located in /usr/local/bin.
68
3.4.2 Hardware requirements for Tivoli Provisioning Manager server machine

For a successful installation, ensure that you meet the disk space and memory requirements for the computer where you are installing Tivoli Provisioning Manager as detailed in Table 3-3 on page 69.
Table 3-3 Hardware requirements for Tivoli Provisioning Manager Operating System AIX 5.2 AIX 5.3 Server type IBM pSeries Processor speed 1 GHz CPU RAM Minimum 4 GB of free memory Free disk space Refers to Table 3-4 on page 69 for details
Table 3-4 on page 69 lists the disk space requirement for the prerequisite software:
Table 3-4 Disk space requirements for the prerequisite software Component Default installation path Minimum required disk space in MB 1600
DB2 Universal Database Enterprise Server Edition server DB2 Universal Database Enterprise Server Edition instance owner Tivoli Directory Server Tivoli Directory Server instance owner WebSphere Application Server Tivoli Provisioning Manager Temporary space
/usr/opt/db2_08_01
/home/db2inst1
2500
/opt/IBM/ldap/V6.0 /home/ldapinst /usr/IBM/WebSphere/AppServer /opt/ibm/tivoli/tpm /tmp
2000 100 2000 5000 2000
69
3.4.3 Software requirements for Tivoli Provisioning Manager

Tivoli Provisioning Manager requires a number of supporting software applications to be installed. For managing servers or server upon which Tivoli Provisioning Manager is installed, the following software is required.
Operating System
The following Operating Systems are supported for the installation: AIX 5.2 64 Bit ML7 AIX 5.3 64 Bit Power5 ML1 Example 3-1 on page 70 shows the configuration of the machines used for this Redbook:
Example 3-1 Machines configuration used in the lab for the installation
Follows the prtconf output from the first machine: System Model: IBM,9113-550 Processor Type: PowerPC_POWER5 Number Of Processors: 2 Processor Clock Speed: 1656 MHz CPU Type: 64-bit Kernel Type: 64-bit Memory Size: 3808 MB Good Memory Size: 3808 MB For this system we created a 2 GB paging space. Follows the prtconf output from the second machine: System Model: IBM,7028-6E1 Processor Type: PowerPC_POWER3 Number Of Processors: 2 Processor Clock Speed: 375 MHz CPU Type: 64-bit Kernel Type: 64-bit Memory Size: 2048 MB Good Memory Size: 2048 MB For this system we created a 2.5 GB paging space There are some additional requirements for the Tivoli Provisioning Manager that are described in the section 3.4.6, Preparing AIX systems for installation on page 77.
70
Important: For all Linux, AIX and Solaris systems, ensure that the /tmp folder is not owned by root.
Prerequisite software
Example 3-5 on page 71 shows the supported version of prerequisite applications.
Table 3-5 Prerequisite software Required software Database Application server Supported applications DB2 Universal Database Enterprise Server Edition 8.2, Fix Pack 11 WebSphere Application Server 6.0, Fix Pack 2 with latest interim fix. In case you plan to use an existing user account on an existing directory server with Tivoli Provisioning Manager, user IDs cannot contain double-byte characters. Directory server Web browser Tivoli Directory Server 6.0, Fix Pack 1 The computer you are using to access the Web interface must be on the same network as the provisioning server. Microsoft Internet Explorer 6.0.29 or later. You must use a full installation of Internet Explorer with Internet Tools with the latest critical security updates from Microsoft. Firefox 1.5 or later. For some Web interface features, such as setting a home page, cookies must be enabled
3.4.4 Installing behind a firewall

If you are running a remote installation and if the management LAN where you intend to install Tivoli Provisioning Manager is protected by a firewall, some communication ports must be opened. In a remote installation the TIL is installed on a machine different from the Tivoli Provisioning Manager server. In this case, if a firewall is located between these two machines, you should make sure that the ports in Table 3-6 on page 72 are opened to the firewall.
71
Table 3-6 Communication port used by Tivoli Provisioning Manager Request DHCP REQUEST DHCP REPLY PROXY DHCP TFTP BootDiscovery MTFTPPort MTFTPClients NBPServer FileServerPort FileMCAST- Address FASTPort SSH Telnet TS SNMP SNMP-TRAP Protocol UDP (broadcast) UDP UDP UDP UDP (multicast) UDP UDP (multicast) UDP UDP UDP UDP TCP TCP TCP UDP UDP Source Port any 67 any any any any any any any any any any any any any any Destination Port 67 68 4011 69 4011 4015 8500 4012 4013 10000 4025 22 23 3389 161 162 From managed servers provisioning server managed servers managed servers managed servers managed servers provisioning server managed servers managed servers provisioning server managed servers provisioning server managed servers provisioning server provisioning server managed servers To provisioning server managed servers provisioning server provisioning server provisioning server provisioning server managed servers provisioning server provisioning server managed servers provisioning server managed servers provisioning server managed servers managed servers provisioning server
72
Request SMB / NetBIOS Agent manager WebSphere Application Server 6.0
Protocol TCP TCP TCP
Source Port any any any
Destination Port 139 9511,9512,9 513 9080,9082, 9043,9045, 9046
From provisioning server provisioning server provisioning server
To managed servers managed servers managed servers
Note: Tivoli Provisioning Manager also uses the RXA (IBM Tivoli Remote Execution and Access) protocol, but it makes connections using standard SSH (Secure Shell) or SMB (Server Message Block) protocols and does not require a separate port.
3.4.5 Preparing installation images

There are several reasons why you might want use installation images instead of CDs to perform installation: Using installation images instead of CDs can reduce installation time. If you are installing software on multiple nodes, you can store the installation images on nodes where they will be installed so that the installer does not need to copy the installation software to each target computer. If you want to perform a silent installation, you must create an image depot for the prerequisite software as well as Tivoli Provisioning Manager. The installer does not prompt for media when running silently. To create a central image depot you should perform the following steps: Create a root installation directory for the installation images. In the example we describe for this Redbook, we use /tpmdepot as root directory. Note: Make sure that you do not name this directory disk or any other name starting with disk and you do not put any spaces in the directory names. The name you choose for the top level directory of your installation directory must be specified in the response file template. In this example it is tpmdepot. 7. Create subdirectories for each installation image. Table 3-7 on page 74 shows the required directory structure.
73
Table 3-7 Required directory structure for images Installation image Tivoli Provisioning Manager Installation: TPM_V51_Disk1_AIX.tar Common Inventory Technology: TPM_TIO_V51_Disk2_multiplatf.tar Tivoli Provisioning Manager: TPM_V51_Disk3_aix.tar TPM_TIO_V51_Disk4_aix.tar TPM_TIO_V51_Disk5_unix.tar.gz Tivoli Provisioning Manager for Dynamic Content Delivery: CDS_V13_AIX.tar (it comes with TPM_TIO_V51_Disk6_aix.tar) Tivoli Common Agent Services: AM_V13_AIX.tar (it comes with TPM_TIO_V51_Disk6_aix.tar) Job Management Service (DMS Federator): DMS_V20_multiplatf.tar.gz (it comes with TPM_TIO_V51_Disk6_aix.tar) DB2 Universal Database Depot directory /tpmdepot/disk1 /tpmdepot/disk2 /tpmdepot/aix/tpm
/tpmdepot/aix/cds
/tpmdepot/aix/cas
/tpmdepot/dms
/tpmdepot/aix/db2 There are separate images for each supported language: ensure that you use the appropriate image. /tpmdepot/aix/itds60 /tpmdepot/aix/was
Tivoli Directory Server WebSphere Application Server
In Example 3-2 on page 74, you can see how the central directory depot looks like after copying all the files needed for the installation:
Example 3-2 Central image depot directory structure on AIX
The central image depot must present the following directory structure: [root@paris][/tpmdepot]-> ls -la total 24 drwxrwxrwx 7 root system drwxr-xr-x 27 root system
256 Aug 28 09:00 . 4096 Aug 30 13:29 ..
74
drwxrwxrwx drwxrwxrwx drwxrwxrwx drwxrwxrwx drwxrwxrwx
8 15 2 2 2
root root root root root
system system system system system
4096 4096 256 256 256
Aug Aug Aug Aug Aug
23 21 21 21 21
14:14 11:51 11:49 12:14 11:13
aix disk1 disk2 dms lost+found
The disk1 directory contains the extracted image of the TPM_V51_Disk1_AIX.tar file: [root@paris][/tpmdepot/disk1]-> ls -la total 89328 drwxrwxrwx 15 root system 4096 Aug 21 11:51 drwxrwxrwx 7 root system 256 Aug 28 09:00 drwxrwxrwx 2 1000 1000 256 Jul 24 17:04 drwxrwxrwx 9 1000 1000 4096 Jul 24 17:04 drwxrwxrwx 2 1000 1000 256 Jul 24 17:04 drwxrwxrwx 3 1000 1000 256 Jul 24 17:04 drwxrwxrwx 2 1000 1000 256 Jul 24 17:04 drwxrwxrwx 2 1000 1000 256 Jul 24 17:04 drwxrwxrwx 2 1000 1000 256 Jul 24 17:04 drwxrwxrwx 2 1000 1000 256 Jul 24 17:04 drwxrwxrwx 2 1000 1000 256 Jul 24 17:04 -rwxrwxrwx 1 1000 1000 12 Jul 24 17:04 -rwxrwxrwx 1 1000 1000 11 Jul 24 17:04 product.properties drwxrwxrwx 2 1000 1000 256 Jul 24 17:04 -rwxrwxrwx 1 root system 7204 Jul 25 19:08 drwxrwxrwx 3 1000 1000 256 Jul 24 17:04 -rwxrwxrwx 1 1000 1000 8416410 Jul 24 17:04 -rwxrwxrwx 1 1000 1000 36684800 Jul 24 17:04 -rwxrwxrwx 1 1000 1000 603776 Jul 24 17:04 drwxrwxrwx 2 1000 1000 256 Jul 24 17:04 drwxrwxrwx 2 1000 1000 256 Jul 24 17:04 The disk2 directory contains the extracted image of the TPM_TIO_V51_Disk2_multiplatf.tar file: [root@paris][/tpmdepot/disk2]-> ls -R total 1121296 CIT_V22_AIX.tar.gz CIT_V22_LIN_IA32.tar.gz CIT_V22_LIN_PPC.tar.gz CIT_V22_SUN.tar.gz CIT_V22_WIN.zip CIT_V22_zLIN.tar.gz
. .. apde bin de eclipse es fr it ja ko media.inf
pt_BR rembo.key setup setup.jar setupaix.bin splash.bmp zh_CN zh_TW
75
Follows the content of the other directories contained in the depot structure: [root@paris][/tpmdepot/dms]-> ls -la total 570952 drwxrwxrwx 2 root system 256 Aug 21 12:14 . drwxrwxrwx 7 root system 256 Aug 28 09:00 .. -rwxrwxrwx 1 root system 292327353 Jul 25 12:09 DMS_V20_multiplatf.tar.gz [root@paris][/tpmdepot/aix]-> ls -la total 16 drwxrwxrwx 8 root system drwxrwxrwx 7 root system drwxrwxrwx 2 root system drwxrwxrwx 2 root system drwxrwxrwx 2 root system drwxrwxrwx 2 root system drwxrwxrwx 2 root system drwxrwxrwx 2 root system
4096 256 256 256 256 256 256 4096
Aug Aug Aug Aug Aug Aug Aug Aug
23 28 21 21 22 21 21 21
14:14 09:00 12:12 12:12 08:59 12:26 12:20 12:25
. .. cas cds db2 itds60 tpm was
This is the content of the other directories: [root@paris][/tpmdepot/aix]-> ls -R cas cds db2 itds60 tpm ./cas: AM_V13_AIX.tar ./cds: CDS_V13_AIX.tar ./db2: DB2_ESE_V82FP11_aix_EnItDeFr.tar.gz ./itds60: FP1_for_ITDS_V60_aix.tar ITDS_V60_aix.tar ./tpm: TPM_V51_Disk3_aix.tar TPM_TIO_V51_Disk4_aix.tar TPM_TIO_V51_Disk5_unix.tar.gz ./was:
was
76
WAS_V60_32bit_aix.tar.gz FP2_for_WAS_V60_32bit_aix.tar FP11_for_WAS_V60_32bit_aix.tar 8. Copy the images to your image depot using one of the following methods: Place each CD in the CD-ROM drive, and copy the images from each CD into the subdirectory that you have created. Mount the CD-ROM drive, but do not change directory to the mount point. Note: Changing directories to the mount point will lock the CD-ROM and prevent you from being able to swap CDs. You must unmount the CD-ROM before trying to eject CD. Otherwise the CD-ROM tray will be locked and you will be unable to switch to CDs of the other software prerequisites.
If you download your product from Passport Advantage refers to Example 3-2 on page 74 to extract the contents to the appropriate subdirectory. Important: The native UNIX tar utility does not support long file names. You must use GNU version of tar to extract the contents of a downloaded image in a .tar archive. You can obtain the tar package from: http://www.ibm.com/servers/aix/products/aixos/linux/download.ht ml.
3.4.6 Preparing AIX systems for installation

Before start the installation you must log on as root and perform the following tasks:
Use 64 bit kernel

On AIX 5.2 and AIX 5.3, Tivoli Provisioning Manager supports a 64-bit kernel only. Perform the following checks: Check the CPU type is 64 bit running the following command: prtconf -c Check the kernel type running the following command: prtconf -k
77
If kernel type is 32 bit, then you need to change to a 64 bit kernel. Run the following commands to change to a 64 bit Kernel and reboot the system: a. ln -fs /usr/lib/boot/unix_64 /unix b. ln -sf /usr/lib/boot/unix_64 /usr/lib/boot/unix c. bosboot -ad /dev/hdboot_volume, where hdboot_volume is where the boot logical volume is located. To find out what boot_volume is, run the following command: d. lslv -m hd5 e. shutdown -Fr
Check that your machine meets the hardware and software requirements
Ensure that the Operating System is at the correct version and maintenance level, and that the memory and disk requirements are satisfied. Example 3-3 on page 78 reports the commands you can use to perform these checks.
Example 3-3 Hardware and software requirements check
To verify the Operating System version and maintenance level: [root@paris][/]-> oslevel -r 5300-04 To check if both the cpu and the kernel are running at 64-bit: [root@paris][/]-> prtconf -c CPU Type: 64-bit [root@paris][/]-> prtconf -k Kernel Type: 64-bit To check the available physical memory on the machine: [root@paris][/]-> lsattr -El mem0 goodsize 3808 Amount of usable physical memory in Mbytes False size 3808 Total amount of physical memory in Mbytes False To check the available paging space on the machine: [root@paris][/]-> lsps -s Total Paging Space Percent Used
78
2048MB
1%
As described in Table 3-3 on page 69, the minimum amount of memory required for the Tivoli Provisioning Manager server is 4 GB, anyway we tested a successful Enterprise installation on a system with 2 GB of RAM, defining a system paging space larger enough to grant at least 4 GB of total free memory counting the sum of both physical memory plus paging space.
Create your own file systems structure

Before you start the software installation, you can create your own file systems structure in case you do not want to use the system ones. Read carefully the instructions detailed in this section to avoid failures during the installation. Table 3-8 on page 79 shows the default path locations of the various components installed by Tivoli Provisioning Manager detailing which paths can be overwritten. Some of those are hard coded and cannot be changed.
Table 3-8 Default path locations for Tivoli Provisioning Manager components Product name Tivoli Provisioning Manager Tivoli Provisioning Manager repository WebSphere Application Server WebSpere Application Server instance owner DB2 UDB ESE Client DB2 UDB ESE Server Tivoli Directory Server Agent Manager Common Inventory Technology Common directory for log files Default path location /opt/ibm/tivoli/tpm /opt/ibm/tivoli/tpm/repository /usr/IBM/WebSphere/AppServer /home/ldapinst /home/db2inst1/sqllib /usr/opt/db2_08_01 /opt/IBM/ldap/V6.0 /usr/IBM/AgentManager /opt/tivoli/cit /opt/ibm/tivoli/common/ctgde/logs Overwrite YES YES YES NO YES NO NO NO NO NO
79
Note: If you create your own file systems, make sure that the mount point does not include the last directory in the path. For example, if you install IBM DB2 Version 8.2, the installer copies, by default, the program files under /usr/opt/db2_08_01 and the instance owner files under /home/db2inst1/sqllib. If you plan to create a file system for the instance owner, make sure the name will be something like /home/db2inst1. Including sqllib in the mount point causes the installation to fail: looking in the log files, you see that the reason of the failure is an already existing installation due to the existence of the sqllib subdirectory created as part of the file systems mount point. Example 3-4 on page 80 reports the file system structure been used in our lab environment.
Example 3-4 File system structure used in lab environment
This output reports the situation after the Operating System installation and maintenance level application: [root@paris][/]-> df -k Filesystem 1024-blocks /dev/hd4 131072 /dev/hd2 1179648 /dev/hd9var 131072 /dev/hd3 131072 /dev/hd1 131072 /proc /dev/hd10opt 131072
Free %Used 118192 10% 160588 87% 122640 7% 127932 3% 130708 1% 38992 71%
Iused %Iused Mounted on 1784 7% / 24780 39% /usr 360 2% /var 61 1% /tmp 5 1% /home - /proc 2288 21% /opt
We first created a volume group called tpmvg with these file systems: [root@paris][/]-> lsvg -l tpmvg tpmvg: LV NAME LPs PPs PVs LV STATE loglv00 1 1 1 open/syncd fslv00 28 28 1 open/syncd fslv01 16 16 1 open/syncd fslv02 20 20 1 open/syncd fslv03 4 4 1 open/syncd fslv04 8 8 1 open/syncd
MOUNT POINT N/A /opt/ibm/tivoli /usr/IBM/WebSphere /home/db2inst1 /opt/IBM/ldap /usr/opt/db2_08_01
80
For the installer requirements, we increased the free space of /usr and /tmp filesystems to meet the requirements detailed in Table 3-2 on page 67 The df output after the file system creation and adjustments looks like the following: [root@paris][/]-> df -k Filesystem 1024-blocks /dev/hd4 131072 /dev/hd2 8519680 /dev/hd9var 7471104 /dev/hd3 8388608 /dev/hd1 655360 /proc /dev/hd10opt 1310720 /dev/fslv00 3670016 /dev/fslv01 2097152 /dev/fslv02 2621440 /dev/fslv03 2097152 /dev/fslv04 1703936
Free %Used 118160 10% 7499452 12% 7461548 1% 8384208 1% 574864 13% 1218460 8% 3669128 1% 2096504 1% 2620712 1% 1952456 7% 918116 47%
Mounted on / /usr /var /tmp /home /proc /opt /opt/ibm/tivoli /usr/IBM/WebSphere /home/db2inst1 /opt/IBM/ldap /usr/opt/db2_08_01
We also increased the default paging space of 512 MB to 2048 MB. We are using 128 MB partitions for the rootvg volume group, so this is the command we used to create and activate now and at reboot a new paging space: [root@paris][/]-> mkps -s'12' -n'' -a'' rootvg paging00 [root@paris][/]-> lsps -s Total Paging Space Percent Used 2048MB 1%
Install required packages

Some packages are required during the installation. You can download them from this location: http://www.ibm.com/server/aix/products/aixos/linux/download.html
Example 3-5 Required packages installation
Once downloaded from the above link, they can be installed using the rpm command as detailed in this example:
81
[root@paris][/tivcode/Prereq/RPMs]-> ls bash-3.0-1.aix5.1.ppc.rpm tcl-8.3.3-8.aix4.3.ppc.rpm bash-doc-3.0-1.aix5.1.ppc.rpm tk-8.3.3-8.aix4.3.ppc.rpm expect-5.34-8.aix4.3.ppc.rpm unzip-5.51-1.aix5.1.ppc.rpm perl-5.8.2-1.aix5.1.ppc.rpm wget-1.9.1-1.aix5.1.ppc.rpm tar-1.14-1.aix5.1.ppc.rpm [root@paris][/tivcode/Prereq/RPMs]-> rpm -ivh bash-3.0-1.aix5.1.ppc.rpm \
> bash-doc-3.0-1.aix5.1.ppc.rpm tcl-8.3.3-8.aix4.3.ppc.rpm \ > tk-8.3.3-8.aix4.3.ppc.rpm expect-5.34-8.aix4.3.ppc.rpm \ > unzip-5.51-1.aix5.1.ppc.rpm perl-5.8.2-1.aix5.1.ppc.rpm \ > wget-1.9.1-1.aix5.1.ppc.rpm tar-1.14-1.aix5.1.ppc.rpm bash ################################################## bash-doc ################################################## tcl ################################################## tk ################################################## expect ################################################## unzip ################################################## perl ################################################## wget ################################################## tar ##################################################
You can now proceed with the other steps in the installation checklist.
Install OpenSSL and OpenSSH

Another prerequisite for the installation is the OpenSSH. The packages can be downloaded from the following url: https://sourceforge.net/projects/openssh-aix Example 3-6 on page 82 details the procedure to install these file packages. Note: Make sure to use the right openSSH version for your Operating System version. There are different packages for AIX 5.2 and AIX 5.3.
Example 3-6 Installation instructions for openSSL and openSSH
The opneSSH requires openSSL to be installed first. [root@paris][/tivcode/Prereq/openSSL_SSH/openSSL]-> ls openssl-0.9.7g-1.aix5.1.ppc.rpm [root@paris][/tivcode/Prereq/openSSL_SSH/openSSL]-> rpm -ivh \ > openssl-0.9.7g-1.aix5.1.ppc.rpm openssl ##################################################
82
To install the openSSH file packages you can use the below provided script in alternative to the classic installation using smit or smitty. /usr/lib/instl/sm_inst installp_cmd -a -l -d '.' -f 'openssh.base ALL @@I:openssh.base _all_filesets,openssh.license ALL @@I:openssh.license _all_filesets,openssh.man.en_ US ALL @@I:openssh.man.en_US _all_filesets,openssh.msg.EN_US ALL @@I:openssh.msg.EN_US _all_filesets,openssh.msg. en_US ALL @@I:openssh.msg.en_US _all_filesets' '-c' '-N ' '-g' '-X' '-Y' After some pages detaling the progress of the installation, you receive the installation summary: Installation Summary -------------------Name Level Part Event Result -----------------------------------------------------------------openssh.license 4.1.0.5301 USR APPLY SUCCESS openssh.base.client 4.1.0.5301 USR APPLY SUCCESS openssh.base.server 4.1.0.5301 USR APPLY SUCCESS openssh.base.client 4.1.0.5301 ROOT APPLY SUCCESS openssh.base.server 4.1.0.5301 ROOT APPLY SUCCESS openssh.msg.en_US 4.1.0.5301 USR APPLY SUCCESS openssh.msg.EN_US 4.1.0.5301 USR APPLY SUCCESS openssh.man.en_US 4.1.0.5301 USR APPLY SUCCESS You can try now to run a ssh for you fully qualified host name: [root@paris][/tivcode/Prereq/openSSL_SSH/openSSH_AIX53]-> ssh \ > paris.itsc.austin.ibm.com The authenticity of host 'paris.itsc.austin.ibm.com (9.3.5.45)' can't be established. RSA key fingerprint is 12:63:a5:2f:50:8a:12:0a:6d:b2:5e:5b:76:26:b0:4a. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'paris.itsc.austin.ibm.com,9.3.5.45' (RSA) to the list of known hosts. root@paris.itsc.austin.ibm.com's password: Last login: Mon Sep 4 13:49:44 CDT 2006 on /dev/pts/0 from dragoon *********************************************************************** * * * * * Welcome to AIX Version 5.3! * * * * *
83
* Please see the README file in /usr/lpp/bos for information * * pertinent to this release of the AIX Operating System. * * * * * *********************************************************************** [root@paris][/]-> You can now proceed with the other steps in the installation checklist.
Verify script location

The location of the shells or script interpreters is important because the scripts called by the installer include this information on the first line of the script. Make sure the following packages are installed in the below locations as these are the locations that the Tivoli Provisioning Manager installer looks in, during the installation, when checking for prerequisites: Bash location /usr/bin Expect Location /usr/local/bin Example 3-7 on page 84 details the commands to check and eventually change these packages location.
Example 3-7 Verify bash and expect locations
The which command can be used to locate a file within the $PATH variable. The ln command can be used to create a link to the expected path. [root@paris][/]-> which bash /usr/bin/bash The above path is correct, so no further actions are needed. [root@paris][/]-> which expect /usr/bin/expect In this case the location of the expect command is not the one required by the Tivoli Provisioning Manager installer. You can use the following commands to create a symbolic link. [root@paris][/]-> mkdir -p /usr/local/bin
84
The -p option is used in case the /usr/local mount point does not exist and allow you to create in one shot both local and bin subdirectories under /usr. [root@paris][/]-> ln -s /usr/bin/expect /usr/local/bin/expect [root@paris][/]-> ls -la /usr/local/bin/expect lrwxrwxrwx 1 root system 15 Sep 04 16:01 /usr/local/bin/expect -> /usr/bin/expect
Verify umask settings

Set the umask to 0002 for the Tivoli Provisioning Manager files to be installed with the correct permissions for operations. The umask command is what the system uses to determine the permissions that new files receive when they are created. It is a shell command and is not a shell variable so it does not show up when the env command is run. Running the umask command shows you the current umask setting. umask 0002 is used to give all access permissions to the group and allow other users read and execute permission. You can either run the command from the same shell that will run the installation or run it in a .kshrc or similar files recalled by the .profile for the root user. Note: Make sure to use the root user, or run su - if you change the current user.
Check system path settings

Set the default system directory path variable so that any user on the system can access the tools. The GNU tar should be in the PATH variable of the root user or any other administrative ID. Edit the PATH variable by adding /usr/linux/bin at the front of the path.
Ensure that xlC.rte 6.0 run-time code is installed

On the nodes where DB2 Universal Database will be installed, download the run-time code as a fix from the AIX Support site at the following url: https://techsupport.services.ibm.com/server/aix.fdc Example 3-8 on page 86 details the command to verify the actual xlC.rte file package installation:
85
Example 3-8 Command to verity the xlC.rte file package installation
[root@paris][/]-> lslpp -l |grep xlC.rte xlC.rte 6.0.0.0 COMMITTED
C Set ++ Runtime
Checking for a fully qualified host name

Tivoli Provisioning Manager and servers managed by Tivoli Provisioning Manager require fully qualified host names. Important: For the Tivoli Provisioning Manager server you must use a static ip address. Some machines might be configured to return a short host name, such as city instead of a fully qualified host name, such as city.myorg.mycompany.com. The default domain name search order is as follows: 1. Domain Name System (DNS) server 2. Network Information Service (NIS) 3. Local /etc/hosts file If the /etc/resolv.conf file does not exist, the /etc/hosts file is used. If only the /etc/hosts file is used, the fully qualified computer name must be the first one that is listed after the IP address. Verify that the /etc/resolv.conf file exists and contains the appropriate information, such as: domain mydivision.mycompany.com nameserver www.xxx.yyy.zzz If NIS is installed, the /etc/irs.conf file overrides the system default. It contains the following information: hosts = bind,local The /etc/netsvc.conf file, if it exists, overrides the /etc/irs.conf file and the system default. It contains the following information: hosts = bind,local If the NSORDER environment variable is set, it overrides all of the preceding files. It contains the following information: export NSORDER=bind,local
86
Modify the prompt of the Tivoli Provisioning Manager machine

Modify the prompt on the machine where you plan to install the Tivoli Provisioning Manager server software, to end in one of the following three prompts: 1. $ 2. # 3. > You can make this change in the default .profile of the root user setting a variable as shown below: PS1="[`whoami`@`hostname`][\$PWD]-> " export PS1 Logout and login to make the change permanent on each shell you open, or execute again the .profile from the current shell running this command from the / directory: . ./.profile The prompt now looks like the following: [root@paris][/]->
WebSphere Application Server

During installation, the default WebSphere Application Server ports 9080, 9061 and 9443 are used to create the WebSphere Application Server profile for Tivoli Provisioning Manager. These ports must be available on the computer where you are installing Tivoli Provisioning Manager.
3.4.7 Installing Tivoli Provisioning Manager step by step

In this section we discuss a local single-node installation using the Topology Installer Launcher. If you want to perform an unattended installation with predefined settings, you can run the installer in silent mode. Refers to 3.5, Unattended installation on Linux on page 120 for details about the silent installation.
Before you begin installation

The installation process allows you to preinstall the prerequisite software on the target system for your Tivoli Provisioning Manager installation.
87
If you do that, make sure that the following requirements are met before you begin the installation process: 1. Ensure that the target computers for the installation meet all the requirements described in 3.4.2, Hardware requirements for Tivoli Provisioning Manager server machine on page 69 and 3.4.3, Software requirements for Tivoli Provisioning Manager on page 70. 2. Close all programs so that the installation program can update files as required. 3. If Tivoli Directory Server is preinstalled, ensure that the Tivoli Directory Server database instance, that you had created while configuring the Tivoli Directory Server database, is started. To check the status of the Tivoli Directory Server, run the following command: ibmdirctl -D cn=root -w password status where password is the password for the cn=root Ensure that the port 389 is free before running the TIL. 4. If you have manually installed the WebSphere Application Server 6.0, then you must stop the WebSphere Application Server 6.0 profile before you can begin the installation. Stopping the profile allows Agent Manager to be able to configure the SSL on WebSphere Application Server 6.0. 5. If you want to perform a silent installation, you must use an installation image depot that contains the install images of all the prerequisite software products that should be installed. Refer to 3.4.5, Preparing installation images on page 73 for details.
Starting the Tivoli Provisioning Manager wizard

To start the Tivoli Provisioning Manager wizard: 1. Log on as root on the system. Note: If you are using the su command to change to root, ensure that you run su -. 2. If you are using CDs for installation, mount the CD-ROM drive, but do not change directory to the mount point. Note: Changing directories to the mount point will lock the CD-ROM and prevent you from being able to swap CDs. You must unmount the CD-ROM before trying to eject the CD. Otherwise the CD-ROM tray will be locked and you will be unable to switch CDs.
88
3. Start the installer by typing the following command: mount_point/setupaix.bin Note: If the locale is in a language other than English, you must run the command with the locale as one of the parameters. For example, if the locale is Japanese and you want to invoke the Topology installer launcher in Japanese, run the following command: mount_point/setupaix.bin -W locale.LANG="ja_JP" To check to see what locale the system is running, run the following command: locale -a For example, if it is a Japanese locale, the value returned is: ja_JP For the installation described in this redbook, we use a central image depot. Figure 3-3 on page 89 shows the installer invocation:
Figure 3-3 Invoking the installer
89
4. The installer brings up some messages in the window where you run the installation, like shown in Figure 3-4 on page 90.
Figure 3-4 InstallShield Wizard initialization
5. At this point you see the Tivoli Provisioning Manager splash screen showed in Figure 3-5 on page 90.
Figure 3-5 Tivoli Provisioning Manager splash screen
During this phase, the installation process installs the Topology Installation Launcher. The files are copied to the /tmp/TopologyInstallerLauncher directory.
90
Note: If you do not want the TIL to be uninstalled when the installation is finished or when you cancel it, you can install it in permanent mode by launching the installer with the following command: setupaix.bin -W options.permanent=True When this option is specified, the TIL is installed in this path: /opt/TopologyInstallerLauncher unless you specify a custom path with the option: -W options.tiLocation="full_path" 6. This is a silent installation. You receive a first the splash screen with the text Initializing wizard... followed by the one shown in Figure 3-6 on page 91.
Figure 3-6 Preparing the environment splash screen
This splash screen is shown while the Topology Installer Launcher is being installed, and depending on the machine you are using for the installation, this phase can last between 15 and 25 minutes. 7. At competition, you see the Figure 3-7 on page 92.
91
Figure 3-7 Tivoli Provisioning Manager Product panel
8. This splash screen precedes the Welcome panel shown in Figure 3-8 on page 92. Click Next:
Figure 3-8 Welcome to the Installation Wizard for Tivoli Provisioning Manager V5.1 panel
9. Click I accept the terms in the license agreement then the Next button becomes available as shown in Figure 3-9 on page 93.
92
Figure 3-9 Software License Agreement panel
10.The installer now verifies the credentials specified for the system and the Server deployment configuration panel is shown in Figure 3-11 on page 94.
Figure 3-10 Specify the credential for the local system
11.As detailed at the beginning of this chapter, the only supported topology at the moment is what is called Single server configuration in the above panel (Figure 3-11 on page 94). Click Next.
93
Figure 3-11 Server deployment configuration panel
12.In the next panel (Figure 3-12 on page 95) you should provide the following information: the fully qualified Host name of the server where you are installing the software; the IP address field is filled automatically if the name resolution has been configured correctly. Refers to Checking for a fully qualified host name on page 86 for details; the Operating system that can be selected from the pull down menu; User name and Password with administrator privileges on the server.
94
Figure 3-12 Configure the target server panel
Note: Passwords can contain letters and digits only. No special characters are allowed. For example, = is not allowed. 13.The installer now verifies the credentials and the privileges specified and the Target servers validation panel is shown (Figure 3-13 on page 96).
95
Figure 3-13 Target servers validation
During this phase of the installation, the Common Inventory Technology (CIT) is installed on the system, and a scan is executed against the Tivoli Provisioning Manager server machine to verify the information provided and the status of the installation and configuration of the prerequisite software. 14.The CIT is contained in the second installation CD image, so the installer prompts you to insert the Tivoli Provisioning Manager and Intelligent Orchestrator, Version 5.1, Disk 2 or specify a Path for the images (Figure 3-14 on page 96).
Figure 3-14 Tivoli Provisioning Manager and Intelligent Orchestrator V5.1, Disk 2
96
15.This phase lasts some minutes and shows you a panel with some information about the progress of the installation and the subsequent discovery as shown in Figure 3-15 on page 97.
Figure 3-15 CIT install and discovery panel
16.Once this phase has been completed, you receive the Validation summary panel, as shown in Figure 3-16 on page 97.
Figure 3-16 Validation summary panel
This panel is composed of two parts:
97
Validation Name that lists the prerequisites that where checked and the status of the validation. The validation includes: Verifying credentials for the target server such as user name and password. Verifying that Cygwin is installed if it the target server is a Windows computer. Hardware and software prerequisites are met. If the target server passes the validation, a green check mark appears. A grey X icon appears if a prerequisite is not met. In case a prerequisite is not met, double-click on the grey X icon to verify what action needs to be taken. Software Name that lists the status for each piece of prerequisite software required for installation. Found Displays Yes if the software is found. Displays No if it is not found. Install Select the Install check box to install the required prerequisite software with the installer on the target server. Configure Select the Configure check box to configure the required prerequisite software with the installer. Note: The CIT is able to perform the scan and make the above selections for you. Just double check that they reflect the actual status of the prerequisite software installation and configuration. In the next panel, you will see a tab for each piece of software that the installer will configure. Click on each tab and specify the settings for each product. Note: Directory paths should not contain a slash as the last character of the path (/). 17.In our installation, we first select the Tivoli Provisioning Manager V5.1 tab. The Tivoli Provisioning Manager configuration screen is shown in Figure 3-17 on page 99.
98
Figure 3-17 Tivoli Provisioning Manager V5.1 tab - Tivoli Provisioning Manager configuration
Specify the Destination directory and the Local software repository directory or accept the defaults. The Tivoli Provisioning Manager user password, is assigned to a user called tioadmin created by the installer, and used to own all the Tivoli Provisioning Manager files. Scroll down this tab and the WebSphere Application Server configuration screen is shown in Figure 3-18 on page 100.
99
Figure 3-18 Tivoli Provisioning Manager V5.1 tab - WAS configuration
Make sure the domain name server suffix has been reported correctly and change the Installation directory if you do not want to maintain the default value. Scroll down this tab and the Tivoli Directory Server configuration screen is shown in Figure 3-19 on page 101.
100
Figure 3-19 Tivoli Provisioning Manager V5.1 tab - TDS configuration
The installer is able to install and configure the Tivoli Directory Server using the information provided in the above screen. Scroll down this tab and the DB2 Universal Database configuration screen is shown in Figure 3-20 on page 102.
101
Figure 3-20 Tivoli Provisioning Manager V5.1 tab - DB2 configuration
Important: Use the default values for the IBM DB2 configuration screen.
102
This screen contains also two fields in a different color, Database user name and Database user password. They are optional and the default value is used if not specified, thus same user name and password as the instance owner. 18.Next we select Tivoli Provisioning Manager Components Configuration tab. The Agent Manager ports are automatically filled to the default values.
Figure 3-21 Tivoli Provisioning Manager Components Configuration tab
Insert the Agent registration password and confirm it. 19.Next, we select the WebSphere Application Server tab as shown in Figure 3-22 on page 104.
103
Figure 3-22 WebSphere Application Server tab
Change the Destination directory for the WebSphere Application Server installation if you do not want to use the default value. 20.Next tab is the DB2 Universal Database tab (Figure 3-23 on page 105).
104
Figure 3-23 DB2 Universal Database tab
In the above screen you are asked to set the default password for the users used by the DB2 Universal Database. Finaly we select Tivoli Directory Server tab (Figure 3-24 on page 106).
105
Figure 3-24 Tivoli Directory Server tab
This screen allows you to specify the DB2 database configuration required by Tivoli Directory Server. This configuration consist of: Creation of a user called ldapinst that represents the instance owner of the Tivoli Directory Server database. Creation of an instance called ldapinst to the Tivoli Directory Server. Configuration of the instance that results in the creation and configuration of a database (the default name is ldapdb) to the DB2 UDB Universal Database.
106
21.Once all the information are provided to the installer, the Next button becomes available. The installer validates the settings you have specified, available disk space, and available memory on the target servers, and then displays results on the Validation summary panel as shown in Figure 3-25 on page 107.
Figure 3-25 Validation summary
Important: In this phase, the installer checks for the available space in the listed file systems. There is an issue related to the IBM DB2 Universal Database installation: the validation uses the custom file system mount point to check for available free space, but the installation checks for the actual free space on the /usr file systems, so you should make sure to have at least 1600 MB of free space on /usr even if you created your own file system with /usr/opt/db2_08_01 mount point (that represents the default mount point for an installation on AIX). The free disk space available for the above file systems, is compared against the values listed in Table 3-9 on page 107.
Table 3-9 Required free space for custom file systems File system name /usr/opt/db2_08_01 /usr/IBM/WebSphere /tmp Required free space in MB 1600 1000 2000
107
File system name /opt/ibm/tivoli /opt/IBM/ldap
Required free space in MB 5000 2000
This output can vary if you creates specific file systems for each product, as we did for this installation. In case you do not create other file systems then the defaults, the required free space is compared against the values shown in Table 3-10 on page 108.
Table 3-10 Required free space for default file systems File system name /usr /tmp /opt Required free space in MB 2600 2000 7000
Important: Additional free space must be reserved for the /home file system. By default, the IBM DB2 Universal Database configuration, created the Tivoli Provisioning Manager and the Tivoli Directory Server databases in the home directory of the instance owner user, respectively /home/db2inst1 for the Tivoli Provisioning Manager database and /home/ldapinst for the Tivoli Directory Server database. An installation uses, at completion, the following space: almost 2500 MB for /home/db2inst1 almost 100 MB for /home/ldapinst Make sure you grant at least 3000 MB of free space on your /home file system to avoid failures during the installation. Additional free space must be reserved also for the /usr filesystem due to the fact that the WebSphere Application Server installation uses more than 1600 MB. Make sure you grant at least 5000 MB of free space on your /usr filesystem to avoid failures during the installation. 22.Click Next and the panel for the installation image locations is displayed.
108
At the beginning you see all the products name in red because the default image location does not contain the images the installer is looking for. You can install the prerequisite software and Tivoli Provisioning Manager using the CDs provided with Tivoli Provisioning Manager or by copying the installation image to the hard drive from which you are installing. If you choose to install using installation images, you must copy all installation media to your hard drive or other filesystems. This includes all the prerequisite software media. Follow the procedure on section 3.4.5, Preparing installation images on page 73 for details. Note: For a silent installation, you must use installation images. If you are running the installer in record mode to create a response file, you must specify the location installation images on this panel. These are the options you can specify in the panel for the installation image locations: Root directory for the images Enter or browse to the location where all the installation images are stored. Use product CDs Select the check box if you want to use the CDs shipped with Tivoli Provisioning Manager. Note: If you select this check box, the fields in the panel that allow you to specify the location of the installation images will be disabled. Installation image paths For each listed piece of software, specify the location of the installation image. Directory paths should not contain a slash as the last character of the path (/). Select the Use the installation image on the target server to use images that you have downloaded on the remote target server to install the software. This option is particularly useful if the installation is on a remote server. In the text field, specify the full path of the image on the remote target server. Clear this check box to use the installation images in the default path. Note: Enter only the directory name. Do not enter the file name of the image in the path. 23.Once make your selections, the panel looks like Figure 3-26 on page 110.
109
Figure 3-26 Specify the location on the images required for the installation
110
24.If you do not build in the right way the path of some of the prerequisite software, a red notice is shown at the top of the panel specifying the image it is not able to find. Make the appropriate corrective actions unless all the red notices disappear. Click Next. The Summary panel displays (Figure 3-27 on page 111).
Figure 3-27 Summary panel
25.Review the summary and click Next to proceed with the installation. A progress bar indicates the status of the installation task. If you want to view the logs during the installation, click on the installation log tab. 26.The following Figure 3-28 on page 111 and Figure 3-29 on page 112 show the panels you see during this phase.
Figure 3-28 Installation in progress... - Installation Tasks tab
111
Figure 3-29 Installation in progress... - Installation Logs tab
27.When the installer completes all its installation tasks, the Next button becomes available (Figure 3-30 on page 113).
112
Figure 3-30 Installation summary
28.Click Next, the Installation is now complete panel appears.
113
Figure 3-31 Installation is now complete
The installation in now complete and you can proceed starting the graphical user interface as detailed in section Starting the Tivoli Provisioning Manager graphical user interface on page 116.
3.4.8 Installation log files

During the installation, the Topology Installer Launcher creates the following log file: /tmp/TopologyInstallerLauncher/workspace/.metadata/.log This file has a maximum size of 1MB. Once reached this size, it is saved as .bak_0.log and so on. As soon as the installer has been closed clicking on Finish button in the last panel you got at the end of the installation, these actions take place: the TIL is uninstalled, unless the parameters -W options.permament=True has been specified at installation time. Refer to Starting the Tivoli Provisioning Manager wizard on page 88 for details; all the /tmp/TopologyInstallerLauncher directory is cleaned up but the uninstall directories; the installation log files are saved under the following path: /tmp/tclog_til/ti Example 3-9 shows a simple directory listing of the above described directories.
Example 3-9 log file directories
Installation log files after the installation: [root@paris][/tmp/tclog_til/ti]-> ls -la total 4680 drwxrwxr-x 2 root system 256 Sep 05 08:37 . drwxrwxr-x 6 root system 256 Sep 05 08:37 ..
114
-rwxrwxr-x -rw-rw-r--rw-rw-r--
1 root 1 root 1 root
system system system
1025213 Sep 05 08:37 .bak_0.log 1025089 Sep 05 08:37 .bak_1.log 337359 Sep 05 08:37 .log
Topology Installer Launcher uninstall directories: [root@paris][/tmp/TopologyInstallerLauncher]-> ls -la total 40 drwxr-xr-x 6 root system 4096 Sep 05 08:39 drwxrwxrwt 17 bin bin 12288 Sep 06 17:27 drwxr-xr-x 4 root system 256 Sep 04 17:04 drwxr-xr-x 2 root system 256 Sep 05 08:40 drwxr-xr-x 2 root system 256 Sep 04 17:05 drwxr-xr-x 3 root system 4096 Sep 05 08:39
. .. _jvm_TIL _uninst _uninst_TIL eclipse
3.4.9 Time required to complete the installation

An Enterprise installation, that installs both Tivoli Provisioning Manager and all the prerequisite software, takes a long time to complete. The sequence of the installation is the following: 1. WebSphere Application Server 6.0 installation 2. WebSphere Application Server 6.0, Fix Pack 2 installation 3. WebSphere Application Server 6.0, Fix Pack 11 installation 4. DB2 Universal Database Enterprise Server Edition 8.2 5. DB2 Universal Database Enterprise Server Edition 8.2, Fix Pack 11 6. Tivoli Directory Server 6.0 7. Tivoli Directory Server 6.0, Fix Pack 1 8. Tivoli Provisioning Manager 9. Agent Manager 10.Tivoli Provisioning Manager for Dynamic Content Delivery 11.Tivoli Provisioning Manager for Job Management Service Table 3-11 on page 116 details the time to install the product on the AIX machine used for this chapter:
115
Table 3-11 Installation timing Product Name WebSphere Application Server 6.0 DB2 Universal Database Enterprise Server Edition 8.2 Tivoli Directory Server 6.0 Tivoli Provisioning Manager Agent Manager Tivoli Provisioning Manager for Dynamic Content Delivery Tivoli Provisioning Manager for Job Management Service Duration of the installation process 45 minutes 13 minutes 8 minutes 1 hour and 10 minutes 33 minutes 9 minutes 18 minutes
Total installation time is 3 hours and 16 minutes. The time required for the installation can be reduced: creating a local file repository on the target machine and specifing this file repository at installation time if you are performing a remote installation. In this case, the installer does not need to transfer via network the installation image, but simply start the uncompress, unpack and install operations. If you do not use a local file repository in a remote installation, another key element that can considerably increase the installation time is the network connectivity, due to the high amount of MB that the TIL should send over the network for the products and fixpack images. preinstalling the prerequisite software. In this case, the installer, during the CIT scanner phase, discover the installation and only needs to configure that specific software. Applying the above, you can save a consistent amount of time on the total installation process.
3.4.10 Starting the Tivoli Provisioning Manager graphical user interface

1. Before starting the Tivoli Provisioning Manager, first make sure that the product is running. To do this, you can use a script provided by the product, called tioStatus.sh as shown in Example 3-10 on page 117.
116
Example 3-10 Checking the status of the Tivoli Provisioning Manager
Make sure you su to the tioadmin user using the command su -. [root@paris][/]-> su - tioadmin $ $TIO_HOME/tools/tioStatus.sh 2006-09-06 15:52:55,254 INFO log4j configureAndWatch is started with configuration file: ///opt/ibm/tivoli/tpm/config/log4j-util.prop COPCOM469I Usage: tioStatus.cmd/sh [wasadmin_username] [wasadmin_password] This script requires an administrative WebSphere Application Server user and password to run. By default, the username and password are set to wasadmin at installation time. $ $TIO_HOME/tools/tioStatus.sh wasadmin wasadmin ADMU0116I: Tool information is being logged in file /opt/ibm/tivoli/tpm/tioprofile/logs/server1/serverStatus.log ADMU0128I: Starting tool with the tioprofile profile ADMU0500I: Retrieving server status for server1 ADMU0509I: The Application Server "server1" cannot be reached. It appears to be stopped. To start the Tivoli Provisioning Manager, use the provided tio.sh script. This script accept start and stop as parameters. The start does not require any authentication, while the stop requires the administrative WebSphere Application Server user and password as detailed above for the tioStatus.sh script. $ $TIO_HOME/tools/tio.sh start This will take a few moments... Starting WSWB Help System... Starting WAS on server1... ADMU0116I: Tool information is being logged in file /opt/ibm/tivoli/tpm/tioprofile/logs/server1/startServer.log ADMU0128I: Starting tool with the tioprofile profile ADMU3100I: Reading configuration for server: server1 ADMU3200I: Server launched. Waiting for initialization status. ADMU3000I: Server server1 open for e-business; process id is 753724 Starting Deployment Engine...
117
Starting Soap service... Starting Policy Engine... Starting Agent Shell Server... Starting DMS Result Server... TIO startup completed. Check /usr/ibm/tivoli/common/COP/logs for startup errors. 2. Now that the product is started you can open the GUI connecting to the following url: https://TPM_SVR_hostname.mydivision.mycompany.com:9045/tcWebUI In the example described in this redbook the url is: https://paris.itsc.austin.ibm.com:9045/tcWebUI You can also the following alternatives: ip address of the Tivoli Provisioning Manager server localhost or 127.0.0.1 if you use the browser page directly on the Tivoli Provisioning Manager server. 3. The first time you connect you will be asked to accept a digital certificate as shown in Figure 3-32 on page 118.
Figure 3-32 Digital certificate
4. Click Yes and the Log On web page in Figure 3-33 on page 119 is shown.
118
Figure 3-33 Log On page to IBM Tivoli Provisioning Manager
5. Enter your logon user ID and password. The default user ID and password are set to tioappadmin. 6. Click Log On. The following Web page is shown:
119
Figure 3-34 Welcome page to IBM Tivoli Provisioning Manager
7. You can now start using the product.
3.5 Unattended installation on Linux

In this section we describe the steps to perform an unattended or silent installation on a Linux platform. For the scope of this section, we used a Red Hat Enterprise Linux AS release 4 (Nahant Update 4) to describe an enterprise local installation, without any prerequisite software installed.
120
3.5.1 Hardware and software requirements for the Topology Installer Launcher
With the Tivoli Provisioning Manager for Software V5.1, a remote installation is also supported. This allows you to run the TIL on a separate machine than the Tivoli Provisioning Manager server target machine. Note: Remote installation feature is expected to be available also for the Tivoli Provisioning Manager V5.1 in a future fixpack. Table 3-12 on page 121 details the requirements for the Topology Installer Launcher:
Table 3-12 Hardware and software requirements for the Topology Installer Operating System Linux on Intel SLES 9 RedHat 4.0 Server type 32 bit IBM compatible PC Processor speed 2.8 GHz Intel Pentium 4 processor or equivalent Minimum free disk space 7 GB in the /var file system 2 GB in the / file system RAM Minimum 2 GB
Note: The above requirements assume that you are using a CD media to perform the installation. In this case the TIL will use the /var directory to copy and uncompress the images before install them. If you are using a local file repository, you must grant at least 5 GB of free disk space for /var file system. There are some additional requirements for the Topology Installer Launcher machine: Ping localhost Verify that you can successfully run the command ping localhost on the computer. The file /etc/hosts must include the IP address 127.0.0.1 for localhost and the correct IP address and host name for the computer where you are running the installer. The following example shows settings for localhost and a computer with the host name tpm.example.com 10.0.0.12 tpm.example.com 127.0.0.1 localhost
121
KDE If you are installing on a RedHat computer, use the K Desktop Environment (KDE) to run the installer. Gnome, the default desktop environment for RedHat, is not supported. For information about KDE, see http://www.kde.org/ Firefox Firefox 1.5 or later must be installed to view online help in the installer. Expect Expect 5.34 or later is required on the computer where you are running the installer. Ensure that the required packages are installed: Expect 5.34 or later tcl tk The Expect files should be located in /usr/bin. Ensure that /usr/bin is in the PATH variable. X Window System connections If you are running the installer on a UNIX or Linux computer, but you want to remotely run the installation using an X session from a Windows computer, verify that the X application supports display of the topology installer: The Cygwin X server does not support display of the installer. Exceed can be used for an X session, but it does not support display of double-byte characters. If you need to run the installer in a language with double-byte characters, you must perform the installation on a local computer. If the DISPLAY variable is exported to an Exceed X window server, to install Tivoli Provisioning Manager, the label and the progress bar of the first product being installed, disappears, when the installation is started. After the first product is installed, the progress bar is displayed again, but the label will not appear.
3.5.2 Hardware requirements for Tivoli Provisioning Manager server machine

For a successful installation, ensure that you meet the disk space and memory requirements for the computer where you are installing Tivoli Provisioning Manager as detailed in Table 3-3 on page 69
122
Table 3-13 Hardware requirements for Tivoli Provisioning Manager Operating System Linux on Intel SLES 9 RedHat 4.0 Server type 32 bit IBM compatible PC Processor speed 2.8 GHz Intel Pentium 4 processor or equivalent RAM Minimum 4 GB of free memory Free disk space Refers to Table 3-14 on page 123 for details
Table 3-4 on page 69 lists the disk space requirement for the prerequisite software:
Table 3-14 Disk space requirements for the prerequisite software Component Default installation path Minimum required disk space in MB 1600
DB2 Universal Database Enterprise Server Edition server DB2 Universal Database Enterprise Server Edition instance owner Tivoli Directory Server Tivoli Directory Server instance owner WebSphere Application Server Tivoli Provisioning Manager Temporary space
/opt/IBM/db2/V8.1
/home/db2inst1
2500
/opt/ibm/ldap/V6.0 /home/ldapinst /opt/IBM/WebSphere/AppServer /opt/ibm/tivoli/tpm /
2000 100 2000 5000 2000
Important: For all Linux, AIX and Solaris systems, ensure that the /tmp folder is not owned by root.
3.5.3 Software requirements for Tivoli Provisioning Manager

Tivoli Provisioning Manager requires a number of supporting software applications to be installed. For managing servers or server upon which Tivoli Provisioning Manager is installed, the following software is required.
123
Operating System
The following Operating System versions are supported for the installation: Red Hat Advanced Server 4.0 32 Bit with Update 3 To verify the version, run the following command: cat /etc/redhat-release The output should look like the following example: Red Hat Enterprise Linux AS release 4 (Nahant Update 3) SUSE LINUX Server 9, Enterprise Edition 32 Bit with SP3. To verify the version, run the following command: cat /etc/SuSE-release For Linux Enterprise Server 9 systems on Intel, the output should look like the following example: SUSE LINUX Enterprise Server 9 (i586) VERSION = 9 PATCHLEVEL = 3 Note: Verify the kernel version, using the command, uname- r. The command uname -r outputs the version number of your linux kernel. This is useful to determine the kernel version when you need to use the required DB2 images, if you are using DB2 as the database server.
Prerequisite software
Example 3-5 on page 71 shows the supported version of prerequisite applications.
Table 3-15 Prerequisite software Required software Database Application server Supported applications DB2 Universal Database Enterprise Server Edition 8.2, Fix Pack 11 WebSphere Application Server 6.0, Fix Pack 2 with latest interim fix. In case you plan to use an existing user account on an existing directory server with Tivoli Provisioning Manager, user IDs cannot contain double-byte characters. Directory server Tivoli Directory Server 6.0, Fix Pack 1
124
Required software Web browser
Supported applications The computer you are using to access the Web interface must be on the same network as the provisioning server. Microsoft Internet Explorer 6.0.29 or later. You must use a full installation of Internet Explorer with Internet Tools with the latest critical security updates from Microsoft. Firefox 1.5 or later. For some Web interface features, such as setting a home page, cookies must be enabled.
3.5.4 Installing behind a firewall

If you are running a remote installation and if the management LAN where you intend to install Tivoli Provisioning Manager is protected by a firewall, some communication ports must be opened. Refer to Installing behind a firewall on page 71 for a complete list of all the ports that must be opened.
3.5.5 Preparing installation images

There are several reasons why you might want use installation images instead of CDs to perform installation: Using installation images instead of CDs can reduce installation time. If you are installing software on multiple nodes, you can store the installation images on nodes where they will be installed so that the installer does not need to copy the installation software to each target computer. If you want to perform a silent installation, you must create an image depot for the prerequisite software as well as Tivoli Provisioning Manager. The installer does not prompt for media when running silently. To create a central image depot you should perform the following steps: Create a root installation directory for the installation images. In the example we describe for this Redbook, we use /tivcode as root directory.
125
Note: Make sure that you do not name this directory disk or any other name starting with disk and you do not put any spaces in the directory names. The name you choose for the top level directory of your installation directory must be specified in the response file template. In this example it is tpmdepot. 1. Create subdirectories for each installation image. Table 3-16 on page 126 shows the required directory structure.
Table 3-16 Required directory structure for images Installation image Tivoli Provisioning Manager Installation: TPM_V51_Disk1_lin_IA32.tar Common Inventory Technology: TPM_TIO_V51_Disk2_multiplatf.tar Tivoli Provisioning Manager: TPM_V51_Disk3_lin_IA32.tar TPM_TIO_V51_Disk4_lin_IA32.tar TPM_TIO_V51_Disk5_unix.tar.gz Tivoli Provisioning Manager for Dynamic Content Delivery: CDS_V13_LIN.tar (it comes with TPM_TIO_V51_Disk6_lin_IA32.tar) Tivoli Common Agent Services: AM_V13_LIN.tar (it comes with TPM_TIO_V51_Disk6_lin_IA32.tar) Job Management Service (DMS Federator): DMS_V20_multiplatf.tar.gz (it comes with TPM_TIO_V51_Disk6_lin_IA32.tar) DB2 Universal Database Depot directory /tivcode/disk1 /tivcode/cit /tivcode/linux_intel32/tpm
/tivcode/linux_intel32/cds
/tivcode/linux_intel32/cas
/tivcode/dms
/tivcode/linux_intel32/db2 There are separate images for each supported language: ensure that you use the appropriate image. /tivcode/linux_intel32/itds60 /tivcode/linux_intel32/was
Tivoli Directory Server WebSphere Application Server
2. Copy the images to your image depot using one of the following methods:
126
Place each CD in the CD-ROM drive, and copy the images from each CD into the subdirectory that you have created. Mount the CD-ROM drive, but do not change directory to the mount point. Note: Changing directories to the mount point will lock the CD-ROM and prevent you from being able to swap CDs. You must unmount the CD-ROM before trying to eject CD. Otherwise the CD-ROM tray will be locked and you will be unable to switch to CDs of the other software prerequisites.
If you download your product from Passport Advantage refers to Example 3-2 on page 74 to extract the contents to the appropriate subdirectory. Importnant: The native UNIX tar utility does not support long file names. You must use GNU version of tar to extract the contents of a downloaded image in a .tar archive.
3.5.6 Preparing Linux systems for installation

Before start the installation you must log on as root and perform the following tasks:
Preparing RedHat Advanced Server systems

For RedHat Advanced Server 4.0, the following packages are required for successful installation of WebSphere Application Server: compat-libstdc++-33-3.2.3-47.3 compat-gcc-32-c++-3.2.3-47.3 compat-db-4.1.25-9 compat-libstdc++-296-2.96-132.7.2 compat-gcc-32-3.2.3-47.3 compat-glibc-2.3.2-95.30 compat-glibc-headers-2.3.2-95.30 You can check if the RPM is applied by typing the following command: rpm -qa | grep compat
Preparing SUSE LINUX Server 9, Enterprise Edition systems
127
On SUSE Linux Server 9, Enterprise Edition check the following: The following packages are required for successful installation of WebSphere Application Server: compat-2004.7.1-1.2.i586.rpm You can get the package from the SUSE Linux Server 9, Enterprise Edition CD (disc 1). To check if the RPM is applied type the following command: rpm -qa | grep compat Set the maximum stack size for each process to 8196 with the command: ulimit -s 8196. This is required to work around a JDK 1.4.1 SR1 issue. Set the LANG environment variable to work around an embedded messaging issue. For example, run the following command: export LANG=$LC_CTYPE The JDK used by Tivoli Provisioning Manager does not support the Native POSIX Thread Library (NPTL), the default thread mode used by SUSE Linux Server 9, Enterprise Edition. You must force the Linux threads to be used instead on all SUSE Linux Server 9, Enterprise Edition. To determine the current thread mode, run the following commands: getconf GNU_LIBPTHREAD_VERSION 2>&1 | grep NPTL For NPTL, you should get an output similar to the following example: NPTL 0.61 To force Linux threads be used instead, run the following commands: export LD_ASSUME_KERNEL=2.4.19 export RPM_FORCE_NPTL=1 Ensure that the inetd service has started. Run the following command to start the service: /usr/sbin/xinetd
Create your own file systems structure

Before you start the software installation, you can create your own file systems structure in case you do not want to use the system ones. Read carefully the instructions detailed in this section to avoid failures during the installation. Table 3-17 on page 129 shows the default path locations of the various components installed by Tivoli Provisioning Manager detailing which paths can be overwritten. Some of those are hard coded and cannot be changed.
128
Table 3-17 Default path locations for Tivoli Provisioning Manager components Product name Tivoli Provisioning Manager Tivoli Provisioning Manager repository WebSphere Application Server WebSphere Application Server instance owner DB2 UDB ESE Client DB2 UDB ESE Server Tivoli Directory Server Agent Manager Common Inventory Technology Common directory for log files Default path location /opt/ibm/tivoli/tpm /opt/ibm/tivoli/tpm/repository /opt/IBM/WebSphere/AppServer /home/ldapinst /home/db2inst1/sqllib /opt/IBM/db2/V8.1 /opt/ibm/ldap/V6.0 /opt/IBM/AgentManager /opt/tivoli/cit /opt/ibm/tivoli/common/ctgde/logs Overwrite YES YES YES NO YES NO NO NO NO NO
Note: If you create your own file systems, make sure that the mount point does not include the last directory in the path. For example, if you install IBM DB2 Version 8.2, by default it will copy the program files under /opt/IBM/db2/V8.1 and the instance owner files under /home/db2inst1/sqllib. If you plan to create a file system for the instance owner, make sure the name will be something like /home/db2inst1. Including sqllib in the mount point will cause the installation to fail: looking in the log files, you will see that the reason of the failure is an already existing installation due to the existence of the sqllib subdirectory created as part of the file systems mount point.
Install required packages

These packages are required on all the Linux computers that you are using for the installation: Expect 5.34 or later SSH, telnet and ftp protocols perl wget
129
Check the SSH status

Run the following command to check the status: /etc/init.d/sshd status The command returns an output like the following: sshd (pid xxxx) is running... if SSH is started. If it is not started, run the following command: /etc/init.d/sshd
Verify script location

The location of the shells or script interpreters is important because the scripts called by the installer include this information on the first line of the script. Make sure the following packages are installed in the below locations as these are the locations that the Tivoli Provisioning Manager installer would look in, during the installation, when checking for prerequisites: Bash location /usr/bin Expect Location /usr/bin/expect
Verify umask settings

Set the umask to 0002 for the Tivoli Provisioning Manager files to be installed with the correct permissions for operations. The umask command is what the system uses to determine the permissions that new files will receive when they are created. It is a shell command and is not a shell variable so it does not show up when the env command is run. Running the umask command shows you the current umask setting. umask 0002 is used to give all access permissions to the group and allow other users read and execute permission. You can either run the command from the same shell that will run the installation or run it in a .kshrc or similar files recalled by the .bash_profile for the root user. Note: Make sure to use the root user, or run su - if you change the current user.
Checking for a fully qualified host name

Tivoli Provisioning Manager and servers managed by Tivoli Provisioning Manager require fully qualified host names.
130
Important: For the Tivoli Provisioning Manager server you must use a static ip address. Some machines might be configured to return a short host name, such as city instead of a fully qualified host name, such as city.myorg.mycompany.com. The default domain name search order is as follows: 1. Domain Name System (DNS) server 2. Network Information Service (NIS) 3. Local /etc/hosts file If the /etc/resolv.conf file does not exist, the /etc/hosts file is used. If only the /etc/hosts file is used, the fully qualified computer name must be the first one that is listed after the IP address. Verify that the /etc/resolv.conf file exists and contains the appropriate information, such as: domain mydivision.mycompany.com nameserver www.xxx.yyy.zzz If NIS is installed, the /etc/irs.conf file overrides the system default. It contains the following information: hosts = bind,local The /etc/netsvc.conf file, if it exists, overrides the /etc/irs.conf file and the system default. It contains the following information: hosts = bind,local If the NSORDER environment variable is set, it overrides all of the preceding files. It contains the following information: export NSORDER=bind,local
Modify the prompt of the Tivoli Provisioning Manager machine

Modify the prompt on the machine where you plan to install the Tivoli Provisioning Manager server software, to end in one of the following three prompt: 1. $ 2. #
131
3. > You can make this change in the default .bash_profile of the root user setting a variable as shown below: PS1="[`whoami`@`hostname`][\$PWD]-> " export PS1 Logout and login to make the change permanent on each shell you open, or execute again the .bash_profile from the current shell running this command from the /root directory: . ./.bash_profile The prompt now looks like the following: [root@paris][/root]->
WebSphere Application Server

During installation, the default WebSphere Application Server ports 9080, 9061 and 9443 are used to create the WebSphere Application Server profile for Tivoli Provisioning Manager. These ports must be available on the computer where you are installing Tivoli Provisioning Manager.
3.5.7 Before you begin the installation

The installation process allows you to preinstall the prerequisite software on the target system for your Tivoli Provisioning Manager installation. If you do that, make sure that the following requirements are met before you begin the installation process: 1. Ensure that the target computers for the installation meet all the requirements described in 3.5.2, Hardware requirements for Tivoli Provisioning Manager server machine on page 122 and 3.5.3, Software requirements for Tivoli Provisioning Manager on page 123. 2. Close all programs so that the installation program can update files as required. 3. If Tivoli Directory Server is preinstalled, ensure that the Tivoli Directory Server database instance, that you had created while configuring the Tivoli Directory Server database, is started. To check the status of the Tivoli Directory Server, run the following command:
132
ibmdirctl -D cn=root -w password status where password is the password for the cn=root Ensure that the port 389 is free before running the TIL. 4. If you are using Red Hat Advanced Server 4.0, you must change the configuration setting in the /etc/hosts file. Following is an example of how the /etc/hosts file should look: IPAddress Hostname 127.0.0.1 localhost 5. If you have manually installed the WebSphere Application Server 6.0, then you must stop the WebSphere Application Server 6.0 profile before you can begin the installation. Stopping the profile will allow Agent Manager to be able to configure the SSL on WebSphere Application Server 6.0.
3.5.8 Performing a silent installation step by step

Silent installation provides you with the ability to predefine installation options in a template response file. You can then run the installation without being prompted to specify additional information. Silent installation is also useful for installing the same configuration on multiple computers.
Response file
A response file is an XML file with predefined settings for the installation. During a silent installation the installer reads the necessary input from the response file at run time while performing a silent installation. You can use of these two methods to create a response file: 1. create a response file with the installer. In this case you run the installer in record mode and save the options that you select in a response file. 2. create a response file from a template. In this case you copy a response file template that you saved while running the installation in record mode, and customize it for your installation. This option is useful if you do not want to run the installer in record mode or if you are working on computer that does not have a graphics card. For the scope of this section we describe a response file creation with the installer.
Creating a response file with the installer

You can run the installer in record mode to select your installation options.
133
When running in record mode, the installer saves your installation options instead of performing the installation. Follow these steps to create the response file: 1. Create a /tivcode/cit directory and copy the CIT installation image (.gz file) for the operating system you are running. Example 3-11 on page 134 shows the content of the directory used for this installation:
Example 3-11 /tivcode/cit directory content
[root@prov005][/tivcode/cit]-> ls -la total 92216 drwxr-xr-x 2 root root 4096 Sep 20 09:25 . drwxr-xr-x 7 root root 4096 Sep 20 09:24 .. -rwxr-x--- 1 root root 94306931 Sep 20 09:25 CIT_V22_LIN_IA32.tar.gz 2. Start the installation in record mode with the following command from the install_repository/disk1 directory: ./setuplinux.bin -W options.record=True -W options.file="path_and_file_name" where path_and_file_name represents the destination directory and file name for the response file. Example 3-12 on page 134 shows the installation invocation in record mode in our environment:
Example 3-12 Installation invocation in record mode
From the /tivcode/disk1 run the following commands: [root@prov005][/tivcode/disk1]-> ls -la total 46756 drwxr-xr-x 15 root root 4096 Aug 16 drwxr-xr-x 6 root root 4096 Aug 17 drwxr-xr-x 2 1000 1000 4096 Jul 24 drwxr-xr-x 9 1000 1000 4096 Jul 24 drwxr-xr-x 2 1000 1000 4096 Jul 24 drwxr-xr-x 3 1000 1000 4096 Jul 24 drwxr-xr-x 2 1000 1000 4096 Jul 24 drwxr-xr-x 2 1000 1000 4096 Jul 24 drwxr-xr-x 2 1000 1000 4096 Jul 24 drwxr-xr-x 2 1000 1000 4096 Jul 24 drwxr-xr-x 2 1000 1000 4096 Jul 24 -rw-r--r-1 1000 1000 12 Jul 24 -rw-r--r-1 1000 1000 11 Jul 24 drwxr-xr-x 2 1000 1000 4096 Jul 24 -rwxr-x--1 root root 7204 Jul 25
18:38 14:48 17:04 17:04 17:04 17:04 17:04 17:04 17:04 17:04 17:04 17:04 17:04 17:04 19:09
. .. apde bin de eclipse es fr it ja ko media.inf product.properties pt_BR rembo.key
134
drwxr-xr-x 3 1000 1000 4096 Jul 24 17:04 setup -rw-r--r-1 1000 1000 8416410 Jul 24 17:04 setup.jar -rwxr-xr-x 1 1000 1000 38627328 Jul 24 17:04 setuplinux.bin -rw-r--r-1 1000 1000 603776 Jul 24 17:04 splash.bmp drwxr-xr-x 2 1000 1000 4096 Jul 24 17:04 zh_CN drwxr-xr-x 2 1000 1000 4096 Jul 24 17:04 zh_TW [root@prov005][/tivcode/disk1]-> ./setuplinux.bin -W options.record="True" -W options.file="/root/fab/tpm_full_install_sept_22.xml" This command will record the installation options in the /root/fab/tpm_full_install_sept_22.xml file. The following operations take place: The installer writes the following information in the shell that started the installation: Initializing InstallShield Wizard........ Extracting Bundled JRE. Installing Bundled JRE. Veryfing JVM Launching InstallShield Wizard........ The splash screen in Figure 3-35 on page 135 is shown:
Figure 3-35 Preparing the environment splash screen
This splash screen is shown for all the time needed to install the Topology Installer Launcher. Depending on the machine you are using for the installation, this phase can last between 15 and 25 minutes. When the TIL installation compltesed, you receive another splash screen with the product name and the main installation dialog opens. The screens for the AIX or Linux installation are exactly the same. Refers to the section Starting the Tivoli Provisioning Manager wizard on page 88 that details all the screenshots. Disk 2 selection:
135
Note: When you are prompted to insert the Tivoli Provisioning Manager and Intelligent Orchestrator, Version 5.1, Disk 2, select the Path radio button and specify: /tivcode/cit The installation continues installing the Common Inventory Technology. Location of the images When the dialog Specify the location of the images required for the installation appears, specify a Root directory for the images. For our environment we specified: /tivcode. 3. Once all the options have been specified click Finish. The TIL is closed, uninstalled and the response file is generated. Wait until TIL is uninstalled (make sure $TIL_HOME is empty). The dialog in Figure 3-36 on page 136 is shown:
Figure 3-36 Installation is now complete
Sample response file

The response file you create, works only against the exact machine and the machines exact status when you created it. If you want it to work for other machines, or the same machine with the prerequisite software installed, you need to edit your response file or run TIL again in record mode against that machine. Example 3-13 on page 137 shows the response file used in our environment. This response file install all the prerequisite software and the Tivoli Provisioning Manager on a Red Hat Enterprise Linux AS release 4 (on Intel) machine.
136
Example 3-13 Response file used for the installation.
<?xml version="1.0" encoding="UTF-8"?> <section name="default"> <section name="ServersConfigurationStep"> <section name="TPMServer"> <item key="ConfirmPassword" value="1Xjj/8nbd0A="/> </section> </section> <section name="TopologyStep"> <item key="one-node" value="true"/> <item key="two-node-a" value="false"/> </section> <section name="LDAPServer"> <item key="Password" value="1Xjj/8nbd0A="/> <item key="Hostname" value="prov005.itsc.austin.ibm.com"/> <item key="Username" value="root"/> <section name="Platform"> <item key="0" value="linux"/> <item key="1" value="Red Hat Enterprise Linux AS release 4 (on Intel)"/> </section> <section name="LDAPType"> <item key="0" value="ibmds"/> <item key="1" value="Tivoli Directory Server"/> </section> <section name="IPAddress"> <item key="0" value="null"/> <item key="1" value="9.3.5.25"/> </section> </section> <section name="ConfigurationStep"> <section name="ConfigurationNodeTPM"> <section name="ConfigurationITDS"> <item key="itds-admin-password" value="1Xjj/8nbd0A="/> <item key="itds-admin-confirm-password" value="1Xjj/8nbd0A="/> <item key="itds-port" value="389"/> <item key="itds-db-directory" value="/home/ldapinst"/> <item key="itds-db2-instance-userpassword-confirm" value="1Xjj/8nbd0A="/> <item key="itds-db2-instance-username" value="ldapinst"/> <item key="itds-admin" value="cn=root"/> <item key="itds-directory" value="/opt/ibm/ldap/V6.0"/> <item key="itds-database-name" value="ldapdb"/>
137
<item key="itds-db2-instance-userpassword" value="1Xjj/8nbd0A="/> </section> <section name="ConfigurationAM"> <item key="am-manager-password" value="1Xjj/8nbd0A="/> <item key="cds-admin-user" value="tioappadmin"/> <item key="am-public-port" value="9513"/> <item key="am-secure-port" value="9512"/> <item key="am-registration-port" value="9511"/> <item key="am-registration-password" value="1Xjj/8nbd0A="/> </section> <section name="ConfigurationTPM"> <item key="admin-host-port" value="9060"/> <item key="tpm-itds-hostname" value="prov005.itsc.austin.ibm.com"/> <item key="tpm-itds-adminuser" value="cn=root"/> <item key="tpm-language-pack" value="false"/> <item key="tpm-confirm-password" value="1Xjj/8nbd0A="/> <item key="tpm-db2-install-dir" value="/home/db2inst1/sqllib"/> <item key="default-client-secure-port" value="9046"/> <item key="tpm-password" value="1Xjj/8nbd0A="/> <item key="tpm-db2-fence-userpassword" value="1Xjj/8nbd0A="/> <item key="tpm-itds-adminpasswd" value="1Xjj/8nbd0A="/> <item key="sib-port" value="7276"/> <item key="tpm-db2-port" value="50000"/> <item key="default-host-port" value="9082"/> <item key="tpm-itds-install-dir" value="/opt/ibm/ldap/V6.0"/> <item key="tpm-db2-instance-groupname" value="db2iadm1"/> <item key="tpm-was-dnssuffix" value="itsc.austin.ibm.com"/> <item key="tpm-repository-directory" value="/opt/ibm/tivoli/tpm/repository"/> <item key="tpm-itds-port" value="389"/> <item key="tpm-db2-adminpasswd" value="1Xjj/8nbd0A="/> <item key="tpm-db2-adminuser" value="db2inst1"/> <item key="soap-connector-port" value="8880"/> <item key="tpm-db2-fence-username" value="db2fnst1"/> <item key="tpm-was-installation-dir" value="/opt/IBM/WebSphere/AppServer"/> <item key="sib-mq-port" value="5558"/> <item key="tpm-db2-userpassword" value=""/> <item key="tpm-db2-name" value="tc"/> <item key="dcs-unicast-port" value="9353"/>
138
<item key="tpm-db2-hostname" value="prov005.itsc.austin.ibm.com"/> <item key="bootstrap-port" value="2809"/> <item key="admin-host-secure-port" value="9043"/> <item key="orb-listener-port" value="9100"/> <item key="tpm-directory" value="/opt/ibm/tivoli/tpm"/> <item key="tpm-itds-basedn" value="dc=ibm,dc=com"/> <item key="sib-mq-secure-port" value="5578"/> <item key="sib-secure-port" value="7286"/> <item key="tpm-db2-fence-groupname" value="db2fadm1"/> <item key="sas-ssl-serverauth-listener-port" value="9401"/> <item key="csiv-ssl-serverauth-listener-port" value="9403"/> <item key="tpm-db2-user" value=""/> <item key="default-host-secure-port" value="9045"/> <item key="csiv-ssl-mutualauth-listener-port" value="9402"/> <section name="tpm-management-ip"> <item key="0" value="null"/> <item key="1" value="9.3.5.25"/> </section> </section> <section name="ConfigurationWAS"> <item key="was-directory" value="/opt/IBM/WebSphere/AppServer"/> </section> <section name="ConfigurationDB2"> <item key="db2-instance-userpassword" value="1Xjj/8nbd0A="/> <item key="db2-instance-username" value="db2inst1"/> <item key="db2-fence-username" value="db2fnst1"/> <item key="db2-instance-port" value="50000"/> <item key="db2-instance-groupname" value="db2iadm1"/> <item key="db2-fence-groupname" value="db2fadm1"/> <item key="db2-fence-userpassword" value="1Xjj/8nbd0A="/> <item key="db2-directory" value="/opt/IBM/db2/V8.1"/> <section name="db2-install-locale"> <item key="0" value="en"/> <item key="1" value="English"/> </section> </section> </section> </section> <section name="TPMServer"> <item key="Password" value="1Xjj/8nbd0A="/>
139
<item key="Hostname" value="prov005.itsc.austin.ibm.com"/> <item key="Username" value="root"/> <section name="ASType"> <item key="0" value="websphere"/> <item key="1" value="IBM WebSphere Application Server V6"/> </section> <section name="Platform"> <item key="0" value="linux"/> <item key="1" value="Red Hat Enterprise Linux AS release 4 (on Intel)"/> </section> <section name="IPAddress"> <item key="0" value="null"/> <item key="1" value="9.3.5.25"/> </section> </section> <section name="ServerValidationStep"> <section name="TPMServerValidations"> <section name="tpm-software-validation-results"> <item key="2" value="$4{DB2 Universal Database Enterprise Server Edition}$4{db2}$3{false}$3{true}$3{false}$3{true}$3{false}"/> <item key="0" value="$4{IBM WebSphere Application Server V6}$4{websphere}$3{false}$3{true}$3{false}$3{true}$3{false}"/> <item key="1" value="$4{Tivoli Directory Server}$4{ibmds}$3{false}$3{true}$3{false}$3{true}$3{false}"/> </section> <section name="tpm-server-validation-results"> <item key="2" value="$4{Physical memory available}$3{false}"/> <item key="0" value="$4{Credentials}$3{true}"/> <item key="1" value="$4{Administrator privileges}$3{true}"/> </section> </section> </section> <section name="ExitStep"> </section> <section name="LicenseAgreementStep"> <item key="disagree" value="false"/> <item key="agree" value="true"/> </section> <section name="WelcomeStep"> </section> <section name="SummaryStep"> </section>
140
<section name="LocalSystemInfoStep"> <item key="local-system-username" value="root"/> <item key="local-system-password" value="1Xjj/8nbd0A="/> </section> <section name="InstallPathsValidationStep"> <section name="TPMServerValidations"> </section> </section> <section name="InstallBinariesStep"> <item key="was-fp2-binaries" value="/tivcode/linux_intel32/was/FP2_for_WAS_V60_lin_IA32.tar"/> <item key="dms-binaries" value="/tivcode/dms/DMS_V20_multiplatf.tar.gz"/> <item key="tpm-binaries" value="/tivcode/linux_intel32/tpm/TPM_V51_Disk3_lin_IA32.tar"/> <item key="dms-binaries-remote" value="false"/> <item key="itds-binaries" value="/tivcode/linux_intel32/itds60/ITDS_V60_lin_IA32.tar"/> <item key="itds-binaries-remote" value="false"/> <item key="root-dir" value="/tivcode"/> <item key="itds-fp-binaries" value="/tivcode/linux_intel32/itds60/FP1_for_ITDS_V60_lin_IA32.tar"/> <item key="itds-fp-binaries-remote" value="false"/> <item key="cds-binaries" value="/tivcode/linux_intel32/cds/CDS_V13_LIN.tar"/> <item key="db2-binaries-remote" value="false"/> <item key="was-fp11-binaries" value="/tivcode/linux_intel32/was/FP11_for_WAS_V60_lin_IA32.tar"/> <item key="tpm-binaries-remote" value="false"/> <item key="tpm-cd3-binaries-remote" value="false"/> <item key="tpm-cd3-binaries" value="/tivcode/linux_intel32/tpm/TPM_TIO_V51_Disk5_unix.tar.gz"/> <item key="tpm-cd2-binaries" value="/tivcode/linux_intel32/tpm/TPM_TIO_V51_Disk4_lin_IA32.tar"/> <item key="cds-binaries-remote" value="false"/> <item key="was-fp11-binaries-remote" value="false"/> <item key="db2-binaries" value="/tivcode/linux_intel32/db2/DB2_ESE_V82FP11_lin_IA32_26.tar"/> <item key="cas-binaries" value="/tivcode/linux_intel32/cas/AM_V13_LIN.tar"/> <item key="was-binaries" value="/tivcode/linux_intel32/was/WAS_V60_lin_IA32.tar.gz"/> <item key="was-fp2-binaries-remote" value="false"/> <item key="cas-binaries-remote" value="false"/> <item key="tpm-cd2-binaries-remote" value="false"/>
141
<item key="was-binaries-remote" value="false"/> </section> <section name="DatabaseServer"> <item key="Password" value="1Xjj/8nbd0A="/> <item key="Hostname" value="prov005.itsc.austin.ibm.com"/> <item key="Username" value="root"/> <section name="Platform"> <item key="0" value="linux"/> <item key="1" value="Red Hat Enterprise Linux AS release 4 (on Intel)"/> </section> <section name="DBType"> <item key="0" value="db2"/> <item key="1" value="DB2 Universal Database Enterprise Server Edition"/> </section> <section name="IPAddress"> <item key="0" value="null"/> <item key="1" value="9.3.5.25"/> </section> </section> </section>
Running a silent installation

After you have prepared the response file with the appropriate installation options, you are ready to run the silent installation. Follow these steps: 1. Log on as root on the system. Note: If you are using the su command to change to root, ensure that you run su -. 2. Start the installation in silent mode with the following command from the install_repository/disk1 directory: ./setuplinux.bin -silent -W options.file="path_and_file_name" where path_and_file_name represents the source directory and file name for the response file. Example 3-14 on page 143 shows the installation invocation in silent mode in our environment:
142
Example 3-14 Installation invocation in silent mode
From the /tivcode/disk1 directory run the following command: [root@prov005][/tivcode/disk1]-> ./setuplinux.bin -silent -W options.file="/root/fab/tpm_full_install_sept_22.xml" Note: If you do not want the TIL to be uninstalled when the installation is finished or when you cancel it, you can install it in permanent mode by launching the installer with the following command: setupaix.bin -W options.permanent=True When this option is specified, the TIL is installed in this path: /opt/TopologyInstallerLauncher unless you specify a custom path with the option: -W options.tiLocation="full_path" 3. The installer begins to install all the options that were selected in the response file. 4. When the installer returns the prompt, check the following log files to make sure the installation completed fine. tivoli_commondir/COP/logs/install/* /tmp/tclog_til/ti
3.5.9 Starting the Tivoli Provisioning Manager graphical user interface

Now that the installation is complete you can start the Web Interface. Follow the steps described in Starting the Tivoli Provisioning Manager graphical user interface on page 116.
3.6 Enterprise installation on Windows

In this section we will document the full installation on our Windows 2003 Advanced server.
143
Important: On Windows, it is not supported to run the Topology Installer Launcher (TIL) on the same system as where the Tivoli Provisioning Manager server will be installed. You need to start TIL on one system (local system hereunder) from where you install Tivoli Provisioning Manager and prerequisite software on the Tivoli Provisioning Manager server (target system hereunder). Two-node topology installation is only supported with Windows Active Directory as the directory server. We run TIL on prov002.itsc.austin.ibm.com to install Tivoli Provisioning Manager on cairo.itsc.austin.ibm.com. DB2 was already installed on the target system. While running TIL, online help is always available by clicking on the question mark in the upper right corner.
3.6.1 Pre-install Cygwin on the local and target systems

We do not have access to the Internet in our lab environment, so we need to pre-install Cygwin. 1. Cygwin is pre-installed by downloading and running the setup.exe found on http://www.cygwin.com. We performed Download Without Installing from the setup program, selecting the default packages and the additional packages needed for Tivoli Provisioning Manager as described in Appendix A of the Tivoli Provisioning Manager Version 5.1, Installation Guide Guide for Windows, SC32-2232. 2. Next, we use the option Install from Local Directory, pointing to the directory where the packages are downloaded. Install all packages found in the setup.ini file, by clicking on the Default next to the All categor, as shown in Figure 3-37 on page 145.
144
Figure 3-37 Use All packages from an already downloaded Cygwin repository
The Default text will change to Install, and all pre-loaded packages will be installed. This way we do not need to specify the Tivoli Provisioning Manager additional packages again. Important: Make sure you install Cygwin in the root directory of the C drive: C:\cygwin.
Note: Make sure that Cygwins bin directory is first in the Path of the system. Verify by right clicking on My Computer Properties Advanced Environment Variables. Check that C:\cygwin\bin is first in the Path variable of the System variables. Edit if needed. 3. After the installation of Cygwin, we create the ssh daemon service. We do this clicking on the Cygwin icon to open a Cygwin bash shell. Here we type the ssh-host-config -y command. We type the password for the sshd_server user account and leave the ntsec environment blank. 4. Next we start the Cygwin ssh daemon with net start sshd. Note: The ssh daemon must be running on the local system where TIL is running. The ssh daemon cannot be running on the target system where Tivoli Provisioning Manager is to be installed.
145
3.6.2 Install Tivoli Provisioning Manager

1. We start TIL by running the setupwin32.exe command located on the Disk 1.
Figure 3-38 Preparing
While preparing the system, TIL is extracting and configuring the Embedded Tivoli Provisioning Manager which is used to drive the installation. The files are extracted to the %TEMP% directory, usually C:\Documents and Settings\%USERNAME%\Local Settings\Temp. It may be needed to clean up all files in %TEMP% when starting TIL a second time. Important log files of TIL are %TEMP%\TopologyInstallerLauncher\workspace\.metadata\.log and %TEMP%\TopologyInstallerLauncher\logs\console.log. It can take several minutes before the next window appears:
Figure 3-39 Welcome message
146
2. Press Next and accept the Software License Agreement to get to the window where we type the local administrator user name and password of prov002.itsc.austin.ibm.com (Figure 3-40 on page 147).
Figure 3-40 Administrator user name and password
3. The credentials are verified and validated (Figure 3-41 on page 148). Press Next.
147
Figure 3-41 Local system validation
Note: If the validation fails, it could be caused by one of the following: The bin directory of Cygwin is not in the path of the System Environment before you start the installation The ssh daemon is not started on the local system The user name and password combination is not valid 4. We choose for the single server configuration as shown in Figure 3-42 on page 149. Press Next.
148
Figure 3-42 One or two node configuration installation
5. In Figure 3-43 on page 150, we are prompted for configuration data of the target system.
149
Figure 3-43 Target servers configuration data
The host name of the target system needs to be fully qualified. If it changes back to the red colored short name after you fill in the fully qualified name, you need to make sure your IP DNS resolving returns fully qualified names. The IP address is filled in automatically after you enter the host name. Note: We needed to add the fully qualified name of the system to the local host file. 6. We choose the Windows Server 2003, Standard Edition as the operating system and enter the user name and password of a valid administrator on the target system. Press Next. Again it takes some time to verify and validate the credentials and privileges on the target system. Note: Be sure the Cygwin ssh daemon service is not active on the target system or the validation will fail.
150
7. After successful validation of the user name and password, TIL will run a Common Inventory Technology (CIT) scan on the system to verify prerequisite software. For this it sends the compressed file containing the CIT scanner for the discovered operating system, in this case CIT_V22_WIN.zip. The file is located on Disk 2, so we point the installer to the directory where we copied Disk 2 (Figure 3-44 on page 151). TIL sends the file, unpacks the zip file on the target and runs a discovery on the target system.
Figure 3-44 CIT scanner on Disk 2
8. In Figure 3-45 on page 152 we see that the installer has discovered we have installed Cygwin and it found the installed DB2 Universal Database Enterprise Server but noticed it lacks correct configuration. It will install and configure the required Tivoli Directory Server and IBM Websphere Application Server. DB2 will be only be configured. We do not mind the lack of memory the wizard reports. Press Next.
151
Figure 3-45 Validation summary
9. In Figure 3-46 on page 153 we need to enter configuration data for Tivoli Provisioning Manager, WAS, DB2 and TDS. We change the destination directories, so all software will be installed in the C:\IBM directory. We type the needed passwords and fill in the DB2 parameters. Also take a look at the advanced settings to note the different ports the Websphere Application Server will utilize. We change the installation directory for WAS.
152
Figure 3-46 Tivoli Provisioning Manager configuration parameters
Note: Even if you install Tivoli Provisioning Manager in a different directory, log files will be written to the default %TIO_LOGS% location C:\Program Files\IBM\tivoli\common\COP\logs. 10.We type the LDAP administrator user password, and change the installation directory for TDS (Figure 3-48 on page 155).
153
Figure 3-47 Tivoli Provisioning Manager WAS configuration parameters
11.We type the DB2 instance, instance owner and password, use the same for the database user name and password and change the installation directory, as shown in Figure 3-49 on page 156.
154
Figure 3-48 Tivoli Provisioning Manager TDS configuration data
12.On the next tabs provided in this window (Figure 3-49 on page 156), we specify how the different components will be configured.
155
Figure 3-49 Tivoli Provisioning Manager DB2 configuration data
Important: A problem exists with the unattended installation of DB2 and instance names of 8 characters, when Terminal Server is installed on the target. If you install DB2 with TIL and Terminal Server is installed on the target, use a shorter name for the instance name, e.g. the Windows default instance name DB2, not db2inst1 proposed by TIL. 13.In the tab shown in Figure 3-50 on page 157, we type the password that will be accepted by the Agent Manager when agents register. We use the default ports.
156
Figure 3-50 Tivoli Provisioning Manager Components configuration
14.On the WebSphere Application Sevices tab, there is only the installation directory, which we change to the directory given on the Tivoli Provisioning Manager tab (Figure 3-51 on page 158).
157
Figure 3-51 WAS configuration parameters
15.On the Tivoli Directory Services tab, we change the installation directory, the TDS Administrator password and the DB2 instance user password for the instance user. We leave the database name unmodified, as shown in Figure 3-52 on page 159. Press Next.
158
Figure 3-52 TDS configuration parameters
Again a discovery is launched on the target system cairo.itsc.austin.ibm.com to verify the installation values, as shown in Figure 3-53 on page 160.
159
Figure 3-53 Parameter validation
16.Disk space requirements and write access validate OK. Press Next to continue (Figure 3-54 on page 161).
160
Figure 3-54 Parameter validation summary
161
Figure 3-55 Installation images location
We need to specify the location of the installation images. You can either use the product CDs or load the images on either the local system or the target system. We choose the local system, so TIL will send the files to the target directory. We point the root directory to C:\CID\IBM\TPM51\Installation_images, where we copied the files on beforehand. You also have the option of placing the files locally on the target system, so no file transfer will be taking place. Click the Use the installation image on the target server check-box in this case. The contents of the C:\CID\IBM\TPM51\Installation_images directory is shown in Figure 3-15 on page 162. The files must be named exactly as shown.
Example 3-15 Installation_images contents
Administrator@prov002 ~ $ cd /cygdrive/c/CID/IBM/TPM51/Installation_images/ Administrator@prov002 /cygdrive/c/CID/IBM/TPM51/Installation_images
162
$ find . . ./dms ./dms/DMS_V20_multiplatf.zip ./windows_intel32 ./windows_intel32/cas ./windows_intel32/cas/AM_V13_WIN.zip ./windows_intel32/cds ./windows_intel32/cds/CDS_V13_WIN.zip ./windows_intel32/db2 ./windows_intel32/db2/DB2_ADMCL_V82FP11_win_IA32.zip ./windows_intel32/db2/DB2_ESE_V82FP11_win_IA32.zip ./windows_intel32/itds60 ./windows_intel32/itds60/FP1_for_ITDS_V60_win_IA32.zip ./windows_intel32/itds60/ITDS_V60_win_IA32.zip ./windows_intel32/tpm ./windows_intel32/tpm/TPM_TIO_V51_Disk4_win_IA32.zip ./windows_intel32/tpm/TPM_TIO_V51_Disk5_win.zip ./windows_intel32/tpm/TPM_V51_Disk3_win_IA32.zip ./windows_intel32/was ./windows_intel32/was/FP11_for_WAS_V60_win_IA32.zip ./windows_intel32/was/FP2_for_WAS_V60_win_IA32.zip ./windows_intel32/was/WAS_V60_win_IA32.zip Administrator@prov002 /cygdrive/c/CID/IBM/TPM51/Installation_images $ 17.Press Next to come to the Summary Window as shown in Figure 3-56 on page 164.
163
Figure 3-56 Summary
18.Press Next to start the actual installation on the system. Figure 3-57 on page 165 shows instalation in progress.
164
Figure 3-57 Installation progress
19.It takes a while to install and configure all applications. You can monitor progress on the Installation Log tab, as shown in Figure 3-57 on page 165.
165
Figure 3-58 Installation log
First WAS is installed, next DB2, which in our case was already installed. WAS and DB2 are followed by TDS. Finally Tivoli Provisioning Manager and the Tivoli Provisioning Manager components Agent Manager, Content Delivery Manager and Job Management Service are installed and configured. 20.Finally TIL will show you a panel as in Figure 3-59 on page 167. Press Next.
166
Figure 3-59 Installation finished
21.Press Finish to quit TIL and logon to your newly installed Tivoli Provisioning Manager server (Figure 3-60 on page 168).
167
Figure 3-60 Installation complete
First you need to start your Tivoli Provisioning Manager server. By default Tivoli Provisioning Manager is installed as a service that is started manually. You start the service by clicking on the Start TPM shortcut icons created on the windows desktop by the installation. The shortcut will start beside Tivoli Provisioning Manager, also WAS.
Figure 3-61 Start and Stop TPM Icons
We connect with our browser over port 9045 to the tcWebUI url over the https protocol, and login with the default toiappadmin userid, typing the default password tioappadmin.
168
Figure 3-62 TPM Logon
Bookmark the page and press Log On.
169
Figure 3-63 Logged on
The user interface consists of 4 main sections : The left hand side task navigation tree. The top toolbar frame. The main content area. The expandable help on the right hand side. Familiarize yourself with the product by taking the Product Tour or some tutorials and explore the navigation tree. The Information Center can be started from this page.
3.6.3 Backup the Tivoli Provisioning Manager databases

Now is also the time to take a backup of the DCM, to have a clean database if you ever need to go back to fresh DCM. We do this by taking a backup of the TC DB2 database. For this the database can not be in use, so stop Tivoli Provisioning Manager by clicking on the Stop TPM icon. Take the backup by opening a DB2 Command Line from Start All Programs IBM DB2
170
Command Line Tools Command Window, as shown in Figure 3-16 on page 171.
Example 3-16 Backup the TC and LDAP database
C:\IBM\SQLLIB\BIN>mkdir C:\DB2BACKUP C:\IBM\SQLLIB\BIN>db2 backup database tc to C:\DB2BACKUP Backup successful. The timestamp for this backup image is : 20060823141103 C:\IBM\SQLLIB\BIN>set DB2INSTANCE=LDAPINST C:\IBM\SQLLIB\BIN>net stop ibmdiradm-ldapinst The IBM Tivoli Directory Admin Daemon V6.0 - ldapinst service is stopping.. The IBM Tivoli Directory Admin Daemon V6.0 - ldapinst service was stopped successfully.
C:\IBM\SQLLIB\BIN>net stop idsslapd-ldapinst The IBM Tivoli Directory Server Instance V6.0 - ldapinst service is stopping.. The IBM Tivoli Directory Server Instance V6.0 - ldapinst service was stopped successfully.
C:\IBM\SQLLIB\BIN>db2 backup database ldapdb to C:\DB2BACKUP Backup successful. The timestamp for this backup image is : 20060823141156
C:\IBM\SQLLIB\BIN>net start idsslapd-ldapinst The IBM Tivoli Directory Server Instance V6.0 - ldapinst service is starting... The IBM Tivoli Directory Server Instance V6.0 - ldapinst service was started successfully.
C:\IBM\SQLLIB\BIN>net start ibmdiradm-ldapinst The IBM Tivoli Directory Admin Daemon V6.0 - ldapinst service is starting.
171
The IBM Tivoli Directory Admin Daemon V6.0 - ldapinst service was started successfully.
C:\IBM\SQLLIB\BIN>dir C:\DB2BACKUP Volume in drive C is IBM_PRELOAD Volume Serial Number is 7817-F096 Directory of C:\DB2BACKUP 08/23/2006 08/23/2006 08/23/2006 08/23/2006 02:11 PM <DIR> . 02:11 PM <DIR> .. 02:11 PM <DIR> LDAPDB.0 02:11 PM <DIR> TC.0 0 File(s) 0 bytes 3 Dir(s) 14,601,027,584 bytes free
C:\IBM\SQLLIB\BIN>
Store the contents of the C:\DB2BACKUP directory in a safe place.
3.6.4 Change the default password

Do the following to change the default tioappadmin password: 1. Select System Management Manage Users in navigation tree, then click on the tioappadmin user. 2. On the User Details page of the tioappadmin user, open the properties window by clicking Edit Properties, as shown in Figure 3-64 on page 173. 3. Change the password in New Password and Confirm Password fields and press Save.
172
Figure 3-64 Change tioappadmin password
173
174
Chapter 4.
Discovery mechanism
This chapter discusses the discovery mechanism available in Tivoli Provisioning Manager 5.1. This feature provides an easy way to discover new devices and configuration changes for computers, switches, subnets, software and images. The following topics are discussed in this chapter: Introduction to discovery mechanism on page 176 Network discovery on page 176 Inventory discovery on page 194 Microsoft Active Directory discovery on page 218 Discovering external resources with discovery library reader on page 226
175
4.1 Introduction to discovery mechanism

Discovery mechanism in Tivoli Provisioning Manager provides an easy way to discover new devices and configuration changes for computers, switches, subnets, software and images.All collected data is stored in a unique database that can help manage assets across the IT infrastructure. Therefore discovery provides a way to find out when the configuration of a device or software information has changed outside Tivoli Provisioning Manager and allows to change the configuration or to synchronize the changes made in the data center model. Moreover, base network discovery is a prerequisite to manage systems and perform tasks like hardware and software inventory and software distribution. In order to update and manage hardware and software devices in your data center model, you need to periodically populate it by performing scheduled discoveries, using the discovery methods appropriate for your enterprise. Tivoli Provisioning Manager 5.1 provides the following discovery mechanisms: Tivoli Provisioning Manager network discovery Discovers devices and computers using SSH, SMB or SNMP protocols. Network discovery is a prerequisite for Inventory discovery and Tivoli common agent installation. Alternatively you can create your object in the database manually. In this chapter we will clarify the differences between available protocols. Tivoli Provisioning Manager inventory discovery Discovers hardware and software configurations and detect changes for computers. It requires the installation of Tivoli common agent on the systems to be discovered. Microsoft Active Directory Discovery Discovers computers and groups defined in Microsoft Active Directory. IBM discovery library reader Imports data from external discovery libraries to the Data Center Model.
4.2 Network discovery

Tivoli Provisioning Manager network discovery provides a fast and easily
configurable way to discover systems and network devices to be managed. It can be configured to discover systems providing single IP addresses, ranges or subnetworks. As far as SSH and SMB discoveries are concerned, you have to
176
provide an authentication method always. As far as SNMP discovery is concerned, an appropriate community is needed. Providing a discovery protocol (SSH, SMB or SNMP) together with credentials results in the creation of a Service Access Point (SAP). After the discovery is performed, SAP identifies the network protocols that is used when communicating with an asset on your network. Depending on the discovery operation that is performed on a device, multiple SAPs can be made available, each of which is used for a specific operation. SMB is the recommended method for discovering Windows systems. This method also automatically determines whether a network interface is using dynamic (DHCP) or static IP addressing. SSH is the recommended method for discovering UNIX and Linux operating systems. It can also be used to discover Windows systems, but you must specify in the configuration whether the target IP addresses are dynamic (DHCP) or static, and you need to have SSH installed and configured before performing discovery. SNMP is the recommended method for discovering networking devices. Although it can be used to discover computers as well, only SNMP credentials are created, whereas SMB and SSH create RXA credentials which provide more computer management capabilities.
4.2.1 Discovering devices using SMB

Server Message Block (SMB) discovery allows to discover Windows computers using IBM Tivoli Remote Execution and Access (RXA). It has the following
requirements: The target computers must have remote registry administration enabled and Windows XP targets must have Simple File Sharing disabled. The default hidden administrative disk shares (such as C$ or D$) are required for the proper operation of RXA. Microsoft File and Print Sharing for Microsoft Networks must be enabled for the ports to be activated. Note: The simplest way to check you are able to discover a remote system is to verify that the Tivoli Provisioning Manager server can map the C$ network drive of the target machine. If all prerequisites are met, but you are still unable to map remote drive, ensure that there are no firewall restrictions in place.
Chapter 4. Discovery mechanism
177
SMB discovered data includes host name, MAC address, IP address, NIC (network interface card), credentials for execute and copy file commands, and the OS type. The OS type will be captured as a hardware resource in the discovered object. Having the OS type allows the installation of the Tivoli common agent after discovery. Following are the steps required to perform an SMB discovery for a single system. This simple scenario has been chosen to provide a clear idea of the output you get for the discovery of each single system: 1. Create a new discovery object. After accessing the console, select Inventory in the navigation panel. Select Manage Discovery, and Discovery Configurations to access the list of the discovery configurations that are already created. Select Edit and Add Discovery Configuration as seen in Figure 4-1 to add a new one.
Figure 4-1 Adding a new discovery configuration
2. Select SMB as Discovery Method. See Figure 4-2.
178
Note: Although a standard Tivoli Provisioning Manager installation provides a set of out-of-the-box discovery object, we recommend you to create your own discovery configuration objects instead of modifying the original ones.
Figure 4-2 Selecting a discovery method
3. In the next panel specify the scope and the credentials for discovery. Scope can be provided specifying single IP addresses, ranges or subnetworks. In our example we provid a single IP address, putting a blank for the range end, as in Figure 4-3 on page 180. When discovering more than one system, you should provide credentials for all the involved ones. For instance if you are going to discover two Windows systems using the same user but different password, you need to create two different credentials providing the same user and the two passwords. Important: The system tries to connect to each IP address using each user name and password provided in the configuration parameters until it finds a user name and a password that can be used for a successful connection. This can trigger user accounts to be locked out, depending on the security policy enforced on the target machines.
179
In case you want to use a domain administrator for discovery, you need to provide it in the format user@domain. At the moment, discovery with domain user works. Because you are not able to use the RXA credentials assigned to your server, you cannot install a common agent, that is a prerequisite for discovering hardware and software and performing software distribution. This problem is expected to be fixed in Tivoli Provisioning Manager fixpack 1. Before it is fixed, it is not advisable to perform discovery using domain users.
Figure 4-3 Providing discovery scope and credentials (SAP)
180
4. Once a new configuration discovery has been created, you can just run it from the Managed Discovery window as seen in Figure 4-4.
Figure 4-4 Starting SMB discovery
5. The next panel allows to schedule discovery or to run it immediately. As soon as you click Submit, discovery starts and you are automatically directed to the Track Tasks panel (It is also accessible from the Task Management option in the navigation panel of the console). Figure 4-5 on page 182 shows the Track Task panel.
181
Figure 4-5 Tracking discovery process
With a single click on the name of the task (Figure 4-5), it is possible to access detailed information about the task that is running, such as the name of the operator that started it, the task id and the task status. 6. Double-click Request Id (Seen at the bottom of Figure 4-6 on page 183), to access the complete log for the execution of the workflow that implements the discovery task.
182
Figure 4-6 Discovery status
183
Figure 4-7 and Figure 4-8 on page 185 shows the log that appears after the successful execution of SMB discovery.
Figure 4-7 Workflow execution log
184
Figure 4-8 Workflow execution log (continued)
7. In case the discovery fails, click the status icon seen in Figure 4-9 on page 186 and select the Error option. The error code, an error message and some other details is displayed. Looking for the error code and the message in Tivoli Provisioning Manager Version 5.1 Problem Determination & Troubleshooting Guide, SC32-2236 can be helpful to understand what is happening, although some error codes can be missing or do not have meaningful explanation associated.
185
Figure 4-9 Workflow execution log for a failed discovery
Note: A successful discovery does not mean a system has been actually added to the data center model database. The status of the discovery only applies to the workflows result. If for instance the discovery is not able to access the target system due to wrong or missing credentials, you find an information message in the Workflow Execution Log about this problem but the discovery does not fail. Therefore you should always check workflow logs before looking for new data in the database. 8. Once the discovery has been successfully completed, look at the new discovered system in database by selecting Computers in the Manage Inventory menu (See Figure 4-10 on page 187). This shows the list of all discovered computers.
186
Alternatively it is possible to find only the systems detected with a specific discovery task by selecting Discovered Computers under Manage Discovery menu. Note: The value for the Operative System column in Figure 4-10 is validated only after the installation of Tivoli common agent on the system.
Figure 4-10 Discovered computers
9. Click the computer name to access the base information that is collected with SMB discovery, actually the network configuration, the MAC address and the operative system of the machine (See Figure 4-11 on page 188).
187
Figure 4-11 SMB discovered information
10.Select Credentials to look at the SAPs available for the discovered system (See Figure 4-12 on page 189). In this case we only have an RXA-Server SAP using the SMB credentials provided for discovery.
188
Figure 4-12 Service Access Point added after an SMB discovery
4.2.2 Discovering devices using SSH

Secure Shell (SSH) discovery allows to discover Windows, UNIX and Linux systems using IBM Tivoli Remote Execution Access (RXA). As a prerequisite, it requires SSH to be installed and active on the target machine. Discovered data includes host name, MAC address, IP address, NIC, SSH service access points, credentials for execute and copy file commands, and the OS type.
The steps required for discovery are similar to the ones described for SMB discovery in Discovering devices using SMB on page 177. Figure 4-13 on page 190 and Figure 4-14 on page 191 show the configuration panel for a generic SSH discovery. In this case discovery is run for a wide IP
189
address range although the credential only addresses a subset of the involved systems.
Figure 4-13 SSH discovery configuration
190
Figure 4-14 SSH Discovery Configuration (continued)
Once discovery is started, its works exactly as it worked for SMB, except for the connection protocol it uses. Note: Although SSH discovery can be used, we suggest to use always SMB for windows machines. When installing a common agent on a windows system that has been discovered with SSH, it needs to access with SMB credentials anyway. Therefore agent installation fails unless you select Credentials and provide a user name and a password to be used to access the system via SMB protocol. Therefore, try the SSH connection from the Tivoli Provisioning Manager 5.1 server to the target system before running discovery to verify that the prerequisites are met.
191
While discovering some AIX machines from our Windows 2003 server we had the following error message: Cannot authenticate to 9.3.5.73 using user name root: CTGRI0000E Could not establish a connection to the target machine with the authorization credentials that were provided. Since we were sure the credentials were right, we tried to debug the problem by running SSH command from the Tivoli Provisioning Manager 5.1 server to the failing systems. As seen in Figure 4-15, the SSH attempt was failing since it was using default user Administrator instead of root. After running ssh elpaso -l root and providing roots password the connection was successful and we were finally able to perform a successful SSH discovery.
Figure 4-15 SSH connection
4.2.3 Discovering devices using SNMP

SNMP discovery allows to discover computers, switches and routers. It needs
the SNMP agent to be installed and started on the target system. Moreover you need the right community to access the SNMP protocol on the system to be discovered. Discovering network devices goes beyond the scope of this redbook. Therefore this paragraph only give base input for an SNMP discovery configuration. The discovery mechanism is the same as SMB (See Discovering devices using SMB on page 177) and SSH (See Discovering devices using SSH on
192
page 189). You have first to create a new discovery configuration as in Figure 4-16. You need to provide the scope and the SNMP communites for the devices to discover, as shown in Figure 4-17 on page 194 and run the discovery.
Figure 4-16 SNMP discovery configuration
193
Figure 4-17 SNMP discovery configuration (continued)
4.3 Inventory discovery

Inventory discovery allows to collect information about hardware and software
configuration for both data center systems and managed workstations. Software discovery can be based on registry or on signature definitions. Custom software inventories can be performed defining new signatures based on files or registry keys. Tivoli common agent is a prerequisites for any inventory discovery task. The inventory mechanism is based on IBM Common Inventory Technology 2.2 that is part of the Tivoli common agent installation. Figure 4-18 compared to Figure 4-12 on page 189 shows the changes occurred to the Credentials tab after Tivoli common agent installation. All new operations on the managed systems are now performed using the Agent-Server SAP instead of the RXA-Server. This means the agent is managed now with an SSL protocol and a key authentication that is not dependent on the user and the
194
password provided in the SMB discovery. More information about Tivoli common agent installation and configuration is provided inChapter 6, Common Agent Services on page 307.
Figure 4-18 Service access points after Tivoli common agent installation
Figure 4-19 shows the mains steps for a complete inventory task.
1. Install Common Agent 4. Update changes based on the policy 3.Get discovered data
2.Start an initial scan
Tivoli Provisioning Manager Server
Discovered Server and Resources
Figure 4-19 Base Inventory mechanism
Following are the steps for a complete inventory task: 1. Install a Tivoli common agent on the system to be managed.
195
2. When the Tivoli common agent is installed, an inventory discovery is run or scheduled. As a consequence of discovery start, the following steps are executed on the agent: a. A configuration file containing the definition of the discovery steps to be run (Discovery Configuration Profile) is pushed to the agent. b. In case it is needed also a Software Signature File, containing definition of softwares to be discovered, is sent to the endpoint. c. The inventory scan collects data, based on configuration files. 3. After data have been collected, it is ready to be sent back to the Tivoli Provisioning Manager server. As shown in Figure 4-20 on page 197, the following steps are executed: a. Scan results are zipped at the endpoint and sent to Tivoli Provisioning server using HTTP upload. b. ZIP files are unzipped on the server and the discovered data is passed to data center model. c. Endpoint and scan result mapping is maintained by using endpoint GUID (unique per endpoint). 4. Tivoli Provisioning Manager manages the data, based on the Discovery Policies defined for the discovery configuration that has triggered the inventory task. Based on these policies, data center model can be automatically updated with the changes, or the updates can be provided to the administrator for approval or rejection.
196
Tivoli Software
Scan
Upload Output ZIP For Endpoint 1
endpoint 1
Schedule & import resources into DCM

Upload Output ZIP For Endpoint 2
Scan
network network
endpoint2
TPM Server
DCM
Upload Output ZIP For Endpoint n
Scan
endpoint n
Tivoli Configuration, Provisioning and Orchestration | IBM Confidential | March 20, 2007
Figure 4-20 Fan-in mechanism
The scenarios described in the following paragraphs go deep in hardware and software discovery, providing best practices about managing custom signatures and handling changes with discovery policies.
4.3.1 Configuring and running inventory scans

This paragraph describes a base inventory scenario, involving both hardware and software discovery.
Inventory scenario
As for network, inventory discovery requires the definition of a new discovery configuration as in Figure 4-21.
197
Figure 4-21 Inventory discovery configuration
The panel in Figure 4-22 on page 199 allows to define the specific discovery to be run on the agent. Note: Although the first panel of discovery configuration in Figure 4-21 allows to choose between Devices and Software, the actual choice between hardware and software discovery is performed in the next panel as shown in Figure 4-22 on page 199. Software discovery can be performed also if you select Devices as seen in Figure 4-21.
198
Figure 4-22 Inventory discover configuration (continued)
In this scenario we are going to perform both hardware and software discovery, the last one based on software signatures. The available options for software discovery configuration are: Registries In this case the inventory mechanism discovers software based on the specific registry entries found on the system. Software signatures They are actually definitions of software to be discovered based on files found on target systems or on specific registry keys. In the simplest case, a signature only defines the name and size of a file (in bytes). Software inventory discovers that a software is installed on an agent if it finds at least one file whose characteristics match the ones contained for that software in the software signature list. Software signatures are contained in the Tivoli Provisioning Manager database and can be updated manually or importing them from specific xml files. Further information about software signatures is provided in 4.3.2, Custom software signatures on page 212. Selected signatures This option allows to perform a lighter discovery, selecting only the signatures for which discovery searches a match on the target system. When running an inventory discovery you are prompted for the target systems to be scanned. In the real world you probably run an inventory discovery on
199
groups containing target systems according to your organization. In order to show the steps occurring on each systems, this scenario takes in consideration the discovery of a single machine. Note: When performing an inventory discovery on a group of computers, the performance of the task is impacted by the Concurrency Level parameter. This value determines the number of parallel deployments that are permitted within a task. By default, the Concurrency Level is set to 1, that means Tivoli Provisioning Manager performs one inventory discovery at a time. If you want to run parallel inventory tasks on multiple targets, you need to change this value. Figure 4-23 shows how to change this parameter at a global level. This change impacts any task (software distribution, patch management, inventory) that is run in a Tivoli Provisioning Manager environment, and therefore it has to be set carefully. Alternatively you can change it only for a specific inventory task, but in this case you need to schedule it first. Once it is scheduled, you can just click on the icon on the right of the scheduled task, available in Task Management Track Tasks. Select Properties and specify a different concurrency level.
Figure 4-23 Changing concurrency level value
200
In Figure 4-24 we selected By Computer under Display and choose the system London that has already been target of hardware discovery and agent installation. We clicked Submit to start discovery immediately. In the real world you might want to schedule discovery to run periodically so that systems configuration is always consistent with data center model database.
Figure 4-24 Starting an inventory discovery
As for network discovery, Tivoli Provisioning Manager allows to track the state of the inventory task looking at the workflow log. In the following of this paragraph the workflow log allows to clarify all the steps involved in an inventory scan. The highlighted line in Figure 4-25 on page 202 shows the name of the discovery configuration file that inventory is going to create according to the configuration provided in Figure 4-22 on page 199. This file, shown in Figure 4-26 on page 202, is sent to the agent.
201
Figure 4-25 Workflow log
Features for which the property-value is true (See Figure 4-26) are the ones to be run on the target.
Figure 4-26 Discovery profile
202
Second line in Figure 4-25 on page 202 also shows that, in case the discovery configuration contains a software signature scan, the task looks for any Software Signature Files that have been cached on the agent during previous discoveries. Because data center model maintains history about the last Discovery Configuration Profiles, and therefore each Software Signature File sent to each agent, the new software signature file is downloaded in case it has been updated from last scan. Note: During our tests, we noticed that even when software signature scan is not selected, workflow log always perform the software signature files check. This has been recognized as a problem and is addressed in next fixes. Figure 4-27 shows the software signature mechanism.
Software Signature File (Windows) Discovery Configuration
endpoint 1 (Windows)
Create/
TPM Discovery Configuration UI
Modify
Software Signature File
network network
Software Signature File (Linux) Software Signature File (AIX)
Update Discovery Profile Change flag for endpoint
endpoint 2 (Linux)
Discovery ID
Endpoint ID
Profile Type ID
Updated
2346 2346 2346
1230 1241 1252
1 1 1
true true true

endpoint 3 (AIX)
Figure 4-27 Software signature mechanism
After the scan is finished, the output is saved in a xml file on the agent and is zipped and copied on the Tivoli Provisioning Manager server. See the workflow log in Figure 4-28 on page 204.
203
Finally, if change policies for the discovery configuration are to update database, new data is copied to the data center model as shown in the highlighted line in Figure 4-29 on page 205.
204
Configurations affecting scan duration

In the analyzed example, the inventory scan starts as soon as you click Submit. This is the default behavior if there is no SOA-SAP Service Access Point defined for the managed system. A SOA-SAP Service Access Point is required on all computers targeted for software distribution. Workflow Create_SOA_Endpoint_Operation_SAP assigns this Service Access Point to the endpoint-operations device operation. Figure 4-30 shows the content of Credentials tab for a managed system after the workflow is run. After the workflow is executed all endpoint-operations device operations is executed using the Service Oriented Architecture infrastructure. Although this infrastructure in Tivoli Provisioning Manager is specifically required for software distribution activities, also inventory scans uses it if the SOA-SAP Service Access Point is created. See Chapter 5, Software management in Tivoli Provisioning Manager V5.1 on page 235 for more information about SOA-SAP and Service Oriented Architecture for software distribution.
205
Figure 4-30 Service Access Point added for software distribution operations
As a consequence of this SOA infrastructure, when you submit the scan, it is submitted as a job at the Device Management Service Federator level, and is therefore affected by two different polling intervals: TCA-subagent JES polling interval The Java Execution Service sub-agent on the managed system polls the Device Management Service Federating Agent component on Tivoli Provisioning Manager server for new jobs with a specific polling interval (at the time of writing the default interval is set to one hour plus a random time of between 0 and 5 minutes). Device Management Service Federator synchronization interval. The Device Management Service Federating Agent and Device Management Service Federator synchronizes periodically with a different time interval (default value 10 minutes). If you do not change the default values, the scan can take up to 75 minutes to start, that can be probably not a problem in some production environments, where scans are scheduled, but that can be useful to change in a test environment or whenever you need to access scan results as soon as possible. Of course changing these values will force jobs to scan faster, that can be desirable, but can also increase the load on Device Management Service, whose impact have to be evaluated before any change. In order to change TCA-subagent JES polling interval, you can modify the TCA-Subagent JES software definition (that you can access selecting Software
206
Management and Install in Tivoli Provisioning Manager console) as shown in Figure 4-31 on page 208, before installing Tivoli common agent . Alternatively you can modify line PollingInterval=01\:00 in file /tivoli/ep/runtime/agent/subagents/jes.properties on the system where the agent is installed and restart Tivoli common agent service. As far as DMS Federator synchronization interval is concerned, you can change it by modifying the line instFederatedAgentPollFrequencyInMinutes=10 in file $TIO_HOME/DeviceManager/config/DMSconfig.properties and restart Tivoli Provisioning Manager server. In case you are working in a Fast Start installation environment, you should modify instead property WAS_DMS_FEDERATED_AGENT_POLL_INTERVAL_IN_MINUTES in file $TIO_HOME/lwi/conf/overrides/TPMconfig.properties. During the last step of inventory scan, when each agent sends results to the data center model, it can result in a significant load of network and system resources on Tivoli Provisioning Manager. This depends on the number of the system involved and on the amount of information collected on each machine. Modifying the Concurrency Level parameter provides a way to limit the number of system sending data in the same moment. Moreover, the zero-to-five-minutes random interval for JES polling interval should allow to spread inventory results in wide time intervals. Each agent in fact polls Device Management Service Federating Agent at different moments and therefore the result data should be in theory splitted in time. Note: When you submit an inventory scan on a system with a SOA-SAP Service Access Point, the task execution goes through the following states: Not Started Submitted In Progress You cannot track its behavior using the Request ID. If there is no SOA-SAP, the status is In Progress as soon as you submit the task.
207
Figure 4-31 TCA-Subagent JES configuration
Inventory results
When the discovery is successfully executed, you can access the results by double-clicking the name of the system seen under Computers. See Figure 4-10 on page 187. In the General tab for the discovered system, shown in Figure 4-32 on page 209, the Hardware Resources panel is now updated with the hardware configuration for the system. The Software tab shows the output of the software discovery. Both signature and registry discovery is shown in this panel.
208
Figure 4-32 Hardware Inventory results
In case there is a software definition associated to the discovered software in data center model, the Software Definition column shows a value (See Figure 4-33). It is also possible to associate manually discovered software to specific Software Definitions, by selecting Unidentified Software Components at the bottom of the Software tab.
209
Note: At the moment in which this redbook is being written, the output of software inventory for Tivoli Provisioning Manager for Software 5.1 is slightly different than the one shown in Figure 4-33. This discrepancy should be fixed in future patches. Figure 4-34 on page 211 shows the Software Inventory results in Tivoli Provisioning Manager for Software 5.1.
Figure 4-33 Software inventory results in Tivoli Provisioning Manager
210
Figure 4-34 Software inventory results in Tivoli Provisioning Manager for Software
Inventory logs
In case you experience problems with inventory scans, you can check file traceCIT.log on the agent in directory %ProgramFiles%\IBM\tivoli\common\CIT\logs on Windows. Check /usr/ibm/tivoli/common/CIT/logs on UNIX and Linux. You can also set a higher trace level modifying file $CA_HOME/../../../cit/config/CitTrace.properties. In our tests we changed all instances of DEBUG_MIN with DEBUG_MAX, but you may probably want to set DEBUG_MAX only for the components you are interested in. The default value for variable CA_HOME is %ProgramFiles%\Tivoli\ep\runtime\agent on Windows and /usr/tivoli/ep/runtime/agent on UNIX and Linux.
Managing IP address change

When you perform an SMB discovery for a Windows system, it automatically detects if the IP address for the network interface is static or dynamic. When you perform an SSH discovery, you must specify if network IP address for the network interface is static or dynamic.
211
If it is dynamic, a common agent polls its IP address every five minutes and, if it has changed, it sends a configuration update to the agent manager. You can change this frequency with the ipaddress.poll.timeinterval property in the endpoint.properties file. The endpoint.properties file is located on the common agent in $CA_HOME/config directory. This allows Tivoli Provisioning Manager to manage DHCP agents. If the IP address of the discovered system is static, you need to perform a new network discovery or to update manually the address in the data center model.
4.3.2 Custom software signatures

Tivoli Provisioning Manager 5.1 provides the capability to create custom signatures for software discovery. In order to access Manage Software Signature panel, select Manage Software Catalogs under Software Management and click Software Signatures. You can then add a new custom signature by selecting Edit Add Software Signature. Figure 4-35 on page 213 shows the resulting panel. In this case we defined a new software called Jade and associated it to a file jade.exe of 1195 bytes. The size of the file has to be provided in byte, as it appears in the output of dir command in a DOS windows. Whenever inventory discovery finds this file on a target system, it shows Jade for Windows 1.1 in the output of software inventory. Important: Whether the name of the file to look for is lower case or upper case, the name of the file provided in the configuration panel in Figure 4-35 on page 213 should always be upper case for the match to be successful.
212
Figure 4-35 Custom signature configuration
Click Add to add your new signature to database and Save. Note: If you start a software signature within 60 minutes of the last scan, it uses the cached value from the previous scan and you cannot find updates in database. To change this default value, open the configuration file $CA_HOME/../../../cit/bin/config.xml and modify the line <Attribute name=maxDataAge value=60 />. The default value for variable CA_HOME is %ProgramFiles%\Tivoli\ep\runtime\agent on Windows and /usr/tivoli/ep/runtime/agent on UNIX and Linux.
213
Figure 4-36 Custom signature scan
After the custom signature have been defined you can run a new software signature scan to update data center model. In this scenario we choose to run a selected signature scan, as in Figure 4-36, that allows to perform a very quick discovery limited to the file defined in the selected signature. After the scan is successful, you can check results in Software tab of the selected computer. Figure 4-37 on page 215 shows the results for the chosen signature. Alternatively to the option File Size in Figure 4-35 on page 213, that allowed us to define a signature based on file match, you can decide to configure the signature to check the existence or the content of a registry key with a mechanism similar to the file matching one. To define single signatures, you can import xml files containing signature definitions using script importSoftwareSignature.cmd (on Windows) or importSoftwareSignature.sh (on UNIX and Linux) in directory /opt/tools. The syntax to run it on Windows is importSoftwareSignature.cmd signaturefile.xml false, where signaturefile.xml should be replaced with the name of the file containing the software signature definitions.
214
Figure 4-37 Custom signature scan results
4.3.3 Change policies

Tivoli Provisioning Manager 5.1 allows to manage changes to data center model occurred as a consequence of a discovery tasks. Although it is not advisable to have a data center model not synchronized with the real world, you might need to control the updates coming from new discoveries so that they do not add objects or configuration you dont desire. The following scenario shows how to define discovery policies to track configuration changes. It is actually the same scenario described in 4.3.2, Custom software signatures on page 212. A new software signature is defined as seen in Figure 4-35 on page 213. In this case, before running a software scan on the target system, we modified the discovery configuration as shown in Figure 4-38 on page 216. We selected Add to add a new policy of type Software Definition so that every time the discovery finds a new object (New Policy box), an updated object (Update policy box) or a removed object (Remove Policy box) it uses Track Configuration Change policy. Therefore, data center model is not automatically updated, but changes are available to administrator for approval.
215
Figure 4-38 Adding a discovery policy
In Figure 4-39 we added two other policy types to track Computer changes and Third Party Software Package changes.
Figure 4-39 Adding multiple discovery policies
216
After running a software scan we did not find any update in database as expected. Selecting the Change Records tab in the discovery configuration we found that there was an update for system London, as seen in Figure 4-40.
Figure 4-40 Tracking changes
By selecting Manage Changes as in Figure 4-40, we found the updates for the system shown in Figure 4-41. In this case there is an update due to the software signature previously defined and another one due to change the free size for the partition.
217
Figure 4-41 Update changes in data center model
In order to update the data center model we selected Update DCM. Otherwise, the administrator has the option to permanently ignore the updates and they are not provided to him anymore, to perform the change manually or to ignore them only for this time. Note: If you choose to update data center model, an update task is started. By default this triggers an additional scan of the target. If you want to avoid it, you should execute the following steps: 1. Search for the workflow SetFlagToDisableRescan under Automation Workflows. 2. Select Run, and fill the DiscoveryID field with the object ID of the discovery task that collected these data. The discovery object ID is a five digit number that can be found in the Track Tasks window, flying with the mouse over the name of the desired discovery task. 3. Enter True in the DisableRescanOption field and run the workflow.
4.4 Microsoft Active Directory discovery

Tivoli Provisioning Manager 5.1 provides an out-of-the-box feature to discover the following information in a Microsoft Active Directory environment: Computers by organizational unit
218
Microsoft Active Directory groups Computer attributes such as Microsoft Active Directory domains, last logon, country code logon count, distinguished name and OS information. This allows to use Active Directory as a source to populate data center model, eliminating the manual task of recreating the same information in Tivoli Provisioning Manager. Update of data center model can therefore be driven by Active Directory synchronization, through inventory scheduling. This also allows to take advantage of the following features: Active Directory can be used as user repository by taking customers organization group machine and making them Tivoli Provisioning Manager groups with assigned Tivoli Provisioning Manager roles. Application can be distributed based on Microsoft Active Directory group to agents. Microsoft Active Directory discovery can also support advanced search. This allows customer to input LDAP query scripts and run them against the Microsoft Active Directory server. The result of the query is placed in a Tivoli Provisioning Manager group.
4.4.1 Preparing Microsoft Active Directory environment for discovery

Microsoft Active Directory discovery is fairly simple and does not have particular requirements. Anyway, while discovering Active Directory in our test environment we had some problems in retrieving data about computers and groups, although the discovery task was apparently successful. This problem has been solved enabling direct and reverse lookup between Tivoli Provisioning Server and Microsoft Active Directory Server.
4.4.2 Running Microsoft Active Directory discovery

As for previous discovery tasks, Microsoft Active Directory discovery requires the creation of a new configuration discovery object, as shown in Figure 4-42.
219
Figure 4-42 Microsoft Active Directory discovery configuration
After selecting Next you are prompted with the panel shown in Figure 4-43. Providing the right information in this panel is crucial to perform a successful discovery: Server name Although during our test we were successful both with short and with long names, we recommend to use Fully Qualified Domain Name for the name of the Active Directory server. Base distinguished name Provide a base distinguished name in Microsoft Active Directory to indicate where the discovery should start with. You might want your Active Directory administrator to help you find the right information. User ID and password Insert the name of a Microsoft Active Directory user that has read access to the given base DN in MSAD server. You should not provide the following domain name before the user name: DOMAIN\user For some reason using the user Administrator does not work as well.
220
Default access group Choose the one you prefer or leave the default. Filters Default values can be enough to perform a complete discovery. User defined search command You can define your own LDAP search query (command) and get specific MSAD resources. A typical usage of this is to define a LDAP search command to update members in a given group and run it based on the scheduler define. Filter LDAP attributes (enabled by default) Controls the discovery not to process specific LDAP attributes such as Objects ID and Object GUID. If this check box is cleared, all discovered LDAP attributes will appear in the console as computer variables. Discover groups Allows to discover groups. We suggest not to disable it. Discover organizational units Allows to discover organizational unit: we suggest to not disable it. Further filtering can be performed selecting a specific Gateway IP or subnet mask.
221
Figure 4-43 Microsoft Active Directory discovery configuration
After starting the discovery, you can monitor its behavior through workflow log as for previous discovery configurations, see Figure 4-44 on page 223. Figure 4-44 shows the log for computers discovery. During our first attempts, when reverse resolution is not set correctly, we have several apparently successful discoveries, although when trying to discovery computers, we always found the following message: MS Active Directory: Discovering computers...0 computers. Always check workflow logs before looking for results.
222
Figure 4-44 Microsoft Active Directory log: computers discovery
223
Figure 4-45 shows the organizational units discovery log.
Figure 4-45 Microsoft Active Directory log: organizations discovery
Figure 4-46 shows group discovery log.
Figure 4-46 Microsoft Active Directory log: groups discovery
224
4.4.3 Visualizing Microsoft Active Directory data

After a successful discovery, you should be able to see the new discovered systems running a search for your discovery configuration under Discovered Computers option, or just have a look at the computers list. Figure 4-47 shows the results for our Active Directory Discovery.
Figure 4-47 Active Directory discovered computer
You should also be able to see the new discovered groups under Inventory Manage Inventory Groups as seen in Figure 4-48 on page 226.
225
Figure 4-48 Active Directory discovered groups
4.5 Discovering external resources with discovery library reader

Tivoli Provisioning Manager provides a simple way to discover hardware and software in your IT infrastructure using third party vendors. In order to perform this task, Tivoli Provisioning Manager needs that the third party component is able to export discovered data to an XML file (book) that conforms to an IDML (International Development Markup Language) schema definition. Currently, the Tivoli Provisioning Manager discovery library reader follows the Common Data Model 1.9 specification. Note: Detailed information on CCMDB and Discovery Library Readers can be found in the Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery and Tracking V1.1, SG24-7264 redbook.
226
In order for Tivoli Provisioning Manager to read and consume the books, they need to be placed into a discovery repository. Tivoli Provisioning Manager maps the discovered resources in the book into the data center model. You can then import this data into the Tivoli Provisioning Manager database and use it for discovering new devices and modifying and deleting existing devices to your data center model. You can also schedule discovery to update the data center model. Figure 4-49 describes the steps involved in a discovery library reader scenario.
Figure 4-49 Discovery library reader scenario
Following steps occur during the discovery library reader scenario: 1. The adapter scans the existing IT infrastructure for hardware and software. 2. Using the adapter's scanning technology, it produces a discovery book. 3. These discovery books need to be placed into a book repository which is accessible for Tivoli Provisioning Manager to read it. 4. After discovery is run, it consumes the discovery books stored in the book repository. 5. Any changes that have been made will be updated in the data center model so that what is in the IT infrastructure is mirrored in Tivoli Provisioning Manager. In the next section, we describe a discovery library reader scenario based on data import from IBM Tivoli Change and Configuration Management Database (CCMDB).
4.5.1 Exporting the CCMDB data in IDML format

These are the steps required to export Change and Configuration Management Database data to an XML file in IDML format: 1. Detect directory where your Change and Configuration Management Database is installed ($COLLATION_HOME). It was /usr/local/CCMDB/dist in our test environment.
227
2. Edit file $COLLATION_HOME/sdk/adaptor/ibm-dl/etc/HEADER to change the sourceContactInfo attribute to http://<confignia Server>:<confignia port> (For example http://confignia.mydomain.com:9430). The original value in the set to __SOURCENAME__ . 3. Open a command line on the Change and Configuration Management DataBase server. 4. Set the environment variable to COLLATION_HOME. 5. Make sure you have the user name and password to access Change and Configuration Management Database console. 6. Execute the following command: /$COLLATION_HOME/sdk/adaptor/ibm-dl/bin/generate-book.sh <username> <password> [hostname] Here the user name and password are the ones you use to access the console and host name is optional. It uses localhost if you omit it. The execution of this command can be time consuming depending on the size of the database you are exporting. In our test environment, that is not so large, it took ten minutes to complete, but it can probably last hours in a production environment. This should generate an output xml file under the following directory: /$COLLATION_HOME/sdk/adaptor/ibm-dl/book. In our test the name of the output file is: COLCON300.hosting02.torolab.ibm.com.2006-09-05T18.53.04Z.refresh.xml, where: COLCON300 is the application code. hosting02.torolab.ibm.com is the fully qualified hostname where the server is running. 2006-09-05T18.53.04Z is the timestamp in the form YYYY-MM-DDThh.mm.ssZ in UTC. refresh: indicates a refresh operation.
4.5.2 Importing the CCMDB data in data center model

After the xml file has been generated on the Change and Configuration Management Database, you can just run a specific discovery task to import it in the data center model. In the real world you might want to mount the remote file system where the book has been created from the Tivoli Provisioning Manager server, and schedule the periodic execution of book creation and discovery task
228
so that any update in Change and Configuration Management Database can also trigger an update in data center model. Figure 4-50 shows the configuration panel for a Discovery Library Reader task.
Figure 4-50 Discovery library reader creation
After selecting Next you get the panel seen in Figure 4-51 on page 230.
229
Figure 4-51 Discovery library reader configuration
The book.source.name variable is defined inside the book under the tag <cdm:Name>. In our test the value we provided is: ibm-cdm:///CDM-ManagementSoftwareSystem/Hostname=hosting02.torolab.i bm.com,Feature=COLCON300 The repository.dir variable specifies the absolute path of the location where the discovery books are read from. In our lab we created a specific directory on the Tivoli Provisioning Manager server. In alternative it would be advisable to map the remote directory on the Change and Configuration Management Database server where the book is created and provide it for the repository.dir parameter. In our test we provide the following value: $TIO_HOME/discoverylibrary/TADDMBooks The drift.repository.dir variable specifies the absolute path of the location where the configuration changes are written to. These XML files are used to update the data center model when updates to it are required. This directory is filled automatically by Tivoli Provisioning Manager when needed and you only have to create it for the discovery to work. It should be different from the repository.dir variable. In our test we provide the following value: $TIO_HOME/discoverylibrary/TADDMDrift
230
Figure 4-52 shows the workflow log we have for this discovery. The highlighted line shows that the book has been marked as read. This information is added to file $TIO_HOME/xml/discovery-book-history.xml. Next time the discovery library reader starts, it looks for new xml files in repository.dir and manages only the ones not present in discovery-book-history.xml. Note: The error bash: /etc/rc: Permission denied in Figure 4-52 is due to a syntax error in the workflow Discovery_Library_Discover that implements the discovery task. The error occurs in the line that checks for the existence of the repository and drift directories. If you define them correctly, you need not worry about it. The problem is probably fixed in a future patch.
Figure 4-52 Discovery library reader execution
231
Figure 4-53 shows the General tab for one of the system whose data is imported from the Change and Configuration Management Database.
Figure 4-53 Discovery library reader discovered system
Figure 4-54 shows the content of Software tab for one of the systems whose data is imported from the Change and Configuration Management Database.
232
Figure 4-54 Discovery library reader discovered data
233
234
Chapter 5.
Software management in Tivoli Provisioning Manager V5.1

This chapter covers the subject of software management with Tivoli Provisioning Manager V5.1. This includes the new services and infrastructure components used for creating and distributing software. The following are discussed in this chapter: Software management in Tivoli Provisioning Manager V5.1 on page 237 Components for software management on page 237 File repository on page 238 Software Package Editor on page 238 Software catalog and software products on page 244 Tivoli Provisioning Manager dynamic content delivery service on page 258 Device management service on page 267 Peer-to-peer file sharing on page 271 Distributing software on page 275 Inside the distribution process on page 287
235
Case study: A banking environment on page 295
236
5.1 Software management in Tivoli Provisioning Manager V5.1

Several new components and concepts are introduced in this chapter, these are described below. Some of these are familiar to existing Tivoli Configuration Manager V4.2.3 users but there are important differences.
5.2 Components for software management

A number of Tivoli Provisioning Manager components are involved in Software Management. Following are the main components: File repository A server that stores installable software images and other files that will be installed on managed systems. Software Package Editor A graphical tool for creating software packages. Software catalog A store of information about software, held within the data center model. It includes software stacks and software groups. The dynamic content delivery service A system for performing bulk data distribution, includes peer-to-peer distributions. Device management service A service that controls operations on managed systems by means of jobs. Depot server A server that stores files ready for distribution to endpoints using a dynamic content delivery service. Regions
Regions are used to group depot servers that are located near one another to
optimize upload, replication, and download times. Zones A zone is an IP range or domain and is used to logically group systems within regions. In addition to these components this chapter describes how the distribution process works and presents a case study of how this is implemented.
Chapter 5. Software management in Tivoli Provisioning Manager V5.1
237
Note: The screen shots shown in this chapter are generated both from the GA release of Tivoli Provisioning Manager and beta releases of Tivoli Provisioning Manager for Software, there are some minor differences compared to later versions of the software.
5.3 File repository

A file repository is a server that stores installable software images and other files that are installed on managed systems. File repositories holds operating system images or can link to external software catalogs such as Microsoft Windows Server Update Services to provide software updates. This chapter addresses the use of file repositories to store software images in software package block (SPB) format. A file repository called LocalFileRepository is automatically created on the Tivoli Provisioning Manager server with the directory path set to TIO_HOME/repository. When software packages are imported into a file repository the directory specified is relative to the repository path even though the import path has a leading forward slash.
5.4 Software Package Editor

The Software Package Editor (SPE) is a graphical tool for creating Software Installable files in software package block (SPB) format. It is installed on the Tivoli Provisioning Manager server by default and can be installed on other servers or workstations as required. In appearance and function it is somewhat similar to the Software Package Editor found in Tivoli Configuration Manager V4.2.3. Important: The Software Package Editor is currently only available on Windows platforms. This chapter deals with the software package block format of software installables that is familiar to existing Tivoli Configuration Manager users, and the distribution of SPBs within Tivoli Provisioning Manager to Tivoli common agent targets. We are not describing in detail creating the content of SPBs, this is covered in the SPE documentation and in various Tivoli Configuration Manager V4.2.3 publications.
238
5.4.1 Installing and starting the Software Package Editor

The following steps discuss the installaing and starting of the Software Package Editor.
Finding the Software Package Editor

The Software Package Editor runs under the Eclipse environment, it is shipped as part of the Automation Package Development Environment (APDE) or as a separate zip file. It is preinstalled on the Tivoli Provisioning Manager server. Eclipse is located in the APDE_HOME/eclipse directory and is started by running the script eclipseLauncher.bat on Windows platforms. The steps detailed below regarding installation of the SSL certificate also apply when running the SPE on the Tivoli Provisioning Manager server.
Installing on administrator workstations

It is also possible to install APDE and/or the Software Package Editor on other workstations, at the time of writing this option is only available on Windows platforms. The method described is applicable to Tivoli Provisioning Manager and is different in Tivoli Provisioning Manager for Software. 1. Ensure you have Java JRE version 1.4.2 on the workstation, if not then install a copy. For this example we use an existing JRE in C:\Program Files\IBM\My Help\jre. You can check the version with the command java -version. 2. Make sure the full path to the jre\bin directory appears on the path before any other Java versions. 3. Start a new Web browser window and open the Tivoli Provisioning Manager admin GUI. When prompted to accept the certificate, instead view the certificate, switch to the Details tab and select Copy to File. Save the certificate file to a temporary directory, for example C:\temp\helsinki.cer. 4. From a command prompt install the certificate with the keytool utility as shown in Example 5-1. The default password for the keystore is changeit. Note: Enter all commands on a single line. Change the value of alias to represent the certificate you are registering.
Example 5-1 Importing a SSL certificate for SPE
C:\>keytool -import -v -keystore "C:\Program Files\IBM\My Help\jre\lib\security\cacerts" -file \temp\helsinki.cer -storepass "changeit" -alias helsinki Owner: CN=helsinki.itsc.austin.ibm.com, CN=C:/Program Files/IBM/AgentManager, CN=CTGEM, CN=790D46403FC211DBA9FD0011099B9740, CN=Agent Manager, DC=itsc, DC=austin, DC=ibm, DC=com
239
Issuer: CN=TivoliAgentManagerCA, DC=itsc, DC=austin, DC=ibm, DC=com Serial number: 3 Valid from: 09/09/06 00:45 until: 06/09/16 01:00 Certificate fingerprints: MD5: AC:56:B3:C9:60:DA:A6:D3:1E:8C:81:8E:ED:09:43:B0 SHA1: 58:8D:9B:6C:24:37:98:EC:C5:AC:7A:42:CE:21:5B:4B:A1:48:74:8B Trust this certificate? [no]: y Certificate was added to keystore [Saving C:\Program Files\IBM\My Help\jre\lib\security\cacerts] 5. Download the full Eclipse SDK version 3.1.2 from http://www.eclipse.org/ and install on the workstation. You cannot use the version of Eclipse provided with the IBM Help Center as this is not the full SDK. 6. Copy TIO_HOME\apde\apde.zip or spe.zip from the Tivoli Provisioning Manager server and extract into the Eclipse directory created in the previous step. The plug-in files in the zip file have the directory structure eclipse\plugins, ensure these files are extracted into your new eclipse\plugins directory. It is understood that APDE is not included in Tivoli Provisioning Manager for Software and that a zip just containing the SPE is available. 7. Start Eclipse with eclipseLauncher.bat.
Configuring Software Package Editor options

Once the Eclipse environment has loaded, the preferences for the Software Package Editor should be set before its first use. Select Window Preferences. Choose Software Package Editor from the list. Complete the dialog as shown in Figure 5-1 on page 241, specifying the fully qualified host name for the Tivoli Provisioning Manager in the Web server host name field. The Web server port must be set to 9045 and the Web server root path left at the default of SPE. Enter your user name and password and specify the default path, this is used as the default directory on your workstation when opening and saving software packages in the Software Package Editor. Ensure the Use SSL option is selected, this is required to enable secure communication when opening or saving software installables to the file repository.
240
Figure 5-1 Setting Software Package Editor preferences
The editor can be started from the Eclipse GUI by selecting Window Show View Other. Select Software Package Editor under the Software Package Editor folder. After clicking OK an empty Software Package Editor is displayed as shown in Figure 5-2 on page 242.
241
Figure 5-2 The Software Package Editor
Saving a Software Package Block

To save a Software Installable (SPB) to a file repository or to a local file system for later importing into a file repository it should be saved in software package block (filename.spb) format. This file type includes both the definition of the package and the files within the package encapsulated into a single file. If you wish to save the definition locally for later editing then save in Software Package format (filename.sp) which includes pointers to the package files, not the actual files.
242
Tip: When saving to sp and spb files it is a good idea to include the version of the package in the file name (For example, MyApplication_v2_1.spb), this helps differentiate between the files for different versions of the same package.
Figure 5-3 Saving a software package locally
Two options are available when saving a software package block installable in preparation for importing into a software product: Save to local filesystem Save to repository If you save the software package block locally you can copy or upload it to a file repository during the import software product process (See 5.5, Software catalog and software products on page 244). If you choose to Save to Repository, the upload and import are done automatically. Attention: In the version of Tivoli Provisioning Manager available when this publication was written, the software package created during the Save to Repository operation creates an SPB on the file repository named PackageName.spb. This means that if you save two versions of the same package then the first one is overwritten. If you decide to use version control package, make sure you save the SPB locally with a unique name and create a software package manually by importing the correct SPB.
243
5.5 Software catalog and software products

A software product is an object wrapping of one or more Software Installable binary files. For SPB type software products the installable is the SPB file itself. To deploy a piece of software it must be created as a software product in the Software catalog (or included as an installable in a software stack). software package blocks that you create can either be manually imported or imported automatically by uploading to the file repository by the Software Package Editor. Some other processes can automatically update the Software catalog. For each software product installed on a given target a Software Installation object is created and stored. The entire set of Software Installation objects associated to a computer represents itssoftware catalog.
5.5.1 Importing manually a software package block

The Software Package Editor can upload and import software package block files in one action. This is described in Saving a Software Package Block on page 242. This method is easier than the manual methods described in this section as it combines several steps in one action. If you have created a software package block or are manually importing one from a Tivoli Framework environment there are a couple of alternative methods for creating the Software Package. Both these methods start from the same place: 1. Create or obtain the software package block file. 2. From the Tivoli Provisioning Manager GUI select Manage Software Catalog Software Products. 3. Select Edit Import Software Product as shown in Figure 5-4.
Figure 5-4 Importing software product
244
4. Enter the name, version and vendor of the software product as shown in Figure 5-5 on page 245.
Figure 5-5 Define software product stage 1
5. Click Next. You now have a choice of selecting the Software Installable Location, either File Repository or Local System, the two alternatives are described below.
File on Repository
Choose this method if you have already placed the software package block file into the repository directory (or a subdirectory beneath it). You need to know the exact file name and location: 1. Select File Repository as the software installable location. 2. Select the appropriate file repository (Usually LocalFileRepository). 3. Enter the package path (note leading /) and file name and click Next.
245
Figure 5-6 Set file name and location
4. The installation of software package blocks does not require a device driver so select None and click Next.
Figure 5-7 Select device driver
5. No additional properties are required so click Next.
246
Figure 5-8 Device driver properties
6. Review the summary and click Finish.
Figure 5-9 Review settings
7. The software package is created. You can edit the configuration template if required. See Software product requirement on page 250.
File on local system

This method moves the software package block from your workstation via your Web browser into the file repository and create the software product: 1. Select File Repository as the software installable location. 2. Do not complete the file path box, instead select Upload Package File, browse to the file location and click Upload (Figure 5-10 on page 248).
247
Figure 5-10 Selecting upload package file
The file path is completed automatically. 3. Select the appropriate file repository (usually LocalFileRepository). 4. Enter the package path (note leading /) and file name and click Next (Figure 5-11 on page 248).
Figure 5-11 Entering the oackage path and file name
248
5. The installation of software package blocks does not require a device driver so select None and click Next. 6. No additional properties are required so click Next. 7. Review the summary and click Finish.
Figure 5-12 Review Summary
8. The software package is created. A message displays saying that file was uploaded successfully.
249
Figure 5-13 Upload successful
9. Check that the file has been copied to the repository directory
5.5.2 Software product requirement

A requirement is the definition of any dependencies that an object has. For SPB type software products there is only one requirement that needs to be specified and that is for the Software Installation Engine (SIE) to be installed on the target computer. The SIE is a subagent of the TCA and implements the SPB Handler to install SPB software installable images. The requirements can be viewed by expanding the Requirements and Capabilities section of a software product as shown in Figure 5-14.
250
Figure 5-14 Checking SIE requirement
If the software product is created automatically it is likely that the requirement is already added but if it is created manually then the requirement is added by selecting Edit Add Requirement as shown in Figure 5-15 on page 252.
251
Figure 5-15 Adding SIE requirement
5.5.3 Adding parameters to software packages

There are currently two parameters that can be added to the configuration template of the software installable to control its behavior during the install process. These parameters are: FORCE This parameter can be used to force the reinstallation of a package even if it is already installed. Use FALSE to not force the SPB reinstallation. Use TRUE to force the SPB reinstallation. The default value is FALSE. REMOVE_SPB_AFTER_PROCESS You can use this parameter to specify whether you want to keep the SPB package after the successful installation of the software. Use TRUE to remove the package after the successful installation. Use FALSE to keep the package after the successful installation. The default value is FALSE. Note: Some versions of the documentation have an incorrect description of REMOVE_SPB_AFTER_PROCESS, the True and False definitions are reversed.
252
These definitions can be added to the configuration template for each package. The parameters can be added manually or copied from a previously modified template. 1. Open the Configuration Templates section and select Edit from the context menu icon (also called the More Actions button) then select Add Parameter. 2. Complete the dialog to add a boolean parameter with TRUE and FALSE values as shown in Figure 5-16 and select Save.
Figure 5-16 Adding a new configuration template parameter
The new parameter is displayed as shown in Figure 5-17 on page 253.
Figure 5-17 Force parameter added
253
If marked as Changeable, then this value can be changed from the Advanced screen when installing the package. 3. While editing the template you can add in the requirement details above. This template can be copied when creating additional software products by selecting Edit Define Configuration Template and choosing Copy from a software definition. Remember to remove the old template leaving just the newly created one.
5.5.4 Adding software products into groups

Software packages can be added into groups. The creation of a software group is illustrated in Figure 5-18 on page 254.
Figure 5-18 Adding a group of software packages
These groups can be very useful for compliance checks. Rather than add individual software packages to the software compliance check for individual computers it is better to add a compliance check of a software group to a computer group. Unlike software stacks it is not possible to perform an installation of a group of software packages.
254
5.5.5 Software views

A software view is a tool to filter a displayed list of software objects by certain attributes. Figure 5-19 on page 255 shows the creation of a software view filtering software products and software stacks by the SIE requirement.
Figure 5-19 Creating a software view
This view can be used when distributing software. Figure 5-20 on page 256 shows that the list of packages is filtered to only include those packages that match the view.
255
Figure 5-20 Using a software view
5.5.6 Software stacks

A software stack is a type of software definition that defines a list of software to be installed or removed at the same time and in a defined order. A software stack can include installable files and software definitions for software products, software patches, and other software stacks. Software stacks can be used for compliance purposes, they can be added to the compliance list of computers or groups of computers to ensure that the computers have the correct software installed. Important: We encountered some difficulties installing software stacks containing SPBs in beta versions of the software. It is expected that this will be addressed in a later release.
256
Creating software stacks

To create a software stack, first identify the list of software and the order that they should be installed. This example shows the definition of a stack that contains software products. Although it does not include any software installables a special installable called an iterator must be included. This instructs Tivoli Provisioning Manager to use the stack entries rather than the installables. 1. Select Software Management Manage Software Software stacks. 2. From the Edit menu select Add Software Stack, enter the name and description of the stack. 3. Click on the newly created stack to display its contents. 4. Click Edit Add Installable. Select iterator from the first field. No further configuration is required. 5. Click Edit Add Stack Entry, search for the software product, confirm its type and click Next.
Figure 5-21 Adding software to a stack
6. Select the template to use and click Next. 7. Customize the template if required and click Finish. 8. Repeat for each software product you want to add. 9. You can reorder the software products if needed.
257
Figure 5-22 Reordering software in the stack
The stack is ready to be installed or specified in a compliance check.
5.6 Tivoli Provisioning Manager dynamic content delivery service

Tivoli Provisioning Manager dynamic content delivery service is one of the core services that enable the efficient distribution of files and content to large numbers of targets.
The dynamic content delivery service comprises a number of components. The following are the main components: The dynamic content delivery service Management Center on page 259 Depot server on page 260 Regions on page 264 Zones on page 266 All of these components are described individually followed by a summary of how they all fit together (See 5.10, Inside the distribution process on page 287).
258
5.6.1 The dynamic content delivery service Management Center

The Management Center is the central component of the dynamic content delivery service. It provides overall control of the other dynamic content delivery service components and provides these key functions: Maintains a list of the files stored on each depot server. Stores the configuration of each depot server. Replicates uploaded files between depots. Authorizes clients to download a file. Creates download plans. Stores information about files and download statistics. The Management Center itself has a number of sub-components, these components are not presented on the GUI but are included here for completeness: Download manager Responsible for building download plans. Peer manager Keeps track of the files stored on each client and is used by the download manager to create the lists of peers included in a download plan. Monitoring agent Periodically checks the health of the depot servers. Distribution agent Controls the distribution of files across depot servers and to targets. When you publish a file, the distribution agent replicates the file to the depot servers that you specify. When a file is deleted, the distribution agent deletes the file from the depot servers that store the file. It is possible to administer the dynamic content delivery service directly (that is, without using the Tivoli Provisioning Manager GUI) by connecting to https://tpmhostname:9045/admin/ and logging in with the tioappadmin account (tioadmin for FastStart installations). This can be useful in certain circumstances but is not generally recommended, in particular it is not advisable to create or delete dynamic content delivery service components from within this tool. The interaction between the dynamic content delivery service and other software management functions is described in 5.10, Inside the distribution process on page 287.
259
5.6.2 Depot server

A depot server is a system that stores files in a designated directory ready for distribution to target systems. Depot servers can also replicate these files to other depot servers to optimize network traffic. In some ways depots are similar to Tivoli Configuration Manager V4.2.3 Gateways but unlike Gateways they do not have a fixed set of Endpoint that they can distribute to.
Features of depots
Each depot server is assigned to a single region (See 5.6.3, Regions on page 264) and can optionally be assigned a DNS domain, for example development.example.com. The domain is used to prioritize depot servers during downloads. A depot server that is in the same domain as a client is chosen before depot servers outside the domain. One or more depot servers can be designated as preferred upload servers. Uploaded files are sent to these servers before any others. If no preferred upload server is available, another depot server is selected to receive the uploaded file. In this concept the term upload is used to describe a software product installable file that is retrieved from a file repository and placed on a depot server. It is possible to configure the bandwidth used by distributions from a depot, either by specifying an explicit bandwidth in kb/s or adaptively. Adaptive bandwidth control monitors the response time of packets sent to a target and slows down the distribution if the response time is slow as this indicates that the network is busy. This is particularly useful for making best use of slow networks as Tivoli Provisioning Manager uses the available bandwidth when the network is quiet but is back off if other applications start using the network and speeds up the distribution again when the network becomes less utilized. It is possible to assign a DNS domain to a depot, A depot server that is in the same domain as a client is chosen before depot servers outside the domain. In the current release this parameter can only be set in the Tivoli Provisioning Manager for Dynamic Content Delivery Service GUI as described in 5.6.1, The dynamic content delivery service Management Center on page 259.
Depot prerequisites
The depot server requires at least 1Gb RAM and is supports all platforms supported by the Tivoli common agent. For current details refer to the current Tivoli Provisioning Manager ReadMe document. As the depot stores copies of all defined software packages it requires a considerable amount of disk space. Any system that is used to host a depot server requires at lease 150 MB of free space available in the /tmp directory (%temp% on Windows systems). Additionally, 250 MB free space must be available in the /opt directory on UNIX
260
or Linux systems. AIX depot servers have unique configuration requirements because the default partition size (64 MB) is too small to perform a depot server installation. On AIX servers, you need to resize the root partition to 250 MB to allow enough space in the /opt directory.
Creating a depot
A depot is a implemented as a client or sub-agent on a Tivoli common agent (TCA), the TCA is automatically installed on the host system when the depot is created. A depot can not be created on the Tivoli Provisioning Manager server as the depot functionality is provided as a sub-agent of the Tivoli common agent which is not supported on the Tivoli Provisioning Manager server. Important: In the GA version of Tivoli Provisioning Manager V5.1 the creation of a depot fails if the Tivoli common agent is already installed. If you need to create a depot on an server that has Tivoli common agent already installed you must first perform an uninstall of the TCA from the computer. This behavior is planned to be addressed in a future fixpack. Following are the steps for creating a depot. Note that the screens for creating depots, regions and zones are located in the GUI under Inventory Infrastructure Management Depots. 1. Check the software and hardware prerequisites for the depot server, in particular ensure you have enough disk space to store the Software Packages that will be distributed. 2. Run a discovery to add the server that hosts the depot into the Data Center Model. For more information on Discovery see Chapter 4, Discovery mechanism on page 175. 3. Create the region to which the depot is assigned. This is specified when the depot is created. Also see Regions on page 264. 4. From the Manage Depots screen select Depot tab and select Edit Add Depot. Complete the Add Depot dialog as in the example shown in Figure 5-23 on page 262. It is important to ensure that you specify the correct fully qualified host name and an appropriate data directory. Do not change the default port number. If the depot is being created on a Windows system that is discovered using SMB discovery then the credentials is already stored in the Data Center Model, otherwise you must enter the username and password of an administrative or root user.
261
Generally only one preferred upload server is required so clear this option for subsequent depot installations. Note: The default size for depot storage is 2 Gb. Make sure you increase this to allow for all packages likely to be stored on the depot.
Figure 5-23 Depot creation dialog
5. When Save is clicked an entry for the depot is created in the Data Center Model and a task is created that uses the workflow Install_CDS_Depot to create the Tivoli common agent and install the Depot sub-agent as shown in Figure 5-24 on page 263.
262
Figure 5-24 Depot creation initialized
The progress of the depot creation can be followed from the Tasks Track Tasks screen. A shortcut to track the task is provided as shown above.
Checking the status of a depot

For a depot to be used it must have an Active status, as you can see in Figure 5-24 the initial status of a depot is Inactive, this will change to Active once the Tivoli common agent and depot sub-agent are up and running. This status is shown on the Depot tab of the Inventory Infrastructure Management Depots screen as in Figure 5-25. As you can see from this screen an incorrect domain was specified for the Oslo server, causing the install to fail and preventing it from becoming active.
Figure 5-25 Viewing depot status
Viewing a list of files on depots

It is possible to check what files are currently resident on a depot by clicking on a depots name and expanding the Files on Depot server section as in Figure 5-26 on page 264. The description, ID and size of the files is also shown.
263
Figure 5-26 Viewing files on Depot server
How files get into depots

There are two ways in which files are placed on a depot: 1. By publishing a Software Package. If a Software Package is published to a depot it will not automatically be purged and will remain on the depot until a Unpublish action is performed. 2. By performing an Install of a Software Package. When a Software Package is distributed as part of an Install it will be placed on whatever depots are required for the distribution. When the distribution is complete the file will automatically be purged from the depots. This is why there may be fewer files listed on a depot than you might expect.
5.6.3 Regions
Regions are used to group depot servers that are located near one another to optimize upload, replication, and download times. In our test environment two regions are created, DataCenterRegion for data centers and BranchRegion for branches as shown in Figure 5-27 on page 265. The inclusion of the word Region in the name is simply for clarity, it is not required but is a matter for personal preference or policy. We have also chosen not to include spaces in the object labels but again this is not a restriction. Figure 5-27 shows a Tivoli Management Framework region called milan-region. This is a policy region that is imported from a connected Tivoli Managed Region.
264
Figure 5-27 Viewing regions
Creating regions
When deciding what regions are to be created you need to look a the physical structure of the company and the network. For example, a company that has several distributed offices typically creates one region for each office location. The regions can be further divided into zones as required (See 5.6.4, Zones on page 266). A region does not have to follow physical boundaries and has no configurable network restrictions but as depots and zones are bound to regions it makes sense to define regions to sensibly group these objects. Regions are created from the Regions tab on the Inventory Infrastructure Management Depots screen. From here select Edit Add Region. Their definition only requires the provision of a Name and optional description as shown in Figure 5-28 on page 266.
265
Figure 5-28 Adding a region
5.6.4 Zones
A zone is logical grouping of computers that have TCP/IP addresses within a single consecutive range, or are within a single DNS sub domain. They are used to optionally control the flow of network traffic by restricting data movement across wide area networks. Zones are typically created to limit network traffic to within a subnet or physical network. For example companies with small branch offices that have limited WAN bandwidth create a zone for each branch. Distributions to targets within each zone use depots (or peers if enabled) within the zone as much as possible. This is further discussed in 5.11, Case study: A banking environment on page 295.
Creating a zone
Zones are created from the Zones tab on the Inventory Infrastructure Management Depots screen. From here select Edit Add Zone. Figure 5-29 on page 267 shows the creation of a zone called EssexDataCenterZone with an IP range of 9.3.5.130 - 9.3.5.205. This zone has the options: Allow peering and Minimize traffic in and out of zone.
266
Figure 5-29 Adding a zone
Clients attempt to download from depot servers within their zone if the option Minimize traffic in and out of zone is selected. If there are no depots or peers within the zone then a depot from within the same region is selected, if the client is not in a zone then a random depot is used. Clients can receive distributions from their peers within the same zone as well as from depots. Zones have an option Allow peering to allow this peering. If a client is not in a zone it can download from depot servers but not its peers. Peering must also be enabled for the dynamic content delivery service subagent, the default is not enabled. Peering is further discussed in 5.8, Peer-to-peer file sharing on page 271.
5.7 Device management service

The device management service provides a flexible solution for managing various devices mainly by performing actions called jobs which is targeted to individual Tivoli common agent devices or to groups of devices that are configured to use a SOA SAP (See SOA Service Access Point on page 269). Within software management, device management service is used to initiate software downloads, run installation actions and collect results. It can also be used for device configuration, inventory scanning and data collection.
267
Device management service tracks the progress of jobs and maintains a history of past jobs. You can also see the device management service referred to as the job management service, notably during the installation process. In general use the device management serviceis hidden and transparent to the operator.
5.7.1 Device manager components

The device manager is composed of the device management server, remote device management agents and device manager subagents. At the time of writing remote federating agents were not available but are expected to be included in a future release.
Device management server

Jobs are submitted into the device management server to be passed on to device manager sub agents via federated agents (if installed). Results are returned in the reverse direction. The device management server does not attempt to understand or parse the jobs it is given.
Device management federating agents

Device management federating agents is referred to as eDMS servers. Currently a single device management agent is implemented on the Tivoli Provisioning Manager server, remote agents are planned for future releases. These are implemented as lightweight versions of the device management server and uses Cloudscape databases. The agents periodically polls the management server for jobs (the default interval is 10 minutes), results are passed up at the same time. The agents maintain a copy of the job and pass them down to agents on request. The polling interval for the agent is controlled by the instFederatedAgentPollFrequencyInMinutes parameter in the DMSconfig.properties file. This is not available in a FastStart installation.
Device manager subagents

Clients are implemented as device manager subagents of the Tivoli common agent and communicate with federated agents or the central device management server. At the time of writing the default interval is set to one hour plus a random time of between 0 and 5 minutes. The interval for beta versions of the software is usually set to five minutes.
268
The polling interval is set on the managed system by changing the value of PollingInterval in the file CA_HOME/jes.properties as shown in Example 5-2. If you edit this or any other properties file, all special characters such as the colon in the time variables are quoted with a preceding \. The agent is restarted for changes to take effect. Other polling variables can be changed to restrict the time of day that the agents poll.
Example 5-2 jes.properties file
#Tue Aug 29 13:01:36 BST 2006 PollingEnabled=true PollingStart=02\:00 PollingEnd=02\:00 PollingInterval=01\:00 ClientPW=tpmpassword Addr=https\://192.168.0.1\:9045/dmserver/SyncMLDMServlet UserName=tpmuser LogSize=200 Many of these parameters can be set centrally by modifying the TCA Subagent JES before the Tivoli common agent is delivered and installed.
5.7.2 Device management service concepts

There are a few important concepts to understand when looking at device management service.
Sending jobs to Tivoli common agent

For software distribution over SOA it is important to understand the way that jobs are given to targets, especially if you are coming from a Tivoli Framework background as the process is quite different. The device manager server or federating agents do not attempt to contact Tivoli common agents when a job is waiting to be sent, instead the device manager subagents running on Tivoli common agents are programmed to poll a federated agent periodically to check if there are any outstanding jobs. This behavior is designed to increase scalability and robustness, the polling processing is delegated out to the agents, reducing the load on the federated agents.
SOA Service Access Point

SOA Service Access Point (SAP) is required on all computers targeted for software distribution. A preloaded workflow, Create_SOA_Endpoint_Operation_SAP, assigns this service access point to the
269
endpoint-operations device operation that is used to perform software distribution tasks using the infrastructure. You can create a favorite task using this workflow and run it to create the SOA-SAP service access point on all the target computers. It is also possible to use the SOAP CLI to run the Create_SOA_Endpoint_Operation_SAP workflow. SOAP commands use the device ID and not the hostname. Example 5-3 shows the process for running the workflow on device 2385 and checking the result, this example is taken from a Windows Tivoli Provisioning Manager server. Note: Commands should be entered on one line.
Example 5-3 Running the workflow on device 2385
> cd C:\Program Files\IBM\tivoli\tpm\soapclient\tpmlteSoap > soapcli tioadmin tioadmin http://localhost:8777/ws/pid/TpmLiteSoapService?wsdl executeDeploymentRequest Create_SOA_Endpoint_Operation_SAP "DeviceID=2385" Result: 10163 rem The deployment status code has the following values: rem 0 - unknown, 1 - in-progress, 2- cancelled rem 3 - success, 4 - failed, "5 - created > soapcli tioadmin tioadmin http://localhost:8777/ws/pid/TpmLiteSoapService?wsdl findDeploymentStatus 10163 Result: 3 >soapcli tioadmin tioadmin http://localhost:8777/ws/pid/TpmLiteSoapService?wsdl findLogDetails 10163 Log Details: Total: 4 Start workflow: 'Create_SOA_Endpoint_Operation_SAP' A SAP for type SOA already exists, SAP_ID = 2582
270
Updating existing default Endpoint Operation Sap with SOA type SAP End workflow: 'Create_SOA_Endpoint_Operation_SAP' Check if the SAP has been created by checking Credentials tab in Computer Properties screen. See that the SOA-SAP credential is created and is the Default SAP for the endpoint-operations Device Operation as highlighted in Figure 5-30.
Figure 5-30 Checking SOA SAP
Following is the third method to set the SOA SAP: Select Inventory Manage Inventory Computers screen. Select Edit Add credentials. Select SOA. Select target computers and click Finish. This results in the creation of a SAP called soahost rather than SOA-SAP but the functionality is identical.
Failures due to no SOA SAP

If the SOA SAP is not created, the following is returned if you perform an operation such as a software installation. COPDEX137E There is no workflow that implements the "SoftwareInstallable.Install" logical operation associated with device "AppName.1.0".
5.8 Peer-to-peer file sharing

Tivoli common agents can act as miniature depot servers, that is they can hold copies of distributed files in a cache and act as sources for this file during
271
downloads by their neighbors. The list of files held by a peer is maintained by the Dynamic Content Distribution Service Peer Manager. Peers periodically contacts the peer manager to refresh the information held. Peers that do not report is marked as inactive and is not included as sources in download plans. For NAT (Network Address Translation) environments both the local and remote TCP/IP address is stored by the peer manager, this is used to enable peer-to-peer distributions to use local addresses. This option must be enabled when creating the zone. When a file is downloaded to a target, a copy is held in the download_directory unless the software package option REMOVE_SPB_AFTER_PROCESS has been specified. If peering is enabled a copy of the file is placed in the cache_directory. Note: The copies of the files are encrypted and have different file names.
5.8.1 Enabling peer-to-peer file sharing

Peer-to-peer file sharing is enabled in two places to become active: 1. The zone containing the managed system must be set to allow peering. (See Zones on page 266 for more information). 2. The peering option must be set to true on the subagent that provides dynamic content delivery services on the Tivoli common agent. This can be set before the Tivoli common agent is installed by editing the configuration template of the software package TCA-Subagent CDS Client URL Handler and setting the peering parameter to true as shown in Figure 5-31 on page 273.
272
Figure 5-31 Setting default peering option
Peering configuration on the endpoint

The configuration of the dynamic content delivery service sub agent on the Tivoli common agent is held in the file CA_HOME\subagents\cdsclient.properties, care must be taken when editing this file, it is not recommended to alter any parameters except for changing peering from false to true. Example 5-4 shows a cdsclient.properties file from a Windows system with peering not enabled.
Example 5-4 Example cdsclient.properties file with peering disabled
#WEBAHEAD DOWNLOADGRID MANAGER / DO NOT EDIT #Tue Sep 12 06:39:13 CDT 2006 uuid=43233B054A1A3DC79C87E181A91BF231 peering=false cache_directory=C\:\\Program Files\\tivoli\\ep\\runtime\\agent\\subagents\\cds\\cache web_service_protocol=1 web_service_https_port=9046 web_service_host=9.3.5.52
273
subnetAddr=9.3.5.0 user_id=maldon.itsc.austin.ibm.com download_directory=C\:\\Program Files\\tivoli\\ep\\runtime\\agent\\subagents\\cds\\downloads web_service_http_port=9082 This file is edited and peering changed to true and the Tivoli common agent stopped and restarted. After the next dynamic content delivery service distribution the properties file is automatically updated with all the information required for it to act as a peer. You also notice that the peer is configured to use adaptive bandwidth control.
Example 5-5 Example cdsclient.properties file after peering enabled
#WEBAHEAD DOWNLOADGRID MANAGER / DO NOT EDIT #Thu Sep 14 11:07:47 CDT 2006 web_service_http_port=9082 user_id=maldon.itsc.austin.ibm.com web_service_protocol=1 subnetAddr=9.3.5.0 web_service_context_root= adaptive_bandwidth_control=true user_web_service_url_secure=https\://helsinki.itsc.austin.ibm.com\:9046 /DownloadGrid/services/DownloadGridUserServerSOAP download_directory=C\:\\Program Files\\tivoli\\ep\\runtime\\agent\\subagents\\cds\\downloads web_service_host=helsinki.itsc.austin.ibm.com cds_port=21235 user_web_service_url=https\://helsinki.itsc.austin.ibm.com\:9046/Downlo adGrid/services/DownloadGridUserServerSOAP peer_services_url=https\://helsinki.itsc.austin.ibm.com\:9046/DownloadG rid/client/PeerServices rmi_port=2111 cache_directory=C\:\\Program Files\\tivoli\\ep\\runtime\\agent\\subagents\\cds\\cache peering=true uuid=43233B054A1A3DC79C87E181A91BF231 initial_login_done=true user_ip=9.3.5.202 client_url=http\://helsinki.itsc.austin.ibm.com\:9082/DownloadGrid/clie nt/ClientUpgrade web_service_https_port=9046 config_setting=false domain=itsc.austin.ibm.com
274
5.9 Distributing software

This section discusses the steps required to install and uninstall software.
5.9.1 Checklist
Before performing an install, the following steps need to be checked: The Tivoli common agent is installed on the targets. SOA SAP is created for all targets. Zones, regions and depot servers are correctly configured. The software package is created. Optionally the software stack is created.
5.9.2 Publishing to depots

It is optionally possible to publish a software package to one or more depots. This reduces the time taken for distributions and ensures that the files remain on the depots ready for future distributions. 1. Select Software Management Publish Software Products. See Figure 5-32 on page 276.
275
Figure 5-32 Publishing a software package
2. Give the task a meaningful title. 3. Choose the software package. 4. Select the depots. 5. The task starts immediately when At Following Time option and complete the schedule date & times is selected. 6. Click Submit. 7. You can monitor the task by following the link shown or from Task Management Track Task, as shown in Figure 5-33 on page 277.
276
Figure 5-33 Tracking a Publish task
8. To check the files on a depot, select the depot from the Inventory Infrastructure Management Depot and expand the File On Depot section (Figure 5-34 on page 278).
277
Figure 5-34 Checking the files on a depot
This published file remains on the depots until you perform Unpublish.
5.9.3 Installing a software package or software stack

One or more software packages is installed on individually selected targets or groups of targets. This same procedure is used to install a software stack. Important: We encountered some difficulties installing software stacks containing SPBs in beta versions of the software. It is expected that this will be addressed in a later release. Perform the following steps for an installation: 1. Select Software Management Install Software Products. 2. Enter a meaningful name for the task. 3. In the Select Software panel click the checkbox by each package you want to install, the packages are moved into the Selected Software list (See Figure 5-35 on page 279).
278
You can filter this view by entering search text the filter box and clicking Search. You can also filter using Software Views. See Software stacks on page 256.
Figure 5-35 Selecting software packages
4. You can change the installation order by selecting a package in the Selected Software list and clicking the up or down buttons. 5. Select the targets to install the software in the same way. You can select by individual target or by computer group as in Figure 5-36 on page 280 where one group and one target are selected.
279
Figure 5-36 Selecting targets
6. If any of the packages have parameters that you need to change or review click Advanced. From the Advanced screen (Figure 5-37 on page 281) you can change the parameters for any of the software packages if any have been defined (See Software product requirement on page 250).
280
Figure 5-37 Advanced options
7. Click Submit to start the installation task. You see a confirmation message that the task has been submitted (Figure 5-38 on page 281).
Figure 5-38 Installation submitted
8. The progress of the task can be followed by clicking on the link provided (Figure 5-39 on page 282).
281
Figure 5-39 Tracking the installation task
9. As the elements of the task complete you can view distribution statistics by selecting View Depots from the More Actions button. This shows from which depot or peer each package was downloaded from for the selected target (Figure 5-40 on page 283).
282
Figure 5-40 Depot and peer statistics
The unique computer ID of the peer is shown rather than the computer name.
5.9.4 Delivering before installing

Using the Software Management Distribute Software Products screen it is possible to deliver the software package to targets without performing an installation. This is useful if you have a large package to install that must be active on many targets at the same time, you can perform the distribution to many targets over a few days and then when all distributions have been completed you can perform an Install without distribution to activate the package. The distribute software products process is much the same as the Install process as detailed in 5.9.3, Installing a software package or software stack on page 278. To perform the second step of installing without distribution, select that option from the advanced screen of Install Software Product.
283
Figure 5-41 Install without distribution
Note: This is the default option, if the package has not already been distributed it will be distributed during the install process. This is different from the behavior of transactional install & commit operations in Tivoli Configuration Manager V4.2.3.
5.9.5 Scheduling and delivering before installing

It is possible to perform the installation at a future time by specifying to install At Following Time.
Figure 5-42 Schedule an install
It is also possible to perform a delivery of the software package prior to a scheduled installation. Specify a future time for the install as above. Before clicking Submit, click Advanced, you can then specify the option to Distribute prior to install as shown in Figure 5-43 on page 285.
284
Figure 5-43 Distribute prior to install
The options specified in Figure 5-42 on page 284 and Figure 5-43 results in two tasks being submitted, a Distribute on 19th September at 23:00 and an Install on 20th September at 03:00 as shown in Figure 5-44.
Figure 5-44 Tracking the two tasks
5.9.6 Installing by remediation

A Remediation is the action taken as a result of a compliance check. Compliance and remediation are described in detail Chapter 7, Compliance management on page 345. Important: There is a known problem that may be encountered when performing remediation with software products containing SPBs in certain versions of the software. A workaround is to perform a scheduled remediation rather than an immediate run.
285
5.9.7 Uninstall
The uninstall process is very similar to the install process except that you can only perform an uninstall for targets that have the selected software installed on them. The uninstall process is data-less, that is no content is sent down when the task is submitted, only a job to perform the uninstall action. For this reason it is not possible to perform an uninstall if the software is not already installed.
286
5.10 Inside the distribution process

Tivoli Provisioning Manager uses both the dynamic content delivery service and the Device Management Service to distribute and install software packages. This section presents a short summary of the concepts and examines the process in more detail.
5.10.1 Distribution process overview

At a very high level the distribution, install and the result process consists of the following six stages:
1 TPM publishes file into content delivery service Management Center
2 Management Center populates depots
3 DMS Job instructs client to download file and install
6 DMS updates TPM
5 Client Installs and sends result to DMS
4 Clients download file from depots
Figure 5-45 Distribution process - high level
1. Tivoli Provisioning Manager publishes the file into the dynamic content delivery service along with the list of targets. 2. The dynamic content delivery service Management Center populates the primary upload server and other depots. 3. Tivoli Provisioning Manager sends Device Management Service instructions to create a job. The job is given to clients on request. 4. The clients download file from one or more depots or peers. 5. Client runs installation instructions and returns result to DMS. 6. DMS updates results into Tivoli Provisioning Manager.
287
5.10.2 Distribution process step by step

This section describes the whole distribution process from end-to-end, split into the six stages presented in Distribution process overview on page 287.
Publishing and uploading a file

1. A software package distribution is initiated to one or more targets. Tivoli Provisioning Manager contacts the dynamic content delivery service Management Center and performs a publish operation. 2. The Management Center validates the request and sends an upload plan to the designated upload depot server specifying what file is to be uploaded. 3. The upload depot server retrieves the file from the file repository and stores it in the depot directory. 4. At the same time Tivoli Provisioning Manager contacts the Device Management Service Federator and submits an installation job to be sent to the target list. 5. The Remote Federating Agent polls the Federator for new jobs every 10 minutes (configurable). At the time of writing the Remote Federating Agent functionality is not available but is planned for a future fixpack. Internally the Device Management Server also implements an federating agent so the functionality and process flow is similar except that targets contact the central Device Management Server directly. 6. The device management server sends down job to remote federating agent. See Figure 5-46 on page 289.
288
TPM 1.4 - Queue job Database
1.1 - Publish
Dynamic content delivery service Management Center
SPB File Repository
Device Management Service
1.3 - File uploaded 1.2 - Upload Plan Upload Depot Depot SubAgent
1.5 - Request jobs
1.6 - Receive jobs
Remote DMS Federating Agent
Figure 5-46 Software Distribution step 1
Populating depots
1. The distribution agent determines which depots requires a copy of the file based upon the target list along with region and zone information. The selected depots are instructed to replicate the file from the upload depot server or other depots. 2. The depot servers retrieve the file from the upload server using the content distribution service subagent to perform this download. The Management Center maintains a catalog of the files stored on each depot server. See Figure 5-47 on page 290.
289
TPM
Database
SPB File Repository
Upload Depot 2.1 - Replicate instruction Depot SubAgent
2.1 - Replicate instruction
2.2 - Replicate Depot cds SubAgent Depot SubAgent Remote DMS Federating Agent
2.2 - Replicate Depot cds SubAgent Depot SubAgent
Target download initiation

1. Periodically the device manager client subagent running on all Tivoli common agents contact the device manager service federating agent (Or Central Device Management server). Device manager passes all pending jobs to the Tivoli common agent. The job contains the ID of the file to retrieve and instructions on how to install it. 2. The device manager client subagent passes the download instruction to the content delivery system subagent. 3. The content delivery system subagent contacts the management center distribution agent and requests a download plan. The download plan returned to the agent includes a list of depots and/or peers from which to download the file. See Figure 5-48 on page 291.
290
TPM
Database
SPB File Repository
Upload Depot Depot SubAgent
3.3 - Request & receive download plan Depot cds SubAgent Depot SubAgent Remote DMS Federating Agent Depot cds SubAgent Depot SubAgent
3.1 - Request & receive jobs
Target 1 cds SubAgent 3.2 DMS & JES SubAgents SPB Handler
Target 2 cds SubAgent 3.2 DMS & JES SubAgents SPB Handler
File download
1. The content delivery system subagent contacts one or more depots and/or peers and requests all or segments of the file. In Figure 5-49 on page 292 Target 1 is receiving parts of the file from both depots and from the peer Target 2.
291
2. When all parts of the file have been downloaded from the various depots and peers, the subagent re-assembles the file and notifies the Management Center that the download is complete. If peering is enabled the file is copied into the Tivoli common agents cache directory. This system can now act as a peer download server for other local agents. See Figure 5-49.
TPM
Database
SPB File Repository
Upload Depot Depot SubAgent 4.2 - cds Notification
Depot cds SubAgent Depot SubAgent Remote DMS Federating Agent
Depot cds SubAgent Depot SubAgent
4.1 - File segment download
4.1 - File segment download 4.1 - File segment download Target 1 cds SubAgent DMS & JES SubAgents SPB Handler 4.1 - File segment download Target 2 cds SubAgent DMS & JES SubAgents SPB Handler
292
Software installation
1. The device manager client subagent starts the appropriate subagent to start the unpacking and installation of the file, this instruction is actually passed via the JES subagent. For software package block software packages the SPBHandler subagent is used. See Figure 5-50.
Target 1 cds SubAgent DMS & JES SubAgents 5.1 SPB Handler SPB Handler Target 2 cds SubAgent DMS & JES SubAgents 5.1
Return results
1. Results of the distribution (success or failure) are passed from the SPB Handler to the dms sub agent. 2. The dms sub agent passes results back to the remote federating agent. 3. Remote federating agent periodically sends back all results to the device management server. 4. The results finally gets passed back to Tivoli Provisioning Manager. See Figure 5-51 on page 294.
293
TPM 6.4 - Results pass back to TPM Database
SPB File Repository
Upload Depot Depot SubAgent
6.3 - Results passed to DMS
Depot cds SubAgent Depot SubAgent Remote DMS Federating Agent
Depot cds SubAgent Depot SubAgent
6.2 Target 1 cds SubAgent DMS & JES SubAgents 6.1 SPB Handler
6.2 Target 2 cds SubAgent DMS & JES SubAgents 6.1 SPB Handler
The descriptions of the various sub agents in the above steps are somewhat simplified to make the text and drawings easier to read. A fuller description of the sub agents can be found in Chapter 6, Common Agent Services on page 307.
294
5.11 Case study: A banking environment

For this case study we take an imaginary company that provides banking services and discusses how Tivoli Provisioning Manager can be configured and used to manage software distribution to their managed systems. The primary focus is deciding on an appropriate infrastructure to support their software distribution requirements. Any similarity between any this imaginary company and any real company is not intended nor should be assumed.
5.11.1 The company

As illustrated in Figure 5-52 on page 296, the Bank, lets call them XYZ Corporation, have two main locations, the Americas head office is in the USA and the European headquarters is in UK. Both these locations have data centers and the UK center has a call center with several hundred workstations to be managed. The Tivoli Provisioning Manager server is located in and managed from the USA data center. XYZ Corporation have a number of branches in America and the UK, All branches have a server running on Windows 2003 with five to 20 workstations. All workstation class systems run Microsoft Windows and are part of a Microsoft Active Directory environment. The network is configured so that there is a fast connection between the two data centers and between the UK data centre and the call center, but the links to the branches are relatively slow, each branch has a distinct subnet. DNS is split into two main sub domains, us.xyz.com and uk.xyz.com. There is a sub domain cc.uk.xyz.com but no sub domains are defined for branches.
295
USA Data Center

Fast connection
UK Data Center
Fast connection
Slow connections
Slow connections
UK Call Center
Branch AM01
Branch AM02
Branch AM03
Branch EU01
Branch EU02
Branch EU03
Figure 5-52 XYZ Corporation locations
5.11.2 Requirements
XYZ Corporation need to distribute two sorts of files to their managed servers in the data centres, call centers and to all branch systems. Firstly there are operating system and application patches, these are generally between 10Mb and 100Mb each and are planned in advance and installed during predetermined overnight windows. The second type is the frequent distribution of small data files to the branch systems for the banking application. It is very important not to interrupt the day to day operation of the branches, much of this is real time communication between the branch workers and the central systems, branch systems must remain responsive at all times.
5.11.3 Infrastructure component overview

Now we look at defining the infrastructure to support the requirements. All components are discussed in detail.
Tivoli Provisioning Manager server

As mentioned above, the Tivoli Provisioning Manager server is located in the US datacenter. An IBM server running on AIX, is installed with lots of memory and enough disk space to store all the software packages in the file repository.
296
All firewalls are configured to allow all the target machines to contact the Tivoli Provisioning Manager server to allow the transfer of dynamic content delivery and device management service requests, download plans, jobs and results. The Tivoli Provisioning Manager server is named tpm.us.xyz.com.
Dedicated depot servers

Two central depot servers is allocated, one in USA and one in UK data center. The USA depot is designated as the preferred upload server. One further dedicated depot is allocated for the UK call center to handle all distributions to that site. These depot servers are named usadepot1.us.xyz.com, ukdepot1.uk.xyz.com and ukdepot2.cc.uk.xyz.com respectively.
Shared depot servers

There is no need to purchase a dedicated depot server for each branch. As all branch offices have an existing server the depot functionality is co-hosted on this device. Checks must be made to ensure adequate disk space and memory is available so the core functionality is not adversely affected. It is planned that branch depot servers also hosts the device management service remote federated agent functionality when it is available. This reduces the amount of WAN traffic generated. Branch servers have names based upon their geography and branch number such as brnuk01srv.uk.xyz.com or brnam99srv.us.xyz.com.
Targets
All systems to be managed have the Tivoli common agent installed. This pushes out after the devices are discovered. XYZ Corporation are considering the use of Tivoli Provisioning Manager to manage their operating system installation, at this stage the installation of the Tivoli common agent is performed at OS install time.
Regions
As defined earlier in 5.6.3, Regions on page 264, regions are used to group depot servers that are located near one another to optimize upload, replication, and download times. Several regions are created in this environment.
297
USCentralRegion Encompasses the central USA depot usadepot1.us.xyz.com and data center servers. UKCentralRegion Encompasses the central USA depot usadepot1.us.xyz.com and data center servers. AMBranchRegion Includes all depots in the USnn branches. UKBranchRegion Includes the central UK depot ukdepot2.uk.xyz.com and all depots in the UKnn branches. UKCallCenterRegion Includes the call center depot ukdepot2.uk.xyz.com.
Zones
Each branch is defined as a zone that includes all TCP/IP addresses in the branch subnet. These zones are named in a similar way to the branch servers, for example BranchUK01Zone. These zone are defined to contain all traffic within each branch as much as possible. One zone is created for the call center that includes the callcenter.uk.xyz.com sub domain. Zones are created for the two data centers.
5.11.4 Infrastructure component detail

This section details the configuration of the infrastructure components described 5.11.3, Infrastructure component overview on page 296.
Depots
The full domain names of the host systems have been omitted to aid readability.
Table 5-1 Depot configuration Depot (hostname) Region Preferred upload server Yes No Bandwidth control Adaptive medium Adaptive medium Max connections 100 100 Domain served us.xyz.com uk.xyz.com
usdepot1 ukdepot1
USCentralRegion UKCentralRegion
298
Depot (hostname)
Region
Preferred upload server No No No
Bandwidth control Adaptive medium Adaptive low Adaptive low
Max connections 250 10 10
Domain served cc.uk. xyz.com uk.xyz.com us.xyz.com
ukdepot2 brnunnnsrv brnusnnsrv
UKCallCenterRegi on UKBranchRegion USBranchRegion
Regions
Apart from the description there are no configurable parameters for regions. The names are listed in Table 5-1 on page 298.
Zones
For all the zones the Minimize traffic in and out of the zone option is set. This ensures that when a distribution is performed the only traffic across the WAN is to the depot within the zone, the network traffic from depot to target is all local.
Table 5-2 Zone configuration Zone Region IP Range IP Domain Allow peering Yes No No No Minimize traffic in & out Yes Yes Yes No
UKCallCenterZone BranchUKnnZone BranchUSnnZone UKCentralZone
UKCallCenterRegion UKBranchRegion USBranchRegion UKCentralRegion
not set branch IP range branch IP range UK data center IP range US data center IP range
cc. uk.xyz.com not set not set not set
USCentralZone
USCentralRegion
not set
No
No
Peering is enabled within the call center as this allows the distribution load to be shared between the depot and a number of peers. Peering is not enabled in branches as there are only a small number of targets and this does not represent a significant load for the branch server. Peering is not enabled in data centers to ensure servers are not loaded unexpectedly.
299
The infrastructure components, regions and zones are shown in Figure 5-53.
Region: USCentralRegion Region: UKCentralRegion Region: UKCallCenterRegion UK Call Center US Data Center
TPM Server tpm.us.xyz.com Depot (Preferred Upload Server) usdepot1. us.xyz.com Depot (Preferred Upload Server) usdepot1. uk.xyz.com Depot ukdepot2. cc.uk.xyz.com
UK Data Center
Admin Admin Workstations Workstations
Data Center Admin Servers Workstations
Call Center Admin Workstations Workstations
Call Center Admin Workstations Workstations
Zone: USCentralZone, Scope: (ip range in Data Center)
Zone: UKCentralZone, Scope: (ip range in Data Center)
Zone: UKCallCenterZone, Scope: cc.uk.xyz.com
Region: USBranchRegion Branch US01 Branch USnn
Region: UKBranchRegion Branch UK01 Branch UKnn
Branch Server Depot brnus01srv .us.xyz.com
Branch Server Depot brnusnnsrv .us.xyz.com
Branch Server Depot brnuk01srv. uk.xyz.com
Branch Server Depot brnuknnsrv. uk.xyz.com
Branch Admin Workstations Workstations
Zone: BranchUS01Zone, Scope: (ip range in branch)
Zone: BranchUSnnZone, Scope: (ip range in branch)
Zone: BranchUK01Zone, Scope: (ip range in branch)
Zone: BranchUKnnZone, Scope: (ip range in branch)
Figure 5-53 Case study regions and zones
Groups
A number of groups are defined, these are used as targets for distributions. Compliance settings is applied at group level. Examples of the groups created are BranchUSallSrv, BranchUKallWks, BranchUK01Wks, CallCenterUKWks.
5.11.5 The logic behind this design

This infrastructure design is chosen to meet the customer requirements, the main consideration is limiting WAN traffic. Here is the explanation of what happens when various distributions occur.
300
Distribution to branch workstations

When a distribution to UK branches is performed the following process occur: 1. The software is published to both central depots. a. The distribution occurs first to usdepot1 as it is the preferred upload server. b. The files are replicated from usdepot1 to ukdepot1. 2. Software is published to all branch depots. a. Branch depots are not in the same region as any other depots but as a domain is assigned to each depot the publication flows to the branch depots from the local country depot. b. Distribution does not occur between branches as the Minimize traffic in & out of Zone option is set for branch zones. c. A maximum of 100 branch depots is updated at once, following the Max Connections setting on the central depots. 3. Software is installed to branch workstations. a. As there is a depot in each branch zone this is chosen to distribute the software to local systems. b. Peering is disabled to prevent loading the workstations. c. As the Minimize traffic in & out of Zone option is set the workstations does not seek to receive distributions from remote depots.
Distribution to UK call center

When a distribution to UK call center is performed the following process occur: 1. The software is published to the depot ukdepot2 in the call center. a. The distribution occurs first to usdepot1 as it is the preferred upload server. b. The files are replicated from usdepot1 to ukdepot2. 2. Software is installed to call center workstations. a. As there is a depot in the call center zone this is chosen to distribute the software. b. Max connections is set to 250, so up to this number of workstations can downloaded from depot ant one time. c. Peering is enabled so the first workstations to complete the download can act as peers to those that have not yet started. This helps to get the distribution performed quickly without overloading the depot.
301
d. Distribution does not occur from other depots as the Minimize traffic in & out of Zone option is set for the call center zone.
Distribution to data center servers

1. The software is published to both central depots. a. The distribution occurs first to usdepot1 as it is the preferred upload server. b. The files are replicated from usdepot1 to ukdepot1. 2. Software is installed to data center servers. a. Distribution occurs from the local depot as it is within the same zone. b. Peering is disabled to prevent loading the servers unnecessarily.
5.11.6 Keeping the estate up to date

XYZ Corporation likes to keep the application software in all their groups of computers in sync with each other, and have chosen to use compliance to help with this. Compliance will be defined and enforced at group level. For example, there are two software products TestAppOne and TestAppThree that need to be installed to all branch systems. A compliance check is added to the inventory group BranchAllWks, this group contains all the groups that in turn contain all the branch workstations in each branch. Figure 5-54 on page 303 shows a typical compliance check result after running a compliance inventory scan and compliance check. You can see that TestAppOne is installed on three out of four targets and TestAppThree is installed on only one.
302
Figure 5-54 Compliance check results
The recommendations for this check are shown in Figure 5-55 on page 304.
303
Figure 5-55 Recommendations
By approving and scheduling these recommendations the managed systems can be kept up to date. Reports are provided to provide management information on the compliance of the estate.
304
Figure 5-56 Standard compliance report
Additional reports can be created to show the level of detail required. For example, Figure 5-57 on page 306 shows a custom report that shows which computers are not software compliant. Definition of this report is available to download. See Not Software Compliant.xml.
305
Figure 5-57 Custom compliance report
Defining a regular schedule of inventory scans and compliance checks and following the recommendations the managed estate can be kept up to date.
306
Chapter 6.
Common Agent Services

Tivoli Provisioning Manager and Tivoli Provisioning Manager for Software 5.1 uses Tivoli common agent Services (Common Agent Services) for software distribution and desired state management. This chapter describes the various components of Common Agent Services which includes the agent manager, resource manager and Tivoli common agent (TCA). We describe installing, configuring and troubleshooting the TCA, and discuss the function of the agent manager. In particular, this chapter has the following sections: Common Agent Services overview on page 308 Agent manager on page 309 Tivoli common agent (TCA) on page 320
307
6.1 Common Agent Services overview

In general terms, an agent is a program that automatically performs some service, such as data collection. To take advantage of some Tivoli Provisioning Manager software management features, the Tivoli common agent must be installed on all managed endpoints. Figure 6-1 on page 308 shows the Common Agent Services architecture.
Figure 6-1 Common Agent Services
The goal of Common Agent Services is to reduce the cost of ownership by minimizing customer effort, by reducing the complexity of the deployment, and by using resources more efficiently. To accomplish this, the Tivoli common agent services architecture provides a shared infrastructure for managing the computer systems in your environment. This infrastructure has the following components:
308
Tivoli common agent Also referred as the common agent, the Tivoli common agent is a common container for all the subagents to run within. It enables multiple management applications to share resources when managing a system. Agent manager The agent manager is the server component of the Common Agent Services that provides functions that allow clients to get information about agents and resource managers. It enables secure connections between managed endpoints, maintains the database information about the endpoints and the software running on those endpoints, and processes queries against that database from resource managers. It also includes a registration service, which handles security certificates, registration, tracking of the Tivoli common agents and resource managers, and status collection and forwarding. Each product that uses Common Agent Services has its own resource manager and subagents. For example, Tivoli Provisioning Manager has a resource manager and subagents for software distribution and software inventory scanning.
Resource manager
6.2 Agent manager

The agent manager is the server component of the Tivoli common agent Services and must run on the same system as the Tivoli Provisioning Manager server. It enables secure connections between managed systems in your deployment, maintains the database of information about the managed systems and the software running on those systems, and processes queries against that database from resource managers. The agent manager has the following parts: The agent manager service The registry The agent recovery service
The agent manager service

The agent manager service is a network service, or servlet, that serves as a certificate and registration authority to provide authentication and authorization using X.509 digital certificates and the Secure Sockets Layer (SSL) protocol. It also processes queries against its registry of configuration information about Tivoli common agents and resource managers.
Chapter 6. Common Agent Services
309
Resource managers and common agents must register with the agent manager before they can use its services to communicate with each other. Resource managers are applications that use the Common Agent Services architecture to securely communicate with managed systems running the common agent service. The resource manager uses the services of the common agent to deploy and run its software on managed systems. Resource managers in Tivoli Provisioning Manager are the content delivery service (CDS), the dynamic device management service (DMS) and Tivoli Provisioning Manager itself. The registration service listens on port 9511. Subsequent secure communication between the agent manager and the agents goes over port 9512.
The registry
The registry is a database that contains the current configuration of all known common agents and resource managers. The registry contains the identity, digital certificates, and communication information for each resource manager, and the following information about common agents: The identity of every known common agent and its computer system. The digital certificate issued to each common agent. Basic configuration information about each common agent, including information about the type and version of the hardware and operating system. The status of each common agent. The last error or, optionally, a configurable number of errors, reported by each common agent. Communication parameters for the common agent, including the IP address, the port or ports for which the common agent is configured, and the supported protocol. The registry also contains information about every bundle and the common agents on which each bundle is installed. The information in the registry is updated by asynchronous events, such as the registration of common agents and resource managers, and by periodic updates from the common agent. The registry can be placed in a Cloudscape, a DB2 Universal Database Enterprise Server Edition or an Oracle database.
The agent recovery service

The agent recovery service is a network service that provides error logging for common agents that cannot communicate with other agent manager services. Common agents use an unsecured (non-SSL encrypted) HTTP connection to
310
communicate with the agent recovery service, which runs as a servlet on the agent manager server. Because the connection is unsecured, a common agent can always communicate with the agent recovery service, even when the common agent is incorrectly configured or has expired or revoked certificates. Common agents locate the agent recovery service using the unqualified host name TivoliAgentRecovery. Note: Your Domain Name System (DNS) server must map the host name TivoliAgentRecovery to the computer system where you installed the agent manager. This can be accomplished by defining a DNS alias to the host. The normal DNS lookup mechanism iterates through the domain search list for the common agent, appends each domain in the list to the unqualified host name, and then performs a DNS lookup to attempt to resolve the name. The agent recovery service listens for recovery messages on port 9513.
6.2.1 Ports used by the agent manager

In summary, Table 6-1 on page 311 shows port usage of the agent manager:
Table 6-1 Ports used by the agent manager Port 9511 9512 Use Registering Tivoli common agents and resource managers Providing configuration updates Renewing and revoking certificates Querying the registry for common agent information Requesting ID resets 9513 Agent Recovery service Unsecure Yes Connection Security Secure SSL Secure SSL with Client Authentication Configurable Yes Yes
If there is a firewall between the agent manager and the Tivoli common agents and resource managers in the infrastructure, configure the firewall for the following situations: Allow inbound traffic to the common agent on the common agent port. By default, this is port 9510. Allow inbound traffic to the agent manager on all of the agent manager ports. By default, this is ports 9511, 9512, and 9513.
311
6.2.2 Installing the agent manager

The installation of the agent manager is part of the Tivoli Provisioning Manager installation with the Topology Installer Launcher. We use AM_HOME below as the directory where the agent manager is installed, by default /usr/IBM/AgentManager on Unix, /opt/IBM/AgentManager on Linux and C:\Program Files\IBM\Agent Manager on Windows. Note: The agent manager installs in C:\Program Files\IBM\Agent Manager, even if Tivoli Provisioning Manager is given a different destination path. The properties file created at install-time is located in $AM_HOME/install/AMInstall.properties, as shown below:
Example 6-1 Agent manager properties file
################################## # AM Install Properties file # # ################################## Cell=cairoNode01Cell Node=cairoNode01 ## PortCount=3 HostName1=* PortNumber1=9511 SSLEnabled1=true SSLProfileName1=cairoNode01/AgentManagerSSL KeyFileName1=C:/Program Files/IBM/AgentManager/certs/agentManagerKeys.jks TrustFileName1=C:/Program Files/IBM/AgentManager/certs/agentManagerTrust.jks ClientAuth1=false ## HostName2=* PortNumber2=9512 SSLEnabled2=true SSLProfileName2=cairoNode01/AgentManagerClientAuthSSL KeyFileName2=C:/Program Files/IBM/AgentManager/certs/agentManagerKeys.jks TrustFileName2=C:/Program Files/IBM/AgentManager/certs/agentManagerTrust.jks ClientAuth2=true
312
## HostName3=* PortNumber3=9513 SSLEnabled3=false ## HostName4=* PortNumber4=80 SSLEnabled4=false ## VirtualHostName=AgentManagerHost ApplicationServerName=server1 Type=db2 JDBCDriverType=type2 DBUserID=db2admin DBName=tc JDBCProviderName=AgentJDBCProvider DataSourceName=AgentRegistry AuthDataAlias=AgentRegistryDBAuth JDBCOracleDriverPath=C:/IBM/SQLLIB/jdbc/lib JNDIName=jdbc/AgentRegistry ServerName=cairo.itsc.austin.ibm.com PortNumber=50000 ## AppCount=2 AppType1=AM ApplicationName1=AgentManager WarFileName1=C:/Program Files/IBM/AgentManager/install/image/AgentManager.war ContextRoot1=/AgentMgr ## AppType2=ARS ApplicationName2=AgentRecoveryService WarFileName2=C:/Program Files/IBM/AgentManager/install/image/AgentRecoveryService.war ContextRoot2=/AgentRecoveryService ## AMInstallLocation=C:/Program Files/IBM/AgentManager ## CASInstall.DBType=db2 CASInstall.DBName=tc CASInstall.DBConnectionMode=local CASInstall.DBLocation=C:\IBM\SQLLIB CASInstall.DBRuntimeUserID=db2admin CASInstall.DBAdminUserID=db2admin CASInstall.DBHostname=cairo.itsc.austin.ibm.com
313
CASInstall.DBPort=50000 ## CASInstall.WASLocation=C:/IBM/WebSphere/AppServer CASInstall.WASProfileLocation=C:/ibm/tivoli/tpm/tioprofile CASInstall.WASCellName=cairoNode01Cell CASInstall.WASNodeName=cairoNode01 ## CASInstall.AgentManagerHostname=cairo.itsc.austin.ibm.com CASInstall.WASAppServerName=server1 CASInstall.RegistrationPort=9511 CASInstall.SecurePort=9512 CASInstall.PublicPort=9513 CASInstall.DisablePort80=true CASInstall.StartAfterInstall=false CASInstall.StartAfterReboot=false ## CASInstall.CertificateType=new CASInstall.CertificateAuthorityName=TivoliAgentManagerCA CASInstall.SecurityDomain=itsc.austin.ibm.com ## CASInstall.AgentManagerContextRoot=/AgentMgr CASInstall.AgentRegistrationServiceContextRoot=/AgentRecoveryService ## CASInstall.InstallType=install ## DatabaseBinDir=C:\IBM\SQLLIB DatabaseDriver=type2 DatabaseDriverJar=C:/IBM/SQLLIB/java/db2java.zip DatabaseDb2InstanceName=DB2 JDBCDB2DriverPath=C:/IBM/SQLLIB/java
6.2.3 Troubleshooting the agent manager

When you are troubleshooting installation errors, you can find installation logfiles in $AM_HOME/logs. To verify that agent manager is installed correctly. Run the following workflow: TCA_PingAgentManager The agent manager runtime logging can be found in the the standard WAS SystemOut.log and SystemErr.log files on an Enterprise installation, located on the $TIO_HOME/tioprofile/logs/server1 by default.
314
On the lightweight infrastructure the agent manager logs into the LWI_HOME/logs/rcp.log.0 file, by default C:/Program Files/IBM/tivoli/tpm/logs/rcp.log.0. Installation logs can be found in the LWI_HOME\runtime\agentmanager\logs.
HealthCheck
You can verify correct function of the agent manager with the HealthCheck.sh/bat script in the $AM_HOME/toolkit/bin directory. See Example 6-2 on page 315.
Example 6-2 HealthCheck script
tioadmin@CAIRO /cygdrive/c/Program Files/ibm/AgentManager/toolkit/bin $ cmd /c HealthCheck.bat -RegistrationPW ****** A subdirectory or file cert already exists. 1 file(s) copied. Tool Launcher is trying to instantiate Command line tool com.tivoli.cas.manager.tools.HealthCheck ... Command Line Tool com.tivoli.cas.manager.tools.HealthCheck succesfully instantiatied. Sep 5, 2006 9:21:14 AM CDT Command Line Tool initialized with log parameters: logDir[] logFilePrefix[] Sep 5, 2006 9:21:14 AM CDT Arguments passed to Command Line Tool: -HOST localhost -RegistrationPW itso05 Sep 5, 2006 9:21:16 AM CDT Initializing configuration with file:c:\Program Files\ibm\AgentManager\toolkit\bin\config\endpoint.properties Sep 5, 2006 9:21:18 AM com.tivoli.agentmgr.client.proxy.WSDLClient$AddressCacheItem tryConnect INFO: NOTE ==>Connected to host=localhost on port=9513 Sep 5, 2006 9:21:18 AM com.tivoli.agentmgr.client.proxy.WSDLClient$AddressCacheItem directConnect INFO: Directly connected Sep 5, 2006 9:21:18 AM com.tivoli.agentmgr.client.proxy.WSDLClient$AddressCacheItem tryConnect INFO: NOTE ==>Connected to host=localhost on port=9511 Sep 5, 2006 9:21:18 AM com.tivoli.agentmgr.client.proxy.WSDLClient$AddressCacheItem directConnect INFO: Directly connected Agent Manager Name: ibm-cdm:///CDM-ManagementSoftwareSystem/TivoliGUID=A1CD3900314411DB82570011099B9859,I nstallPath=file%3A%2F%2F%2FC%3A%2FProgram%20Files%2FIBM %2FAgentManager,Feature=CTGEM Registration.domain = itsc.austin.ibm.com CA.keyRing.name = certs/CARootKeyRing.jks CA.Certificate.Root.Alias = rootcert CA.Key.Root.Alias = rootkey CA.CRL.TimeToLive = 24
315
CA.CRL.filename = certs/CertificateRevocationList Registration.Agent.Reregistration.Policy = Any Registration.Agent.Certificate.Duration = 365 Registration.Manager.Certificate.Duration = 3600 CA.Certificate.graceTime = 1380 Config.Server.Host = 9.3.5.56 Config.Server.Port = 9512 Config.URI = /AgentMgr/ConfigurationUpdate CertManagement.Host = 9.3.5.56 CertManagement.Renewal.Port = 9512 CertManagement.Renewal.URI = /AgentMgr/CertificateRenewal CertManagement.CRL.Port = 9513 CertManagement.CRL.URI = /AgentMgr/CRLRequest CertManagement.Revoke.Port = 9512 CertManagement.Revoke.URI = /AgentMgr/CertificateRevocation AgentQuery.Host = 9.3.5.56 AgentQuery.Port = 9512 AgentQuery.URI = /AgentMgr/AgentQuery AgentConfiguration.Host = 9.3.5.56 AgentConfiguration.Port = 9512 AgentConfiguration.URI = /AgentMgr/AgentConfiguration AgentManagerQuery.Host = 9.3.5.56 AgentManagerQuery.Port = 9511 AgentManagerQuery.URI = /AgentMgr/AgentManagerQuery Registration.Host = 9.3.5.56 Registration.Port = 9511 Registration.URI = /AgentMgr/Registration Status.timeToLive = 0 ARS.directory = C:/Program Files/IBM/AgentManager ARS.port.base = 9511 ARS.port.secure = 9512 ARS.port.public = 9513 ARS.URI.root = /AgentMgr ARS.security.enabled = true Status.Authorization.Required = true Access.restriction.revocation = true Access.restriction.Configuration = true Query.Agent.Max.Return = -1 Query.Database.Type = db2 ARS.version = 1.3.0.26 Config.Listener.Manager = com.tivoli.agentmgr.spi.providers.makeAgentRegistryUpdate, com.tivoli.agentmgr.cert.AgentStatusChangeListener Config.Listener.Agent = com.tivoli.agentmgr.spi.providers.makeAgentRegistryUpdate
316
Registration.Listeners.Manager.Request = com.tivoli.agentmgr.registration.AuthorizationValidator, com.tivoli.agentmgr.registration.AuthorizationTestOnly, c om.tivoli.agentmgr.registration.AgentReregistrationTest Registration.Listeners.Manager.Issue = com.tivoli.agentmgr.registration.StoreCertificateListener Registration.Listeners.Agent.Request = com.tivoli.agentmgr.registration.SimplePWRequestValidator, com.tivoli.agentmgr.registration.AuthorizationTestOnly, com.tivoli.agentmgr.registration.AgentReregistrationTest Registration.Listeners.Agent.Issue = com.tivoli.agentmgr.registration.StoreCertificateListener Sep 5, 2006 9:21:19 AM CDT Health Check passed. Sep 5, 2006 9:21:19 AM CDT Command Line Tool execution successful. tioadmin@CAIRO /cygdrive/c/Program Files/ibm/AgentManager/toolkit/bin $ The HealthCheck script must be launched from the $AM_HOME/toolkit/bin directory Also the https://tpmhostname:9511/AgentMgr/Info URL shows information on the configuration of the agent manager. Note: It is not recommended to use the The AgentMgr/Info page. The page is not yet translated.
Collecting log files for support

The $AM_HOME/toolkit/bin directory contains a tool to collect and zip logfiles from the agent manager to send to IBM support. The LogCollector script must be called from the $AM_HOME/toolkit/bin directory. The zip file is created in the $AM_HOME directory.
Example 6-3 LogCollector script
tioadmin@CAIRO /cygdrive/c/Program Files/ibm/AgentManager/toolkit/bin $ cmd /c LogCollector.bat Tool Launcher is trying to instantiate Command line tool com.tivoli.cas.manager.tools.was.WASLogCollector ... Command Line Tool com.tivoli.cas.manager.tools.was.WASLogCollector succesfully instantiatied. Sep 5, 2006 10:21:14 AM CDT Command Line Tool initialized with log parameters: logDir[] logFilePrefix[]
317
Sep 5, 2006 10:21:14 AM CDT Sep 5, 2006 10:21:15 AM CDT
Arguments passed to Command Line Tool: Command Line Tool execution successful.
tioadmin@CAIRO /cygdrive/c/Program Files/ibm/AgentManager/toolkit/bin $ unzip -l ../../LogCollector.zip Archive: ../../LogCollector.zip Length Date Time Name ----------------56958 09-05-06 10:21 LogCollector_notes.txt 677 09-05-06 10:21 AM\AMReturnValues.log 55856 09-05-06 10:21 AM\am_install.log 27268 09-05-06 10:21 AM\am_upgrade.log 0 09-05-06 10:21 AM\auth_stderr.log 587 09-05-06 10:21 AM\auth_stdout.log 0 09-05-06 10:21 AM\certGen_stderr.log 2375 09-05-06 10:21 AM\certGen_stdout.log 9885 09-05-06 10:21 AM\datastore.out 0 09-05-06 10:21 AM\datastore_stderr.log 10840 09-05-06 10:21 AM\datastore_stdout.log 0 09-05-06 10:21 AM\db_stderr.log 9886 09-05-06 10:21 AM\db_stdout.log 10681 09-05-06 10:21 AM\ds_install.log 0 09-05-06 10:21 AM\encrypt_stderr.log 687 09-05-06 10:21 AM\encrypt_stdout.log 451302 09-05-06 10:21 AM\guid_install.log 0 09-05-06 10:21 AM\guid_stderr.log 0 09-05-06 10:21 AM\guid_stdout.log 9821 09-05-06 10:21 AM\msg_EPM_Install.log 0 09-05-06 10:21 AM\serverStatus_err.log 402 09-05-06 10:21 AM\serverStatus_out.log 52497 09-05-06 10:21 AM\trace_EPM_Install.log 0 09-05-06 10:21 AM_jacl\amApp_err.log 4276 09-05-06 10:21 AM_jacl\amApp_out.log 0 09-05-06 10:21 AM_jacl\appServer_err.log 1602 09-05-06 10:21 AM_jacl\appServer_out.log 0 09-05-06 10:21 AM_jacl\checkcell_err.log 511 09-05-06 10:21 AM_jacl\checkcell_out.log 0 09-05-06 10:21 AM_jacl\checknode_err.log 507 09-05-06 10:21 AM_jacl\checknode_out.log 0 09-05-06 10:21 AM_jacl\jdbc_err.log 2646 09-05-06 10:21 AM_jacl\jdbc_out.log 0 09-05-06 10:21 AM_jacl\ssl_err.log 1362 09-05-06 10:21 AM_jacl\ssl_out.log 0 09-05-06 10:21 AM_jacl\virHost_err.log 1184 09-05-06 10:21 AM_jacl\virHost_out.log
318
507 2800 32 2097152 333 1958 6586 266 118 3709 1519 369 168 12337 2220 372 486 1479 796 362 2372 883 580 369 2680 0 22993 20237 20582 14859 2426 21280 21412 2516 19347 15501 11973 14381 3502 11288 10401 1167 0 0 4
09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06
10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21
AM_datastore\datastore.rsp AM_install\AMInstall.properties AM_guid\os.guid WAS\activity.log WAS\amjrte_config.log WAS\backupConfig.log WAS\collect_metadata.log WAS\createDefaultServer.log WAS\createshortcutforprofile.log WAS\defaultapp_config.log WAS\defaultapp_deploy.log WAS\filetransfer_config.log WAS\hamanager_config.log WAS\ivtClient.log WAS\ivt_config.log WAS\mejb_config.log WAS\portdef.props WAS\query_config.log WAS\scheduler.cal_config.log WAS\server1_service.log WAS\serverStatus.log WAS\SIBDefineChains.log WAS\SIBDeployRA.log WAS\webui_config.log WAS\wsadmin.traceout WAS\wsadmin.valout WAS_ffdc\server1_296f84b4_06.09.01_14.19.13_0.txt WAS_ffdc\server1_2edfc4bb_06.08.31_11.56.11_0.txt WAS_ffdc\server1_35d484ba_06.08.31_18.40.55_0.txt WAS_ffdc\server1_3f8284b8_06.08.30_18.06.37_0.txt WAS_ffdc\server1_65dd84b9_06.08.29_09.49.52_0.txt WAS_ffdc\server1_65dd84b9_06.09.01_15.13.05_0.txt WAS_ffdc\server1_65dd84b9_06.09.01_15.13.05_1.txt WAS_ffdc\server1_708484b9_06.08.31_13.59.56_0.txt WAS_ffdc\server1_708484b9_06.08.31_16.50.09_0.txt WAS_ffdc\server1_70d7c4b9_06.08.29_09.59.24_0.txt WAS_ffdc\server1_70d7c4b9_06.08.29_09.59.25_0.txt WAS_ffdc\server1_70d7c4b9_06.08.29_09.59.25_1.txt WAS_ffdc\server1_70d7c4b9_06.08.29_09.59.25_2.txt WAS_ffdc\server1_70d7c4b9_06.08.29_09.59.25_3.txt WAS_ffdc\server1_exception.log WAS_Server1\DMSMsg1.log WAS_Server1\native_stderr.log WAS_Server1\native_stdout.log WAS_Server1\server1.pid
319
2183 2283 11052 0 56590 58056 22432 17015 0 133071 44639 3124 138058 157414 114389 70578 2720 318248 112571 12306 649 649 -------4344159
09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06 09-05-06
10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21 10:21
WAS_Server1\serverStatus.log WAS_Server1\startServer.log WAS_Server1\stopServer.log WAS_Server1\SystemErr.log WAS_Server1\SystemErr_06.08.29_23.00.00.log WAS_Server1\SystemErr_06.08.30_23.00.00.log WAS_Server1\SystemErr_06.08.31_23.00.00.log WAS_Server1\SystemErr_06.09.01_23.01.00.log WAS_Server1\SystemErr_06.09.02_23.00.00.log WAS_Server1\SystemErr_06.09.03_23.00.00.log WAS_Server1\SystemErr_06.09.04_23.00.00.log WAS_Server1\SystemOut.log WAS_Server1\SystemOut_06.08.29_23.00.00.log WAS_Server1\SystemOut_06.08.30_23.00.00.log WAS_Server1\SystemOut_06.08.31_23.00.00.log WAS_Server1\SystemOut_06.09.01_23.01.00.log WAS_Server1\SystemOut_06.09.02_23.00.00.log WAS_Server1\SystemOut_06.09.03_23.00.00.log WAS_Server1\SystemOut_06.09.04_23.00.00.log WAS_AM\AgentManager.properties WAS_AM\ibm-web-ext.xmi WAS_CONFIG_AM\ibm-web-ext.xmi ------104 files
Determining the version of agent manager

To determine the version of the agent manager, use the GetAMInfo command, which is located in the AM_HOME/bin directory. On Windows systems, it has the .bat extension (GetAMInfo.bat). On AIX, Linux, and Solaris systems, it has the .sh extension (GetAMInfo.sh). Administrator@CAIRO /cygdrive/c/Program Files/ibm/AgentManager/bin $ ./GetAMInfo.bat CTGEM2124I Agent Manager: version 1.3.1.6 build 200609140622 CTGEM2124I Agent Recovery Service: version 1.3.1.6 build 200609140622
6.3 Tivoli common agent (TCA)

Tivoli Provisioning Manager uses Tivoli common agent (also referred as common agent) for software management features, including software distribution and software compliance management.
320
The common agent consists of Common Agent Services code and product-specific subagent code. For example, Tivoli Provisioning Manager includes subagents for deploying software and obtaining software inventory from managed endpoints. The product-specific subagents consist of one or more OSGi bundles. A bundle is an application that is packaged in a format defined by the Open Services Gateway Initiative (OSGi) Service Platform specification, which is implemented in a lightweight runtime based on WebSphere Everywhere Deployment technology. The Common Agent Services code is installed once on a managed endpoint. For example, if you have two management applications on the same endpoint (application A and application B), the Common Agent code is installed only once on the endpoint. However, there will be two product-specific subagents: one for application A and one for application B. The Tivoli common agent provides these features: Continuous operation. Self-healing features ensure that the common agent and subagents are always available. If the common agent stops, a "watchdog" process called the nonstop service automatically restarts it. A single set of security credentials and a common security infrastructure for all management applications. Automated management of security credentials. When common agent certificates near their expiration date, they are automatically renewed. Deployment and life cycle management of subagents. Resource managers can remotely install, upgrade, patch, or uninstall bundles on any common agent. This helps keep the common agent deployment current without having to take explicit action on each common agent system. Common agent health monitoring and configuration monitoring. The common agent has a "heartbeat" function that sends periodic status and configuration reports to the agent manager. The common agent allows any subagent to participate and to provide status information. Management applications can register to receive these updates. Updates are initiated by certain bundle events and periodically by the common agent. You can turn off periodic updates or control the frequency of updates. The default frequency is 24 hours. The common agent contacts the agent manager and reports its status and any configuration changes at these times: When a common agent starts or stops. After a configurable period of time. The default is 24 hours. Any time a bundle is installed, upgraded, or removed.
321
6.3.1 The authority needed to install the common agent

To install and run the common agent, you must log in as a user with the following authority: On Windows systems You must have Administrator authority and the following rights: Act as part of the operating system Log on as a service The common agent service runs either as the local system account or as an account that you specify. If you specify an account, it must be a member of the Administrators group and have the above rights: On AIX, Linux, and Solaris systems You must be logged in as the root user. After the common agent is installed, a resource manager can deploy subagents to a common agent using the standard security mechanisms of the Common Agent Services.
6.3.2 TCP/IP ports used by the common agent

Table 6-2 on page 322 lists the port numbers that are used by the common agent and states the security used by connections to each port. You can change any of the common agent port numbers.
Table 6-2 TCP/IP ports used by common agent Port 9510 9514 9515 Use The common agent The non-stop service The non-stop service Connection Security Secure SSL with Client Authentication This port is bound to localhost This port is bound to localhost Configurable Yes Yes Yes
6.3.3 Installing the common agent

When you install the common agent from Tivoli Provisioning Manager, the common agent and Tivoli Provisioning Manager subagents that the common agent will host are all installed on the managed system. Note: Installing the common agent on the Tivoli Provisioning Manager server, where the agent manager is also installed, is not supported. Version 1.3 of the Tivoli common agent must be used with Tivoli Provisioning Manager.
322
Service access points and subagent bundles

There are two service access points (SAPs) that are associated with installing the common agent and communicating with it.
Common agent service access point

When the common agent is installed, Tivoli Provisioning Manager creates a common agent SAP and sets it as the default SAP for file-transfer and execute-command device operations. This SAP type is defined as ipv4/CommonAgent. The common agent service access point (SAP) supports the following functions: Running commands and copying files: The common agent SAP supports the logical device operations Device.Execute.Command and Device.CopyFile. Workflows use these logical device operations to run commands on endpoints and copy files between the Tivoli Provisioning Manager server and an endpoint. Running scriptlets: Scriptlets are a list of commands embedded in a workflow that can be run without user interaction. Tivoli Provisioning Manager uses a Java Virtual Machine (JVM) on the Tivoli Provisioning Manager server to run scriptlets. The JVM is a local daemon that connects to the common agent SAP on an endpoint to perform scriptlet actions. By default the JVM starts when the Tivoli Provisioning Manager server starts. It listens for Telnet requests from localhost on port 5191 by default. You can edit the values in the file TIO_HOME/config/agentShellServerConfig.properties that determine if the JVM starts when Tivoli Provisioning Manager starts, and the port number for monitoring Telnet requests. The common agent SAP is created as a part of the common agent installation process. Tivoli Provisioning Manager can perform this operation using default SAPs for the Device.Execute.Command and Device.CopyFile device operations, or it can create and use an RXA SAP if default SAPs do not exist. For more information about RXA and how it connects to target endpoints to perform common agent installation, see Remote Execution and Access service access point.
Remote Execution and Access service access point

Tivoli Provisioning Manager uses the Remote Execution and Access (RXA) Service Access Point (SAP) to install the common agent, if default SAPs required to install it are not configured for the target system. This SAP type is defined as ipv4/RXA. Whether or not RXA is used to communicate with the endpoints depends on your input on the Install common agent page, as follows:
323
If you provide credentials on the Install common agent page, RXA will be used. A service access point (SAP) for the RXA protocol is installed and set up as the default SAP. Target capabilities are set up automatically. If you do not provide credentials on the Install Common Agent page, it is assumed that a SAP is already in place. In this case, you must set up the target capabilities prior to installing the common agent. The RXA SAP provides authentication with a user ID and password, and detects and uses existing configured protocols (SSH or Windows SMB) to install the common agent. Like the CommonAgent SAP, the RXA SAP supports the Device.Execute.Command and Device.CopyFile device operations. However, the RXA SAP is used only for installation of the common agent. Use the CommonAgent SAP for other endpoint operations. If RXA is used to communicate with the target endpoints, the following RXA prerequisites must be met: Remote registry administration is enabled on the endpoints. The default hidden administrative disk shares (such as C$ and D$) are required. Simple File Sharing must be disabled for RXA on Windows XP Professional. Both ports 135 (RPC) and 139 (NetBIOS over TCP/IP) is enabled on the endpoints, to ensure successful communication through RXA. If you are using Windows XP Professional, you need to disable Simple File Sharing for remote execution and access (RXA). To disable Simple File Sharing: i. In a Windows Explorer window, click Tools > Folder Options, and then click the View tab. ii. In the Advanced settings list, clear the Simple File Sharing check box. iii. Click OK.
Subagent bundles
Tivoli Provisioning Manager bundles for subagents are installed when you install the common agent. It an automation package with the following bundles to support the functions of the common agent service access point:
Tivoli Provisioning Manager Core agent

TivoliCommonAgent-core COP-CommonAgent-TPM.jar
324
Scalable File Distribution

Content Delivery Service CDSClientAPIBundle.jar CDSDepotServer.jar
Job-processing subagents
dms-client-subagent httpadpator.jar httpsadaptor.jar osgiagent.jar syncml-core.jar syncml-dm.jar TPMAgentExt.jar EventAdmin.jar: jes.jar:
event-subagent jes-subagent
Scanning subagents
SCMCollectorAgent SCMCollectorAgent_<os>.jar CitScannerAgent_<os>.jar citBundle.jar CitScannerAgent
SPB-processing subagents
SPBHandler spb_handler_<os>.jar dsm_utils.jar: DSMUtils
Installing the agent

To install Tivoli common agent you need to: 1. Click Software Management Install Common Agent. The install Common Agent Page is shown as seen in Figure 6-2 on page 326.
325
Figure 6-2 Install common agent
2. In the Task Name field type a relevant name for your install task. This name will be used to identify the task and help you monitor the status of the task in the Track Task page. 3. As you can see the Tivoli common agent Stack which installs the Tivoli common agent and Tivoli Provisioning Manager subagents is selected by default. 4. You can now select the computers where you need to install the agent by selecting the machine. By default the display is set by Group you will need to change it to By Computer to see all the machines. On the right hand side a Selected Computers list is displayed
326
Restriction: In GA version of Tivoli Provisioning Manager V5.1, Tivoli Provisioning Manager server is not supported with a TCA. Do not install TCA on a Tivoli Provisioning Manager server. Depot Servers are subagents of TCA hence TCA is already installed on a depot server and will fail if TCA is attempted to be pushed. For more details refer to Creating a depot on page 261. 5. By default the system uses the credentials used to discover the device. If you need to provide separate credential to install the machine you can click the check box and provide new credentials to install the common agent. 6. In the Schedule section, click Now to run the common agent installation task immediately, or specify the date and time when you want the task to start. 7. Click Submit. Once the task is submitted you can track the progress of your install from Track task window as seen in Figure 6-3 on page 328. Further details of the task can be seen by clicking the Request ID link in the task. Note: By default single target will get installed at a time. This is controlled by global setting variable default concurrency level. You can change the variable by clicking System Management --> Global Settings ---> Variables In Figure 6-3 on page 328 yo can see three machines are installed simultaneously due to the variable setting increased to 3. The agent is installed in Windows: C:\Program Files\Tivoli\ep AIX: /usr/tivoli/ep Other operating systems: /opt/tivoli/ep
327
Figure 6-3 Track common agent install task
On Windows during the install the agent creates a temporary directory called tcatemp. This directory is used to push the common agent installable file and final install is initiated from this directory. Here is the directory extract from one of our installs as seen in Example 6-4 on page 328.
Example 6-4 tcatemp
09/06/2006 09/06/2006 07/13/2006 07/13/2006 09/06/2006
05:20 05:20 08:54 08:54 05:20
PM PM PM PM PM
<DIR> <DIR>
<DIR>
. .. 523 BTCJ010300.sys 20,508 caInstall.rsp cert
328
09/06/2006 05:20 PM 82,197,228 common_agent_1.3.0.26_windows_full_200607131958.exe 09/06/2006 05:20 PM <DIR> guid 09/06/2006 05:20 PM <DIR> jre 07/13/2006 08:54 PM 40,964,865 setup.exe 09/06/2006 05:20 PM 18,809 uncompress.log 09/06/2006 05:20 PM <DIR> utility Note: During the time of writing this redbook the agent install stack pushed almost 123MB of installable code.
Endpoint properties
Endpoint properties file, shown below, is located under $TCA_INSTALL\runtime\agent\config.
Example 6-5 Endpoint.properties file
#Agent Properties #Wed Sep 27 14:10:33 CDT 2006 CertManagement.Revoke.URI=/AgentMgr/CertificateRevocation ARS.URI.root=/AgentMgr CertManagement.Revoke.Port=9512 ep.port=9510 Registration.Server.Port=9511 AgentManagerQuery.URI=/AgentMgr/AgentManagerQuery AgentConfiguration.Host=9.3.5.56 deployer.subagent.count=0 CertManagement.CRL.URI=/AgentMgr/CRLRequest AgentManager.ID=ibm-cdm\:///CDM-ManagementSoftwareSystem/TivoliGUID\=8D 31A2004DD311DBAC9D0011099B9859,InstallPath\=file%3A%2F%2F%2FC%3A%2FProg ram%20Files%2FIBM%2FAgentManager,Feature\=CTGEM ARS.port.disablePort80=null agent.label=kcwc12w CertManagement.Host=9.3.5.56 ARS.version=1.3.1.6 AgentQuery.Host=9.3.5.56 Access.restriction.Configuration=true AgentQuery.URI=/AgentMgr/AgentQuery evr.last.reported.version=1.3.1.6 ipaddress.poll.timeinterval=300 Access.restriction.revocation=true AgentConfiguration.URI=/AgentMgr/AgentConfiguration Update.SystemBundle=1 agent.version=1.3.1.6
329
Registration.Host=9.3.5.56 ARS.port.public=9513 Query.Database.Type=db2 Query.Agent.Max.Return=-1 Key.Algorithm.Name=RSA AgentManagerQuery.Port=9511 Registration.Server.Host=9.3.5.56 Registration.Server.PW=mNVOW+/ggOo\= Config.Server.Port=9512 Config.URI=/AgentMgr/ConfigurationUpdate CertManagement.CRL.Port=9513 Status.Authorization.Required=true agent.install.date=1159384212062 agent.ssl.truststore.download=true ServiceAcctID=Administrator ARS.port.secure=9512 AgentConfiguration.Port=9512 AgentQuery.Port=9512 ServiceName=IBMTivoliCommonAgent0 CertManagement.Renewal.URI=/AgentMgr/CertificateRenewal ARS.port.base=9511 ARS.security.enabled=true CertManagement.Renewal.Port=9512 Status.timeToLive=0 Registration.URI=/AgentMgr/Registration ARS.directory=C\:/Program Files/IBM/AgentManager AgentManagerQuery.Host=9.3.5.56 Config.Server.Host=9.3.5.56 Registration.Port=9511 Apart from the main endpoint properties, each subagent has its own properties cdsclient.properties ctiscanner.properties jes.properties scm.properties tpm.properties Example 6-6 on page 330 jes.properties file allows you to change the default polling interval of TCA from 1hour (01\:00) to say 5 minutes (00\:05), as seen in the file.
Example 6-6 jes.properties file
#Wed Sep 27 14:13:05 CDT 2006 PollingEnabled=true
330
PollingEnd=02\:00 PollingInterval=00\:05 ClientPW=tpmpassword Addr=https\://9.3.5.56\:9045/dmserver/SyncMLDMServlet UserName=tpmuser PollingStart=02\:00 LogSize=200 Important: Even though the polling interval is reduced to say 5 minutes the distribution to this target may not occur for more than 10 minutes because, when you submit your job via DMS, it is submitted to the DMS federator. The DMS federator syncs up with the DMS federating agent every 10 minutes. The agents on the endpoints query the DMS federating agent for a job, every 5 minute in our case. Therefore, the maximum amount of time before your endpoint can get a job after you submit it is 10 minutes.
Return codes for the common agent installation

The installation program sets the return value to reflect the success or failure of the installation procedure. It also writes the return value to a log file. For installation, the return value is in the CA_HOME/runtime/agent/logs/install/epIninstallStatus.log file. For uninstallation, return values are written to the CA_HOME/runtime/agent/logs/install/epUnInstallStatus.log file. Return values are in the following format for an installation: #date_and_time InstallStatus=number For an uninstallation, the file has the following format: #date_and_time UnInstallStatus=number The variable number is a signed integer value. For example, the following lines in the epInstallStatus.log file indicate a successful installation: #Wed Sep 27 14:09:54 CDT 2006 InstallStatus=0 The following lines indicate that the installation failed: #Wed Sep 27 16:19:32 CDT 2006 InstallStatus=-101 Table 6-3 on page 332 lists the return values and their meaning.
331
Table 6-3 Installation and uninstallation program return values. Value of InstallStatus or UninstallStatus 0 -101 Meaning Successful installation or uninstallation Installation failed. Read other log files for more information. For example, epInstall.log in the common agent installation directory and other log files in the logs/install directory. A newer version of the common agent exists in the location that you are trying to upgrade. User canceled the upgrade to the existing common agent. User entered an incorrect password for the Windows service account associated with the common agent. An incorrect JVMs used to invoke installer. A file operation failure occurred. Possible reasons include: v Cannot change file or directory permissions v Cannot copy the certificate or truststore files A Windows or UNIX service cannot be created, started, or stopped. Usually it has to do with the user not having the following rights: log on as service act as part of operating system
-102 -103 -104 -111 -120
-121
6.3.4 Starting and stoping the Tivoli common agent

To start and stop the common agent on a Windows system, use the Windows Services window or the Services folder in the Microsoft Management Console. Start or Stop the service with the following name: Tivoli Common Agent - 'installation directory' For example, the Windows service name might be: Tivoli Common Agent - 'C:\Program Files\Tivoli\ep' If your Windows system is set to a supported locale other than en_US, the string "Tivoli Common Agent" appears in your language. To start or stop the common agent on a UNIX or Linux system, run the following command:
332
/opt/tivoli/ep//runtime/agent/endpoint.sh start /opt/tivoli/ep//runtime/agent/endpoint.sh stop
6.3.5 Uninstalling Tivoli common agent

To uninstall Tivoli common agent, you can use the uninstall workflows to either remove the common agent component or completely remove the agent along with the subgents by using the Tivoli common agent stack. To uninstall the agent use the Software Management Uninstall Software Products and than select TCA 1.3.1.6. To uninstall the complete stack run Software Management Uninstall Software Stacks Tivoli Common Agent Stack.
Uninstalling the agent from the managed system

To uninstall the common agent: 1. Start the uninstallation wizard by running the command for your operating system: a. On Windows systems, use one of these methods: Use the Add or Remove Programs window to uninstall Tivoli Common Agent - 'installation directory'. If your Windows system is set to a supported locale other than en_US, the string "Tivoli Common Agent" appears in your language. Run the following command from a command prompt: C:\Program Files\tivoli\ep\_uninst\uninstall.exe b. On AIX operating systems: /usr/tivoli/ep/_uninst/uninstall c. On other operating systems: /opt/tivoli/ep/_uninst/uninstall You can also run the uninstallation program silently by adding the -silent argument to the command. If you are uninstalling a common agent that might have subagents on it that you no longer need, add the -W CASInstall.forceUninstall=true option to the command line to uninstall anyway. For example: C:\Program Files\tivoli\ep\_uninst\uninstall -silent -W CASInstall.forceUninstall=true 2. Select the language you want to use in the wizard and click OK
333
3. On the Welcome window, click Next. 4. If a confirmation window is displayed, make sure that no products need to run subagents on this common agent. If no other products are using this common agent, click Next to continue. 5. On the uninstallation summary window, click Next to start uninstalling the common agent. 6. On the installation results window, make sure that the uninstallation was successful and click Finish to exit the wizard. The common agent is now uninstalled. The uninstallation log is the CA_HOME/logs/install/epUnInstallStatus.log file. If the common agent was able to contact the agent manager during the uninstallation, the common agent is marked as logically deleted in the registry. This prevents management applications from continuing to manage it.
6.3.6 Removing old agents from the registry

When you uninstall the common agent software, the common agent's entry in the registry is marked as logically deleted and its certificate is revoked. However, the information about the common agent is not removed from the agent manager's registry. If the common agent is unable to contact the agent manager during the uninstallation, the registry is not updated and the certificate is not revoked. The common agent sends a report to the agent recovery service to log the failure, but it does not retry the connection. Also, common agents can be removed from service without being uninstalled. For example, a user who gets a new computer is unlikely to uninstall the common agent before turning in the old computer. Because these common agents are no longer providing periodic updates, you can identify them in the registry by the date of their last update. To identify and remove logically deleted or obsolete common agents from the registry, use the RetrieveAgents, PurgeAgents, and LogicallyDeleteAgents utilities. These utilities are available in the Agentmanager /toolkit/bin directory. A typical use of these tools is as follows: 1. Use the RetrieveAgents utility to get a list of common agents that meet a specific criteria. For example, you might request a list of all common agents that have expired. 2. Use one of the following utilities to clean up the registry:
334
a. Use the LogicallyDeleteAgents utility to logically delete, but not remove from the registry, common agents that have sent an update recently. The certificates for the logically deleted common agents are revoked. b. Use the PurgeAgents utilities to delete any common agents that are marked as logically deleted. For details about running these utilities, see the README file for each utility in the Agentmanager toolkit directory.
6.3.7 Running the common agent discovery and health status report
You can run a common agent discovery scan on the agent manager database to discover information about the common agent health on the target computers. You can output the common agent status information to a health status report.
Running the common agent discovery scan

To run the common agent discovery scan: 1. In the navigation pane, click Inventory Manage Discovery Discovery Configurations. The Manage Discovery Configurations page is displayed. 2. In the list, find the IBM Tivoli Common Agent Discovery configuration and, in that row, click Actions Run. The Initiate Discovery page is displayed, as shown in Figure 6-4 on page 336.
335
Figure 6-4 Initiate Discovery page
3. Specify the Task Name or accept the default name. 4. Under Schedule, select Now to run the discovery task immediately, or schedule it to run at a specified date and time, as shown in .Figure 6-5 on page 337. Select the appropriate notification options .
336
Figure 6-5 Discover all agents known to AgentManager
Tip: It would be a good practice to schedule IBM Tivoli Common Agent Discovery, this way you dont have to run this discovery whenever you want Endpoint Status report. 5. Click Submit. When you submit the task, the Track Tasks page is displayed. You can click the task name to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status as seen in Figure 6-6 on page 338.
337
Figure 6-6 Track task for discover all agents in the agent manager
Running the common agent health status report

You can now run a health status report, to display the common agent status information generated during the common agent discovery scan. To generate a common agent health status report: 1. In the navigation pane, click Reports Inventory. 2. In the Inventory010 row What is the status of all endpoints, click Actions > Run. The Run Report page is displayed. 3. The report is generated. It displays agent status parameters such as the status, last contact time, last boot time, agent start time, last attempt time, last error message for each of the target computers, which enable you to assess the current health status of the common agent installed on the target computers. See Figure 6-7 on page 339.
338
Figure 6-7 Endpoint status report
You can export the above report into XML or CSV format. To check status of individual endpoint you can run the workflow TCA_PingAgent.
6.3.8 Troubleshooting the common agent

In the following section, we discuss troubleshooting the Tivoli common agent.
Log files for the common agent

Table 6-4 on page 340 lists the logs created during the installation and uninstallation of the common agent. Table 6-5 on page 340 lists the runtime logs for the common agent and subagents.
339
Table 6-4 Installation logs for the Tivoli common agent Log FileLocated in LWI_HOME/runtime agent/logs/install/ epInstallStatus.log Description Contains the return code for the installation of the Tivoli common agent. For information about the contents of this log. see Return codes for the common agent installation on page 331 Contains the return code for the uninstallation of the Tivoli common agent The complete installation log. The contents of other installation logs are duplicated in this file. Standard output and standard error from the installation of the Tivoli GUID Standard output for setting the JAVA_HOME environment variables in the lwiSetJavaHome.bat and lwiSetJavaHome.sh commands. Standard error for setting the JAVA_HOME environment variables in the lwiSetJavaHome.bat and lwiSetJavaHome.sh commands. The log of the nonstop process On Windows, the log for the nonstop bundle On operating systems other than Windows, the log for the nonstop bundle. Note: This file is in a different directory that other installation logs The preconfiguration log for the installation
agent/logs/install/ epUnInstallStatus.log agent/logs/agentInstall.log agent/logs/guid_install.log agent/logs/lwiSetJavaHome_std out.log agent/logs/lwiSetJavaHome_std err.log agent/logs/nonstop.log agent/logs/nonstopbundle.log base/logs/nonstopbundle.log
agent/logs/preinstall.log
Table 6-5 Runtime logs Log file LWI_HOME/logs/rcp.log.0 Description The most current runtime log for the Tivoli common agent. When the size of this log reaches 1.9 MB, it is renamed to rcp.log.1 and a new rcp.log.0 file is started. The runtime logs for subagents
LWI_HOME/runtime/base/logs/rcp.log.0
340
Collecting diagnostic information on Tivoli common agent

The service command takes a snapshot of the diagnostic information about a Tivoli common agent and the computer system where the Tivoli common agent is running. It compresses the information into an archive that can be used for troubleshooting or sent to IBM Customer Support for analysis. The archive includes an HTML file that displays a compilation of the information gathered.
Running the service command

On Windows: C:\Program Files\tivoli\ep\runtime\agent\service On AIX operating systems: /usr/tivoli/ep/runtime/agent/service.sh On other operating systems: /opt/tivoli/ep/runtime/agent/service.sh version The script creates an archive file named CASservice.zip file in the same directory as seen in Example 6-7 on page 341. If you have more than one Tivoli common agent on a managed system, run the tool in the CA_HOME directory of the Tivoli common agent for which you want to capture diagnostic information. If you plan to send multiple CASservice.zip files to IBM Customer Support, rename them to give them unique names.
Example 6-7 service.sh script
[root@elpaso][/usr/tivoli/ep/runtime/agent]-> ./service.sh IBM Common Agent Services Program CTGEM2124I Common Agent: version 1.3.1.6 build 200609140622
Licensed Materials - Property of IBM (C)Copyright IBM Corporation 2004. All Rights Reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Collecting service information for IBM Please wait... Gathering product info:/usr/tivoli/ep/runtime/agent/CASserviceInfo.html Zipping up /usr/tivoli/ep/runtime/agent/../../logs/rcp.log.0
341
Zipping up /usr/tivoli/ep/runtime/agent/../../conf/overrides/agent.properties Zipping up /usr/tivoli/ep/runtime/agent/cert/pwd Zipping up /usr/tivoli/ep/runtime/agent/cert/agentTrust.jks Zipping up /usr/tivoli/ep/runtime/agent/cert/CertificateRevocationList Zipping up /usr/tivoli/ep/runtime/agent/cert/agentKeys.jks Zipping up /usr/tivoli/ep/runtime/agent/config/endpoint.properties Zipping up /usr/tivoli/ep/runtime/agent/config/logging.properties Zipping up /usr/tivoli/ep/runtime/agent/config/nonstop.properties Zipping up /usr/tivoli/ep/runtime/agent/config/nonstopbundle.properties Zipping up /usr/tivoli/ep/runtime/agent/config/initialBundles.txt Zipping up /usr/tivoli/ep/runtime/agent/config/currentBundles.txt Zipping up /usr/tivoli/ep/runtime/agent/logs/uninstall.log Zipping up /usr/tivoli/ep/runtime/agent/logs/install/epInstallStatus.log Zipping up /usr/tivoli/ep/runtime/agent/logs/agentInstall.log Zipping up /usr/tivoli/ep/runtime/agent/logs/preinstall.log Zipping up /usr/tivoli/ep/runtime/agent/logs/lwiSetJavaHome_stdout.log Zipping up /usr/tivoli/ep/runtime/agent/logs/lwiSetJavaHome_stderr.log Zipping up /usr/tivoli/ep/runtime/agent/logs/nonstop.log Zipping up /usr/tivoli/ep/runtime/agent/BTCJ010301.sys Zipping up /usr/tivoli/ep/runtime/agent/CASserviceInfo.html Zipping up /usr/tivoli/ep/runtime/agent/../base/logs/nonstopbundle.log Zipping up /usr/tivoli/ep/runtime/agent/../base/logs/cds_trace_client.log Zipping up /usr/tivoli/ep/runtime/agent/../base/logs/cds_msg_client.log Zipping up /usr/tivoli/ep/runtime/agent/../base/logs/citAgentTrace.log Execution time in seconds: 8 Service information has been collected in /usr/tivoli/ep/runtime/agent/CASservice.zip Please send this file to IBM for diagnostic evaluation Service completed successfully. Exiting Service Tool
Contents of the CASservice.zip file

The CASservice.zip file contains the following information: A summary of key system information in the CASserviceInfo.html file, which can be viewed in a Web browser. The summary displays: The configuration of the lightweight runtime where the Tivoli common agent runs The Tivoli common agent configuration Operating system and network configuration Java configuration
342
A list of the files and directories in the TCA directory On Windows, the Microsoft system information displayed by the Msinfo32.exe command. This information is in the msInfo.txt file. The files and subdirectories in the cert, config, and logs directories. The Tivoli common agent software signature file, BTCversion.sys. The runtime logs (rcp.log.n) in the LWI_HOME/logs or LWI_HOME/runtime/base/logs directory
Determining the version of the currently installed Tivoli common agent

To determine the version of the currently installed Tivoli common agent, run the following command: On Windows: C:\Program Files\tivoli\ep\runtime\agent\endpoint version On AIX operating systems: /usr/tivoli/ep/runtime/agent/endpoint.sh version On other operating systems: /opt/tivoli/ep/runtime/agent/endpoint.sh version The output of the command indicates the version, major release, minor release (modification level), and fix pack level of the Tivoli common agent. It also includes a build identifier. [root@elpaso][/usr/tivoli/ep/runtime/agent]-> ./endpoint.sh version Common Agent signature file information Version : 1 Release : 3 Modification : 1 FixPack : 6 Build Level : 200609140622 The above method is for determining information on the agent itself. You can also determine version of the agents from the Inventory data.
343
344
Chapter 7.
Compliance management
This chapter describes the compliance management functionality provided by Tivoli Provisioning Manager V5.1. Defining compliance checks for a computer or group of computers allows us to define a desired state for our target computers. This desired state is compared to the actual state of the target machines and can result in non-compliance issues. Tivoli Provisioning Manager generates recommendations for any non-compliance issues and can automatically remediate non-compliance through the use of automated workflows. The following topics are discussed in this chapter: Tivoli Provisioning Manager compliance management concepts on page 346 Compliance checks on page 347 Inventory and compliance check on page 372 Managing non-compliance on page 382 Creating a custom remediation workflow on page 396
345
7.1 Tivoli Provisioning Manager compliance management concepts

Compliance management is a growing concern of corporate IT management. Compliance is a state of being in accordance with established guidelines, specifications or processes. Tivoli Provisioning Manager allows you to examine the software and security setup of you target computers and compare it to a desired setup. If the actual setup does not match the desired setup, non-compliance occurs. Tivoli Provisioning Manager allows you to detect, report and remediate any non-compliance. The desired setup of a computer system or a group of computer systems is defined using compliance checks. There are two types of compliance checks: Software compliance checks Security compliance checks
7.1.1 Compliance management process

The compliance management process provided with Tivoli Provisioning Manager V5.1 consists of 4 iterative steps: 1. Creating and configuring the software and security compliance checks. 2. Performing an Inventory scan of the target system(s), retrieving the actual status of the targets. Optionally the Inventory scan can be scheduled periodically. 3. Running a compliance scan, comparing the actual state of the target machines with the desired state. Optionally the compliance scan can be scheduled periodically. 4. Verifying and fixing any non-compliance issues (remediation). Each of these steps can be performed on a single computer or on a group of computers. Using groups is an effective way to apply a set of policy checks to a group of computers.
7.1.2 Compliance Management scenario

Throughout this chapter a scenario will be used to demonstrate the compliance management functionality provided by Tivoli Provisioning Manager V5.1. The usage of compliance checks will be demonstrated for 4 groups of computers (x-ref to creating groups):
346
All_Computers XP_Computers Linux_Computers Solaris_Computers The All_Computers group contains the three other groups. See Figure 7-1 on page 347.
Figure 7-1 The All_Computers group
The purpose of the All_Computers group is to define general compliance checks for all machines, whereas the other groups will be used to define OS specific compliance checks.
7.2 Compliance checks

Compliance checks are a set of rules used to determine whether a computer or group of computers is compliant or not. There are two types of compliance checks - security and software. Compliance checks applied to a group of computers apply to all members of a group. Since groups can be nested it is possible to create a hierarchy of compliance checks. If you create the following hierarchy of groups: In our example the compliance checks defined for the All_Computers group will also apply to the XP_Computers, Linux_Computers and Solaris_Computers groups. If a computer is part of one or more groups (containing compliance checks) and specific compliance checks are defined at the computer level, the resultant set of
Chapter 7. Compliance management
347
compliance checks for that computer is the sum of the group compliance checks and the individual compliance checks.
7.2.1 Software compliance checks

Software compliance checks are used to check whether certain software applications should be on a computer or not. Software compliance checks can be created for software groups, software products, software patches, and software stacks. Compliance checks for an individual software product, software patch, or software stack, have the following options: Required: If you select this option, the software must be on the computer. This is the default choice. Prohibited: If you select this option, the software must not be on the computer. Optional: If you select this option, the software can be on the computer, but it does not have to be. This option is used in conjunction with the Restrict other software security compliance check and will be explained later. For a software group, the above mentioned options are not available, the compliance check for a software group is satisfied if at least one member of the software group is installed. When defining software compliance checks a numeric priority level has to be specified. The priority value for software is used when multiple recommendations to install or uninstall software are implemented at the same time. Software with a lower priority value (for example, 25) will be installed before software with a higher priority value (for example, 75). The reverse is applicable for uninstalling software.
7.2.2 Security compliance checks

Security compliance checks can be used to check for a variety of security issues The following paragraphs outline the security compliance checks available with Tivoli Provisioning Manager V5.1.
AIX activity auditing compliance check

The AIX activity auditing compliance check allows you to check for the existence or non-existence of the following AIX logs:
348
Connection time logs: Checks for the /var/adm/wtmp file, which contains connect-time accounting records. Connect-time records are created by the init and the login programs. Set user ID logs: Checks for the /var/log/sulog file, which contains login information from su command. Each time the su command is executed, an entry is made in the /var/adm/sulog file. The /var/adm/sulog file records the following information: date, time, computer name, and login name. It also records whether or not the login attempt was successful. Logon failure logs: Checks for the /etc/security/failedlogin file, which contains a record of unsuccessful login attempts.
Antivirus compliance check

The antivirus compliance check, available for Windows only, checks the settings of an installed antivirus program. The following antivirus programs are supported: Symantec Antivirus Corporate Edition (Versions 8.x and 9.x) Norton Antivirus Corporate Edition (Version 7.x) Norton Antivirus (Versions 5.x and 6.x) Trend Micro Antivirus (Version 7) McAfee VirusScan Enterprise (Versions 7.0 and 8.0i) Sophos Anti-Virus (Versions 3.xx, 4.5x, and 5.x). When defining an antivirus compliance check the following settings can be configured. Maximum elapsed time (hours). Specify the maximum number of hours that can elapse between virus scans. Maximum virus definition age (days). Specify the maximum age your definitions can be. Auto update schedule. Select when the auto update (to update your virus definitions) should be run. Refer to your antivirus documentation for more information about these options. Note: The options in this list cover the supported antivirus packages, so there may be options in it that are not supported by a specific antivirus software.
Endpoint Agent compliance check

The Endpoint Agent compliance check, checks the status of the Tivoli Common Agent as reported by the Agent Manager. This check is available for all platforms and supports the following settings:
349
Maximum elapsed time between contact: The maximum amount of time (in hours) that can elapse between successful contact with the endpoint agent by the agent manager. Status: The status of the endpoint agent
Hard disk password compliance check

The hard disk password compliance check checks for the existence of a hard disk password on Windows target computers. This compliance check setting applies to all hard disks on the system. Therefore, all the hard disks much match the specified setting in order for compliance to occur. A setting of Yes means that there must be a password on all hard disks. If any disk is missing a password, noncompliance occurs. A setting of No means that there must not be a password on any hard disk. If there is a password on any hard disk, noncompliance occurs.
Linux System Logging compliance check

The Linux System Logging compliance check, checks for the existence, priority and destination of system logs. In order for the computer to be compliant, these values must match the values you have in syslog.conf on your target computer: The following settings are available: Facility: The facility specifies the subsystem that produced the message. For example - all mail programs log with the mail facility (LOG_MAIL) if they log using syslog. Priority: The priority defines the severity or importance of the messages. Destination: The destination file for the logs. This should be a fully qualified path.
Operating system patches and updates compliance check

This compliance check verifies that all operating system patches and updates required by Tivoli Provisioning Manager patch management are installed. No specific settings exist for this compliance check. This compliance check will verify that the target computer (Windows, Linux, AIX or Solaris) is up to date on all operating system patches and updates required by Tivoli Provisioning Manager patch management. If you are missing any patches or updates the target computer will be considered noncompliant and automatic remediations are available to install the missing patches.
350
Note: You must have patch scanning running periodically to receive an accurate compliance status.
Power-on password compliance check

The power-on password compliance check, checks for the existence of a power-on password. This check is available for Windows only and has no specific configuration settings.
Remote root login compliance check

Checks remote root login settings, for AIX systems only. A setting of Yes means that remote root login is allowed. If it is not allowed on the target computer, noncompliance occurs. A setting of No means that remote root login is not allowed. If it is allowed on the target computer, noncompliance occurs.
Restrict other software compliance check

The restrict other software compliance check verifies that no software other than those listed in software compliance checks are on a target machine. No specific settings are available for this compliance check. If the target machine has any software installed that is not listed in the software compliance check, the target computer will be considered noncompliant. The only exception to this rule are softwares that are defined Optional in the software compliance check. If an optional software is installed on a target machine, the machine can still be compliant with the restrict other software compliance check. This setting can be very helpful for tightly controlled machines with only a few pieces of software on it, where you want to ensure nothing else is on it, without having to list numerous pieces of software as Prohibited.
Screen saver compliance check

This compliance checks the settings of the Windows screen saver. The following configuration settings are available: Active: A setting of Yes means the screen saver should be active. If it is not, noncompliance occurs. A setting of No means the screen saver should not be active. If it is, noncompliance occurs. Password protected: A setting of Yes means that there must be a password. If there is no password, noncompliance occurs. A setting of No means that there must not be a password. If there is a password, noncompliance occurs.
351
Maximum timeout value: This is the maximum amount of idle time (in minutes) before the screen saver is launched. If the actual value on the computer is greater than this value, noncompliance occurs. In order for the computer to be compliant, these 3 values must match the set up you have on your target computer. Note: Settings for all users that are not disabled on a system are checked.
UNIX file permissions compliance check

This compliance check is used to check the permissions on Linux, Solaris, and AIX files or directories. For each file or directory specified in the compliance check the following settings are available: Is directory: Select Yes if the file you have created the compliance check for is actually a directory. If you select Yes, and the target is not a directory, noncompliance will occur. If you select No, and the target is a directory, noncompliance will occur. Permissions: The permissions for this file or directory. If they do not match the settings on the computer, noncompliance occurs. They are specified as a string of characters representing UNIX permissions for owner, group, and others. For example: rwxr-x?-?. This is for a file or directory where the user has read, write, and execute permission, the group has read and execute permission, and others may have read and execute permission but don't require it. indicates that the specified permission is not set. ? indicates that the permission can either be set or not set. r indicates that read permission is set. w indicates that write permission is set. x indicates that execute permission is set.
UNIX services compliance check

This compliance check, available for Linux, Solaris, and AIX, checks for missing or prohibited UNIX services, for configuration of the service and the state of the service. For each service specified in this compliance check the following settings are available: Port number: port number for the service, this must be an integer. Protocol: the transport protocol used for the service (tcp, udp,...).
352
Service stat: you can select from the following service states: Prohibited: The service is not allowed on this computer. Required: The service is mandatory on this computer. Optional: If a service is optional, and it is actually installed on the system, then it must also comply with the Port number and Protocol. If the service is optional, and it is not installed on the system, then the Port number and Protocol are ignored.
Unauthorized guest access compliance check

This compliance check verifies the guest users account settings on a Windows machine. In order for the target computer to be compliant, the following values must match the set up you have on your target computer: Guest account can only be a member of Guests group: If the user must not be exclusively in the Guests group, select No. For example, if the guest account is a member of the Guests group, then noncompliance occurs. However, if the guest account is a member of the Guests and the Administrators group (or just the Administrators group), then compliance occurs. If you only want to allow the guest account to be a member of the guest group, select Yes. Guest account must be active: If you select No the guest account must not be active. If you select Yes the guest account must be active. Guest account must be locked: Select Yes if you want to make it mandatory for the guest account to be locked (that is, it cannot be used). If you do not want the guest account to have to be locked, select No.
User password compliance check

This compliance check verifies Windows password settings. The following configuration options are available: Minimum password reuse count: Specifies the number of previous passwords that a user cannot reuse when selecting a new password. If the value on the computer is greater or equal to the value specified here, then the system is compliant. Otherwise, noncompliance occurs. Maximum password age: Specifies the maximum number of days a user can use a password after it is set. If the value on the computer is greater or equal to the value specified here, then the target is compliant. Otherwise, noncompliance occurs. Minimum password length: Specifies the minimum length a user password has to be. If the value on the computer is greater or equal to the value the machine is compliant. Otherwise, noncompliance occurs.
353
Note: A target Windows machine will be compliant if all users on the system are compliant.
Windows event logging compliance check

The Windows event logging compliance check verifies the settings of the Windows event log. The following settings are available: Minimum retention period of application data: The minimum age, in days, of data to overwrite when the maximum application log size is reached. The value should be between 0 to 49710; a value 0 means the data can be overwritten as necessary, and a value of 49710 means the data should never be overwritten. Minimum retention period of security data: The minimum age, in days, of data to overwrite when the maximum security log size is reached. The value should be between 0 to 49710; a value 0 means the data can be overwritten as necessary, and a value of 49710 means the data should never be overwritten. Minimum retention period of system data: The minimum age, in days, of data to overwrite when the maximum system log size is reached. The value should be between 0 to 49710; a value 0 means the data can be overwritten as necessary, and a value of 49710 means the data should never be overwritten. Minimum value of the maximum application log size: The maximum size (in MB) of the application event log. It can be no larger than 4 GB. Minimum value of the maximum security log size: The maximum size (in MB) of the security event log. Its maximum size is 4 GB. Minimum value of the maximum system log size: The maximum value (in MB) of the system event log. It can be no larger than 4 GB.
Windows file permission compliance check

This compliance check verifies Windows file and folder permissions. For each file or folder settings for a specific user can be specified: List Folder/Read Data: List Folder allows or denies viewing file names and subfolder names within the folder and Read Data allows or denies viewing data in files. Create Files/Write Data: Create Files allows or denies creating files within the folder (applies to folders only) and Write Data allows or denies making changes to the file and overwriting existing content (applies to files only). Create Folders/Append Data: Create Folders allows or denies creating folders within the folder (applies to folders only) and Append Data allows or
354
denies making changes to the end of the file but not changing, deleting, or overwriting existing data (applies to files only). Read Extended Attributes: Allows or denies viewing the extended attributes of a file or folder. Extended attributes are defined by programs and may vary by program. Write Extended Attributes: Allows or denies changing the extended attributes of a file or folder. Extended attributes are defined by programs and may vary by program. Traverse Folder/Execute File: Traverse Folder allows or denies moving through folders to reach other files or folders, even if the user has no permissions for the traversed folders (applies to folders only). Execute File allows or denies running program files (applies to files only). Delete Subfolders and Files: Allows or denies deleting subfolders and files, even if the Delete permission has not been granted on the subfolder or file (applies to folders). Read Attributes: Allows or denies viewing the attributes of a file or folder, such as read-only and hidden. Attributes are defined by NTFS. Write Attributes: Allows or denies changing the attributes of a file or folder, such as read-only or hidden. Attributes are defined by NTFS. Delete: Allows or denies deleting the file or folder. If you don't have Delete permission on a file or folder, you can still delete it if you have been granted Delete Subfolders and Files permission on the parent folder. Read Permissions: Allows or denies reading permissions of the file or folder, such as Full Control, Read, and Write. Change Permissions: Allows or denies changing permissions of the file or folder, such as Full Control, Read, and Write. Take Ownership: Allows or denies taking ownership of the file or folder. Synchronize: Allows or denies different threads to wait on the handle for the file or folder and synchronize with another thread that may signal it. This permission applies only to multi threaded, multiprocess programs.
Windows Firewall compliance check

This compliance check verifies a number of Windows Firewall settings on Windows XP and Windows 2003. These firewall programs are supported: McAfee Desktop Firewall (Versions 8.0 and 8.5) Windows Native Firewall Zone Alarm Integrity Flex Firewall (Version 3.5.175.057).
355
In order for the computer to be compliant, the following values must match the set up on the target computer: Track traffic: If set to Yes, the firewall must be active and capable of monitoring and blocking incoming and outgoing traffic. If set to No, the firewall must not be active. Activate Windows service: If set to Yes, the firewall must be active as a Windows service. If set to No, the firewall must not be active as a Windows service. Windows service enabled to start automatically: If set to Yes, the Windows Service firewall must be configured to start automatically when the computer reboots. If set to No, the Windows Service firewall must not be configured to start automatically when the computer reboots.
Windows services compliance check

This compliance check is used to verify the settings of Windows services. The following settings can be checked for each individual service: Startup mode: You can select from the following startup modes: Automatic: The service must start automatically. Manual: The service must be started manually. Disabled: The service must be disabled (it cannot be started). Service state: You can select from the following service states: Prohibited: The service is not allowed on this computer. Required: The service is mandatory on this computer. Optional: If a service is optional, and it is installed on this computer, then the Startup mode and Running state are checked. If the service is optional, and it is not installed on this computer, then the Startup mode and Running state are not checked. Running state: You can select from the following states: Running: The service must be running. Paused: The service must be paused. Stopped: The service must be stopped. Note: Service names must be specified using their Windows service display names.
356
7.2.3 Creating compliance checks

As explained earlier compliance checks are defined at the group or computer level. In order to create a new compliance check the target group or computer is accessed from the Inventory section: Inventory Manage Inventory Groups or Computers. After selecting the target group or computer, compliance checks can be added from the Compliance tab by selecting Edit Add Security Compliance Checks or Add Software Compliance Checks as shown in Figure 7-2 on page 357.
Figure 7-2 Creating compliance checks
The next sections of this chapter demonstrate how to add various compliance checks for Windows XP, Linux and Solaris. The following compliance checks will be added for the four groups of computers: All Computers Group: Endpoint agent: the agent should be running on all target computers Linux Group Unix services: The ftp service should be disabled. Windows XP Group Software compliance: The Windows Update Agent has to be installed on all XP machines. Windows Firewall: Windows firewall must be enabled
357
Operating System Patches and Updates: All XP machines must have the latest patches and updates installed. Solaris Group Unix File Permissions: /etc/shadow must have r-------- permissions and /etc/passwd must have rw-r--r-- permissions.
7.2.4 Creating and configuring the Endpoint Agent compliance check

First we will add the compliance check for the All_Computers group. Adding compliance checks for a group is done from the Compliance tab of the corresponding group. This tab can be accessed by selecting Inventory Manage Inventory Groups and selecting the target group from the list. Adding a security compliance check is done by selecting Edit Add Security Compliance Checks (Figure 7-3 on page 358).
Figure 7-3 Adding security compliance checks for the All_Computers group
Next the Endpoint Agent compliance check is selected and moved to the right-hand side.
358
Figure 7-4 Assigning the endpoint agent compliance check
After selecting the Save button the compliance check is added with default settings. From the compliance tab of the group the settings of the Endpoint Agent compliance check can be changed by clicking on the name of the compliance check. This brings up the following dialog (Figure 7-5 on page 359).
Figure 7-5 Configuring the endpoint agent compliance check
We will use the default settings for this compliance check: the agent should be running and the maximum amount of time (in hours) that can elapse between successful contact with the endpoint agent by the agent manager should be less than 24 hours. Saving the settings returns you to the compliance tab of the All Computers group.
359
7.2.5 Creating and configuring Linux compliance checks

For the Linux group the Unix services security compliance checks will be added. Adding the security compliance check is done by selecting Edit Add Security Compliance Checks from the compliance tab of Linux_Computers group (Figure 7-6 on page 360).
Figure 7-6 Adding the security compliance checks for Linux
Next the two compliance checks are selected and moved to the right-hand side as shown in Figure 7-7 on page 360.
Figure 7-7 Assigning the security compliance checks
After saving the security compliance check, you are returned to the compliance tab where the new compliance check will be listed (Figure 7-8 on page 361).
360
Figure 7-8 Linux security compliance check added
Now that the compliance check is added, it must be configured.
Configuring the Unix Services compliance check

We will configure the UNIX services compliance check to look for the ftp service on port 21. If the ftp service is enabled, non-compliance will be reported. 1. The settings can be changed from the Compliance tab by clicking on the name of the compliance check (UNIX Services) or by clicking the little icon and selecting Settings (Figure 7-9 on page 361).
Figure 7-9 Accessing the settings of Unix services compliance check
2. Next a service can be added by selecting Edit Add Compliance Check, as shown in Figure 7-10 on page 362.
361
Figure 7-10 Adding Unix Services
3. The next window (Figure 7-11 on page 362) allows you to specify the name of the compliance check and the name of the service. Note that the name of the service must match with the name of the service in the /etc/services file.
Figure 7-11 Specifying the name of the Unix service
4. After selecting the Save button the Unix Service is added to the list of compliance checks. Changing the settings of the Unix service compliance check is done by clicking the name Ftp service. We will specify the settings as shown in Figure 7-12 on page 363.
362
Figure 7-12 Ftp Service Settings
With these settings a target system will be non-compliant if the ftp service on port 21 using protocol tcp is present in the /etc/services file of the target machine. 5. After clicking the Save button you are returned to the Unix Services window. The Close button returns you to the compliance tab of the Linux group. The Compliance tab now shows the following information (Figure 7-13 on page 364):
363
Figure 7-13 Linux compliance checks added
Note: The 0% compliant value means that none of the systems in the Linux group are compliant (a value of 100% would indicate all machines are compliant). This is normal since the machines have not been scanned and checked for compliance yet. This will be covered later.
7.2.6 Creating Windows compliance checks

For the XP_Computers group we will add three compliance checks, one software compliance check (WUA software has to be installed) and two security compliance checks (Windows Firewall and Operating System Patches and Updates). The group is accessed by selecting Inventory Manage Inventory Groups and clicking the group name. The compliance checks can then be added from the Compliance tab.
Creating Windows software compliance checks

On the Windows XP machines we want to ensure that the Windows Update Agent software is installed, if it is not installed the target machine should be marked non-compliant.
364
1. Adding the software compliance check is done by selecting Edit Add Software Compliance Checks (Figure 7-14 on page 365).
Figure 7-14 Adding software compliance checks
2. Next you have to select the software product(s) you want to add to the compliance check (Figure 7-15 on page 365).
Figure 7-15 Adding software compliance checks
3. In the Type drop down, we select Software Products and the Search button can be used to find the Windows Update Agent software product, which can then be added to the Selected Software list (Figure 7-16 on page 366).
365
Figure 7-16 Adding the Windows Update Agent software product
4. After saving the software compliance check, it can be configured by clicking on the name of the software product (Windows Update Agent (WUA)). See Figure 7-17 on page 366.
Figure 7-17 Configuring the software compliance check
366
The priority value for a software is used when multiple recommendations to install or uninstall software are implemented at the same time. Software with a lower priority value (for example, 25) will be installed before software with a higher priority value (for example, 75). The reverse is applicable for uninstalling software. In our example we will leave the default value of 50. In the Install drop down we select Required indicating the software must be on the computer to be compliant. The Alert settings are used to specify when notification messages are to be sent. A failed software compliance check will begin generating notification messages immediately. If you want to specify a future date when these notification messages will begin to be sent, click the Planned Start radio button and specify the date and time. In our example we will leave the default setting: Run Now. 5. After saving the settings you are returned to the compliance tab of the group.
Creating Windows XP security compliance checks

Adding the security compliance checks is done by selecting Edit Add Security Compliance Checks on the compliance tab of the group. After moving the desired security compliance checks to the right hand side, they can be saved by clicking the Save button (Figure 7-19 on page 368).
Figure 7-18 Adding Windows security compliance checks
Configuring the operating system patches and updates compliance check

The operating system patches and updates compliance check has no configurable attributes (you can not click on the compliance check to configure it). This compliance check verifies whether the target systems are up to date on all operating system patches and updates required by Tivoli Provisioning
367
Manager patch management. If any patches or updates on the target computers are missing they will be considered noncompliant.
Configuring the Windows Firewall compliance check

1. The Windows Firewall compliance check is configured by clicking on the name of the compliance check. This brings up the following configuration window (Figure 7-19 on page 368)
Figure 7-19 Windows firewall compliance check settings
In our scenario we will leave all the defaults, meaning we want the firewall to monitor traffic, the firewall service should be running and the firewall service should be configured to start automatically when the computer is started. 2. Clicking the Save button returns you to the compliance tab of the group where all security and software compliance checks for the XP_Computers group are summarized as shown in Figure 7-20 on page 369.
368
Figure 7-20 Windows compliance checks
Since the inventory scan and compliance check have not run yet, the Compliant column shows 0% for all compliance checks.
7.2.7 Creating Solaris compliance checks

For the Solaris computer group we want to add a Unix File Permissions security compliance check. This check will verify that permissions of /etc/passwd are set to rw-r--r-- and of /etc/shadow are set to r--------. 1. The compliance check is added by selecting Edit Add Security Compliance Checks from the compliance tab of the target Solaris group (Figure 7-21 on page 370).
369
Figure 7-21 Adding the Unix file permissions compliance check
2. After clicking the Save button a compliance check for both files can be added by clicking on the Unix File Permissions compliance check and selecting Edit Add compliance check (Figure 7-22 on page 370).
Figure 7-22 Adding files to the Unix file permissions compliance check
3. After saving the compliance check the file permissions are configured by clicking the name (passwd file). This brings up the following window (Figure 7-23 on page 371).
370
Figure 7-23 Configuring file permissions
In our example we specify that /etc/passwd is a not a directory and the permissions are defined as rw-r--r--. Similarly we can add a second compliance check for the /etc/shadow file, with different file permissions (r--------). See Figure 7-24 on page 371.
Figure 7-24 Unix file permissions compliance check
4. Clicking the Close button returns you to the compliance tab of the Solaris group.
371
7.3 Inventory and compliance check

As explained earlier the compliance management process consists of 4 iterative steps. 1. Creating and configuring the software and security compliance checks. 2. Performing an Inventory scan of the target system(s) 3. Running a compliance check 4. Verifying and fixing any non-compliance issues (remediation). Creating and configuring the security and software compliance checks, actually defines a desired state for our target machines. Checking whether the machines are compliant with this desired state is done by performing an Inventory scan of the target machines and running a compliance check.
7.3.1 Inventory scan

The purpose of launching an Inventory scan on the target computers or group of computers is to verify the actual status of the targets. The Inventory scan is launched from the compliance tab of the target group or computer. This launches a new task on all the targets of the group or the target computer. The task that is launched is named Inventory Compliance Scan: Name_of_group_or_computer. This task contains a number of discovery workflows. The number of discovery workflows and the settings of each discovery configuration depends on the compliance checks defined for the target group or computers. Tivoli Provisioning Manager will automatically perform the correct Inventory scan to discover the actual values needed for the various compliance checks defined for the group or computer. For the All_Computers group, where the Endpoint Agent compliance check was added, the Inventory scan will automatically include the IBM Tivoli Common Agent Discover Device discovery. The only exception to this rule is the Operating System Patches and Updates compliance check. When this compliance check is included for a group or computer, the scan for patches and updates must be executed or scheduled outside the compliance page of the group or computer. An example of this will be shown later.
372
Launching the Inventory Scan for the different computer groups

1. Launching the scan for the All Computers group is done from the Compliance tab of the group by selecting Run Inventory Scan. (Figure 7-25 on page 373).
Figure 7-25 Running the inventory scan
2. A new task is submitted for the Inventory scan and the details of the task can be seen by following the link that is displayed on the compliance tab of the group (Figure 7-26 on page 373).
Figure 7-26 Inventory scan task submitted
3. The progress of the task can also be monitored by selecting Task Management Track Tasks. 4. Similarly the Inventory scan for the other three groups can be launched. The Track Tasks window will now display the status of the Inventory scans for all four groups (Figure 7-27 on page 374).
373
Figure 7-27 Inventory scan progress
5. To see the details of a particular task, click on the name of the task. This will show the details of the particular Inventory scan. The following figure shows the details of the Inventory scan for the Linux group. This Inventory scan task contains two workflows a Security Compliance Scan, needed to check the Unix services compliance check, and an SCMCollectorAgent scan, needed to check the Endpoint Agent status. In our example both workflows have been successfully executed as can be seen in Figure 7-28 on page 375.
374
Figure 7-28 Linux group: Inventory scan details
6. To see the details of a particular scan you can click on the Request ID which will display the following window (Figure 7-29 on page 376).
375
Figure 7-29 Security compliance scan workflow details
From this window the details of the workflow can be seen. In this example the details of the security compliance scan for the linux group are shown. After executing the Inventory scan, looking at the compliance tab of the groups you will notice that the Last Scan value is still unknown and the Compliant value is still 0%. This is normal since the compliance check has not been executed yet. This will be covered later.
376
Scheduling an inventory scan

Instead of executing the inventory scans manually, it is possible to schedule the Inventory scan for a computer or a group of computers. 1. Scheduling an Inventory scan is done from the compliance scan of the target group by selecting Edit Inventory Scan Schedule (Figure 7-30 on page 377).
Figure 7-30 Scheduling the inventory scan
2. Next the settings for the Inventory scan schedule can be set. The scan can be schedule every day, every week or every month and a start date and time can be specified as shown in Figure 7-31 on page 377.
Figure 7-31 Settings for the inventory scan schedule
7.3.2 Compliance check scan

The third step in the compliance management process is running the compliance check. The compliance check uses the data from the Inventory scan(s) to calculate the compliance status of the target machines. For non-compliant machines the compliance check also generates recommendations to return the machines to a compliant status.
377
1. Running the compliance check is done from the compliance tab of the target computer or computer group by selecting RunCompliance Check (Figure 7-32 on page 378).
Figure 7-32 Running the compliance check
2. Running a compliance check launches a new task named Compliance Check: Name_of_group. The status of the task can be seen by clicking on the name of the task (Figure 7-33 on page 378).
Figure 7-33 Compliance check launched
3. Following the link brings up the following window (Figure 7-34 on page 379).
378
Figure 7-34 Compliance check details
Note that the Compliance Validation workflow is executed on the Tivoli Provisioning Manager server. The agents are not contacted during the compliance check. After successfully running the compliance checks for the different groups the compliance tab of the target groups now have values for the Last Scan (value is set to the date and time of the compliance scan) and the compliant value, ranging from 0-100%. The following figure displays the compliance tab of the XP Computers group (Figure 7-35).
379
Figure 7-35 Compliance tab for the XP_computers group
Figure 7-35 shows that none of the computers in the XP group are compliant with the Operating System Patches and Updates and Windows Firewall compliance check and all computers are compliant with the software compliance check for the Windows Update Agent. Also note that in this example the Last Scan of the Operating System Patches and Updates does not have the same value as the date of the other compliance check. The Operating System Patches and Updates compliance check is not checked automatically when an Inventory scan is launched from the compliance tab. The scan has to be launched outside of the compliance tab. The scan has to be launched outside of the compliance tab. This can be done by selecting Inventory Discovery Manage Discovery Configurations and then
380
running the Microsoft WUA Scan on the target group. When the scan completes successfully the compliance check for the target group has to be executed again in order to update the compliance status.
Scheduling the compliance check

The compliance check can be scheduled to run every day, every week or every month. In a real life environment the compliance check will be scheduled after the inventory scan. 1. Scheduling the compliance check is done from the compliance tab of the target computer or target group by selecting Edit Edit Compliance Check Schedule as shown in Figure 7-36 on page 381.
Figure 7-36 Scheduling the compliance check
2. This brings up the following window (Figure 7-37 on page 381).
Figure 7-37 Compliance check schedule settings
3. In this example, the compliance check is scheduled to run every week at 03:00AM starting on 09/18/06. After selecting the Save button, the compliance check schedule is saved and the compliance tab of the target group or computer will show the settings of the compliance check and inventory scan schedule (Figure 7-38 on page 382).
381
Figure 7-38 Compliance check and Inventory scan schedule
4. The scheduled compliance checks and inventory scans are also shown in the Track Tasks window as shown in Figure 7-39 on page 382.
Figure 7-39 Track tasks windows for scheduled compliance check and inventory scan
7.4 Managing non-compliance

Remediation is the task required to return a non-compliant computer or group of computers back to their compliant state. This can be policy driven (automated) or a manual effort. Automated remediation for compliance checks is provided by workflows and logical device operations associated with them.
382
7.4.1 Viewing recommendations

When a computer or a group of computers is non-compliant Tivoli Provisioning Manager will provide a number of recommendations to return the computers to a compliant state. Recommendations can be accessed from the compliance tab of a computer or group of computers or they can be viewed in the Recommendations tab of the target group or computer. Looking at the Compliance tab of a group of computers the Compliant column for each compliance check indicates a percentage. A value of 100% indicating all computers are compliant and 0% indicating all computers are non-compliant for that particular compliance check (Figure 7-40 on page 384).
383
Figure 7-40 Compliance tab for XP_Computers group
In this example all computers are compliant with the software compliance check: all computers have the Windows Update Agent version 2.0 installed and as a consequence no remediations for this compliance check are available. The two security compliance checks (Windows Firewall and Operating System Patches and Updates) are 0% compliant, indicating none of the computers in the group are compliant. To view the recommendations for one of these compliance checks you can click on the compliant value. For example if we click on the 0% compliant value of the Operating System Patches and Updates compliance check, the following recommendations will be shown (Figure 7-41 on page 385).
384
Figure 7-41 Patches and Updates recommendations
In this example the recommendations include all Windows patches that have to be installed for the target machines. Recommendations can also be viewed directly from the Recommendations tab of the target group or computer. The recommendations tab will show the recommendations for all compliance checks and all targets of the group. If the group is compliant for all compliance checks the recommendations tab will be empty. Figure 7-42 on page 386 shows the recommendation tab of the XP_Computers group.
385
Figure 7-42 Recommendations tab of the XP_Computers group.
The figure shows all recommendations for the different compliance checks. In this example recommendations are included for all missing patches and a recommendation on the Windows firewall settings.
7.4.2 Automated remediation

Tivoli Provisioning Manager provides automated remediation for software compliance checks and for the Operating System Patches and Updates security compliance check. For other security noncompliance issues, automated remediation is not provided with IBM Tivoli Provisioning Manager. Automated remediation for these security compliance checks will be made available through automation packages which
386
can be downloaded on an ongoing basis from the Orchestration and Provisioning Automation Library Web site: http://catalog.lotus.com/wps/portal/topal A default workflow is automatically associated with all recommendations when they are generated; you can change the default associated workflow for each compliance check. To see the default workflows that are used for remediation, from the main navigation pane select System Management Global Settings and click on the Compliance tab. This will show the following window in Figure 7-43 on page 387.
Figure 7-43 Compliance global settings
387
As can be seen from the figure, by default, only two workflows for automated remediation are available: Placeholder_Security_Remediation: This workflow does not perform any action and fails when executed, with a message saying no automated remediation is available. Sample_Software_Remediation: Workflow used to install or uninstall software or patches as appropriate for the remediation
7.4.3 Managing recommendations

As explained earlier the Recommendations tab of a computer or a group of computers shows the recommendations for all compliance checks. In order to work with a specific recommendation you select the check box of the recommendation you want to work with. You can now click one of the following action buttons: Open: An issue you previously ignored. Approve: Approve the recommendation, which must be done before it can be implemented or closed. Run: Implement the recommendation using a workflow. The recommendation must be approved before it can be implemented. Schedule: Implements an approved recommendation using the Install Software page, so you cannot use this action for security recommendations. Close: Close an approved recommendation manually. Use this option if you have selected to manually fix an issue instead of using automatic remediation. Ignore: Ignore the issue and do not show it again, until the next compliance check is run. The action you selected will be taken and the status of the issue will be updated once the action has been completed. You may need to refresh the page in order to see the updated status. Recommendations can be filtered using the Status list. This list can be used to filter the list of issues. You can select to view only the issues with a certain status - for example, only issues that have been Ignored or Approved. In our example scenario the Linux_Computers and Solaris_Computers groups are 100% compliant. As a consequence the recommendations tab for these groups are empty (Figure 7-44 on page 389).
388
Figure 7-44 Linux_Computers compliance
The XP_Computers group contains recommendations for a number of Windows security patches and for the Windows firewall compliance check. 1. First we will approve the recommendations, this is done by selecting the recommendations and clicking the Approve button.
389
Figure 7-45 Approving recommendations
2. After approving the recommendations we can select the Run button to automatically launch the associated workflows for each selected recommendation. This will start a new task as shown in Figure 7-46 on page 390.
Figure 7-46 Running compliance remediation for the XP_Computers group
390
Note that the workflow that will be launched for the Windows Firewall compliance check will not perform any remediation actions. In this case we should fix the problem manually and close it afterwards. 3. Clicking on the name of the task: Compliance Remediation: XP_Computers shows the details of the particular task. (Figure 7-47 on page 391).
Figure 7-47 Remediation task details
The figure shows the task contains two workflows, one for installing the OS patches and one dummy workflow for the Windows Firewall compliance check.
391
4. Clicking on the ID of the OS patch install recommendation group shows the details for this workflow. The following figure shows a part of this workflow execution, as shown in Figure 7-48 on page 392.
Figure 7-48 Workflow details
As can be seen from this screen the workflow installs the required windows patches using a timeout of 86400 seconds. If a reboot is required the target machine will be automatically booted and the patches are downloaded from the Internet and not from a local WSUS server. After launching the remediation the status of the recommendations will change to implementing. The status of a recommendation can be any of the following: Opened: Recommendation has been made, but no action has been taken.
392
Approved: Recommendation has been made, and approved for implementation. Ignored: Recommendation is to be ignored. Implemented: Recommendation has been approved and implemented. Implementing: Recommendation has been approved and is in the process of being implemented. Either the Implement or Close action can be used on a recommendation that is in the Implemented state. Failed: Recommendation has been approved, and implementation has been attempted, but failed. If a recommendation is in this state, you can select to Ignore it, to Implement it again (if you have fixed the problem that was causing it to fail) or Close it. In our example the compliance remediation task fails as shown in Figure 7-49 on page 393.
Figure 7-49 Failed compliance remediation
5. Clicking on the name of the task shows the tasks details. From this window we can see that the job with id 10499 has failed (Figure 7-50 on page 394).
393
Figure 7-50 Recommendation task details
6. Clicking on the request id (10499) brings up a window showing the details of the failed workflow (Figure 7-51 on page 395). From it we can see that the
394
workflow has failed because there is no automatic remediation provided for the Windows Firewall compliance check (the sample workflow always fails).
In this case we have to manually fix the Windows firewall settings on the target machine. After running the automated remediations and/or manually fixing non-compliance issues the compliance process can be restarted: Performing an inventory scan (eventually scheduled) Performing a compliance check (eventually scheduled) Reviewing and implementing recommendations In the example of the Windows XP group we have installed the missing patches using the provided automated remediation and we corrected the Windows firewall setting manually. After performing an inventory scan and a compliance check the XP_Computers group is 100% compliant, as can be seen in Figure 7-52 on page 396.
395
Figure 7-52 XP_Computers compliance
7.5 Creating a custom remediation workflow

In our example scenario the Solaris_Computers group is not compliant with the Unix File Permissions compliance check. The /etc/shadow file has incorrect permissions on one of the Solaris machines. The compliance check that was executed has generated the recommendation shown in Figure 7-53 on page 397.
396
Figure 7-53 Unix file permissions recommendation
The generated recommendation instructs the administrator to manually change the permissions to the desired value, returning the machine to a compliant status. This section will explain how to create a custom workflow to automatically adjust the file permissions on the target computer. This process consists of the following steps: Creating a new workflow Compiling and testing the new workflow Associating the new workflow with the appropriate recommendation key Approving the recommendation and running the remediation from the Recommendation tab.
7.5.1 Creating a new workflow

Creating a new workflow is done by first selecting Automation Workflows which opens the Manage Workflows window. Here we select Edit Add Workflow, as shown in Figure 7-54 on page 398.
397
Figure 7-54 Adding a new workflow
This opens the Workflow Editor or Workflow Composer window. The workflow composer displays the source code of a workflow in a text box so that you can view or edit it. The Workflow Composer allows you to: Edit workflow text Compile a workflow after making changes Run the workflow Export the workflow Open a workflow file Tivoli Provisioning Manager also includes the Automation Package Development Environment (APDE). APDE is an Eclipse-based plug-in environment that developers can use to customize existing automation packages or create new automation packages. The workflow composer provides the ability to view workflows and create new workflows, but does not provide the full workflow and automation package development capabilities that are available in the Automation Package Developer Environment. In our simple example of creating a remediation workflow we will use the workflow composer and not the APDE. The workflow code we developed is shown below.
Example 7-1 The workflow code
# ----------------------------------------------------------------# Licensed Materials - Property of IBM # 5724-F75 # (C) Copyright IBM Corp. 2003 - 2006 # All Rights Reserved # US Government Users Restricted Rights -Use, duplication or # disclosure restricted by GSA ADP Schedule Contract with IBM Corp. # ----------------------------------------------------------------@doc A custom remediation workflow for Unix file permission issues workflow Unix_File_Permissions_Remediation (in ComplianceRecommendationID, in TargetID) implements ComplianceRecommendation.Remediate LocaleInsensitive
398
var permissions = DCMQuery(/ComplianceRecommendation[@id=$ComplianceRecommendationID]/Com plianceIssue/ComplianceResult/UnixFileACLRule/@permissionString) var fileId = DCMQuery(/ComplianceRecommendation[@id=$ComplianceRecommendationID]/Com plianceIssue/ComplianceResult/UnixFileACLRule/@fileResourceId) var filepath = DCMQuery(/ComplianceRecommendation[@id=$ComplianceRecommendationID]/Com plianceIssue/ComplianceResult/UnixFileACLRule/File[@id=$fileId]/@name) var message = "File and desired permissions are " + filepath + " " + permissions log debug message scriptlet (filepath, permissions) language = perl target = TargetID <<EOF if (-f $filepath) { TIOlog("Info", "$filepath exists OK to continue"); } else { TIOthrow("NoSuchFileOrDirectory", "$filepath does not exist can NOT continue"); } TIOlog("Info", "Converting $permissions to numerical equivalent"); my (@modes) = $permissions =~ /(...)(...)(...)$/g; my $result; my $numpermissions = ""; while (my $mode = shift @modes) { my $m = 0; $m += 1 if $mode =~ /[xsS]/; $m += 2 if $mode =~ /w/; $m += 4 if $mode =~ /r/; $numpermissions .= "$m"; } TIOlog("Info", "Numerical equivalent is $numpermissions"); $Cmd = "chmod $numpermissions $filepath"; TIOlog("Info", "Executing $Cmd"); `$Cmd`; $rc = $?; if ($rc ne 0) { TIOthrow("ChmodException,Failed to chmod $filepath RC is $rc); } else { TIOlog("Info", "Successfully executed chmod command"); } EOF We will now discuss the different parts of this custom workflow.
399
The first lines of code define the name of the workflow; Unix_File_Permissions_Remediation and define the arguments that are provided to the workflow when it is called in a remediation action.
Example 7-2 Define the name of the workflow
workflow Unix_File_Permissions_Remediation (in ComplianceRecommendationID, in TargetID) implements ComplianceRecommendation.Remediate LocaleInsensitive All compliance remediation workflows must implement the ComplianceRecommendation.Remediate logical device operation and always have the same two arguments: TargetId: Device id of the computer where the non-compliance occured. ComplianceRecommendationID: The ID of the compliance recommendation object that is generated for each computer when the compliance check is executed. This object in the DCM contains further information about the compliance check and the reason for non-compliance. In our example this ComplianceRecommendation object will hold information such as the file name, desired permissions and effective permissions. The next part of the workflow queries the DCM to get the information we need to fix the non-compliance issue: Desired permission string, as specified in the compliance check. In our example scenario we specified r-------- as the desired permissions for /etc/shadow). Filename, including the full pathname (/etc/shadow).
Example 7-3 Query the DCM
var permissions = DCMQuery(/ComplianceRecommendation[@id=$ComplianceRecommendationID]/Com plianceIssue/ComplianceResult/UnixFileACLRule/@permissionString) var fileId = DCMQuery(/ComplianceRecommendation[@id=$ComplianceRecommendationID]/Com plianceIssue/ComplianceResult/UnixFileACLRule/@fileResourceId) var filepath = DCMQuery(/ComplianceRecommendation[@id=$ComplianceRecommendationID]/Com plianceIssue/ComplianceResult/UnixFileACLRule/File[@id=$fileId]/@name) var message = "File and desired permissions are " + filepath + " " + permissions log debug message
400
In order to get the filename we first need to query the Compliance Recommendation object to get the fileId. With this fileId we can then query the DCM to get the fully qualified filename. After retrieving the information from the DCM we log the filename and desired permissions using the message variable. The key to the DCMQuery statements is using the correct object path. In our example we are querying: /ComplianceRecommendation[@id=$ComplianceRecommendationID]/ComplianceIs sue/ComplianceResult/UnixFileACLRule/@permissionString In order to find the correct path to this information we consulted the file %TIO_HOME%\xml\DcmObjectMappingsDocument.xml, which is located on the DCM server. This xml file contains a description of the objects in the DCM database. Example 7-4 on page 401 shows an extract of this file, defining the UnixFileACLRule object.
Example 7-4 UnixFileACLRule object definition
<dcmObject name='UnixFileACLRule'> <inherits> <object name='Rule'/> <object name='DesiredStateElement'/> </inherits> <attributes> <attribute name='id' isId='y'/> <attribute name='name' isId='n'/> <attribute name='description' isId='n'/> <attribute name='appliedTime' isId='n'/> <attribute name='dSEId' isId='n'/> <attribute name='fileResourceId' isId='n'/> <attribute name='directory' isId='n'/> <attribute name='permissionString' isId='n'/> <attribute name='directoryEffective' isId='n'/> <attribute name='permissionStringEffective' isId='n'/> </attributes> <relationships> <relationship name='File'/> </relationships> </dcmObject> From this example we can see that the UnixFileACLRule has an attribute permissionString and an attribute fileResourceId. This ID points to another object of type File. The File object is also defined in the DcmObjectMappingsDocument.xml and is shown in the following figure.
401
Example 7-5 File object definition
<dcmObject name='File'> <inherits> <object name='DcmObject'/> </inherits> <attributes> <attribute name='id' isId='y'/> <attribute name='name' isId='n'/> <attribute name='lockedUntil' isId='n'/> <attribute name='deviceModelId' isId='n'/> <attribute name='physicalContainerId' isId='n'/> <attribute name='locale' isId='n'/> <attribute name='rowVersion' isId='n'/> <attribute name='objectType' isId='n'/> <attribute name='ownerId' isId='n'/> <attribute name='path' isId='n'/> <attribute name='qualifier' isId='n'/> <attribute name='checksumType' isId='n'/> <attribute name='checksum' isId='n'/> <attribute name='lastAntivirusCheck' isId='n'/> <attribute name='version' isId='n'/> <attribute name='description' isId='n'/> <attribute name='managedSystemId' isId='n'/> </attributes> <relationships> <relationship name='SoftwareResource'/> <relationship name='SoftwareInstallable'/> <relationship name='ManagedSystem'/> <relationship name='UnixFileACL'/> <relationship name='WinFileACL'/> <relationship name='WindowFileACLRule'/> <relationship name='UnixFileACLRule'/> <relationship name='EPTaskFileAssoc'/> </relationships> </dcmObject> From the file object, we queried the name in order to get the full pathname of the file, using the DCMQuery:
Example 7-6 Using DCMQuery
DCMQuery(/ComplianceRecommendation[@id=$ComplianceRecommendationID]/Com plianceIssue/ComplianceResult/UnixFileACLRule/File[@id=$fileId]/@name)
402
In the next section of the workflow we define the message variable containing useful debug information. The message variable will be logged when the workflow is executed.
Example 7-7 Log the message variable
var message = "File and desired permissions are " + filepath + " " + permissions log debug message The last part of the workflow is the definition of a Perl scriptlet that will be executed on the target machine where the non-compliance occured.
Example 7-8 Definition of a Perl scriptlet
scriptlet (filepath, permissions) language = perl target = TargetID <<EOF if (-f $filepath) { TIOlog("Info", "$filepath exists OK to continue"); } else { TIOthrow("NoSuchFileOrDirectory", "$filepath does not exist can NOT continue"); } TIOlog("Info", "Converting $permissions to numerical equivalent"); my (@modes) = $permissions =~ /(...)(...)(...)$/g; my $result; my $numpermissions = ""; while (my $mode = shift @modes) { my $m = 0; $m += 1 if $mode =~ /[xsS]/; $m += 2 if $mode =~ /w/; $m += 4 if $mode =~ /r/; $numpermissions .= "$m"; } TIOlog("Info", "Numerical equivalent is $numpermissions"); $Cmd = "chmod $numpermissions $filepath"; TIOlog("Info", "Executing $Cmd"); `$Cmd`; $rc = $?; if ($rc ne 0) { TIOthrow("ChmodException,Failed to chmod $filepath RC is $rc); } else { TIOlog("Info", "Successfully executed chmod command"); } EOF
403
The scriptlet has 2 arguments: filepath and permissions. First a check is made to see whether the file exists. If the file exists a message is logged during workflow execution using the TIOlog routine. If the file does not exist an exception is thrown and the workflow will fail (TIOthrow routine). Next the permission string (for example r--------) is converted to the numerical equivalent (in this case 0400) and finally the chmod command is executed to change the file permissions of the target file to the desired permissions, returning the machine to a compliant state.
7.5.2 Compiling and testing a new workflow

Once we ared done entering the workflow in the workflow composer, we can compile the workflow. This is done by selecting Compile Compile as shown in Figure 7-55 on page 404.
Figure 7-55 Compiling a workflow
Compiling a workflow will check for syntax errors and will also save the new workflow. If no syntax errors are detected you will get a message saying compilation is successful, as shown in Figure 7-56 on page 404.
Figure 7-56 Wokflow compiled successfully
To test our new workflow we can run it by selecting Run Run. This opens a new dialog window, where the two required arguments for the workflow must be specified (Figure 7-57 on page 405).
404
Figure 7-57 Running a workflow - Input parameters
The ComplianceRecommendationID of a recommendation can be found by selecting the Recommendation tab from the target group or computer. By hovering the mouse pointer over the recommendation, the ID will be displayed as shown in Figure 7-58 on page 405.
Figure 7-58 Determining the compliance recommendation ID
In this example the compliance recommendation ID is 66288. Similarly the ID of a target computer can be found by hovering the mouse over the computer name. After filling in the compliance recommendation ID and target ID, the workflow can be executed by clicking the Run button. This will open a new window displaying the workflow deployment requests (Figure 7-59 on page 406).
405
Figure 7-59 Workflow Deployment Requests
The details of the execution can be seen by clicking on the Request Id, which opens a new window as shown in Figure 7-60 on page 406.
Figure 7-60 Workflow execution details
406
From this figure we can see that the workflow executes the perl scriptlet on the target and successfully changes the permissions on the target file.
7.5.3 Associating the custom workflow with the Recommendation Key

Now that we have tested the custom workflow we can change the global settings of Tivoli Provisioning Manager, ensuring the new custom workflow will be executed whenever new recommendations are generated, approved and run. In order to do this we select System Management Global Settings and next the Compliance tab, as shown in Figure 7-61 on page 407.
Figure 7-61 Global Settings Compliance Management
From this window we change the UnixFileACLDesiredStateElement_Remediation_wf ,as shown in Figure 7-62 on page 407 by selecting Properties.
Figure 7-62 Changing the workflow for the UnixFileACLDesiredStateElement_Remediation_wf key
407
In the next window, we replace the Placeholder_Security_Remediation with our new workflow Unix_File_Permissions_Remediation (Figure 7-63 on page 408).
Figure 7-63 Changing the default workflow for UnixFileACLDesiredStateElement_Remediation_wf
After saving the settings newly generated compliance recommendations for the Unix file permissions compliance check will use the new workflow for remediating non-compliance. Note: In the general availability code of this Tivoli Provisioning Manager V5.1, feature does not work; newly generated recommendations will not use the new workflow. This will be fixed in fixpack 1 for Tivoli Provisioning Manager V5.1.
408
Chapter 8.
Patch management
This chapter discusses the patch management functionality in Tivoli Provisioning Manager V5.1 and has the following sections: Introduction to patch management on page 410 Preparation required for the Tivoli Provisioning Manager server on page 412 Managing patches with the Deployment Engine (DE) on page 421 Managing patches with the scalable software distribution infrastructure on page 435 Workaround for the patch management workflows on page 449
409
8.1 Introduction to patch management

Patch management is an integral part of protecting customer services, corporate and customer data, and day-to-day operations. Tivoli Provisioning Manager provides tools to manage patch acquisition, evaluation, and deployment. However, keeping systems up-to-date and compliant with corporate security requirements is complex due to the following main factors: Vendors release a large number of updates on a frequent basis. Tracking and evaluating security risks and the appropriate software updates is time-consuming and requires in-depth knowledge of installed software, hardware and software dependencies, and corporate requirements. Deployment of patches must be managed to reduce downtime or service interruptions. Effective auditing and reporting is required to monitor deployment, verify compliance, and troubleshoot errors.
8.1.1 Patch management scenarios

In a dynamic IT environment, several situations require the services of patch management. These are: vendor releases new OS patches. new computers added to datacenter or extended enterprise. existing computers re-purposed. computers reconnected to network after an absence of several days or weeks.
8.1.2 Typical steps for patch management

We can define the steps for patch management as follows: 1. Review patch bulletin from vendor. This might be for OS or application vendors. 2. Acquire patch and test for site-wide applicability (system admin role). Note that the level to which patches are scrutinized depends on the environment that the computers are used. Less critical roles may just require computers to have all vendor recommended patches (automatic update). Mission critical systems need to have patches evaluated on a test system to make sure they will not break the production system. Different steps are typically done by different people.
410
3. Approve patches for groups of computers (software approver role). Patches must be tested and approved before installed in the production environment. 4. Schedule, distribute and apply approved patches, monitor status (software operator role). Distribution can involve considerable planning for a large enterprises. It may involve maintenance windows. 5. Verify patch installation (software operator role). This includes looking at the computers where patch installation has failed, troubleshoot the problems and reinstalled failed patches.
8.1.3 Tivoli Provisioning Manager V5.1 patch management

Tivoli Provisioning Manager V5.1 has the ability to manage patches using: the Deployment Engine (DE), through the Tivoli Provisioning Manager compliance checks and Tivoli Provisioning Manager Remediation mechanism the scalable software distribution infrastructure. Note: Currently only Microsoft Windows patch management is supported through the scalable software distribution infrastructure. You can perform patch management in Microsoft and UNIX environments using: Microsoft Windows Server Update Services (using DE or scalable software distribution infrastructure) Red Hat Enterprise Linux V3 (via Red Hat Network, using DE) AIX V5.3 (via Service Update Management Assistant, using DE) Solaris V10 (via Sun Update Connection using DE) Note: HP UNIX support is expected to be available with a future fix pack. Patch management in Tivoli Provisioning Manager V5.1 is tightly integrated with compliance management, which is discussed in Chapter 7, Compliance management on page 345. In this chapter we cover the Microsoft Windows Server Update Services (WSUS) scenario.
8.1.4 Scenario used to demonstrate patch management

The following machines have been used to carry out our tests: an AIX acting as Tivoli Provisioning Manager server called paris.
Chapter 8. Patch management
411
a Windows 2003 Standard Edition Service Pack 1 to function as a depot called Florence. the main target called London, running Windows 2000 Server Service Pack 4, as shown on Figure 8-1.
Figure 8-1 Scenario used to demonstrate patch management
The same procedure has also been tested on a Tivoli Provisioning Manager server running under Windows 2003 Service Pack 1.
8.2 Preparation required for the Tivoli Provisioning Manager server

Before patches can be applied on a target, the Tivoli Provisioning Manager server must be configured for patch management for each and every OS. In the scenario described in this redbook, we configured the machines paris and Cairo to perform patch management for the Microsoft Windows OS and applications.
8.2.1 Downloading the Windows Update Agent

The Microsoft Update Agent (WUA) must be installed and configured on endpoints for you to be able to determine which Microsoft software updates must be applied to these endpoints, download the updates, and then install them on the endpoints. WUA is the client component of the Microsoft Server Update Services server that is installed on the endpoints, and can be regarded as a scanning engine that enables the endpoints to receive updates either from a WSUS server (for
412
example, when there is no access to internet from the endpoint) or directly from the Microsoft Update site. If you have not installed this tool yet, you can download the WUA software package and copy it to the Tivoli Provisioning Manager server so that you can distribute it to managed systems. To set up the Microsoft Update Agent for distribution, follow these steps: 1. Go to the Microsoft Web site at: http://go.microsoft.com/fwlink/?LinkId=43264 and download the WindowsUpdateAgent20-x86.exe file. 2. Copy the WindowsUpdateAgent20-x86.exe file to the root folder of the file repository named LocalFileRepository. By default, the local file repository is the %TIO_HOME%\repository directory for Windows or $TIO_HOME/repository directory for UNIX on the Tivoli Provisioning Manager server. WUA is now ready for distribution. Tip: Ensure that the file is owned by tioadmin user in order to avoid file access permissions problems.
8.2.2 Configuring the Microsoft Updates Discovery

Tivoli Provisioning Manager can discover Microsoft updates and patches. This will make any updates and patches available from Microsoft known to the data center model (DCM) and eliminates the manual task of recreating the same information in Tivoli Provisioning Manager. The Microsoft Updates Discovery configuration downloads the wsusscan.cab file from the Microsoft Web site, extracts it, parses it, and then populates the data center model with this information. It also creates a software installable for each update and patch and provides a link to download the executable file. A Microsoft Updates Discovery configuration is supplied with the product if you want to use it immediately. Otherwise, you can create your own discovery configuration. The following categories of parameters can be changed: Locale: specifies the locale, for example en for english or it for italian
413
Patch Status: Available values include: NEW, APPROVED, DISCONTINUED. If nothing is selected, then the default is Not Approved. Product Family: Available values include: SQL, Exchange, Windows, Office Internet Security and Acceleration Server Product: Available values include: SQL Server 2005, Exchange Server 2003, Windows XP, Windows XP x64 Edition, Exchange 2000 Server, Windows Server 2003 Datacenter Edition, Windows Internet Explorer 7.0 Dynamic Installer, Windows 2000, Windows Server 2003, Office 2003, Office 2002/XP, Internet Security and Acceleration Server 2004, Windows XP 64-Bit Edition Version 2003 Severity: Available values include: Critical, Important, Moderate, Low, or Unspecified. A sample dialog is shown on Figure 8-2.
Figure 8-2 Microsoft Updates Discovery configuration
The syntax must be exact and may change should Microsoft decide to update the names. If you only want Windows XP patches, then the Product Family should be Windows and the Product Windows XP.
414
The Patch Severity level can be set in order to further reduce the number of patches to a more manageable level.
8.2.3 Initiating the Microsoft Updates Discovery

Important: We discovered a defect in the general availability code, that prevents the process to complete successfully until you make a change to the MS_SOA_DiscoverWindowsUpdates workflow on the Tivoli Provisioning Manager server. This defect has been already fixed in Tivoli Provisioning Manager for Software. IT will be incorporated into Tivoli Provisioning Manager FP01 that is planned to be available in Dec. 2006. Refer to section 8.5, Workaround for the patch management workflows on page 449 for details. Once you modify the Microsoft Update Discovery to meet your needs, you can schedule the discovery or run it immediately to update the data model. To run the discovery immediately on the newly created discovery configuration, click Run to start the operation, as shown on Figure 8-3. Note: There is no need to run Microsoft Updates Discovery on a daily basis. You can do it once a week since Microsoft changes the content of wsusscn.cab file once a week or even once in two weeks.
415
Figure 8-3 Microsoft Updates Discovery
The workflow that is associated with Microsoft Updates Discovery is MS_SOA_DiscoverWindowsUpdates. This workflow updates the DCM with patch information provided by wsusscan.cab. Here is an high level description of the actions performed by this workflow: 1. Downloads wsusscan.cab file from the following URL: http://go.microsoft.com/fwlink/?LinkId=40751 2. Unpacks wsusscan.cab and creates package.cab. Note: With Tivoli Provisioning Manager Fix Pack 1, a new global variable will be introduced, called wsus-download-server-name which will point to an existing Windows box in order to perform operations on cab file. Once this cab file extracted, its contents will be zipped up and sent to the Tivoli Provisioning Manager server. Unzip tool will be available on all Tivoli Provisioning Manager platforms. 3. Unpacks package.cab and creates package.xml.
416
4. Passes the package.xml file to the script WsusscanToDcm.sh. This very last step of the workflow is to run the script WsusscanToDcm.sh. The WsusscanToDcm.sh script logs entries into the wsusscan.log file. Important: If you are running your Tivoli Provisioning Manager server on a UNIX box, make sure you download the cabextract utility, as detailed in Getting the CabExtract utility for AIX on page 417.
MicrosoftWeb file repository

A file repository is a server that you use to centrally store software, images, scripts, application data, and other files that you want to install or run on managed systems. File repositories are used in several ways: When you add new software to the software catalog, you can select a file repository where you currently store the installation packages. When you capture an image from a server, you can select the file repository where you want to store the image. When you want to create external software catalogs, such as Microsoft Windows Server Update Services, that is a specialized file repository providing software updates. The last file repository is called MicrosoftWeb and points to the following url: http://go.microsoft.com/fwlink This file repository is used to flag each Windows update as "not-downloaded yet". Once the download of an update is done, MicrosoftWeb is replaced with the real file repository location. This mechanism is also used for subsequent patches download. Only patches that still have MicrosoftWeb flag will be downloaded.
Getting the CabExtract utility for AIX

The cabextract utility is used by the Tivoli Provisioning Manager 5.1 to unpack the wsusscan.cab file from Microsoft website and the subsequent package.cab is generated by the first wsusscan.cab unpackage operation. On the Windows Operating System, this utility is part of Cygwin installation. For a UNIX operating system, you must download it before run the Microsoft Update Discovery scan.
417
Note: IBM plans to use extrac32.exe (a native tool in Windows Operating System) cabextract utility in a future release of Tivoli Provisioning Manager patch management solution. We used the below URL to download this utility for AIX: http://aixpdslib.seas.ucla.edu/packages/cabextract.html The available version for AIX 5.3 is a file called cabextract.1.1.tar.Z. You can follow Example 8-1 on page 418 to apply the package to the Operating System.
Example 8-1 Installing cabextract utility on the AIX Operating System
Download the file and copy it into a temporary directory. [root@milan][/tmp/chicco]-> ls -la total 456 drwxrwxrwx 2 root system drwxrwxrwt 16 bin bin -rw-r----1 root system cabextract.1.1.tar.Z
512 Sep 26 13:45 . 2560 Sep 26 13:45 .. 224097 Sep 26 13:45
Uncompress the file with the below command: [root@milan][/tmp/chicco]-> uncompress cabextract.1.1.tar.Z You have now a tar version of the file. Check if it has been build using the relative or absolute path name for the files contained in the archive using the following command: [root@milan][/tmp/chicco]-> tar tvf cabextract.1.1.tar -rwxr-xr-x 0 0 513099 Oct 02 15:27:41 2005 ./usr/local/bin/cabextract -rw-r--r-0 0 2193 Oct 02 15:27:42 2005 ./usr/local/man/man1/cabextract.1 The file names starts by ./ so they are referring to a relative path name; this means that the above directory structures will be created starting from the current directory. Change directory to the root and run the below command: [root@milan][/]-> tar xvf /tmp/chicco/cabextract.1.1.tar x ./usr/local/bin/cabextract, 513099 bytes, 1003 media blocks.
418
x ./usr/local/man/man1/cabextract.1, 2193 bytes, 5 media blocks. Make sure you link the file to a path that is accessible by all the users; the MS_SOA_DiscoverWindowsUpdates workflow is run by tioadmin, so it must be able to access this file. [root@milan][/]-> ln -s /usr/local/bin/cabextract /usr/sbin/cabextract [root@milan][/]-> ls -la /usr/sbin/cabextract lrwxrwxrwx 1 root system 25 Sep 26 13:48 /usr/sbin/cabextract -> /usr/local/bin/cabextract
8.2.4 Imported Windows patches in the DCM

When the wsusscanToDCM.sh script completes, a new Microsoft group, containing all the Microsoft patches definition is created. You can browse in this group by clicking: Software Management Manage Software Catalog Groups. Figure 8-4 reflects what was specified when the Microsoft Updates Discovery was run.
419
Figure 8-4 Imported groups of Windows patches
The DCM database is populated with the data contained in the package.xml file. This file, after the extract utility completes its processing, can be found in the following path: /opt/ibm/tivoli/tpm/repository/wua/wsusscancab/update. This directory contains also some sub-directories created by the package.cab unpack. A sample is shown in Example 8-2 on page 420.
Example 8-2 Content of /opt/ibm/tivoli/tpm/repository/wua/wsusscancab/update directory
This example shows the sub-directories stucture created by the unpack operation against the package.cab file: [root@paris][/opt/ibm/tivoli/tpm/repository/wua/wsusscancab/update]-> ls -la total 23640 drwxrwxr-x 7 tioadmin tioadmin 256 Sep 25 09:46 . drwxrwxr-x 3 tioadmin tioadmin 256 Sep 25 09:21 ..
420
drwxrwxr-x drwxrwxr-x drwxrwxr-x drwxrwxr-x drwxrwxr-x -rw-rw-r--
2 27 2 65 28 1
tioadmin tioadmin tioadmin tioadmin tioadmin tioadmin
tioadmin tioadmin tioadmin tioadmin tioadmin tioadmin
413696 4096 413696 4096 4096 11252198
Sep Sep Sep Sep Sep Sep
25 25 25 25 25 12
09:26 09:26 09:31 09:31 09:45 11:10
core eula extended files localized package.xml
The cabextract operation against this file took a long time, arounfd 20 or 30 minutes, depending by the machine you are using, cause it extract a big amount of files (and therefore MBs) as shown by this sample output: [root@paris][/opt/ibm/tivoli/tpm/repository/wua/wsusscancab/update]-> du -ms 292.55
8.3 Managing patches with the Deployment Engine (DE)

This method (see Figure 8-5 on page 422) does not use the Tivoli Provisioning Manager scalable software distribution infrastructure. For the Microsoft patches, this means that the WUA agent will communicate with the Microsoft web site in order to directly download each patch to be applied. WUA agent is also reponsible for installing the patches on the endpoint after they are approved from the Tivoli Provisioning Manager user interface. Note that WSUS server is the interface to Microsoft Web site for finding new patches and downloading those patches and typically will be put in a DMZ (demilitarized zone ) to isolate it from the datacenter (since it needs to access internet.) In the Windows patch management using the Deployment Engine scenario, you need to install a WSUS server. We will see later that if we use the scalable software distribution infrastructure instead, you dont need that component.
421
www.microsoft.com
TPM Server DE
Endpoint
WUA WSUS Server
Figure 8-5 Managing Microsoft patches with the Deployment Engine
Follow the steps described in the next pages for a succesfull patch installation.
8.3.1 Creating computer groups

Defining groups and their members is a way of organizing managed computers and helping to facilitate software distribution, compliance, patch management, and other tasks. You need to create an empty group first, and then populate it with all the target computers that you want to monitor and scan for missing patches. When you set up a group, all computers in the group must comply with the group compliance checks, otherwise the group will be considered noncompliant. Note: Before creating a group, you must ensure that the machine have been discovered. Do the following to create a group: 1. In the navigation pane, click Inventory . Manage Inventory Groups. 2. Click Edit Add Group. Type a name and a description for the new group. In our case, we named it ITSO. 3. Select Computer as the Type of the group. In the Available Members list, do not select any computers. 4. Click Save. Next you need to add target computers to the group. 5. Click Inventory Manage Discovery Discovered Computers.
422
In the Discovery Configuration list, select the discovery configuration that you have created. 6. Click Search. All the computers that have been discovered using the selected discovery configuration are listed. 7. In the list, select the target computers that you want to add to your group. 8. Expand Assign Computer to. In the Group list, select the name of the empty group that you have just created. 9. Click Proceed.
8.3.2 Ensure that an initial inventory is performed on targets

Refer to Configuring and running inventory scans on page 197 on how to perform an inventory on the targets.
8.3.3 Creating a security compliance check

You can use the security compliance checks to verify whether or not patches are required on your group of endpoints. The endpoints should be missing at least one patch. You can also select to provide a Tivoli Provisioning Manager user with compliance check notifications. If you do, an e-mail notification will automatically be generated if a compliance check discovers noncompliance on an endpoint. Follow this procedure: 1. Select a group of machines. 2. Select the Compliance page and from the Edit pull-down menu select Add Security Compliance Check, as seen on Figure 8-6. 3. Select Operating System Patches and Updates from Available Compliance Checks.
423
Figure 8-6 Adding Security Compliance Check
Note: It is important to mention that OS Patches and updates fall under the Security Compliance and not under the Software Compliance Check.
8.3.4 Installing a WUA agent

The Windows Update Agent (WUA) enables you to determine which computers require updates, download the required updates, and install them. The WUA is already downloaded to the local file repository on the Tivoli Provisioning Manager server as described in 8.2.1, Downloading the Windows Update Agent on page 412. You can install the WUA on all endpoints in your group using the Install Software Products page. Once WUA is installed on the endpoints, Tivoli Provisioning
424
Manager will configure the WUA clients to connect to Microsoft to search for the latest updates, download, and install them. To install WUA on endpoints, follow these steps: 1. In the navigation pane, expand Software Management. 2. Click Install Software Products. The Install Software Products page is displayed. 3. In the Task Name, type a relevant name for the task. You will use this name to identify the task and monitor its status on the Track Tasks page. 4. In the Select Software section, select the Windows Update Agent (WUA) software product. 5. In the Select Computers section, use the Display list to filter the displayed computers By Group. Select the name of your group. 6. In the Schedule section, click Now to run the WUA installation task immediately, or specify the date and time when you want the task to start. 7. If you want to be notified about the task status, specify the appropriate notification settings in the Notification section. 8. Click Submit. A task is created for the WUA installation, and the Track Tasks page is displayed. You can click the task name to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status. You have finished installing WUA on all of the endpoints in your group. The WUA provides the ability to install multiple updates without rebooting the endpoints after each update installation. The WUA prompts you to reboot only if an update requires a reboot and if you have selected the reboot option on the Install Software Products page. Figure 8-7 shows the values that you can specify for the setup. The defaults that we used are: setup: /quiet/norestart ForceOption: /noforce SilentOption: /quiet RebootOption: /norestart
425
Figure 8-7 Installing a WUA agent
8.3.5 Microsoft WUA scan discovery configuration

After you have created the security compliance check, you can run discovery using the Microsoft WUA discovery configuration. This will scan the endpoints in your group for missing patches. The scanning task for the WUA discovery scan is initiated by the MS_WUA_Scan.wkf workflow. The scan returns a list of patches that are missing from each of the selected endpoints. For new patches, the MS_WUA_Scan.wkf workflow creates new software modules, and adds them to the data center model. For patches that are already installed on the endpoints, the MS_WUA_Scan.wkf workflow creates software installations in the data center model.
426
Initiating a patch discovery using WUA scanner

To initiate a WUA discovery scan on the endpoints in your group follow these steps: 1. In the navigation pane, expand Inventory. 2. In the navigation pane, click Manage Discovery Discovery Configurations. The Manage Discovery Configurations page is displayed. 3. In the list, identify the Microsoft WUA Scan discovery configuration and, in that row, click Run. The Initiate Discovery page is displayed. 4. In the Task Name field, type a relevant name for the task. You will use this name to identify the task and track its status on the Track Tasks page. 5. In the Select Targets section, use the Display list to filter the displayed computers by group. In the list, select the group that you have created. 6. In the Schedule section, click Now to run the discovery task immediately, or specify the date and time when you want the discovery to start. 7. If you want to be notified about the task status, specify the appropriate notification settings in the Notification section. 8. Click Submit. A task is created for the WUA scan, and the Track Tasks page is displayed. You can click the task name to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status. You have now set up and run the WUA scan on all endpoints in your group. The WUA scan creates a list of recommendations, based on the patches that are missing from your endpoints. You can now see the recommendations list to verify the compliance status of all endpoints in your group. If you want to see which endpoints in your group are missing which patches, you can generate a compliance report. As seen on Figure 8-8, a Microsoft WUA scan is initiated for a group of machines like in this case ITSO - Group of one with London.
427
Figure 8-8 Initiating a patch discovery using the WUA scanner
Important: When running the WUA scan, you must access the Internet.
8.3.6 Running a compliance check for a group

A compliance check must be run to find out what are the patches currently installed and what are the patches required for a group of computer. This is an efficient way to handle compliance checks. Notice that from Figure 8-9, we see that the group of one machine London is not compliant, because it indicates Compliant: 0%.
428
Figure 8-9 Security Compliance Check
For a single machine you can either be 100% compliant or 0% compliant. If you see 75% compliant for a group of 4 machines, it means that 3 machines are compliant and one is not. The compliance check compares the result of the WUA scan with the latest level stored in the DCM.
Running a compliance check for a single machine

The compliance check can also be performed against a single machine as seen on Figure 8-10.
429
Figure 8-10 Issues and recommendations
In this figure, the Issue field indicates that no compliance check for this machine has been run and the recommendation is to run a compliance check.
Task details: Compliance check

In Figure 8-11, you can see that the compliance check was successfully ran.
430
Figure 8-11 Task Details: Compliance Check
More information can be obtained by clicking on the Request ID link on the bottom right of the above page.
8.3.7 Compliance reports

Compliance reports provide patch compliance information, such as what computer groups or individual computers do not have compliance checks, and what computers are compliant with their security or software compliance checks. To generate patch compliance reports follow these steps: 1. In the navigation pane, expand Reports. 2. In the navigation pane, click Compliance. 3. In the Compliance003 - Do computers comply with their patch compliance checks? row, click Run. The Report page lists all the endpoints that have a patch compliance check. The compliance status of the endpoints is listed in the Is Compliant column.
431
The type of compliance check they are compliant or noncompliant with is listed in the Compliance column. 4. Click Reports Compliance again. 5. In the Compliance008 - What patches are missing on what computers? row, click Run. The Report page lists all of the missing patches and their corresponding endpoints. Figure 8-12 shows an extract of the report Compliance008.
Figure 8-12 Running Compliance008 report
8.3.8 Viewing and approving recommendations

Before the patches can be applied they must be approved. This can be achieved by selecting all patches with one click or by selecting individual patches as seen in Figure 8-13.
432
Figure 8-13 Viewing and approving recommendations
To display the above dialog box, Issues and Recommendations, follow these steps: 1. From a Computer or Group, select the compliance tab. 2. Click on the Percentage link. To approve patches follow these steps: 1. Patches to be approved must first be selected. 2. The status must be changed from Opened or Failed by clicking Approve. The status will be changed to Approve.
8.3.9 Approving patches for installation

After you have approved patches as candidates for distribution, you must identify the endpoints that need to be updated, and approve missing patches for installation.
433
Identifying missing patches

The security compliance check for operating system patches and updates provides a list of recommendations per endpoint that requires patches and per missing patch. The Compliance page for the group displays the recommendations so that software approvers can review and approve patches for installation on endpoints. You can also review a list of recommended patches at group level. To view a list of all recommended patches, you can: Review the Compliance page of the selected group. The percentage in the Compliant column for Operating System Patches and Updates indicates the total patch compliance for all the endpoints in the group. Click the percentage to display the Issues and Recommendations page for the group. Recommendations are listed per endpoint that requires patches and per missing patch. The recommendations are to install the missing patches. View a report that lists missing patches. This option is useful if you want to review recommendations for specific endpoints or groups of endpoints.
Approving patches to install

For patch management, Tivoli Provisioning Manager uses a compliance remediation process to install all of the patches that are approved for installation. When noncompliance occurs, recommendations are generated to suggest how to fix the noncompliance issues. On the Issues and Recommendations page for the selected group, recommendations are listed per endpoint and per missing patch. For operating system patches and updates, the recommendation is to install the missing patches with these steps: 1. Check that the patches to be applied patches are selected. 2. Click Run. A compliance remediation task is created for all approved recommendations. You can click the task name to see details about its status and monitor its progress until the task has completed. On Figure 8-14 we see that the Compliance Remediation has been submitted.
434
Figure 8-14 Compliance Remediation for patches
The status will be changed from Approve to Implementing when the task is run. This action actually starts the process. You can track it track like any other Tivoli Provisioning Manager task.
8.4 Managing patches with the scalable software distribution infrastructure

The scalable software distribution infrastructure enables the management of large numbers of target computers or endpoints in a variety of topologies, and provides a fast and reliable way to distribute and install patches on target computers or groups of computers that require them. Note: Currently only Microsoft Windows patch management is supported through the scalable software distribution infrastructure.
The patch management steps using the scalable software distribution infrastructure can be broken down to two high level steps:
435
1. Scan for missing patches 2. Installing the missing patches
8.4.1 Scan for missing patches

In this method we have to have a common agent on the endpoint, because scalable software distribution infrastructure uses the common agent as described in Chapter 5, Software management in Tivoli Provisioning Manager V5.1 on page 235. We also need to install the WUA agent which will communicate with the Microsoft web site in order to download patches to be applied. It is possible to put a proxy server and a firewall to isolate the Software management in Tivoli Provisioning Manager server from the internet. We no longer have a WSUS server in this scenario. wsusscan.cab file that describes the patch catalog is periodically dowloaded to the Tivoli Provisioning Manager server and using the content delivery server it is distributed to the endpoints. For the scan part, device management server runs a scan job on the endpoint. The cab file, which is the list of patch catalog is pushed up to the endpoint prior to the missing patch scan. The scan is done and the result of the scan is sent to the Tivoli Provisioning Manager server and displayed on the screen.
8.4.2 Installing the missing patches

Once it is determined that which patches need to be installed, device management server runs a workflow that fetches those patch files from the vendor (Microsoft in this case), publishes them to content delivery server so that they are available to endpoints and runs job on the endpoints that fetches the individual patches and calls the vendor agent (WUA in this case) to install the patches. The status is then updated to the Tivoli Provisioning Manager server.
8.4.3 Detailed steps for patch management using the scalable software distribution infrastructure
The procedure to apply patches using the scalable software distribution infrastructure consist of these steps: 1. Configuring the Microsoft Updates Discovery. Refer to Configuring the Microsoft Updates Discovery on page 413. 2. Creating a region, a depot and a zone on page 431. 3. Creating a group of machines targeted for patch management. Refer to Creating computer groups on page 422.
436
4. Downloading patches to Tivoli Provisioning Manager repository on page 439 5. Installing the Tivoli common agent on targets on page 443. 6. Creating an SOA-SAP for endpoint operations on page 444. 7. Installing a WUA agent for all members of the group. Refer to Installing a WUA agent on page 424. 8. Perform an initial inventory discovery for machines in the group on page 446. 9. Creating a security compliance check. Refer to Creating a security compliance check on page 423. 10.Review and approve all patches to be applied. Refer Viewing and approving recommendations on page 432 and Approving patches for installation on page 433. 11.Run compliance remediation to apply patches. Refer to Managing non-compliance on page 382 on details on how to run compliance remediation. 12.Repeating the compliance verification process on page 446. 13.Generating the compliance report again on page 448. The above list includes many steps that were carried out in the previous section. All the duplicate steps from the previous section or other chapters are not repeated. Only the new steps are explained.
8.4.4 Creating a region, a depot and a zone

We first created a region called EU zone as seen in Figure 8-15. This step will install the common agent. If it was previously installed, then it must be first removed. Note that the IP range for a zone must be continuous. If this is a problem then multiple zones must be created.
437
Figure 8-15 Creating a region and a zone
See Note that the IP range for a zone must be continuous. If this is a problem then multiple zones must be created. on page 437 for more information on creating zones.
Creating a depot
It is recommended to replace the default name with another one that is easier to identify. In our example we used \depot. We defined a depot size of 10 GB. The Bandwidth is set to Adaptive. Refer to Figure 8-16.
438
Figure 8-16 Creating a depot
You do not need to dedicate the depot to patch management operations. It can also be used by other components of Tivoli Provisioning Manager. See Creating a depot on page 261 for more information on creating depots.
8.4.5 Downloading patches to Tivoli Provisioning Manager repository

You must download the available Microsoft patches before they can be installed on the target computers. To do this, you run a workflow which run through the list of available Microsoft patches created when you ran the Microsoft Updates Discovery. The workflow downloads each of the patches and update the software module for each patch with its new local location. The download time depends on the
439
Microsoft Update Discovery configuration and the subsequent number of patches that must be downloaded. Tip: Do not download the patches in all the languages but only in those required for your environment. This will save a lot of time and space on the Tivoli Provisioning Server machine. In our test environment we downloaded all the Microsoft patches in english locale, and this resulted in about 10 GB. You may wish to schedule the downloads for off-peak times to minimize wait times. To schedule the downloading of the Microsoft updates perform these steps: 1. In the navigation pane, click Automation Workflows. 2. Enter the workflow name, MS_SOA_DownloadWindowsUpdates in the Search box. Click Search. 3. Click Run. 4. Expand the Workflow run schedule section and complete the fields: c. Ensure the Schedule this task with the following details check box is selected. d. Update the fields to indicate how often the workflow should run to download patches. 5. Click Run. The Track Tasks page is displayed. You can see details about the workflow status on this page. You have now scheduled the workflow to download available Microsoft patches. The download may take 4 to 6 hours depending on the number of patches and your connection speed. Subsequent downloads will take less time since there will be less patches to download and it will process only the delta between those previously downloaded. Figure 8-17 on page 441 shows the workflow execution.
440
Figure 8-17 Running MS_SOA_DownloadWindowsUpdates
Note: Make sure that the time is synchronized between the Tivoli Provisioning Manager server and the workstation you are installing the patches to.
Downloading patches workflow execution log

You can track the status of the download looking at the workflow execution logs as shown in Figure 8-18.
441
Figure 8-18 Downloading Patches Workflow Execution Log
All the patches downloaded can be found to the following directory on the AIX Tivoli Provisioning Manager Server: /opt/ibm/tivoli/tpm/repository/wua/windowsupdates
Reboots controlled within workflows

The system has a time-out of five minutes to allow the machine to reboot. This is indicated by the step workflow Sleep_local on Figure 8-19.
442
Figure 8-19 Reboots controlled within workflows
8.4.6 Installing the Tivoli common agent on targets

Before installing a TCA, two security roles on Windows targets must be checked and updated if necessary. These two roles are: 1. Act as part of the Operating System 2. Log on as a Service The above two roles can be checked by going to: Local Security Policy Local Policy User Rights Assignment. Also ensure that the name of the machine is fully qualified in the DNS or the host file. After performing the changes, it is important to reboot the machine. A TCA provides remote deployment capabilities, secure connectivity and a single entry point. Refer to the Chapter 6, Common Agent Services on page 307 for instructions on how to install a Tivoli common agent.
443
8.4.7 Creating an SOA-SAP for endpoint operations

This operation, as seen on Figure 8-20, is very fast because it is performed at the DCM level. It allows a TCA to perform Software Distribution operations. Note: Even if there is only one Workflow Parameter Name, it must be selected to proceed.
Figure 8-20 Creating an SOA-SAP for endpoint operations
Task details for ITSO Create SOA-SAP for clients

Figure 8-21 shows the task details for ITSO Create SOA-SAP for clients. Name of the Favorite Tasks: ITSO Create SOA_SAP for clients. Description: Getting ready to install SOA_SAP on London and Florence.
444
Figure 8-21 Task details for ITSO Create SOA-SAP for clients
Checking the status of SOA-SAP for endpoint operations

It is important to ensure that the default status for endpoint-operations indicate SOA-SAP as seen on Figure 8-22. Under Device Operation you should find endpoint-operations. Under the column labeled Default SAP it should indicate SOA-SAP.
Figure 8-22 Checking the status of SOA-SAP for endpoint operations
445
8.4.8 Perform an initial inventory discovery for machines in the group

Refer to Inventory discovery on page 194 for more information on how to perform an inventory discovery. Figure 2-40 shows the ITSO - Inventory Discovery details in our environment.
Figure 8-23 Inventory Discovery
8.4.9 Repeating the compliance verification process

If some patches that you have approved and implemented failed to install, the Compliant percentage displayed on the group page is less than 100%. To achieve 100% compliance, you must repeat the compliance verification process. To repeat the compliance verification process: 1. In the navigation pane, click Inventory Manage Inventory Groups. The Manage Groups page is displayed. 2. Select the name of your group, for example, the ITSO - group of one with London group, and then click the Compliance tab. 3. Click Run Run Compliance Check again. Under Security Compliance Checks, the Compliant column in the table displays the percentage of target computers that are compliant for operating system patches and updates.
446
a. If all patches installed successfully, the Compliant percentage under Security Compliance Checks is 100%. b. If some patches failed to install, the Compliant percentage is less than 100%, and the compliance verification process must be repeated until 100% compliance is achieved. 4. Click the percentage for more details. The Issues and Recommendations page is displayed. It lists all issues and recommendations per target computer and per missing patch. 5. Select the check box preceding the Computer column header to select all recommendations, and then click Approve. The status of all recommendations is changed to Approved. Where appropriate, you can also choose to ignore patches. Ignored patches will not make the group noncompliant. 6. Select all approved recommendations, and then click Run. An installation task for all approved patches is created. You can click the task name to see details about its status and monitor its progress until the task has completed. 7. Return to the Compliance page for the group, and access the Issues and Recommendations page again. The status for the issues is now Implemented. 8. Click Run Run Compliance Check again. If all patches installed successfully, the Compliant percentage under Security Compliance Checks is 100%. You have run the compliance check again to update the Compliant status for the group. You can now generate the compliance report again to verify whether all the target computers are now compliant. Another way to verify this is to access the Issues and Recommendations page (by clicking the Recommendations tab). It should now be empty as shown in Figure 8-24 on page 448.
447
Figure 8-24 Security compliance check after applying patches
8.4.10 Generating the compliance report again

Generating the compliance report again enables you to verify whether all target computers in your group are now compliant. To generate the compliance report again: 1. Click Reports Compliance. 2. In the Compliance003 - Do computers comply with their patch compliance checks? row, click Run. All the computers with a patch compliance check will be listed. Their compliance status will be listed in the Is Compliant column. The type of compliance check they are compliant or noncompliant with will be listed in the Compliance column. Currently, all of the target computers should be compliant with their patch compliance checks.
448
8.5 Workaround for the patch management workflows

This workaround only applies to Tivoli Provisioning Manager 5.1 GA code. Tivoli Provisioning Manager for Software and Tivoli Provisioning Manager 5.1 Fix Pack 1 will not have this problem. The workaround consist of some steps to be performed on both the MS_SOA_DiscoverWindowsUpdates and MS_SOA_DownloadWindowsUpdates workflows and the WsusscanToDcm.sh script as detailed in the below sections.
8.5.1 Applying the workaround to the MS_SOA_DiscoverWindowsUpdates workflow

Follow this procedure to apply the workaround to the MS_SOA_DiscoverWindowsUpdates workflow: 1. Enter MS_SOA in the Search box on the navigation pane. 2. Select MS_SOA_DiscoverWindowsUpdates workflow and scroll down the text unless you find a line like the following: var Repository = "Microsoft Web" 3. change the above line in: var Repository = "MicrosoftWeb" 4. At the beginning of the workflow, change its name to do not overwrite the original one: workflow MS_SOA_DiscoverWindowsUpdates_fixed(in DiscoveryID) implements Discovery.Discover LocaleInsensitive 5. The compilation of the workflow validates the workflow itself and create a new one with the name specified, in the above example, a new workflow called MS_SOA_DiscoverWindowsUpdates_fixed in created. 6. You should now associate this new workflow to the Microsoft Update Discovery following these steps: a. Select Inventory Manage Discovery Discovery Configurations from the navigation pane. b. Click on the discovery configuration called Microsoft Updates Discovery. c. In the Workflows tab select Edit Assign Workflow. d. In the Logical Device Operation pull down menu select Discovery.Discover; the Workflow pull down menu is populated.
449
e. Select the workflow you have modified, in the example MS_SOA_DiscoverWindowsUpdates_fixed as shown in Figure 8-25 on page 450.
Figure 8-25 Assign Workflow to the Microsoft Updates Discovery
f. Click Save 7. The last step before you can run again the discovery, is remove the old workflow association selecting Remove from the context icon at the right of the workflow name. 8. Modify the WsusscanToDcm.sh script as detailed in section 8.5.2, Applying the workaround to the WsusscanToDcm.sh script on page 450 before run again the discovery.
8.5.2 Applying the workaround to the WsusscanToDcm.sh script

This workaround is only needed for an AIX and Solaris Tivoli Provisioning Manager server, used to implement the patch management solution for Windows Operating Systems.
450
As detailed in 8.2.3, Initiating the Microsoft Updates Discovery on page 415, the last step of the MS_SOA_DiscoverWindowsUpdates is to call a script called WsusscanToDcm.sh that accept as parameters, the package.xml file that must be parsed and the file repository used to store the patches in the DCM. The default heap size for JVM on AIX and Solaris it is only 64MB, and this is not enough for this process to complete. The minimum size for max heap setting is 256MB. To apply the workaround login or switch user to tioadmin and edit this script: $TIO_HOME/repository/wua/WsusscanToDcm.sh Example 8-3 on page 451 shows the original script, and the one modified with the workaround applied.
Example 8-3 Changes to the WsusscanToDcm.sh script
The original script looks like the following: #!/bin/bash # # # Licensed Materials - Property of IBM # 5724-F75 # (C) Copyright IBM Corp. 2005 # All Rights Reserved # US Government Users Restricted Rights -Use, duplication or # disclosure restricted by GSA ADP Schedule Contract with IBM Corp. # # . $TIO_HOME/tools/setupCmdLine.sh $JAVA_HOME/bin/java \ -Dkanaha.config=file:$TIO_HOME/config \ -Dlog4j.configuration=file:$TIO_HOME/config/log4j-util.prop \ -Dkanaha.logs=$TIO_LOGS \ -Dkanaha.logfile=$TIO_LOGS/wsusscan.log \ -classpath $TIO_HOME/eclipse/startup.jar org.eclipse.core.launcher.Main \ -launcher $TIO_HOME/eclipse \ -name Eclipse \ -noSplash -application launcher.CliLauncher \ WsusscanToDCM $*
451
exit $? The workaround consist of adding more memory to the java process that loads the patches into the DCM. The script must reflect these changes: #!/bin/bash # # # Licensed Materials - Property of IBM # 5724-F75 # (C) Copyright IBM Corp. 2005 # All Rights Reserved # US Government Users Restricted Rights -Use, duplication or # disclosure restricted by GSA ADP Schedule Contract with IBM Corp. # # . $TIO_HOME/tools/setupCmdLine.sh $JAVA_HOME/bin/java \ -Xms32m \ -Xmx256m \ -Dkanaha.config=file:$TIO_HOME/config \ -Dlog4j.configuration=file:$TIO_HOME/config/log4j-util.prop \ -Dkanaha.logs=$TIO_LOGS \ -Dkanaha.logfile=$TIO_LOGS/wsusscan.log \ -classpath $TIO_HOME/eclipse/startup.jar org.eclipse.core.launcher.Main \ -launcher $TIO_HOME/eclipse \ -name Eclipse \ -noSplash -application launcher.CliLauncher \ WsusscanToDCM $* exit $?
8.5.3 Applying the workaround to the MS_SOA_DownloadWindowsUpdates workflow

Follow this procedure to apply the workaround to the MS_SOA_DownloadWindowsUpdates workflow. 1. Enter MS_SOA in the Search box on the navigation pane.
452
2. Select MS_SOA_DownloadWindowsUpdate workflow. At the beginning of the script you find a line like the following: array WindowsUpdatesInfo = Java[com.ibm.tivoli.orchestrator.discovery.wsusscan.helper.DcmSoftwa reComponentHelper#getAllUnfetchedInstallableURL("Microsoft Web")] 3. change the above line in: array WindowsUpdatesInfo = Java[com.ibm.tivoli.orchestrator.discovery.wsusscan.helper.DcmSoftwa reComponentHelper#getAllUnfetchedInstallableURL("MicrosoftWeb")] 4. At the beginning of the workflow, change its name to do not overwrite the original one: workflow MS_SOA_DownloadWindowsUpdates_fixed LocaleInsensitive 5. The compilation of the workflow validates the workflow itself and create a new one with the name specified, in the above example, a new workflow called MS_SOA_DownloadWindowsUpdates_fixed in created. 6. You should now associate this new workflow to the Task created to download the patches. To do this, follow these steps: a. Select Task Management Favorite Tasks. b. Delete the task previously created with the procedure described in section 8.4.5, Downloading patches to Tivoli Provisioning Manager repository on page 439. c. Create a new favorite task, selecting Edit Create Workflow Taks. d. Once provided a name, mandatory, and a description, select the workflow name you just modified. Save the changes and save the task. 7. Execute the task to allow the patches that are registered into the DCM with the flag MicrosoftWeb to be downloaded from the Microsoft Web Site.
453
454
Chapter 9.
Image management
This chapter introduces the image management (also called OS provisioning) functionality in Tivoli Provisioning Manager V5.1 and discusses the following: Introduction to image management on page 456 Ways to perform image management on page 458 Installing a Boot Server on page 459 Preparation required to capture an image on page 468 Capturing the images on page 473 Restoring the images on page 481 Advanced topics on page 489
455
9.1 Introduction to image management

Image management is a way to perform a complete installation of a new computer or the reinstallation of an existing one. That includes the deployment of the initial operating system (OS), a Tivoli Common Agent, the applications and all configuration that is required. Image management corresponds to the term Pristine Installations. This term is used by Tivoli Configuration Manager, NetView Distribution Manager and the CID (Configuration Installation and Distribution) process. The Rembo Boot Server can perform all functions that an existing Tivoli Configuration Manager Pristine Manager can do. In 2006, IBM purchased a Swiss company headquartered in Geneva and called Rembo Technology SaRL. They specialize in image management. They have two main products: the Rembo Toolkit Version 4 and Rembo Auto-Deploy. The Rembo Toolkit was used to allow Tivoli Provisioning Manager V5.1 to perform image management natively. The Rembo Auto-Deploy was re-branded as an IBM product called Tivoli Provisioning Manager for Operating System Deployment. Rembo Toolkit is also named as Tivoli Provisioning Manager for OS Deployment Embedded Edition. Image management using the Rembo Boot Server supports two main operations: Image capture and image restoration. Image capture is the process of creating a clonable image from a master computer. Image restoration is the process of restoring or deploying the clonable image to one or multiple computers. Note: For more information on image management in Tivoli Provisioning Manager, you can refer to the online document Tivoli Provisioning ManagerVersion 5.1, Managing operating systems at: http://publib.boulder.ibm.com/infocenter/tivihelp/v13r1/index.jsp
9.1.1 Rembo Server boot process overview

Figure 9-1 on page 457 explains the Rembo Server boot process in detail.
456
DHCP and PXE boot scenario

IP address Workstation PXE boot 2a PXE boot info 1a
DHCP discovery broadcast
1b
TFTP bootstrap download
DHCP server Port 67 2b Rembo Boot server Port 67 Port 4011 Port 69 6 5 Rembo Hardware discovery Bootstrap request With DHCP proxy Boot discovery hw info 3
Figure 9-1 Rembo boot process chart
The Rembo uses PXE programming interface natively which provides better control. PXE stands for Pre-boot eXecution Environment. Here is the boot sequence when booting using the Rembo Boot Server. 1. a and b: A UPP discovery broadcast is performed when booting. 2. a and b: Information is sent back by the DHCP server and the Rembo. 3. Bootstrap request from the client. 4. Rembo Boot Server uploads the Rembo Kernel. 5. The boot server request some basic boot information through a Rembo hardware discover. 6. The client provides the hardware discovered.
9.1.2 Scenario used to perform image management

Although all tests were carried out with Tivoli Provisioning Manager V5.1 GA, it could have done with Tivoli Provisioning Manager for Software 5.1 as well.
Chapter 9. Image management
457
As seen on Figure 9-2, the Tivoli Provisioning Manager server is named Cairo. The machines to be captured or restored are named Lizbon, Dakar, Izmir and Toronto.
TPM 5.1 Rembo Boot Server
Imaging farm
Captured computer izmir
Captured computer lizbon Restored Image on Dakar Restored image on Toronto
Figure 9-2 Used scenario for image management
9.2 Ways to perform image management

In order to perform image management or pristine Installations, one must first understand what must be done manually to perform the initial installation of a workstation. The process can be fully automated by the Rembo Boot Server component of the Tivoli Provisioning Manager server.
9.2.1 Types of imaging

Tivoli Provisioning Manager with Tivoli Provisioning Manager for OS Deployment Embedded Edition supports the golden master image type. Golden master image is a depersonalized boot device image that is used for deployment on multiple computers. This image type uses configuration files to personalize the image for the target computers. Golden master images are generic images that can be installed on a different computer from the computer where the image was captured from.
458
9.2.2 Types of image restoration

There are three different ways to deploy an image which are supported by the Rembo Boot Server.
No cloning
Installing the OS and all the applications using Tivoli Provisioning Manager without any form of cloning.
Full cloning
Completes the installation by cloning images using multicast and using a universal profile. This is fastest way to install new machines that will have the same OS and the same set of applications.
9.3 Installing a Boot Server

In our tests we only installed a single boot server. However, multiple Rembo Boot Server can be installed as required and images can be synchronized between servers.
9.3.1 Getting ready to install the Boot Server

Before you install the Rembo Boot Server, it is important to specify the location to be used to store images by setting the DataDir variable. If your corporation does not have a specific directory to store images, it is recommended to use a simple structure like \CID\Machines\. Ideally, it should reside on a separate physical disk or at the very least on a separate partition. Plenty of storage space must be planned for in advance. It is preferable to calculate the amount of space anticipated and multiply by two. By default the main directories created for the Rembo Boot Server are: C:\Rembo Files\global To store configuration data C:\Rembo Files\shared To store images created by captures C:\Rembo Files\logs For logs tracking the Rembo Service C:\Rembo Files\temp For temporary files created by the boot server
459
The Rembo Boot Server component can be installed on a Windows Tivoli Provisioning Manager server, as was done during our tests. The DNS Server must be configured to accept dynamic DNS updates from the DHCP Server. If an MS-DNS Server is used, then it should be configured for WINS Lookup. If installing under the Windows 2000 Server O/S, Windows Script Host v5.6 must be installed as a pre-requisite. Windows Script Host v5.6 is included in Windows 2003.
9.3.2 Initiating the Boot Server installation

From the navigation menu of Tivoli Provisioning Manager V5.1 Web interface, select Inventory and expand the Infrastructure Management and click Boot Servers. The right Pane should show the list of installed Boot Servers, as in Figure 9-3. In our case, none are displayed as this is the first Boot Server to be installed.
Figure 9-3 Initiating the boot server installation
For the first time, it is recommended to use the wizard for the installation of the Rembo Boot Server.
460
9.3.3 Selecting the Boot Server type

The first panel of the wizard, shown in Figure 9-4, gives you a choice between 5 types of Boot Servers. In this case, we will select Rembo which is supported under Windows 2003, SLES9, RHEL3 and RHEL4. Because we are installing the Rembo Boot Server component on the Tivoli Provisioning Manager server, the operating system must be Windows 2003. Advanced Deployment Services (ADS) is a Microsoft product. Network Installation Manager (NIM) is an IBM product for AIX. Remote Deployment Manager (RDM) is an IBM product.
Figure 9-4 Choosing Rembo as a Boot Server type
9.3.4 Specifying the Boot Server name

In Figure 9-5, it is important to provide a good name for your server. You should select the operating system that your Boot Server is running. Once the selection is made, the Configuration Templates field will be updated with the right type of installation.
461
Figure 9-5 Specifying the Boot Server name
Important: The Rembo Boot Server requires a Static IP address.
9.3.5 Selecting targets

In Figure 9-6, select a discovered target. In this case both machines were identified by an SMB discovery.
462
Figure 9-6 Selecting targets
463
9.3.6 Configuring the administration

The license key requested in Figure 9-7 is located on the first distribution CD or DVD. It is called rembo.key
Figure 9-7 Configuring the administration
The license key does not expire and is valid for 5,000 seats. In our tests we had a problem due to the expiration of the SSL certificate. Please refer to Re-activating Rembo Server license key on page 494 for more information.
9.3.7 Scheduling now

Figure 9-8 shows the panel to schedule or run the Add Boot Server task.
464
Figure 9-8 Scheduling now the Add Boot Server task
9.3.8 Finishing the installation

Figure 9-9 shows the summary of the installation to be performed.
Figure 9-9 Summary of the installation to be performed
Clicking on Finish initiates the installation of the boot server.
465
9.3.9 Workflow execution log

You can track the job by double-clicking on the job ID. For clarity, the Debug level can be deselected. Also the different events can be sorted in descending order so that the most recent entries appear on top. It is recommended to perform manual refresh when required. The automatic screen updates makes it more difficult to track what is happening in real time because display updates can happen while you viewing results which can be annoying. It populates the DCM with Windows discovery information. Figure 9-10 shows the workflow execution for the Add Boot Server task.
9.3.10 Starting the Rembo Server

As shown in Figure 9-11, the status of the for OS Deployment Embedded Edition (Rembo Toolkit) is Not running. The status of the Tivoli Provisioning Manager for OS Deployment Embedded Edition must be changed to Running because this service drives the Rembo Server. The status can be changed by bringing-up the task icon properties and by choosing the Start option.
466
Figure 9-11 Starting the Rembo Server
By starting the Tivoli Provisioning Manager for OS Deployment Embedded Edition, it starts the following services: Rembo Server Rembo TCP to ODBC gateway Rembo Agent When stopping the Rembo Server service, it also stops the Rembo TCP to ODBC gateway service. Similarly, when you start the server service it also starts the gateway component.
9.3.11 Getting the right version of Sysprep

The Microsoft utility SysPrep has to be copied to the right windows directory before it can be used. Sysprep is different for all different platforms of Windows. This means that SysPrep for Windows 2000, 2003, XP and Vista are all different. Moreover, they usually differ from FixPack to FixPack. However, the version that comes with a specific FixPack is backward compatible i.e. meaning that it will work with previous versions of the same Windows platform. For example, if you have a version of Sysprep that came with FixPack 3 of Windows 2000, it means that it will work with FP0, FP1, FP2, FP3 but not with FP4. If you fail to get the
467
right version of SysPrep, you will get the following message when trying to capture an image: The procedure entry point pSetupIsUserAdmin could not be located in the DLL library. Files are copied to a Platform specific directory on the Boot Server. For example for Windows 2000, they would be copied to: \IBM\tivoli\TPM\repository\Rembo\win2k\ those files should be sysprep.exe and setupcl.exe.
9.4 Preparation required to capture an image

The following preparation steps are required to capture an image:
9.4.1 Ensure that the BIOS settings are properly set

Because the client must boot from the Rembo Boot Server, the BIOS settings must be checked in order to ensure that the client will first attempt to contact the Rembo Server and not boot from a local device like a hard disk or from a removable device like a CD-ROM. In addition, the following parameters of the BIOS of the reference machine to be captured must be set to: PXE should be enabled. Wake-on-Lan must be enabled. Automatic power management (APM) should be disabled. This is not to be confused with ACPI (Advanced Configuration and Power Interface), which should be enabled. Tip: Network boot and PXE should not be systematically associated. Network boot can happen from a non-PXE compliant interface. In most BIOS, you have to choose the start-up sequence and enable the PXE separately.
9.4.2 Obtaining an IP address from a DHCP server

If a static address is used on the machine to be captured, the IP Address must be changed to obtain an IP address from a DHCP server. If the machine is already configured to obtain an IP address from a DHCP server, then there is nothing to do for this step.
468
This step is necessary for the Rembo Boot Server to properly control the machine to be reinstalled.
9.4.3 Performing an SMB or SSH discovery

A Tivoli Provisioning Manager discovery task should be performed on the computer to be captured. This is essential. An SMB (Server Message Block ) discovery should be performed on Windows machines while an SSH discovery should be performed on Linux machines. Refer to the Chapter 4, Discovery mechanism on page 175 for more information.
9.4.4 Defining the operating system

Figure 9-12 shows how to define the operating system of the machine to be captured. In a multilingual environment, different languages can be supported. For example, an installation can be performed in a particular language as long as the base image was created.
Figure 9-12 Defining the Operating System and the language
9.4.5 Discovering the operating system attributes

The Windows Configuration Discovery must be run as in Figure 9-13 in order to discover the OS related attributes.
469
Figure 9-13 Windows Configuration Discovery
9.4.6 Discovering the local users

Figure 9-14 highlights the Windows Local Users Discovery.
470
Figure 9-14 Discovering Local Users
The user information is used by the Rembo Server to perform reboots of a live system and to finalize the installation after the final reboot.
471
9.4.7 Setting the administrator DCM password

Setting the DCM password, as shown in Figure 9-15, will allow the Rembo Boot Server to access the computer, to be captured, during the imaging process.
Figure 9-15 Updating the DCM password
9.4.8 Enable boot from Network Interface Card

Setting the DCM password, as shown in Figure 9-15 will allow the Rembo Boot Server to access the computer to be captured during the imaging process.
472
Figure 9-16 Selecting Network Enabled
It is important to note that Netboot Enabled is not selected by default. It must be selected for the right interface and for every machine to be captured or restored. If this parameter is not set you will get the error message shown in Figure 9-16 when trying to capture the image. There must be at least one NIC with Netboot Enabled.
9.5 Capturing the images

Once a computer is prepared to be captured, it is relatively simple to capture the image.
9.5.1 Selecting the computer to be captured

One way to select the machine is to go to Manage Inventory and select Computers. From that point, the name of the machine to be selected can be selected which will display the properties, as shown in Figure 9-17.
473
Figure 9-17 Selecting the machine to be captured
Before capturing an image, you must ensure that the file system is checked. Moreover, it is a good idea to delete temporary files and empty the recycling bin. This will decrease the size of the image to be captured.
9.5.2 Initiating the capture process

To initiate the capture process, from General tab, click Edit -> Capture Image as shown in Figure 9-18. This will start the 5 step Capture Wizard.
474
Figure 9-18 Initiating the Capture Process
9.5.3 Selecting the source computer and time-out

The first step in Figure 9-19 allows you to select the computer and specify the time-out. Ensure that the time-out is long enough for the capture process to complete.
475
Figure 9-19 Selecting the Source and time-out
9.5.4 Selecting the Boot Server

As you can see in Figure 9-20, multiple Rembo Boot Servers can be used. Usually you should pick the closest one to the target.
476
Figure 9-20 Selecting the Boot Server
A Golden_Master is a Rembo image depersonalized that can be used for restoration on multiple computers.
9.5.5 Describing the image

In Figure 9-21, it is recommended to set Post Execute Status to Reboot_System.
477
Figure 9-21 Providing image information
9.5.6 Schedule the image capture

Figure 9-22 shows how to schedule the image capture.
Figure 9-22 Schedule now the image to be captured
478
9.5.7 Performing the actual capture

Figure 9-23 shows the final panel for the Capture Image Wizard.
Figure 9-23 Performing the actual capture
Figure 9-23 shows the final panel for the Capture Image Wizard. The speed at which an image is captured depends on many factors. If the image of the operating system was previously captured in an existing image then the time to capture the new image will be much less. Besides the space taken by the new image should also be significantly smaller. Also the image creating depends on the speed of the hard drive and the speed of the CPU. This is important for compression and decompression on the fly. The Rembo Boot Server will create a series of files. One contains the bulk of the data and the other contains the table of contents. The naming convention is as follows: blk0001 & toc0001 blk0002 & toc0002 ...
9.5.8 Booting the Rembo kernel

After you start the capture task, the machine to be captured will be rebooted and will then start with the Rembo kernel as shown in Figure 9-24.
479
Figure 9-24 Rembo Kernel on the machine to be captured
The Rembo kernel is a dedicated operating system used to perform image management operations only. The computer to be captured boots from the network card using PXE and loads the Rembo kernel in memory and waits to execute imaging operations. This is the sequence of operations that take place during the capture: 1. Rembo Kernel is automatically or manually booted on the client machine. 2. The client is deregistered from Active Directory. Note: Machine to be cloned cannot be part of a domain. 3. The correct version of SysPrep is run on the client machine. 4. The client machine is rebooted remotely. 5. The client machine image is created. 6. The client will reboot, but this time not from Rembo.
480
Before actually capturing an image of a Windows machine, the Rembo Server runs SysPrep in order to remove the Security ID. This step will prepare the image so it will be clonable. The Rembo Boot Server has been designed to work with Microsoft SysPrep and completely automates the post-cloning reconfiguration. If the Rembo image is clonable then it will be listed as a Golden_Master image. Note: The computer to be captured is identified by the MAC address, the GUID, the model, the serial number, the fully qualified host name, the IP address of the machine to be captured, the IP address of the assigned Boot Server, and the IP address of the DHCP server.
9.6 Restoring the images

The process of restoring an image is the process of restoring already captured images. The restoration can be performed on a machine known or unknown by Rembo. Here are the steps for a typical restoration: 1. The client machine to be restored, is rebooted remotely if the OS is running. If powered off then Wake-on-LAN is used. 2. The machine to be restored boots from PXE and gets an IP address from a DHCP server. The Rembo Boot Server will detect DHCP packets sent over the network by PXE bootroms and will offer PXE parameters without disturbing standard DHCP negotiation process. This behavior is called DHCP Proxy. The machine loads the Rembo Kernel. 3. The client determines that it is starting a new deployment and queries the Tivoli Provisioning Manager server for relevant deployment configuration. 4. The client performs an hardware discovery through DMI and PCI system calls. The Tivoli Provisioning Manager server tries to match the machine to install with a specific serial number and UUID(GUID) and associates the match to a Fully Qualified Domain Name. If a match is found then it will proceed. 5. The client queries the Tivoli Provisioning Manager DCM database for all relevant information regarding the image to be restored and all the software packages to be installed. This process will generate a deployment script. 6. The client reboots the Rembo kernel and carries on the process of restoring an image. 7. The Rembo kernel will partition or format, or both, if required by the profile. 8. The Rembo kernel will download the image.
481
9. The Rembo kernel will run pre-installation tasks. 10.The Rembo kernel will download all the required files. 11.The Rembo kernel configures the O/S. 12.The Rembo kernel installs Software Products. The following sections will explain how to capture an image step by step.
9.6.1 Preparing the machine to be deployed

The same preparation that was done before capturing an image must also be performed on a machine to be restored. The BIOS of the machine to be restored must be set to: PXE Enabled. The Boot order should be changed to reflect that the first machine should be Network, then Removable drives and finally the right bootable hard disk. Wake-on-line Enabled. Automatic APM power management should be disabled. This is not to be confused with the O/S controlled ACPI which should be enabled.
9.6.2 Preparing a Rembo Hardware Discovery Task

The first step is to build a task that will perform a Discovery task. The Rembo Hardware Discovery Method must be selected from the drop down menu as shown in Figure 9-25. The Rembo Hardware Discovery can be performed on a x86 machines with or without an O/S. There is no need for security credential. This discovery will create a DCM drift record. The following information will be gathered: Host name obtained from the manufacturer serial # of the device. PCI network cards detected on the device. Details about CPU resources existing on the device. Details about memory slots as well as the RAMs in the slots. Details about hard disks found on the device including size. Details about the BIOS. Any removable device like DVD, CDR or floppy drive.
482
Figure 9-25 Creating a Rembo Hardware Discovery Task
9.6.3 Identifying the machine to be installed

In Figure 9-26, the serial number of the machine must be specified. Do not get it from the label but from the BIOS. Models that support reflashing of the BIOS usually allows for changing the serial number of the machine.
483
Figure 9-26 Entering the serial number and host name
If the wrong serial number is specified, then the Rembo Boot Server will deny service to this machine. It will treat it as a rogue machine and deny installation. Once the machine is authorized, then the MAC address and the GUID will be the main machine identifiers. The Rembo Discovery will also identify the type of hardware architecture of the machine.
9.6.4 Selecting the image to be installed

On the panel shown on Figure 9-27, the images available to be restored are listed. Select one and proceed with the installation. The task of Install Image will restore or in other words deploy the selected image on targets.
484
Figure 9-27 Selecting the image to be installed
9.6.5 Selecting the targets to be installed

On Figure 9-28 you select the image to be restored and the target. One easy way to select the target is to search the host name of the machine and then to select it. Before clicking Submit, you must click Advanced in order to customize the installation.
485
Figure 9-28 Select the targets to be installed
Multiple targets can be selected easily selected as a group.
9.6.6 Customizing the image restoration

Figure 9-29 shows information about the Windows 2000 Server template that will be used to install the operating system. Note: The restore will fail if image is not taken from similar machine.
486
Figure 9-29 Customizing the pristine installation
It allows to customize the image installation. Note that the items grayed out cannot be changed. Critical parameters like the Boot Partition RbOsRootPart and the ImageSize cannot be changed. However GraceTime, PostExecStatus and Drives can be changed. The bottom part of the screen capture will be shown on the next page.
9.6.7 Customizing the OS installation

Figure 9-30 displays more parameters that will be used to customize the installation of the OS itself.
487
Figure 9-30 Customizing the OS installation
Tip: The size of the partition to be created on the target machine must usually be changed. By default, it creates a partition that is the same size as the original captured image. In our case we had to increase the value from 4 GBytes to 25 GBytes.
9.6.8 Finalizing the installation

Figure 9-31 shows the workflow execution log for the installation.
488
Figure 9-31 Proceeding with the restoration
During the installation, the machine may be rebooted multiple times as required. Once you see that the workflow is successful it means that the machine was installed successfully and that the machine was rebooted.
9.7 Advanced topics

You will find in this section a description of the problems that we found during our tests.
9.7.1 Cannot delete a computer that has an image associated to it

It seems it is not possible to delete a computer that has a rembo image associated in DCM database. In our test we captured an image for a particular computer named lizbon. The image was ok and we were able to install it on another machine. Then we tried to delete lizbon from the computer list and it failed with the error: It was confirmed to us that there is a defect. There is nothing you can do unless you hack in the database and update the image association manually before you try to delete the server. It would be a SQL command like:
489
UPDATE DB2INST1.IMAGE SET "SOURCE_SERVER_ID"=NULL WHERE "IMAGE_ID"=2346 GO
9.7.2 Booting from the Boot Server

During our tests, we noticed that when booting a computer that is not registered in Rembo Server database and has PXE network boot enabled, it always boots the proprietary IBM/Rembo OS. This actually allows Rembo to discover unknown systems and store information about their MAC address and serial number as soon as they boot, but is probably acceptable only if working in a separate network where only new machines are booted. Tivoli Provisioning Manager provides a workflow to change this default behavior so that unknown computers will start on their hard disk instead of on the network. To run the workflow, navigate to Automation Workflows and search for the workflow called Rembo_Global_Settings. In the same row, click Run. Specify the object ID of the boot server and set the parameter BootFromHardDisk value to true. Schedule the workflow and click Run. This workflow will avoid undesired boot problems for unknown systems. As for known systems: If they have been installed with a Rembo image, they know they do not have to boot with the proprietary IBM/Rembo OS, unless you start a Rembo Hardware Discovery or you need to perform an Image operation like cature or restore. If they have not been installed yet, they will start with the Rembo OS and wait until a Rembo hardware discovery task is triggered. List of systems that are known to Rembo is available in the Rembo Console at: http://rembo.server.name:8088. Default User ID is admin and password provided during Rembo Server installation. Figure 9-32 shows the Rembo Console.
490
Figure 9-32 Rembo Server Console
If you want to prevent a system that is known to Rembo and has network boot enabled to start with the Rembo OS, you can execute one of the following three actions: Run workflow Rembo_Reset_ClientTask providing the following data: BootServerID Data Model ID of the Rembo bootserver ClientDeviceMac The hardware address of the client's NIC used for PXE booting PostExecStatus that can be one of: hdboot Reset Rembo client task to boot on hard disk, and set PXE client to boot from hard disk. reboot Reset Rembo client task to reboot, and set PXE client to boot from hard disk. poweroff Reset Rembo client task to power off, and set PXE client to boot from network.
491
These are all modifications in Rembo server PXE configuration, and do not change anything in client BIOS settings. There is no need to be concerned about changing these back at the next client PXE operation, as Tivoli Provisioning Manager will configure the client task accordingly. Log on Rembo Server Console, which is shown in Figure 9-32, and delete the respective clients from Rembo list of clients under the Default folder. Log on Rembo Server Console, which is shown in Figure 9-32, using the navigation click on Host lists Administrative Groups Default. Then edit the client configuration to boot from the hard disk.
Managing known and unknown systems

The following summarizes the possible scenarios when managing known and unknown systems in a Rembo environment, depending on the network where the Rembo server is located, relative to the network where the client sits. Rembo server in the same subnet as the client: Unknown clients, with or without an existing installed OS: Conditions: Rembo PXE server running DHCP server available to offer leases for these clients Client not present in Rembo Default group of hosts Operator reboots or powers-on the client. Any unknown client will boot from the next available device in BIOS boot order. For instance, if client BIOS boot order is network/CD/HDD, the client will try to boot from CD. For image restoration, you first start a Tivoli Provisioning Manager Rembo Hardware Discovery execution, and then power-on the client. That will make the bare-metal run the discovery, and then wait in Rembo client VM until an image install task is triggered.
Behavior:
Known clients: Conditions: Rembo PXE server running DHCP server available to offer leases for these clients Client are registered in Rembo Default group of hosts Operator submits an image operation on the client.
Behavior:
492
If the target has an OS, or there are remote control configurations that will allow a hardware reboot, Tivoli Provisioning Manager will succeed in rebooting the client, otherwise operator has to reboot the client. If the target is powered-off, and the MAC address of the PXE NIC is known by Tivoli Provisioning Manager, then Rembo will do a WOL. You must have the client configured to work with WOL. Client boots in Rembo, executing the image restoration. For image restoration, first start a Tivoli Provisioning Manager Rembo Hardware Discovery execution, and then power-on the client. That will make the image restore run the discovery, and then wait in Rembo client VM until the image install task is triggered.
For both unknown clients and known clients, the client is supposed to end-up in boot from hard disk state. Even in case of errors, Tivoli Provisioning Manager resets the client state to boot from hard disk before raising an exception. There are situations when Tivoli Provisioning Manager cannot contact the Rembo server to reset the state. These are most frequent with Rembo on Windows, because of known problems in RXA implementation. This is when operator would eventually have to run Rembo_Reset_Client by hand. Rembo server in a different subnet Both known and unknown clients will behave same as above. The difference this time is you will have to configure the network to forward the PXE (and maybe relay DHCP) packets over the routers.
9.7.3 When trying to restore an image twice on the same computer

When trying to restore an image that was previously restored, sometimes we get Example 9-1.
Example 9-1 Message we get when trying to restore an image twice
The system cannot evaluate a Jython expression. Tracebck (innermost last): File <string>, line 1, in ? NameError: SourceDeviceName In this case the MAC address discovered is all zeroes. If it Happens, just replace it for the NIC using the Rembo Console.
493
9.7.4 Re-activating Rembo Server license key

After stopping our Rembo Server for a few days, we found the service was not able to start, reporting error code 43. In Windows Event Viewer we found the error shown in Figure 9-33.
Figure 9-33 Event Viewer error for expired license key
After running command C:\Program Files\Common Files\ Rembo Technology\rembo -d -activate, we were provided a long alpha-numeric output to use on the web site shown in Figure 9-34 to generate an activation token.
494
Figure 9-34 URL to generate activation token
Figure 9-35 shows the resulting activation code with the instructions to use it.
Figure 9-35 Generation of an activation token
495
After importing the activation token, we were able to restart our Rembo Server successfully.
496
10
Chapter 10.
Reporting and notification

This chapter gives an overview of the pre-defined reports and show the readers how to run predefined reports, manipulate existing reports, create new reports and share report definitions with others. We also cover how to generate notifications. The chapter has the following sections: Reports on page 498 Reporting actions on page 499 Creating reports on page 500 Managing reports on page 508 Predefined reports examples on page 516 Notification on page 521
497
10.1 Reports
Reports are used to retrieve current information about data center inventory, activity, and system compliance. Tivoli Provisioning Manager V5.1 provides the following main categories of reports: Audit Audit reports show changes (adding and removing) that are made to hardware and software, and show who is responsible for the changes. Audit reports also show changes to infrastructure, such as adding and removing systems from groups, application tiers, and resource pools and show who is responsible for the changes Inventory Inventory reports show current information about data center inventory; inventory of available software, currently installed software, and hardware activity. Data is extracted directly from the Tivoli Provisioning Manager data center model database. Compliance Compliance reports show systems that are identified as vulnerable, systems that are in compliance, and systems out of compliance because of failed compliance criteria. Deployment Deployment reports show successful and failed deployments of software and the status of deployments which include deployments in progress, not yet started, successful, failed, and submitted. These reports also include successful and attempted operating system deployments that are part of image management. Discovery Discovery reports show the last discovery scan results by endpoint and discovery scan type. Other Other reports are any reports that cannot be organized into the other report categories. The types of reports in this category range from recent workflow activity, notification subscribers and events, task status, and user access permissions. Report views Tivoli Provisioning Manager provides predefined database views. The views are directly associated to the fields that are available for the report.
498
For each of these categories, a number of predefined reports are available, enabling you to review and analyze activity in your data center. You can use these reports to identify patterns, diagnose problems, optimize and plan resource allocation, and forecast future activity. All reports and report results can be saved using the import and export functions so that you can re-execute a report or refer to past results at any time. The output formats can be: HTML PDF CSV (Comma Separated Value) XML The reports can also be scheduled to run at a specific time, or repetitively. Scheduling uses Tivoli Provisioning Manager task scheduling mechanism and report is actually executed from a workflow.
10.2 Reporting actions

Reports in Tivoli Provisioning Manager can be easily created or customized to suit your business requirements. You can execute the following actions against them: Creating new reports The Tivoli Provisioning Manager predefined reports allow you to provide most of the general data that you require. You may also want to create specific reports based on your business requirements. Using the report wizard you can create your own report and then either save the report in the report category so you can run it again, or discard the report. The report wizard will walk you through the steps to create a new report, choosing the views, fields and configuring the report layout. Editing reports Each report category lists the predefined or user defined reports that have been saved. You can choose any of these reports and edit the report using the report wizard. If you save your changes, the existing report will be updated with your changes. Copying reports You can copy an existing report, instead of editing it, so that Tivoli Provisioning Manager will clone the report with a new file name. This will
Chapter 10. Reporting and notification
499
allow you to make changes when you require the original report to remain the same. Running reports In each report category there are a list of saved reports. You can run or schedule these reports to run at any time. In the following sections we describe some of these actions.
10.3 Creating reports

Tivoli Provisioning Manager provides a number of predefined reports for each report category. If the data that you require cannot be retrieved from the existing reports, you can create your own. Your access might be limited to certain report types depending on your user role and on the permissions that you are assigned to by your administrator. The wizard for the report creation enables you to perform the following main operations: Select the category of report that you want to create. Select the views and fields that you want to include in the report. Customize the report results by adding constraints and ordering and grouping the selected fields. Schedule the report to run immediately, at a later date, or at a scheduled interval. Select the output format that you want to save your report in. The report wizard structure is identical in all report categories. To create a new report using the wizard, follow these steps: 1. In the navigation pane, expand Reports. 2. Click the report category that you are interested in. If the report that you want to create does not belong in any of the defined categories, select the Other report category. 3. Click Edit Add a Report. The Report Description page of the wizard is displayed. 4. Tivoli Provisioning Manager automatically generates a report name for each new report. It is recommended that you change the provided name to something more meaningful to the report that you are creating as shown in Figure 10-1 on page 501. On this page you can also provide a description for
500
your new report. Adding a description will help to differentiate the report from similar reports in the report list. The report type will be selected based on the report category that you are in. Specify the access group that will have permission to view this report.
Figure 10-1 Create Report - Report Description page
5. Click Next. The Report Constraints page is displayed. 6. Use the Report Constraints page to select the views and fields that you want included in your report results. The available fields are determined by the views that you select. You can add operators to the report fields to constrain the results of your report. Figure 10-2 on page 502 shown an example.
501
Figure 10-2 Create Report - Report Constraints page
7. Click Next. The Report Layout page is displayed. On the layout page you can select how you want your report structured based on the fields that you have already selected. Specify how you want those fields ordered and grouped when you see the final report results. Select the report output style from the available options. You can also chose a field to drill down on data center model objects in your report. Selecting a field will give you the option of linking to the object information page from the report results. Figure 10-3 on page 503 shows an example:
502
Figure 10-3 Create Report - Report Layout page
8. Click Next. The Report Summary page is displayed. 9. Review the summary of your selections for the report. If you have the required edit permissions you can manually edit the SQL statements. Verify any changes that you have made. Specify when you want the report to run or if you want to save it and run it at a later date. You can select to be notified by e-mail when the report task successfully completes. 10.Click Finish to generate the report. Figure 10-4 on page 504 shows a sample output of the report generated.
503
Figure 10-4 Report output example
You have successfully created a new report, and the report is now saved in the report category list.
10.3.1 Adding report prompts

When you are creating or editing a report, you can add a promptable parameter. This means that every time a report is run, the user will be prompted to select a value before running the report. This feature enables the user to customize the report results based on the parameter that they choose. To add a promptable parameter to a report follow these steps: 1. In the navigation pane, expand Reports. 2. Expand the report category that you want to work with and choose one of the following options:
504
a. Select the existing report that interests you. In the report row, click on the context icon and select Edit. b. Create a new report. Click Edit Add a Report. 3. Follow the instruction on the first page of the reports wizard. 4. On the Report Constraints page, select or verify the views for the report. 5. Select the Available Field that you want to use as the parameter. For example, for a report on task status: all view, selecting the field task status: main task status:all will prompt the user to select a task status of failed or succeeded before the report is run. 6. Select an Operator and type ? in the Value field. Press the AND button or the OR button. The ? is the value that triggers the prompt for a parameter when the report is run. 7. Follow the instructions to get through the rest of the wizard page. Save the report without running it and return to the main report page. 8. Beside the report that you have just created or edited, click on the context icon and select Run. The report parameter page will open and you will be prompted to select a value. Select a value and click Run Now. Note: Choosing a value is optional. You can click Run Now without selecting any values to see all the results possible for that report. The Select All button will also return all the possible results for that report. 9. The report will run and you will see the results for the value that you selected. You have finished adding a promptable parameter for your report. Now, any time that report is run the user will be prompted to select a value that will customize their results.
10.3.2 Creating a group

Reports can be used to create dynamic groups. Tivoli Provisioning Manager provides a number of predefined reports for each report category. You can use these reports to create a dynamic group or you can create your own report to use. A dynamic group can only be created if the report contains an ID for a data center object and that field is selected in the Drill Down Field. For example, a report containing the field patch: ID with that field selected will successfully create a dynamic group of patches. Your access might be limited to certain report types depending on your user role and on the access permission group that you are assigned to by your administrator.
505
Build a new report to use for creating a dynamic group

The wizard enables you to perform the following main operations: Select the category of report that you want to create. Select the views and fields that you want to include in the report. Customize the report by adding constraints. Save the report so you can select the report when you are creating a dynamic group. The report wizard structure is identical in all report categories. To create a new report using the wizard, follow these steps: 1. In the navigation pane, expand Reports. 2. Click the report category that you are interested in. If the report you want to create does not belong in any of the defined categories, select the Other report category. 3. Click Edit Add a Report. The Report Description page of the wizard is displayed. 4. Tivoli Provisioning Manager automatically generates a report name for each new report. It is recommended that you change the provided report name to something more meaningful to the report that you are creating for your group. On this page you can also provide a description for your new report. Adding a description will help to differentiate the report from similar reports in the report list. The report type will be selected based on the report category that you are in. Specify the access group that will have permission to view this report. 5. Click Next. The Report Constraints page is displayed. 6. Use the Report Constraints page to select the views and fields that you want included in your report. The available fields are determined by the views that you select. You can add operators to the report fields to constrain the results of your report. 7. Click Next. The Report Layout page is displayed. 8. If this report is only being used to create a dynamic group, you can omit the grouping and order specifications. In the Drill Down Field, you must select a data center object ID field for the dynamic group to be created successfully. For example, selecting the field base_computer: computer ID will create a dynamic group of computers. 9. Click Next. The Report Summary page is displayed. 10.Review the summary of your selections for the report. If you have the required edit permissions you can manually edit the SQL statements. Verify any changes that you have made and select Save without running.
506
11.Click Finish. You have successfully created a new report and the report is now saved in the category report list. Now, when you want to create a new dynamic group, this report can be selected for your group.
Copying reports
All of the report definitions saved in the report categories can be copied, according to your needs. Copying a report creates an identical report but assigns it a unique name. This allows you to clone an existing report so you can edit the report to suit your new requirements, without overwriting the original report. To copy a report follow these steps: 1. In the navigation pane, expand Reports. 2. Expand the report category that you want to work with, and then click the name of the report that interests you. 3. Next to the report that you want to edit, click Copy. The corresponding wizard is displayed, showing the new unique report name and all the previous selections for that report. 4. On each wizard page, review the existing selections and make all necessary changes. 5. On the Report Summary page, click Finish. You now have a new copy of the original report.
Running a report
Each of the report categories contain lists of existing reports. Run any of the existing reports that you have access to for that particular report type. You can run any of those reports, at any time, to get immediate report results. To run a report follow these steps: 1. In the navigation pane, expand Reports. 2. Click the report category that interests you, the available reports are listed on the category page. 3. In the same row as the report that you want to run, click on the context icon and select Run. 4. Some reports are designed to give you the option of selecting specific values, or parameters. The parameters page enables you to select one or more values. For example, if you run report Other009 you can select to see results only for tasks that have failed. If you select All values, the report will show
507
you all possible results; you will see all tasks that have failed, succeeded, and that are still running. 5. The report results page will open and display the rendered data. The report will be displayed according to the report layout specified when the report was created. 6. Save or print the report results. There are several options: Select Save Result to save the results to the report Archive. Select Export PDF to save the results to a portable document file (PDF). Select Export XML to save the results to an extensible markup language (XML) file. Select Export CSV to save the results in a comma separated value (CSV) format in a Microsoft Excel file. Select Print to print the results in a printer-friendly format. The report results are organized neatly on the page for optimal printing.
Note: If elements in your report results use double-byte characters, the characters may not be displayed properly with the HTML output format or when you select the Print option from the results page. For example, if you have a computer name that was created with double-byte characters, the computer name may display as a ? in the results table. To avoid this problem, install Tivoli Provisioning Manager on a double-byte locale server, or display the results in an output format other than HTML or HTML with Graph.
You have finished running the report.
10.4 Managing reports

The following actions can be performed against reports:
10.4.1 Editing reports

All of the existing reports that you have access to can be edited, according to your needs. All of the reports that you have created, whether personal or public, as well as all of the public reports that are owned by other users can be edited. However, once edited, reports will be overwritten with your changes. To edit a report definition follow these steps:
508
1. In the navigation pane, expand Reports. 2. Expand the report category that you want to work with. 3. Next to the report that you want to edit, click on the context icon and select Edit. The corresponding wizard is displayed, showing all the previous selections for that report. 4. On each wizard page, review the existing selections and make all necessary changes. 5. On the Summary page, choose to schedule, save, or run the report. You have finished editing the current report. If you chose to run the report now you will see the report results immediately.
10.4.2 Displaying reports

When you run a report in Tivoli Provisioning Manager the results are displayed according to the specifications in the report. Each report is created in the report wizard. If you want to change the way the results are displayed, you can edit the report in the wizard and change the output style on the layout page of the wizard. Report results can be displayed in the output styles: HTML PDF XML CSV Printing
Changing the output style of the report results

If you want to change the way the results are displayed, you can edit the layout page in the report wizard. 1. In the navigation pane, expand Reports. 2. Expand the report category. All of the available reports are listed on the category page. 3. In the same row as the report that you want to edit, click on the context icon and select Edit. The corresponding wizard is displayed, showing all the previous selections for that report. 4. On each wizard page, review the existing selections and make all necessary changes.
509
5. On the Report Layout page, select the fields and specify how you want the fields to be ordered and grouped in the results. Select the output method for your report results. The default is set so that the results are displayed in HTML format. You can select one of the following choices: DHTML, DHTML with Graph, HTML, HTML with Graph, PDF, CSV, or XML format. Your choices will vary depending on your Tivoli Provisioning Manager environment. 6. On the Report Summary page, verify your selections and schedule the report to run or save the changes without running the report. The changes that you have made on the layout page will determine how the report results will be displayed the next time you run the report.
HTML
HTML is the default output format for all of the predefined reports. When the report runs, the output will be displayed in HTML using a report table to organize the results. If your Tivoli Provisioning Manager environment includes WebSphere Application Server and DB2 Universal Database, DB2 Alphablox has the capability to render dynamic and interactive results.
Results page display for output in HTML

The following elements can be displayed on the results page when you select any of HTML, HTML with Graph, DHTML, and DHTML with Graph:
Tables
Every report that renders results displays a table. Each column that you see has been specified by the views selected in the report or the values that you have selected on the parameters page. If your Tivoli Provisioning Manager environment includes WebSphere Application Server and DB2 Universal Database, the table will be dynamic. The DB2 Alphablox software renders interactive tables that give you the option to right-click on columns to change the style, move, sort, and hide the columns. Note: If elements in your report results use double-byte characters, the characters may not be displayed properly with the HTML output format or when you select the Print option from the results page. For example, if you have a computer name that was created with double-byte characters, the computer name may display as a ? in the results table. To avoid this problem, install Tivoli Provisioning Manager on a double-byte locale server, or display the results in an output format other than HTML or HTML with Graph.
510
Graphs
Graphs are available if your Tivoli Provisioning Manager environment includes WebSphere Application Server and DB2 Universal Database. Graphs will be displayed if the reports contain numeric values. Note: If the report results are too large, the graph feature will not be enabled. Tivoli Provisioning Manager will determine the graph capabilities automatically. If a graph does not show up in the results then the report was not suitable for a graph to be created. If your report renders a graph, the following edit options are available by right-clicking on the graph: Formatting graph color, font size and style. Customizing legends, labels, titles, and footnotes. Changing the graph types and moving the axis.
Changing graph types

After you run a report, you may decide that the results would be more appropriately displayed in a different graph type. You can change the graph type to better suit the results. To change the graph type follow these steps: 1. Navigate to Reports and select a category that interests you. For example, select the Inventory category. 2. Run a report. For this example, run the report called Inventory011. 3. On the results page, right-click on the graph and select Chart Types. 4. On the Chart Type tab, select the Pie chart type from the list. 5. On the Axes Placement tab, make the following selections: a. Select Sum matching relational rows. b. Click OS_NAME and then click Legend. c. Click OS_VERSION and then click X-Axis. d. Click COMPUTER_COUNT and then click Y-Axis. e. Click Apply and then click OK to save your changes. The original bar graph has now been changed to a pie graph. For help with the interactive graphs, refer the ChartBlox section in the DB2 Alphablox information center:
511
http://publib.boulder.ibm.com/infocenter/ablxhelp/v8r4m0/index.jsp
PDF
PDF, or Portable Document Format, is an Adobe Acrobat file type. When you select PDF as the output format, the report results will be exported to a file which you can open to view, or save immediately. The report results is created with a filename containing the date and time. This helps to differentiate the reports if you run the same report periodically. You can customize the PDF output style by adding a custom logo to the file. For more information, see Adding a custom logo.
XML
If you choose to save the report output in XML, Extensible Markup Language, the report results will be exported to an XML file which you can open to view, or save immediately. The report results will be time-stamped to differentiate these results from other results that may be run from the same report.
CSV
The CSV, or Comma Separated Value, file type is generally used to exchange data between different applications. When you select CSV as the output format, the report results will be exported to a Microsoft Excel file which you can open to view, or save immediately. The report results will be time-stamped to differentiate these results from other results that may be run from the same report.
10.4.3 Importing and exporting reports

Tivoli Provisioning Manager provides the features to import and export report definitions. You can import and export single or multiple files. Importing and exporting reports allows you to: Move reports from one installation of Tivoli Provisioning Manager to another. Share reports with other Tivoli Provisioning Manager users. Backup the reports by saving them to an alternate source.
Exporting reports
To export a report or an entire report category follow these steps: 1. In the navigation pane, expand Reports. 2. Expand the report category that you want to work with. 3. Choose one of the following export operations:
512
To export the report category, click Edit Export. To export a single report , in the same row as the report, click Export. a. Click Save and specify a name and location for the file. The file is saved in XML format. You have successfully exported the report to another location.
Importing reports
To import a report follow these steps: 1. In the navigation pane, expand Reports. 2. Select any report category and click Edit Import. Note: The report that you import will be saved in the report category that it was created in. For example, if you import a deployment report from the Compliance report category , the deployment report will be automatically saved to the Deployment report category. If you do not have the appropriate permissions to view the deployment reports, you will not see the report that you just imported. 3. Browse for the file that you want to import and then click OK. 4. The report is saved to the appropriate report category. The file that you imported has been saved to the appropriate report category list.
10.4.4 Viewing report history

The report archive stores saved report results so that you can view them at a later date. You may want to save report results so that you can compare them with new results or to have a record of the results for a given date. Any time you run a report you have the option to save the report results to the archive. To view saved report results follow these steps: 1. In the navigation pane, expand Reports. 2. Click the report category that you are interested in and then find the report name that you want to view the past report results for. 3. In the same row as the report, click Archives. The Report Archives page is displayed. 4. Select the report instance that you want to see and click View Output. The results for that report will be displayed.
513
If you review the results and decide that they are no longer required, you can remove them from the archive by clicking Discard.
10.4.5 Saving and printing report results

Anytime you run a report, you can save the results that the report generates. There are several formats that you can choose to save the report results in so that you can view them at a later date. You may want to save report results so that you can compare them with new results or to have a record of the results for a given date. Tivoli Provisioning Manager also provides a print option from the report results page that automatically formats the results on a print-friendly page. Report results can be saved in the following methods from the report output page: Save Results: The report results will be saved to the report Archives. Note: If your report results are longer than 3000 - 4000 rows you may be unable to save them to the reports archive because it exceeds the maximum report size. The range in row size depends on the amount of data in each row. Save the file in either PDF or XML format. If you try to save a report that exceeds the maximum size it will cause a SQL exception error. Export PDF: Save the results to a portable document file (PDF). Export XML: Save the results to an extensible markup language (XML) file. Export CVS: Save the results in a comma separated value (CSV) format in a Microsoft Excel file. When you export a report, the file is saved with a filename containing the date and time. This helps to differentiate the reports if you run the same report periodically. To save a report follow these steps: 1. In the navigation pane, expand Reports. 2. Expand the report category that you want to work with. 3. Beside the name of the report that interests you, click on the context icon and select Run. 4. The report results are displayed. Select the method that you want to save the report in. You have run a report and saved the results.
514
Printing results
After you run your report, you can print the results immediately from the results page. The predefined reports are created to display the results on the results page in an HTML format. Click Print to preview the printer-friendly page. The report results are organized neatly on the page for optimal printing. If you run a report that has a PDF, XML, or CSV output style selected, you can print the results directly from those files also. Note: If the report type is non-interactive and double-byte characters have been used, the double-byte characters may display as a ? on the printed page. For example, if a computer name uses double-byte characters and the computer name appears in the results, the name will display as a ?. If you experience this problem, export the results to an XML or a CVS file and print that version instead of printing directly from the results page. You can also install Tivoli Provisioning Manager on a double-byte locale server to avoid this problem.
Adding a custom logo

You can add a custom logo to your report results if you save your report results to a PDF file. Adding a custom logo to your report results will personalize the page. The default for the logo is empty so if you choose not to add a logo, no logo will appear on the page. To add a custom logo to your PDF report results files follow these steps: 1. Open the report.xml file in the following file path %TIO_HOME%/config/. 2. Look for the following text in the report.xml file:
Example 10-1 Text in the report.xml file
<customLogo>  <location></location>  <pdfLocation></pdfLocation>
515
</customLogo> 3. Following the sample, insert the logo file name and file path into the location tags for PDF file. The file path has to be accessible, either in URL format or a relative path to your application. 4. Save the changes to the report.xml file. 5. Restart your Tivoli Provisioning Manager server for the changes to update. You have added a custom logo to your PDF report results files. Now, when you create these files you will see your logo.
10.5 Predefined reports examples

In this section we show some screenshot of the predefined reports execution.
10.5.1 Audit004 Who was notified about what event?

Figure 10-5 on page 516 shows a sample output of the Audit004 report execution.
Figure 10-5 Audit004 Who was notified about what event?
516
10.5.2 Inventory004 What patches are in the data center?

Figure 10-6 on page 517 shows a sample output of the Inventory004 report execution.
Figure 10-6 Inventory004 What patches are in the data center?
10.5.3 Compliance003 Do computers comply with their patch compliance checks?

Figure 10-7 on page 518 shows a sample output of the Compliance003 report execution.
517
Figure 10-7 Compliance003 Do computers comply with their patch compliance checks?
10.5.4 Deployment007 What patch deployment ran on which computers?

Figure 10-8 on page 519 shows a sample output of the Deployment007 report execution.
518
Figure 10-8 Deployment007 What patch deployment ran on which computers?
Discovery002 What objects were discovered by which discovery configuration? This report accept some input parameters. For the example described we selected Computers and Computers Group as shown in Figure 10-9 on page 520.
519
Figure 10-9 Discovery002 Input Parameter List
Figure 10-10 on page 521 shows a sample output of the Discovery002 report execution.
520
Figure 10-10 Discovery002 What objects were discovered by which discovery configuration?
10.6 Notification
Tivoli Provisioning Manager allows you to be notified for the following tasks: Software management Discovery Reports Favorite tasks Compliance checks Before you can select a user to notify, you must create that user in Tivoli Provisioning Manager. If a user does not exist, or you do not want to create one, you can select to simply add an e-mail address.
521
If you create a user, Tivoli Provisioning Manager will check for the e-mail address each time the notification is to be sent. One advantage of specifying a user is that when the e-mail address for the user is set or changed, the change is automatically applied to all notification subscriptions for that user.
Associating an e-mail address with the default user

During the Tivoli Provisioning Manager for Software installation, a default user tioappadmin is created with a default password tioappadmin. In order to test the SMTP server information, you must have an e-mail address associated with the tioappadmin ID. To associate an e-mail address with the default user follow these steps: 1. Log on to Tivoli Provisioning Manager for Software using tioappadmin as your User ID. The default password is tioappadmin. 2. Click Systems Management Manage Users. 3. In the tioappadmin row, click on the context icon and select Properties. 4. Specify an E-mail Address, Given Name, and Family Name. 5. Click Save. You have now associated an e-mail with the tioappadmin user. When you set up notification and test it, an e-mail will be sent to this address.
Setting up the notification mail server settings

You can select to notify users by e-mail when a specified task fails. You must supply the notification mail server settings. To set up notification follow these steps: 1. If you are not already logged on, log on to Tivoli Provisioning Manager for Software Web User Interface using tioappadmin as your User ID. The default password is tioappadmin. 2. Click System Management Global Settings. 3. Click the Notification tab. 4. In the SMTP row, click on the context icon and select Properties. 5. Enter the SMTP configuration information: SMTP Server Name: Type the address of the mail server. This server must already exist. SMTP Server Port: Type the mail server port number. User ID logon SMTP Server: Type the user ID logon if your SMTP server requires authentication.
522
User Password: Type the password used to authenticate to the mail server if the SMTP server requires authentication. 6. Click Test to ensure the connection works. You have now set up the SMTP mail server for notification to work. Check the e-mail address you specified in the Associating an e-mail address with the default user topic. A test e-mail will be sent to it.
10.6.1 Adding notification to software management tasks

You can select to be notified when you are installing, uninstalling, distributing, publishing, and unpublishing software. To create a notification subscription follow these steps: 1. In the navigation pane, click Software Management and then click on the desired task. For example, Install. 2. Select the type of software that you want to install. We will select Images to use as an example. 3. On the Install Images page, make the required selections. 4. In the Notification section select any one of the following situations: Notify me when this task begins Notify me when this task completes successfully Notify me when there are errors on % or more of the targets or more of the targets
5. To add other users to the notification event, click More Options, beside the notification section. 6. Add existing Tivoli Provisioning Manager users or you can add people by typing in their e-mail address. Select the Event Type that you want that user to be notified about. Click Save. The notification event has been selected so that when the task runs, the users will be notified if the selected situation occurs.
10.6.2 Adding user notification for discovery

You can select to be notified when you are running a discovery configuration. To create a notification subscription follow these steps:
523
1. In the navigation pane, click Inventory Manage Discovery Discovery Configuration. 2. In the same row as the discovery configuration that you want to run, click on the context icon and select Run. 3. On the Discovery Configuration page, make the required selections. 4. In the Notification section select any one of the following situations: Notify me when this task begins Notify me when this task completes successfully Notify me when there are errors on % or more of the targets or more of the targets
5. To add other users to the notification event, click More Options, beside the notification section. 6. Add existing Tivoli Provisioning Manager users or you can add people by typing in their e-mail address. Select the Event Type that you want that user to be notified about. Click Save. The notification event has been selected so that when the discovery configuration runs, the users will be notified if the selected situation occurs.
10.6.3 Adding user notification for reports

You can select to be notified when a scheduled report runs successfully. To create a notification subscription follow these steps: 1. In the navigation pane, expand Reports and click on a report category. 2. On the report category page, find the report that interests you. In the same row as the report, click on the context icon and select Edit. 3. The report wizard will open and you can review the existing selections. On the Summary page, select Notify me when this task completes successfully. 4. To add other users to the notification event, click Advanced 5. Add existing Tivoli Provisioning Manager users or you can add people by typing in their e-mail address. The notification event has been selected so that the users will be notified when the report runs successfully.
524
10.6.4 Adding user notification for favorite tasks

You can select to be notified when you run favorite tasks. To create a notification subscription follow these steps: 1. In the navigation pane, click Task Management Favorite Tasks. 2. In the same row as the task that you want to run, click on the context icon and select Run. 3. The task wizard opens. Follow the instructions until you get to the Report Summary page. 4. In the Notification section select any one of the following situations: Notify me when this task begins Notify me when this task completes successfully Notify me when there are errors on % or more of the targets or more of the targets
5. To add other users to the notification event, click More Options, beside the notification section. 6. Add existing Tivoli Provisioning Manager users or you can add people by typing in their e-mail address. Select the Event Type that you want that user to be notified about. Click Save. The notification event has been selected so that when the task runs, the users will be notified if the selected situation occurs.
10.6.5 Adding user notification for compliance checks

You can select a user to notify or e-mail address to notify individuals once your compliance check has been run. Note: Notification will only be sent if one or more compliance checks fail.
User notification
To add a user notification for compliance check follow these steps: 1. Search for the computer or group you want to work with and select it from your search results. 2. Click the Compliance tab.
525
3. Click Edit Add User Notification. The Add User Notification dialog opens. 4. Select the user you want to notify. 5. Click Save. The user will be listed in the Notification section of the Compliance page. To remove a user notification, select its check box in Notification section and click Remove.
e-mail notification
To add an e-mail address for compliance notifications follow these steps: 1. Search for the computer or group you want to work with and select it from your search results. 2. Click the Compliance tab. 3. Click Edit Add E-mail Notification. The Add e-mail Notification dialog opens. 4. Enter the e-mail address you want to notify. 5. Click Save. The e-mail will now be listed in the Notification section of the Compliance page. To remove an e-mail address for compliance notifications, select its check box in Notification section and click Remove.
526
11
Chapter 11.
User security
In this chapter we describe the concepts and artifacts available in Tivoli Provisioning Manager to protect access to operations and resources. We explain the security model from an operator perspective and describe the needed steps in a case study. Note: FastStart configurations are limited in function in regard to user security. An Enterprise installation is needed to enable all security features available in Tivoli Provisioning Manager. This chapter has the following sections: User security concepts on page 528 A case study on page 532
527
11.1 User security concepts

We distinguish two security aspects: user authentication, who are you and are you really who you say you are. user authorization, what are you allowed to do in the environment.
11.1.1 User authentication

Authentication is needed for all users that access the Tivoli Provisioning Manager server. Users and passwords are stored in the LDAP server. The encryption of the passwords is governed by the LDAP registry. Select System Management Manage Users to create and delete users, reset passwords of existing users and maintain properties of users such as e-mail address or telephone numbers. A user can be given superuser property. A superuser is not restricted by access group permissions and thus has full control over all devices and actions in the DCM.
11.1.2 User authorization

User authorization is based on the combination of user roles, access groups and permissions groups.
User roles
Tivoli Provisioning Manager uses role-based security. User roles are primarily used to control what a user can access in the user interface. User roles are stored in the LDAP registry. A user can have multiple roles. Only a user with the correct set of role can logon and view the pages in the user interface. A role is defined as a set of basic permissions. Tivoli Provisioning Manager comes with a number of predefined user roles as shown in Figure 11-1 on page 529.
528
Figure 11-1 Pre-defined security user roles
New user roles can be defined. Select System Management Manage Security Security Roles Edit Add Role to define a new role and to assign the wanted permissions. The user interface will only present the given permissions to users having this role. Users are assigned one or more user roles from the User Details page by selecting System Management Manage Users, select a user and from the User Details page, select Edit Configure Roles and move the required roles from the left list to the right. User roles can also be removed from this window, by moving roles from right to left.
Access groups
Access groups are a way of logically grouping access to any object. An access group contains the instances of DCM objects to be protected. An access group can be nested.
Chapter 11. User security
529
You create an access group by selecting System Management Manage Security Access Groups Edit Add Access Group. Enter the name and description. Select a parent group if you want to inherit from a another access group. To protect a DCM object or collection of DCM objects, e.g. a group, select the more actions button from a list of objects, and select Add to Access Group. Or from the properties of an object itself - select the General tab first if available select Edit Add to Access Group. Now only users belonging to the access group can access the object.
Permission groups
Permission groups define what kind of access you have on a specific object or collection of objects. A fixed list of permissions is available on objects, for example: Software.Install Software.Uninstall Software.Start Software.Stop Software.CheckStatus FileRepository.PutFile FileRepository.GetFile FileRepository.RemoveFile You create a permission group by selecting System Management Manage Security Permission Groups Edit Add Permission Group. Enter the name and description. Move the wanted permissions from the Available Permission list to the Assigned Permissions.
11.1.3 Access Permission group

By combining access groups and permission groups you declare what kind of operations users are allowed to perform on which objects. 1. We declare what kind of actions particular users can perform on which objects, from the User Details page, accessible from System Management Manage Users. 2. Select a user and from the User Details page, select Edit Assign Access Permissions. Select the required access group from the Available Access
530
Group drop down list box together with the wanted permission group from the Available Permission Groups drop down list box and press Save. 3. Repeat this selection if more access permissions are needed. The assigned access permissions are listed on the User Details page, on the right of the assigned security roles. The access group can also be removed for the user by clicking on the more actions button and selecting Remove.
11.1.4 Enable access control

By default, access control is not enforced by the Tivoli Provisioning Manager server. 1. When user roles have been defined and objects have been secured by access and permission groups, we need to set Access Control to on from the System Management Global Settings page, as shown in Figure 11-2 on page 531.
Figure 11-2 Enable access control from the global settings page
2. Press Apply to turn access control on.
531
Once access control is enabled, only a user with System Management - Edit security role permission is able to turn access control off. Note: Access control is never enforced for any user with the superuser property.
11.2 A case study

In this scenario, we want to configure the Tivoli Provisioning Manager server so that a user named patchman, our security officer can login and perform all patch related activities on Windows systems. All other operations and interaction to all other systems should be shielded from the security officer.
11.2.1 Create the security role

1. To limit menu items presented to patchman, we create a new security role from System Management Manage Security Security Roles Edit Add Role. 2. We create the LDAP ID distinguished name (cn) ITSO PatchMan role, give it the same name, and a declarative description. 3. We assign the needed roles, so that patchman can access all menu items to perform his job to as a Windows patch administrator. We open the Security Roles Properties page from Edit Properties and select the roles from the left listbox. We press Save. (Figure 11-3 on page 533)
532
Figure 11-3 ITSO Patchman security role
4. We do not forget the more generic roles Login, Task - Edit, Task - View and Workflow - Run.
11.2.2 Create the access group

We want to protect our DCM objects, and only expose those objects to patchman which he needs to interact with to perform his job as a Windows patch administrator. We protect the object by associate them with an access group in Associate objects to the access group on page 536, which we assign as default - and only - access group for our patchman user in Associate access and permission groups to the use on page 543. 1. First we need to create the access group from System Management Manage Security Access Groups Edit Add Access Group.
533
2. We create the ITSO PatchmanAG access group, providing a declarative description as shown in Figure 11-4 on page 534.
Figure 11-4 Create access group
3. We press Save and it is listed in available access groups (Figure 11-5 on page 535).
534
Figure 11-5 List of access groups
11.2.3 Create the permission group

1. Next we create a permission group from System Management Manage Security Access Groups Edit Add Permission Group. 2. We call it ITSO PatchmanPG, again providing a declarative description. 3. From the Properties page, we move the wanted permissions from the Available Permissions on the right to the left Assigned Permissions and press Save. Obviously we need the Software.Install and Software.Uninstall permissions to install patches. Additionally we need permissions to run compliance checks and the workflows to update the DCM with new Microsoft patch definitions. Figure 11-6 on page 536 shows the Create permission group window.
535
Figure 11-6 Create permission group
11.2.4 Associate objects to the access group

To protect DCM objects, we associate the object with an access group. Later we link the user to the access group and a permission group, The user can only see and act upon the resources belonging to the access group associated to the user. Our patchman user must be able to perform actions with software patches but only on Windows computers, the user must be able to run compliance, remediation and reports, and must be able to update the Microsoft patch catalog by running the workflow. 1. We created a static group to which we added the ITSO Windows system, so we associate the group with the ITSO PatchmanAG. From Inventory Manage Inventory Groups we click on the more actions button next to the ITSO Windows Group and select Add to Access Group. 2. From the Available Access Groups drop down list, we select the ITSO PatchmanAG and press Save.
536
Figure 11-7 Associate ITSO Windows group to ITSO PatchmanAG
This will make the Windows computers available to patchmans user interface, but only by passing through the ITSO Windows group. 3. If we want to make the computer visible in a by computer view, we need to assign the ITSO PatchmanAG access group to each individual computer. We can perform this in one operation, by selecting the ITSO Windows group. From the Members tab, we select all computers by clicking next to the Name tag, we expand the Assign to by clicking on the + sign, add the ITSO PatchmanAG and press Proceed as shown in Figure 11-8 on page 538.
537
Figure 11-8 Assign all computers to the ITSO PatchmanAG
In the same way, we assign more DCM resources to the ITSO PatchmanAG access group so patchman can do its jobs as a Windows patch administrator: Software Products Windows Update Agent (WUA) 2.0 WSUS Scan Cabinet File Patches Windows security bulletins for Windows 2000, Windows 2003 and XP Discovery Configurations Microsoft Updates Discovery Microsoft WUA Scan Security Compliance Scan Symantic AntiVirus Discovery Reports Inventory Inventory004 What patches are in the data center
538
Inventory006 What patches are on which computers Inventory007 What computers have which patches Compliance003 Do computers comply with their patch compliance checks Compliance007 What computers have patches approved for installation Compliance008 What patches are missing on what computers Deployment007 What patch deployment ran on which computers Deployment008 What patch deployment ran on computers grouped by operating system
Compliance
Deployment
4. We can verify which resources are associated to the access group, by selecting System Management Manage Security Access Groups, we select ITSO PatchmanAG. 5. Here we also have the capability to disassociate a particular DCM object with our ITSO PatchmanAG, by clicking on its more actions button and selecting Remove, or by selecting multiple items and pressing Proceed next to Remove selected object from Access Groups. New DCM resources created by our patchman account will automatically be assigned to the ITSO PatchmanAG, because we define it as the default access group for the user as described in Create the user on page 540.
539
Figure 11-9 ITSO PatchmanAG members
11.2.5 Create the user

1. We open Manage Users page from System Management and select Edit Add User (Figure 11-10 on page 541).
540
Figure 11-10 Add new user
2. We fill in the required fields, together with additional information, such as e-mail address. We select the ITSO_PatchWindowsAG as the Default Access Group. We provide the password, and select that the user must change his password the next time he logs in, The password policies, such as minimum length and enforced character rules are governed by the LDAP server. 3. We press Save and store the user properties in the LDAP registry. All DCM resources created by the patchman user will be assigned to its default access group, thus the user is granted intrinsic access to them. We dont check the superuser flag. Access control is never enforced for superuser-type users.
541
11.2.6 Assign the user a security role

As long as the user does not have a role, the user cannot login and interact with the DCM resources. At least Login role needs be attributed to the user to login to to Tivoli Provisioning Manager user interface. 1. From System Management Manage Users we click on the patchman user to view the user details page, we select Edit Configure Roles to assign our ITSO Patchman Role to patchman. 2. We move the role from the left to the right list by selecting it and clicking Add, and press Save (Figure 11-11 on page 542).
Figure 11-11 Assign security role
Now the user can login and will be shown the menu selection we defined in the ITSO Patchman Role in Create the security role on page 532.
542
11.2.7 Associate access and permission groups to the use

Next we assign the access group and permission groups to the user. 1. We click on Edit Assign Access Permissions, we select our ITSO PatchmanAG and ITSO PatchmanPG and press Save (Figure 11-12 on page 543).
Figure 11-12 Assign access group and permission
11.2.8 Enable access control

By default access control is disabled. If the default is still active, we need to enable access control as described in Figure 11-2 on page 531, or our patchman user will continue to have full access to the DCM.
11.2.9 Validate the access

Now we can verify if the patchman user has access to the needed menu items and is able to perform the wanted function. If this is not the case we can iterate one or more steps and validate the actions again:
543
If too much menu items are shown or if menu items are missing, go back to Create the security role on page 532 and adapt the security role. The user must logoff and logon again to see the changes. If resources are not shown in lists such as computers or software products, go back to Associate objects to the access group on page 536, and assign the access group to the object. The user normally does not need to logoff, unless the list of objects is cached. If access is denied in some way, go back to either Associate objects to the access group on page 536 or Create the permission group on page 535 and add either the needed permission or assign an additional object to the access group. It could also be that the security role is too restrictive, in that case go back to Create the security role on page 532. Validation can be done online, by using two different browser windows. Note that it is not possible to logon simultaneously to Tivoli Provisioning Manager with different users in different windows of the same browser instance - the latest user information will be applied. But it is possible to logon using Firefox and Mozilla or Internet Explorer with different users. This way we can validate changes quickly by logging on with a superuser on one browser, and verify the correct behavior of the restricted user using another browser. Here we are using Firefox to logon with patchman. Tivoli Provisioning Manager immediately asks us to change our password (Figure 11-13 on page 544).
Figure 11-13 Logon patchman
544
We see the limited options in the navigation tree on the left restricted by security role, and the limited list of computers and products to install - restricted by access group (Figure 11-14 on page 545).
Figure 11-14 Restricted computers and software products
The same applies to the reports. In Figure 11-15 on page 546 we see the inventory reports available to patchman.
545
Figure 11-15 Restricted Inventory reports
546
12
Chapter 12.
SOAP and command line interface

This chapter provides an introduction into the SOAP (Simple Object Access Protocol) services and command line interface (CLI) available with Tivoli Provisioning Manager V5.1 The full reference guide for all the commands referred to in this chapter can be found in the Tivoli Provisioning Manager V5.1 online Information center that can be accessed at: http://publib.boulder.ibm.com/infocenter/tivihelp/v13r1/index.jsp The following topics are discussed in this chapter: SOAP overview on page 548 Location of SOAP Client on page 549 Examples of using SOAP on page 552 Tivoli Provisioning Manager V5.1 logical device operations on page 561 Tivoli Provisioning Manager V5.1 scripts on page 568
547
12.1 SOAP overview

SOAP is a platform neutral protocol which consists of a network, transport, and programming services which allows a client to call a remote service. All messages sent using a SOAP client, are in XML format. SOAP is the chosen XML messaging protocol for many reasons:
It is the standardized enveloping mechanism for communicating document-centric messages and remote procedure calls using XML. The term envelope in this context, is used as a group of XML components wrapped together and sent as a single message. The envelope has a defined structure, namely a message header, and a location for an XML document (also known as the payload). A SOAP message is similar to a HTTP POST message with an XML envelope as payload. SOAP is a specification for the exchange of structured information in a decentralized, distributed environment, and represents the main way of communication between the three main services in SOA: The service provider. The service requestor. The service broker. Many Tivoli Provisioning Manager V5.1 internal properties and methods are available through SOAP commands. Some services enable you to perform data center administration tasks, such as changing the operating mode. Other commands provide access to logical device operations for making configuration changes to data center assets. To run a particular SOAP command, you must have the required security role and access permissions, and SOAP commands can be used to manage your data center from the command line. There are two main categories of SOAP commands: For data center administration These commands enable you to perform tasks such as changing operating modes, approving and declining recommendations, and managing failed servers. For logical device operations These commands are used to invoke workflows from the command line or client applications.
548
12.1.1 Using SOAP

SOAP commands are invoked from the command line, and can be useful for integrating and automating processes that are managed by an external management system. For example, you can create a SOAP script that is invoked when specific events occur. For example, consider an IBM Tivoli Monitoring solution which is being used to monitor a cluster of Web servers, which are being used as a home shopping Website. If one Web server in this cluster develops a performance problem and stops responding, this could be detected by IBM Tivoli Monitoring, which would be actively monitor the servers in the cluster. IBM Tivoli Monitoring can then invoke a SOAP command which would send a message to Tivoli Provisioning Manager V5.1. This message could cause Tivoli Provisioning Manager V5.1 to start a workflow to provision a new web server for the web cluster, hence minimizing the impact of the server which had stopped responding.
12.2 Location of SOAP Client

As shown in Figure 12-1, the SOAP client is located in the <Installation directory>/soapclient/tpmLteSoap/ directory. For example, C:/ibm/tivoli/tio/soapclient/tpmLtsSoap.
Figure 12-1 Tivoli Provisioning Manager V5.1 supplied SOAP Scripts
Chapter 12. SOAP and command line interface
549
This directory will contain a number of sample SOAP scripts (discussed in 12.3.1, Running the SOAP client on page 552, together with the SOAP Client. There are three variants of the SOAP client scripts. The appropriate one must be used, depending on the platform you are running on: soapcli.cmd This is used in a Windows DOS shell, and can also be used in a cygwin shell which is opened on a Windows Tivoli Provisioning Manager V5.1server. soapcli.sh This is used on a UNIX or Linux Tivoli Provisioning Manager V5.1 server. soap_bash4win.sh This would be used inside a bash shell running on a windows Tivoli Provisioning Manager V5.1 server. This script has to be modified to point to a suitable Java Development Kit (JDK) version1.4 or later.
12.2.1 Running a remote SOAP Client

To enable a remote server to communicate with the Tivoli Provisioning Manager V5.1, the following setup needs to be performed on the remote server: 1. Copy the appropriate SOAP client script and Java archive (JAR) files to the remote server: a. On the remote server, create a directory for the SOAP client. b. Copy the contents of the soapclient directory from the Tivoli Provisioning Manager V5.1 server to the SOAP client directory on the remote server: c. On the remote server, change to the SOAP client directory. d. Open the appropriate SOAP script in a text editor. e. Set the value of TIO_LIB by changing the value of the TIO_HOME variable to the SOAP client directory that you created on the remote server: On Windows: set TIO_LIB=%TIO_HOME%\tpmlteSoap\lib On UNIX or Linux: TIO_LIB=$TIO_HOME\tpmlteSoap\lib
550
2. The JAR files which need to be copied, are in the lib subdirectory of the SOAP client directory, as shown in Figure 12-2.
Figure 12-2 Tivoli Provisioning Manager V5.1 SOAP Client JAR files
3. Modify the soapcli script that you will use, to point to the correct location of the JDK. A Java Development Kit (JDK) that supports Java Technology version 1.4 or later must be installed on the remote server. Before you begin configuration of the remote server, ensure that the JDK is installed and configured: a. Install a JDK if one is not currently installed. You can obtain a JDK from IBM, Sun Microsystems, and various open source groups. The IBM developer kits are available from: http://www-106.ibm.com/developerworks/java/jdk/ The Sun Microsystems developer kits are available from: http://java.sun.com Note: The JDK installation directory should not include spaces. b. Ensure that the JAVA_HOME environment variable is set to the JDK installation directory. c. If you are using a remote Windows server, add the \java\bin directory to the system path.
551
12.3 Examples of using SOAP

Here we show a number of examples using the various SOAP scripts and commands.
12.3.1 Running the SOAP client

The general syntax of making a SOAP call is: soapcli.cmd username password wsdl_location operation parameters The username and password are for a valid user created in Tivoli Provisioning Manager V5.1 The wsdl location refers to the URL for the Web Services Definition Language (WSDL) file, and is of the form: http://hostname:port/ws/pid/wsdlservicename?wsdl The Web address includes the following parameters: Host name Is the fully qualified domain name of the Tivoli Provisioning Manager V5.1server, or localhost, if the client is running locally on the Tivoli Provisioning Manager V5.1 server. Port Is the port number (the default is 8777). wsdlservicename Is the name of the WSDL Service. Operation The WSDL operation that you want to run. Parameters The parameters for the specified method or operation.You can obtain the values for most of the parameters from the Web interface. Move mouse cursor over the appropriate device to obtain the device ID. Table 12-1 shows the WSDL services that are supported in Tivoli Provisioning Manager V5.1. The URL shown should be entered on an Internet browser on the Tivoli Provisioning Manager V5.1, to get a list of all operations and their definitions available.
552
Table 12-1 WSDL Service name and URL WSDL Service Name TpmLiteSoapService CredentialsManagerService SPOfferingService SPSubscriptionService EffectiveModeService OperationsModeService FaultManagementService RecommendationsSerivice ResourceInformationService WSDL Service URL http://localhost:8777/ws/pid/TpmLiteSoapService?wsdl http://localhost:8777/ws/pid/CredentialsManagerService?wsd l http://localhost:8777/ws/pid/SPOfferingService?wsdl http://localhost:8777/ws/pid/SPSubscriptionService?wsdl http://localhost:8777/ws/pid/EffectiveModeService?wsdl http://localhost:8777/ws/pid/OperationsModeService?wsdl http://localhost:8777/ws/pid/FaultManagementService?wsdl http://localhost:8777/ws/pid/RecommendationsService?wsdl http://localhost:8777/ws/pid/ResourceInformationService?ws dl
As an example, on the Tivoli Provisioning Manager V5.1 server, the following URL will show an XML file: http://localhost:8777/ws/pid/OperationsModeService?wsdl, As shown in Example 12-1, the portion of this file from which the operations can be determined begins with - <xsd:schema targetNamespace="http://service.Webservice.soap.tpm.tivoli.ibm.com"> The operation keyword which would be used in the SOAP command is shown in bold.
Example 12-1 Sample output from browsing to a WSDL URL
- <xsd:schema targetNamespace="http://service.webservice.soap.tpm.tivoli.ibm.com"> <xsd:element name="setGlobalMode" type="xsd:string" /> <xsd:element name="createWSResourceResponse" type="apache-soap:Element" /> + <xsd:element name="getGlobalMode"> <xsd:complexType /> </xsd:element> <xsd:element name="getEffectiveClusterMode" type="xsd:int" /> <xsd:element name="setApplicationMaintenanceMode" type="pns1:SetApplicationMaintenanceModeRequest" /> <xsd:element name="getEffectiveClusterModeResponse" type="xsd:string" /> <xsd:element name="getClusterModeResponse" type="xsd:string" /> + <xsd:element name="setApplicationModeResponse">
553
<xsd:complexType /> </xsd:element> <xsd:element name="getEffectiveApplicationModeResponse" type="xsd:string" /> <xsd:element name="setGlobalModeResponse"> <xsd:complexType /> </xsd:element> <xsd:element name="createWSResource" type="apache-soap:Element" /> <xsd:element name="setMaintenanceModeResponse"> <xsd:complexType /> </xsd:element> <xsd:element name="setMaintenanceMode" type="pns1:SetMaintenanceModeRequest" /> <xsd:element name="setClusterMode" type="pns1:SetClusterModeRequest" /> <xsd:element name="setApplicationMaintenanceModeResponse"> <xsd:complexType /> </xsd:element> <xsd:element name="setApplicationMode" type="pns1:SetApplicationModeRequest" /> <xsd:element name="getApplicationModeResponse" type="xsd:string" /> <xsd:element name="getClusterMode" type="xsd:int" /> <xsd:element name="setClusterModeResponse"> <xsd:complexType /> </xsd:element> <xsd:element name="getEffectiveApplicationMode" type="xsd:int" /> <xsd:element name="getApplicationMode" type="xsd:int" /> <xsd:element name="getGlobalModeResponse" type="xsd:string" /> </xsd:schema>
An example of making a SOAP call to find all the deployment requests that have been executed is shown in Example 12-2.
Example 12-2 Using the soapcli.cmd to retrieve all deployment requests
$ ./soapcli.cmd tioadmin object00 http://localhost:8777/ws/pid/TpmLiteSoapService?wsdl findAllDeploymentRequests The output from this command is also shown in Example 12-3.
Example 12-3 Output of the findAllDeplotmentRequests operation
Deployment Requests: Total: 14 requestId=10085, workflowName=Cluster.RemoveServer, status=success, createdDate=Tue Sep 19 22:04:54 BST 2006 requestId=10083, workflowName=Cluster.AddServer, status=success, createdDate=Tue Sep 19 22:01:51 BST 2006
554
requestId=10101, workflowName=Cluster.RemoveServer, status=success, createdDate=Tue Sep 19 21:52:58 BST 2006 requestId=10100, workflowName=Cluster.AddServer, status=success, createdDate=Tue Sep 19 21:50:31 BST 2006 requestId=10080, workflowName=Execute_Local_Command, status=success, createdDate=Tue Sep 19 21:30:10 BST 2006 requestId=10062, workflowName=loop, status=success, createdDate=Tue Sep 19 16:03:49 BST 2006 requestId=10061, workflowName=loop, status=success, createdDate=Tue Sep 19 16:03:20 BST 2006 requestId=10060,workflowName=Education_Installable_install,status=success, createdDate=Tue Sep 19 15:27:46 BST 2006 requestId=10042, workflowName=Education_Installation_AddInstance, status=success, createdDate=Tue Sep 19 13:06:45 BST 2006 requestId=10041,workflowName=Education_Installable_install,status=success, createdDate=Tue Sep 19 13:06:14 BST 2006 requestId=10040, workflowName=Education_Installable_install, status=success, createdDate=Tue Sep 19 12:57:04 BST 2006 requestId=10021, workflowName=Education_Installable_install, status=success, createdDate=Tue Sep 19 08:07:06 BST 2006 requestId=10020, workflowName=Education_Instance_Start, status=success, createdDate=Tue Sep 19 08:05:53 BST 2006 requestId=10000, workflowName=Cluster.AddServer, status=success, createdDate=Wed Aug 23 12:04:20 BST 2006
12.3.2 Running the SOAP scripts

The out of the box SOAP scripts are simply wrapper scripts for commonly used soap commands, as show in Table 12-2
Table 12-2 SOAP Wrapper Scripts Script Name and Usage approve.cmd username password recommendation_id deploy.cmd username password cluster_ID number_of_servers Description Approves the specified deployment recommendation, while in semiautomatic mode. Adds or removes the specified number of servers to or from a tier. The tier must be in manual mode. Use negative numbers for server removal. Set a given server to the Failed state.
failserver.cmd username password server_id
555
Script Name and Usage repairserver.cmd username password server_id manual.cmd username password
Description Repair a given server. Changes the current global operating mode to manual. (Relevant to IBM Tivoli Intelligent Orchestrator) Changes the current global operating modeto semiautomatic. (Relevant to IBM Tivoli Intelligent Orchestrator) Changes the current global operating mode to automatic. (Relevant to IBM Tivoli Intelligent Orchestrator) Returns the current global operating mode. (Relevant to IBM Tivoli Intelligent Orchestrator) Cancels the specified deployment request. Imports a resource defined in XML format into the data center model. Checks the status of the workflow. Finds the error message associated with a workflow. Finds log information associated with a workflow. Find the value of a parameter in a deployment request. Returns the value of the local server ID
semi.cmd username password
auto.cmd username password
mode.cmd username password
cancelDeploymentRequest.cmd username password DeploymentRequestID createByXmlImport.cmd username password file_name findDeploymentStatus.cmd username password DeploymentRequestID findErrorMessage.cmd username password DeploymentRequestID findLogDetails.cmd username password DeploymentRequestID findParameterValue.cmd username password DeploymentRequestID parametername getLocalServerId.cmd username password
12.3.3 Running logical operations using SOAP

A common use of the SOAP interface, would be to run logical operations as part of driving the automation from an external system, such as a help desk or event management system.
556
The TpmLiteSoapService provides an operation called executeDeploymentRequest which can be used to run any logical device operation, as shown in Example 12-4.
Example 12-4 Using soapcli to run a logical device operation
$ ./soapcli.cmd <user id> <password> http://localhost:8777/ws/pid/TpmLiteSoapService?wsdl executeDeploymentRequest <Logical Device.Logical Operation> "<parameter1=value1> <parameter2=value2>" The logical device operation parameter will be of the form Logical Device.Logical Operation, and a few examples are show below: Cluster.AddServer Cluster.RemoveServer BootServer.CaptureImage BootServer.InstallImage SoftwareModule.Install SoftwareInstallation.AddInstance SoftwareInstallation.Uninstall SoftwareInstance.RemoveInstance SoftwareInstance.Start SoftwareInstance.Stop A complete list of logical device operations (LDOs) is shown in Example 12-10 on page 561. To add a server to an application tier, the command shown in Example 12-5 is used.
Example 12-5 Using soapcli to run the Cluster.AddServer Logical Device Operation
$ ./soapcli.cmd tioadmin object00 http://localhost:8777/ws/pid/TpmLiteSoapService?wsdl executeDeploymentRequest Cluster.AddServer "ClusterID=4070"
557
The Cluster.AddServer LDO requires the ClusterID as an input parameter. This parameter is obtained by using the User Interface and moving the mouse over the Application Cluster hyperlink, as shown in Figure 12-3.
Figure 12-3 Obtaining the Application Cluster ID
The output of the SOAP command is the deployment request id, as shown in Example 12-6
Example 12-6 The output of running the Cluster.AddServer executeDeploymentRequest
$ ./soapcli.cmd tioadmin object00 http://localhost:8777/ws/pid/TpmLiteSoapService?wsdl executeDeploymentRequest Cluster.AddServer "ClusterID=4070"Result: 10083
Figure 12-4 Workflow Execution Status
This request, together with the completion can also be viewed in the User Interface Workflow Status screen, as shown in Figure 12-4. The completion status can also be obtained using the SOAP command shown in Example 12-7 on page 559
558
Example 12-7 Using soapcli to view the completion status of a deployment request.
$ ./soapcli.cmd tioadmin object00 http://localhost:8777/ws/pid/TpmLiteSoapService?wsdl findDeploymentStatus 10083 Result: 3 The output of the findDeploymentStatus operation will return one of the following numerical values, which represents the status of the workflow. 0 1 2 3 4 5 unknown in-progress cancelled success failed created
Figure 12-5 shows that the Cluster.AddServer LDO succeeded, and provisioned a server into the StateBank Mail Appication Tier.
Figure 12-5 Result of Cluster.AddServer
Some deployment requests, may take longer to execute, in which you will see a result code of 1, indicating that the workflow is in progress, as shown in Example 12-8 on page 559.
Example 12-8 Using soapcli to show deployments in progress
$ ./soapcli.cmd tioadmin object00 http://localhost:8777/ws/pid/TpmLiteSoapService?wsdl findDeploymentStatus 10085 Result: 1
559
To obtain further execution details of a workflow, you can use the findLogDetails operation, as shown in Example 12-9 on page 560.
Example 12-9 Using soapcli to show execution log details of a deployment request
$ ./soapcli.cmd tioadmin object00 http://localhost:8777/ws/pid/TpmLiteSoapServi ce?wsdl findLogDetails 10085 Log Details: Total: 37 Start logical operation: 'Cluster.RemoveServer' Start workflow: 'Simulator_RemoveServer' Start workflow: 'Get_Current_Deployment_Request_Id' Start Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.GetCurrentDeploymentRequestId' End Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.GetCurrentDeploymentRequestId' End workflow: 'Get_Current_Deployment_Request_Id' Start workflow: 'Get_Cluster_Attributes' End workflow: 'Get_Cluster_Attributes' Start Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.resourcemanager.RMChooseServerForRemoval' End Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.resourcemanager.RMChooseServerForRemoval' Processing server template StateBank Mail template 602 for application tier StateBank Mail. Cannot find matching NIC for NIC template 41. Start workflow: 'RM_Remove_Server' Start Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.resourcemanager.RMRemoveServerFromCluster' End Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.resourcemanager.RMRemoveServerFromCluster' End workflow: 'RM_Remove_Server' Processing server template Sendmail-Solaris8 template 200 for resource pool Sendmail-Solaris8. Processing NIC 3858 with NIC template 26 Processing network interface template 26 Start Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.resourcemanager.RMAllocateIPAddress' End Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.resourcemanager.RMAllocateIPAddress' Start workflow: 'Create_Network_Interface' End workflow: 'Create_Network_Interface' Start workflow: 'Simulator_Move_Net_Interfaces' Start Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.simulator.SimulatorMoveNetworkInterfaces'
560
End Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.simulator.SimulatorMoveNetworkInterfaces' End workflow: 'Simulator_Move_Net_Interfaces' Start workflow: 'Set_NIC_s_VLAN' Start Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.datacentermodel.SetNicVlan' End Java plugin 'com.thinkdynamics.kanaha.de.javaplugin.datacentermodel.SetNicVlan' End workflow: 'Set_NIC_s_VLAN' End workflow: 'Simulator_RemoveServer' Start workflow: 'PostClusterRemoveServer' Start Java plugin'com.thinkdynamics.kanaha.de.javaplugin.GetCurrentDeploymentRequestId' End Java plugin'com.thinkdynamics.kanaha.de.javaplugin.GetCurrentDeploymentRequestId' End workflow: 'PostClusterRemoveServer' End logical operation: 'Cluster.RemoveServer'
12.4 Tivoli Provisioning Manager V5.1 logical device operations

A list of all logical device operations available in Tivoli Provisioning Manager V5.1 through the user interface is shown in Example 12-10 on page 561, in the form of Logical Device.Logical Operation.
Example 12-10 Logical device operations
AdminDomain.AddNode Application.Deploy Application.DisruptiveUpgrade Application.NonDisruptivePatch Application.Undeploy ApplicationDeployment.Undeploy ApplicationModule.Deploy BackupResource.Backup BackupResource.Restore BackupSystem.Backup BackupSystem.Restore BootServer.CaptureBackupImage BootServer.CaptureImage
561
BootServer.DeleteImage BootServer.InstallGoldenMasterImage BootServer.InstallImage BootServer.InstallScriptedImage BootServer.ReplicateImage BootServer.RestoreBackupImage Cluster.AddRepairedServer Cluster.AddServer ClusterDomain.AddNode ClusterDomain.Config ClusterDomain.Create ClusterDomain.CreateNode ClusterDomain.CreateResource ClusterDomain.CreateResourceGroup ClusterDomain.Remove ClusterDomain.RemoveNode ClusterDomain.Start ClusterDomain.StartNode ClusterDomain.Stop ClusterDomain.StopNode ClusterDomain.UpdateDomainStatus ClusterDomain.UpdateNodeStatus ClusterResource.AddGroupMember ClusterResource.CreateDependency ClusterResource.RemoveDependency ClusterResource.RemoveResource ClusterResource.RemoveResourceGroup ClusterResource.Start ClusterResource.StartResourceGroup ClusterResource.Stop ClusterResource.StopResourceGroup ClusterResource.Update ClusterResource.UpdateResourceGroup Compliance.ValidateServer ComplianceRecommendation.Remediate ComplianceRecommendationGroup.Remediate ConfigurationCompliance.OnNonComplianceEvent
562
Device.AddMPLSPathToMPLSTunnel Device.ClearAllTunnels Device.CopyFile Device.CreateMPLSPath Device.CreateMPLSTunnel Device.CreateServiceAccessPoint Device.DeleteMPLSPath Device.DeleteMPLSTunnel Device.Discover Device.DiscoverDrift Device.ExecuteCommand Device.GetAttribute Device.HardwareReboot Device.Initialize Device.Ping Device.PowerOff Device.PowerOn Device.Reboot Device.Rebuild Device.RemoveMPLSPathFromMPLSTunnel Device.RemoveServiceAccessPoint Device.SetAttribute Device.SoftwareRebootAsync Device.SoftwareRebootSync Device.UpdateMPLSTunnelActivePath DeviceDriver.Associate DeviceDriver.Dissociate Discovery.CheckStatus Discovery.Discover Discovery.Drift Discovery.OnDevice Discovery.OnDeviceChangedEvent Discovery.OnDeviceRemovedEvent Discovery.OnDevices Discovery.OnDeviceUpdatedEvent Discovery.OnNewDevicesUpdateDcm Discovery.Start Discovery.Stop Discovery.Update Discovery.UpdateDcm EventConsumer.OnEvent
563
FileRepository FileRepository.GetFile FileRepository.MountShare FileRepository.Publish FileRepository.PutFile FileRepository.RemoveFile FileRepository.UnmountShare FileRepository.UnPublish Firewall.AddACL Firewall.DisableACL Firewall.EnableACL Firewall.RemoveACL Group.Refresh HostingEnvironment.Host HostingEnvironment.Undeploy HostPlatform.AllocateVirtualResource HostPlatform.CreateVirtualServer HostPlatform.DeallocateVirtualResource HostPlatform.DestroyVirtualServer HostPlatform.ExpandResourceAllocation HostPlatform.ReduceResourceAllocation IPSystem.AddNetworkInterface IPSystem.ApplyRoutingTable IPSystem.RemoveNetworkInterface LoadBalancer.AddRealIPToVirtualIP LoadBalancer.CreateVirtualIP LoadBalancer.RemoveRealIPFromVirtualIP LoadBalancer.RemoveVirtualIP MonitoringApplication.ConfigureMonitoring MonitoringApplication.RemoveMonitoring MonitoringApplication.StartMonitoring MonitoringApplication.StopMonitoring OperatingSystem.AddGroup OperatingSystem.AddNetworkInterface OperatingSystem.AddUser OperatingSystem.AddUserToGroup
564
OperatingSystem.ApplyRoutingTable OperatingSystem.CaptureUserProfile OperatingSystem.CreateDASDPhysicalVolume OperatingSystem.CreateSANPhysicalVolume OperatingSystem.RemoveGroup OperatingSystem.RemoveNetworkInterface OperatingSystem.RemovePhysicalVolume OperatingSystem.RemoveUser OperatingSystem.RemoveUserFromGroup OperatingSystem.RemoveUserProfile OperatingSystem.RestoreUserProfile OperatingSystem.SetUserPassword OperatingSystem.SoftwareRebootAsync OperatingSystem.SoftwareRebootSync PowerUnit.CycleOutlet PowerUnit.TurnOutletOFF PowerUnit.TurnOutletON Repository.ImportPatches Repository.UpdatePatches Router.CreateRoute Router.RemoveRoute SANFabric.AddZoneMembers SANFabric.CreateZone SANFabric.RemoveZone SANFabric.RemoveZoneMembers ServerTemplate.ConfigureServerByTemplate ServiceAccessPoint ServiceAccessPoint.CopyFile ServiceAccessPoint.CreatePwdCredential ServiceAccessPoint.CreateRSACredential ServiceAccessPoint.CreateSNMPCredential ServiceAccessPoint.ExecuteCommand ServiceAccessPoint.GetAttribute ServiceAccessPoint.PingIP ServiceAccessPoint.RemovePwdCredential ServiceAccessPoint.RemoveRSACredential ServiceAccessPoint.RemoveSNMPCredential ServiceAccessPoint.ReplacePwdCredential ServiceAccessPoint.ReplaceRSACredential
565
ServiceAccessPoint.ReplaceSNMPCredential ServiceAccessPoint.SetAttribute Software.CheckStatus Software.Install Software.Start Software.Stop Software.Uninstall SoftwareApplicationDeployment SoftwareApplicationDeployment.Deploy SoftwareDistributionApplication.RegisterSoftwarePackage SoftwareDistributionApplication.UnregisterSoftwarePackage SoftwareInstallable.Distribute SoftwareInstallable.Install SoftwareInstallable.MultipleInstall SoftwareInstallable.Publish SoftwareInstallable.UnPublish SoftwareInstallation.AddInstance SoftwareInstallation.Uninstall SoftwareInstance.RemoveInstance SoftwareInstance.Start SoftwareInstance.Stop SoftwareModule.DistributeInstallable SoftwareModule.Install SoftwareModule.MultipleInstall SoftwareResource.Configure SoftwareResource.UpdateDCM SoftwareResource.Upgrade SoftwareStack.Install SoftwareStack.Uninstall SparePool.CleanupServer SparePool.InitializeServer SPService.Deprovision SPService.Modify SPService.ProcessOrder
566
SPService.Provision SPService.Reserve StorageManager.AddPhysicalVolumeToLogicalVolume StorageManager.AddPhysicalVolumeToVolumeContainer StorageManager.AddServerToVolumeContainer StorageManager.AddStorageToHost StorageManager.AddStorageVolumeArrayToHost StorageManager.AddStorageVolumeToHost StorageManager.Clone StorageManager.CreateFileSystem StorageManager.CreateLogicalVolume StorageManager.CreateMirrorVolume StorageManager.CreateStripeVolume StorageManager.CreateVolumeContainer StorageManager.ExtendFileSystem StorageManager.ExtendLogicalVolume StorageManager.RemoveFileSystem StorageManager.RemoveLogicalVolume StorageManager.RemovePhysicalVolumeFromLogicalVolume StorageManager.RemovePhysicalVolumeFromVolumeContainer StorageManager.RemoveServerFromVolumeContainer StorageManager.RemoveStorageFromHost StorageManager.RemoveStorageVolumeArrayFromHost StorageManager.RemoveVolumeContainer StorageManager.RmStorageVolumeFromHost StoragePool.CreateStorageVolume StoragePool.CreateStorageVolumeWithName StoragePool.GetStorageVolumes StoragePool.RemoveStorageVolume StorageSubsystem.CreateStorageVolume StorageSubsystem.CreateStorageVolumeWithName StorageSubsystem.GetStorageVolumes StorageSubsystem.LunMapping StorageSubsystem.LunMasking StorageSubsystem.LunUnmapping StorageSubsystem.LunUnmasking StorageSubsystem.MapVolumeArrayToFA StorageSubsystem.MapVolumeToFA StorageSubsystem.RemoveStorageVolume StorageSubsystem.UnmapVolumeArrayFromFA StorageSubsystem.UnmapVolumeFromFA
567
Switch.CarryVLANThroughSwitchEndpoint Switch.ChangeSwitchEndpointAttributes Switch.ClearVLANFromSwitchEndpoint Switch.CreateVLAN Switch.MovePort Switch.MovePortToVLAN Switch.RemoveVLAN Switch.TurnPortOFF Switch.TurnPortON Task.OnTaskFailEvent Task.OnTaskStartEvent Task.OnTaskSuccessEvent TpmTask.CancelInProgress TpmTask.Execute TpmTaskDefinition.Execute
12.5 Tivoli Provisioning Manager V5.1 scripts

A number of scripts are provided in the Tivoli Provisioning Manager V5.1installation subdirectory, called tools, as shown in Figure 12-6 on page 569 Some of these scripts are discussed here. Each script is supplied in two variants: One with a .cmd extension and one with a .sh extension. The .sh variant must only be run on a Linux or Unix Tivoli Provisioning Manager V5.1 server. The .cmd variant is to be used on a windows Tivoli Provisioning Manager V5.1 server.
568
Figure 12-6 Commands scripts located in $TIO_HOME/tools
12.5.1 Starting Tivoli Provisioning Manager V5.1 on the command line

The script startServiceAndBrowser.cmd can be used to start the Tivoli Provisioning Manager V5.1 service and then launch the Internet Browser. If Tivoli Provisioning Manager V5.1 is already running, then a message will be displayed, and only the Internet browser will be launched, as shown below in Example 12-11
Example 12-11 Starting Tivoli Provisioning Manager V5.1 on the command line
$ ./startServiceAndBrowser.cmd TPM is already running
12.5.2 Working with automation packages

An automation package is an installation unit that consists of the scripts, workflows, documentation and Java files for a particular device or software package. Automation packages have a .tcdriver extension and are centrally stored in the <installation location>\drivers directory of the Tivoli Provisioning Manager V5.1 server.
569
Automation Packages can be installed using the tc-driver-manager.cmd. If this script is run with no, or incorrect arguments, then the output shown in Example 12-12 on page 570 will be displayed. This command can also be used to list the installation status of each automation package, which exists in the <installation location>\drivers directory, as shown in Example 12-12.
Example 12-12 Listing status of Automation Packages
Administrator@enterprise /cygdrive/c/IBM/tivoli/tio/tools $ ./tc-driver-manager.cmd listAllStr 2006-09-20 16:41:51,234 INFO log4j configureAndWatch is started with configurat ion file: C:\IBM\tivoli\tio/config/log4j-util.prop 2006-09-20 16:41:51,562 INFO COPTDM001I TCDrivermanager was started. 2006-09-20 16:41:52,562 INFO COPTDM004I Config directory: "file:C:\IBM\tivoli\t io/config/". 2006-09-20 16:41:52,656 INFO COPTDM004I Config directory: "file:C:\IBM\tivoli\t io/config/". 2006-09-20 16:41:52,703 INFO COPTDM002I Driver directory: "Driver directory: "C :\IBM\tivoli\tio/drivers/".". 2006-09-20 16:42:04,859 INFO COPTDM004I Config directory: "file:C:\IBM\tivoli\t io/config/". 2006-09-20 16:42:08,547 INFO COPTDM005I TCDrivermanager was stopped. 2006-09-20 16:42:08,562 INFO TC Driver Name ============== AIX-LVM AIX-Operating-System AIX_FIX Apache-Web-Server-Windows ApacheLinux ApacheWebServerWindows Blade-Center-4p-Gb-Eth CDS CHAMPS CIMClient CSM-Linux-Install CiscoSwitchDiscovery CitScannerAgent Cygwin DB2 DSMUtils F5-BIG-IP.3.3 F5-BIG-IP.4.1 Version Status ================= ================ not-installed not-installed not-installed not-installed 1.0 installed 5.1.0.0.1767.38 installed not-installed 5.1.0.0.1767.38 installed not-installed not-installed not-installed not-installed 5.1.0.0.1767.38 installed not-installed 5.1.0.0.1767.38 installed 5.1.0.0.1767.38 installed not-installed not-installed
570
F5-BIG-IP.4.5 FileRepository Globalization_Helper HP-UX HPUX_VPAR_CPU IBM-BladeCenter-Management IBM-ESS IBM-Http-Server IBM-RDM IBM-WebSphere-App-Server IBM-WebSphere-Edge IBMHttp IBM_Director_Discovery ITM ITM6.1 ITM61 LPAR-cpu LocalFileRepository MS-Exchange-Server MS-SQL2K MSADS MSAD_Discovery MSClusterServices MS_VirtualServer MS_WSUS NIM Nortel_Alteon PeopleSoftTools Provider1 RXA RedHat_EL_Update SCMCollectorAgent SPBHandler Sun_Update_Connection SymantecAV TECDriver TMAInstall TPMNetworkDiscovery TivoliCommonAgent TivoliCommonAgent-core TpmTaskInf Tuxedo VxVM-VolumeManager apache apc-snmp
5.1.0.0.1767.38
5.1.0.0.1767.38 5.1.0.0.1767.38
5.1.0.0.1767.38
5.1.0.0.1767.38
5.1.0.0.1767.38 5.1.0.0.1767.38 5.1.0.0.1767.38
5.1.0.0.1767.38 5.1.0.0.1767.38 5.1.0.0.1767.38
not-installed not-installed not-installed not-installed not-installed not-installed not-installed not-installed not-installed not-installed not-installed installed not-installed not-installed not-installed installed not-installed installed not-installed not-installed not-installed installed not-installed not-installed installed not-installed not-installed not-installed not-installed installed not-installed installed installed not-installed not-installed not-installed not-installed installed installed installed not-installed not-installed not-installed not-installed not-installed
571
application-service application-topologies backup brocade cisco-csm-6500 cisco-css-11000 cisco-discovery cisco-mds cisco-pix cisco-switches citrix cluster-domain-simulator cluster-ldo-templates core cvsserver db2 default-device-model default_automation_package discovery-library discovery-library-adaptor dms-client-subagent domino dummy-load-balancer dummy-switch educationDriver event-subagent extreme-48i foundry hacmp image itds60 jes-subagent jumpstart mailer mcdata microsoft-patch netview networking-advanced oa-tio-capacity-on-demand oracle10g oracle9i pSeries-Server proliant-bl-server rational-testmgr rdp-altiris
5.1.0.0.1767.38 5.1.0.0.1767.38
5.1.0.0.1767.38 5.1.0.0.1767.38 5.1.0.0.1767.38 5.1.0.0.1767.38 5.1.0.0.1767.38 5.1.0.0.1767.38 5.1.0.0.1767.38 5.1.0.0.1767.38 5.1.0.0.1767.38 5.1.0.0.1767.38 5.1.0.0.1767.38
1.0 5.1.0.0.1767.38
5.1.0.0.1767.38 5.1.0.0.1767.38
5.1.0.0.1767.38
not-installed not-installed not-installed not-installed installed installed not-installed not-installed installed installed not-installed installed installed installed not-installed installed installed installed installed installed installed not-installed not-installed not-installed installed installed not-installed not-installed not-installed installed not-installed installed not-installed not-installed not-installed not-installed not-installed installed not-installed not-installed not-installed not-installed not-installed not-installed not-installed
572
redhat-linux-operating-system redline rembo sample-compliance-validation siebel simulator sles-operating-system software_simulator solaris-operating-system storage-simulation test tsa-cluster-domain vmware-4 weblogic windows-operating-system zvm
5.1.0.0.1767.38 5.1.0.0.1767.38
5.1.0.0.1767.38 5.1.0.0.1767.38
5.1.0.0.1767.38 1.0
5.1.0.0.1767.38
installed not-installed installed not-installed not-installed installed installed not-installed not-installed installed installed not-installed not-installed not-installed installed not-installed
An example of installing an automation package called software_simulator.tcdriver is shown in Example 12-13.

Example 12-13 Installing an Automation package using tc-driver-manager.cmd
Administrator@enterprise /cygdrive/c/IBM/tivoli/tio/tools $ ./tc-driver-manager.cmd installDriver software_simulator 2006-09-20 16:51:40,484 INFO log4j configureAndWatch is started with configurat ion file: C:\IBM\tivoli\tio/config/log4j-util.prop 2006-09-20 16:51:41,234 INFO COPTDM001I TCDrivermanager was started. 2006-09-20 16:51:43,734 INFO COPTDM004I Config directory: "file:C:\IBM\tivoli\t io/config/". 2006-09-20 16:51:43,875 INFO COPTDM004I Config directory: "file:C:\IBM\tivoli\t io/config/". 2006-09-20 16:51:43,953 INFO COPTDM002I Driver directory: "Driver directory: "C :\IBM\tivoli\tio/drivers/".". 2006-09-20 16:51:52,781 INFO COPTDM003I Installing driver "software_simulator", force: "false", installItems: "true". 2006-09-20 16:52:17,000 INFO COPTDM004I Config directory: "file:C:\IBM\tivoli\t io/config/". 2006-09-20 16:52:22,156 INFO COPTDM006I Creating DCM_OBJECT entry for TCDriver "software_simulator". 2006-09-20 16:52:24,656 INFO COPTDM011I Installing driver item "xml/dmcategorie s.xml". 2006-09-20 16:52:26,094 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_BootServer/software_simulator_BootServer_CaptureBackupImage.wkf". 2006-09-20 16:52:29,938 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_BootServer/software_simulator_BootServer_CaptureImage.wkf".
573
2006-09-20 16:52:30,375 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_BootServer/software_simulator_BootServer_DeleteImage.wkf". 2006-09-20 16:52:30,656 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_BootServer/software_simulator_BootServer_InstallGoldenMasterImage.wk f". 2006-09-20 16:52:30,953 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_BootServer/software_simulator_BootServer_InstallImage.wkf". 2006-09-20 16:52:31,484 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_BootServer/software_simulator_BootServer_InstallScriptedImage.wkf". 2006-09-20 16:52:31,703 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_BootServer/software_simulator_BootServer_ReplicateImage.wkf". 2006-09-20 16:52:32,141 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_BootServer/software_simulator_BootServer_RestoreBackupImage.wkf". 2006-09-20 16:52:32,344 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_HostingSoftwareResource/software_simulator_HostingEnvironment_Host.w kf". 2006-09-20 16:52:32,578 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_HostingSoftwareResource/software_simulator_HostingEnvironment_Host.w kf". 2006-09-20 16:52:39,344 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_HostingSoftwareResource/software_simulator_HostingEnvironment_Undepl oy.wkf". 2006-09-20 16:52:39,625 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_HostingSoftwareResource/software_simulator_HostingEnvironment_Undepl oy.wkf". 2006-09-20 16:52:39,859 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_SoftwareInstallable/software_simulator_SoftwareInstallable_Install.w kf". 2006-09-20 16:52:40,109 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_SoftwareInstallation/software_simulator_SoftwareInstallation_AddInst ance.wkf". 2006-09-20 16:52:40,297 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_SoftwareInstallation/software_simulator_SoftwareInstallation_Uninsta ll.wkf". 2006-09-20 16:52:40,547 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_SoftwareInstance/software_simulator_SoftwareInstance_RemoveInstance. wkf". 2006-09-20 16:52:40,750 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_SoftwareInstance/software_simulator_SoftwareInstance_Start.wkf". 2006-09-20 16:52:40,969 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_SoftwareInstance/software_simulator_SoftwareInstance_Stop.wkf". 2006-09-20 16:52:42,203 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_SoftwareModule/software_simulator_SoftwareModule_Install.wkf". 2006-09-20 16:52:42,781 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_SoftwareResource/software_simulator_SoftwareResource_UpdateDCM.wkf".
574
2006-09-20 16:52:44,625 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_SoftwareResource/software_simulator_SoftwareResource_Upgrade.wkf". 2006-09-20 16:52:44,812 INFO COPTDM011I Installing driver item "workflow/softwa re_simulator_postinstall.wkf". 2006-09-20 16:52:48,266 INFO COPTDM011I Installing driver item "workflow/test_S oftware_LDOs.wkf". 2006-09-20 16:52:48,484 INFO COPTDM011I Installing driver item "workflow/test_u secase_one.wkf". 2006-09-20 16:52:50,562 INFO COPTDM011I Installing driver item "workflow/test_u secase_three.wkf". 2006-09-20 16:52:52,391 INFO COPTDM011I Installing driver item "workflow/test_u secase_two.wkf". 2006-09-20 16:52:53,297 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_ClusterDomain/Software_Simulator_AdminDomain_AddNode.wkf". 2006-09-20 16:52:53,453 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_ClusterDomain/SoftwareSimulator_ClusterDomain_CreateNode.wkf". 2006-09-20 16:52:55,359 INFO COPTDM011I Installing driver item "workflow/Softwa reSimulator_ClusterDomain/Software_Simulator_ClusterDomain_Remove.wkf". 2006-09-20 16:52:55,703 INFO COPTDM012I Creating Device Model "SoftwareSimulato r_SoftwareInstallable". 2006-09-20 16:52:58,078 INFO COPTDM016I Creating the data center model object p roperties template for Device Model "SoftwareSimulator_SoftwareInstallable". 2006-09-20 16:52:58,125 INFO COPTDM017I Associating workflow "software_simulato r_SoftwareInstallable_Install" with Device Model "SoftwareSimulator_SoftwareInst allable". 2006-09-20 16:52:59,109 INFO COPTDM012I Creating Device Model "SoftwareSimulato r_SoftwareInstallation". 2006-09-20 16:52:59,516 INFO COPTDM016I Creating the data center model object p roperties template for Device Model "SoftwareSimulator_SoftwareInstallation". 2006-09-20 16:52:59,547 INFO COPTDM017I Associating workflow "software_simulato r_SoftwareInstallation_AddInstance" with Device Model "SoftwareSimulator_Softwar eInstallation". 2006-09-20 16:52:59,594 INFO COPTDM017I Associating workflow "software_simulato r_SoftwareInstallation_Uninstall" with Device Model "SoftwareSimulator_SoftwareI nstallation". 2006-09-20 16:52:59,703 INFO COPTDM012I Creating Device Model "SoftwareSimulato r_SoftwareInstance". 2006-09-20 16:52:59,891 INFO COPTDM016I Creating the data center model object p roperties template for Device Model "SoftwareSimulator_SoftwareInstance". 2006-09-20 16:52:59,953 INFO COPTDM017I Associating workflow "software_simulato r_SoftwareInstance_RemoveInstance" with Device Model "SoftwareSimulator_Software Instance". 2006-09-20 16:53:00,016 INFO COPTDM017I Associating workflow "software_simulato r_SoftwareInstance_Start" with Device Model "SoftwareSimulator_SoftwareInstance" .
575
2006-09-20 16:53:00,062 INFO COPTDM017I Associating workflow "software_simulato r_SoftwareInstance_Stop" with Device Model "SoftwareSimulator_SoftwareInstance". 2006-09-20 16:53:00,125 INFO COPTDM012I Creating Device Model "SoftwareSimulato r_SoftwareModule". 2006-09-20 16:53:00,875 INFO COPTDM016I Creating the data center model object p roperties template for Device Model "SoftwareSimulator_SoftwareModule". 2006-09-20 16:53:00,891 INFO COPTDM017I Associating workflow "software_simulato r_SoftwareModule_Install" with Device Model "SoftwareSimulator_SoftwareModule". 2006-09-20 16:53:00,984 INFO COPTDM012I Creating Device Model "SoftwareSimulato r_SoftwareResource". 2006-09-20 16:53:01,391 INFO COPTDM016I Creating the data center model object p roperties template for Device Model "SoftwareSimulator_SoftwareResource". 2006-09-20 16:53:01,406 INFO COPTDM017I Associating workflow "software_simulato r_SoftwareResource_UpdateDCM" with Device Model "SoftwareSimulator_SoftwareResou rce". 2006-09-20 16:53:01,453 INFO COPTDM017I Associating workflow "software_simulato r_SoftwareResource_Upgrade" with Device Model "SoftwareSimulator_SoftwareResourc e". 2006-09-20 16:53:01,500 INFO COPTDM017I Associating workflow "software_simulato r_HostingEnvironment_Host" with Device Model "SoftwareSimulator_SoftwareResource ". 2006-09-20 16:53:01,531 INFO COPTDM017I Associating workflow "software_simulato r_HostingEnvironment_Undeploy" with Device Model "SoftwareSimulator_SoftwareReso urce". 2006-09-20 16:53:01,594 INFO COPTDM012I Creating Device Model "SoftwareSimulato r_BootServer". 2006-09-20 16:53:01,734 INFO COPTDM016I Creating the data center model object p roperties template for Device Model "SoftwareSimulator_BootServer". 2006-09-20 16:53:01,750 INFO COPTDM017I Associating workflow "software_simulato r_BootServer_CaptureBackupImage" with Device Model "SoftwareSimulator_BootServer ". 2006-09-20 16:53:01,797 INFO COPTDM017I Associating workflow "software_simulato r_BootServer_CaptureImage" with Device Model "SoftwareSimulator_BootServer". 2006-09-20 16:53:01,844 INFO COPTDM017I Associating workflow "software_simulato r_BootServer_DeleteImage" with Device Model "SoftwareSimulator_BootServer". 2006-09-20 16:53:01,875 INFO COPTDM017I Associating workflow "software_simulato r_BootServer_InstallGoldenMasterImage" with Device Model "SoftwareSimulator_Boot Server". 2006-09-20 16:53:01,922 INFO COPTDM017I Associating workflow "software_simulato r_BootServer_InstallImage" with Device Model "SoftwareSimulator_BootServer". 2006-09-20 16:53:01,953 INFO COPTDM017I Associating workflow "software_simulato r_BootServer_InstallScriptedImage" with Device Model "SoftwareSimulator_BootServ er". 2006-09-20 16:53:02,000 INFO COPTDM017I Associating workflow "software_simulato
576
r_BootServer_ReplicateImage" with Device Model "SoftwareSimulator_BootServer". 2006-09-20 16:53:02,031 INFO COPTDM017I Associating workflow "software_simulato r_BootServer_RestoreBackupImage" with Device Model "SoftwareSimulator_BootServer ". 2006-09-20 16:53:02,094 INFO COPTDM012I Creating Device Model "SoftwareSimulato r_HostingSoftwareResource". 2006-09-20 16:53:02,234 INFO COPTDM016I Creating the data center model object p roperties template for Device Model "SoftwareSimulator_HostingSoftwareResource". 2006-09-20 16:53:02,250 INFO COPTDM017I Associating workflow "software_simulato r_HostingEnvironment_Host" with Device Model "SoftwareSimulator_HostingSoftwareR esource". 2006-09-20 16:53:02,297 INFO COPTDM017I Associating workflow "software_simulato r_HostingEnvironment_Undeploy" with Device Model "SoftwareSimulator_HostingSoftw areResource". 2006-09-20 16:53:02,422 INFO COPTDM012I Creating Device Model "SoftwareSimulato r_ClusterDomain". 2006-09-20 16:53:02,562 INFO COPTDM016I Creating the data center model object p roperties template for Device Model "SoftwareSimulator_ClusterDomain". 2006-09-20 16:53:02,594 INFO COPTDM017I Associating workflow "Software_Simulato r_AdminDomain_AddNode" with Device Model "SoftwareSimulator_ClusterDomain". 2006-09-20 16:53:02,625 INFO COPTDM017I Associating workflow "SoftwareSimulator _ClusterDomain_CreateNode" with Device Model "SoftwareSimulator_ClusterDomain". 2006-09-20 16:53:02,656 INFO COPTDM017I Associating workflow "Software_Simulato r_ClusterDomain_Remove" with Device Model "SoftwareSimulator_ClusterDomain". 2006-09-20 16:53:03,500 INFO COPTDM011I Installing driver item "xml/software_si mulator.xml". 2006-09-20 16:53:29,703 INFO installing driver plugin to C:\IBM\tivoli\tio/ecli pse/plugins/software_simulator 2006-09-20 16:53:32,031 INFO COPTDM005I TCDrivermanager was stopped. 2006-09-20 16:53:32,047 INFO Successfully installed: software_simulator The installation can be confirmed by using the following concocted command: $ ./tc-driver-manager.cmd listAllstr | grep software_simulator software_simulator 5.1.0.0.1767.38 installed
$
12.5.3 Retrieving information about DCM object definitions

The reteiveDetails.cmd script can be used to retrieve information about data center objects, by supplying a data center object id, as shown in Example 12-14 on page 578.
577
Example 12-14 Retrieving information about data center objects
Administrator@enterprise /cygdrive/c/IBM/tivoli/tio/tools $ ./retrieveDetails.cmd 2006-09-22 09:14:50,938 INFO log4j configureAndWatch is started with configuration file: C:\IBM\tivoli\tio/config/log4j-util.prop 2006-09-22 09:15:05,297 ERROR COPCOM425E Usage: retrieveDetails -i <deviceId> [i <deviceId>]*. Administrator@enterprise /cygdrive/c/IBM/tivoli/tio/tools $ ./retrieveDetails.cmd -i 2222 2006-09-22 09:15:50,703 INFO log4j configureAndWatch is started with configurat ion file: C:\IBM\tivoli\tio/config/log4j-util.prop 2006-09-22 09:16:22,906 INFO ID=[2222] 2006-09-22 09:16:22,906 INFO Name=[enterprise] 2006-09-22 09:16:22,906 INFO TypeId=[3] 2006-09-22 09:16:22,922 INFO TypeName=[server] 2006-09-22 09:16:22,922 INFO Locale=[en_US] 2006-09-22 09:16:22,938 INFO ================================================== =================
12.5.4 Importing data center model definitions

The data center model (DCM) represents the physical and logical assets under Tivoli Provisioning Manager V5.1 management, such as switches, load balancers, application software, and more. The DCM objects can be defined in an XML file, which can then be importing into your DCM using the xmlimport.cmd command. A sample XML file containing a sample DCM is located in <installation location>/xml/venice.xml. This file contains definitions for switches, load balancers, application software, and much more, and is shown in Appendix A, A sample data center model - venice.xml on page 757 for your reference. An example of importing the DCM object definition of one computer, is shown in Example 12-15.
Example 12-15 Importing a DCM Object XML file using xmlimport.cmd
Administrator@enterprise /cygdrive/c/IBM/tivoli/tio/tools $ cat ../xml/gees_test_server.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE datacenter PUBLIC "-//Think Dynamics//DTD XML Import//EN" "http://www.thinkdynamics.com/dtd/xmlimport.dtd" [
578
<!ENTITY resourcepoolconfig SYSTEM "http://www.thinkdynamics.com/dtd/res ourcepool.xml"> <!ENTITY dataacquisitionconfig SYSTEM "http://www.thinkdynamics.com/dtd/ dataacquisition.xml"> <!ENTITY simulator-cpu ' <dae-driver device="server" classname="com.thinkdynamics.kanaha.dataacquisit ionengine.NullDriver"/> <dae-signal name="cpu-utilization" device="server" metric="cpu-utilization" aggregation="average" filter="low-pass-filter"/> '> ]> <datacenter> <spare-pool name="Local Server" locale="en_US"> <server name="ghufrans_test_servero" locale="en_US"> <network-interface ipaddress="10.2.1.1.106" management=" true"></network-interface> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-na me> </access-domain-membership> </spare-pool> </datacenter> Administrator@enterprise /cygdrive/c/IBM/tivoli/tio/tools $ ./xmlimport.cmd file:../xml/gees_test_server.xml 2006-09-20 16:58:45,172 INFO log4j configureAndWatch is started with configuration file: C:\IBM\tivoli\tio/config/log4j-util.prop user.dir=[c:\IBM\tivoli\tio\tools] file:../xml/gees_test_server.xml 2006-09-20 16:59:30,312 INFO Import took 33593 millisecs
12.5.5 Exporting data center model (DCM) into an XML file

The data center model can be exported into an XML file, using the dcmexport.cmd, as shown in Example 12-16
579
Example 12-16 Exporting the DCM into an XML file
$ ./dcmexport.cmd -d geesExport.xml 2006-09-22 08:58:26,531 INFO log4j configureAndWatch is started with configuration file: C:\IBM\tivoli\tio/config/log4j-util.prop $ ls -al geesExport.xml -rwx------+ 1 Administrator Domain Users 1953635 Sep 22 09:04 geesExport.xml Note that the export file which has been created is a lot larger than the orgininal venice.xml which was inported earlier. Administrator@enterprise /cygdrive/c/IBM/tivoli/tio/tools $ ls -al ../xml/venice.xml ----rwx---+ 1 tioadmin Administrators 147184 Jul 24 19:53 ../xml/venice.xml
Please note that, an XML export is not a substitute for a database backup and restore and should not be used as a method for disaster recovery purposes. The dcmexport.cmd command enables you to export the entire data center model to an XML format that conforms to the rules defined in the xmlimport.dtd file. There are several uses for an exported XML file: You can use the exported XML file to obtain information about specific data center objects, and the necessary XML syntax to import similar data center objects. For troubleshooting purposes, you can send your data center configuration to IBM Tivoli Software Support for analysis.
12.5.6 Pinging the agent manager

As shown in Example 12-17, the ping-agent-manager.cmd script will retrieve the status of the agent manager process.
Example 12-17 Pinging the agent manager
$ ./ping-agent-manager.cmd 2006-09-20 17:01:33,938 INFO log4j configureAndWatch is started with configuration file: C:\IBM\tivoli\tio\config\log4j-util.prop 20-Sep-2006 17:01:47 com.tivoli.agentmgr.client.proxy.WSDLClient$AddressCacheItem tryConnect INFO: NOTE ==>Connected to host=enterprise.gee.local on port=9513
580
20-Sep-2006 17:01:47 com.tivoli.agentmgr.client.proxy.WSDLClient$AddressCacheItem directConnect INFO: Directly connected 20-Sep-2006 17:01:52 com.tivoli.agentmgr.client.proxy.WSDLClient$AddressCacheItem tryConnect INFO: NOTE ==>Connected to host=enterprise.gee.local on port=9511 20-Sep-2006 17:01:52 com.tivoli.agentmgr.client.proxy.WSDLClient$AddressCacheItem directConnect INFO: Directly connected
12.5.7 Checking the status of Tivoli Provisioning Manager V5.1 engines

As shown in Example 12-18, the tioStatus.cmd script will retrieve the status of the Tivoli Provisioning Manager V5.1 engines.
Example 12-18 Checking the status of Tivoli Provisioning Manager V5.1 engines
$ ./tioStatus.cmd Checking LWI status... ACTIVE SUCCESS 2006-09-20 17:03:18,203 INFO log4j configureAndWatch is started with configurat ion file: C:\IBM\tivoli\tio\config\log4j-util.prop 2006-09-20 17:03:18,797 INFO COPCOM421I The deployment engine is started. 2006-09-20 17:03:26,312 INFO COPCOM423I The policy engine is started. 2006-09-20 17:03:27,891 INFO COPCOM484I The agent shell server is started.
581
582
Part 2
Part
IBM Tivoli Provisioning Manager for Software V5.1

In this part we discuss IBM Tivoli Provisioning Manager for Software V5.1.
583
584
13
Chapter 13.
Migrating Tivoli Configuration Manager to Tivoli Provisioning Manager for Software

In this chapter we describe the functionalities provided by Tivoli Provisioning Manager for Software V5.1. The following topics are discussed in this chapter: Tivoli Provisioning Manager for Software overview on page 587 Tivoli Provisioning Manager for Software architecture on page 588 The migration process on page 591 Creating coexistence between Tivoli Management Framework and Tivoli Provisioning Manager for Software environments on page 610 Install Tivoli Provisioning Manager for Software V5.1 on page 612 Setup the Tivoli Management Framework environment on page 613 Map to the Tivoli Management Framework on page 620 Replicating the Tivoli Management Framework data on page 628
585
Tivoli Provisioning Manager for Software security overview on page 635 Configure user security settings on page 636 Upgrading to the Tivoli Provisioning Manager for Software environment on page 641 Tivoli Provisioning Manager for Software behind the scenes on page 646 Mapping of resources and concepts on page 664 Migration considerations on page 671
586
13.1 Tivoli Provisioning Manager for Software overview

Tivoli Provisioning Manager for Software has been developed to provide a migration path from Tivoli Management Framework to the new Scalable Distribution Infrastructure (SDI) based Operations, Administration, Maintenance and Provisioning infrastructure (OAMPi). It provides you with powerful tools for the management of system resources and IT assets, automating resource management processes at every stage of the life cycle of your managed systems. Tivoli Provisioning Manager for Software provides new capabilities to allow these operations to the users: Operating system installation Automated processes to manage your operating systems, including installing operating system software and capturing and restoring disk images. Software installation Automated processes to distribute and install software to all the managed endpoints in your enterprise. Software patching and upgrade management Easily deploy needed software patches to computers in your enterprise and check the software installation status of target computers. Compliance checking and remediation Determine whether the software and security configuration matches your desired set up. If systems are noncompliant, Tivoli Provisioning Manager for Software can make recommendations to fix them and in some cases automatically perform the recommended action. Hardware and software discovery Discover the presence and characteristics of system devices such as hard disks, CD-ROM drives, USB devices, and network printers. Discover the presence of software based on a software signature or registry entry. Tivoli Provisioning Manager for Software has a flexible architecture comprising a central provisioning server and optional local depot servers. It can be easily expanded to cover additional targets and new geographical locations. The dynamic content delivery service provides a centralized control for optimizing the use of resources when requests are received to upload or download files, for example during software distributions. A Web User Interface provides centralized access to all the tasks that can be performed with role-based security based on a directory (LDAP) server. An extensive set of predefined reports is provided, and facilities are available to define your own custom reports.
Chapter 13. Migrating Tivoli Configuration Manager to Tivoli Provisioning Manager for Software
587
The Web User Interface includes a Software Package Editor and an Activity Plan Editor, which are similar to those available in Tivoli Configuration Manager, enabling you to be up-and-running on software distribution and activity planning tasks with minimum disruption once you have moved to a coexistence environment.
13.2 Tivoli Provisioning Manager for Software architecture

Tivoli Provisioning Manager for Software provides a single point of control with a unified interface to handle both the new and the old infrastructure, the so called Web User Interface. A staged migration allows you to add the Scalable Distribution Infrastructure for Provisioning to Tivoli Configuration Manager to take advantage of the new functionalities of the Tivoli Provisioning Manager for Software. Refer to The migration process on page 591 for details about the migration. On the left side of the Figure 13-1 on page 589 you can see the 3 tier architecture provided by the Tivoli Management Framework; the first tier is represented by the Tivoli Management Region server, the second tier by the Tivoli Gateways, the third tier by the target of the operations, the Tivoli management agents, also known as endpoints. Comparing the Tivoli Management Framework infrastructure with the one introduced by Tivoli Provisioning Manager for Software, you can have two or more tiers based on the number of Device Management Servers (DMS) used in the infrastructure. The Home Office represent a two tier architecture with a single DMS, the Remote Office uses a Remote DMS that connects to the central DMS: in this case we have a three tier architecture.
588
Figure 13-1 Adding SOA for Provisioning to Tivoli Configuration Manager
Figure 13-2 on page 590 describes an architectural view of the Tivoli Provisioning Manager for Software. You can refer to Chapter 2, Product architecture planning and deployment best practices on page 33 for information on other components that are common for Tivoli Provisioning Manager for Software and Tivoli Provisioning Manager.
589
Figure 13-2 Tivoli Provisioning Manager for Software V5.1 architectural view
The infrastructure layer mainly contains: the definition of the communication interface to the SOA or TMF environment. for the TMF part, scope of this chapter, it implements: definition of the management operations (install, discovery and so on) implementation of the reporting thread that interfaces the Report Manager. Refer to section 13.13.2, Report Manager on page 652 for more details.
590
13.3 The migration process

As part of the migration process to Tivoli Provisioning Manager for Software V5.1 it is highly advisable to understand what features are available on each Tivoli Configuration Manager product version. Please read carefully the Release Notes available with each Tivoli Configuration Manager Fix Pack release. As you will see version upgrades are often called migrations. However a move to a new version of Tivoli Configuration Manager does involve in reality new code levels as new features or enhancements are included. In summary, Table 13-1 on page 591 presents Tivoli Configuration Manager V4.2.x evolution in terms of fix packs and product releases.
Table 13-1 Tivoli Configuration Manager 4.2.x evolution Tivoli Configuration Manager Release built on top of 4.1 plus specific patches 4.2 FP01 + enhancements + new Features 4.2.1 FP01 + enhancements 4.2.2 -SWD-001 + new features Tivoli Configuration Manager Release 4.2 4.2.1 4.2.2 4.2.3
The list and details of Tivoli Configuration Manager V4.1 and V4.2 specific patches are given in the redbook Deployment Guide Series: IBM Tivoli Configuration Manager, SG24-6454. In some cases it also requires the implementation of patches on each gateway that may lead to download the product specific methods to each endpoint. Special notice should be given to the components that may download methods on your software distribution or inventory targets. Method download may impact your whole installation as during the first software package profile or inventory profile distributions the method download will be triggered via the Framework dependency mechanism. In Figure 13-3 on page 592, you can graphically see how Tivoli Configuration Manager has evolved into Tivoli Provisioning Manager for Software 5.1.
591
2001
2002
2003
2004
2005
2006
TCM 4.2.1
Software Distribution 4.1
Pristine Mgr (PXE, RIS, ADS) Performance enhancements FP01 CIM like powerfull packaging (SPB / SIE) Async delivery mechanism inTMF (mdist2) TMF based RIM - multiplatform support Planner, CCM Reference Models, DataMoving, MSI, WebUI pull, mobile
TCM 4.2.1
Enhancements FP05 (Avoid concurrent logins)
TCM 4.2.1
Additional Enhs FP02
TCM 4.2.2
Enhancements FP03 (Avoid concurrent logins)
IBM Configuration Manager 4.1

Marketing Inv 4.0 + SWD 4.1
TCM 4.2.2
Enhancements in Web GW, (Nokia 9500), Activity Planner and DataMoving
TCM 4.2.3 FP02

Active Directory Integration Operating System Imaging (Rembo) License Manager extension
TCM 4.2
Inventory integration Pervasive Devices (DMS) Directory integration WebUI thru DMS and TAM Pkg: rpm, installp, pkgadd, hp Integrated installation (TII)
TCM 4.2.3 FixPack2

Native Patch Mgmt Nokia 9300 + 9500 support in Web GW Running Program before reboot in commit operations
TPM for SW 5.1

Scalable Deployment (content delivery service/depot) Enhance Operating System Imaging Software Compliance Preserve existing ITCM deployment (Acitivity Planner, Software Packages, Single point of Control) Device discovery, Patch Management
Figure 13-3 TCM to TPM for Software 5.1: Historical background
At the time this redbook was written the following Fix Packs were available: Tivoli Configuration Manager 4.2.1 Fix Pack 5 Tivoli Configuration Manager 4.2.2 Fix Pack 3 Tivoli Configuration Manager 4.2.3 Fix Pack 2 These Fix Packs that apply to Tivoli Configuration Manager, Version 4.2.1, Version 4.2.2 and Version 4.2.3 respectively were tested using Tivoli Management Framework, Version 4.1.1 Fix Pack 4, that contains the following interim fixes: 4.1.1-TMF-0058 interim fix for Tivoli Management Region servers, managed nodes, and gateways. 4.1.1-TMF-0055 interim fix for Mobile, JRIM (Java RDBMS Interface Module), JCF (Java Client Framework), MDist 2 GUI, and Tivoli Desktop for Windows. 4.1.1-LCF-0028 interim fix for endpoints.
592
It is important to notice that deploying the components of each Tivoli Configuration Manager depends greatly on the architecture you are planning to install.
13.3.1 Staged approach

The process described in this section, allows you to gradually migrate to the new Tivoli Provisioning Manager for Software infrastructure through a staged approach. Three stages can be defined, as detailed below: Stage1: Move one or more regions into a coexistence environment in which configuration management operations can be performed from the Tivoli Provisioning Manager server while maintaining the Tivoli Management Framework as distribution infrastructure. Stage 2: Work in a coexistence environment, managing Tivoli Management Regions from the provisioning server Web UI. Stage 3: Gradually roll out the new scalable software distribution infrastructure and deploy the Tivoli common agents. Table 13-2 on page 593 includes the description and the objectives of each stage.
Table 13-2 Upgrade strategy stages
Stage Stage 1
Description Tivoli Provisioning Manager for Software using the Tivoli Management Framework for distribution: Install and Migrate to Tivoli Provisioning Manager for Software V5.1
Objective Provide new capabilities without requiring migration to new infrastructure Preserve existing investment in Tivoli Management Framework infrastructure: profiles, activity plans, logical grouping
593
Stage Stage 2
Description Roll out new OAMPi distribution tiers and Tivoli common agent (TCA) endpoints: Pilot of the SOA based infrastructure
Objective Enable gradual introduction of new OAMPi managed endpoints
Stage 3
Migration of Tivoli Management Framework infrastructure to OAMPi, Tivoli management agent endpoints to TCA: Start real migration
Reuse or migrate core assets for continued use in Tivoli Provisioning Manager for Software V5.1 Migration of existing Tivoli management agent endpoints (TMA) to TCA ones
13.3.2 Stage 1: Moving to a coexistence environment

The first step in the move to Tivoli Provisioning Manager is to bring your existing Tivoli Management Framework infrastructure within the management of the Tivoli Provisioning Manager for Software server (will be referred as the Provisioning server). This stage allows a Tivoli Management Framework customer to drive the existing infrastructure through a more usable interface to accomplish operational tasks. Tivoli Management Framework objects and data are replicated in the provisioning server DCM, allowing the provisioning manager server to work with endpoints, software packages, profile managers and other objects that you defined in the Tivoli Management Framework environment. Installing the Tivoli Provisioning Manager for Software you can exploit: New usability capabilities new Web User Interface for existing Tivoli Configuration Manager V4.2.3 operations coexistence and imports profiles, inventory, software catalog etc. new reporting engine and reports Customer benefit
594
New Operations Graphical User Interface Easier endpoint installation/reinstallation Improved reporting Improved desktop management Support for new capabilities utilizing unchanged Tivoli Configuration Manager Tivoli Management Framework infrastructure The Tivoli Management Framework architecture of servers, repeaters, gateways, and source hosts continues to be used as the distribution infrastructure. Figure 13-4 on page 595 shows an example of a complex Tivoli Management Framework architecture that connects multiple Tivoli Management Regions using the hub and spoke infrastructure. In the later figures, showing the migration phases, the structure of the regions is simplified for readability, but both complex and simple architectures can be brought into the coexistence environment.
Figure 13-4 Hub and spoke architecture
Coexistence between Tivoli Configuration Manager for Software and Tivoli Management Framework depends on the definition of a bridge between the Tivoli Management Framework infrastructure and the Provisioning server.
595
You define the bridge by providing Tivoli Provisioning Manager for Software with information about the servers and databases in one or more Tivoli Management Regions. Figure 13-5 on page 596 shows a coexistence environment in which a Tivoli Management Region (TMR B) can be recognized and managed by a provisioning server. In this scenario, Tivoli region TMR A has not yet been added to the coexistence environment and can only be managed from the Tivoli desktop.
Figure 13-5 Coexistence between Tivoli Provisioning Manager for Software and Tivoli Management Framework topology
596
To bring a Tivoli region into a coexistence environment, as shown in Figure 13-5 on page 596 for TMR B, you must complete the following tasks: Provide the Provisioning server with information about Tivoli Configuration Manager servers and databases Using tasks on the Tivoli Provisioning Manager for Software server Web User Interface, you can create objects that represent the servers and databases that are configured in your Tivoli Management Framework environment. Options are available to create hub and spoke servers and their associated inventory and activity planner databases. You can complete the definition of your Tivoli Management Framework environment in stages. Each stage must include at least a hub server, any spoke servers that are related to it, and the associated databases. Refer to 13.8, Map to the Tivoli Management Framework on page 620 for detailed information about this task. Populate the Tivoli Provisioning Manager for Software DCM with replications of the objects related to the Tivoli Configuration Manager servers and databases When you have created the objects for at least one hub server and its associated spoke servers and databases, you can import information about Tivoli Configuration Manager objects that are associated with the servers and databases. Using the Provisioning server Web User Interface, you create a Discovery Configuration to replicate the information in the Tivoli Configuration Manager databases. When you run the Discovery task, the objects discovered in the database are imported into the Tivoli Provisioning Manager for Software DCM and mapped to Tivoli Provisioning Manager for Software object types. For example, a Software Distribution profile becomes a Software Definition and an Inventory profile becomes a Discovery Configuration. Refer to 13.9, Replicating the Tivoli Management Framework data on page 628 for detailed information about this task. Migrate user login credentials and role authorizations to the LDAP server In Tivoli Provisioning Manager for Software, authentication of user credentials and authorization of users to perform tasks on the Web User Interface are controlled by an LDAP server. This provides a centralized mechanism for access control that can be reused for other applications.
597
Supported LDAP server are IBM Tivoli Directory Server for both UNIX and Windows Operating Systems. In a Windows environment you can optionally use a Microsoft Active Directory installation. During the process of migration to a coexistence environment, details of user credentials and security roles that are stored in the Tivoli Management Framework database are extracted and, after checking and modification, are imported into the LDAP server. Profile manager and role objects from the Tivoli Management Framework database are replicated in the Tivoli Provisioning Manager for Software DCM as access groups and access permission groups. An access group defines the types of objects that can be worked with and the access permission groups that are associated an access group define groups of individual objects that can be worked with. Refer to 13.13, Tivoli Provisioning Manager for Software behind the scenes on page 646 for details about this task.
13.3.3 Stage 2: Working in a coexistence environment

When the bridge between Tivoli Management Framework and Tivoli Provisioning Manager for Software has been established by completing the steps described in 13.3.2, Stage 1: Moving to a coexistence environment on page 594 for one or more Tivoli Management Regions, you can manage the Tivoli endpoints from the Tivoli Provisioning Manager for Software Web User Interface. The objects that you require to continue software distribution, activity planning, and inventory tasks are available from the Tivoli Provisioning Manager for Software Web User Interface. You do need to redefine any inventory scan schedules that you had defined because the schedules are not replicated. In addition, you have access to an extensive set of reports that you can use to perform software compliance checks. Refer to Chapter 10, Reporting and notification on page 497 for more information on reporting with Tivoli Provisioning Manager for Software. Figure 13-6 on page 599 shows a mixed environment that includes a Tivoli Management Region that has not been brought into the coexistence environment (TMR A), a Tivoli Management Region that has been brought into the coexistence environment (TMR B), and computers where the Tivoli common agent is installed, which are within the Tivoli Provisioning Manager for Software scalable software distribution infrastructure. You might want to use this type of gradual approach to allow users to become accustomed to working on the Tivoli Provisioning Manager for Software Web User Interface.
598
Figure 13-6 Working on both Tivoli endpoints and Tivoli common agents
TMR A continues to be managed from the Tivoli desktop. TMR B is now managed from the Tivoli Provisioning Manager for software Web User Interface. Although the Tivoli Management Framework infrastructure is still in place, including the Tivoli desktop, you should avoid using the Tivoli desktop to manage the endpoints in TMR B because problems could occur if the same operation is performed from both the Tivoli Provisioning Manager for Software Web User Interface and the Tivoli Desktop.
599
Using the Web User Interface, you can define and perform software distribution, activity planning, and inventory operations that include the Tivoli management agents in TMR B and the Tivoli common agents that are connected to distribution server 1. Working in the coexistence environment, you can do the following: Perform software distributions, activity planning, and inventory tasks from the Tivoli Provisioning Manager for software interfaces The Web User Interface provides integrated access to many of the tasks that are available from the Tivoli desktop, and a more complete set of software distribution tasks is available if you have installed the eclipse plug-in Software Package Editor. The names assigned to tasks within Tivoli Provisioning Manager for Software, both on the Web User Interface and the Software Package Editor, differ from those used on the Tivoli desktop. For example, Software Distribution become Software Management, and Inventory becomes Discovery. Define target lists that include computers that are running the Tivoli common agent and computers that are running the Tivoli management agent In a mixed environment, operations such as software distributions and inventory scans can include targets that have either of the supported agents installed. For example, in the scenario shown in Figure 13-6 on page 599 a list of targets for a software distribution could include endpoints in TMR B and the computers running the Tivoli common agent that are attached to distribution server 1. Use the extensive reporting capabilities of the Web User Interface Reports allow you to retrieve current information about data center inventory, activity, and system compliance Tivoli Provisioning Manager for Software reporting functionality includes: Numerous predefined reports. A Web-based query builder, which allows you to easily customize existing reports or create new reports. Easier access to information in the DCM through more than 40 high-performance views. Easier sharing of report definitions through enhanced import and export capabilities in the Web User Interface. Charts and graphs.
600
The ability to schedule reports to run at a later time including repeating intervals. E-mail report distribution and notification. Integration with third-party reporting software. When moving to the coexistence environment, part of the Tivoli Management Framework queries are replicated and are available from the reports menu on the Web User Interface. Perform software compliance checks and automatically resolve out-of-compliance situations Software compliance checks are used to check whether certain software applications should be on a computer or not. You can create software compliance checks for software groups, software products, software patches, and software stacks. When the compliance check runs it compares the compliant state that has been defined against the actual state of computers retrieved by the most recent inventory scan. If it discovers out-of-compliance situations on computers, it generates recommendations for bringing the computers to a compliant state. You can review out-of-compliance situations recommendations for remediation. For more information on compliance and remediation, refer to Chapter 7, Compliance management on page 345. If the software that has caused the out-of-compliance situation has an associated software template, the recommended installation, upgrade, or uninstallation can be performed automatically. A software template identifies a software resource and its associated configuration details that can be used to create a software resource on a managed computer.
13.3.4 Stage 3: Moving to a full Tivoli Provisioning Manager for Software implementation
After you have moved to the coexistence environment, make a plan to gradually migrate to a full implementation of Tivoli Provisioning Manager for Software. When you upgrade to a full implementation, you can take advantage of all the functionalities available from the Tivoli Provisioning Manager for Software Web User Interface, from the scalable software distribution infrastructure, and from the Tivoli common agent, for example: Security Compliance management and remediation
601
Security compliance checks can be used to check for a variety of security issues such as whether appropriate passwords or improper settings have been set. There are a series of predefined security compliance checks for security requirements that are generally applicable. For example, you can check for the existence of hard disk and power-on passwords or for the values of firewall settings. You can also define your own security checks to cover situations that are not included in the predefined list. When a security check is run against a group of computers, it identifies out-of-compliance situations which you can then act to resolve. Optimized use of distribution resources A dynamic content delivery service management center that is installed on the Tivoli Provisioning Manager for Software server and maintains a data set of record for the bulk data to be distributed to the depots. The dynamic content delivery service management server implements a distribution policy that sends bulk data to some or all of the distributed depot servers in advance of when it is needed. A number of regional distribution servers that ensure the communication between the management server and the clients installed on the endpoints. The distribution servers communicate to the management server to get data requested by agents. Clients installed as subagents on all the managed systems or endpoints at the regional branch request to download files from distribution servers or from other clients. Refer to Chapter 5, Software management in Tivoli Provisioning Manager V5.1 on page 235 for more information on software management in Tivoli Provisioning Manager V5.1. If you are running in a multi-homed environment, made of a hub-spoke architecture, to minimize disruption plan to migrate one region at a time, ensuring that all migration-related problems have been resolved before starting the migration of the next region.
602
Figure 13-7 Moving to a Tivoli Provisioning Manager environment
Figure 13-7 on page 603 shows an environment in which the gradual migration process has started. The computers that were in Region TMR B now have the Tivoli common agent installed and a distribution server has been deployed in their geographical location. The deployment of the Tivoli common agent is performed from the Tivoli Provisioning Manager Web User Interface using an automation package which
603
distributes the package to the Tivoli endpoints using the Tivoli Management Framework infrastructure. Once the Tivoli common agents are installed, they connect to the provisioning server and the Tivoli management agents that are still installed can no longer be used for operations performed from the provisioning server. Distribution servers provide a geographically distributed set of depots to which bulk data can be sent. They are deployed from the Web User Interface. In some ways, they are the equivalent of gateways and during the migration process, you could choose to deploy a distribution server for each gateway you had deployed in the Tivoli Management Framework infrastructure. Refer to Chapter 5, Software management in Tivoli Provisioning Manager V5.1 on page 235 for more information on distribution servers.
13.3.5 Migration complete: Working in parallel with the Tivoli Management Framework
Following the deployment of the Tivoli common agent to the managed computers in a region, management of the computers from the provisioning server is performed through the scalable software distribution infrastructure to the Tivoli common agent. The Tivoli Management Framework infrastructure and Tivoli management agents are no longer used by the Provisioning server. You might decide to keep the Tivoli management agents on the computers where the Tivoli common agent has been installed, as shown in Figure 13-8 on page 605.
604
Figure 13-8 Computers running both the Tivoli common agent and the Tivoli management agent
In this scenario, all software distribution, activity planning, and inventory tasks are performed from the Provisioning server, using the scalable software distribution infrastructure and the Tivoli common agent. The Tivoli Management Framework and the Tivoli management agent are retained to support other Tivoli Management Framework applications, for example Tivoli Remote Control.
605
Note: It is the intention of IBM to provide a Remote Control product that does not require Tivoli Framework. You could also use it for some Tivoli Configuration Manager functionality that is supported by Tivoli Provisioning Manager for Software, for example Data Moving and support for software distribution to mobile endpoints.
13.4 Some typical migration scenarios

The following are real life scenarios we may encounter when migrating Tivoli Configuration Manager environments to Tivoli Provisioning Manager for Software V5.1.
13.4.1 Central managed nodes and gateways

In this case the Tivoli gateways are located in a central data centre. The endpoints connect to their relevant gateway(s) via the endpoint login policies traversing the WAN. Here you may find two cases: a. Low bandwidth In this case links to the data centre are around 64 kbps. b. Enough bandwidth Typical case when managed endpoints are connected via fast links to a data centre. In both cases, the Tivoli Configuration Manager Framework needs to be tuned in order to avoid endpoint login storms. See Figure 13-9 on page 607.
606
RDBMS
TMR Server
Gateways
WAN
TMA TMA TMA TMA TMA
TMA TMA TMA TMA TMA
TMA TMA TMA TMA TMA
TMA TMA TMA TMA TMA
Figure 13-9 Central gateways / managed nodes
13.4.2 Distributed managed nodes and gateways

In the case of distributed managed nodes and gateways, there are also two different scenarios: a. Low bandwidth In this case links to the data centre are around 64 kbps. However the gateways or Managed nodes are located on each branch office or remote building. b. Enough bandwidth Typical case when managed endpoints are connected via fast links to a data centre. However the gateways or managed nodes are located on each branch office or remote building. Typically in this case applying maintenance patch to a large number of managed nodes or gateways is costly in terms of effort and bandwidth. See Figure 13-10 on page 608.
607
TMR Server RDBMS Source Host
TPM for Software Server 5.1 RDBMS
Gateways
File Replication Server
WAN
TCA TCA TCA TCA TCA
TMA TMA TMA TMA TMA
TMA TMA TMA TMA TMA
TMA TMA TMA TMA TMA
Figure 13-10 Distributed gateways / managed nodes
Nevertheless there are other considerations you need to bear in mind when migrating to Tivoli Provisioning Manager for Software V5.1. Current Tivoli Configuration Manager software levels installed As the integration of Tivoli Provisioning Manager for Software and Tivoli Configuration Manager requires Tivoli Configuration Manager V4.2.3 FixPack 2, you need to perform an assessment to find out the list of patches and/or fix packs you may need to install to upgrade your environment. Tivoli Configuration Manager architecture When the number of managed nodes and gateways are centrally located we may think about upgrading your Tivoli Configuration Manager environment to version 4.2.3 Fix Pack2. Later on you can then run the Tivoli Configuration Manager Infrastructure Discovery. See Figure 13-11 on page 609.
608
TMR Server TCM 4.x RDBMS
Source Host
WAN
CDS Depot Gateway/Depot

TMA TMA TMA TMA TMA TMA TMA TMA TMA TMA TMA TMA TMA TMA TMA
TCA TCA TCA TCA TCA
Gateway/Depot
Figure 13-11 TCM integrated with TPM for Software using central gateways
Issues when migrating large numbers of gateways

When you have an Tivoli Configuration Manager infrastructure that spans over a large network using hundreds of gateways (Typically in a hub-spoke configuration) you need to consider: Need to traverse the WAN with slow links Involved effort to upgrade your Tivoli Configuration Manager gateways to Tivoli Configuration Manager V4.2.3 FixPack2 In such a case, you can maintain a parallel between our Tivoli Configuration Manager environment and our Tivoli Provisioning Manager environment. You should proceed to install the dynamic content delivery service server and depots on each branch office server. You would also need the to install the Tivoli common agent agents using Tivoli Configuration Manager software package blocks. See Figure 13-12 on page 610.
609
TMR SERVER TCM 4.x RDBMS
Source Host
WAN
CDS Depot Gateway/Depot

TMA TMA TMA TMA TMA
TCA TCA TCA TCA TCA
Gateway/Depot
TMA TMA TMA TMA TMA
Gateway/Depot
TMA TMA TMA TMA TMA
Figure 13-12 TPM for Software parallel to TCM Infrastructure
13.5 Creating coexistence between Tivoli Management Framework and Tivoli Provisioning Manager for Software environments
This section describes the actions you must perform to create coexistence between Tivoli Management Framework and Tivoli Provisioning Manager for Software environments. In this way, using the Tivoli Provisioning Manager for Software Web User Interface you have a single point of control to manage the existing resources on both the old targets and the new targets. To realize this coexistence, you need to set up your environment first by performing the following tasks that are described later on: 1. Install Tivoli Provisioning Manager for Software V5.1 using the Topology Installer Launcher.
610
Note: Since the installation of TIL based installation of Tivoli Provisioning Manager V5.1 and Tivoli Provisioning Manager for Software V5.1 is identical, we will not repeat the installation steps here. You can refer to Chapter 3, Installing Tivoli Provisioning Manager V5.1 on page 61 for detailed information about the installation steps. 2. Setup the Tivoli Management Framework environment as described in section 13.7, Setup the Tivoli Management Framework environment on page 613. 3. Map to the Tivoli Management Framework as described in section 13.8, Map to the Tivoli Management Framework on page 620. 4. Replicate Tivoli Management Framework data as described in section 13.9, Replicating the Tivoli Management Framework data on page 628. 5. This step replicates the existing Tivoli Management Framework objects into the Tivoli Provisioning Manager for Software DCM database. 6. The Tivoli Management Framework databases remain the same after the replica. 7. Configure user security settings as described in section 13.11, Configure user security settings on page 636. At this point you can manage the Tivoli Management Framework objects from the Tivoli Provisioning Manager for Software Web User Interface.
13.5.1 Environment used for the integration

The diagram in Figure 13-13 on page 612 shows the lab environment that has been used to perform the integration described in this chapter.
611
Existing TMR
TMR Server GW milan-gw LCF milan-ep AIX 9.3.5.57
LCF belfast-ep TPM Cairo Win2003 9.3.5.56 TMF Bridge GW prov003-gw LCF prov003-ep Win2003 9.3.5.22 AIX 9.3.5.53
LCF rome-ep AIX 9.3.5.54
LCF elpaso-ep AIX 9.3.5.73
LCF prov001-ep Win2003 9.3.5.39
LCF prov002-ep Win2003 9.3.5.20
Figure 13-13 Integration lab environment diagram
13.6 Install Tivoli Provisioning Manager for Software V5.1

The Tivoli Provisioning Manager for Software V5.1 installation is exactly the same as the classic Tivoli Provisioning Manager V5.1. You can refer to Chapter 3, Installing Tivoli Provisioning Manager V5.1 on page 61 for more information. There are some differences between the two product, for example: Some of the functionalities that comes with Tivoli Provisioning Manager V5.1 are not available to Tivoli Provisioning Manager for Software V5.1. The bridging functionality between Tivoli Management Framework and Tivoli Provisioning Manager for Software V5.1 only comes with this product. Important: This bridging functionality will be incorporated into Tivoli Provisioning Manager V5.1 in a future fix pack.
612
You must install Tivoli Provisioning Manager for Software V5.1 using the Topology Installer Launcher on Windows platforms. Depending on the operating systems, ensure you have the following databases installed:
Table 13-3 Operating systems and supported databases Operating System Windows, AIX, Linux Sun Tivoli Provisioning Manager for Software IBM DB2 Oracle
Important: The Tivoli Management Framework database should be the same as the Tivoli Provisioning Manager for Software database. Actually the only Operating System that supports Oracle as the relational database is Sun. You can integrate the Tivoli Provisioning Manager for Software V5.1 on a Sun environment running with Oracle and a Tivoli Management Framework environment that uses an Oracle database for storing the data. A mix of IBM DB2 and Oracle for Tivoli Configuration Manager and Tivoli Provisioning Manager for Software databases is not supported.
13.7 Setup the Tivoli Management Framework environment

In this section we describe all the steps to integrate Tivoli Provisioning Manager for Software with the Tivoli Management Framework environment. To take advantage of the support provided for the Tivoli Management Framework setup and data replication to Tivoli Provisioning Manager for Software, ensure that your Tivoli Configuration Manager environment is at the required level and has the required compatibility Interim Fixes installed. Refer to section 13.7.2, Installing required Interim Fixes on the Tivoli Management Framework environment. on page 616.
13.7.1 Tivoli Configuration Manager V4.2.3

If you have an existing installation of Tivoli Configuration Manager V4.2.3, the Tivoli Provisioning Manager for Software V5.1 requires Tivoli Configuration Manager V4.2.3 Fix Pack 02.
613
Tivoli Configuration Manager V4.2.3 Fix Pack 02

To confirm that fix pack 02 is installed in the Inventory and Software Distribution components, follows the Example 13-1 on page 614.
Example 13-1 Checking for installation of Tivoli Configuration Manager V4.2.3 Fix Pack 02
Log on to the system and set the tivoli environment: [root@milan][/]-> . /etc/Tivoli/setup_env.sh Check the output of the command wlsinst -P | grep 4.2.3. If the Fix Pack 02 is installed you will see an output like the following: Activity Planner, Version 4.2.3, Fix Pack 4.2.3-APM-FP02 (U806551 2006/06) Change Manager, Version 4.2.3, Fix Pack 4.2.3-CCM-FP02 (U806551 2006/06) Scalable Collection Service, Version 4.2.3, Fix Pack 4.2.3-CLL-FP02 (U806551 - 2006/06) Inventory, Version 4.2.3, Fix Pack 4.2.3-INV-FP02 (U806551 - 2006/06) Inventory Gateway, Version 4.2.3, Fix Pack 4.2.3-INVGW-FP02 (U806551 2006/06) Software Distribution Gateway, Version 4.2.3, Fix Pack 4.2.3-SWDGW-FP02 (U806551 - 2006/06) Software Distribution Software Package Editor, Version 4.2.3, Fix Pack 4.2.3-SWDJPS-FP02 (U806551 - 2006/06) Software Distribution, Version 4.2.3, Fix Pack 4.2.3-SWDSRV-FP02 (U806551 - 2006/06) Check the output of the command wlookup -ar PatchInfo | grep 4.2.3. If the Fix Pack 02 is installed you will see an output like the following: 4.2.3-APM-FP02 1536006190.1.899#TMF_Install::PatchInfo# 4.2.3-CCM-FP02 1536006190.1.900#TMF_Install::PatchInfo# 4.2.3-CLL-FP02 1536006190.1.922#TMF_Install::PatchInfo# 4.2.3-INV-FP02 1536006190.1.901#TMF_Install::PatchInfo# 4.2.3-INVGW-FP02 1536006190.1.921#TMF_Install::PatchInfo# 4.2.3-SWDGW-FP02 1536006190.1.897#TMF_Install::PatchInfo# 4.2.3-SWDJPS-FP02 1536006190.1.898#TMF_Install::PatchInfo# 4.2.3-SWDSRV-FP02 1536006190.1.894#TMF_Install::PatchInfo# TMF_DDC_4.2.3 1536006190.1.606#TMF_Install::PatchInfo#
614
Validating Inventory scripts

After confirming that Tivoli Configuration Manager V4.2.3 Fix Pack 02 is installed, you must confirm that the inventory schema scripts included with Fix Pack 02 have been executed. These scripts must be run in order for Tivoli Configuration Manager V4.2.3 to work with Tivoli Provisioning Manager for Software. You have three options for validating that Fix Pack 02 inventory schema scripts were run: Use the Tivoli Management Framework Query Facility in the Tivoli Desktop. Use inv_query RDBMS Interface Module (RIM) to perform RIM extended retrieve option. Perform a db2 or oracle sql query on the Inventory database In the Example 13-2 on page 615 we use a db2 sql query against the inv_db database.
Example 13-2 Validating Inventory scripts for Tivoli Configuration Manager V4.2.3 Fix Pack 02
Log on to the system and set the tivoli environment: [root@milan][/]-> . /etc/Tivoli/setup_env.sh Run the wgetrim inv_query command to find the information regarding the RDBMS User and the Database ID: [root@milan][/etc/Tivoli]-> wgetrim inv_query RIM Host: milan RDBMS User: db2inst1 RDBMS Vendor: DB2 Database ID: inv_db Database Home: /home/db2inst1/sqllib Server ID: tcpip Instance Home: ~db2inst1 Instance Name: db2inst1 You can now use these data to connect to the inv_db database after su as db2inst1. [root@milan][/]-> su - db2inst1 [db2inst1@milan][/home/db2inst1]-> db2 connect to inv_db user db2inst1 Enter current password for db2inst1: Database Connection Information
615
Database server SQL authorization ID Local database alias
= DB2/6000 8.2.4 = DB2INST1 = INV_DB
From the db2 prompt run the following select: db2 => select * from schema_vers; You get an output like the following:
DATABASE_VERS ------------CM 4.2.3 CM 4.2.3 installation CM 4.2.3 installation CM 4.2.3 installation, CM 4.2.3 installation, SCHEMA_CHG_TIME -------------------------2006-08-22-16.26.16.270186 2006-08-30-18.47.34.452586 SCHEMA_CHG_TYPE --------------INSTALL PATCH CHG_FILE_NAME ----------------------------inv_db2_schema.sql New 4.2.3 inv_db2_schema_423_FP01.sql inv_db2_schema_423_FP02.sql CHG_DESC -------------------------------installation, GA level FP01 applied to existing FP02 applied to existing
2006-08-30-18.54.00.410347 PATCH 2006-08-30-18.54.51.554885 PATCH enable history 2006-08-30-18.55.00.333925 PATCH enable history
h_inv_db2_schema_423_FP01.sql FP01 applied to existing h_inv_db2_schema_423_FP02.sql FP02 applied to existing
5 record(s) selected,
13.7.2 Installing required Interim Fixes on the Tivoli Management Framework environment.
Two Interim Fixes are required on the Tivoli Management Framework environment for the Tivoli Provisioning Manager for Software, Tivoli Configuration Manager coexistence: Software Distribution, Version 4.2.3, Interim Fix 4.2.3.2-TIV-SWDSRV-IF0002 Inventory Server, Version 4.2.3, Interim Fix 4.2.3.2-TIV-INV-IF0002 These Interim Fixes are part of 4.2.3.2-TIV-TCM-IF0002 that you can download from this url: ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_4.2. 3.2/4.2.3.2-TIV-TCM-IF0002 They do not need to be installed in a specific order. Software Distribution, Version 4.2.3, Interim Fix 4.2.3.2-TIV-SWDSRV-IF0002 This is an Interim Fix for the Software Distribution Server and must be applied on any Tivoli server (also known as Tivoli Management Region server) and managed node where the Software Distribution Server component is installed.
616
To install this Interim Fix you can either use the Tivoli Desktop or the wpatch command line interface. Once extracted the package for 4.2.3.2-TIV-TCM-IF0002, the source directory for this patch is: 4.2.3.2-TIV-TCM-IF0002_dir/images/SWD where 4.2.3.2-TIV-TCM-IF0002_dir is the root directory where you extracted the Interim Fix. Once installed you can use the commands shown in Example 13-3 on page 617 to check for the correct Interim Fix installation.
Example 13-3 Software Distribution, Version 4.2.3, Interim 4.2.3.2-TIV-SWDSRV-IF0002
Run the following commands to make sure the Interim Fix has been successfully installed and registered: [root@milan][/]-> wlsinst -P | grep 4.2.3.2-TIV-SWDSRV-IF0002 Software Distribution, Version 4.2.3, Interim Fix 4.2.3.2-TIV-SWDSRV-IF0002 [root@milan][/]-> wlookup -ar PatchInfo | grep 4.2.3.2-TIV-SWDSRV-IF0002 4.2.3.2-TIV-SWDSRV-IF0002 1536006190.1.1062#TMF_Install::PatchInfo#
rep_vendor.sql script
This Interim Fix installs a new component, called Report Manager. It requires some tables to be generated in the inv_db database. To accomplish this run the rep_vendor.sql script where vendor can be db2 or oracle. The scripts are located in the following path: $BINDIR/TME/ReportManager for UNIX %BINDIR%\TME\ReportManager for Windows The Example 13-4 on page 617 shows the execution of the rep_db2.sql script:
Example 13-4 rep_db2.sql script execution
[root@milan][/]-> . /etc/Tivoli/setup_env.sh Run the wgetrim inv_query command to find the information regarding the RDBMS User and the Database ID:
617
[root@milan][/etc/Tivoli]-> wgetrim inv_query RIM Host: milan RDBMS User: db2inst1 RDBMS Vendor: DB2 Database ID: inv_db Database Home: /home/db2inst1/sqllib Server ID: tcpip Instance Home: ~db2inst1 Instance Name: db2inst1 You can now use these data to connect to the inv_db database after su as db2inst1. [root@milan][/]-> su - db2inst1 [db2inst1@milan][/home/db2inst1]-> db2 connect to inv_db user db2inst1 Enter current password for db2inst1: Database Connection Information Database server SQL authorization ID Local database alias = DB2/6000 8.2.4 = DB2INST1 = INV_DB
The rep_db2.sql script is located in $BINDIR/TME/ReportManager directory on the TMR server machine. [db2inst1@milan][/Tivoli/usr/local/Tivoli/bin/aix4-r1/TME/ReportManager ]-> db2 -t -f rep_db2.sql DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0204N "DB2INST1.REP_MANAGER" is an undefined name. SQLSTATE=42704 DB20000I The SQL command completed successfully.
DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0204N "DB2INST1.REPMANAGER_TR" is an undefined name. SQLSTATE=42704 DB20000I The SQL command completed successfully.
618
The first error message, DB21034E is normal because the sql script execute a drop command before the create command, so you will see this message the first time the script is executed.
For an Oracle database, the command to execute the script is the following: sqlplus sys/sys_password@server as sysdba @rep_ora.sql The above command logs on as sysdba database user to update the database with the tables required by the Report Manager. The sys_password represents the password of the sys database user, and server is the name of the Oracle server. Refer to Report Manager on page 652 for more details about this new component introduced by the above Interim Fix. The same Interim Fix provides another functionality on the source hosts, which is used by the implementation of the FileRepository.GetFile and FileRepository.PutFile logical device operations (LDO) on the Tivoli Management Framework source hosts. The scenarios where these functions are used are the following: Software Package Editor download of an SPB from a migrated Tivoli Management Framework file repository (Source Host) getFile Software Package Editor upload of a new SPB to a migrated Tivoli Management Framework file repository (Source Host) putFile Deployment of a migrated SPB to OAMPi targets getFile Deployment of a new SPB (created on Tivoli Provisioning Manager) to Tivoli Management Framework endpoints putFile Inventory Server, Version 4.2.3, Interim Fix 4.2.3.2-TIV-INV-IF0002 This is an Interim Fix for the Inventory Server and must be installed on the Inventory Server machine. To install this Interim Fix you can either use the Tivoli Desktop or the wpatch commad line interface. Once extracted the package for 4.2.3.2-TIV-TCM-IF0002, the source directory for this patch is: 4.2.3.2-TIV-TCM-IF0002_dir/images/INVENTORY where 4.2.3.2-TIV-TCM-IF0002_dir is the root directory where you extracted the Interim Fix.
619
Once installed you can use the commands shown in Figure 13-5 on page 620 to check for the correct Interim Fix installation.
Example 13-5 Inventory Server, Version 4.2.3, Interim Fix 4.2.3.2-TIV-INV-IF0002
Run the following commands to make sure the Interim Fix has been successfully installed and registered: [root@milan][/]-> wlsinst -P | grep 4.2.3.2-TIV-INV-IF0002 Inventory, Version 4.2.3, Interim Fix 4.2.3.2-TIV-INV-IF0002 [root@milan][/]-> wlookup -ar PatchInfo | grep 4.2.3.2-TIV-INV-IF0002 4.2.3.2-TIV-INV-IF0002 1536006190.1.1068#TMF_Install::PatchInfo#
13.8 Map to the Tivoli Management Framework

To be able to manage the Tivoli Management Framework objects from the Tivoli Provisioning Manager for Software Web User Interface, you need to add the required Tivoli Management Framework infrastructure to Tivoli Provisioning Manager for Software, and then replicate the existing Tivoli Management Framework objects into the Tivoli Provisioning Manager for Software DCM.
13.8.1 Adding the infrastructure

Using the Tivoli Provisioning Manager for Software Web User Interface, you need to point to the hubs, spokes, and databases for your Tivoli Management Framework infrastructure. Note: The minimum configuration required is a Tivoli Configuration Manager Inventory database and a single hub that is the configuration used for this redbook. Adding the hubs, spokes, and databases from the existing Tivoli Management Region Framework to the Tivoli Provisioning Manager for Software DCM creates on the fly the following XML file: %TIO_HOME%\config\tcm.xml on Windows platforms or $TIO_HOME/config/tcm.xml on UNIX platforms. In the example described in this Redbook, we added a Tivoli Management Environment infrastructure based on an AIX Tivoli Management Region server
620
using an IBM DB2 relational database to store Inventory and Software Distribution data. To add the Tivoli Management Framework infrastructure you should follow the below steps.
Add a database
The first step is to add a database definition on the Tivoli Provisioning Manager for Software DCM that points to the existing inv_db database on the Tivoli Management Environment infrastructure. 1. In the navigation pane, click Inventory Infrastructure Management Tivoli Management Framework. The Manage Tivoli Management Framework page is displayed 2. Click Edit Add Database The Add Database dialog is displayed.
Figure 13-14 Add Database dialog
Specify these information: In the Host Name field, type the fully qualified host name of the database server. In the Database type list, click DB2 Universal Database. The port field is optional and in a different color. The default port IBM DB2 uses for a single instance database is 50000. If you want to make sure the
621
port used, refers to Checking the default DB2 port on page 622. For this database we did not specify any value. In the Database version field, type the database version, for example, 8.2. In the Database name field, type the inventory database name, for example inv_db. In the User and Password fields, type the database user name and password. Click Save. Repeat step 2 with all its substeps for each Tivoli Management Region that includes a configured Tivoli Configuration Manager Inventory database. In case the database used for your infrastructure is Oracle, the selection will be Oracle Database. Note: If the Inventory database is shared among different Tivoli Management Regions, you should create one unique record for the Inventory database and relate it to every associated Tivoli Management Region.
Checking the default DB2 port

If you do not specify a different port at installation time, the IBM DB2 will use the default of 50000. If you have multiple instances on you IBM DB2 server, you must define different ports. To check the port used your IBM DB2 installation, you can refer to Example 13-6 on page 622:
Example 13-6 Checking the default port used by IBM DB2
Switch to your instance owner user, in our example db2inst1: [root@milan][/]-> su - db2inst1 Run the below command lo locate the TCP/IP service name associated to IBM DB2: [db2inst1@milan][/home/db2inst1]-> db2 get dbm cfg | grep -i svc TCP/IP Service name (SVCENAME) = db2c_db2inst1 Grep for this service name in the /etc/services file:
622
[root@milan][/etc]-> grep db2c_db2inst1 services db2c_db2inst1 50000/tcp The file on Windows Operating Systems is the following: %SystemRoot%\system32\drivers\etc\services
Add a hub
The next step is to add a hub definition on the Tivoli Provisioning Manager for Software DCM that points to the existing hub on the Tivoli Management Framework infrastructure. 1. Click Edit Add Hub. The Add Hub dialog is displayed.
Figure 13-15 Add Hub dialog
Specify these information: In the Host Name field, type the fully qualified host name of the hub. In the User and Password fields, type the user name with administrative rights of the hub server, and the password, respectively. Note: The user name for the Hub is case-sensitive Select the Associated database for the hub. 2. Click Save.
623
Add a spoke
This step must be executed in case you have spoke Tivoli Management Region servers to add the spoke definition to the Tivoli Provisioning Manager for Software DCM. 1. Click Edit Add Spoke. The Add Spoke dialog is displayed. Specify these information: In the Host Name field, type the fully qualified host name of the spoke. In the User and Password fields, type the user name with administrative rights of the spoke server, and the password, respectively. Note: The user name for the Spoke is case-sensitive Select the Associated database for the inventory database associated with this Tivoli Management Region. 2. Click Save. Repeat these steps with all its substeps for as many Spokes you have in the existing Tivoli Management Region Framework infrastructure.
Add an activity plan database

The last step is to add an activity plan database definition on the Tivoli Provisioning Manager for Software DCM that points to the existing planner database on the Tivoli Management Environment infrastructure. 1. In the navigation pane, click Inventory Infrastructure Management Tivoli Management Framework. The Manage Tivoli Management Framework page is displayed 2. Click Edit Add Activity Plan Database The Add Database dialog is displayed.
624
Figure 13-16 Add Activity Plan Database dialog
Specify these information: In the Host Name field, type the fully qualified host name of the database server. In the Database type list, click DB2 Universal Database. The port field is optional and in a different color. The default port IBM DB2 uses for a single instance database is 50000. If you want to make sure the port used, refers to Checking the default DB2 port on page 622. For this database we specified a value of 50000. In the Database version field, type the database version, for example, 8.2. In the Database name field, type the inventory database name, for example planner. In the User and Password fields, type the database user name and password. Select the Associated server for the Activity Plan database 3. Click Save. Repeat step 2 with all its substeps for each Tivoli Management Region that includes a configured Tivoli Configuration Manager Activity Plan database.
625
In case the database used for your infrastructure is Oracle, the selection will be Oracle Database. Note: If the activity plan database is shared among different Tivoli Management Regions, you should create one unique record for the activity plan database and relate it to every associated Tivoli Management Region.
13.8.2 tcm.xml file

All the above described actions, result in the creation of a XML file called tcm.xml. This file is maintained in the following path on the Tivoli Provisioning Manager server: $TIO_HOME/config/tcm.xml on UNIX %TIO_HOME%\config\tcm.xml on Windows Example 13-7 on page 626 shows the file we used for our environment.
Example 13-7 Sample tcm.xml file
This file add the following resources to the Tivoli Provisioning Manager database: 1. HUB called milan.itsc.austin.ibm.com 2. Database pointing to a a Tivoli Configuration Manager Inventory database called inv_db 3. Activity Plan Database pointing to a a Tivoli Configuration Manager Activity Plan database called planner <?xml version="1.0"?> <config> <tmr> <server>milan.itsc.austin.ibm.com</server> <username>root</username> <password>cZyAQ8477wk=</password> <database>milan.itsc.austin.ibm.com</database> </tmr> <databases> <database> <server>milan.itsc.austin.ibm.com</server>
626
<type>db2</type> <version>8.2</version> <name>inv_db</name> <username>db2inst1</username> <password>cZyAQ8477wk=</password> </database> </databases> <apmdatabases> <apmdatabase> <identifier>milan.itsc.austin.ibm.com</identifier> <server>milan.itsc.austin.ibm.com</server> <type>db2</type> <version>8.2</version> <name>planner</name> <port>50000</port> <username>db2inst1</username> <password>cZyAQ8477wk=</password> </apmdatabase> </apmdatabases> </config> In case you must add multiple Tivoli Management Region server, you can add entries in this file and use the command xmlimport to import it into the DCM.
Example 13-8 xmlimport command
Once you made the modifications to the file, follow these steps to import it into the DCM database: 1. Login as tioadmin 2. Ensure the database is running 3. Open a command window and run the following command which enable you to import properly formed XML file to populate the DCM: $TIO_HOME/tools/xmlimport.sh file:$TIO_HOME/xml/tcm.xml for UNIX or %TIO_HOME%\tools\xmlimport.cmd file:%TIO_HOME%\xml\tcm.xml for Windows. The DCM is now populated with the data related to your xml file.
627
13.9 Replicating the Tivoli Management Framework data

Tivoli Provisioning Manager for Software version 5.1 provides two script files, tcmLink.cmd/sh and rcmReplicate.cmd/sh that must be run in the order specified to replicate the Tivoli Management Region Framework data into the Tivoli Provisioning Manager for Software DCM.
13.9.1 tcmLink
This script file sets up a number of views in the Tivoli Provisioning Manager for Software database, which can be regarded as links between the Tivoli Management Region Framework and the DCM databases. In order to run this script follow these steps: 1. Stop the Tivoli Provisioning Manager for Software server. Allow two or three minutes to ensure that any databases associated with Tivoli Provisioning Manager for Software server have also stopped. Make sure that no connections to the TC database are pending running the database command to list them. In our scenario we are using an IBM DB2 database that uses the below command to list the active connections to the database: db2 list application 2. Ensure that the Tivoli Management Framework databases and the managed node process on the Tivoli Management Region servers (oserv) are running. 3. Open a Command Prompt or a shell window. 4. Change directory to %TIO_HOME%\tools and run the tcmLink.cmd script file to create links between the Tivoli Management Framework and the Tivoli Provisioning Manager for Software databases. In case your Tivoli Provisioning Manager for Software machine is on UNIX, the script is called tcmLink.sh and it is located in $TIO_HOME/tools. 5. Restart the Tivoli Provisioning Manager for Software server. For troubleshooting, a tcmLink_timestamp.log file is created in the %TIO_LOGS% directory. The default value for %TIO_LOGS% is C:\Program Files\ibm\tivoli\common\COP\logs. In case you are running your Tivoli Provisioning Manager server on a UNX machine, the script to use is called tcmLink.sh and the $TIO_LOGS is defaulted to /usr/ibm/tivoli/common/COP/logs.
628
Note: If the script ends with errors, the database part of the bridge is not created. In this case you need to analyze the log files before attempt again the script execution.
tcmLink execution details for an IBM DB2 database

These are the main operations executed by this script for an IBM DB2 database: 1. Catalogs a local node called tcm_1: catalog tcpip node tcm_1 remote MILAN.ITSC.AUSTIN.IBM.COM server 50000; 2. catalogs a local database with alias name TCM1 that points to the inv_db database on the Tivoli Management Region server: catalog database inv_db as TCM1 at node tcm_1; 3. connects to local TC database on the Tivoli Provisioning Manager server: Database server = DB2/NT 8.2.4 SQL authorization ID = DB2INST1 Local database alias = TC; 4. enables the federation to the database manager: UPDATE DATABASE MANAGER CONFIGURATION USING FEDERATED YES; 5. stops and starts the database for the above configuration to take effect; 6. connects to the remote Tivoli Management Region database using the new TCM1 alias: Database server = DB2/6000 8.2.4 SQL authorization ID = DB2INST1 Local database alias = TCM1; 7. creates the following views: HARDWARE_VIEW STORAGE_DEVICE_VIEW CPU_VIEW; 8. connects to local TC database on the Tivoli Provisioning Manager server Database server = DB2/NT 8.2.4 SQL authorization ID = DB2INST1 Local database alias = TC; 9. creates the following wrapper: TCM_WRAPPER1; 10.creates the following nicknames: db2inst1.COMPUTER_VIEW1 db2inst1.COMPUTER_MEM_VIEW1 db2inst1.CPU_VIEW1 db2inst1.HARDWARE_VIEW1
629
db2inst1.INVENTORY_SIG1 db2inst1.MEM_MODULES_VIEW1 db2inst1.MODEM_VIEW1 db2inst1.MOUSE_VIEW1 db2inst1.PARTITION_VIEW1 db2inst1.PRINTER_VIEW1 db2inst1.SD_INST1 db2inst1.SD_PACKAGES1 db2inst1.SIGNATURE1 db2inst1.SMBIOS_DATA_VIEW1 db2inst1.STORAGE_DEVICE_VIEW1 db2inst1.USB_DEV_VIEW1 db2inst1.VID_CARD_VIEW1; 11.connects to local TC database on the Tivoli Provisioning Manager server Database server = DB2/NT 8.2.4 SQL authorization ID = DB2INST1 Local database alias = TC; 12.creates a view for all the above nickname with these sql commands for each view: create COMPUTER_VIEW and return to COMPUTER_VIEW CREATE VIEW COMPUTER_VIEW as SELECT * from COMPUTER_VIEW1; 13.catalogs a local node called apm_1: catalog tcpip node apm_1 remote MILAN.ITSC.AUSTIN.IBM.COM server 50000; 14.catalogs a local database with alias name APM1 that points to the planner database on the Tivoli Management Region server: catalog database planner as APM1 at node apm_1 15.connects to local TC database on the Tivoli Provisioning Manager server Database server = DB2/NT 8.2.4 SQL authorization ID = DB2INST1 Local database alias = TC; 16.enables the federation to the database manager: UPDATE DATABASE MANAGER CONFIGURATION USING FEDERATED YES; 17.stops and starts the database for the above configuration to take effect; 18.connects to the remote Tivoli Management Region database using the new APM1 alias: Database server = DB2/6000 8.2.4 SQL authorization ID = DB2INST1 Local database alias = APM1; 19.creates the following view: TCM_ACTIVITY_PLAN_VIEW;
630
20.connects to local TC database on the Tivoli Provisioning Manager server Database server = DB2/NT 8.2.4 SQL authorization ID = DB2INST1 Local database alias = TC; 21.creates the following wrapper: APM_WRAPPER1; 22.creates the following nicknames: db2inst1.TCM_ACTIVITY_PLAN_VIEW1 db2inst1.TCM_ACTIVITY1 db2inst1.TCM_ACT_TARGET_SPEC1 db2inst1.TCM_ACTIVITY_TARGET1 db2inst1.TCM_PLAN_TARGET_SPEC1 db2inst1.TCM_PLAN_TARGET1 db2inst1.TCM_EXECUTION_WINDOW1 db2inst1.TCM_ACT_PARAMETER1 db2inst1.TCM_VARIABLE1; 23.connects to local TC database on the Tivoli Provisioning Manager server Database server = DB2/NT 8.2.4 SQL authorization ID = DB2INST1 Local database alias = TC; 24.creates a view for all the above nickname with these sql commands for each view: Create view TCM_ACTIVITY_PLAN_VIEW and return to TCM_ACTIVITY_PLAN_VIEW CREATE VIEW TCM_ACTIVITY_PLAN_VIEW as SELECT * from TCM_ACTIVITY_PLAN_VIEW1.
13.9.2 tcmReplicate
This script file populates the Tivoli Provisioning Manager for Software DCM using the links that have already been created running the tcmLink.cmd/sh script. The tcmReplicate.cmd or tcmReplicate.sh files can be run more than once. In order to run the script follow these steps: 1. Open a command prompt or a shell window. 2. Change directory to %TIO_HOME%\tools and run the tcmReplicate.cmd script file to populate the Tivoli Provisioning Manager for Software DCM database with the Tivoli Management Framework data. In case your Tivoli Provisioning Manager for Software machine is on UNIX, the script is called tcmReplicate.sh and it is located in $TIO_HOME/tools.
631
For troubleshooting, a tcmReplicate_timestamp.log file is created in the %TIO_LOGS% directory. The default value for %TIO_LOGS% is C:\Program Files\ibm\tivoli\common\COP\logs. In case you are running your Tivoli Provisioning Manager server on a UNX machine, the script to use is called tcmLink.sh and the $TIO_LOGS is defaulted to /usr/ibm/tivoli/common/COP/logs. The same task can be accomplished using a provided discovery configuration called Tivoli Configuration Manager Discovery. 3. To execute the replication using the above discovery configuration, follow these steps: a. Log on to the Tivoli Provisioning Manager for Software Web User Interface. The default user ID and the default password are both tioappadmin. b. In the navigation pane, expand Inventory. c. Click Manage Discovery Discovery Configurations. The Configure Discovery window is displayed. d. Click Edit Add Discovery Configurations. The Discovery window is displayed. e. Enter the name and the description of the discovery. f. Under Discovery select Other as the type of data to discover. g. Under Discovery Method select Tivoli Configuration Manager Discovery. h. Click Next. The Discovery Parameters window is displayed. i. You can specify a full or partial replication, by choosing to replicate all or some of the predefined types. Important: The first time you replicate, you must perform a full replication by accepting the default values. For each type, the selection for replication can be: All Replicate all new and existing items in the DCM. Choose this value the first time you replicate all the Tivoli Management Framework objects into the Tivoli Provisioning Manager for Software DCM database. None Do not replicate any items into the DCM.
632
New Replicate only the new items that are not currently defined in the DCM. Existing Allow partial replication of existing items defined in the DCM. When you select Existing, you have the possibility to choose which existing items to replicate from a list. j. Click Finish. k. On the Manage Discovery Configurations page, select the Tivoli Configuration Manager Discovery configuration and, click Run. The Initiate Discovery page is displayed. l. Enter a Task Name or accept the default value. m. Under Schedule, select Now to run the discovery task immediately, or schedule it to run at a specified date and time. n. Select the appropriate notification options. o. Click Submit. Check the console.log file in the %TIO_LOGS%\deploymentengine directory for errors. The default value for %TIO_LOGS% is C:\Program Files\ibm\tivoli\common\COP\logs. In case you are running your Tivoli Provisioning Manager server on a UNX machine, the $TIO_LOGS is defaulted to /usr/ibm/tivoli/common/COP/logs.
tcmReplicate execution details

A full replication migrates the following Tivoli Management Framework data into the Tivoli Provisioning Manager for Software DCM: All target computers, source hosts, managed nodes, gateways, profile managers that have been defined in the Tivoli Management Framework. All the SoftwarePackage profiles that have been defined in the Tivoli Management Framework, which are converted to Software Products in Tivoli Provisioning Manager for Software; All the InventoryConfig profiles that have been defined in the Tivoli Management Framework, which are converted to discovery configurations in Tivoli Provisioning Manager for Software; All the activity plans that have been defined in the Tivoli Management Framework environment using the old Activity Plan Editor, which are converted to new Activity Plans in Tivoli Provisioning Manager for Software; All the task libraries and tasks that have been defined in the Tivoli Management Framework;
633
All the queries that have been defined in the Tivoli Management Framework, which are converted to new reports in Tivoli Provisioning Manager for Software. During the replication, a TCM_ROOT group is created, which contains all of the group members that you have replicated; Note: Only the resources are replicated but not the scheduled procedures such as Inventory scans or scheduled tasks. Those need to be manually redefined after the replication. It is recommended not to replicate Tivoli Management Framework data, until you have pending scheduled activities. Summary of the replication settings The following table resumes the replication settings you can specify to run a partial or a full replication from the Web User Interface or the from command line.
Table 13-4 Replication settings summary Replicating from Web User Interface Partial replication For each replicating type set one of the following values: Full replication Set all replication types to All No replication Set all replication types to None
All New Existing None

Command line (tcmReplicate.cmd /sh For each replication type, specify one of the following values: No parameters Do not run tcmReplicate.cmd/ sh
NEW ALL The names of the item to be replicated: name#region
634
13.10 Tivoli Provisioning Manager for Software security overview

Similar to Tivoli Provisioning Manager 5.1, authentication is based on data stored into LDAP server. For authorization there are two types of security: role-base level Role-base security are primarily for GUI. Who can submit the operation (who can edit packages?/who can run queries?). It is configured using roles. instance level Instance level security are for workflow and LDO operations. Who can submit the operation on a given object (who can distribute the test.1.0 package? Who can edit test.1.0 package to modify its settings?). It is configured in terms of AccessGroups and AccessPermissions The two levels are complementary and they should be used together to properly configure security. Figure 13-17 on page 635 shows the security actors.
Figure 13-17 Security actors
Users
Each user account includes the following information: user ID, stored in LDAP; password stored in LDAP; default access group stored in DCM;
635
roles stored in LDAP; full name, address, e-mail address, phone numbers of the user stored in LDAP
Roles
Roles are stored in LDAP and defined as a set of basic permissions. Only user with the correct set of roles can logon and view the pages in the Web User Interface. New roles can be added.
Access group
Contains the instances of objects to be protected. It groups together all the objects for which you need the same permissions (policy regions in Tivoli Configuration Manager environment). It is stored in Tivoli Provisioning Manager for Software DCM database.
Access permission group

It groups together basic permissions. It is stored in Tivoli Provisioning Manager for Software DCM database.
13.11 Configure user security settings

After migrating the existing Tivoli Management Framework data into the Tivoli Provisioning Manager for Software DCM database, you can migrate the existing Tivoli Management Framework users into Tivoli Provisioning Manager for Software. Based on the assumption that you might choose to configure Tivoli Provisioning Manager for Software with a read-only replica of the LDAP server, migrating the existing Tivoli Management Framework data will insert the migrated resources only into the Tivoli Provisioning Manager for Software DCM database. You are then required to perform additional steps, after migrating the existing Tivoli Management Framework data, in order to complete the migration process.
tmrname.xml
After populating the Tivoli Provisioning Manager for Software DCM database with Tivoli Management Framework data, for each Tivoli region a file named tmrname.xml is created on the Tivoli Provisioning Manager for Software, where:
636
tmrname is the variable associated to the Tivoli region name. Example 13-9 on page 637 shows the root administrator for the Tivoli region Root_milan-region:
Example 13-9 sample milan.xml file
The hostname of the Tivoli Management Region server used for this chapter is milan. Follow the content of the milan.xml file: <Tmr> <Administrators> <Administrator name="Root_milan-region"> <Login name="root@milan" /> <Login name="Administrator" /> <Policy-Region name="global"> <Role name="backup" /> <Role name="restore" /> <Role name="Query_view" /> <Role name="Query_execute" /> <Role name="Query_edit" /> <Role name="RIM_view" /> <Role name="RIM_update" /> <Role name="HTTP_Control" /> <Role name="Dist_control" /> <Role name="Inventory_view" /> <Role name="Inventory_scan" /> <Role name="Inventory_edit" /> <Role name="Inventory_end_user" /> <Role name="CCM_Manage" /> <Role name="CCM_Edit" /> <Role name="CCM_Admin" /> <Role name="CCM_View" /> <Role name="APM_Manage" /> <Role name="APM_Edit" /> <Role name="APM_Admin" /> <Role name="APM_View" /> <Role name="policy" /> <Role name="install_product" /> <Role name="install_client" /> <Role name="user" /> <Role name="admin" /> <Role name="senior" /> <Role name="super" /> <Role name="set_role_role" />
637
</Policy-Region> <Policy-Region name="security_group_any_admin"> <Role name="user" /> </Policy-Region> <Policy-Region name="Root_milan-region#milan-region"> <Role name="admin" /> <Role name="user" /> <Role name="rconnect" /> </Policy-Region> </Administrator> </Administrators> <InterRegions> <LocalRegion HostName="milan" /> </InterRegions> </Tmr> On the tmrname.xml file, for each user the following data are reported: The login names used to identify an operating system user The policy region name The related Tivoli Management Framework security role for each policy region To migrate the existing users data into Tivoli Provisioning Manager for Software, perform the following steps: 1. Review information contained in the tmrname.xml file. Choose which users you intend to keep and delete the other login names from the file. Note: Remove the login names having the following naming convention: hostname\username. 2. Create the users on the LDAP server. The following options are available: Use any LDAP tool. Use the Tivoli Provisioning Manager for Software Web User Interface, if Tivoli Provisioning Manager for Software is configured with write permissions on the LDAP server. For more details on how to perform the System Management Manage Users Edit Add User action from the Web User Interface, refer to the Tivoli Provisioning Manager for Software Information Center. Create the admin.ldif file and customize its content by using the Example 13-10 on page 639 as a reference.
638
The mandatory fields in this file are: Ensure you specify the fn, cn, roleA and userPassword values for each Login name in the tmrname.xml file. The roleA keyword must contain a valid Tivoli Provisioning Manager for Software role. After customizing this .ldif file, run from the Tivoli Provisioning Manager for Software server command line the following command to create the LDAP users: ldapmodify -a -D cn=root -w pass -h hostname -i admin.ldif Where: pass Is the password of the LDAP user. hostname Is the host name of the LDAP server. admin.ldif Is the name of the .ldif file you have created.
Example 13-10 admin.ldif example file
dn: cn=tioappadmin, dc=ibm,dc=com pwdMustChange: false sn: tioappadmin roleA: SuperUser roleA: SystemAdministrator userPassword:: e1NIQX1GbElwQWdoS1NGclZ4UnlnalZ0QWVueGhQVDg9 businessTelephoneNumber: (555)555-5555 notificationMethod: SMTP mail: user@company objectClass: thinkControlUser objectClass: organizationalPerson objectClass: person objectClass: top postalAddress: 1234 Street fn: tioappadmin cn: tioappadmin locale:en 3. From the Tivoli Provisioning Manager for Software Web User Interface perform the following steps: a. Click System Management b. Click Manage Users. A list of all the LDAP users is displayed. c. Verify that the users displayed on this list are the same users defined on the tmrname.xml file. 4. From the Tivoli Provisioning Manager for Software server command line run the following command to associate to each LDAP user the appropriate
639
Access Permission Group, based on the information contained in the tmrname.xml file: tcmreplicate -a true
Customizing access permissions

When an IBM Tivoli Management Framework user is migrated to an Tivoli Provisioning Manager for Software user, it is associated to a default access group. The objects related to this user are organized in this default access group. An access permission group is also automatically assigned to that default access group. It contains the individual permissions that apply to individual objects. Depending on the access permission group, the user can perform particular actions on a group of resources. To keep the same IBM Tivoli Management Framework permissions for a migrated user, the administrator must either change the default access group associated to the user or define a new access permission group for the default access group.
Roles
Table 13-5 on page 640 provides a mapping between the security roles of Tivoli Configuration Manager and Tivoli Provisioning Manager for Software.
Table 13-5 Security roles mapping Tivoli Configuration Manager roles admin Tivoli Provisioning Manager for Software roles Configuration Operator Tivoli Provisioning Manager for Software tasks The user can not create or edit DCM objects, can only work with existing objects. The user can work with existing objects. The user can create DCM objects in the DefaultAccessGroup. The user can work with existing objects. The user can create DCM objects in the DefaultAccessGroup. The user can plase the objects in any existing AccessGroup.
super, senior
Configuration Administrator
root, super
System Administrator
640
If you are using Tivoli Provisioning Manager for Software roles such as Inventory Specialist or Software Operator, you can perform only specific discovery operations or software management operations.
13.12 Upgrading to the Tivoli Provisioning Manager for Software environment

The upgrade to Tivoli Provisioning Manager for Software enables you to use the resources defined in the Configuration Manager environment and to perform management actions on the enterprise from the Tivoli Provisioning Manager for Software Web User Interface. After the upgrade, the Tivoli management agent remains active on the computers and you can continue to perform Tivoli Management Framework functions against them. Note: After the upgrade to the Tivoli common agent, if you run a replica, no synchronization is performed between IBM Tivoli Management Framework and Tivoli Provisioning Manager for Software environments for these agents. After you have moved to a coexistence environment, as described in 13.5, Creating coexistence between Tivoli Management Framework and Tivoli Provisioning Manager for Software environments on page 610 start to migrate to the new infrastructure. A gradual approach is recommended: migrate one region at a time, ensuring that all migration problems have been resolved before proceeding to the next region. For each region you must complete the following tasks: 1. Install the Tivoli common agents. You can use the Tivoli Provisioning Manager for Software Web User Interface to operate on the Tivoli management agent endpoints. Refer to 13.12.1, Upgrading a Tivoli management agent to a Tivoli common agent on page 642 for details. 2. Upgrade the Tivoli Management Framework infrastructure to the distribution infrastructure. Migrate the Tivoli Management Framework database to the Tivoli Provisioning Manager for Software database.
641
13.12.1 Upgrading a Tivoli management agent to a Tivoli common agent

The Tivoli common agent is a software product that provides infrastructure for management applications. You should upgrade the Tivoli management agent computers to the Tivoli common agent computers to improve remote deployment capability and provide shared machine resources, secure connectivity, and a single entry point. Note: Run an Inventory scan on the endpoint, before upgrading. The steps you must perform to upgrade Tivoli management agent computers to Tivoli common agent computers are the following: 1. Install the Tivoli common agent on the Tivoli management agent computers. 2. Verify the Tivoli common agent computer registration. 3. Configure all the Tivoli management agent computers, that have the Tivoli common agent installed, to use the software distribution infrastructure.
13.12.2 Installing the Tivoli common agent on the Tivoli management agent computers
To install the Tivoli common agent on the Tivoli management agent computers you must submit an activity plan provided with Tivoli Provisioning Manager for Software. On the file system of the Tivoli Provisioning Manager for Software server, the following XML file is provided: $TIO_HOME/repository/plan/Plan_TCA_PLAN_FOR_TMA.xml For a Windows Tivoli Provisioning Manager for Software server the variable is %TIO_HOME% and the full path uses the back slashes. Before submitting the plan, edit it locally using the Web User Interface as follows: 1. In the navigation pane, expand Task Management. 2. Click Manage Activity Plans 3. Select Edit Launch Activity Plan Editor 4. Locate and open the TCA_PLAN_FOR_TMA activity plan by selecting File Open. The file name for UNIX is: $TIO_HOME/repository/plan/Plan_TCA_PLAN_FOR_TMA.xml
642
for Windows is: %TIO_HOME%\repository\plan\Plan_TCA_PLAN_FOR_TMA.xml After opening this XML file, the plans JRE142 and TCAforTMA are added to your workspace. 5. Add targets at activity plan level, as follows: d. Select Plan Properties from the View menu. The multi-tabbed Plan Properties window is displayed. e. Select the Target tab. f. Select Computers from the Target types for browsing down menu. g. Select List of target names from the Target selection type menu, andclick Insert. The Select Target window is displayed. h. Select the ... browse button. Add the selected targets to the List of Targets box. i. Click Add. 6. Select Save As from the File menu. 7. In the Manage Activity Plans window, select the TCA_PLAN_FOR_TMA activity plan. 8. Click the Actions icon and select Run. The Run Activity Plan window is displayed. 9. Click Submit. During installation, the Tivoli common agent registers with the Agent Manager. Reports are sent to the Tivoli Management Region server and synchronization between Tivoli Provisioning Manager for Software and Tivoli Management Framework completes. The Tivoli common agents are configured with the address and port of the Agent Manager and are automatically started.
13.12.3 Verifying that the Tivoli common agent is running in the upgraded Tivoli management agent
After installing the Tivoli common agent, you can verify that it is running. On a Windows computer, you can open the Windows Services control panel and look for a service called IBM Tivoli common agent. Make sure that the service is started. There is also a workflow called TCA_PingAgent that can be used to check the Tivoli common agent status. Follow these steps to execute the workflow:
643
1. In the navigation pane, expand Automation. 2. Click Workflows. 3. In the Name search bar enter TCA_PingAgent and select Search. The TCA_PingAgent workflow name is displayed. 4. Click the Actions icon and select Run. The Input Parameter for Workflow: TCA_PingAgent window is displayed. 5. In the DeviceID field, enter the ID associated to the target computer where the common agent has been installed. This represents the ID of the object registered in the DCM. To get this value follow these steps: a. Expand Inventory Manage Inventory Computers b. In the Name field add the name of the computer you are looking for or select it from the list c. Moving the mouse on the computer name. The computer ID is shown for a couple of seconds within brackets. An example is shown in Figure 13-18 on page 644
Figure 13-18 Computer ID
644
6. In the Port field, enter the default value 9510. 7. Select Run. If the Tivoli common agent is running, the workflow ends in success status. Selecting the Request ID connected to the workflow execution just completed, you can access the workflow execution log as shown in Figure 13-19 on page 645
Figure 13-19 TCA_PingAgent workflow execution log
13.12.4 Configuring Tivoli management agent computers to use the software distribution infrastructure
After having installed the Tivoli common agent on a set of Tivoli management agent computers, you need to configure each Tivoli management agent to use the software distribution infrastructure by creating the SOA-SAP service access
645
point. A SOA-SAP service access point (SAP) is required for software distribution and provides the credentials required for a secure communication protocol to and from the Tivoli common agent. The upgraded computers can only be managed through the distribution infrastructure. You can configure the SOA-SAP on a Tivoli management agent computer using one of these procedures: Run the Create_SOA_Endpoint_Operation_SAP workflow on the device id of the Tivoli common agent From Inventory Manage Inventory Computers click on Edit Add Credentials. You can specify multiple computers or groups with a single operation. From the computer page, select the Credentials tab, and select Edit Add Credentials. In this case the SAP is added only for that computer. These are the steps to add the SAP on multiple computers: 1. Select Inventory Manage Inventory Computers 2. Select Edit Add Credentials. The Add Credential Wizard window is displayed 3. In the Select Credential Pair Type panel, select SOA from the pull-down menu and click Next 4. In the Specify Target Computers panel, select one or more computers to act as targets for the requests, and click Next. 5. Click Finish. 6. This action results in the submission creation of the soahost SAP.
13.13 Tivoli Provisioning Manager for Software behind the scenes

This section provides some details and internal information about the components and the flows of the integration with the Tivoli Management Framework.
13.13.1 Database synchronization process

In a medium-large business enterprise managed by Tivoli Configuration Manager over Tivoli Management Framework, the number of endpoints can reach tens of thousands. Management operations over such enterprises are made of hundreds
646
of software distribution profiles, inventory data retrieval profiles and general purposes task execution. With the objective of simplifying and help the administrator in getting this huge number of resources under control, Tivoli Management Framework allows you to organize them in hierarchical groups. The enterprise could be logically organized in policy regions, containing several profile managers each, used to address Software Distribution and Inventory profiles over a list of target endpoints. In addition, this organization can belong to a multi Tivoli Management Region Servers environment, structured in a typical Hub-Spoke architecture. In order for Tivoli Provisioning Manager for Software to coexist with an environment where Tivoli Configuration Manager is deployed, a subset of the resources handled by Tivoli Configuration Manager is required to be available from the Tivoli Provisioning Manager for Software server to allow the enterprise system operator to perform management operations on these resources directly from the Tivoli Provisioning Manager for Software Web User Interface. A replication strategy has been implemented to make those resources available in Tivoli Provisioning Manager for Software DCM.
Coexistence databases architecture

The synchronization process analyzes several types of data from the following databases: Inventory Activity Plan Tivoli Management Framework object database Figure 13-20 on page 648 shown the connections between the Tivoli Provisioning Manager for Software and the Tivoli Management Framework environment.
647
Figure 13-20 Connections generic architecture
Typical Tivoli Management Framework resources belonging to each Tivoli Management Region like endpoints, profile managers, profiles, policy regions, queries, task libraries and tasks along with their relationships are stored into the object database registered on that Tivoli Management Region. Accessing these resources from outside the Tivoli Management Framework environment is only possible using the Java Client Framework (JCF) that is a kind of Java development kit that the Tivoli Management Framework ships exactly for these purposes. Once the right credentials are used by an external process to create a connection to a given Tivoli Management Region through the Java Client Framework, that process is able to perform any kind of management operations for which the used credential is authorized on that Tivoli Management Region. In Tivoli Provisioning Manager for Software a process called tcmReplicate is intended to perform the database synchronization and in this context it uses JCF connections (one connection for each Tivoli Management Region required to be migrated) to retrieve the information stored inside the Object Databases.
Database link
From a Tivoli Configuration Manager standpoint other storage systems are used to contain data specific to Inventory and Configuration Management. In other words, Tivoli Configuration Manager specific data along with their relationships with Tivoli Management Framework resources are used to be stored in Relational Data Base Management Systems (RDBMS) connected to the Tivoli Management Framework environment. In general, each Tivoli Management Region server
648
holds its own Inventory database even though in particular configurations the same Inventory database could be shared between several Tivoli Management Region servers. In this case, all the Tivoli Management Region spoke servers will store the data on a central database connected to the hub Tivoli Management Region server. In the same way, the Activity Plan Manager (APM) component needs to have its own database too and again, in general any Tivoli Management Region server could own one APM database. A lot of information belonging to both Tivoli Configuration Manager databases (Inventory and APM) gets retrieved by the tcmReplicate process during database synchronization. This implies that additional connections to the databases in Tivoli Configuration Manager world are needed to be maintained by Tivoli Provisioning Manager for Software in order for the replication process to happen. To activate these connections, a link must be established between each Tivoli Configuration Manager databases and the database used by Tivoli Provisioning Manager for Software as depicted in Figure 13-21 on page 650. The database link (also known as federation) is a technique by which for a remote and catalogued database a wrapper is created on the local instance of another database and inside this wrapper a set of nicknames is used to emulate Tables belonging to the remote database. In this way, whatever process (either CLI or running inside an application) can connect to the local instance of the database and be able to retrieve data from a nickname even though the physical data are stored in the related linked table on the remote database. In the context of Tivoli Provisioning Manager for Software, after the federation has taken place, the replication process (tcmReplicate) needs only the Tivoli Provisioning Manager for Software database connection credentials to access data belonging to any linked database in Tivoli Configuration Manager side.
649
Figure 13-21 Database link diagram
Database replication
Once clarified the objects that are replicated in a coexistence environment, we should know what objects they are mapped to in Tivoli Provisioning Manager for Software DCM. Considering that Tivoli Provisioning Manager for Software is intended to manage configuration and provisioning of heterogeneous environments (for example data centers, enterprises with servers and workstations, down to single laptops) its DCM is needed to be standardized to address this heterogeneity. From this point of view, Tivoli Management Framework concepts designed to address logical grouping and hierarchical organizations like policy regions and profile managers don't have a specific mapping on the new Tivoli Provisioning Manager for Software, so any kind of Tivoli Management Framework grouping are mapped into the group generic object. Tivoli Provisioning Manager for Software groups can be: typed they can contain only objects of the specified type, e.g. Computer, Software Product, Discovery Configuration, and so on; untyped the can contain any kind of objects regardless their type.
650
The task of reporting inside Tivoli Provisioning Manager for Software DCM one single resource along with its relations to other objects stored in Tivoli Management Framework and Tivoli Configuration Manager databases is a large time consuming task; the overall process could take a large timeframe to complete depending on how many objects and how many relations they have inside the original enterprise. The resource requiring the highest number of database accesses in read-mode from Tivoli Management Framework and Tivoli Configuration Manager side and in write-mode on Tivoli Provisioning Manager for Software side is the Tivoli management agent endpoint. Figure 13-22 on page 651 shows the connections that are maintained for any single migrated endpoint. Considering the number of groups that are created or updated once an endpoint is migrated, its easy to understand that the tcmReplicate process is time consuming, and its duration is strictly related to the number of endpoints belonging to the Tivoli Management Framework enterprise.
Figure 13-22 Connections between endpoint and other resources inside Tivoli Provisioning Manager for Software DCM
Best practices
For the above considerations about the tcmReplicate process duration, it is possible to smoothly synchronize the Tivoli Management Framework and the Tivoli Provisioning Manager for Software environments using one of the following methods: Overnight synchronization To avoid the initial replication process it is possible to schedule the syncronization by night to avoid a slowdown of any Tivoli Provisioning Manager for Software business related operations.
651
Selective replication tcmReplicate process allows you to select a subset of resource types or resource groups to be replicated at a time.
13.13.2 Report Manager

The Report Manager component is installed on the TMR server via an Interim Fix installation for the Tivoli Configuration Manager Software Distribution server component. Refer to 13.7.2, Installing required Interim Fixes on the Tivoli Management Framework environment. on page 616 for details about the Interim Fixes installation. It act as a report consumer for the Inventory and Software Distribution operations. Its behavior is similar to the old Activity Plan engine; the notification is sent at the end of the operation. It is responsible for: Managing reports coming from Tivoli Configuration Manager and to provide a querying interface to the Tivoli Provisioning Manager for Software server. Storing reports coming from the underlying applications into the inventory database inv_db. Tivoli Provisioning Manager for Software reporting engine queries the Report Manager at regular intervals to retrieve the results of completed actions and stores them into the DCM repository. Two separate threads are used to manage Software related reports and Discovery related reports. The Discovery thread triggers endpoint selective replication.
Report Manager internals

Figure 13-23 on page 653 shows an internal representation of the Report Manager component.
652
Figure 13-23 Report Manager - internals
The Report Manager is responsible for the following actions: 1. Every request from Tivoli Provisioning Manager for Software server to Tivoli Configuration Manager applications registers the Report Manager as callback object on the receive_report method 2. When the Tivoli Configuration Manager application completes, it notifies the Report Manager about the result of the operation on each target, using the registered callback method 3. The Report Manager receive_report method stores each report on a temporary file in the local filesystem 4. A consumer thread in the Report Manager is responsible for consuming the enqueued reports and storing them into the inventory database. As shown in Figure 13-24 on page 654 the Report Manager ialso executes the following actions: 1. At regular time the Reporting engine on Tivoli Provisioning Manager for Software server queries the infrastructures for the status of pending tasks
653
2. The Tivoli Management Framework infrastructure invokes the query_report method on the Report Manager component, specifying a starting date and time as well as the max number of reports 3. The Report Manager retrieves from its database all the reports starting from the specified date and time 4. The Reporting engine on the server side updates the status of the pending tasks in the DCM repository.
Figure 13-24 Report Manager - reports handling
REP_MANAGER table
This table is created on the inv_db database by the execution of the rep_vendor.sql script as described in section rep_vendor.sql script on page 617. Table 13-6 on page 655 describeds the REP_MANAGER table schema:
654
Table 13-6 REP_MANAGER table schema Column name SERVER_ID Type String Description The TPM server identifier. This information is used to identify which TPM server originated the request on TCM The MDist2 distribution ID used to identify the TPM task which originated the request on TMF The MDist2 status of the operation (final status) The TME object ID used to identify each target TMA endpoint The date and time information for each report. This information is used by the Report Manager when querying the results A string containing a reference to the installable used by TPMfS server when originating the request. This is valid only for SWD operations The application which originated the report The TMR region identifier, used to identify the TR where the report has been generated (when multiple TMRs share the same inventory database) The message associated to the report.
DIST_ID
String
STATUS TARGET
Integer String
RECORD_MODE
String
INST_ID
String
APP_DATA REGION_ID
String String
MESSAGES
String
655
Configuration
The Report Manager component provides a command line interface for configuring trace information: wrpmgcfg. Follow the usage of the command: wrpmgcfg -s key[=value] Where the valid keys are the following trace_level [0..6] trace_size [100..2000000000] trace_files [>0] When Tivoli Provisioning Manager for Software consumes the reports in the database, the Report Manager removes the entries related to those reports in order to keep the table size under control. This behavior can be disabled setting a specific idl attribute of the Report Manager component (delete_old_rows) Example 13-11 on page 656 shows some command to check the actual status of the delete_old_rows attribure and eventually change its value:
Example 13-11 Report Manager configuration
The Report Manager is registered on the Tivoli Management Region server, as a distinguished resource called ReportManager. To locate its OID run the following command: [root@milan][/]-> wlookup ReportManager 1536006190.1.1067#RMEngine::ReportManager# To get the value of the delete_old_rows attribute run the following command: [root@milan][/]-> idlcall 1536006190.1.1067 _get_delete_old_rows TRUE By default the output is set to TRUE. To disable the report entries removal, use this command to set the attribute to FALSE: [root@milan][/]-> idlcall 1536006190.1.1067 _set_delete_old_rows FALSE
Troubleshooting
The Report Manager component stores trace files as well as temporary files for unprocessed reports in the follow folders:
656
%BINDIR%\..\ReportManager for Windows or $BINDIR/../ReportManager for UNIX: these directories contain trace files; %BINDIR%\..\ReportManager\work for Windows or $BINDIR/../ReportManager/work: these directories contain temporary files used by the consumer thread when processing reports. Example 13-12 on page 657 shows some sample traces coming from a standard processing.
Example 13-12 Trace showing a standard processing
When the operation completes the receive_report method is invoked: it stores the report on a temporary file with .msg extension [944:18574632] 10/9/2006 19:36:01.078 [I] t_receive_report >>>> ENTRY >>>>> [944:18574632] 10/9/2006 19:36:01.078 [I] make_name_file attempting to create D:\IBM\Tivoli\bin\ReportManager\work\rm1160415361078 [944:18574632] 10/9/2006 19:36:01.078 [I] t_receive_report save the message [944:18574632] 10/9/2006 19:36:01.093 [I] t_receive_report rename the file The consumer thread handles such a file and stores its contents in the database: [944:18590968] 10/9/2006 19:36:01.109 [I] t_consumer_report >>>> ENTRY >>>>> [944:18590968] 10/9/2006 19:36:01.109 [I] listFiles >>>> ENTRY >>>>> [944:18590968] 10/9/2006 19:36:01.109 [I] file::list directory path is D:\IBM\Tivoli\bin\ReportManager\work\*.msg [944:18590968] 10/9/2006 19:36:01.109 [I] t_consumer_report analize the file 'D:\IBM\Tivoli\bin\ReportManager\work\rm1160415361078.msg' [944:18590968] 10/9/2006 19:36:01.109 [I] t_consumer_report read data [944:18590968] 10/9/2006 19:36:01.109 [I] update_the_db >>>> ENTRY >>>>> [944:18590968] 10/9/2006 19:36:01.109 [I] update_the_db targets num: 1 [944:18590968] 10/9/2006 19:36:01.109 [I] update_the_db SERVER_ID: 2293 DIST_ID: 1098543693.18 STATUS: 6 TARGET oid: 1098543693.8.522+#TMF_Endpoint::Endpoint# MESSAGE: DISSE0001I Operation successful. INST_ID: 3242
657
APP_DATA: SoftwareModule.Install [944:18590968] 10/9/2006 19:36:01.109 [I] RepDB:update_db >>>> ENTRY >>>>> [944:18590968] 10/9/2006 19:36:01.109 [I] RepDB:update_db query: <insert into REP_MANAGER (SERVER_ID , DIST_ID , STATUS , TARGET , RECORD_TIME , MESSAGES , INST_ID , APP_DATA , REGION_ID) values ('2293', '1098543693.18', '6', '1098543693.8.522+#TMF_Endpoint::Endpoint#', '20061009173601109', 'DISSE0001I Operation successful. ', '3242', 'SoftwareModule.Install', '1098543693') > When the report has been processed, the temporary file is removed from the working directory. [944:18590968] [944:18590968] [944:18590968] [944:18590968] <<<<< 10/9/2006 10/9/2006 10/9/2006 10/9/2006 19:36:01.109[I] 19:36:01.109[I] 19:36:01.109[I] 19:36:01.109[I] file::remove >>>> ENTRY >>>>> file::remove return data = 1 file::remove <<<<< EXIT <<<<< t_consumer_report <<<<< EXIT
TPMfS reporting thread invokes the query_report method to get results of pending tasks specifying a start date [944:18569120] 10/9/2006 20:07:43.953 [I] t_query_report >>>> ENTRY >>>>> [944:18569120] 10/9/2006 20:07:43.953 [I] t_query_report list=011AFD88 When the query_report method starts, it first trigger the consumer thread to see if there is any pending report in the working area that needs to be processed. [944:18569120] 10/9/2006 20:07:43.953[I] run_consumer_thread >>>> ENTRY >>>>> [944:18569120] 10/9/2006 20:07:43.953[I] run_consumer_thread <<<<< EXIT <<<<< According to the specified configuration, the report manager delets obsolete rows in the database: [944:18569120] 10/9/2006 [944:18569120] 10/9/2006 >>>>> [944:18569120] 10/9/2006 <delete from REP_MANAGER 20:07:43.953 [I] t_query_report del_old_rows=1 20:07:43.953 [I] RepDB:del_old_rows >>>> ENTRY 20:07:43.953 [I] RepDB:del_old_rows query: where RECORD_TIME < '20061009180018251' AND
658
SERVER_ID = '2293' AND APP_DATA LIKE 'SoftwareModule%' AND REGION_ID = '1098543693' > It then executes the required query returning the available reports to the caller: [944:18569120] 10/9/2006 20:07:43.984 [I] t_query_report execute query_db [944:18569120] 10/9/2006 20:07:43.984 [I] RepDB:query_db query=<SELECT * FROM REP_MANAGER WHERE RECORD_TIME >= '20061009180018251' AND REGION_ID = '1098543693' AND SERVER_ID = '2293' AND APP_DATA LIKE 'SoftwareModule%' AND ( STATUS = 6 OR STATUS = 7) ORDER BY RECORD_TIME> [944:18569120] 10/9/2006 20:07:44.046 [I] RepDB:query_db DIST_ID= 1098543693.20 [944:18569120] 10/9/2006 20:07:44.046 [I] RepDB:query_db STATUS= 6 [944:18569120] 10/9/2006 20:07:44.046 [I] RepDB:query_db TARGET= 1098543693.8.522+#TMF_Endpoint::Endpoint# [944:18569120] 10/9/2006 20:07:44.046 [I] RepDB:query_db RECORD_TIME= 18562904 [944:18569120] 10/9/2006 20:07:44.046 [I] RepDB:query_db MESSAGES= DISSE0001I Operation successful. [944:18569120] 10/9/2006 20:07:44.046 [I] RepDB:query_db INST_ID= 3242 [944:18569120] 10/9/2006 20:07:44.046 [I] RepDB:query_db APP_DATA= SoftwareModule.Install [944:18569120] 10/9/2006 20:07:44.046 [I] RepDB:query_db <<<<< EXIT <<<<< [944:18569120] 10/9/2006 20:07:44.046 [I] t_query_report <<<<< EXIT <<<<< On the TPMfS side, the activityplan console.log register the activity of the Status Updater thread which, for TMF actions, interacts with the Report Manager. 2006-10-09 20:07:43,875 DEBUG [Status Updater] (TmfStatusUpdater.java:44) tmf.TmfStatusUpdater: Thread[Status Updater,5,main] thread calling ProcessJobStatus on TMF It starts processing the Software related reports 2006-10-09 20:07:43,906 DEBUG [Status Updater] (Connector.java:257) proxy.Connector: current TMR server OID:1098543693.1.0 2006-10-09 20:07:43,938 DEBUG [Status Updater] (TmfService.java:93) swd.TmfService: processing software related results
659
2006-10-09 20:07:43,938 DEBUG [Status Updater] (TMFOperation.java:112) tmf.TMFOperation: Invoking the getDistributionStatus with start_time = 20061009180018251 2006-10-09 20:07:44,047 DEBUG [Status Updater] (TMFOperation.java:117) tmf.TMFOperation: building report 2006-10-09 20:07:44,062 DEBUG [Status Updater] (TMFOperation.java:140) tmf.TMFOperation: managing work item status 2006-10-09 20:07:44,062 DEBUG [Status Updater] (TmfService.java:551) swd.TmfService: MDist Status Count=1 2006-10-09 20:07:44,062 DEBUG [Status Updater] (TmfService.java:128) swd.TmfService: singleDist=false 2006-10-09 20:07:44,062 DEBUG [Status Updater] (TmfService.java:129) swd.TmfService: distId=null 2006-10-09 20:07:44,062 DEBUG [Status Updater] (TmfService.java:138) swd.TmfService: loop on targets 2006-10-09 20:07:44,062 DEBUG [Status Updater] (TmfService.java:149) swd.TmfService: returnDate= '20061009180742312' distId= '1098543693.20' 2006-10-09 20:07:44,109 DEBUG [Status Updater] (TmfService.java:161) swd.TmfService: status=SUCCEEDED 2006-10-09 20:07:44,203 DEBUG [Status Updater] (TmfService.java:166) swd.TmfService: gino#gbernard-tp-region 2006-10-09 20:07:44,203 DEBUG [Status Updater] (TmfService.java:170) swd.TmfService: tm.getTaskId()='16913', tm.getTaskJobItemId()='4504', ep.getId()='8218' 2006-10-09 20:07:44,281 DEBUG [Status Updater] (TmfService.java:226) swd.TmfService: loop completed 2006-10-09 20:07:44,297 DEBUG [Status Updater] (TmfService.java:229) swd.TmfService: softwareTasks.size = 1 2006-10-09 20:07:44,297 DEBUG [Status Updater] (TmfService.java:247) swd.TmfService: returnDate = '20061009180742312' 2006-10-09 20:07:44,297 DEBUG [Status Updater] (TmfService.java:557) swd.TmfService: MDist Total Count=1 2006-10-09 20:07:44,297 DEBUG [Status Updater] (TmfService.java:105) swd.TmfService: done processing software related results It then processes Discovery related reports spawning a new thread for this task, since it might require running a selective replica 2006-10-09 20:07:44,312 DEBUG [Status Updater] (TmfService.java:109) swd.TmfService: discovery thread is not alive... let's start it 2006-10-09 20:07:44,406 DEBUG [DiscoveryStatusUpdater] (Connector.java:257) proxy.Connector: current TMR server OID:1098543693.1.0
660
2006-10-09 20:07:44,453 DEBUG [DiscoveryStatusUpdater] (TMFOperation.java:112) tmf.TMFOperation: Invoking the getDistributionStatus with start_time = 20061006154835704 2006-10-09 20:07:44,734 DEBUG [DiscoveryStatusUpdater] (DiscoveryResultsProcessor.java:47) swd.TmfService: MDist Status Count=0
13.13.3 InventoryConfig
Once the integration between Tivoli Provisioning Manager for Software and Tivoli Configuration Manager is done, the InventoryConfig profiles are created on the Tivoli Provisioning Manager for Software and mapped in Discovery Configurations of type Tivoli Provisioning Manager Inventory Discovery. A Tivoli Provisioning Manager Discovery Configuration of this type has the following parameters: Hardware Software Use the registry Use software signatures Use selected signatures TPM Discovery Configuration does not have different set of properties for Unix and PC platforms like the old InventoryConfig. The Tivoli Provisioning Manager Discovery Configuration that is created has the same fully qualified name of the originating Inventory Profile: <IPname#region-name> and contains the link to the Tivoli Management Framework object identifier (OID) of the InventoryConfig itself. The Inventory profile parameters have been mapped using the following schema: Global Properties are ignored. HW Properties: PC DMI Scanner is ignored. If any other Hardware property (PC or Unix) is selected the Hardware property is set in the migrated TPM Discovery. SW Properties: PC Scan for Patches Information is ignored. If any other Software property (PC or Unix) is selected the Software property is set in the migrated TPM Discovery.
661
If Signature Scan or Registry Scan is set, the equivalent option is set in the migrated TPM Discovery. Scripts and MIF files are not currently supported. Pervasive Devices are not currently supported. The discovery can be submitted against both Tivoli management agents (Endpoints) and Tivoli common agents. Discovery against endpoints When the Discovery is submitted against an endpoint, the scan request is forwarded to the Inventory engine on the Tivoli Management Framework. The inventory data are inserted into the Inventory database on the Tivoli Management Framework first (inv_db), then a tcmReplicate is run against that specific endpoint and the DCM database is updated with the scan result. The report is then saved to the Report Manager table in the inv_db database and returned to the Tivoli Provisioning Manager for Software. The Task generated by the Discovery completes and the progress bar becomes green and the status of the task is changed to Successful. Discovery against Tivoli common agents In this case the replicated InventoryConfig configuration is managed by the new SOA infrastructure: the request is sent to the Common Inventory Technology (CIT) sub-agent as a DMS job and the results are collected back to the Tivoli Provisioning Manager for Software server directly by leveraging a specific servlet for the upload.
SoftwarePackage
The SoftwarePackage object (SPO) contains global attributes and instructions on installation actions. In contrast, the DCM software representation contains only the setting attributes. The installation actions are implemented currently as workflow instructions. In Tivoli Provisioning Manager for Software, the installation actions are delegated to deployment infrastructure that can be agent based or agentless. The agent based installation relies on information contained in the SPO and interpreted by the Software Installation Engine preinstalled on each target. The distribution infrastructure is either SOA or TMF based. For agent-less distribution the workflow will provide both the distribution and installation on the target. The mapping requires the information about the SPO contained in both the Relational Inventory Database and Tivoli Management Framework's Object Database.
662
The Tivoli Management Framework Object Database provides the SPO details related to its internal information and the logical assignment to policy region and profile manager, Tivoli Management Framework logical concepts. The Relational Inventory Database stores the relationship between the software package, its installable and the installation on the targets performed through the Tivoli Management Framework infrastructure.
Activity plans
The activity plans created with the old Tivoli Configuration Manager Software Distribution V4.2.3 are also replicated to the Tivoli Provisioning Manager for Software, but if you create new plans on Tivoli Provisioning Manager for Software side, they are not created on Tivoli Configuration Manager Software Distribution V4.2.3 side for execution. Tivoli Provisioning Manager for Software handles activity plans with its own activity plan engine, regardless the target of the distribution. If the activity plan executed is one of those replicated, the activity plan engine on the Tivoli Provisioning Manager for Software server instructs the Tivoli Management Framework for the elementary instructions contained in the plan. The activity plan engine at the Tivoli Management Framework side is no more used. The reports returns to the activity plan engine on the Tivoli Provisioning Manager for Software server.
13.13.4 Top level policy region

When you distribute to an endpoint a Software Product or an Inventory Discovery configuration items created on the Tivoli Provisioning Manager for Software, the following actions take place on the Tivoli Management Region: a new top level policy region, called TPM_Region is created. a new profile manager called TPM_product_ProfileManager is created, where product can be: Inv for an Inventory Discovery, Swd for a Software Product. a new InventoryConfig or SoftwarePackage profile is created with the same name of the corresponding Inventory Discovery or Software Product configuration items. the distribution is started and the flow is the same described in the section InventoryConfig on page 661.
663
13.14 Mapping of resources and concepts

This section describes the mapping between the Tivoli Provisioning Manager for Software names and the Tivoli Configuration Manager ones.
13.14.1 User interfaces

Table 13-7 on page 664 shows a comparison between the Tivoli Configuration Manager User Interfaces and the new Tivoli Provisioning Manager for Software ones:
Table 13-7 TCM V4.2.3 UIs versus TPM for Software V5.1 UIs Tivoli Configuration Manager V4.2.3 User Interface TME Desktop Admin Software Package Editor Inventory Distribution Status Console Change Configuration Manager Activity Plans Editor Activity Plans Monitor Query Facility Action Tivoli Provisioning Manager for Software V5.1 User Interface TME Desktop Admin Eclipse and Web Discovery Task Monitoring Compliance Management Web Applet Activity Plan and Task Monitoring Group Management and Reporting
Keep Keep Replace Replace Replace Keep Replace Replace
13.14.2 Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software terminology for resource management
The following shows a comparison between the Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software terminology for resource management.
664
Table 13-8 Tivoli Configuration Manager versus Tivoli Provisioning Manager for SW 5.1 Object in Tivoli Configuration Manager terminology Software Distribution profile Current Location Object in Tivoli Provisioning Manager for Software terminology Software definition the definition of an application in terms of generic properties (name, version...) also known as Software Module Software installable the installable (binary) file associated to a software definition, also known as software product. A software definition might have more than one installable. Endpoint Task New concept introduced in Tivoli Provisioning Manager to provide the ability to execute a command on a remote machine leveraging the infrastructure capabilities Reports or dynamic groups A report is an object used to perform queries on the DCM contents. It is a wrapper of an SQL statement and can be used to define dynamic groups, that is groups whose members are defined by the execution of a query on the db. New location
Tivoli object database
data center model (DCM) This names identifies the Tivoli Provisioning Manager relational database, where every Tivoli Provisioning Manager resource is defined. File repository (FR) Device dedicated to store files. A valid FR must have: a root path a valid IP configuration Each file has an associated file repository and its path is related to the FR root path. data center model (DCM)
Software package block (SPB)
Tivoli Configuration Manager source host
TMF task
TMF queries
data center model (DCM)
Software Distribution profile Software Distribution is a component of Tivoli Configuration Manager that performs distributions of large amounts of data to multiple target systems. A
665
profile in a Tivoli Management Environment is a container for application-specific information about a particular type of resource. Software package block (SPB) In Tivoli Software Distribution, a file that contains the resources referred to by the actions in a software package. Tivoli Management Framework task In a Tivoli Management Environment, the definition of an action that must be routinely performed on various managed resources throughout the network. A task defines the executables to be run when the task is executed, the authorization role required to execute the task, and the user or group name under which the task will execute. Tivoli Management Framework queries In a Tivoli environment, a combination of statements that are used to search the configuration repository for systems that meet certain criteria. The query object is created within a query library.
13.14.3 Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software terminology for hardware and group management
The following shows a comparison between the Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software Terminology for hardware and group management.
Table 13-9 TCM versus TPM for Software V5.1 Hardware and Group Management terminology Object in TCM terminology Inventory Profile Current Location Object in Tivoli Provisioning Manager for Software terminology Discovery Configuration An instance of a configuration for a specific discovery method (device model). Tivoli Provisioning Manager for Software release provides two discovery methods: the one based on the Common Inventory Technology (CIT) v2.2 and the one based on the Security Compliance Manager (SCM) for compliance checks (desired state management) New location
666
Object in TCM terminology Hardware Inventory data (HW/SW discovered information)
Current Location
Object in Tivoli Provisioning Manager for Software terminology
New location
TCM RDBMS
Properties of Computer Each software installed on a Computer is mapped into the concept of SoftwareInstallation: this entity represents the association between a software installable and a device. The hardware properties discovered during a scan are mapped into computer's properties.
Logical grouping Policy region Tivoli object database Untyped group A group is a DCM object used to represent a collection of resources. It can be either typed (every member having the same type) or untyped (members having mixed types). Untyped group Endpoint task group data center model (DCM)
Profile manager Task library
Tivoli object database Tivoli object database
data center model (DCM) data center model (DCM)
Inventory profile Inventory is a component of Tivoli Configuration Manager that enables system administrators to gather hardware and software information for a network computing environment. A profile in a Tivoli Management Environment is a container for application-specific information about a particular type of resource. Inventory data Hardware and software information for a network computing environment discovered by an inventory scan that runs on the resources of the environment. Policy region A group of managed resources that share one or more common policies and which models the management or organizational structure of a network computing environment. Administrators use policy regions to group similar
667
resources, to define access to the resources, to control the resources, and to associate rules for governing the resources. Profile manager In a Tivoli Management Environment, a container for profiles that links the profiles to a set of resources, called subscribers. Tivoli administrators use profile managers to organize and distribute profiles. A profile manager can operate in the dataless mode or database mode. Task library In a Tivoli Management Environment, a container in which a Tivoli administrator can create and store tasks and jobs.
13.14.4 Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software terminology for topology configuration
The following shows comparison between the Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software Terminology for topology configuration.
Table 13-10 TCM versus TPM for SW 5.1 - Topology Configuration terminology Object in TCM terminology Current Location Object in Tivoli Provisioning Manager for Software terminology New location
Topology TMR Tivoli object database Computer A computer is a DCM object used to represent a system in the enterprise, regardless of its role (server, endpoint) Computer File Repository data center model (DCM)
Managed node Source host
Tivoli object database Tivoli object database
data center model (DCM) data center model (DCM)
668
Object in TCM terminology
Current Location
Object in Tivoli Provisioning Manager for Software terminology Computer Group A computer group is a typed collection of computers. TPM Depot A TPM Depot is a DCM object used to represent a system where software resources could be loaded in order to allow a faster deployment of such resources. It is the only allowed target of a publish operation and is used to represent TMF repeaters as well as CDS depots. Computer
New location
Gateway
Repeater
Endpoint (TMA object)
TMR, Tivoli Management Region server The server for a specific Tivoli Management Region that holds or references the complete set of Tivoli software, including the full object database. Managed node In a Tivoli Management Environment, a computer system on which Tivoli Management Framework is installed. Source host The managed node on which the source files and directories referred to in a software package or a file package reside.
669
Gateway Software that provides services between the endpoints and the rest of the Tivoli environment. Repeater In a Tivoli Management Environment, a managed node that receives a single copy of data and distributes it to the next tier of clients. Endpoint (TMA object) In a Tivoli Management Environment, the agent that is the ultimate recipient for any type of Tivoli operation.
13.14.5 Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software terminology for security
The following shows a comparision between the Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software terminology for security.
Table 13-11 TCM versus Tivoli Provisioning Manager for SW 5.1 - Security terminology Object in TCM terminology Current Location Object in Tivoli Provisioning Manager for Software terminology Security Administrator Tivoli object database User group Collections of users that could be used to assign the same level of security permissions LDAP users A user's profile is defined for each of them that include: logon information, personal information, the security role, the access permission groups to which the user belongs, the user's password. Access group Logical organizations of DCM Objects which a user is granted access over. data center model (DCM) New location
Login (OS users)
LDAP server
Policy region
670
Object in TCM terminology Roles
Current Location Tivoli object database
Object in Tivoli Provisioning Manager for Software terminology Access permission group Set of access privileges identifying the security requirements needed to perform logical device operations. A logical device operation (LDO) is an abstraction of a real operation, which could be implemented in different ways depending on the involved resources.
New location data center model (DCM)
Administrator login (OS users) In a Tivoli Management Environment, a system administrator who has been authorized to perform systems management tasks and manage policy regions in one or more networks. Policy region A group of managed resources that share one or more common policies and which model the management or organizational structure of a network computing environment. Administrators use policy regions to group similar resources, to define access to the resources, to control the resources, and to associate rules for governing the resources. Role A job function that identifies the tasks that a user can perform and the resources to which a user has access. A user can be assigned one or more roles.
13.15 Migration considerations

In this section we provide some consideration about the migrated resources after the replication has been perfomed. We also describe the Tivoli Configuration Manager functionalities that are not included in Tivoli Provisioning Manager for Software and that you can continue to perform using the Tivoli Configuration Manager if you work in a coexistence environment. This section also describes Tivoli Configuration Manager scenarios, actions, devices, no longer supported when you fully upgrade your environment to Tivoli Provisioning Manager for Software.
671
13.15.1 Supported functionalities in a coexistence environment

In a coexistence environment, you can perform any Tivoli Configuration Manager actions from the Tivoli desktop and Tivoli command line, but be aware that if you perform software distribution, activity planning, and inventory operations from Tivoli Provisioning Manager for Software, to avoid database synchronization problems, you should continue to use the Tivoli Provisioning Manager for Software to perform these operations. Table 13-12 on page 672 describes the Tivoli Configuration Manager functionalities that you can perform using Tivoli Configuration Manager because they are not supported by Tivoli Provisioning Manager for Software. They can still be performed from the Tivoli Desktop or the Command Line Interface. Note: After using some of these functionalities, you need to schedule a periodic replica to realign the Tivoli Configuration Manager database with the Tivoli Provisioning Manager for Software DCM.
Table 13-12 Functions unavailable on Tivoli Provisioning Manager for Software Functionality Data moving Device management Verify operation TEC integration Tivoli License Manager integration Replica No No No No Yes Comment
672
Functionality WebUI for published software catalog
Replica Yes
Comment Ensure you manage the software package using only Tivoli Configuration Manager. Do not use a mix of Tivoli Provisioning Manager for Software and Tivoli Configuration Manager.
Byte-level differencing Software package version checking Wake-on-LAN Mobile support, software pull capabilities in MDist2 Install source Install repair Device management End user notification
Yes Yes Yes Yes Yes Yes Yes Yes
13.15.2 Unsupported Tivoli Configuration Manager devices

The Tivoli Configuration Manager devices that are not supported by Tivoli Provisioning Manager for Software are the following: Pervasive devices such as: Nokia Palm Windows CE Note: You can keep managing the pervasive devices from the Tivoli Management Framework environment.
13.15.3 Unsupported Tivoli Configuration Manager scenarios

The Tivoli Configuration Manager scenarios that are not supported by Tivoli Provisioning Manager for Software are the following: Using the Pristine tool for creating a repository and storing images for installing an operating system remotely on a clean workstation.
673
Using Data Moving operations to distribute, retrieve, and delete files from workstations. Using the Multicast Management settings to enable data broadcasting to multiple repeaters.
13.15.4 Unsupported Tivoli Configuration Manager actions

The following is a list of unsupported operations for activities: install undoable and all other combinations of the install operation, other than, install transactional remove undoable remove transactional undo accept send, retrieve, delete commit with reboot options pause resume
13.15.5 Activity Planner unsupported options

The following are unsupported options for both replicated plans and for new plans created from the Web User Interface: The static Targets resolution option on the Frequency page of the Plan Properties notebook. The Target resolution at activity execution option on the Target page of the Plan Properties notebook. The Stop on error option on the Execution Time page and the Frequency page of the Plan Properties notebook The Start not before and Complete not after scheduling options can be set from the Execution Time page of the Plan Properties notebook, however, only the Start not before option can be modified at submission time from the Web interface. The Variables page of the Plan Properties notebook. The usage of variables from the Run Activity Plan Advanced wizard. Activity plans containing built-in or custom variables.
674
Activity plans containing activities that are not supported with Tivoli Provisioning Manager for Software are marked as "inoperative" in the list of replicated plans on the Web interface after being replicated. To use this plan, you must remove the activity which is not supported, and recreate the activity to include one of the following supported activities: software management (install, distribute, uninstall), endpoint task, and discovery configuration. The relative Expiration date option on the Frequency page of the Plan Properties notebook and the Priority on the Distribution Options page of the Distribute Properties notebook are valid if defined in Tivoli Configuration Manager plans that have been replicated. Activity plans containing any of the following options will not be replicated during the replication process: Assigned targets of any one of the following types: . user device pristine inventory subscriber Activities with conditioning by depot defined. Activities containing Rembo or Pristine operations. If you need to deploy operating system images using the existing plans, you can continue to use Tivoli Configuration Manager. Otherwise you can either use the bare-metal install feature set based on Rembo Toolkit integrated in Tivoli Provisioning Manager for Software or Tivoli Provisioning Manager for Operating System Deployment. For additional information refer to the Tivoli Provisioning Manager for Software Information Center available from the Web interface. The activity properties options marked as "TMF only options" on the graphical user interface, represent options applicable to only replicated activity plans executed on Tivoli Management Framework targets. The Execution Windows options available at activity level are correctly processed by the Activity Plan Engine only for the start time specifications. This causes the following behavior: the state of an activity, for which the Execution Windows options have been specified, is not showing PAUSED when the specified end time is reached.
675
13.15.6 Software Package Editor unsupported options

The following are limitations of the Software Package Editor when launched from the Web interface: Since the Web Start Software Package Editor runs inside the Web Start application, the language is defined by the client workstation and not by the Internet browser. Click Software Management Manage Software Catalog Groups, expand SoftwarePackages and select any not-built software package from the list. The fields showing the File Name and the Package Path information contain only fictitious information. These file names do not exist under the specified directories. The name of the software package block does not support DBCS characters. The following are limitations of the Software Package Editor when launched from the Eclipse client: Using the eclipse-based Software Package Editor with a user ID different from tioappadmin, you are able to open and upload any built software package belonging to the Default Access Group, while if you create a new software package, the Software Package Editor is not able to associate the software package to any Default Access Group. In this case, you must assign it manually to the Default Access Group from the Tivoli Provisioning Manager for Software Web interface. The name of the software package block does not support DBCS characters.
13.15.7 Considerations on migrated activity plans

After the migration process the activity plans can show one of the following status: Completed This is a plan that you can submit for execution. Draft This is a plan that cannot be submitted. This was a draft plan before replication took place, it was a plan still under preparation. You can edit the plan and then save it as a template to run it in the future. Inoperative This is a plan that contains an activity which is not supported after migration. You must edit the plan by deleting the activity containing the operation that is not supported and recreate the activity to contain a supported operation.
676
After replicating the Tivoli Management Framework data to Tivoli Provisioning Manager for Software DCM, you can assign both Tivoli common agent targets and replicated target computers to the replicated activity plan.
13.15.8 Considerations on migrated software packages

The name of a migrated software package becomes name#region, where name is the name of the software package before migrating and region is the name of the region to which the software package belongs. You cannot install a software package on a managed node. If you want to replicate a software package using the Tivoli Provisioning Manager for Software command line, you should specify only the software package name without any software package version, by running the following command: tcmReplicate -s package_name#region_name Where: package_name Is the name of the Tivoli Configuration Manager software package you want to replicate region_name is the name of the Tivoli Management Region where the software package resides. All the software package versions of the software package specified in the command are replicated. Important: A replicated Tivoli Configuration Manager software package block (SPB) may fail when published or distributed to a new depot server and Tivoli common agent targets. However, you can publish and distribute replicated SPBs to the Tivoli Management Framework environment and Tivoli management agent targets. You can also publish and distribute newly created SPBs (in Tivoli Provisioning Manager for Software V5.1) to both environments.
13.15.9 Identifying reports after the migration process

After replicating the Tivoli Management Framework data, a subset of the existing Framework queries is migrated. Migrated reports are added to the Reports Other view of the Tivoli Provisioning Manager for Software Web User Interface. These reports show the original names of the Tivoli Management Framework queries. The data returned by these reports are collected by querying the DCM
677
database. When running these reports, they return data about both Tivoli common agent and Tivoli management agent endpoints. The new reports which have been added to the Other view are of different types: RAM memory reports Reports showing as a result a list of computers having RAM memory larger than a specified value. Operating System reports Reports showing as a result a list of computers having the specified operating system. Inventory reports Reports showing basic Inventory hardware data. Table 13-13 on page 678 shows the queries that are migrated to reports which are added to the Other view:
Table 13-13 Migrated reports Type of report Report name
CM_STATUS_QUERY COMPUTER_MEM_QUERY
COMPUTER_QUERY
Change management status query Computer memory information Computer system information Hard disk information Basic Inventory hardware query Keyboard information Modem information Mouse information Installed software information Operating system information Partition information Printer information Count of installed processors per workstation Processor information SMBIOS general information
HDISK_QUERY INVENTORY_HWARE KEYBOARD_QUERY

MODEM_QUERY MOUSE_QUERY NATIV_SWARE_QUERY OS_QUERY PARTITION_QUERY
PRINTER_QUERY PROCESSOR_NUM_QUERY PROCESSOR_QUERY SMBIOS_DATA_QUERY
678
Type of report
Report name
STORAGE_DEV_QUERY SWDISTDATA_QUERY USB_DEV_QUERY VID_CARD_QUERY
Storage information Software Distribution query USB device information Video card information
Figure 13-25 on page 679 shows how the reports look like after the migration. They are listed in the Other category:
Figure 13-25 Migrated reports
Figure 13-26 on page 680 shows an example of a HDISK_QUERY report execution.
679
Figure 13-26 HDISK_QUERY report execution
13.16 Activity mappings

This section provides a reference of the mappings between IBM Tivoli Management Framework and Tivoli Configuration Manager activities and the corresponding activities available from the Tivoli Provisioning Manager for Software Web User Interface. The information is divided into the following sections: Software Distribution activities Activity Planner activities Inventory activities
680
13.16.1 Software Distribution activities

Table 13-14 on page 681 provides mappings between the Software Distribution activities of Tivoli Configuration Manager and Tivoli Provisioning Manager for Software.
Table 13-14 Software Distribution activities mapping Tivoli Configuration Manager activities Install, Commit Transaction install Remove Load Unload Send, Retrieve, Delete Tivoli Provisioning Manager for Software activities Software Management Install Software Management Distribute Software Management Uninstall Software Management Publish Software Management Unpublish Not supported
The Software Package object does not have a one to one relation with any Tivoli Provisioning Manager for Software object, the mapping process produces two different objects into the data model: Software definition to store the package definition in terms of name and version Software Installable, which represents the binaries and files to install. It stores the following properties: if the package is built or not built the package OID the region id.
13.16.2 Activity Planner activities

Table 13-15 on page 681 describes the mapping between activity plans and workflows.
Table 13-15 Activity Planner mapping Activity Planner actions Software Distribution Tivoli Provisioning Manager for Software actions Software Management
681
Activity Planner actions Install Commit a previous transactional installation Transactional install Remove Load Unload Send Retrieve Delete Inventory Task Run Inventory Scan Task Libray Run Tivoli Management Framework Task
Tivoli Provisioning Manager for Software actions Install Distribute Uninstall Not supported Not supported Not supported Not supported Not supported Discovery Configuration Run Discovery Endpoint Task Run Endpoint Task
13.16.3 Inventory activities

Table 13-16 on page 682 provides a mapping between the Inventory activities of Tivoli Configuration Manager and Tivoli Provisioning Manager for Software.
Table 13-16 Inventory activities mapping Tivoli Configuration Manager activities Distribute Inventory Run Inventory Profile Tivoli Provisioning Manager for Software activities Inventory Manage Discovery Discovery Configurations Run
682
14
Chapter 14.
Tivoli Configuration Manager migration case studies

This chapter describes coexistence and migration scenarios with Tivoli Provisioning Manager for Software V5.1 and Tivoli Configuration Manager V4.2.3 architectures and has the following sections: Introduction to case studies on page 684 Scanning Tivoli endpoint on page 685 ReportManager on page 698 Distributing software to Tivoli endpoints on page 699 Migrating the Tivoli environment to Tivoli Provisioning Manager on page 717 Using Activity Planner on page 734
683
14.1 Introduction to case studies

For the case studies we use a Tivoli Management Region server running on an AIX host milan, with 3 AIX endpoints in several European cities and one remote branch location in Antwerp with a gateway servicing 3 Windows endpoints. We have connected the Tivoli Management Region to Helsinki that is hosting the Beta1 release of Tivoli Provisioning Manager for Software. Figure 14-1 on page 684 shows our case study environment:
Region: DataCenterRegion
TPM Helsinki Win2003 9.3.5.52
Head Office
Depot Upload Server Nice Win2003 9.3.5.88 TMR Server GW milan-gw LCF milan-ep AIX 9.3.5.57 Admin Admin Workstations Workstations
Existing TMR Europe Data Center
Install Server Prov006 Win2003 9.3.5.26
LCF belfast-ep AIX 9.3.5.53
LCF rome-ep AIX 9.3.5.54
LCF elpaso-ep AIX 9.3.5.73
Zone: AustinDepotZone, Scope: 9.3.5.88-9.3.5.89
Remote data center

Server Maldon Win2003 9.3.5.203 Server Southend Win2003 9.3.5.131
Zone: EuropeDataCenter, Scope: 9.3.5.53-9.3.5.73 Group: EuropeDataCenterTargets
Belgium Data Center

GW prov003-gw LCF prov003-ep Win2003 9.3.5.22
Zone: EssexDataCenter, Scope: 9.3.5.130-9.3.5.205 Group: EssexDataCenterTargets
LCF
LCF prov002-ep Win2003 9.3.5.20
Region: BranchRegion
prov001-ep Win2003 9.3.5.39
Remote branch
Depot Oslo SUSE Linux 9.3.5.49 Zone: BelgiumDataCenter, Scope: 9.3.5.20-9.3.5.39 Group: BelgiumDataCenterTargets
Workstation Amsterdam WinXP 9.3.5.47
Workstation Copenhagen WinXP 9.3.5.48
Workstation Edinburg WinXP 9.3.5.50
Zone: Branch01, Scope: 9.3.5.47-9.3.5.50 Group: Branch01Targets (does not include Depot)
Figure 14-1 Case study environment
We cover following scenarios: Manage the Tivoli infrastructure with the Tivoli Provisioning Manager server. Run Tivoli scan.
684
Run Tivoli Provisioning Manager discovery. Distribute Tivoli SPB. Distribute Tivoli Provisioning Manager Software Product. Migrate the Tivoli infrastructure to Tivoli Provisioning Manager. Run activity plans in the SOA environment. Important: The scenarios in this chapter have been performed on Tivoli Provisioning Manager for Software Beta code and there might be slight differences with he GA code. Please keep this in mind when following the scenarios.
14.2 Scanning Tivoli endpoint

Note: The following scenarios are run on helsinki.itsc.austin.ibm.com, running the Tivoli Provisioning Manager for Software Beta 1 program. In this section we describe performing both a Tivoli scan and a Tivoli Provisioning Manager V5.1 scan on a Tivoli endpoint.
14.2.1 Running InventoryConfig scan from Tivoli Provisioning Manager V5.1

After linking the TMR server to the Tivoli Provisioning Manager V5.1 server and after the replication, as performed in Figure 14-2, we are able to see all InventoryConfig profiles defined in the Tivoli Management Region by selecting Inventory Manage Discovery Discovery Configurations. The profiles belong to the Inventory-PM#milan-region discoveryAG AccessGroup and are marked with the #region suffix notation.
Chapter 14. Tivoli Configuration Manager migration case studies
685
Figure 14-2 Replicated InventoryConfig profiles
Also the Tivoli endpoints and managed nodes are shown (Figure 14-3 on page 687) with the #milan-region suffix in the list of computers, as shown in Manage Manage Inventory Computers. A group ENDPOINT-milan.itsc.austin.ibm.com is created containing all endpoints of the milan-region TMR. For endpoints that are scanned before the replication we have the inventory data available in Tivoli Provisioning Manager. The Tivoli Provisioning Manager replication links through DB2 nicknames or Oracle directly to the Tivoli Management Region Inventory RDBMS database and copies the Inventory data into the Tivoli Provisioning Manager TC database, so it becomes visible in the DCM.
686
Figure 14-3 Replicated scanned endpoint elpaso-ep Inventory data
The replicated endpoint has a Service Access Point (SAP) of TestTmfPep, as shown on the Credentials tab (Figure 14-4 on page 688).
687
Figure 14-4 Tivoli endpoint credentials
We run a hardware scan on a Windows endpoint and an AIX endpoint. There is no difference between running a Tivoli Provisioning Manager discovery and running a Tivoli scan. 5. Click on the More Actions button on the right of the Inventory#milan row as shown in Figure 14-2 on page 686 and select Run from the menu. 6. Check milan-ep and prov001-ep endpoints and click Submit. See Figure 14-5.
688
Figure 14-5 Initiate Tivoli inventory scan
The inventory scan is launched by Tivoli Provisioning Manager on the TMR server, where we can use Tivoli commands to verify progress of the scan distribution and data collection. See Example 14-1.
Example 14-1 Tivoli Provisioning Manager initiated Tivoli scan
[root@milan][/]-> wgetscanstat -a -f -p -s Scan ID: Distribution ID: Profile name: Start time: Elapsed time: Clients completed: Clients pending: 6 1536006190.6 Inventory Tue Sep 12 17:32:11 CDT 2006 0 Days 0 Hours 0 Minutes 28 Seconds 0 2
689
The following clients have successfully completed: The following clients have failed: The following clients are still pending: milan-ep prov001-ep [root@milan][/]-> wgetscanstat -a -f -p -s Scan ID: 6 Distribution ID: 1536006190.6 Profile name: Inventory Start time: Tue Sep 12 17:32:11 CDT 2006 Elapsed time: 0 Days 0 Hours 0 Minutes 47 Seconds Clients completed: 1 Clients pending: 1 The following clients have successfully completed: prov001-ep The following clients have failed: The following clients are still pending: milan-ep [root@milan][/]-> wgetscanstat -a -f -p -s No scans using the Inventory status collector are in progress. [root@milan][/]-> wmdist -lvi 1536006190.6 Distribution ID: 1536006190.6 Name: Inventory Owner: root@milan Size: 5 Source Application: Inventory Source Node: 1536006190.1.605 Start Time: 2006.09.12 17:32:13 Finish Time: 2006.09.12 17:32:51 Expire Time: 2006.09.15 17:32:11 Update Time: 2006.09.12 17:32:51 Targets: 2 Complete: 2(100%) Waiting: 0 Paused: 0 Ready: 0 Unavailable: 0 Receiving: 0 Interrupted: 0 Sending: 0 Successful: 2 Failed: 0 Canceled: 0 Rejected: 0
690
Expired: 0 Stored: 0 [root@milan][/]-> wmdist -q 1536006190.6 milan (SUCCESSFUL) |--prov003.itsc.austin.ibm.com (SUCCESSFUL) | |--prov001-ep (SUCCESSFUL) | |--milan-ep (SUCCESSFUL) The discovery stays in progress until all data is sent back to the Tivoli Provisioning Manager server by the Tivoli ReportManager. See Figure 14-6.
Figure 14-6 Track task details of the Inventory scan discovery
We have the inventory data in the DCM, there is no need to replicate as the Discovery task itself triggers the replication.
691
7. To view the collected inventory data, click on one of the targets in the lower pane, or select Inventory Manage Inventory Computers to select a computer. See Figure 14-7.
Figure 14-7 DCM data collected through Tivoli scan discovery
Note: While working with the Tivoli Provisioning Manager for Software Distribution beta code, we noted a problem with repeated runs of the replication. When a TME endpoint is not scanned before the replication and is scanned for the first time through the Tivoli Provisioning Manager engine, a duplicate row is created in Manage Manage Inventory Computers for that endpoint. The replicate script fails until we remove the duplicate row. 8. Whenever you create new resources in the Tivoli Management Region which you want to access from Tivoli Provisioning Manager, you need to run the
692
replicate script again to populate the Tivoli Provisioning Manager DCM with the new objects. The logic for keeping Tivoli Provisioning Manager synchronized with Tivoli Configuration Manager by cleaning-up Tivoli Configuration Manager objects not existing anymore is based on the following assumptions: If a Tivoli Configuration Manager object is removed after the replication took place, next replication remove it from Tivoli Provisioning Manager. If, by mistake, an administrator creates a Tivoli Provisioning Manager object that does not have a correspondent in Tivoli Configuration Manager, it is removed during the next replication. If a Tivoli Configuration Manager object is modified on the Tivoli Configuration Manager side so that its object ID is different than the original one, Tivoli Provisioning Manager removes the object that has no corresponding object ID in Tivoli Configuration Manager and creates a brand-new Tivoli Provisioning Manager object having the new object ID.
14.2.2 Running Tivoli Provisioning Manager hardware discovery on Tivoli endpoint

We can also run a standard Tivoli Provisioning Manager discovery on a Tivoli endpoint. 1. Create a Discovery Configuration ITSO - SOA Inventory discovery HW only from the nagivation pane by selecting Inventory Manage Discovery Discovery Configurations, and clicking Edit Add Discovery Configuration. We selected Hardware only as scope. The Discovery Configuration can be used on Tivoli Common Agents as well as on Tivoli endpoints. 2. Invoke the Inventory discovery on the prov002-ep and prov003-ep endpoints, by selecting Run from the More Action button (Figure 14-8 on page 694).
693
Figure 14-8 SOA Inventory discovery in progress
When a Tivoli Provisioning Manager discovery configuration is launched for the first time in a Tivoli Management Region, a top level policy region TPM_Region is created. Within the region a profile manager TPM_Inv_ProfileManager and the actual InventoryConfig profile are created with the converted Tivoli Provisioning Manager hardware and/or software discovery configuration.
Example 14-2 InventoryConfig profile created from Tivoli Provisioning Manager discovery configuration
[root@milan][/]-> wls /Regions/ milan-region Inventory-region SWD-region Task-region TPM_Region [root@milan][/]-> wls /Regions/TPM_Region
694
TPM_Inv_ProfileManager [root@milan][/]-> wls /Regions/TPM_Region/TPM_Inv_ProfileManager ITSO - SOA Inventory discovery HW only [root@milan][/]-> wgetinvpchw "/Regions/TPM_Region/TPM_Inv_ProfileManager/ITSO - SOA Inventory discovery HW only" Run Tivoli Scanner: YES Update the hardware scan results in the configuration repository: YES Data to scan: Processor:YES Memory:YES Memory Modules:YES Operating System:YES Storage:YES IP Address:YES Modem:YES Network Adapter:YES Partition:YES PC System Params:YES PCI Device:YES Pointing Device:YES SMBIOS:YES Keyboard:YES IPX Address:YES Video:YES Printer:YES USB Device:YES Service Info:YES Run DMI Scanner: NO Update the DMI scan results in the configuration repository: NO [root@milan][/]-> wgetinvunixhw "/Regions/TPM_Region/TPM_Inv_ProfileManager/ITSO SOA Inventory discovery HW only" Run Tivoli Scanner: YES Update the hardware scan results in the configuration repository: YES Data to scan: Processor:YES Memory:YES Memory Modules:YES Operating System:YES Storage:YES IP Address:YES Network Adapter:YES Partition:YES PCI Device:YES Pointing Device:YES SMBIOS:YES
695
Keyboard:YES UNIX System Params:YES Lpar:YES [root@milan][/]-> wgetinvpcsw "/Regions/TPM_Region/TPM_Inv_ProfileManager/ITSO - SOA Inventory discovery HW only" Scan for and update basic file information: NO Cyclic Redundancy Check: No CRC Scan for and update header information: NO Scan for and update PC registry information: NO Scan for and update matching software signatures: NO Apply custom filter to basic file information scan results: NO Executable files only: NO Enable Patch Management scan: NO Do not send files <catalog$(platform).txt> to the Endpoint: NO Do not send the file <wsusscan.cab> to the Endpoint: NO [root@milan][/]-> wgetinvunixsw "/Regions/TPM_Region/TPM_Inv_ProfileManager/ITSO SOA Inventory discovery HW only" Scan for and update basic file information: NO Cyclic Redundancy Check: No CRC Scan for and update Unix product and patch information: NO Scan for and update matching software signatures: NO Apply custom filter to basic file information scan results: NO Executable files only: YES Do not send files <catalog$(platform).txt> to the Endpoint: NO [root@milan][/]-> wgetinvglobal "/Regions/TPM_Region/TPM_Inv_ProfileManager/ITSO SOA Inventory discovery HW only" Distribution option: Distribute configuration file and run scan (ALL) Endpoint timeout:1800 seconds Log file pathname: Log file host: Notice location:NOTICE_GROUP Distribution shown to mobile users:NO Notice interval:DONE Distribution allowed to non-subscribers:NO Notice type:ALL Data option: Update with differences (DIFFS) Distribution uses wake on LAN technology:YES [root@milan][/]-> A new InventoryConfig profile is automatically created the first time an unknown Tivoli Provisioning Manager discovery configuration is run in the Tivoli Management Region.
696
The conversion of the Common Inventory Technology discovery operation follows the rules described in Table 14-1.
Table 14-1 Tivoli Provisioning Manager discovery conversion to TCM InventoryConfig Scan type Hardware Resources Computer OS platform Storage CDRom & floppy Memory CPU Video Keyboard Mouse Printer Network USB devices Modem BIOS Registry Signatures Selected Signatures Tivoli Configuration Manager comparision All the related resources are discovered. No finer granularity is provided.
Software
Tivoli Configuration Manager file basic and header scan apply only to migrated Discovery Configurations. Selected Signature scan not supported on TMA targets
Global properties are ignored. HW properties: The PC DMI Scanner is ignored. If any other Hardware property (PC or Unix) is selected the Hardware property is set in the migrated Tivoli Provisioning Manager Discovery. SW Properties: PC Scan for Patches Information is ignored. If any other Software property (PC or UNIX) is selected the Software property is set in the migrated Tivoli Provisioning Manager Discovery. If Signature Scan or Registry Scan is set, the equivalent option is set in the migrated Tivoli Provisioning Manager Discovery. Custom scripts and MIF files are currently not supported.
697
Pervasive Devices are currently not supported.
14.3 ReportManager
The ReportManager is a new Tivoli component that is responsible to forward the results of Tivoli Configuration Manager operations initiated from the Tivoli Provisioning Manager back to the Tivoli Provisioning Manager server. It acts as a daemon, that is working on a queue such as the APM queues. The queue is located in $BINDIR/ReportManager/work. All files in this directory are reports that still need to be sent to the Tivoli Provisioning Manager server. Tracing can be enabled by the new wrepmgrcfg command. Logging and tracing is to be found in the $BINDIR/ReportManager/rep.log and $BINDIR/ReportManager/rep*.trc files. The ReportManager also logs all activity in the REP_MANAGER table in the Inventory RDBMS. See Example 14-3.
Example 14-3 REP_MANAGER table
[root@milan][/]-> su - db2inst1 [db2inst1@milan][/home/db2inst1]-> db2 connect to INV_DB Database Connection Information Database server SQL authorization ID Local database alias = DB2/6000 8.2.4 = DB2INST1 = INV_DB
[db2inst1@milan][/home/db2inst1]-> db2 describe table rep_manager Column name -----------------------------DIST_ID STATUS TARGET RECORD_TIME MESSAGES 5 record(s) selected. Type schema --------SYSIBM SYSIBM SYSIBM SYSIBM SYSIBM Type name Length Scale Nulls ------------------ -------- ----- -----VARCHAR 32 0 No INTEGER 4 0 No VARCHAR 64 0 No TIMESTAMP 10 0 No VARCHAR 256 0 Yes
698
[db2inst1@milan][/home/db2inst1]-> db2 select dist_id,status,target,record_time,substr$messages,1,80$ from rep_manager where dist_id=\'1536006190.6\' DIST_ID RECORD_TIME STATUS 5 TARGET
-------------------------------- --------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------1536006190.6 6 1536006190.9.522+#TMF_Endpoint::Endpoint# 2006-09-12-17.33.01.391929 The distribution succeeded on the following clients: prov001-ep milan-ep 1536006190.6 6 1536006190.2.522+#TMF_Endpoint::Endpoint# 2006-09-12-17.33.01.395800 The distribution succeeded on the following clients: prov001-ep milan-ep 2 record(s) selected.
14.4 Distributing software to Tivoli endpoints

In this section we describe the distribution of both an imported Tivoli software package and a Tivoli Provisioning Manager software product to the Tivoli endpoints. First explain Tivoli Provisioning Manager concepts in respect to the Tivoli Configuration Manager environment.
14.4.1 Tivoli Provisioning Manager concepts and Tivoli Configuration Manager

In Tivoli Provisioning Manager for Software V5.1 a software product is an object wrapping one or more software installables (binary files) having the same business objective, each of them matching a particular target type. The right installable is chosen by the Tivoli Provisioning Manager for Software server matching its requirements with the capabilities declared by the target.
699
When a software product is a software package block (SPB), either migrated from Tivoli Configuration Manager or newly created with the Eclipse software package editor, it contains only one installable that is the SPB binary itself. The requirement for a SPB software installable is the software installation engine (SIE) subagent running on the targets. On TCA targets, the bundle called SPBHandler is in charge of performing the actual job against SPBs. The SPBHandler bundle holds the Tivoli Configuration Manager software installation engine in the form of the disconnected command line interface (For example wdinstsp, wdrmvsp etc). On Tivoli Configuration Manager endpoints, the actual SIE dependency is used. For this reason, software products wrapping an SPB can be installed on both LCF and TCA targets. For each software product installed on a given target a software installation object is created and stored. The entire set of software installation objects associated to a computer represents its software catalog. Table 14-2 shows how Tivoli Provisioning Manager operations map to Tivoli Configuration Manager operations.
Table 14-2 Tivoli Configuration Manager/Tivoli Provisioning Manager operations Tivoli Provisioning Manager Operation Publish Unpublish Distribute Install Uninstall TCM Operation
Load Unload Install transactional Install Commit, if the package was distributed before Remove Rollback, if the package was distributed before and no commit action was performed
mapping
Note: Currently not all Tivoli Configuration Manager operations are supported in Tivoli Provisioning Manager, noteably undoable installations and auto-commit or verify operations.
700
Tivoli Provisioning Manager for Software operations behave differently depending the target type: Publish SOA picks the SPB from its source location and makes it available on a Content Distribution Service (CDS) depot. TMF invokes a Load command of the related SPB on a specified Tivoli Configuration Manager depot. Unpublish SOA removes the related SPB from the CDS depot. TMF invokes an Unload command of the related SPB from the Tivoli Configuration Manager depot. Distribute SOA stores the related SPB in a temporary cache of the remote targets by downloading it from the CDS depot if a previous Publish was issued. If the SPB is not previously published, the SPB gets published and distributed afterwards. No actual installation is performed. TMF invokes a transactional installation of the related SPB on the specified targets. Install SOA invokes a straightforward installation of the cached SPB on the SPBHandler subagent running on the targets if both Publish and Distribute is previously issued against the related SPB. If one or both of the Publish and Distribute operations is not performed before, SPB gets published and/or distributed before being installed. TMF invokes a commit command on the given targets, if a Distribute is previously issued against the related SPB. If no Distribute operation is performed before, a straightforward Install is issued. Uninstall SOA invokes the removePackage operation exposed by the SPBHandler subagent running on the TCA target. TMF invokes a rollback operation if the SPB is previously Distributed (installed transactionally), otherwise a straightforward Remove operation is issued.
14.4.2 Distributing software package to Tivoli endpoint

1. The replicated ITPMfSW_Beta_Viewlet#milan-region software product in the Tivoli Provisioning Manager software catalog is accessible from Software
701
Management Manage Software Catalog Software Products. See Figure 14-9.
Figure 14-9 Software catalog
2. When we click ITPMfSW_Beta_Viewlet#milan-region software product, we open the software definition page. See Figure 14-10.
702
Figure 14-10 Software definition page of replicated ITPMfSW_Beta_Viewlet
The #milan-region suffix points to the the fact that the software product is a replicated Tivoli Configuration Manager software package block. 3. Click ITPMfSW_Beta_Viewlet#milan-region installable files to open the software installable page, which shows the name of the software package block, and its location on the file repository milan#milan-region. The requirement window displays the requirement for the software installation engine (SIE). See Figure 14-11.
703
Figure 14-11 Software installable page of replicated ITPMfSW_Beta_Viewlet
The Variables tab shows the Tivoli object ID of the software package block. Only built software packages can be replicated.
Figure 14-12 Variables tab of the ITPMfSW_Beta_Viewlet installable Example 14-4 Tivoli management region software package object id.
[root@milan][/]-> wlookup -r SoftwarePackage ITPMfSW_Beta_Viewlet.5.1
704
1536006190.1.1044#SoftwarePackage::Spo# The Tivoli object IDs of replicated software packages can also be found on the Variables tab of the software definition page. A software package block is not copied during the replicate phase, only its definition. The actual SPB stays on the Tivoli Management Region sourcehost file repository. When the software product is installed, distributed or published for the first time in the SOA environment, the TMF_FileRepository_GetFile workflow is invoked to upload the software installable to the preferred upload depot server. Likewise, if you install, distribute or publish an SPB software installable defined on the Tivoli Provisioning Manager server for the first time to a Tivoli Configuration Manager endpoint, the TMF_FileRepository_PutFile is invoked to send the SPB to the Tivoli Management Region server and create a new SPB on the fly.
Submitting installation
1. From Software Management Install Software Products, we open the Install Software Products page, as shown in Figure 14-13 on page 706.
705
Figure 14-13 Submit install ITPMfSW_Beta_Viewlet software product
2. Change the task name to something meaningful that can be recognized in the task tracking page. 3. Search and filter the Software and Computer view for Viewlet and Windows endpoints in the milan-region, and select the objects by checking the box. The software and targets move to the selected list on the right side. Click Submit.
706
Tracking installation task

1. Track progress and status of the installation task from Task Management Track Task. See Figure 14-14.
Figure 14-14 Track installation task
2. Filter the view on Task Name in Install viewlet. We see the task in progress. 3. Click the name of the task,to open the Task Details page. We notice that the distribution is succesfully finished. See Figure 14-15.
707
Figure 14-15 Task details ITPMfSW_Beta_Viewlet installation
The Tivoli Provisioning Manager server launched a standard installation on the Tivoli Management Region, as we see in Example 14-5.
Example 14-5 Tivoli Provisioning Manager initiated Software package installation
[root@milan][/]-> wmdist -l Name Distribution ID Targets Completed ITPMfSW_Beta_Viewlet.5.1 (install) 1536006190.12 3(100%) 0( 0%) [root@milan][/]-> wmdist -q 1536006190.12 milan (SUCCESSFUL) |--prov003.itsc.austin.ibm.com (SUCCESSFUL) |--prov002-ep (SUCCESSFUL) |--prov003-ep (SUCCESSFUL) |--prov001-ep (SUCCESSFUL) [root@milan][/]-> wmdist -e 1536006190.12
Successful Failed 3 3(100%)
708
Name Status Start Time End Time milan SUCCESSFUL 2006.09.18 17:27:03 2006.09.18 17:27:22 prov003.itsc.austin.ibm.com SUCCESSFUL 2006.09.18 17:24:33 2006.09.18 17:25:34 prov001-ep SUCCESSFUL 2006.09.18 17:24:33 2006.09.18 17:25:34 prov002-ep SUCCESSFUL 2006.09.18 17:24:33 2006.09.18 17:25:33 prov003-ep SUCCESSFUL 2006.09.18 17:24:33 2006.09.18 17:25:29 [root@milan][/]-> wmdist -lvi 1536006190.12 Distribution ID: 1536006190.12 Name: ITPMfSW_Beta_Viewlet.5.1 (install) Owner: root@milan Size: 9111 Source Application: Software Distribution Source Node: 1536006190.1.605 Start Time: 2006.09.18 17:27:03 Finish Time: 2006.09.18 17:28:23 Expire Time: 2006.09.21 17:27:00 Update Time: 2006.09.18 17:28:23 Targets: 3 Complete: 3(100%) Waiting: 0 Paused: 0 Ready: 0 Unavailable: 0 Receiving: 0 Interrupted: 0 Sending: 0 Successful: 3 Failed: 0 Canceled: 0 Rejected: 0 Expired: 0 Stored: 0
14.4.3 Distributing a software product to a Tivoli endpoint

Only software products with SPB installables are distributed to Tivoli endpoints. In this scenario we will use a simple SPB file, called AppA_v1.0.spb. You can download this file from the ITSO Web site using the instructions in Appendix B, Additional material on page 835. Do the following to distribute AppA_v1.0 version 1.0 to endpoints belonging to TMR milan-region.
709
Schedule and submitting distribution

1. Select Software Management Install Software Product and select the AppA_v1.0 from the list or start from Software Management Manage Software Catalog Software Products. 2. Filter the view on Name App. Click on the more actions button of AppA_v1.0 version 1.0 and select Install, as shown in Figure 14-16 on page 710.
Figure 14-16 Install software product from catalog
3. On Install Software Products page, the AppA_V1.0 is selected. View the target list By Computer, filtered on prov. The operation does not look different compared to installing software on TCA targets.
710
Figure 14-17 Install Software products on Tivoli endpoints
4. Schedule the installation in future by selecting At following time. From the Advanced page separate the Distribute phase from the install phase, by selecting Distribute prior to installation. The distribute time must be between now and the installation time. In our case we select 2:40 p.m. for the installation time, and 2:30 p.m. for distribution time. See Figure 14-18.
711
Figure 14-18 Advanced options to install software
5. Click Submit.
Tracking distribution and installation task

1. Select Task Management Track Tasks to see the installation job in scheduled state. See Figure 14-19.
712
Figure 14-19 Track AppA_v1.0 installation task
2. Click the task to see the details page, as seen in Figure 14-20 on page 714.
713
Figure 14-20 Installation task details
By splitting the distribute and install time, Tivoli Provisioning Manager actually generates two jobs, which get translated on the TMF infrastructure in a transactional install and a commit operation. At the scheduled time, we
see the software package is created in TPM_Swd_ProfileManager in the TPM_Region See the transactional distribution starting at 14:31. The clocks are not exactly synchronized between the Tivoli Provisioning Manager and TMR servers, and the Tivoli endpoints. At around 14:40 the commit operation is triggered.
714
Example 14-6 TMF activities when distributing and installing a software product
[root@milan][/]-> wls /Regions/TPM_Region TPM_Inv_ProfileManager TPM_Swd_ProfileManager [root@milan][/]-> wls /Regions/TPM_Region/TPM_Swd_ProfileManager AppA_v1.0.1.0.1.0 [root@milan][/]-> wlookup -r SoftwarePackage AppA_v1.0.1.0.1.0 1536006190.1.1061#SoftwarePackage::Spo# [root@milan][/]-> wmdist -l Name Distribution ID Targets Completed Successful Failed ITPMfSW_Beta_Viewlet.5.1 (install) 1536006190.12 3 3(100%) 3(100%) 0( 0%) AppA_v1.0.1.0.1.0 (install) 1536006190.13 3 3(100%) 3(100%) 0( 0%) AppA_v1.0.1.0.1.0 (commit) 1536006190.14 3 3(100%) 3(100%) 0( 0%) [root@milan][/]-> wmdist -e 1536006190.13 Name Status Start Time End Time milan SUCCESSFUL 2006.09.19 14:31:32 2006.09.19 14:31:40 prov003.itsc.austin.ibm.com SUCCESSFUL 2006.09.19 14:28:49 2006.09.19 14:29:10 prov001-ep SUCCESSFUL 2006.09.19 14:28:49 2006.09.19 14:29:10 prov002-ep SUCCESSFUL 2006.09.19 14:28:49 2006.09.19 14:29:10 prov003-ep SUCCESSFUL 2006.09.19 14:28:49 2006.09.19 14:29:10 [root@milan][/]-> wmdist -lvi 1536006190.13 Distribution ID: 1536006190.13 Name: AppA_v1.0.1.0.1.0 (install) Owner: root@milan Size: 3377 Source Application: Software Distribution Source Node: 1536006190.1.605 Start Time: 2006.09.19 14:31:32 Finish Time: 2006.09.19 14:32:02 Expire Time: 2006.09.22 14:31:30 Update Time: 2006.09.19 14:32:02 Targets: 3 Complete: 3(100%) Waiting: 0 Paused: 0 Ready: 0 Unavailable: 0 Receiving: 0 Interrupted: 0 Sending: 0 Successful: 3
715
Failed: 0 Canceled: 0 Rejected: 0 Expired: 0 Stored: 0 [root@milan][/]-> wmdist -lvi 1536006190.14 Distribution ID: 1536006190.14 Name: AppA_v1.0.1.0.1.0 (commit) Owner: root@milan Size: 0 Source Application: Software Distribution Source Node: 1536006190.1.605 Start Time: 2006.09.19 14:41:17 Finish Time: 2006.09.19 14:41:20 Expire Time: 2006.09.22 14:41:17 Update Time: 2006.09.19 14:41:20 Targets: 3 Complete: 3(100%) Waiting: 0 Paused: 0 Ready: 0 Unavailable: 0 Receiving: 0 Interrupted: 0 Sending: 0 Successful: 3 Failed: 0 Canceled: 0 Rejected: 0 Expired: 0 Stored: 0 Note: A defect is raised on the wrong version info of the package. A dot or caret character is not allowed in the Software Product, because it is used as a version delimiter in Tivoli Configuration Manager, and the disconnected SWD CLI used in the SPBHandler subagent.
716
Figure 14-21 Track task results
When the ReportManager sents the results back to the Tivoli Provisioning Manager server, we see the results of the installation as shown in Figure 14-21 on page 717.
14.5 Migrating the Tivoli environment to Tivoli Provisioning Manager

The GA version of the Tivoli Provisioning Manager for Software will include SPBs to install the TCA using Tivoli Configuration Manager. At the time of writing of this redbook, these SPBs were not yet available. Use the Install_Agent workflow to install the TCA and Install_CDS_Depot workflow to create DCD depots.
717
For the new infrastructure put all systems in one region, and migrate the Tivoli gateways to DCD depots each in their own zone. The Tivoli endpoints become TCAs, receiving their packages from the depots. Do not enable peering. Keep the Tivoli components on the boxes during the migration phase. Note: For this scenario use the beta 2 of Tivoli Provisioning Manager fS, installed on Tivoli Provisioning Manager cairo.itsc.austin.ibm.com. Link the milan-region TMR server and replicated the TMR resources to the Tivoli Provisioning Manager environment.
14.5.1 Discovering the computers

First we need to discover the computers. Discover the AIX systems with an SSH discovery configuration, for the Windows machines running on SMB discovery. For more information on discovery of the computers, refer to Discovering devices using SSH on page 189 and Discovering devices using SMB on page 177 respectively. This populates the DCM with the computers in our TMR and sets the SAP entries for the system automatically. On AIX systems the file-transfer, execute-command and ping SAP entries are set to SSH-Server. On Windows computers the file-transfer and execute-command SAPs are set to RXA-Server.
14.5.2 Creating the region

A region is just a logical placeholder for zones, a way of grouping systems that act as depot servers. Create a new EuropeRegion, for all system in the Europe TMR. 1. From the Inventory Infrastructure Management Depots window, select Regions, and click Edit Add Region. See Figure 14-22.
718
Figure 14-22 Create Europe region
2. Click Save to create the region.
14.5.3 Creating zones

A zone is not only a way to logically group systems, but it also defines how network traffic flows between the different systems. The DCD service utilizes the zone information to optimize the transfer of data in the Tivoli Provisioning Manager environment.
719
A zone belongs to a region, a depot belongs to a region. You can can have multiple depots in a zone. The scope of a zone is defined as an IP range or DNS subdomain. Because we do not enable peering in our Europe region, we create two zones: EuropeMilanZone and EuropeAntwerpZone, each with one depot so that data only pass once to each zone. 1. From the Inventory Infrastructure Management Depots window, select Zones, and click Edit Add Zone.
Figure 14-23 Create Milan zone in Europe region
2. Make sure the Minimize traffic in and out of zone flag is checked, otherwise systems of other zones initiates a download from this zone.
720
Note: When a zone either has no depot defined, or depots are unavailable network traffic can still be initiated in and out of the zone, even if the flag is checked. 3. Create the EuropeAntwerpZone in the same way, with IP range 9.3.5.20 to 9.3.5.39, also belonging to the EuropeRegion. Note: In a real world environment, a DNS subdomain is more likely to be used. Our lab simulation does not allow this. Note however that elpaso-ep is not located in El Paso, TX, but El Paso, Spain, Gran Canararia: 2839'1.55"N, 1752'41.98"W.
14.5.4 Creating depots

Next create the depots in the zones. Make the gateway managed nodes depots in the TMP environment. Depots are running on Tivoli Common Agents. To install the depots, and thus the TCAs we first need to discover the systems. Run a SSH discovery on the IP range of the AIX systems, and a SMB discovery for the Windows machines, as described in Discovering devices using SSH on page 189 and Discovering devices using SMB on page 177. 1. From the Inventory Infrastructure Management Depots window, select Depots, and click Edit Add Depot.
721
Figure 14-24 Create depot on milan
2. Enter Fully qualified host name of the depot server, give the description and place it in the EuropeRegion (See Figure 14-24). Use the adaptive bandwidth control to select the radio button. Clear the Preferred upload server flag, but leave the Install the depot agent services checkbox checked. Provide the root user ID and password. Specify on which computer to install the depot, this is the computer discovered by the SSH Discovery. Change the Data
722
Directory limit from the default 2 GB to a larger 5GB. Click Save, and the Install_CDS_Depot workflow starts. Note: Make sure you do not mistype the fully qualified hostname of the depot, as the installation will succeed, but the depot will never become active, and there is no way to change the property later. It takes about eight minutes to install the TCA with associated bundles, and the IBM_Tivoli_Content_Delivery_Service_Depot subagent on the AIX milan server. Add the Windows prov003 depot in the same way, using Administrator as user ID.
Figure 14-25 Task details result depot installation prov003
723
3. Click Request ID to view the detailed installation steps. You can click the target name to go to depot characteristics, as shown in Figure 14-27 on page 725. 4. From Inventory Infrastructure Management Depots the depots are listed as shown in Figure 14-26 on page 724.
Figure 14-26 The depot servers
5. Click a specific depot, to see the characteristics of the depot and its statistics such as files in the depot, bytes transferred and average transfer rate. See Figure 14-27 on page 725.
724
Figure 14-27 Depot characteristics of milan.itsc.austin.ibm.com
6. From Edit Properties change the properties of the depot.
14.5.5 Installing Tivoli common agents

The next step is to install the Tivoli common agents (TCA) on the discovered AIX and Windows computers. In the Tivoli Provisioning Manager for Software Beta release we use, we had to give separate credentials for UNIX computers when installing the common agent. Therefore we split the installation of the TCA by operating system. You do not need install the TCA on the depot servers, as it is part of the CDS Depot softwarestack.
725
1. Open the Install Common Agent window from Software Management Install Common Agent. 2. Switch to the computer view and carefully select the AIX computers as they are discovered by the SSH discovery. Add the credentials for root and click Submit (Figure 14-28 on page 726).
Figure 14-28 Install the AIX common agents in the Europe zone
3. Do the same for the Windows computers prov001 and prov002 in the Antwerp data center, but do not provide the credentials, as the credentials of the RXA-SAP created at the time of the discovery is used. See Figure 14-29.
726
Figure 14-29 Install the Windows common agents in the Antwerp data center
4. Again click Submit. After the successful execution of the Install_Agent workflow on the computers, the endpoints of the milan-region are manageable by both the Tivoli Configuration Manager environment and the Tivoli Provisioning Manager infrastructure. Note: At the time of the writing of the redbook, it was planned to provide - at GA time - Tivoli SoftwarePackageBlocks to install Tivoli Common Agents on the Tivoli endpoints through the Tivoli Configuration Manager environment. This provides a smooth migration path for large infrastructures.
727
14.5.6 Assigning new computers to a group

In order to ease the management of the computers of the newly added data centers, we add the computers to groups. 1. From Inventory Manage Inventory Groups, select Edit Add Group. Create a MilanComputerGroup to which we add all systems belonging to the EuropeMilanZone. Similarly create the AntwerpComputerGroup. 2. Provide the Name and Description for the group. Select the Computer type from the menu and designate it as a Static Group. Add the Tivoli Common Agent systems in Antwerp. Click Save. See Figure 14-30.
Figure 14-30 Create AntwerpComputerGroup
3. Create a EuropeComputergroup to assign the MilanComputerGroup and AntwerpComputerGroup. See Figure 14-31.
728
Figure 14-31 EuropeComputerGroup
14.5.7 Creating SOA service access point on Tivoli Common Agents

In order to be targets of the SOA Scalable Distribution Infrastructure the Tivoli Common Agents must be attributed a SOA-SAP. This service access point, assigned as the default SAP for the endpoint-operations, provides the needed credentials for a secure communications protocol to and from the TCA. There are several ways to add or change the SOA service access point to Tivoli Common Agents. Run the Create_SOA_Endpoint_Operation_SAP workflow on the device ID of the TCA. From Inventory Manage Inventory Computers click Edit Add Credentials and select computers and/or groups to perform the action on. 1. From the computer page, select the Credentials. 2. Select Edit Add Credentials. Choose the second option.
729
Figure 14-32 Select SOA credential
3. Select the SOA credential from the drop down and press Next. See Figure 14-32. 4. In the next page, select Specify target computers. Click Advanced to select EuropeComputerGroup. See Figure 14-33.
730
Figure 14-33 Advanced Search by grouping
5. Click Search. 6. We return to the Specify Targets Computers page with all EuropeComputerGroups systems selected. Select Select All and click Next. See Figure 14-34.
731
Figure 14-34 Specify targets
7. In the Summary page click Finish. See Figure 14-35.
732
Figure 14-35 Add Credential Summary
8. Verify the operation on the Credentials tab of one the computers (Figure 14-36 on page 734). A SOA type must be defined as the default SAP for endpoint-operations. Note: In our Beta release, the soahost is added as a credential to the computers, but we still need to assign the soahost as the default endpoint-operations SAP.
733
Figure 14-36 Set soahost as default endpoint-operations SAP
9. Set soahost as the default endpoint-operations SAP for all Europe systems manually as shown in Figure 14-36.
14.6 Using Activity Planner

Activity Planner is an important component of Tivoli Configuration Manager, and has been brought to the Tivoli Provisioning Manager infrastructure to preserve customers investment and skills into building activity plans.
The Activity Plan Editor (APE) is integrated as a Java applet in the Tivoli Provisioning Manager for Software user interface. It has the same look and feel as Tivoli Configuration Manager V4.3.2, and allows you to browse resources defined in the DCM, and also Tivoli Configuration Manager objects after replication. Existing plans from a linked Tivoli Configuration Manager environment are converted and copied into the new repository at replication time.
734
Currently not all Tivoli Configuration Manager operations and options are supported in plans inside Tivoli Provisioning Manager for Software. Table 14-3 on page 735 shows the mapping between operations Tivoli Configuration Manager and Tivoli Provisioning Manager for Software.
Table 14-3 Activity Planner operation mapping Object Software product Tivoli Configuration Manager activity Install Install transactional Install undoable Commit Accept Undo Remove Remove transactional Remove undoable Load Unload Send Retrieve Delete Discovery configuration Endpoint task Scan Execute task Tivoli Provisioning Manager fS activity Install Distribute NOP Install NOP NOP Uninstall NOP NOP NOP NOP NOP NOP NOP Discovery Execute
Replicated plans with any of the not supported activities (NOP) as described in Table 14-3 are marked as inoperative in the Tivoli Provisioning Manager Activity Planner, and need user modification after migration before becoming runnable. Note: Transactional operations with autocommit options and commit with a reboot are migrated into inoperative plans. Only simple transactional installation is accepted.
735
Plans with any of the following options are converted into inoperative plans, and need user modification: Custom Variables and Built-in Variables (For example $(TARGET_LIST)). Target resolution at activity execution. Static target resolution in recursive plans (only Dynamic is accepted). Relative expiration date in recursive plans. Stop on error. Finally, only a subset of the activity plans existing in the Tivoli Configuration Manager database is migrated during the replication step. The following plans are not replicated: Plans containing targets as Users, Device, Enterprise Directory. Plans containing activities with By Depot conditions. Plans containing Rembo or Pristine activities. The new Activity Planner engine provides a homogeneous way to manage endpoints that are managed by different infrastructures and is designed to address integrated distribution infrastructures including the SOA-based Scalable Distribution Infrastructure (SDI), TMF and Deployment Engine (DE) infrastructure. Performance and scalability are addressed by the design and implementation of the new engine, it is possible to support load balancing. For example, running multiple activity plan engines to support large scale distribution. Activity plans allows mixed targets that are managed by different infrastructures. The engine organizes the targets based on the infrastructure and submits jobs to corresponding infrastructures. Figure 14-37 on page 737 shows the components of the Activity Planner architecture in Tivoli Provisioning Manager for Software environment.
736
submit a plan Activity Plan Engine dispatch Deployment Engine SDI TMF infrastructures
end points
Figure 14-37 Activity Planner architecture
The endpoints can be configured to be handled by a different infrastructure for management operations. Assign the appropriate infrastructure for the job by configuring the Service Access Point (SAP) associated with the endpoint. It can be either SOA for SDI or TMF for legacy TMF infrastructure The Deployment Engine is the default management infrastructure when an endpoint is not assigned the SOA or TMF SAP, or when the operation to be performed is not supported by the infrastructure. Table 14-4 lists the supported operations in the new Activity Planner engine.
Table 14-4 Supported operations Tivoli Provisioning Manager for Software operation Distribute Install Tivoli Provisioning Manager for Software logical device operation SoftwareModule.Distribute Installable SoftwareModule.Install Tivoli Configuration Manager operation Install transactional Install Commit, if the package was distributed before Remove Rollback, if the package was distributed before and no commit action was performed Scan
Uninstall
SoftwareModule.Uninstall
Discovery
Discovery.OnDevice
737
Tivoli Provisioning Manager for Software operation n/a
Tivoli Provisioning Manager for Software logical device operation EndPointTask.Execute
Tivoli Configuration Manager operation ExecuteTask
The following options are supported in the Tivoli Provisioning Manager for Software Activity Planner: Conditions Success All, Fail All, Complete All Success Target, Fail Target, Complete Target Scheduling Start not before Complete not after Stop on overlap Days of week, Days of month, Time Interval, Date Interval Variables Software distribution variables Target resolution Target resolution at each plan instance submission Static resolution for recursive plans Supported targeting Static target list Static computer groups Dynamic through Tivoli Provisioning Manager fS Reports Dynamic through dynamic computer group Targets listed inside a file Any combination of the above
14.6.1 Activity Planner scenario

Once the linkage is defined between the Tivoli Configuration Manager and the Tivoli Provisioning Manager Activity Planner as defined in Inventory Infrastructure Management Tivoli Management Framework, it is possible to replicate Activity Planner plans into the DCM, as shown in Figure 14-38.
738
See Add an activity plan database on page 624 for more details on how to add the activity planner database.
Figure 14-38 APM database properties
Create a simple plan in the Tivoli Configuration Manager Activity Planner. Load a software package block to the gateway in the Antwerp data center, and subsequently install the package on the TMA endpoints. Finally it runs a task on the endpoints. The install activity is conditioned with Success Target condition on the load activity. The task runs on completion of the install activity. The plan is replicated into the DCM by tcmReplicate.cmd and is marked Inoperative in Tivoli Provisioning Manager because of the unsupported Load operation as seen in Task Management Manage Activity Plans. See Figure 14-39.
739
Figure 14-39 Manage Activity Plans
10.Open the Activity Plan Editor by clicking milan.itsc.austin.ibm.com.Plan0 planname. 11.Recognize the Activity Plan Editor as delivered in Tivoli Configuration Manager, with the menu and the different possible activity types in the upper right corner, and graphical representation of the activities of the plan in the lower pane with the arrows used to show activity conditioning and sequencing. 12.A special icon designating the inoperable Load operation is displayed. Open the properties of the not supported activity by right-clicking on the Load Activity and selecting Not Supported Operation Properties (Figure 14-40 on page 741).
740
Figure 14-40 Inoperative plan in the Activity Plan Editor
13.Delete the Load activity to make the plan submittable in Tivoli Provisioning Manager s Activity Planner.
741
Important: Publishing a software product to a DCD depot is functionally the same as loading a software package to a TMF gateway. But currently the publish operation is not available in the Activity Planner of Tivoli Provisioning Manager. The distribute operation to Tivoli Common Agents on the other hand is supported in Tivoli Provisioning Manager Activity Planner, and technically meets our requirement of not sending large amounts of data over the WAN at installation time. The distribution phase always uses the DCD infrastructure, and because we selected Minimize traffic in and out of zone when we created the zone, the content of the SPB transfers only once over the WAN to the depot, from where it is downloaded by the targets. 14.Adapt the plan by changing the load operation into a publish operation, actually delete the activity after removing the condition and create a new one. Change the TMA targets into TCA systems to make use of the Scalable Distribution Infrastructure. 15.Modify the plan in much the same way as used in Tivoli Configuration Manager, creating activities, changing their properties, assigning targets of the activities and defining conditions between the activities. Change the name of the plan from View Plan Properties in milan.itsc.austin.ibm.com.TPM_Plan1. 16.The Tivoli Provisioning Manager for Software Distribution Beta 2 code on which the scenario was built has issues running tasks on TCA targets. The Activity Planner on Tivoli Provisioning Manager is also capable of running tasks on TMA endpoint, so we choose that type of target for Task activity. 17.This results in a plan as seen in Figure 14-41 on page 745, which we save by selecting File Save as Template. The XML export of the plan is shown in Example 14-7.
Example 14-7 XML exported activity plan
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE activity_plan SYSTEM "apm_plan.dtd"> <activity_plan> <name>milan.itsc.austin.ibm.com.TPM_Plan1</name> <version>TPM51</version> <allow_run>false</allow_run> <priority>medium</priority> <submit_paused>n</submit_paused> <cancel_at_cutoff>n</cancel_at_cutoff> <post_notice>y</post_notice> <activity>
742
<application>SoftwareDistribution</application> <name>Distribute</name> <description>Distribute a package</description> <target_resource_type>endpoint</target_resource_type> <targets type="list">prov001.itsc.austin.ibm.com,prov002.itsc.austin.ibm.com,prov003.itsc.aust in.ibm.com</targets> <targets_computation>p</targets_computation> <operation>SoftwareModule.DistributeInstallable</operation> <parameter> <name>EnableMulticast</name> <value>F</value> </parameter> <parameter> <name>DistributionMode</name> <value>CHNG_ALL</value> </parameter> <parameter> <name>SoftwarePackageName</name> <value>ITPMfSW_Beta_Viewlet#milan-region</value> </parameter> <parameter> <name>Transactional</name> <value>TRAN_NO</value> </parameter> <parameter> <name>Undo</name> <value>UNDO_NO</value> </parameter> <parameter> <name>RetryUnicast</name> <value>T</value> </parameter> <parameter> <name>RoamEp</name> <value>T</value> </parameter> <parameter> <name>Force</name> <value>F</value> </parameter> <parameter> <name>MobileForceMandatory</name> <value>T</value> </parameter> <parameter> <name>MobileHidden</name> <value>F</value> </parameter> <parameter> <name>FromCD</name> <value>F</value> </parameter> <parameter> <name>WakeOnLan</name> <value>F</value> </parameter> <parameter> <name>Reboot</name> <value>REBOOT_NO</value> </parameter> <parameter> <name>DependencyCheck</name> <value>T</value> </parameter> <parameter> <name>FromDepot</name> <value>F</value> </parameter> <parameter> <name>EnableNotification</name> <value>F</value> </parameter> <parameter> <name>AutoAccept</name> <value>F</value> </parameter> <parameter> <name>Ignore</name> <value>F</value> </parameter> <parameter> <name>LenientDistribution</name> <value>T</value> </parameter> <parameter> <name>DisconnectedOperation</name> <value>F</value> </parameter> <parameter> <name>Disposable</name> <value>F</value> </parameter> <parameter> <name>SoftwarePackageVers</name> <value>5.1</value> </parameter> <parameter> <name>Priority</name> <value>PRTY_MEDIUM</value> </parameter> <parameter> <name>FromFileServer</name> <value>F</value> </parameter> <parameter> <name>AutoCommit</name> <value>F</value> </parameter> </activity> <activity> <application tcm_application="SoftwareDistribution">SoftwareDistribution</application> <name>Install</name> <description>Install package</description> <target_resource_type>endpoint</target_resource_type>
743
<targets type="list">prov001.itsc.austin.ibm.com,prov002.itsc.austin.ibm.com,prov003.itsc.aust in.ibm.com</targets> <targets_computation>p</targets_computation> <operation tcm_operation="Install">SoftwareModule.Install</operation> <condition>ST(Distribute)</condition> <parameter> <name>EnableMulticast</name> <value>F</value> </parameter> <parameter> <name>DistributionMode</name> <value>CHNG_ALL</value> </parameter> <parameter> <name>SoftwarePackageName</name> <value>ITPMfSW_Beta_Viewlet#milan-region</value> </parameter> <parameter> <name>Transactional</name> <value>TRAN_NO</value> </parameter> <parameter> <name>Undo</name> <value>UNDO_NO</value> </parameter> <parameter> <name>RetryUnicast</name> <value>T</value> </parameter> <parameter> <name>RoamEp</name> <value>T</value> </parameter> <parameter> <name>Force</name> <value>F</value> </parameter> <parameter> <name>MobileForceMandatory</name> <value>T</value> </parameter> <parameter> <name>MobileHidden</name> <value>F</value> </parameter> <parameter> <name>FromCD</name> <value>F</value> </parameter> <parameter> <name>WakeOnLan</name> <value>F</value> </parameter> <parameter> <name>Reboot</name> <value>REBOOT_NO</value> </parameter> <parameter> <name>DependencyCheck</name> <value>T</value> </parameter> <parameter> <name>FromDepot</name> <value>T</value> </parameter> <parameter> <name>EnableNotification</name> <value>F</value> </parameter> <parameter> <name>AutoAccept</name> <value>F</value> </parameter> <parameter> <name>Ignore</name> <value>F</value> </parameter> <parameter> <name>LenientDistribution</name> <value>T</value> </parameter> <parameter> <name>DisconnectedOperation</name> <value>F</value> </parameter> <parameter> <name>Disposable</name> <value>F</value> </parameter> <parameter> <name>SoftwarePackageVers</name> <value>5.1</value> </parameter> <parameter> <name>Priority</name> <value>PRTY_MEDIUM</value> </parameter> <parameter> <name>AutoCommit</name> <value>F</value> </parameter> <parameter> <name>FromFileServer</name> <value>F</value> </parameter> </activity> <activity> <application tcm_application="TaskLibrary">TaskLibrary</application> <name>Task</name> <description>Run a task</description> <target_resource_type>endpoint</target_resource_type> <targets type="list">prov001-ep#milan-region,prov002-ep#milan-region,prov003-ep#milan-region</ targets> <targets_computation>p</targets_computation> <operation tcm_operation="ExecuteTask">EndPointTask.Execute</operation> <condition>CA(Install)</condition>
744
<parameter> <name>ExecutionMode</name> <value>EXEC_MODE_PARALLEL</value> </parameter> <parameter> <name>Timeout</name> <value>300</value> </parameter> <parameter> <name>Task</name> <value>dir@Windows Tasks#milan-region</value> </parameter> </activity> </activity_plan>
Figure 14-41 TPM_Plan1 layout
18.The plan is now shown complete in Task Management Manage Activity Plans window. Only complete plans can be run. Run the new plan by clicking the more actions button of the milan.itsc.austin.ibm.com.TPM_Plan1 and selecting Run. See Figure 14-42.
745
Figure 14-42 Run TPM_Plan1
19.On the following window, click Submit. Change the Priority Level (High, Medium, Low) and choose to submit as paused on the Advanced page. 20.Follow the plan from Task Management Track Activity Plans.
746
Figure 14-43 Track activity plans
21.Collapse the left pane by clicking the arrow bar and click the plan name. Select the radio button to see the targets and their status. See Figure 14-44.
747
Figure 14-44 Activity Distribute targets and status
22.To get an update of the status window, click Refresh. Cancel a specific activity by clicking the more action button of that activity, and select Cancel from the menu (Figure 14-45 on page 749). Although the Install activity status icon is displayed In Progress, the actual activity is not started because of the Success Target condition on the Distribute activity.
748
Figure 14-45 Activity Install not started
23.When we click the Install operation, we can verify the arguments of the SoftwareModule.Install workflow (Figure 14-46 on page 750).
749
Figure 14-46 SoftwareModule.Install workflow arguments
24.The Install activity is started on each target on successful execution of the ST conditioned activity, as shown in Figure 14-47 on page 751.
750
Figure 14-47 Activity Install status and targets
If a Distribute activity has failed on any target, the Install activity is not started on that target. The activity has the cancel_by_condition status. The other targets still continue with the Install activity. 25.Verify the depot usage from Inventory Infrastructure Management Depots and click on Antwerp depot prov003.itsc.austin.ibm.com.
751
Figure 14-48 Depot statistics
From the depot usage page, we see that the package is published. We also can verify the space used by the depot, and bytes transferred today, since yesterday, last week and last month, next to the average transfer rate. Finally, when the Install activity is completed, successful or not, the Task activity is triggered (Figure 14-49 on page 753).
752
Figure 14-49 Activity Task status and targets
The output of the task is available in the logfile of the Activity Planner, located in the $TIO_LOGS/activityplan directory, where all other trace, error and common base event messages are found. The logfile is console.log. See Example 14-7.
Example 14-8 Excerpt of console.log
2006-10-14 09:37:28,000 DEBUG [Status Updater] ( ?:?) manager.StatusUpdateProcessor: updating task Install from PROGRESS to SUCCEEDED^M 2006-10-14 09:37:30,609 INFO [execute_task] (EptThread.java:159) ept.EptThread: TsklThread - execute_task : done^M 2006-10-14 09:37:30,609 DEBUG [execute_task] (EptThread.java:183) ept.EptThread: EptThread - added good target prov002-ep#milan-region^M 2006-10-14 09:37:30,609 DEBUG [execute_task] (EptThread.java:183) ept.EptThread: EptThread - added good target prov001-ep#milan-region^M 2006-10-14 09:37:30,609 DEBUG [execute_task] (EptThread.java:183) ept.EptThread: EptThread - added good target prov003-ep#milan-region^M 2006-10-14 09:37:30,609 DEBUG [execute_task] (TmfServer.java:230) map.TmfServer: Searching for tmf type server with name:prov002-ep#milan-region^M
753
2006-10-14 09:37:30,656 DEBUG [execute_task] (TmfServer.java:230) map.TmfServer: Searching for tmf type server with name:prov001-ep#milan-region^M 2006-10-14 09:37:30,688 DEBUG [execute_task] (TmfServer.java:230) map.TmfServer: Searching for tmf type server with name:prov003-ep#milan-region^M 2006-10-14 09:37:30,734 INFO [execute_task] (EptThread.java:288) ept.EptThread: ################################################################################ Task Name : dir Task Endpoint : prov002-ep#milan-region (Endpoint) Return Code : 0 ------- Standard Output ------^M C:\Program Files\Tivoli\lcf\dat\1>cd c: ^M C:\Program Files\Tivoli\lcf\dat\1^M ^M C:\Program Files\Tivoli\lcf\dat\1>dir^M Volume in drive C has no label.^M Volume Serial Number is 9433-C076^M ^M Directory of C:\Program Files\Tivoli\lcf\dat\1^M ^M 10/03/2006 06:08 PM <DIR> .^M 10/03/2006 06:08 PM <DIR> ..^M 10/14/2006 09:34 AM <DIR> cache^M 05/02/2006 08:51 PM <DIR> codeset^M 09/11/2006 04:25 PM 120 ITCMW040203.sys^M 10/03/2006 06:08 PM 889 last.cfg^M 10/03/2006 06:08 PM 504 lcf.dat^M 05/05/2006 04:45 PM 66 lcf.id^M 10/06/2006 08:34 AM 1,024,017 lcfd.bk^M 10/14/2006 08:24 AM 596,012 lcfd.log^M 10/03/2006 06:08 PM 75 lcfd.st^M 7 File(s) 1,621,683 bytes^M 4 Dir(s) 34,254,196,736 bytes free^M ################################################################################ Task Name : dir Task Endpoint : prov001-ep#milan-region (Endpoint) Return Code : 0 ------- Standard Output ------^M C:\Program Files\Tivoli\lcf\dat\1>cd c: ^M C:\Program Files\Tivoli\lcf\dat\1^M ^M C:\Program Files\Tivoli\lcf\dat\1>dir^M Volume in drive C has no label.^M
754
Volume Serial Number is 10D8-7A93^M ^M Directory of C:\Program Files\Tivoli\lcf\dat\1^M ^M 10/14/2006 05:38a <DIR> .^M 10/14/2006 05:38a <DIR> ..^M 10/14/2006 09:18a <DIR> cache^M 09/08/2006 04:07p <DIR> codeset^M 09/11/2006 04:03p 120 ITCMW040203.sys^M 10/14/2006 05:38a 817 last.cfg^M 10/14/2006 05:38a 504 lcf.dat^M 09/08/2006 04:07p 64 lcf.id^M 10/14/2006 05:35a 15,870 lcfd.log^M 10/14/2006 05:38a 75 lcfd.st^M 6 File(s) 17,450 bytes^M 4 Dir(s) 7,324,344,320 bytes free^M ################################################################################ Task Name : dir Task Endpoint : prov003-ep#milan-region (Endpoint) Return Code : 0 ------- Standard Output ------^M C:\Program Files\Tivoli\lcf\dat\1>cd c: ^M C:\Program Files\Tivoli\lcf\dat\1^M ^M C:\Program Files\Tivoli\lcf\dat\1>dir^M Volume in drive C has no label.^M Volume Serial Number is 9433-C076^M ^M Directory of C:\Program Files\Tivoli\lcf\dat\1^M ^M 09/29/2006 10:28 AM <DIR> .^M 09/29/2006 10:28 AM <DIR> ..^M 10/14/2006 09:28 AM <DIR> cache^M 05/02/2006 08:48 PM <DIR> codeset^M 09/13/2006 01:12 PM 120 ITCMW040203.sys^M 09/29/2006 10:28 AM 889 last.cfg^M 09/29/2006 10:28 AM 504 lcf.dat^M 05/02/2006 08:48 PM 66 lcf.id^M 10/01/2006 03:28 PM 1,024,045 lcfd.bk^M 10/14/2006 08:23 AM 790,355 lcfd.log^M 09/29/2006 10:28 AM 75 lcfd.st^M 7 File(s) 1,816,054 bytes^M 4 Dir(s) 49,423,040,512 bytes free^M
755
################################################################################ ^M 2006-10-14 09:37:38,016 DEBUG [Status Updater] ( ?:?) soa.SoaStatusUpdater: Thread[Status Updater,5,main] thread calling ProcessJobStatus^M 2006-10-14 09:37:38,016 DEBUG [Status Updater] ( ?:?) client.JobManagementServiceClient: Using endpoint URL: https://cairo.itsc.austin.ibm.com:9045/dmserver/services/EDMSTPMManagementService^M 2006-10-14 09:37:38,172 DEBUG [Status Updater] ( ?:?) dms.DmsService: Dms Status Count=0^M 2006-10-14 09:37:38,172 DEBUG [Status Updater] ( ?:?) soa.SoaStatusUpdater: Setting job status time to: 1160836637027^M
756
Appendix A.
A sample data center model - venice.xml

This appendix provides a sample data center model, called a venice.xml.
757
A sample data center model - venice.xml

The following is a sample data center model, venice.xml. This XML contains a sample data center model, with defintions for switches, load balancers, application software, and much much more. It is located in <installation location>/xml/venice.xml. Refer to Importing data center model definitions on page 578 on for a discussion on importing DCM definitions.
Example 14-9 A sample data center model - venice.xml
<!DOCTYPE datacenter PUBLIC "-//Think Dynamics//DTD XML Import//EN" "http://www.thinkdynamics.com/dtd/xmlimport.dtd" [ <!ENTITY resourcepoolconfig SYSTEM "http://www.thinkdynamics.com/dtd/resourcepool.xml"> <!ENTITY dataacquisitionconfig SYSTEM "http://www.thinkdynamics.com/dtd/dataacquisition.xml"> <!ENTITY simulator-cpu ' <dae-driver device="server" classname="com.thinkdynamics.kanaha.dataacquisitionengine.NullDriver"/> <dae-signal name="cpu-utilization" device="server" metric="cpu-utilization" aggregation="average" filter="low-pass-filter"/> '> ]> <datacenter>  <inventory-group name="Rivers" description="Computers named after rivers" type="server"> <inventory-group-member name="Amazon" type="server" /> <inventory-group-member name="Danube" type="server" /> <inventory-group-member name="Ganges" type="server" /> <inventory-group-member name="Mississippi" type="server" /> <inventory-group-member name="Nile" type="server" /> <property component="KANAHA" name="Sample Group Property" value="Sample group property value" /> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </inventory-group> <inventory-group name="Places" description="Computers named after places" type="server"> <inventory-group-member name="Arizona" type="server" /> <inventory-group-member name="DC" type="server" /> <inventory-group-member name="Delaware" type="server" />
758
<inventory-group-member name="Montana" type="server" /> <inventory-group-member name="NewYork" type="server" /> <inventory-group-member name="Oregon" type="server" /> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </inventory-group> <inventory-group name="DB2 Software" description="DB2 software for various platforms" type="softwareModule"> <inventory-group-member name="DB2 For Windows" type="softwareModule" /> <inventory-group-member name="DB2 For Linux" type="softwareModule" /> <inventory-group-member name="DB2 For Linux 1" type="softwareModule" /> <inventory-group-member name="DB2 HA Software for Linux" type="softwareModule" /> </inventory-group> <inventory-group name="Application Servers" description="Application server software from various vendors" type="softwareModule"> <inventory-group-member name="Weblogic 7.1" type="softwareModule" /> <inventory-group-member name="Weblogic 8.1" type="softwareModule" /> <inventory-group-member name="Tomcat 4" type="softwareModule" /> </inventory-group> <query name="D Computers" primary-id-field="server_info_view.SERVER_ID" query-string="SELECT server_info_view.SERVER_NAME
FROM server_info_view
WHERE (server_info_view.SERVER_NAME LIKE 'D%')
ORDER BY server_info_view.SERVER_NAME"> <select> <field name="server_info_view.SERVER_NAME" /> </select> <join firstTable="server_info_view" /> <where> <condition operation="LIKE" name="server_info_view.SERVER_NAME"> <values> <value name="'D%'" /> </values> </condition> </where> <groupby /> <orderby> <field name="server_info_view.SERVER_NAME" /> </orderby> </query> <inventory-group name="D Computers" description="Computers with names that start with D" type="server" query="D Computers"> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name>
Appendix A. A sample data center model - venice.xml
759
</access-domain-membership> </inventory-group>  <power-unit name="APC Power Bar 1" locale="en_US"> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </power-unit> <power-unit name="APC Power Bar 2" locale="en_US"> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </power-unit> <power-unit name="AC/DC Power Unit" locale="en_US"> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </power-unit> <subnetwork ipaddress="10.1.0.0" netmask="255.255.255.0"/> <subnetwork ipaddress="10.1.100.0" netmask="255.255.255.0"/> <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan <vlan vlan-number="1" name="Cisco 6500 vlan-1"/> vlan-number="1" name="Extreme Alpine 3804 vlan-1"/> vlan-number="101" name="domain-101"/> vlan-number="102" name="vlan-102"/> vlan-number="103" name="vlan-103"/> vlan-number="104" name="vlan-104"/> vlan-number="200" name="vlan-200"/> vlan-number="201" name="vlan-201"/> vlan-number="101" name="Test-01-101"/> vlan-number="500" name="VLAN-500"/> vlan-number="501" name="VLAN-501"/> vlan-number="502" name="VLAN-502"/> vlan-number="503" name="VLAN-503"/> vlan-number="504" name="VLAN-504"/> vlan-number="505" name="VLAN-505"/> vlan-number="506" name="VLAN-506"/> vlan-number="507" name="VLAN-507"/> vlan-number="510" name="VLAN-510"/> vlan-number="511" name="VLAN-511"/> vlan-number="601" name="VLAN-601"/> vlan-number="602" name="VLAN-602"/> vlan-number="1001" name="VLAN-1001"/>
760
<vlan vlan-number="1002" name="VLAN-1002"/> <vlan vlan-number="1010" name="VLAN-1010"/>  <software-stack name="Windows 2000 Server" locale="fr_FR"> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-stack> <software-stack name="Cluster Stack" locale="fr_FR" description="Stack Description" is-draft="false"> <software-stack-entry software-module="Cluster Software" position="1" expected-state="Running"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-stack> <switch name="Cisco 3548G-01" locale="en_US"> <network-interface ipaddress="10.1.0.26" netmask="255.255.255.0"/> <power-outlet power-unit="APC Power Bar 1" outlet-number="1"/> <power-outlet power-unit="APC Power Bar 2" outlet-number="1"/> <property name="snmp.community.read" value="public"/> <property name="snmp.community.write" value="public"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </switch> <switch name="Cisco 6509-01" locale="en_US"> <network-interface ipaddress="10.1.0.11" netmask="255.255.255.0"/> <switch-module> <switch-port port-number="1" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="2" vlan-name="Cisco 6500 vlan-1" managed="false" failed="false" mode="TRUNK" encapsulation="802.1Q" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="3"> <vlan-in-trunk vlan-name="domain-101"/> <mpls-protocol-endpoint total-bandwidth="100" available-bandwidth="50"/> </switch-port> <switch-port port-number="3" vlan-name="Cisco 6500 vlan-1" managed="false" failed="false" mode="TRUNK" encapsulation="802.1Q" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="2">
761
<vlan-in-trunk vlan-name="domain-101"/> </switch-port> <switch-port port-number="4" vlan-name="domain-101" managed="false" failed="false" /> <switch-port port-number="5" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="6" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="7" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="8" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="9" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="10" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="11" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="12" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="13" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="14" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="15" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="16" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="17" vlan-name="domain-101" managed="false" failed="false" connected-to-switch="Test-01" connected-to-port="1"/> <switch-port port-number="18" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="19" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="20" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="21" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="22" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="23" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="24" vlan-name="vlan-102" managed="false" failed="false"/>
762
<switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/>
port-number="25" vlan-name="vlan-102" managed="false" port-number="26" vlan-name="vlan-102" managed="false" port-number="27" vlan-name="vlan-102" managed="false" port-number="28" vlan-name="vlan-103" managed="false" port-number="29" vlan-name="vlan-103" managed="false" port-number="30" vlan-name="vlan-103" managed="false" port-number="31" vlan-name="vlan-103" managed="false" port-number="32" vlan-name="vlan-104" managed="false" port-number="33" vlan-name="vlan-104" managed="false" port-number="34" vlan-name="vlan-104" managed="false" port-number="35" vlan-name="vlan-104" managed="false" port-number="36" vlan-name="vlan-200" managed="false" port-number="37" vlan-name="vlan-200" managed="false" port-number="38" vlan-name="vlan-200" managed="false" port-number="39" vlan-name="vlan-200" managed="false" port-number="40" vlan-name="vlan-201" managed="false" port-number="41" vlan-name="vlan-201" managed="false" port-number="42" vlan-name="vlan-201" managed="false" port-number="43" vlan-name="vlan-201" managed="false" port-number="44" vlan-name="vlan-104" managed="false" port-number="45" vlan-name="vlan-104" managed="false" port-number="46" vlan-name="vlan-104" managed="false"
763
<switch-port port-number="47" vlan-name="vlan-104" managed="false" failed="false"/> <switch-port port-number="48" vlan-name="vlan-104" managed="false" failed="false"/> </switch-module> <power-outlet power-unit="APC Power Bar 1" outlet-number="2"/> <power-outlet power-unit="APC Power Bar 2" outlet-number="3"/> <property name="snmp.community.read" value="public"/> <property name="snmp.community.write" value="public"/> <switch-vlan vlan-name="domain-101"/> <switch-vlan vlan-name="Cisco 6500 vlan-1"/> <switch-vlan vlan-name="vlan-102"/> <switch-vlan vlan-name="vlan-103"/> <switch-vlan vlan-name="vlan-104"/> <switch-vlan vlan-name="vlan-200"/> <switch-vlan vlan-name="vlan-201"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </switch> <switch name="Extreme Alpine 3804-01" locale="en_US"> <network-interface ipaddress="10.1.0.12" netmask="255.255.255.0"/> <switch-module> <switch-port port-number="1" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="2" vlan-name="Extreme Alpine 3804 vlan-1" managed="false" failed="false" mode="TRUNK" encapsulation="802.1Q" connected-to-switch="Cisco 6509-01" connected-to-port="3"> <vlan-in-trunk vlan-name="domain-101"/> </switch-port> <switch-port port-number="3" vlan-name="Extreme Alpine 3804 vlan-1" managed="false" failed="false" mode="TRUNK" encapsulation="802.1Q" connected-to-switch="Cisco 6509-01" connected-to-port="2"> <vlan-in-trunk vlan-name="domain-101"/> </switch-port> <switch-port port-number="4" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="5" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="6" vlan-name="domain-101" managed="false" failed="false"/>
764
<switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/> <switch-port failed="false"/>
port-number="7" vlan-name="domain-101" managed="false" port-number="8" vlan-name="domain-101" managed="false" port-number="9" vlan-name="domain-101" managed="false" port-number="10" vlan-name="domain-101" managed="false" port-number="11" vlan-name="domain-101" managed="false" port-number="12" vlan-name="domain-101" managed="false" port-number="13" vlan-name="domain-101" managed="false" port-number="14" vlan-name="domain-101" managed="false" port-number="15" vlan-name="domain-101" managed="false" port-number="16" vlan-name="domain-101" managed="false" port-number="17" vlan-name="domain-101" managed="false" port-number="18" vlan-name="domain-101" managed="false" port-number="19" vlan-name="domain-101" managed="false" port-number="20" vlan-name="domain-101" managed="false" port-number="21" vlan-name="domain-101" managed="false" port-number="22" vlan-name="domain-101" managed="false" port-number="23" vlan-name="domain-101" managed="false" port-number="24" vlan-name="domain-101" managed="false" port-number="25" vlan-name="domain-101" managed="false" port-number="26" vlan-name="domain-101" managed="false" port-number="27" vlan-name="domain-101" managed="false" port-number="28" vlan-name="domain-101" managed="false"
765
<switch-port port-number="29" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="30" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="31" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="32" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="33" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="34" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="35" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="36" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="37" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="38" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="39" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="40" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="41" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="42" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="43" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="44" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="45" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="46" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="47" vlan-name="domain-101" managed="false" failed="false"/> <switch-port port-number="48" vlan-name="domain-101" managed="false" failed="false"/> </switch-module> <power-outlet power-unit="APC Power Bar 1" outlet-number="3"/> <power-outlet power-unit="APC Power Bar 2" outlet-number="2"/> <property name="snmp.community.read" value="public"/> <property name="snmp.community.write" value="public"/>
766
<switch-vlan vlan-name="domain-101"/> <switch-vlan vlan-name="Extreme Alpine 3804 vlan-1"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </switch> <switch name="Test-01" locale="en_US"> <network-interface ipaddress="10.1.0.12" netmask="255.255.255.0"/> <switch-module> <switch-port port-number="1" vlan-name="Test-01-101" managed="false" failed="false" connected-to-switch="Cisco 6509-01" connected-to-port="17"/> <switch-port port-number="2" vlan-name="Test-01-101" managed="false" failed="false"/> <switch-port port-number="3" vlan-name="Test-01-101" managed="false" failed="false"/> </switch-module> <property name="snmp.community.read" value="public"/> <property name="snmp.community.write" value="public"/> <switch-vlan vlan-name="Test-01-101"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </switch> <switch name="virtualization-switch" locale="en_US"> <network-interface ipaddress="10.1.0.123" netmask="255.255.255.0"/> <switch-module name="0"> <switch-port port-number="1" vlan-name="VLAN-1001" managed="false" failed="false"/> <switch-port port-number="2" vlan-name="VLAN-1002" managed="false" failed="false"/> <switch-port port-number="3" vlan-name="VLAN-1001" managed="false" failed="false"/> <switch-port port-number="4" vlan-name="VLAN-1001" managed="false" failed="false"/> <switch-port port-number="5" vlan-name="VLAN-1001" managed="false" failed="false"/> <switch-port port-number="6" vlan-name="VLAN-1001" managed="false" failed="false"/> <switch-port port-number="7" vlan-name="VLAN-1002" managed="false" failed="false"/> <switch-port port-number="8" vlan-name="VLAN-1002" managed="false" failed="false"/>
767
<switch-port port-number="9" vlan-name="VLAN-1001" managed="false" failed="false"/> <switch-port port-number="10" vlan-name="VLAN-1001" managed="false" failed="false"/> </switch-module> <property name="snmp.community.read" value="public"/> <property name="snmp.community.write" value="public"/> <switch-vlan vlan-name="VLAN-1001"/> <switch-vlan vlan-name="VLAN-1002"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </switch> <load-balancer type="alteon-load-balancer" name="Alteon 184-01" locale="en_US"> <network-interface ipaddress="10.1.0.13" netmask="255.255.255.0"/> <power-outlet power-unit="APC Power Bar 1" outlet-number="4"/> <power-outlet power-unit="APC Power Bar 2" outlet-number="4"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </load-balancer> <load-balancer type="arrowpoint-load-balancer" name="Cisco 11154-01" locale="en_US"> <network-interface ipaddress="10.1.0.14" netmask="255.255.255.0"/> <power-outlet power-unit="APC Power Bar 1" outlet-number="5"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </load-balancer> <load-balancer type="foundry-load-balancer" name="FoundryServerIronXL-01" locale="en_US"> <network-interface ipaddress="10.1.0.15" netmask="255.255.255.0"/> <power-outlet power-unit="APC Power Bar 2" outlet-number="5"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </load-balancer> <switch name="Alteon 184-01" locale="en_US"> <network-interface ipaddress="10.1.0.13" netmask="255.255.255.0"/> <power-outlet power-unit="AC/DC Power Unit" outlet-number="A"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </switch>
768
<switch name="Cisco 11154-01" locale="en_US"> <network-interface ipaddress="10.1.0.14" netmask="255.255.255.0"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </switch> <switch name="FoundryServerIronXL-01" locale="en_US"> <network-interface ipaddress="10.1.0.15" netmask="255.255.255.0"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </switch> <subnetwork ipaddress="10.1.8.0" netmask="255.255.255.224"/> <subnetwork ipaddress="10.1.8.32" netmask="255.255.255.240"/> <subnetwork ipaddress="10.1.8.48" netmask="255.255.255.240"/> <subnetwork ipaddress="10.1.8.64" netmask="255.255.255.240"/> <subnetwork ipaddress="10.1.8.80" netmask="255.255.255.240"/> <acl name="acl-1"> <rule position="1" target="permit" protocol="icmp" source-subnet="10.1.8.0" destination-subnet="10.1.8.32" options="log"/> <rule position="2" target="permit" protocol="icmp" source-subnet="10.1.8.32" destination-subnet="10.1.8.0" options="log"/> </acl> <acl name="acl-2"> <rule position="1" target="permit" protocol="icmp" source-subnet="10.1.8.48" destination-subnet="10.1.8.64" options="log"/> <rule position="2" target="permit" protocol="icmp" source-subnet="10.1.8.64" destination-subnet="10.1.8.48" options="log"/> </acl> <acl name="acl-3"> <rule position="1" target="permit" protocol="icmp" source-subnet="10.1.8.32" destination-subnet="10.1.8.48" options="log"/> <rule position="2" target="permit" protocol="icmp" source-subnet="10.1.8.48" destination-subnet="10.1.8.32" options="log"/> </acl> <acl name="acl-4"> <rule position="1" target="permit" protocol="icmp" source-subnet="10.1.8.64" destination-subnet="10.1.8.80" options="log"/> <rule position="2" target="permit" protocol="icmp" source-subnet="10.1.8.80" destination-subnet="10.1.8.64" options="log"/> </acl> <acl name="acl-5"> <rule position="1" target="permit" protocol="icmp" source-subnet="10.1.8.80" destination-subnet="10.1.8.0" options="log"/>
769
<rule position="2" target="permit" protocol="icmp" source-subnet="10.1.8.0" destination-subnet="10.1.8.80" options="log"/> </acl> <acl name="acl-11"> <rule position="1" target="permit" protocol="icmp" source-subnet="10.1.1.32" destination-subnet="10.1.1.48" options="log"/> </acl> <acl name="acl-12"> <rule position="1" target="permit" protocol="icmp" source-subnet="10.1.1.32" destination-subnet="10.1.1.48" options="log"/> </acl> <acl name="acl-13"> <rule position="1" target="permit" protocol="icmp" source-subnet="10.1.1.32" destination-subnet="10.1.1.48" options="log"/> </acl> <acl name="acl-14"> <rule position="1" target="permit" protocol="icmp" source-subnet="10.1.1.32" destination-subnet="10.1.1.48" options="log"/> </acl> <acl name="acl-15"> <rule position="1" target="permit" protocol="icmp" source-subnet="10.1.1.32" destination-subnet="10.1.1.48" options="log"/> </acl> <acl name="acl-16"> <rule position="1" target="permit" protocol="http" source-subnet="10.1.1.32" source-first-port="8080" source-last-port="8088" destination-subnet="10.1.1.48" destination-first-port="7080" destination-last-port="7087" options="log"/> </acl> <boot-server name="Rembo" type = "Rembo" locale="en_US"> <nic connected-to-switch="Cisco 6509-01" connected-to-port="1"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </boot-server> <blade-admin-server name="blade-chassis-admin" locale="en_US"> <network-interface name="Management network" ipaddress="10.1.8.77" netmask="255.255.255.240" managed="false"> </network-interface> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </blade-admin-server> <switch name="Extreme Routing Switch" locale="en_US"> <network-interface name="Management network" ipaddress="10.1.8.28" netmask="255.255.255.224" managed="false">
770
<route subnetwork="10.1.8.0"/> <acl-ref name="acl-1" type="1" enabled="true"/> </network-interface> <network-interface name="cust02" ipaddress="10.1.8.60" netmask="255.255.255.240" managed="false"> <route subnetwork="10.1.8.48"/> <acl-ref name="acl-2" type="1" enabled="true"/> </network-interface> <network-interface name="cust01" ipaddress="10.1.8.44" netmask="255.255.255.240" managed="false"> <route subnetwork="10.1.8.32"/> <acl-ref name="acl-3" type="1" enabled="true"/> </network-interface> <network-interface name="nt-pool" ipaddress="10.1.8.77" netmask="255.255.255.240" managed="false"> <route subnetwork="10.1.8.64"/> <acl-ref name="acl-4" type="1" enabled="true"/> </network-interface> <network-interface name="lnx-pool" ipaddress="10.1.8.93" netmask="255.255.255.240" managed="false"> <route subnetwork="10.1.8.80"/> <acl-ref name="acl-5" type="1" enabled="true"/> </network-interface> <firewall/> <property name="snmp.community.read" value="public" component="KANAHA"/> <property name="snmp.community.write" value="public" component="KANAHA"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </switch> <subnetwork ipaddress="10.1.9.0" netmask="255.255.255.224"/> <subnetwork ipaddress="10.1.9.32" netmask="255.255.255.240"/> <subnetwork ipaddress="10.1.9.48" netmask="255.255.255.240"/> <subnetwork ipaddress="10.1.9.64" netmask="255.255.255.240"/> <subnetwork ipaddress="10.1.9.80" netmask="255.255.255.240"/> <switch name="Cisco 2611 Router" locale="en_US"> <network-interface name="Management network" ipaddress="10.1.9.28" netmask="255.255.255.224" managed="false"> <route subnetwork="10.1.9.0"/> <acl-ref name="acl-11" type="1" enabled="true"/> </network-interface> <network-interface name="cust04" ipaddress="10.1.9.60" netmask="255.255.255.240" managed="false"> <route subnetwork="10.1.9.48"/> <acl-ref name="acl-12" type="1" enabled="true"/>
771
</network-interface> <network-interface name="cust03" ipaddress="10.1.9.44" netmask="255.255.255.240" managed="false"> <route subnetwork="10.1.9.32"/> <acl-ref name="acl-13" type="1" enabled="true"/> </network-interface> <network-interface name="nt-pool1" ipaddress="10.1.9.77" netmask="255.255.255.240" managed="false"> <route subnetwork="10.1.9.64"/> <acl-ref name="acl-14" type="1" enabled="true"/> </network-interface> <network-interface name="lnx-pool1" ipaddress="10.1.9.93" netmask="255.255.255.240" managed="false"> <route subnetwork="10.1.9.80"/> <acl-ref name="acl-15" type="1" enabled="true"/> </network-interface> <firewall/> <property name="snmp.community.read" value="public" component="KANAHA"/> <property name="snmp.community.write" value="public" component="KANAHA"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </switch>  <subnetwork ipaddress="10.1.1.16" netmask="255.255.255.240"/> <spare-pool name="Apache-Redhat" os-type="linux" locale="en_US"> <server-template name="Apache-Redhat template 101"> <nic-template vlan-name="domain-101"> <network-interface-template> <subnetwork ipaddress="10.1.1.16" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template>
<server name="hp-sa1100-1" locale="en_US"> <server-template name="Apache-Redhat hp-sa1100-1 template 101"> <nic-template vlan-name="domain-101"> <network-interface-template> <subnetwork ipaddress="10.1.1.16" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template>
772
<nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="20"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="20" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.50" netmask="255.255.255.0"/> </nic> <software-resource name="RedHat9" type="INSTALLATION" software-module="RedHat9"/> <software-resource name="Tomcat 4.0 Installation" type="INSTALLATION" software-module="Tomcat 4"> <software-resource name="Tomcat 4.0 Instance" type="INSTANCE" software-module="Tomcat 4"/> <software-resource name="Tomcat 4.0 Configuration" type="CONFIGURATION" software-module="Tomcat 4"/> <software-resource name="Tomcat 4.0 Application Data" type="APPLICATION-DATA" software-module="Tomcat 4"/> <file name="Tomcat 4 Installation directory" path="/usr/local/tomcat4"/> </software-resource> <resource name="Processor 1" resource-type="cpu"> <property name="cpu.architecture" value="intel"/> </resource> <resource name="RAM" resource-type="memory"> <property name="memory.size" value="1500000"/> </resource> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="hp-sa1100-2" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="21" macaddress="001122334455"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="21" managed="false" macaddress="001122334466"> <network-interface name="ADMIN" ipaddress="10.1.0.51" netmask="255.255.255.0"/> </nic> <resource name="Processor 1" resource-type="cpu"> <property name="cpu.architecture" value="intel"/> </resource> <resource name="RAM" resource-type="memory">
773
<property name="memory.size" value="1500000"/> </resource> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="hp-sa1100-3" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="22"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="22" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.52" netmask="255.255.255.0" managed="false"/> </nic> <resource name="Processor 1" resource-type="cpu"> <property name="cpu.architecture" value="intel"/> </resource> <resource name="RAM" resource-type="memory"> <property name="memory.size" value="1500000"/> </resource> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="hp-sa1100-4" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="23"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="23" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.53" netmask="255.255.255.0" managed="false"/> </nic> <resource name="Processor 1" resource-type="cpu"> <property name="cpu.architecture" value="intel"/> </resource> <resource name="RAM" resource-type="memory"> <property name="memory.size" value="1500000"/> </resource> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name>
774
</access-domain-membership> </spare-pool> <subnetwork ipaddress="10.1.1.32" netmask="255.255.255.240"/> <spare-pool name="Oracle9i-Solaris8" os-type="solaris" locale="en_US"> <server-template name="Oracle9i-Solaris8 template 102"> <nic-template vlan-name="vlan-102"> <network-interface-template> <subnetwork ipaddress="10.1.1.32" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <server name="sun-fire-280-1" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="24"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="24" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.54" managed="false" netmask="255.255.255.0"/> </nic> <resource name="Processor 1" resource-type="cpu"> <property name="cpu.architecture" value="sparc"/> </resource> <resource name="RAM" resource-type="memory"> <property name="memory.size" value="2500000"/> </resource> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="sun-fire-280-2" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="25"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="25" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.55" netmask="255.255.255.0" managed="false"/> </nic> <resource name="Processor 1" resource-type="cpu"> <property name="cpu.architecture" value="sparc"/> </resource> <resource name="RAM" resource-type="memory"> <property name="memory.size" value="2500000"/> </resource>
775
<access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="sun-fire-280-3" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="26"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="26" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.56" netmask="255.255.255.0" managed="false"/> </nic> <resource name="Processor 1" resource-type="cpu"> <property name="cpu.architecture" value="sparc"/> </resource> <resource name="RAM" resource-type="memory"> <property name="memory.size" value="2500000"/> </resource> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="sun-fire-280-4" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="27"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="27" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.57" netmask="255.255.255.0" managed="false"/> </nic> <resource name="Processor 1" resource-type="cpu"> <property name="cpu.architecture" value="sparc"/> </resource> <resource name="RAM" resource-type="memory"> <property name="memory.size" value="2500000"/> </resource> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </spare-pool> <subnetwork ipaddress="10.1.1.48" netmask="255.255.255.240"/>
776
<spare-pool name="Weblogic6-HPUX" os-type="hpux" locale="en_US"> <server-template name="Weblogic6-HPUX template 103"> <nic-template vlan-name="vlan-103"> <network-interface-template> <subnetwork ipaddress="10.1.1.48" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template>
<server name="hp-rp5400-1" blade-admin-server="blade-chassis-admin" blade-slot="1" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="28" netboot-enabled="true"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="28" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.58" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="hp-rp5400-2" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="29"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="29" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.59" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="hp-rp5400-3" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="30"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="30" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.60" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership>
777
<access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="hp-rp5400-4" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="31"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="31" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.61" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </spare-pool> <subnetwork ipaddress="10.1.1.64" netmask="255.255.255.240"/> <spare-pool name="IIS-Win2K" os-type="windows" locale="en_US"> <server-template name="IIS-Win2K template 104"> <nic-template vlan-name="vlan-104"> <network-interface-template> <subnetwork ipaddress="10.1.1.64" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template>
<server name="dell-poweredge-2550-1" software-stack="Windows 2000 Server" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="32"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="32" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.62" netmask="255.255.255.0" managed="false"/> </nic> <ic name="slot1"> <ic-port port-number="1" port-type="RS232"/> <ic-port port-number="2" port-type="RS232"/> </ic>
778
<sap name="ssh service" locale="en_US" port="22" is-device-model="SSH Service Access Point"> <default-sap operation-type="execute-command"/> <credentials search-key="primary" is-default="true"> <password-credentials username="primary" password="bingo"/> </credentials> <credentials search-key="secondary"> <rsa-credentials username="primary" public-key="Base64Voila="/> </credentials> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </sap> <sap name="snmp service" port="161" locale="en_CA" is-device-model="SNMP V1 Service Access Point"> <default-sap operation-type="get-attribute"/> <credentials search-key="primary" is-default="true"> <snmp-credentials community="public"/> </credentials> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </sap> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="dell-poweredge-2550-2" software-stack="Windows 2000 Server" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="33"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="33" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.63" netmask="255.255.255.0" managed="false"/> </nic> <ic name="slot1"> <ic-port port-number="1" port-type="RS232"/> <ic-port port-number="2" port-type="RS232"> <port-connection device="dell-poweredge-2550-1" card="slot1" port-number="1" port-type="RS232"/> </ic-port> </ic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name>
779
</access-domain-membership> </server> <server name="dell-poweredge-2550-3" software-stack="Windows 2000 Server" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="34"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="34" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.64" netmask="255.255.255.0" managed="false"/> </nic> <ic name="dell-poweredge-2550-3-slot1card"> <ic-port port-number="1" port-type="RS232"> <port-connection device="dell-poweredge-2550-1" card="slot1" port-number="2" port-type="RS232"/> </ic-port> <ic-port port-number="2" port-type="RS232"/> </ic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="compaq-proliant-1" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="35"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="35" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.65" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="compaq-proliant-2" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="44"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="44" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.74" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership>
780
</server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </spare-pool> <subnetwork ipaddress="10.1.2.16" netmask="255.255.255.240"/> <spare-pool name="Sendmail-Solaris8" os-type="solaris" locale="en_US"> <server-template name="Sendmail-Solaris8 template 200"> <nic-template vlan-name="vlan-200"> <network-interface-template> <subnetwork ipaddress="10.1.2.16" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <server name="sun-e3500-1" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="36"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="36" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.66" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="sun-e3500-2" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="37"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="37" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.67" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="sun-e3500-3" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="38"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="38" managed="false">
781
<network-interface name="ADMIN" ipaddress="10.1.0.68" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="sun-e3500-4" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="39"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="39" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.69" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </spare-pool> <subnetwork ipaddress="10.1.2.32" netmask="255.255.255.240"/> <spare-pool name="WebSphere4-AIX5" os-type="aix" locale="en_US"> <server-template name="WebSphere4-AIX5 template 201"> <nic-template vlan-name="vlan-201"> <network-interface-template> <subnetwork ipaddress="10.1.2.32" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template>
<server name="ibm-p660-1" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="40"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="40" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.70" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name>
782
</access-domain-membership> </server> <server name="ibm-p660-2" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="41"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="41" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.71" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="ibm-p660-3" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="42"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="42" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.72" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="ibm-p660-4" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="43"/> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="43" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.73" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </spare-pool>  <file-repository name="test file repository" ipaddress="10.1.5.48" root-path="tmp" boot-server="Rembo">
783
<access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </file-repository> <repository name="test external repository" description="test" is-device-model="Simulator" server="test file repository"/>  <subnetwork ipaddress="10.1.3.16" <subnetwork ipaddress="10.1.4.16" <subnetwork ipaddress="10.1.5.32" <subnetwork ipaddress="10.1.6.48" <subnetwork ipaddress="10.1.7.16" <subnetwork ipaddress="10.1.4.32" <subnetwork ipaddress="10.1.4.48" <subnetwork ipaddress="10.1.5.16"
netmask="255.255.255.240"/> netmask="255.255.255.240"/> netmask="255.255.255.240"/> netmask="255.255.255.240"/> netmask="255.255.255.240"/> netmask="255.255.255.240"/> netmask="255.255.255.240"/> netmask="255.255.255.240"/>
<software-module name="Cluster Software" is-device-model="Simulator" version="1.0"> <installable-package name="Cluster Product" version="1.0" file-repository="test file repository" status="not_tested"> <file name="Cluster Product File" path="/usr/local"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="template 1"> <software-resource-template name="child template 01" option-group-name="group 1" is-selected='true'> <template-param name="param 0" value="value 0" /> </software-resource-template> <software-resource-template name="child template 11" option-group-name="group 1"> <template-param name="param 1" value="value 1" /> </software-resource-template> <software-resource-template name="child template 12"> <template-param name="param 1" value="value 1" /> <template-param name="param 2" value="Has {1} as value">
784
<template-param-operand name="/Cluster Software/template 1/child template 11/param 1" /> </template-param> </software-resource-template> <template-param name="param 1" value="value 1" /> <template-param name="install-path" value="C:\" /> </software-resource-template> <software-resource-template name="template 2" software-resource-type="INSTANCE" software-resource-template-source="/Cluster Software/template 1" software-resource-device-model="Simulator" is-default="true"> <template-param name="param 1" value="value 1" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module>
<software-module name="Weblogic 7.1" is-device-model="Simulator" version="1.0" description="Test Description"> <software-capability type="J2EERT:ServletContainer" name="version" value="2.3"/> <software-capability type="J2EERT:EJBContainer" name="version" value="1.1"/> <software-requirement type="JRE" name="jdk.version" hosting="true"> <software-requirement-value value="1.3"/> </software-requirement> <installable-package name="Weblogic 7.1 Installable Package" version="1.0" file-repository="test file repository" status="not_tested"> <file name="Weblogic 7.1 Installable Package File" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="Weblogic 7.1 template" software-resource-device-model="Simulator"> <template-param name="install-path" value="C:\" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module>
785
<software-module name="Weblogic 8.0" is-device-model="Simulator" version="1.0" is-draft="true"> <software-capability type="J2EERT:ServletContainer" name="version" value="2.3"/> <software-capability type="J2EERT:EJBContainer" name="version" value="1.1"/> <software-requirement type="JRE" name="jdk.version" enforcement="" hosting="true"> <software-requirement-value value="1.3"/> </software-requirement> <software-requirement type="OS" name="os.version" enforcement="" hosting="false"> <software-requirement-value value="Win2K"/> </software-requirement> <installable-package name="Weblogic 8.0 Installable Package" version="1.0" file-repository="test file repository" status="not_tested"> <file name="Weblogic 8.0 Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="Weblogic 8.0 template" software-resource-device-model="Simulator"> <template-param name="install-path" value="C:\" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software name="Weblogic 8.1" is-device-model="Simulator" version="1.0" package_path="package-path" install_path="install-path" type="SOFTWARE"> <software-capability type="J2EERT:ServletContainer" name="version" value="2.3"/> <software-capability type="J2EERT:EJBContainer" name="version" value="1.1"/> <software-requirement name="jdk.version" type="JRE" enforcement="" hosting="true"> <software-requirement-value value="1.3"/> </software-requirement> <software-requirement name="os.version" type="OS" enforcement="" hosting="false"> <software-requirement-value value="Win2K"/> </software-requirement> <software-requirement name="os.servicepack" type="OS" enforcement="" hosting="false"> <software-requirement-value value="SP3"/> </software-requirement>
786
</software> <software-module name="Tomcat 4" is-device-model="Simulator" version="1.0" > <software-capability type="J2EERT:ServletContainer" name="version" value="2.3"/> <software-requirement type="JRE" name="jdk.version" enforcement="" hosting="true"> <software-requirement-value value="1.3"/> </software-requirement> <installable-package name="Tomcat 4 Installable Package" version="1.0" file-repository="test file repository" status="not_tested"> <file name="Tomcat 4 Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="Tomcat 4 template" software-resource-type="INSTALLATION"> <template-param name="File.1" value="/opt/jakarta-tomcat/conf/server.xml"/> <template-param name="File.2" value="/opt/jakarta-tomcat/conf/web.xml"/> <template-param name="BackupResource.1.Type" value="generic"/> <template-param name="BackupResource.1.Description" value="backup set of files"/> <template-param name="BackupResource.1.local-copy-file-backup-dir" value="/tmp/backup/tomcat_installation"/> <template-param name="BackupResource.1.tsm-virtual-file-space" value="tiovfs"/> <template-param name="BackupResource.1.tsm-group" value="tomcat_installation"/> <template-param name="install-path" value="C:\" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="TSM 5.2 Client" is-device-model="Simulator" version="5.2" > <installable-package name="TSM 5.2 Client Installable Package" version="5.2" file-repository="test file repository" status="not_tested"> <file name="TSM 5.2 Client Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package>
787
<software-resource-template name="TSM 5.2 Client template" software-resource-type="INSTALLATION"> <template-param name="BackupSystem.1.Type" value="generic"/> <template-param name="BackupSystem.1.Description" value="TSM backup group"/> <template-param name="BackupSystem.1.ManagedSystem" value="localhost"/> <template-param name="BackupSystem.1.install-dir" value="/opt/tivoli/tsm"/> <template-param name="install-path" value="C:\" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="Win2KSP3" is-device-model="Simulator" version="1.0" > <software-capability name="os.version" value="Win2K"/> <software-capability name="os.servicepack" value="SP3"/> <software-requirement name="hardware.type" type="HARDWARE" enforcement="" hosting="true"> <software-requirement-value value="intel"/> </software-requirement> <installable-package name="Win2KSP3 Installable Package" version="1.0" file-repository="test file repository" status="not_tested"> <file name="Win2KSP3 Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="Win2KSP3 template" software-resource-device-model="Simulator"> <template-param name="install-path" value="C:\" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="Win2KSP1" is-device-model="Simulator" version="1.0" > <software-capability type="OS" name="os.version" value="Win2K"/> <software-capability type="OS" name="os.servicepack" value="SP1"/> <software-requirement name="hardware.type" type="HARDWARE" enforcement="" hosting="true"> <software-requirement-value value="intel"/> </software-requirement> <installable-package name="Win2KSP1 Installable Package" version="1.0" file-repository="test file repository" status="not_tested">
788
<file name="Win2KSP1 Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="Win2KSP1 template" software-resource-device-model="Simulator"> <template-param name="install-path" value="C:\" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <image name="GM_image" priority="2" boot-server="Rembo" software-module="Win2KSP1" image-type="Golden_Master" version="1.0" description="Description" status="not_tested"> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </image> <software-stack name="Win2KSP3 + Weblogic 8.0" locale="en_US"> <software-stack-entry software-module="Win2KSP3" position="1" expected-state="Running"/> <software-stack-entry software-module="Weblogic 8.0" position="2" expected-state="Running"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-stack> <image name="Win2KSP3 + Weblogic 8.0-GM-Image" boot-server="Rembo" software-module="Win2KSP3 + Weblogic 8.0" image-type="Golden_Master" version="1.0" description="Description" file-repository="test file repository" status="not_tested"> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </image>
<software-module name="RedHat9" is-device-model="Simulator" version="1.0" > <software-capability type="OS" name="os.version" value="RH9"/> <software-requirement name="hardware.type" type="HARDWARE" enforcement="" hosting="true">
789
<software-requirement-value value="intel"/> </software-requirement> <installable-package priority="2" name="RedHat9 Installable Package" version="1.0" file-repository="test file repository" status="not_tested"> <file name="RedHat9 Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="RedHat9 template" software-resource-device-model="Simulator"> <template-param name="install-path" value="C:\" /> </software-resource-template> <image name="Scripted_image" boot-server="Rembo" image-type="Scripted_OS" version="1.0" description="Description" file-repository="test file repository" status="not_tested"> <sap name="my sap" port="5201" app-protocol="Telnet" locale="fr_FR" role="host"> <credentials search-key="primary" is-default="true"> <password-credentials username="primary" password="bingo"/> </credentials> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </sap> <software-requirement name="hardware.type" type="HARDWARE" enforcement="" hosting="true"> <software-requirement-value value="Dummy signature"/> </software-requirement> <file name="Scripted_image" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </image> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="HPUX" is-device-model="Simulator" version="1.0" > <supported-requirement-type value="OS"/> <software-requirement name="hardware.type" type="HARDWARE" enforcement="" hosting="true"> <software-requirement-value value="hp"/> </software-requirement>
790
<installable-package name="HPUX Installable Package" version="1.0" file-repository="test file repository" status="not_tested"> <file name="HPUX Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="HPUX template" software-resource-device-model="Simulator"> <template-param name="install-path" value="C:\" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="Sun JDK1.3 for Windows" is-device-model="Simulator" version="1.0" > <software-capability type="JRE" name="jdk.version" value="1.3"/> <software-requirement name="os.version" type="OS" enforcement="" hosting="true"> <software-requirement-value value="Win2K"/> </software-requirement> <installable-package name="Sun JDK1.3 for Windows Installable Package" version="1.0" file-repository="test file repository" status="not_tested"> <file name="Sun JDK1.3 for Windows Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="Sun JDK1.3 for Windows template" software-resource-device-model="Simulator"> <template-param name="install-path" value="C:\" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="Sun JDK1.3 for Linux" is-device-model="Simulator" version="1.0" > <software-capability type="JRE" name="jdk.version" value="1.3"/> <software-requirement name="os.version" type="OS" enforcement="" hosting="true">
791
<software-requirement-value value="RH9"/> </software-requirement> <installable-package name="Sun JDK1.3 for Linux Installable Package" version="1.0" file-repository="test file repository" status="not_tested"> <file name="Sun JDK1.3 for Linux Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="Sun JDK1.3 for Linux template" software-resource-device-model="Simulator"> <template-param name="install-path" value="C:\" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="DB2 For Windows" is-device-model="Simulator" version="1.0" > <software-capability type="RDBRT:RDB" name="name" value="DB2UDB"/> <software-capability type="RDBRT:DB2UDB" name="version" value="8"/> <software-requirement name="os.version" type="OS" enforcement="" hosting="true"> <software-requirement-value value="Win2K"/> </software-requirement> <installable-package name="DB2 for Windows Installable Package" version="1.0" file-repository="test file repository" status="not_tested"> <file name="DB2 for Windows Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="DB2 for Windows template" software-resource-device-model="Simulator"> <template-param name="install-path" value="C:\" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="DB2 For Linux" is-device-model="Simulator" version="1.0">
792
<software-capability type="RDBRT:RDB" name="name" value="DB2UDB"/> <software-capability type="RDBRT:DB2UDB" name="version" value="8"/> <software-requirement name="os.version" type="OS" enforcement="" hosting="true"> <software-requirement-value value="RH9"/> </software-requirement> <installable-package name="DB2 for Linux Installable Package" version="1.0" file-repository="test file repository" status="not_tested"> <file name="DB2 for Linux Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="DB2 for Linux template" software-resource-device-model="Simulator"> <template-param name="install-path" value="/usr/local/" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <!-app topo sample-->
<software-module name="Standalone Java App" version="1.1"> <software-requirement type="JRE" name="jdk.version" hosting="false"> <software-requirement-value value="1.3" /> </software-requirement> <software-requirement hosting="false" type="OS" name="os.version"> <software-requirement-value value="Win2K" /> <software-requirement-value value="XP" /> </software-requirement> </software-module> <software-module name="Web App" version="1.0"> <software-requirement hosting="true" type="J2EERT:ServletContainer" name="version"> <software-requirement-value value="2.3" /> </software-requirement> <software-requirement hosting="false" type="OS" name="os.version"> <software-requirement-value value="Win2K" /> <software-requirement-value value="XP" /> </software-requirement> <software-requirement hosting="false" type="OS" name="os.servicepack"> <software-requirement-value value="SP3" />
793
</software-requirement> <software-resource-template name="Web App template"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="Ejb App" version="1.0"> <software-requirement hosting="true" name="version" type="J2EERT:EJBContainer"> <software-requirement-value value="1.1" /> </software-requirement> <software-resource-template name="Ejb App template"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="Db App" version="1.0"> <software-requirement hosting="true" name="version" type="RDBRT:DB2UDB"> <software-requirement-value value="8" /> </software-requirement> <software-requirement hosting="false" name="os.version" type="OS"> <software-requirement-value value="RH9" /> </software-requirement> <software-resource-template name="Db App template"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="Lotus Notes Server" version="6.0" title="IBM Lotus Notes" vendor="IBM"> <installable-package name="Lotus Notes 6 Installable" file-repository="test file repository" version="1.0"> <file name="Notes.zip" path="/usr/local"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-license-pool name="Lotus Notes License Pool" nbr-of-keys="3"> <software-license-key name="112211-223322-122332"/> <software-license-key name="112211-223322-122321"/> <software-license-key name="112211-223322-122343"/>
794
</software-license-pool> <software-resource-template name="Lotus Notes Installation"> <software-resource-template name="Lotus Notes Instance" software-resource-type="INSTANCE"> <template-param name="start" value="true" /> </software-resource-template> <software-resource-template name="Lotus Notes Configuration" software-resource-type="CONFIGURATION"> <template-param name="config-file" value="/usr/local/conf/notes.cfg" /> </software-resource-template> <software-resource-template name="Lotus Notes Application Data" software-resource-type="APPLICATION-DATA"> <template-param name="ds-jndi-name" value="jndi:/ds/notes.ds" /> </software-resource-template> <template-param name="install-dir" value="/usr/local/notes" /> <template-param name="resource-name" value="Lotus Notes" /> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-module name="Lotus Notes Patch 6.1" version="6.1" title="IBM Lotus Notes Patch" vendor="IBM"> <patch-details reboot="true" coexist="false" severity="1" status="APPROVED"/> <installable-package name="Lotus Notes 6.1 Patch" file-repository="test file repository" version="1.0"> <file name="Notes6.1.zip" path="/usr/local"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <!-<discovery name="Discovery" description="Test Discovery" locale="en_US">
795
<property name="test.prop" value="test.value" component="DEPLOYMENT_ENGINE" /> <dcm-policy object-type="server" policy-assertion="new" policy-action="update-dcm" type="discovery" /> <dcm-policy object-type="server" policy-assertion="exist" policy-action="drift" type="discovery" /> <discover-object-type object-type="server" /> <discover-object-type object-type="subnetwork" /> <discover-object-type object-type="switch" /> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </discovery> -->  <customer name="QA Environment"> <application name="CRM" locale="en_US" priority="10" ignored-by-resource-broker="false"> <cluster name="IIS Web Server" is-device-model="Simulator" virtual-ipaddress="10.1.1.131" virtual-tcp-port="80" min-servers="0" max-servers="5" pool="IIS-Win2K" locale="en_US" software-stack="Cluster Stack"> <server-template name="IIS Web Server template 500"> <nic-template vlan-name="VLAN-500"> <network-interface-template> <subnetwork ipaddress="10.1.3.16" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <with-load-balancer name="Alteon 184-01"/> <data-acquisition> &simulator-cpu; </data-acquisition> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <cluster name="Database" locale="en_US" is-device-model="Simulator" managed="false" min-servers="0" max-servers="1" pool="Oracle9i-Solaris8"> <server-template name="Database template 501"> <nic-template vlan-name="VLAN-501"> <network-interface-template> <subnetwork ipaddress="10.1.4.16" netmask="255.255.255.240"/> </network-interface-template>
796
</nic-template> </server-template> <data-acquisition> &simulator-cpu; </data-acquisition> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <property component="KANAHA" name="Number of servers" value="1" /> <objective-analyzer type-name="TIO capacity-on-demand"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </application> <application name="E-Commerce (Customer)" locale="en_US" priority="10" ignored-by-resource-broker="true"> <cluster name="Apache Web" is-device-model="Simulator" virtual-ipaddress="10.1.1.135" virtual-tcp-port="80" min-servers="0" max-servers="4" pool="Apache-Redhat" locale="en_US"> <server-template name="Apache Web template 502"> <nic-template vlan-name="VLAN-502"> <network-interface-template> <subnetwork ipaddress="10.1.5.32" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <with-load-balancer name="Alteon 184-01"/> <data-acquisition> &simulator-cpu; </data-acquisition> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <cluster name="Application Server" locale="en_US" is-device-model="Simulator" virtual-ipaddress="10.1.1.136" virtual-tcp-port="7001" min-servers="0" max-servers="3" pool="Weblogic6-HPUX"> <server-template name="Application Server template 503">
797
<nic-template vlan-name="VLAN-503"> <network-interface-template> <subnetwork ipaddress="10.1.6.48" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <with-load-balancer name="Alteon 184-01"/> <data-acquisition> &simulator-cpu; </data-acquisition> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <cluster name="Database" is-device-model="Simulator" managed="false" min-servers="0" max-servers="1" pool="Oracle9i-Solaris8" > <server-template name="Database template 504"> <nic-template vlan-name="VLAN-504"> <network-interface-template> <subnetwork ipaddress="10.1.7.16" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <data-acquisition> &simulator-cpu; </data-acquisition> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <objective-analyzer type-name="TIO capacity-on-demand"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </application> <application name="Procurement" locale="en_CA" priority="10" ignored-by-resource-broker="true"> <cluster name="Apache Web" is-device-model="Simulator" virtual-ipaddress="10.1.1.137" virtual-tcp-port="80" min-servers="0" max-servers="2" pool="Apache-Redhat" locale="en_US">
798
<server-template name="Apache Web template 505"> <nic-template vlan-name="VLAN-505"> <network-interface-template> <subnetwork ipaddress="10.1.4.32" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <with-load-balancer name="Alteon 184-01"/> <data-acquisition> &simulator-cpu; </data-acquisition> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <cluster name="Application Server" locale="fr_CA" is-device-model="Simulator" virtual-ipaddress="10.1.1.138" virtual-tcp-port="7001" min-servers="0" max-servers="3" pool="Weblogic6-HPUX"> <server-template name="Application Server template 506"> <nic-template vlan-name="VLAN-506"> <network-interface-template> <subnetwork ipaddress="10.1.4.48" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <with-load-balancer name="Alteon 184-01"/> <data-acquisition> &simulator-cpu; </data-acquisition> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <cluster name="Database" is-device-model="Simulator" managed="false" min-servers="0" max-servers="1" pool="Oracle9i-Solaris8"> <server-template name="Database template 507"> <nic-template vlan-name="VLAN-507"> <network-interface-template> <subnetwork ipaddress="10.1.5.16" netmask="255.255.255.240"/> </network-interface-template>
799
</nic-template> </server-template> <data-acquisition> &simulator-cpu; </data-acquisition> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <objective-analyzer type-name="TIO capacity-on-demand"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </application> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </customer> <customer name="Rivers Edge Retail"> <subnetwork ipaddress="10.1.3.48" netmask="255.255.255.240"/> <subnetwork ipaddress="10.1.3.64" netmask="255.255.255.240"/> <application name="Online Store" locale="ja_JP" priority="5"> <cluster name="RiversEdge Web" is-device-model="Simulator" virtual-ipaddress="10.1.1.132" virtual-tcp-port="80" min-servers="2" max-servers="10" pool="Apache-Redhat" locale="en_US"> <server-template name="RiversEdge Web template 510"> <nic-template vlan-name="VLAN-510"> <network-interface-template> <subnetwork address-space="Rivers Edge Retail" ipaddress="10.1.3.48" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <with-load-balancer name="Alteon 184-01"/> <server name="Nile" locale="en_CA"> <nic name="NIC01" locale="fr_FR" connected-to-switch="Cisco 6509-01" connected-to-port="4" managed="false"> <network-interface iftype="Ethernet" name="DMZ" locale="de_DE" address-space="Rivers Edge Retail" ipaddress="10.1.3.49" netmask="255.255.255.240" managed="false"> <virtual-ip-ref virtual-ip="10.1.1.132" port="80" protocol="TCP" maxcon="1000" weight="1.0"/>
800
</network-interface> </nic> <nic name="NIC02" locale="en_CA" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="4" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.103" netmask="255.255.255.0" managed="false"/> </nic> <software-resource name="Tomcat 4 installation" software-module="Tomcat 4" is-device-model="Simulator" type="INSTALLATION" installable-package="Tomcat 4 Installable Package"> <file name="file1" path="/opt/jakarta-tomcat/conf/server.xml"/> <file name="file2" path="/opt/jakarta-tomcat/conf/web.xml"/> <backup-resource type="generic" description="backup set of files"> <property name="local-copy-file-backup-dir" value="/tmp/backup/tomcat_installation"/> <property name="tsm-virtual-file-space" value="tiovfs"/> <property name="tsm-group" value="tomcat_installation"/> <backup-entry backup-system-installation="TSM 5.2 Client Installation" created-time="1102530820632"> <property name="tsm-virtual-file-space" value="tiovfs"/> <property name="tsm-group" value="tomcat_installation"/> </backup-entry> </backup-resource> </software-resource> <software-resource name="TSM 5.2 Client Installation" software-module="TSM 5.2 Client" is-device-model="Simulator" type="INSTALLATION" installable-package="TSM 5.2 Client Installable Package"> <backup-system xml-id="xmlid_1" type="generic" description="TSM backup group"> <property name="install-dir" value="/opt/tivoli/tsm"/> </backup-system> </software-resource> <backup-system-ref xml-ref="xmlid_1"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="Ganges" locale="en_CA"> <nic name="NIC01" locale="fr_CA" connected-to-switch="Cisco 6509-01" connected-to-port="5" managed="false"> <network-interface name="DMZ" locale="en_US" address-space="Rivers Edge Retail" ipaddress="10.1.3.50" netmask="255.255.255.240" managed="false"> <virtual-ip-ref virtual-ip="10.1.1.132" port="80" protocol="TCP" maxcon="1000" weight="1.0"/> </network-interface>
801
</nic> <nic name="NIC02" locale="en_US" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="5" managed="false"> <network-interface name="ADMIN" locale="en_US" ipaddress="10.1.0.104" netmask="255.255.255.0" managed="false"/> </nic> <software-resource name="Tomcat 4 installation 2" software-module="Tomcat 4" is-device-model="Simulator" type="INSTALLATION" installable-package="Tomcat 4 Installable Package"> <backup-resource type="generic" description="backup set of files"> <property name="local-copy-file-backup-dir" value="/tmp/backup/tomcat_installation"/> <property name="tsm-virtual-file-space" value="tiovfs"/> <property name="tsm-group" value="tomcat_installation"/> <backup-entry backup-system-installation="TSM 5.2 Client Installation 2" created-time="1102530820632"> <property name="tsm-virtual-file-space" value="tiovfs"/> <property name="tsm-group" value="tomcat_installation"/> </backup-entry> </backup-resource> </software-resource> <software-resource name="TSM 5.2 Client Installation 2" software-module="TSM 5.2 Client" is-device-model="Simulator" type="INSTALLATION" installable-package="TSM 5.2 Client Installable Package"> <backup-system xml-id="xmlid_2" type="generic" description="TSM backup group"> <property name="install-dir" value="/opt/tivoli/tsm"/> </backup-system> </software-resource> <backup-system-ref xml-ref="xmlid_2"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <cluster name="RiversEdge App" is-device-model="Simulator" virtual-ipaddress="10.1.1.133" virtual-tcp-port="7001" min-servers="2" max-servers="10" pool="Weblogic6-HPUX" locale="en_US"> <server-template name="RiversEdge App template 511">
802
<nic-template vlan-name="VLAN-511"> <network-interface-template> <subnetwork address-space="Rivers Edge Retail" ipaddress="10.1.3.64" netmask="255.255.255.240" /> </network-interface-template> </nic-template> </server-template>
<with-load-balancer name="Alteon 184-01"/> <server name="Danube" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="6" managed="false" is-vlan-aware="true"> <network-interface name="SECURE" address-space="Rivers Edge Retail" ipaddress="10.1.3.66" netmask="255.255.255.240" managed="false"> <virtual-ip-ref virtual-ip="10.1.1.133" port="7001" protocol="TCP" maxcon="1000" weight="1.0"/> </network-interface> </nic> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="6" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.105" netmask="255.255.255.0" managed="false"/> </nic> <software-resource name="Weblogic 8.0 installation" software-module="Weblogic 8.0" is-device-model="Simulator" type="INSTALLATION" installable-package="Weblogic 8.0 Installable Package"> <backup-resource type="generic" description="backup set of files"> <property name="local-copy-file-backup-dir" value="/tmp/backup/weblogic_installation"/> <property name="tsm-virtual-file-space" value="tiovfs"/> <property name="tsm-group" value="weblogic_installation"/> <backup-entry backup-system-installation="HPUX Installation" created-time="1102530820632"> <property name="tsm-virtual-file-space" value="tiovfs"/> <property name="tsm-group" value="weblogic_installation"/> </backup-entry> </backup-resource> </software-resource> <software-resource name="HPUX Installation" software-module="HPUX" type="INSTALLATION" is-device-model="Simulator" installable-package="HPUX Installable Package"> <backup-system xml-id="xmlid_3" type="generic" description="local copy-file backup"/>
803
</software-resource> <software-resource name="TSM 5.2 Client Installation 3" software-module="TSM 5.2 Client" is-device-model="Simulator" type="INSTALLATION" installable-package="TSM 5.2 Client Installable Package"> <backup-system xml-id="xmlid_4" type="generic" description="TSM backup group"> <property name="install-dir" value="/opt/tivoli/tsm"/> </backup-system> </software-resource> <backup-system-ref xml-ref="xmlid_4"/> <backup-system-ref xml-ref="xmlid_3"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="Mississippi" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="7" managed="false"> <network-interface name="SECURE" address-space="Rivers Edge Retail" ipaddress="10.1.3.67" netmask="255.255.255.240" managed="false"> <virtual-ip-ref virtual-ip="10.1.1.133" port="7001" protocol="TCP" maxcon="1000" weight="1.0"/> </network-interface> </nic> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="7" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.106" netmask="255.255.255.0" managed="false"/> </nic>  <software-resource name="HPUX Installation 2" software-module="HPUX" is-device-model="Simulator" type="INSTALLATION" installable-package="HPUX Installable Package"> <backup-system xml-id="xmlid_5" type="generic" description="local copy-file backup"/> </software-resource> <backup-system-ref xml-ref="xmlid_5"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server>
804
<access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <cluster name="RiversEdge DB" is-device-model="Simulator" managed="true" min-servers="1" max-servers="1" locale="en_US"> <server-template name="RiversEdge DB template 511"> <nic-template vlan-name="VLAN-511"> <network-interface-template> <subnetwork address-space="Rivers Edge Retail" ipaddress="10.1.3.64" netmask="255.255.255.240" /> </network-interface-template> </nic-template> </server-template>
<server name="Amazon" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="8" managed="false"> <network-interface name="SECURE" address-space="Rivers Edge Retail" ipaddress="10.1.3.68" netmask="255.255.255.240" managed="false"/> </nic> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="8" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.107" netmask="255.255.255.0" managed="false"/> </nic>  <software-resource name="DB2 For Linux installation" software-module="DB2 For Linux" is-device-model="Simulator" type="INSTALLATION" installable-package="DB2 for Linux Installable Package"> <backup-resource type="generic" description="backup set of files"> <property name="local-copy-file-backup-dir" value="/tmp/backup/db2_installation"/> <property name="tsm-virtual-file-space" value="tiovfs"/> <property name="tsm-group" value="db2_installation"/> </backup-resource> </software-resource> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server>
805
<access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <objective-analyzer type-name="TIO capacity-on-demand"/> <objective-analyzer type-name="TIO reserve-application" start-time="2000-01-01 1:00:00" end-time="2000-01-01 2:00:00"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </application> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </customer> <subnetwork ipaddress="10.1.3.80" netmask="255.255.255.240"/> <subnetwork ipaddress="10.1.3.96" netmask="255.255.255.240"/> <virtual-ip name="VIP for StateBank Web/App" load-balancer="Alteon 184-01" virtual-ip-address="10.1.1.134" in-tcp-port-first="80" in-tcp-port-last="80" out-tcp-port="80" balancing-algorithm="round-robin"/> <customer name="State Bank"> <application name="Self-serve Banking" priority="1" locale="en_US"> <cluster name="StateBank Web/App" is-device-model="Simulator" virtual-ipaddress="VIP for StateBank Web/App" min-servers="2" max-servers="10" pool="WebSphere4-AIX5" locale="en_US"> <server-template name="StateBank Web/App template 601"> <nic-template vlan-name="VLAN-601"> <network-interface-template> <subnetwork ipaddress="10.1.3.80" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <with-load-balancer name="FoundryServerIronXL-01"/> <server name="Oregon" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="9" managed="false"> <network-interface name="DMZ" ipaddress="10.1.3.81" netmask="255.255.255.240" managed="false"> <virtual-ip-ref virtual-ip="VIP for StateBank Web/App" port="80" protocol="TCP" maxcon="1000" weight="1.0"/> </network-interface> </nic>
806
<nic name="NIC02" connected-to-switch="Cisco 6509-01" connected-to-port="10" managed="false"> <network-interface name="SECURE" ipaddress="10.1.3.97" netmask="255.255.255.240" managed="false"/> </nic> <nic name="NIC03" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="9" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.108" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="Delaware" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="11" managed="false"> <network-interface name="DMZ" ipaddress="10.1.3.82" netmask="255.255.255.240" managed="false"> <virtual-ip-ref virtual-ip="VIP for StateBank Web/App" port="80" protocol="TCP" maxcon="1000" weight="1.0"/> </network-interface> </nic> <nic name="NIC02" connected-to-switch="Cisco 6509-01" connected-to-port="12" managed="false"> <network-interface name="SECURE" ipaddress="10.1.3.98" netmask="255.255.255.240" managed="false"/> </nic> <nic name="NIC03" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="10" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.109" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <cluster name="StateBank Mail" is-device-model="Simulator" min-servers="2" max-servers="10" pool="Sendmail-Solaris8" locale="en_US"> <server-template name="StateBank Mail template 602">
807
<nic-template vlan-name="VLAN-602"> <network-interface-template> <subnetwork ipaddress="10.1.3.96" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <server name="Arizona" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="13" managed="false"> <network-interface name="DMZ" ipaddress="10.1.3.83" netmask="255.255.255.240" managed="false"/> </nic> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="11" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.110" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="Montana" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="14" managed="false"> <network-interface name="DMZ" ipaddress="10.1.3.84" netmask="255.255.255.240" managed="false"/> </nic> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="12" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.111" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <cluster name="StateBank DB" is-device-model="Simulator" managed="false" min-servers="2" max-servers="2" locale="en_US"> <server-template name="StateBank DB template 602">
808
<nic-template vlan-name="VLAN-602"> <network-interface-template> <subnetwork ipaddress="10.1.3.96" netmask="255.255.255.240"/> </network-interface-template> </nic-template> </server-template> <server name="NewYork" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="15" managed="false"> <network-interface name="SECURE" ipaddress="10.1.3.99" netmask="255.255.255.240" managed="false"/> </nic> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="13" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.112" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="DC" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="16" managed="false"> <network-interface name="SECURE" ipaddress="10.1.3.100" netmask="255.255.255.240" managed="false"/> </nic> <nic name="NIC02" connected-to-switch="Extreme Alpine 3804-01" connected-to-port="14" managed="false"> <network-interface name="ADMIN" ipaddress="10.1.0.113" netmask="255.255.255.0" managed="false"/> </nic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </cluster> <objective-analyzer type-name="TIO capacity-on-demand"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership>
809
</application> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </customer> <terminal-server name="Console Server" locale="en_US"> <ic name="Console Server Mother Board"> <ic-port port-type="RS232" port-number="1"> <port-connection card="dell-poweredge-2550-3-slot1card" device="dell-poweredge-2550-3" port-number="2" port-type="RS232"/> <sap name="telnetd-5201" port="5201" app-protocol="Telnet" locale="fr_FR" role="host"> <credentials search-key="primary" is-default="true"> <password-credentials username="primary" password="bingo"/> </credentials> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </sap> </ic-port> <ic-port port-type="RS232" port-number="2"> <port-connection card="slot1" device="dell-poweredge-2550-2" port-number="1" port-type="RS232"/> <sap name="telnetd-5202" locale="de_DE" port="5202" app-protocol="Telnet" role="host"> <credentials search-key="primary" is-default="true"> <password-credentials username="primary" password="bingo"/> </credentials> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </sap> </ic-port> </ic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </terminal-server>  <virtual-server-template name="virtual-server-template-01"> <resource-requirement resource-type="cpu" how-many="2" size="0.5" group-name="cpu-group-01"/> <resource-requirement resource-type="disk" how-many="2" size="60" group-name="disk-group-01"/>
810
<resource-requirement resource-type="memory" size="512" group-name="memory-group-01"/> <resource-requirement resource-type="cdrom" group-name="cdrom-group-01" is-shared="true"/> <resource-requirement resource-type="floppy" group-name="floppy-group-01" is-shared="true"/> <resource-requirement resource-type="nic" group-name="nic-group-01"/> <resource-requirement resource-type="nic" group-name="nic-group-01"/> </virtual-server-template> <spare-pool name="Host Platforms" os-type="linux"> <server name="pSeries-01">  <nic name="nic01" connected-to-switch="virtualization-switch" connected-to-module="0" connected-to-port="1" group-name="nic-group-01"> <property name="nic.type" value="100BaseT"/> </nic> <nic name="nic02" connected-to-switch="virtualization-switch" connected-to-module="0" connected-to-port="2" group-name="nic-group-01"> <property name="nic.type" value="100BaseT"/> </nic> <nic name="nic03" connected-to-switch="virtualization-switch" connected-to-module="0" connected-to-port="3" group-name="nic-group-02"> <property name="nic.type" value="100BaseT"/> </nic> <nic name="nic04" connected-to-switch="virtualization-switch" connected-to-module="0" connected-to-port="4" group-name="nic-group-02"> <property name="nic.type" value="100BaseT"/> </nic> <host-platform/>  <resource name="hdd1" resource-type="disk" group-name="disk-group-01" partitionable="true"> <property name="disk.size" value="120"/> </resource> <resource name="hdd2" resource-type="disk" group-name="disk-group-02" partitionable="false"> <property name="disk.size" value="40"/> </resource>
811
<resource name="hdd3" resource-type="disk" group-name="disk-group-02" partitionable="false"> <property name="disk.size" value="40"/> </resource>  <resource name="cpu0" resource-type="cpu" group-name="cpu-group-01" partitionable="true"> <property name="cpu.size" value="2"/> </resource> <resource name="cpu1" resource-type="cpu" group-name="cpu-group-02" partitionable="true"> <property name="cpu.size" value="4"/> </resource>  <resource name="ram0" resource-type="memory" group-name="memory-group-01" partitionable="true"> <property name="memory.size" value="2048"/> </resource> <resource name="ram1" resource-type="memory" group-name="memory-group-02" partitionable="true"> <property name="memory.size" value="1024"/> </resource>  <resource name="cdrom0" resource-type="cdrom" group-name="cdrom-group-01"> </resource>  <resource name="floppy0" resource-type="floppy" group-name="floppy-group-01"> </resource> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </spare-pool>
812
<software-distribution-app name="ITCM" locale="en_US" description="My ITCM App" server="NewYork" vendor="IBM" version="5.1" discovery-application="false"> <property name="tcm.dir" value="c:/usr/ov/TIO" component="DEPLOYMENT_ENGINE" /> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-distribution-app> <software-distribution-app name="ITCM 1" locale="en_US" description="My ITCM App" server="NewYork" vendor="IBM" version="5.2" discovery-application="false"> <property name="PolicyRegion" value="Tivoli PR" component="DEPLOYMENT_ENGINE" /> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-distribution-app> <software-module name="DB2 For Linux 1" is-device-model="Simulator" version="1.0"> <third-party-software-package name="test spb" software-distribution-app="ITCM" locale="en_US" description="My test spb" version="1.1" file-repository="test file repository" status="not_tested" registration-status="not_registered"> <file name="Test SPB binary" path="C:/tmp/package-path"/>  <!-<access-domain-name>sample:all-objects</access-domain-name> -->  </third-party-software-package> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <spare-pool name="Virtual Servers" os-type="linux"> <server name="virtual-server-02" host-platform="pSeries-01">  <nic name="vnic01" connected-to-switch="virtualization-switch" connected-to-module="0" connected-to-port="9" physical-resource="nic01"/> <nic name="vnic02" connected-to-switch="virtualization-switch" connected-to-module="0" connected-to-port="10" physical-resource="nic02"/>  <resource name="vcdrom0" resource-type="cdrom" physical-resource="cdrom0"> <property name="cdrom.property.name" value="cdrom.property.value"/>
813
</resource>  <resource-allocation physical-resource="cpu0" how-many="2" size="0.5"> <property name="cpu-allocation.property.name" value="cpu-allocation.property.value"/> </resource-allocation> <resource-allocation physical-resource="hdd1" how-many="2" size="60"/> <resource-allocation physical-resource="ram0" size="512"/> <resource-allocation physical-resource="cdrom0" is-shared="true"/> <resource-allocation physical-resource="floppy0" is-shared="true"/> <resource-allocation physical-resource="nic01"/> <resource-allocation physical-resource="nic02"/> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </spare-pool>
 <cluster-domain name="tsaHA1" display-name="TSA DB2 HA 2-Node Cluster" cluster-type="Peer-Domain" is-device-model="Cluster Domain Simulator" virtual-ipaddress="VIP for StateBank Web/App" software-module="Windows 2000 Server" observed-state="Online" desired-state="Online">  <property name="cd-prop1" value="cd-prop1-value1"/> <property name="cd-prop2" value="cd-prop1-value2"/>  <cluster-node name="DB2 Server 1" system-name="Oregon" observed-state="Online" desired-state="Online">  <cluster-resource name="nfsserver-server" resource-type="IBM.Application" observed-state="Online" desired-state="Online" is-device-model="Cluster Domain Simulator"> <cluster-resource-attributes> <property name="StartCommand" value="mount_start.ksh"/> <property name="StopCommand" value="mount_stop.ksh"/> <property name="MonitorCommand" value="mount_monitor.ksh"/>
814
<property name="MonitorCommandPeriod" value="6"/> <property name="MonitorCommandTimeout" value="4"/> <property name="StartCommandTimeout" value="120"/> <property name="StopCommandTimeout" value="300"/> <property name="UserName" value="root"/> <property name="ProtectionMode" value="1"/> </cluster-resource-attributes> </cluster-resource> <cluster-resource name="nfsserver-ip" resource-type="IBM.ServiceIP" observed-state="Online" desired-state="Online" is-device-model="Cluster Domain Simulator"/> <cluster-resource name="nfsserver-data-vars" resource-type="IBM.Application" observed-state="Online" desired-state="Online" is-device-model="Cluster Domain Simulator"/> <cluster-resource name="db2-dbinst1-rs" resource-type="IBM.Application" observed-state="Online" desired-state="Online" is-device-model="Cluster Domain Simulator"> <cluster-resource-attributes> <property name="StartCommand" value="db2_start.ksh"/> <property name="StopCommand" value="db2_stop.ksh"/> <property name="MonitorCommand" value="db2_monitor.ksh"/> <property name="MonitorCommandPeriod" value="20"/> <property name="MonitorCommandTimeout" value="10"/> <property name="StartCommandTimeout" value="60"/> <property name="StopCommandTimeout" value="60"/> <property name="UserName" value="root"/> </cluster-resource-attributes> </cluster-resource> <cluster-resource name="db2-dbinst1-rs_mount" resource-type="IBM.SerivceIP" observed-state="Online" desired-state="Online" is-device-model="Cluster Domain Simulator"/> <cluster-resource name="db2-dbinst1-rs_ip" resource-type="IBM.ServiceIP" observed-state="Online" desired-state="Online" is-device-model="Cluster Domain Simulator"> <cluster-resource-attributes> <property name="ProtectionMode" value="1"/> <property name="IPAddress" value="9.21.31.4"/> <property name="NetMask" value="255.255.255.0"/> </cluster-resource-attributes> </cluster-resource> </cluster-node> <cluster-node name="DB2 Server 2" system-name="Delaware" observed-state="Online" desired-state="Online">
815
<cluster-resource name="nfsserver-server" resource-type="IBM.Application" observed-state="Offline" desired-state="Offline" is-device-model="Cluster Domain Simulator"> <cluster-resource-attributes> <property name="StartCommand" value="mount_start.ksh"/> <property name="StopCommand" value="mount_stop.ksh"/> <property name="MonitorCommand" value="mount_monitor.ksh"/> <property name="MonitorCommandPeriod" value="6"/> <property name="MonitorCommandTimeout" value="4"/> <property name="StartCommandTimeout" value="120"/> <property name="StopCommandTimeout" value="300"/> <property name="UserName" value="root"/> <property name="ProtectionMode" value="1"/> </cluster-resource-attributes> </cluster-resource> <cluster-resource name="nfsserver-ip" resource-type="IBM.SerivceIP" observed-state="Offline" desired-state="Offline" is-device-model="Cluster Domain Simulator"/> <cluster-resource name="nfsserver-data-vars" resource-type="IBM.Application" observed-state="Offline" desired-state="Offline" is-device-model="Cluster Domain Simulator"/> <cluster-resource name="db2-dbinst1-rs" resource-type="IBM.Application" observed-state="Offline" desired-state="Offline" is-device-model="Cluster Domain Simulator"> <cluster-resource-attributes> <property name="StartCommand" value="db2_start.ksh"/> <property name="StopCommand" value="db2_stop.ksh"/> <property name="MonitorCommand" value="db2_monitor.ksh"/> <property name="MonitorCommandPeriod" value="20"/> <property name="MonitorCommandTimeout" value="10"/> <property name="StartCommandTimeout" value="60"/> <property name="StopCommandTimeout" value="60"/> <property name="UserName" value="root"/> </cluster-resource-attributes> </cluster-resource> <cluster-resource name="db2-dbinst1-rs_mount" resource-type="IBM.ServiceIP" observed-state="Offline" desired-state="Offline" is-device-model="Cluster Domain Simulator"/> <cluster-resource name="db2-dbinst1-rs_ip" resource-type="IBM.ServiceIP" observed-state="Offline" desired-state="Offline" is-device-model="Cluster Domain Simulator"> <cluster-resource-attributes> <property name="ProtectionMode" value="1"/> <property name="IPAddress" value="9.21.31.5"/> <property name="NetMask" value="255.255.255.0"/>
816
</cluster-resource-attributes> </cluster-resource> </cluster-node>  <cluster-resource-group name="SA-nfsserver-rg" is-device-model="Cluster Domain Simulator" observed-state="Online" desired-state="Online"> <group-member name="nfsserver-server"/> <group-member name="nfsserver-ip"/> <group-member name="nfsserver-data-vars"/> </cluster-resource-group> <cluster-resource-group name="db2-rg" is-device-model="Cluster Domain Simulator" observed-state="Online" desired-state="Online"> <group-member name="db2-dbinst1-rs"/> <group-member name="db2-dbinst1-rs_mount"/> <group-member name="db2-dbinst1-rs_ip"/> </cluster-resource-group>  <cluster-resource-relationship name="rel1" source-resource="db2-dbinst1-rs" target-resource="db2-dbinst1-rs_mount" dependency="DependsOn"/> <cluster-resource-relationship name="rel2" source-resource="db2-dbinst1-rs" target-resource="db2-dbinst1-rs_ip" dependency="DependsOn"/> </cluster-domain>
 <software-module name="DB2 HA Software for Linux" is-device-model="Simulator" version="1.0"> <installable-package name="HA Cluster Product" version="1.0" file-repository="test file repository" status="not_tested"> <file name="HA Cluster Product File" path="/usr/local"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </installable-package> <software-resource-template name="ClusterResources"> <software-resource-template name="cr1"> <software-resource-template name="cr1-cra">  <template-param name="StartCommand" value="mount_start.ksh" /> <template-param name="StopCommand" value="mount_stop.ksh" /> <template-param name="MonitorCommand" value="mount_monitor.ksh" />
817
<template-param name="MonitorCommandPeriod" value="6" /> <template-param name="MonitorCommandTimeout" value="4" /> <template-param name="StartCommandTimeout" value="120" /> <template-param name="StopCommandTimeout" value="300" /> <template-param name="UserName" value="root" /> <template-param name="ProtectionMode" value="1" /> </software-resource-template> <template-param name="name" value="nfsserver-server" /> <template-param name="resource-type" value="IBM.Application" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> <software-resource-template name="cr2"> <template-param name="name" value="nfsserver-ip" /> <template-param name="resource-type" value="IBM.Service" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> <software-resource-template name="cr3"> <template-param name="name" value="nfsserver-data-vars" /> <template-param name="resource-type" value="IBM.Application" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> <software-resource-template name="cr4"> <software-resource-template name="cr4-cra">  <template-param name="StartCommand" value="db2_start.ksh" /> <template-param name="StopCommand" value="db2_stop.ksh" /> <template-param name="MonitorCommand" value="db2_monitor.ksh" /> <template-param name="MonitorCommandPeriod" value="20" /> <template-param name="MonitorCommandTimeout" value="10" /> <template-param name="StartCommandTimeout" value="60" /> <template-param name="StopCommandTimeout" value="60" /> <template-param name="UserName" value="root" /> </software-resource-template> <template-param name="name" value="db2-dbinst1-rs" /> <template-param name="resource-type" value="IBM.Application" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template>
818
<software-resource-template name="cr5"> <template-param name="name" value="db2-dbinst1-rs_mount" /> <template-param name="resource-type" value="IBM.Service" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> <software-resource-template name="cr6">  <software-resource-template name="cr6-cra">  <template-param name="ProtectionMode" value="1" /> <template-param name="IPAddress" value="9.21.31.4" /> <template-param name="MNetMask" value="255.255.255.0" /> </software-resource-template> <template-param name="name" value="db2-dbinst1-rs_ip" /> <template-param name="resource-type" value="IBM.ServiceIP" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> </software-resource-template>
<software-resource-template name="ClusterResourceGroups" software-resource-template-source="/DB2 HA Software for Linux/ClusterResources"> <software-resource-template name="crg1"> <software-resource-template name="crg1-groupMember"> <template-param name="member1" value="nfsserver-server" /> <template-param name="member2" value="nfsserver-ip" /> <template-param name="member3" value="nfsserver-data-vars" /> </software-resource-template> <template-param name="name" value="SA-nfsserver-rg2" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> <software-resource-template name="crg2"> <software-resource-template name="crg2-groupMember"> <template-param name="member1" value="db2-dbinst1-rs" /> <template-param name="member2" value="db2-dbinst1-rs_mount" /> <template-param name="member3" value="db2-dbinst1-rs_ip" /> </software-resource-template> <template-param name="name" value="db2-rg2" />
819
<template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> </software-resource-template> <software-resource-template name="ClusterResourceRelationships" software-resource-template-source="/DB2 HA Software for Linux/ClusterResources"> <software-resource-template name="crr1"> <template-param name="name" value="rel1" /> <template-param name="sourceResource" value="db2-dbinst1-rs" /> <template-param name="targetResource" value="db2-dbinst1-rs_mount" /> <template-param name="dependency" value="Dependson" /> </software-resource-template> <software-resource-template name="crr2"> <template-param name="name" value="rel2" /> <template-param name="sourceResource" value="db2-dbinst1-rs" /> <template-param name="targetResource" value="db2-dbinst1-rs_ip" /> <template-param name="dependency" value="Dependson" /> </software-resource-template> </software-resource-template> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module>  <cluster-domain name="tsaHA2" display-name="TSA DB2 HA 2-Node Cluster (using Resource Template)" cluster-type="Peer-Domain" is-device-model="Cluster Domain Simulator" virtual-ipaddress="VIP for StateBank Web/App" software-module="DB2 HA Software for Linux" observed-state="Unknown" desired-state="Online"> </cluster-domain>
  <software-module name="AIX 5L" version="1.0" is-device-model="Storage Simulator"> <software-capability type="OS" name="os.version" value="5L"/> <installable-package name="AIX 5L Installable Package" version="1.0" file-repository="test file repository" status="not_tested"> <file name="AIX 5L Installable Package file" path="package-path"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name>
820
</access-domain-membership> </installable-package> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-module> <software-application-module name="J2ee Java App" locale="en_US" description="J2ee Java App Application Module" version="6.1" vendor="IBM" is-device-model="Simulator"> <application-module-entry software-module="Web App" position="1" /> <application-module-entry software-module="Ejb App" position="2" /> <application-module-entry software-module="Db App" position="3" /> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </software-application-module>  <storage-function-type name="meta" description="Symmetrix meta" />  <san name="IBM SAN"> <san-fabric name="BrocadeSAN-1" wwn="10:00:00:60:69:51:5c:22" is-device-model="Storage Simulator"> <zone-set name="BrocadeSAN-1-zone-set-1" active="true"> <zone name="ibm-p5-570-1_fcs00_fa1" /> </zone-set> <fibre-channel-switch name="IBM-2109-1" start-port-number="0" end-port-number="31" switch-domain-id="80" wwn="10:00:00:60:69:51:6e:34"> <ic name="fc0" type="FibreChannel"> <fc-port port-number="0" speed="2000" permanent-address="10:00:00:60:69:51:6e:72"/> <fc-port port-number="1" speed="2000" permanent-address="10:00:00:60:69:51:6e:73"/> <fc-port port-number="2" speed="2000" permanent-address="10:00:00:60:69:51:6e:74"/> <fc-port port-number="3" speed="2000" permanent-address="10:00:00:60:69:51:6e:75"/> </ic> <fc-ports ic-name="fc0" first-port-number="4" last-port-number="31" speed="2000"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership>
821
</fibre-channel-switch> <fibre-channel-switch name="IBM-M14-1" start-port-number="0" end-port-number="127" switch-domain-id="81" wwn="10:00:00:60:69:51:6e:35"> <ic name="fc0" type="FibreChannel"> <fc-port port-number="0" permanent-address="10:00:00:60:69:51:6e:97"> <port-connection device="IBM-2109-1" card="fc0" port-number="0" port-type="FIBRE"/> </fc-port> </ic> <fc-ports ic-name="fc0" first-port-number="1" last-port-number="31" speed="2000"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </fibre-channel-switch> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </san-fabric> <san-fabric name="BrocadeSAN-2" is-device-model="Storage Simulator"> <zone-set name="BrocadeSAN-2-zone-set-1" active="true"> <zone name="ibm-p5-570-1_fcs10_fa2" /> <zone name="ibm-p5-570-2_fcs10_14B0"/> </zone-set> <zone-set name="BrocadeSAN-2-zone-set-2" active="false" /> <fibre-channel-switch name="IBM-2109-2" start-port-number="0" end-port-number="31" switch-domain-id="90" wwn="10:00:00:60:69:51:6e:34"> <ic name="fc0" type="FibreChannel"> <fc-port port-number="0" speed="2000" permanent-address="10:00:00:60:69:51:6f:3e"/> <fc-port port-number="1" speed="2000" permanent-address="10:00:00:60:69:51:6f:3d"> <zone-membership-data san-fabric="BrocadeSAN-2" zone-set="BrocadeSAN-2-zone-set-1" zone="ibm-p5-570-1_fcs10_fa2"/> </fc-port> <fc-port port-number="2" speed="2000" permanent-address="10:00:00:60:69:51:6f:3f"/> </ic> <fc-ports ic-name="fc0" first-port-number="3" last-port-number="31" speed="2000"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </fibre-channel-switch>
822
<fibre-channel-switch name="IBM-M14-2" start-port-number="0" end-port-number="127" switch-domain-id="91" wwn="10:00:00:60:69:51:6e:35"> <ic name="fc0" type="FibreChannel"> <fc-port port-number="0" permanent-address="10:00:00:60:69:51:6f:41"> <port-connection device="IBM-2109-2" card="fc0" port-number="0" port-type="FIBRE"/> </fc-port> </ic> <fc-ports ic-name="fc0" first-port-number="1" last-port-number="63" speed="2000"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </fibre-channel-switch> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </san-fabric> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </san> <storage-subsystem name="IBM-ESS-800-1" ansi-t10-id="2105.12345" is-device-model="Storage Simulator"> <storage-volume volume-id="1003" name="1003" logical-volume-type="raid" state="AVAILABLE" storage-function-type="2-Way-BCV-Mir" raid-level="RAID5" consumable-size="9G"/> <storage-volume volume-id="1004" name="1004" logical-volume-type="raid" state="AVAILABLE" storage-function-type="2-Way-BCV-Mir" raid-level="RAID5" consumable-size="9G"/> <storage-volume volume-id="1006" name="1006" logical-volume-type="raid" state="AVAILABLE" storage-function-type="storage" raid-level="RAID5" consumable-size="9G"/> <ic name="00" type="FibreChannel"> <fc-port port-number="0" permanent-address="50:05:07:63:00:C4:A8:10"> <port-connection device="IBM-M14-1" card="fc0" port-number="2" port-type="FIBRE"/> <zone-membership-data san-fabric="BrocadeSAN-1" zone-set="BrocadeSAN-1-zone-set-1" zone="ibm-p5-570-1_fcs00_fa1"/> <storage-volume-on-port lun="0x12" storage-volume="1003"/> </fc-port> </ic> <ic name="04" type="FibreChannel"> <fc-port port-number="0" permanent-address="50:05:07:63:00:C3:A8:11">
823
<port-connection device="IBM-M14-2" card="fc0" port-number="2" port-type="FIBRE"/> <zone-membership-data san-fabric="BrocadeSAN-2" zone-set="BrocadeSAN-2-zone-set-1" zone="ibm-p5-570-1_fcs10_fa2"/> <storage-volume-on-port lun="0x13" storage-volume="1003"/> </fc-port> <fc-port port-number="1" permanent-address="50:05:07:63:00:C3:A8:12"/> </ic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </storage-subsystem> <storage-subsystem name="Symmetrix-1" ansi-t10-id="796" is-device-model="Storage Simulator"> <storage-allocation-pool name="BCV Pool" storage-pool-type="generic" is-device-model="Storage Simulator"> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </storage-allocation-pool> <storage-volume name="0037" logical-volume-type="raid" state="AVAILABLE" consumable-size="2G" raid-level="RAID1" storage-function-type="2-Way-Mir" volume-id="0037"/> <storage-volume name="0038" logical-volume-type="raid" state="AVAILABLE" consumable-size="2G" raid-level="RAID1" storage-function-type="2-Way-Mir" volume-id="0038"/> <storage-volume name="0039" logical-volume-type="raid" state="AVAILABLE" consumable-size="2G" raid-level="RAID1" storage-function-type="2-Way-Mir" volume-id="0039"/> <storage-volume name="003A" logical-volume-type="raid" state="AVAILABLE" consumable-size="2G" raid-level="RAID1" storage-function-type="2-Way-Mir" volume-id="003A"/> <storage-volume name="0040" storage-pool="BCV Pool" logical-volume-type="raid" state="AVAILABLE" consumable-size="8.5G" raid-level="RAID1" storage-function-type="BCV" volume-id="0040"/> <storage-volume name="0041" storage-pool="BCV Pool" logical-volume-type="raid" state="AVAILABLE" consumable-size="8.5G" raid-level="RAID1" storage-function-type="BCV" volume-id="0041"/> <storage-volume name="0042" storage-pool="BCV Pool" logical-volume-type="raid" state="AVAILABLE" consumable-size="8.5G" raid-level="RAID1" storage-function-type="BCV" volume-id="0042"/> <storage-volume name="005D" storage-pool="BCV Pool" logical-volume-type="raid" state="AVAILABLE" consumable-size="8.5G" raid-level="RAID1" storage-function-type="BCV" volume-id="005D"/>
824
<storage-volume name="0063" logical-volume-type="raid" state="AVAILABLE" consumable-size="8.5G" raid-level="RAID10" storage-function-type="other" other-storage-function-type="meta" volume-id="0063"/> <ic name="14A" type="FibreChannel"> <fc-port port-number="0" permanent-address="50:06:04:82:bc:61:a7:0a"/> <fc-port port-number="1" permanent-address="50:06:04:82:bc:61:a7:0b"/> <fc-port port-number="2" permanent-address="50:06:04:82:bc:61:a7:0c"/> </ic> <ic name="14B" type="FibreChannel"> <fc-port port-number="0" permanent-address="50:06:04:82:bc:61:a7:1a"> <port-connection device="IBM-M14-2" card="fc0" port-number="3" port-type="FIBRE"/> <zone-membership-data san-fabric="BrocadeSAN-2" zone-set="BrocadeSAN-2-zone-set-1" zone="ibm-p5-570-2_fcs10_14B0"/> <storage-volume-on-port lun="0x36" storage-volume="0039"/> </fc-port> </ic> <ic name="15A" type="FibreChannel"> <fc-port port-number="0" permanent-address="50:06:04:82:bc:61:a7:2a"> <port-connection device="IBM-M14-2" card="fc0" port-number="4" port-type="FIBRE"/> </fc-port> </ic> <ic name="15B" type="FibreChannel"> <fc-port port-number="0" permanent-address="50:06:04:82:bc:61:a7:3a"> <port-connection device="IBM-M14-2" card="fc0" port-number="5" port-type="FIBRE"/> </fc-port> </ic> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </storage-subsystem>  <storage-template name="AIX-5L Storage template 1"> <volume-container-setting name="vg1" storage-manager-name="storage-manager-local"> <logical-volume-setting name="lv01" logical-volume-type="raid" consumable-size-min="4G" raid-level="RAID1" storage-function-type="BCV"> <file-system-setting label="/data1" file-system-size="4G" read-only="true" file-system-type="FAT32" ref-point="/data1"/> </logical-volume-setting> <logical-volume-setting name="lv02" logical-volume-type="raid" consumable-size-min="1G" raid-level="RAID1" storage-function-type="BCV"/>
825
<logical-volume-setting name="lv03" consumable-size-min="42G"> <file-system-setting label="/data3" file-system-size="40G" file-system-type="FAT32" ref-point="/data3"/> </logical-volume-setting> <physical-volume-setting name="SAN disk 1" primary="true"> <disk-partition-setting disk-partition-type="Primary" bootable="true" os-partition="true" partition-size="4G"> <explicit-logical-volume-setting logical-volume-setting="lv01"/> </disk-partition-setting> <disk-partition-setting disk-partition-type="Extended" partition-size="1G"> <explicit-logical-volume-setting logical-volume-setting="lv02"/> </disk-partition-setting> <storage-multipath-setting name="SAN disk 1 multipath"> <data-path-setting hba-port-name="fcs0:0" fa-port-name="15A:0" physical-volume-name="hdisk10" san-fabric-name="BrocadeSAN-2" zone-set-name="BrocadeSAN-2-zone-set-1" zone-name="AIX-5L-fcs00_15A0"/> <data-path-setting hba-port-name="fcs1:0" fa-port-name="15B:0" physical-volume-name="hdisk11" san-fabric-name="BrocadeSAN-2" zone-set-name="BrocadeSAN-2-zone-set-1" zone-name="AIX-5L-fcs10_15B0"/> <storage-allocation-pool-info storage-allocation-pool-name="BCV Pool"/> </storage-multipath-setting> <san-storage-setting consumable-size-min="5G" raid-level="RAID1" storage-function-type="BCV" /> </physical-volume-setting> <physical-volume-setting name="DASD 1"> <disk-partition-setting partition-size="40G"> <explicit-logical-volume-setting logical-volume-setting="lv03"/> </disk-partition-setting> <dasd-template name="dasd template 1" dasd-name="hdisk0" dasd-size="40G"/> </physical-volume-setting> <physical-volume-setting name="SAN disk 2" primary="true"> <disk-partition-setting disk-partition-type="Logical" partition-size="2G"> <explicit-logical-volume-setting logical-volume-setting="lv03"/> </disk-partition-setting> <storage-multipath-setting name="SAN disk 2 multipath" > <data-path-setting hba-port-name="fcs0:0" fa-port-name="15B:0" physical-volume-name="hdisk12" san-fabric-name="BrocadeSAN-2" zone-set-name="BrocadeSAN-2-zone-set-1" zone-name="AIX-5L-fcs00_15B0"/> <storage-subsystem-info storage-subsystem-name="Symmetrix-1"/> </storage-multipath-setting> <san-storage-setting consumable-size-min="2G" raid-level="RAID1" storage-function-type="2-Way-Mir" /> </physical-volume-setting> </volume-container-setting>
826
</storage-template>  <subnetwork ipaddress="192.178.0.0" netmask="255.255.255.0"/> <spare-pool name="Storage-AIX5L" os-type="aix" locale="en_US"> <server-template name="Storage-AIX5L template 1" storage-template="AIX-5L Storage template 1"> <nic-template vlan-name="VLAN-1010"> <network-interface-template> <subnetwork ipaddress="192.178.0.0" netmask="255.255.255.0"/> </network-interface-template> </nic-template> </server-template> <server name="ibm-p5-570-1" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="45"> <network-interface name="eth0" ipaddress="192.178.0.169" managed="false" netmask="255.255.255.0"/> </nic> <ic name="fcs0" type="FibreChannel"> <fc-port port-number="0" permanent-address="10:00:00:00:c9:25:57:0c"> <port-connection device="IBM-2109-1" card="fc0" port-number="2" port-type="FIBRE"/> <zone-membership-data san-fabric="BrocadeSAN-1" zone-set="BrocadeSAN-1-zone-set-1" zone="ibm-p5-570-1_fcs00_fa1"/> <storage-volume-on-port lun="0x23" storage-subsystem="IBM-ESS-800-1" storage-volume="1003"/> </fc-port> <fc-port port-number="1" permanent-address="10:00:00:00:c9:25:57:0d"/> </ic> <ic name="fcs1" type="FibreChannel"> <fc-port port-number="0" permanent-address="10:00:00:00:c9:25:57:11"> <port-connection device="IBM-2109-2" card="fc0" port-number="3" port-type="FIBRE"/> <zone-membership-data san-fabric="BrocadeSAN-2" zone-set="BrocadeSAN-2-zone-set-1" zone="ibm-p5-570-1_fcs10_fa2"/> <storage-volume-on-port lun="0x24" storage-subsystem="IBM-ESS-800-1" storage-volume="1003"/> </fc-port> </ic> <software-resource name="AIX 5L installation" software-module="AIX 5L" type="INSTALLATION" installable-package="AIX 5L Installable Package"/> <storage-manager name="storage-manager-local" manage-remote="true" is-device-model="Storage Simulator"> <volume-container name="vg1"/>
827
<access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </storage-manager> <volume-container-access server="ibm-p5-570-1" storage-manager="storage-manager-local" volume-container="vg1"> <logical-volume name="lv01" logical-volume-type="simple" consumable-size="8G" raid-level="RAID0"> <file-system label="/data1" file-system-size="8G" read-only="true" file-system-type="FAT32"/> </logical-volume> <logical-volume name="lv02" consumable-size="9G" logical-volume-type="raid" storage-function-type="2-Way-BCV-Mir" raid-level="RAID5"> <file-system label="/data2" file-system-size="9G" file-system-type="FAT32"/> </logical-volume> </volume-container-access> <physical-volume name="hdisk0" total-size="10G"> <volume-container-info server="ibm-p5-570-1" storage-manager="storage-manager-local" volume-container="vg1"/> <disk-partition partition-size="8G" disk-partition-type="Logical" bootable="true" logical-volume="lv01"/> </physical-volume> <physical-volume name="hdisk1" total-size="9G" storage-subsystem="IBM-ESS-800-1" storage-volume="1003" host-lun="0x23"> <volume-container-info server="ibm-p5-570-1" storage-manager="storage-manager-local" volume-container="vg1"/> <disk-partition partition-size="9G" logical-volume="lv02"/> </physical-volume> <physical-volume name="hdisk2" total-size="9G" storage-subsystem="IBM-ESS-800-1" storage-volume="1003" host-lun="0x24"> <volume-container-info server="ibm-p5-570-1" storage-manager="storage-manager-local" volume-container="vg1"/> </physical-volume> <physical-volume name="cd_rom" total-size="80G"> <file-system label="/cd_data" file-system-size="80G" read-only="true" file-system-type="FAT32"/> </physical-volume> <data-path target-storage-subsystem="IBM-ESS-800-1" target-storage-volume="1003" fa-port-name="00:0" fa-lun="0x12" hba-port-name="fcs0:0" host-lun="0x23"> <zone-info san-fabric="BrocadeSAN-1" zone-set="BrocadeSAN-1-zone-set-1" zone="ibm-p5-570-1_fcs00_fa1"/> </data-path>
828
<data-path target-storage-subsystem="IBM-ESS-800-1" target-storage-volume="1003" fa-port-name="04:0" fa-lun="0x13" hba-port-name="fcs1:0" host-lun="0x24"> <zone-info san-fabric="BrocadeSAN-2" zone-set="BrocadeSAN-2-zone-set-1" zone="ibm-p5-570-1_fcs10_fa2"/> </data-path> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <server name="ibm-p5-570-2" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="46"> <network-interface name="eth0" ipaddress="192.178.0.170" managed="false" netmask="255.255.255.0"/> </nic> <ic name="fcs0" type="FibreChannel"> <fc-port port-number="0" permanent-address="10:00:00:00:c9:25:57:2c"/> </ic> <ic name="fcs1" type="FibreChannel"> <fc-port port-number="0" permanent-address="10:00:00:00:c9:25:57:21"> <port-connection device="IBM-2109-2" card="fc0" port-number="4" port-type="FIBRE"/> <zone-membership-data san-fabric="BrocadeSAN-2" zone-set="BrocadeSAN-2-zone-set-1" zone="ibm-p5-570-2_fcs10_14B0"/> <storage-volume-on-port lun="0x47" storage-subsystem="Symmetrix-1" storage-volume="0039"/> </fc-port> </ic> <software-resource name="AIX 5L installation" software-module="AIX 5L" type="INSTALLATION" installable-package="AIX 5L Installable Package"/> <storage-manager name="storage-manager-local" is-device-model="Storage Simulator"> <volume-container name="vg1"/> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </storage-manager> <volume-container-access server="ibm-p5-570-2" storage-manager="storage-manager-local" volume-container="vg1"> <logical-volume name="lv01" logical-volume-type="simple" consumable-size="30G" raid-level="RAID0"> <file-system label="/data1" file-system-size="30G" read-only="true" file-system-type="FAT32"/> </logical-volume>
829
<logical-volume name="lv02" logical-volume-type="raid" consumable-size="2G" raid-level="RAID1" storage-function-type="2-Way-Mir"> <file-system label="/data2" file-system-size="2G" file-system-type="FAT32"/> </logical-volume> <logical-volume name="lv03" logical-volume-type="simple" consumable-size="10G" raid-level="RAID0" storage-function-type="backup"/> </volume-container-access> <physical-volume name="hdisk0" total-size="20G"> <volume-container-info server="ibm-p5-570-2" storage-manager="storage-manager-local" volume-container="vg1"/> <disk-partition disk-partition-type="Extended" partition-size="20G" bootable="true" logical-volume="lv01"/> </physical-volume> <physical-volume name="hdisk1" total-size="20G"> <volume-container-info server="ibm-p5-570-2" storage-manager="storage-manager-local" volume-container="vg1"/> <disk-partition disk-partition-type="Primary" partition-size="10G" logical-volume="lv01"/> <disk-partition partition-size="10G" logical-volume="lv03"/> </physical-volume> <physical-volume name="hdisk2" total-size="2G" storage-subsystem="Symmetrix-1" storage-volume="0039" host-lun="0x47"> <volume-container-info server="ibm-p5-570-2" storage-manager="storage-manager-local" volume-container="vg1"/> <disk-partition partition-size="2G" logical-volume="lv02"/> </physical-volume> <data-path target-storage-subsystem="Symmetrix-1" target-storage-volume="0039" fa-port-name="14B:0" fa-lun="0x36" hba-port-name="fcs1:0" host-lun="0x47"> <zone-info san-fabric="BrocadeSAN-2" zone-set="BrocadeSAN-2-zone-set-1" zone="ibm-p5-570-2_fcs10_14B0"/> </data-path> <file-system-mount mount-point="/mount1" ref-point="/share1" ref-server="ibm-p5-570-1"> <ref-logical-volume-file-system ref-storage-manager="storage-manager-local" ref-volume-container="vg1" ref-logical-volume="lv01" /> </file-system-mount> <file-system-mount mount-point="/mount2" ref-point="/share2" ref-server="ibm-p5-570-1"> <ref-physical-volume-file-system ref-physical-volume="cd_rom" /> </file-system-mount> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name>
830
</access-domain-membership> </server> <server name="ibm-p5-570-3" locale="en_US"> <nic name="NIC01" connected-to-switch="Cisco 6509-01" connected-to-port="47"> <network-interface name="eth0" ipaddress="192.178.0.171" managed="false" netmask="255.255.255.0"/> </nic> <ic name="fcs0" type="FibreChannel"> <fc-port port-number="0" permanent-address="10:00:00:00:c9:25:57:4e"> <port-connection device="IBM-2109-2" card="fc0" port-number="5" port-type="FIBRE"/> </fc-port> </ic> <ic name="fcs1" type="FibreChannel"> <fc-port port-number="0" permanent-address="10:00:00:00:c9:25:57:4f"> <port-connection device="IBM-2109-2" card="fc0" port-number="6" port-type="FIBRE"/> </fc-port> </ic> <software-resource name="AIX 5L installation" software-module="AIX 5L" type="INSTALLATION" installable-package="AIX 5L Installable Package"/> <storage-manager name="storage-manager-local" is-device-model="Storage Simulator"> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </storage-manager> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </server> <access-domain-membership> <access-domain-name>sample:all-objects</access-domain-name> </access-domain-membership> </spare-pool> <kanaha-config> <dcm-object type="cluster" name="RiversEdge Web"> <data-acquisition> &simulator-cpu; </data-acquisition> </dcm-object> <dcm-object type="cluster" name="RiversEdge App"> <data-acquisition>
831
&simulator-cpu; </data-acquisition> </dcm-object> <dcm-object type="cluster" <data-acquisition> &simulator-cpu; </data-acquisition> </dcm-object> <dcm-object type="cluster" <data-acquisition> &simulator-cpu; </data-acquisition> </dcm-object> <dcm-object type="cluster" <data-acquisition> &simulator-cpu; </data-acquisition> </dcm-object> <dcm-object type="cluster" <data-acquisition> &simulator-cpu; </data-acquisition> </dcm-object> </kanaha-config>
name="RiversEdge DB">
name="StateBank Web/App">
name="StateBank Mail">
name="StateBank DB">
<monitoring-app name="ITM_App1" is-device-model="Simulator" description="ITM" vendor="IBM" version="5.5" server="hp-sa1100-1" > <property name="propertyName1" value="value1" /> <property name="propertyName2" value="value2" /> </monitoring-app> <monitoring-config name="ITM_Austin_Config1" description="Default NetView profile for AIX servers for StateBank" monitoring-app="ITM_App1" > <resource-type type="deviceModel" name="Simulator" /> <property name="DeleteExistingProfilesFromEndpoint" value="TRUE" /> <property name="Lenient" value="TRUE" /> <property name="ProfileDistributionOptions" value="" /> <property name="Profiles" value="TestMon1;TestMon2" /> <property name="RemoveSubscriptions" value="TRUE" /> <property name="SubscriptionProfileManagers" value="monitoring;Test1" /> </monitoring-config> </datacenter>
832
833
834
Appendix B.
Additional material
This redbook refers to additional material that can be downloaded from the Internet as described below.
Locating the Web material

The Web material associated with this redbook is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to: ftp://www.redbooks.ibm.com/redbooks/SG247261 Alternatively, you can go to the IBM Redbooks Web site at: ibm.com/redbooks Select the Additional materials and open the directory that corresponds with the redbook form number, SG247261.
Using the Web material

The additional Web material that accompanies this redbook includes the following files: File name SG247261.zip Description AppA_v1.0.spb file
835
System requirements for downloading the Web material

The following system configuration is recommended: Hard disk space: Operating System: 10 MB minimum Windows/Linux
How to use the Web material

Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder.
836
Abbreviations and acronyms

ACL ADS APDE APE APM CCMDB CDS CIT CMS CSV CVT DCM DE DHCP DMS DNS EJB eTPM FR GRT IBM IEEE ITSO JCF JVM access control list Advanced Deployment Services Automation Package Development Environment Activity Plan Editor Activity Plan Manager Change and Configuration Management Database dynamic content delivery services Common Inventory Technology content delivery services comma separated value Component Verification and Test data center model Deployment Engine dynamic device management services Domain Name System Enterprise Java Beans Embedded Tivoli Provisioning Manager File Repository Global Response Team International Business Machines Corporation Inc. International Technical Support Organization Java Client Framework Java Virtual Machine PDF POC RDBMS RDM RIM RXA RXA SAP SAP SAP SAPs SCM OID OPAL OS OSGi KDE KPIs LDO LWI MSAD NIM NIS NPTL OAMP K Desktop Environment key performance indicators logical device operation Lightweight Infrastructure Microsoft Active Directory Network Installation Manager Network Information Service Native POSIX Thread Library Operations, Administration, Maintenance and Provisioning Operations, Administration, Maintenance and Provisioning infrastructure object identifier Open Process Automation Library operating system Open Services Gateway Initiative portable document file proof of concepts Relational Data Base Management Systems Remote Deployment Manager RDBMS Interface Module Remote Execution Access remote execution and access scope and credentials service access point SOA Service Access Point service access points Security Compliance Manager
OAMPi
837
SDI Servers SIE SMB SMB SMF SOA SDI SPB SPE SPO SSH SSL TADDM
SOA-based Scalable Distribution Infrastructure share resources software installation engine Server Message Block Small-Medium Business Service Management Framework Service Oriented Architecture Scalable Distribution Infrastructure software package block Software Package Editor SoftwarePackage object Secure Shell Secure Sockets Layer Tivoli Application Dependency Discovery Manager Tivoli common agent Tivoli Configuration Manager Topology Installer Launcher Tivoli management agent endpoints Tivoli Provisioning Manager user datagram protocol Web Services Resource Framework Windows Server Update Services Windows Update Agent
TCA TCM TIL TMA TPM UDP WSRF WSUS WUA
838
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 about ordering these publications, see How to get IBM Redbooks on page 840. Note that some of the documents referenced here may be available in softcopy only. Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery and Tracking V1.1, SG24-7264
Other publications
These publications are also relevant as further information sources: Tivoli Provisioning Manager Version 5.1, Installation Guide Guide for Windows, SC32-2232 Tivoli Provisioning Manager Version 5.1, Fast Start Installation Guide for Windows, SC32-2206 Tivoli Provisioning Manager Version 5.1 Problem Determination & Troubleshooting Guide, SC32-2236
Online resources
These Web sites are also relevant as further information sources: AIX tech support site: https://techsupport.services.ibm.com/server/aix.fdc Location to download AIX packages required by Tivoli Provisioning Manager Version 5.1: http://www.ibm.com/server/aix/products/aixos/linux/download.html Location to download OpenSSH, required by Tivoli Provisioning Manager Version 5.1:
839
https://sourceforge.net/projects/openssh-aix Location to download cabextract.html for AIX OS: http://aixpdslib.seas.ucla.edu/packages/cabextract.html Microsoft web site to download WUA: http://go.microsoft.com/fwlink/?LinkId=43264 MicrosoftWeb location: http://go.microsoft.com/fwlink For information about KDE: http://www.kde.org/ Location to download the Expect package: http://www.ibm.com/servers/aix/products/aixos/linux/download.html Orchestration and Provisioning Automation Library Web site: http://catalog.lotus.com/wps/portal/topal Eclipse SDK version 3.1.2 download Web site: http://www.eclipse.org/
How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site: ibm.com/redbooks
Help from IBM

IBM Support and downloads ibm.com/support IBM Global Services ibm.com/services
840
Index
Symbols
/etc/services file 362 Add a hub 623 add a Hub definition 623 Add a spoke 624 Add an activity plan database 624 admin.ldif 638 Agent health 22 Agent Manager 309 agent recovery service 310 collecting log files 317 database 335 different destination path 312 firewall considerations 311 functions 309 HealthCheck 315 installing 312 ports used 311 properties file 312 service 309 troubleshooting 314 version 320 agent manager 580 agent manager process 580 agent manager server 311 agent manager service 309 agent recovery service 309, 311 Antivirus compliance check 349 McAfee VirusScan Enterprise 349 Norton Antivirus 349 Norton Antivirus Corporate Edition 349 Sophos Anti-Virus 349 Symantec Antivirus Corporate Edition 349 Trend Micro Antivirus 349 apde.zip 240 Application 24 Application Cluster 24 application-specific information 667 asynchronous events 310 automated remediation 386 automation engine 10 Automation Package Developer Environment (APDE) 398 Automation Package Development Environment (APDE) 239 Automation Packages 24
Numerics
64 bit kernel 77
A
access group 598 Access groups 529 Access Permission group 530 access permission group 598 Activate Windows service 356 Active Directory 219, 480 activity plan 633 activity plan database 626 Activity Plan Editor (APE) 734 activity plan engine 663 Activity Planner 734 commit with a reboot 735 inoperative plans 735 new engine 736 performance and scalability 736 not replicated activity plans 736 activities with By Depot conditions 736 Pristine activities 736 Rembo activities 736 targets as Users, Device, Enterprise Directory 736 operation mapping 735 replicated plans 735 scenario 738 supported operations 735 Transactional operations with autocommit options 735 unsupported options Conditions 738 Scheduling 738 Supported targeting 738 Target resolution 738 Variables 738 Adaptive 438
841
automation packages 569 available bandwidth 260
B
Blade Server 9 Blade Server provisioning 9 book file 226 branch office 607 Built-in Variables 736 bulk data distribution 237 By Depot conditions 736 Byte-level differencing 673
C
C$ 177 CabExtract utility 417 Capture Image Wizard 479 Capturing an image 16 controlling the BIOS settings 468 defining the operating system 469 discovering the local users 470 discovering the OS attributes 469 enable boot from NIC 472 opbtaining an IP address 468 performing an SMB or SSH discovery 469 preperation 468 setting the administrator DCM password 472 Capturing the images 473 booting the Rembo kernel 479 describing the image 477 initiating the process 474 performing the actual capture 479 schedule the image capture 478 selecting the Boot Server 476 selecting the computer 473 setting the time-out 475 source computer 475 capturing the images 473 case study 295 company 295 infrastucture component overview 296 dedicated depot servers 297 firewalls 297 Groups 300 logic behind the design 300 Regions 297 server 296 shared depot servers 297
targets 297 Zones 298 requirements 296 Cendura 21 central data centre 606 central image depot 73 creating 73 Change Configuration Manager 664 Changing graph types 511 CID (Configuration Installation and Distribution) 456 CIT installation image 134 client BIOS settings 492 Cloudscape 64, 310 Cluster.AddServer LDO 558 coexistence environment 598 co-existence functionality 9 command line interface 547 Common Agent Services 307, 321322 architecture 308, 310 components 308 Agent Manager 309 resource manager 309 Tivoli common agent 309 goal 308 infrastructure 308 overview 308 registry 310 Common Agent Services Agent Manager 41 Common Data Model 1.9 specification 226 Common Inventory Technology (CIT) 151 Common Inventory Technology 2.2 21 Compliance checks 347 Compliance management 346 software compliance checks Optional 348 Prohibited 348 Required 348 automated remediation 386 compliance checks 347 concepts 346 creating a custom remediation workflow 396 creating compliance checks 357 for Endpoint Agent 358 for Inventory 372 for Linux 360 for Solaris 369 for Windows 364
842
managing non-compliance 382 managing recommendations 388 Approve 388 Close 388 Ignore 388 Open 388 Run 388 Schedule 388 process 346 running the compliance check 377 scenario 346 scheduling the compliance check 381 security compliance checks 348 AIX activity auditing 348 Antivirus compliance check 349 Connection time logs 349 Endpoint Agent 349 Hard disk password 350 Linux System Logging 350 Logon failure logs 349 Maximum password age 353 Operating system patches and updates 350 Power-on password 351 Remote root login 351 Restrict other software 351 Screen saver 351 Active 351 Maximum timeout value 352 Password protected 351 Set user ID logs 349 Unauthorized guest access 353 UNIX file permissions 352 UNIX services 352 User password 353 Maximum password age 353 Minimum password length 353 Minimum password reuse count 353 Windows event logging 354 Minimum retention period of application data 354 Minimum retention period of security data 354 Minimum retention period of system data 354 Minimum value of the maximum application log size 354 Minimum value of the maximum security log size 354 Minimum value of the maximum system
log size 354 Windows file permission 354 Change Permissions 355 Create Files/Write Data 354 Create Folders/Append Data 354 Delete 355 Delete Subfolders and Files 355 List Folder/Read Data 354 Read Attributes 355 Read Extended Attributes 355 Read Permissions 355 Synchronize 355 Take Ownership 355 Traverse Folder/Execute File 355 Write Attributes 355 Write Extended Attributes 355 Windows Firewall 355 McAfee Desktop Firewall 355 Windows Native Firewall 355 Zone Alarm Integrity Flex Firewall 355 Windows services 356 Running state 356 Service state 356 Startup mode 356 Software compliance checks 348 software compliance checks 348 numeric priority level 348 types 346 viewing recommendations 383 Workflow Composer 398 Workflow Editor 398 Composite Application Development 9 composite applications 4 Computer 667 Concurrency Level 200 Concurrency Level parameter 207 console.log 633 Continuous operation 321 copy file 26 copying reports 499 Core agent 324 create the software product 247 Create_SOA_Endpoint_Operation_SAP workflow 729 creating a depot 261 creating a new workflow 397 creating new reports 499 creating SOA service access point 729 creating software packages 237
Index
843
Credentials tab 205 custom remediation workflow 396 associating with the Recommendation Key 407 compiling 404 creating 396 ComplianceRecommendationID 400 TargetId 400 testing 404 custom signatures 212 Custom software signatures 212 CVS file 515 Cygwin installation 417 Cygwin X server 68
D
D$ 177 data center model (DCM) 2425, 413, 578, 665 data center model database 186, 420 data center model objects 26 data center object id 577 Data Moving 606 DCM drift record 482 dcmexport.cmd 579 default password 119, 172 default user ID 119 delete a computer 489 Demo installation 44 Deployment Engine (DE) 10, 421 Deployment Engine functionality 10 Depot 40 checking the status 263 how files get into depots 264 viewing a list of files 263 Depot server 260 features 260 prerequisites 260 desired state 372 device driver 24 Device Management 672 Device management server 268 Device Management Service Device manager components server 268 Device management service 267 concepts 269 Device manager instFederatedAgentPollFrequencyInMinutes parameter 268
jes.properties file 269 polling interval how to change 269 subagents 268 Device manager components 268 sending jobs to TCA 269 Service Access Point 269 device management service 41 Device Management Service Federating Agent 40, 206 Device Management Service Federator 39, 206 device manager federator 14 Device manager subagent 40 Device manager subagents 268 Device.CopyFile 323 Device.Execute.Command 323 DHCP negotiation process 481 Discovery Configuration 661 Discovery Library Reader 226 Discovery mechanism 176 Secure Shell (SSH) discovery 189 Discovering external resources with Discovery Library Reader 226 introduction 176 Inventory discovery 194 Inventory scenario 197 Microsoft Active Directory discovery 218 Network discovery 176 Server Message Block (SMB) discovery 177 specify the scope 179 DISPLAY variable 68 Displaying reports 509 distribute software products 283 distributing software 275 case study 295 delivering before installing 283 file download 291 installing a software package 278 installing a software stack 278 populating depots 289 process step by step 288 publishing 288 scheduling 284 software installation 293 target download initiation 290 to Tivoli endpoints 699 uninstall 286 uploading a file 288
844
Distribution Status Console 664 distrubuting software tracking distribution 712 tracking the installation task 712 DMZ 421 DNS alias 311 DNS lookup mechanism 311 domain 86 Domain Name System (DNS) server 311 domain search list 311 driver 24 dstributing software publishing to depots 275 duplicate row 692 dynamic content delivery service 14, 258 dynamic content delivery services 41 Dynamic Content Delivery Services Management Center 40 Dynamic content delivery services management center 40 Dynamic content delivery services subagent 40 Dynamic Content Distribution Service 237 dynamic content distribution service 237 Dynamic Content Distribution Service Peer Manager 272 dynamic group 506
F
failed restore 486 Fast Start installation 44 file download 291 file repository 237238, 245, 417 filename.sp 242 FileRepository.GetFile 619 FileRepository.PutFil 619 Firefox 122, 544 FR root path 665 full cloning 459 fully qualified host name 86
G
gateway 606607, 633, 670 Gateway manager and service 57 gateway service 57 groups 254
H
hard coded 79 HealthCheck script 317 HealthCheck.sh 315 hidden administrative disk shares 177 hosts file 131 hub-spoke architecture 595, 602
E
ead 636 Eclipse directory 240 Eclipse provided with IBM Help 240 Eclipse SDK version 3.1.2 240 eclipseLauncher.bat 239 Editing reports 508 editing reports 499 eDMS servers 268 e-mail notification 526 Embedded IBM Tivoli Provisioning Manager 10 endpoint 648 Enterprise Java Beans (EJB) 24 env command 85 execute command 26 executeDeploymentRequest 557 expandable help 170 Expect 5.32 68 Expect package 68 Exporting the CCMDB data 227 extrac32.exe 418
I
IBM boot server 21 IBM developer kits 551 IBM Discovery library reader 36 IBM Help Center 240 IBM Network Installation Manager (NIM) 21 IBM Remote Deployment Manager 21 IBM Service Management Framework (SMF) 7 IBM WebSphere Everyplace 8 main highlights 7 OSGi Service Platform 7 IBM SOA 4 IBM SOA Foundation 4 architecture 5 best practices 5 components 4 IBM software portfolio 4 IBM Tivoli Change and Configuration Management Database (CCMDB) 20, 227 IBM Tivoli Common Agent Discover Device discov-
Index
845
ery 372 IBM Tivoli common agent Discovery 337 IBM Tivoli common agent Discovery configuration 335 IBM Tivoli Directory Server 598 IBM Tivoli Monitoring 549 IBM Tivoli Provisioning Manager Express Version 4.1 10 IBM Tivoli Provisioning Manager OEM Edition / Embedded Tivoli Provisioning Manager 10 IBM Tivoli Provisoning Manager for OS deployment Version 5.1 10 IBM Tivoli Service Management 12 IBM WebSphere Everyplace 8 IDML (International Development Markup Language) 226 IDML format 227 Image management Advanced topics 489 image restoration 458459 Full cloning 459 No cloning 459 introduction 456 process overview 456 Rembo Boot Server 461 Restoring the images 481 Scenario 457 ways to perform 458 Image managment capturing an image 468 image restoration 458459 import software product 243 importing a software package 244 Importing CCMDB data 228 importSoftwareSignature.cmd 214 input streams 58 Install_Agent workflow 717 installation log files 114 Installation methods Fast Start 63 Silent installation 63 Tivoli Provisioning Manager Topology installer 62 Installation scenarios Enterprise installation 64 on AIX 65 creating file systems structure 79 default path locations 79 installation log files 114
installing
verifying umask settings

installing OpenSSH 82 installing OpenSSL 82 installing required packages 81 installing starting the wizard 88 machine hardware requirements 78 starting the GUI 116 static ip address 86 step by step installation 87 time required for installation 115 use 64 bit kernel 77 xlC.rte 6.0 run-time code 85 Fast Start installation 63 on Windows 143 unattended installation on Linux 120 check the SSH status 130 creating a response file with the installer 133 creating file systems structure 128 hardware requirements 122 how to create a response file 133 installing required packages 129 modify the prompt 131 preparing Linux systems 127 prerequisite software 124 RedHat Advanced Server 127 response file 133 running a silent installation 142 software requirements 123 starting the GUI 143 step by step installation 133 SUSE LINUX Server 9 127 verify script location 130 verify umask settings 130 WebSphere Application Server 132 Installing agent manager 312 common agent 322 Cygwin 144 Software Package Editor 239 Tivoli Provisioning Manager behind a firewall 71 Fast Start installation 63 log files 114 on AIX 65 on Windows 146 single-node topology 66 two-node topology 67
85
846
unattended installation on Linux 120 installing a WUA agent 424 instFederatedAgentPollFrequencyInMinutes 268 Interim Fix 617 Interim Fixes 613, 616 inv_db database 615 inv_query 615 Inventory data 667 Inventory discovery 194 Inventory logs 211 Inventory profile 597, 667 Inventory reports 678 Inventory results 208 Inventory scans 211, 372 Inventory scenario 197 Inventory scripts 615 Inventory Server 616 Inventory Specialist 641 inventory task 605 InventoryConfig 633, 661, 663 InventoryConfig profiles 633 InventoryConfig scan 685 invoking the installer 89 IP address 178 ipv4/RXA 323 irs.conf file 86
ldapinst 106 ldapinst user 106 ldapmodify 639 left hand side task navigation tree 170 Light Stack Tivoli Provisioning Manager 64 LocalFileRepository 238, 245 logical device 26 logical device operation (LDO) 26, 619, 671 Logical Device.Logical Operation 561 logical operation 24 LogicallyDeleteAgents 334 Login (OS users) 670 login names 638
M
MAC address 178, 490 main content area 170 manage DHCP agents 212 managed node 633, 669, 677 managing non-compliance 382 Managing reports Adding a custom logo 515 Changing graph types 511 Changing the output style 509 Displaying 509 Editing 508 Exporting 512 Graphs 511 Importing 513 printing 514 Saving 514 Viewing report history 513 managing reports 508 managing unknown systems 492 McAfee Desktop Firewal 355 MDist 2 592 Microsoft Active Directory 225 Microsoft Active Directory data 225 Microsoft Active Directory discovery 218 Microsoft Active Directory Server 219 Microsoft File and Print Sharing for Microsoft Networks 177 Microsoft Update Agent (WUA) 412 Microsoft updates 413 Microsoft Updates Discovery 415 configuring 413 initiating 415 Microsoft Updates Discovery 415
J
Java Execution Service 206 Java Virtual Machine (JVM) 323 JCF (Java Client Framework) 592 JES polling interval 207 job 267 job management service 268 job-processing subagents 325 JRIM (Java RDBMS Interface Module) 592
K
K Desktop Environment (KDE) 122
L
Large branch office 50 Large data center 48 last directory in the path 129 last Discovery Configuration Profile 203 last scan 203 LDAP tool 638
Index
847
modify 415 MS_SOA_DiscoverWindowsUpdates 416 Microsoft Windows Server Update Services 238 Microsoft Windows Server Update Services (WSUS) 411 Microsoft Active Directory discovery 36 MicrosoftWeb file repository 417 MIF files 662 migrated activity plans 676 Migrated reports 678 migrating the Tivoli environment 717 minimum password length 353 minimum password reuse count 353 minimum retention period of application data 354 minimum retention period of security data 354 minimum value of the maximum application log size 354 minimum value of the maximum security log size 354 minimum value of the maximum system log size 354 misconfigured antivirus 22 misconfigured firewall 22 mobile endpoints 606 monitoring Telnet requests 323 mount point 129 MS_SOA_DiscoverWindowsUpdates 415 MS_WUA_Scan.wkf 426 Multicast Management 674 multiple CASservice.zip files 341 multiple Rembo Boot Servers 476 multiple Tivoli Management Regions 595
Adding notification to software management tasks 523 Adding user notification for compliance checks 525 Adding user notification for discovery 523 Adding user notification for favorite tasks 525 Adding user notification for reports 524 Associating an e-mail address 522 Setting up the notification 522 tasks 521
O
OAMPi (Operations, Administration, Maintenance and Provisioning Infrastructure) 38 object wrapping 244 online Information center 547 Open Services Gateway Initiative (OSGi) 7, 321 Operating System reports 678 Oracle 622 OSGi bundles 321 OSGi platform 7 Other category 679 Out-of-the box network discovery 21 output streams 58
P
package.cab 416 package.xml 416 package-driven software installation 19 Patch management AIX CabExtract utility 417 cabextract.1.1.tar.Z 418 AIX 5.3 411 HP UNIX support 411 introduction 410 Microsoft updates 413 Microsoft Updates Discovery 415 Microsoft Updates Discovery configuration 413 parameters 413 Locale 413 Product 414 Product Family 414 Severity 414 parametersPatch Status 414 Microsoft Web site 413 Microsoft Windows 411 Microsoft Windows Server Update Services
N
Nahant Update 4 120 nameserver 86 NAT environments 272 netsvc.conf file 86 NetView Distribution Manager 456 Network Installation Manager (NIM) 461 network service 309 new Activity Planner engine 737 new geographical locations 587 new object ID 693 next replication 693 nLayers 21 no cloning 459 Notification
848
411 preparation 412 Red Hat Enterprise Linux 3 411 rednbook scenario 411 scalable software distribution infrastructure 411 scenarios 410 Solaris V10 411 typical steps 410 using Deployment Engine approving patches for installation 433 compliance reports 431 installing a WUA Agent 424 MS_WUA_Scan.wkf 426 perform creating a security compliance check 423 perform initial inventory 423 running a compliance check 428 viewing and approving recommendations 432 WUA scan discovery configuration 426 using Deployment Engine (DE) 421 using scalable software distribution infrastructure 435 architecture 435 high level steps 435 installing the missing patches 436 compliance verification process 446 creating a depot 438 creating a region 437 creating an SOA-SAP for endpoint operations 444 detailed steps 436 downloading patches 439 generating the compliance report 448 installing the Tivoli common agent 443 perform an initial inventory discovery 446 scan for missing patches 436 workflow execution log 441 Windows extrac32.exe 418 imported Windows patches 419 Microsoft Update Discovery 415 Microsoft Updates Discovery 413 MicrosoftWeb file repository 417 package.cab 416 package.xml 416 using Deployment Engine 421 wsusscan.cab 416 Windows XP patches 414
with Tivoli Provisioning Manager V5.1 411 workounds for workflows 449 wsusscan.cab 413 PC DMI Scanner 697 peer-to-peer 271 peer-to-peer file sharing configuring 273 enabling 272 Permission groups 530 Pervasive devices 673 Ping localhost 68 policy region 264, 636, 638, 647, 650, 667, 670671 policy region name 638 polling interval 331 PollingInterval parameter 207 populating depots 289 Preferred Upload Server 40 Pristine activity 736 Pristine Manager 456 profile 666 profile manager 668 property-value 202 Provisioning Blade Server 9 CPU 9 elements 4 hardware 9 Network Device 9 server 4 set of software and hardware resources 4 software package 4 software stack 4 Storage 9 Virtual Server 9 what it is? 4 Provisioning server 605 proxy relay 57 proxy relay collector 55 PurgeAgents 334 PXE (Pre-boot eXecution Environment) 457
Q
Query Facility 664
R
racking distribution 712 RAM memory reports 678
Index
849
RDBMS Interface Module (RIM) 615 Read Extended Attributes 355 read-only replica of the LDAP server 636 Redbooks Web site 840 Contact us xxxix Regions 264 registration service 310 registry 310, 661 Relicore 21 Rembo Agent 467 Rembo Auto-Deploy 456 Rembo Boot Server 456460, 462 Boot Server name 461 Boot Server type 461 selecting 461 installing 459 license key 494 re-activating the license key 494 Rembo Hardware Discovery 482 Rembo kernel 480, 482 Rembo Server 467 Rembo Server database 490 Rembo TCP to ODBC gateway 467 Rembo technology 10 Rembo Technology SaRL 456 remote building 607 Remote Deployment Manager (RDM) 461 remote depot 49 Remote Execution and Access (RXA) 323 remote federating agents 268 REMOVE_SPB_AFTER_PROCESS 252 REP_MANAGER table schema 654 rep_vendor.sql script 617 Repeater 670 replicate script 692 replicated endpoint 687 Reporting Predefined reports examples 516 reporting output formats 499 CSV 499 HTML 499 PDF 499 XML 499 ReportManager 698 Reports 498 actions 499 Copying reports 499 Creating new reports 499 Editing reports 499
Managing 508 Running reports 500 Adding report prompts 504 Copying 507 Creating 500 Creating a group 505 Exporting 512 Importing 512 Running 507 types 498 Audit 498 Compliance 498 Deployment 498 Discovery 498 Inventory 498 Other 498 Report views 498 repository 439 resolv.conf file 86, 131 resource 667 resource management 664 resource manager 307, 309310, 322 deploying subagents 322 firewalls 311 registry 310 resource pool 24 Restoring the images 481 customizing the image restoration 486 customizing the OS installation 487 finalizing 488 identifying the machine 483 preparing a Rembo Hardware Discovery Task 482 preparing the machine 482 selecting the image 484 selecting the targets 485 RetrieveAgents 334 RHEL3 461 RHEL4 461 rip and replace 20 role object 598 running reports 500 RXA (IBM Tivoli Remote Execution and Access) 73
S
Scalability 58 Scalable Distribution Infrastructure (SDI) for provisioning 38
850
Scalable File Distribution 325 scalable software distribution infrastructure 604605 Scanning subagents 325 scope 693 scriptlets 323 Secure Shell (SSH) 189 Secure Sockets Layer (SSL) 309 Security case study 532 Security compliance checks 348 serial number 490 Servers definition 25 Service Access Point (SAP) 25, 323 service broker 548 service level priority 24 Service Oriented Architecture (SOA) 4 IBM 4 life cycle 5 stages 5 Assemble 6 Deploy 6 Governance and processes 7 Manage 6 Model 6 Service Oriented Architecture for provisioning components 38 Device Management Service 38 Dynamic Content Delivery Service 38 Tivoli Common Agent Services 38 service provider 548 service requestor 548 service.sh script 341 servlet 309 setupaix.bin 89 signaturefile.xml 214 simple transactional installation 735 single-node topology 65 Small branch office 47 SMB (Server Message Block) 73 SMB discovered data 178 SMB discovery 462 SOA life cycle 5 SOA Service Access Point (SAP) 269 soahost 733 SOAP call 554 commands 548 message 548 overview 548
running logical operations 556 service broker 548 service provider 548 service requestor 548 using 549 SOAP (Simple Object Access Protocol) 547 soap_bash4win.sh 550 soapcli.cmd 550 soapcli.sh 550 software catalog 244 Software compliance checks 348 Software Definition 597 software definition 665 software distribution 19 Software Distribution profile 597, 665 Software groups 237, 254 software installable 667, 699 Software Installable files 238 Software Installation Engine (SIE) 250 Software Installation objects 244 Software Operator 641 software package 244, 677 parameters 252 FORCE 252 REMOVE_SPB_AFTER_PROCESS 252 software package block (SPB) 238, 666 importing 244 software package block file 244 Software Package Editor (SPE) 238, 244, 600, 619 configuring 240 finding 239 importing into a Software Product 243 installing 239 saving a Software Package Block 242 Save to local filesystem 243 Save to repository 243 supported platform 238 Software Package format 242 Software Package version checking 673 software product 25, 244 Software product requirement 250 Software Resource Template (SRT) 25 Software Signature File 203 software signature scan 203 software signatures 661 software stack 25, 237, 244, 256 Software views 255 software_simulator.tcdriver 573 SoftwareInstallable DCM object 26
Index
851
SoftwareInstallation 667 SoftwarePackage 633, 662663 SoftwarePackage object (SPO) 662 SoftwarePackage profiles 633 Solaris Jumpstart 21 source host 619, 633, 665, 669 SPB-processing subagents 325 specialized file repository 417 specify the scope 179 SSH (Secure Shell) 73 startServiceAndBrowser.cmd 569 subagent 42 Subagent bundles 324 Job-processing subagents 325 Scalable File Distribution 325 Scanning subagents 325 SPB-processing subagents 325 Tivoli Provisioning Manager core agent 324 subagents 309 successfull discovery 208 support for mobile endpoints 606 supported platforms 42 Supported tasks for notification Compliance checks 521 Discovery 521 Favorite tasks 521 Reports 521 Software management 521 sys database user 619 sys_password 619 sysdba 619
T
TARGET_LIST 736 task library 633, 648, 668 TC database 686 TC driver 24 tcdriver 24 tc-driver-manager.cmd. 570 tcm.xml file 626 TCM_ROOT group 634 tcmLink 628 tcmLink execution details 629 tcmLink_timestamp.log 628 tcmReplicate 631, 648649, 677 tcmreplicate 640 tcmReplicate execution details 633 TEC integration 672
The Dynamic Content Distribution Service 237 The Information Center 170 tioappadmin 632 tioStatus.cmd 581 Tivoli 10 Tivoli Application Dependency Discovery Manager (TADDM) 21 Tivoli common agent (TCA) 41, 261, 267268, 274, 308309, 321322, 325326, 604 authority needed to install 322 CASservice.zip file 342 certificates 321 collecting diagnostic information 341 Endpoint properties 329 features 321 functions 323 heartbeat function 321 installation return codes 331 installing 322 managed endpoint 321 polling interval 331 ports used 322 removing old agents 334 running the service command 341 runtime logs 340 security credentials 321 service access point 323 Service Access Point (SAP) 323 stack 333 starting 332 stoping 332 subagent bundles 323 troubleshooting 339 uninstalling 331, 333 updates 321 Tivoli common agent version 1.3 41 Tivoli Configuration Manager 456 Activity Planner operation mapping 735 clients 19 coexistence environment 596 coexistence with TPM environment 595 Interim Fixes 616 Inventory database 620 migration case studies 683 object 693 Pristine Manager 456 synchronize with Tivoli Provisioning Manager 693
852
unsupported actions 674 accept 674 commit with reboot options 674 install undoable 674 pause 674 remove transactional 674 remove undoable 674 resume 674 send, retrieve, delete 674 undo 674 unsupported scenarios 673 Tivoli Configuration Manager versus Tivoli Provisioning Manager for Software terminology hardware and group management 666 resource management 664 security 670 topology configuration 668 Tivoli Desktop 599, 615, 617, 619, 672 Tivoli Desktop for Windows 592 Tivoli endpoint 693 Tivoli License Manager integration 672 Tivoli Management Agent 605 Tivoli Management Framework 605, 628 Tivoli Management Framework Query Facility 615 Tivoli Management Region (TMR) 708 Tivoli object database 671 Tivoli object ID 705 Tivoli profile 648 Tivoli Provisioning family 8 Tivoli Provisioning family of products 8 comparison 10 IBM Tivoli Provisioning Manager Express Version 4.1 10 IBM Tivoli Provisioning Manager for Software Version 5.1 8 IBM Tivoli Provisioning Manager OEM Edition 10 IBM Tivoli Provisioning Manager Version 5.1 9 Tivoli Provisioning Manager for Operating System Deployment 456, 675 Tivoli Provisioning Manager for OS Deployment Embedded Edition 456 Tivoli Provisioning Manager for Software V5.1 910, 591, 610611, 613, 683, 699, 735 Activity Plan Editor (APE) 734 Activity Planner 734 activity plans 663 behind the scenes 646 Best practices 651
Coexistence databases architecture 647 Database link 648 Database replication 650 Database synchronization 646 Beta code 685 coexistence with TCM 598 database 613 discovery conversion to TCM Inventory 697 distributing software to a Tivoli endpoint 709 manage the Tivoli infrastructure 684 map to the Tivoli Management Framework 620 migrating the Tivoli environment 717 migration considerations 671 migration process 591 migration stages 593 completion of migration 604 moving to a coexistence environment 594 moving to a full Tivoli Provisioning Manager for Software implementation 601 working in a coexistence environment 598 new capabilities 587 Report Manager 652 Configuration 656 internals 652 REP_MANAGER table 654 Troubleshooting 656 ReportManager 698 running hardware discovery 693 scanning Tivoli endpoint 685 scenarios 684 security 635 Access group 636 Access permission group 636 configure 636 instance level 635 role-base level 635 Roles 636 Users 635 Software Distribution profile 665 terminology 664 Security 670 Tivoli Provisioning Manager network discovery 36 Tivoli Provisioning Manager V3.1 3 Tivoli Provisioning Manager V5.1 10, 3334, 4244, 52, 55, 5960, 6263, 121, 237, 327, 345346, 348, 408, 411, 456457, 498, 602, 611 Agent Manager 309 benefits 20 bridging functionality 612
Index
853
command-line interface 547 Compliance management 345 components 34 Automation Package Developer Environment 38 Deployment infrastructure 37 Deployment engine infrastructure 37 Scalable software distribution infrastructure 37 Discovery 36 IBM Discovery library reader 36 Inventory discovery 36 Microsoft Active Directory discovery 36 network discovery 36 IBM Open Process Automation Library 38 Operator and administrator console 37 Provisioning server 35 Automation 35 Compliance and remediation 35 Data center model 35 Provisioning database 35 Reporting 36 User directory 38 Web Services interface 37 concepts 24 Application 24 Application tier 24 Automation package 2425 Capability 25 Customer 24 data center model (DCM) 24 Logical operation 24 Requirement 25 Resource pool 24 Servers 25 Service Access Point 25 Software Configuration Template 25 Software product 25 software stack 25 Transition 24 Workflow 24 Deployment scenarios 44 Demo installation 44 Fast Start installation 44 firewalls 52 Large branch office 50 Large data center 48 Small branch office 47
Small data center 45 Discovery mechanism 176 environment used for coexistence 611 Image management 456 installing 62 Enterprise installation 65 Fast Start 63 hardware requirement 69 installation images 73 installing behind a firewall 71 new options 62 Silent installation 63 software requirements 70 Tivoli Provisioning Manager Topology installer 62 logical device operations 561 new features Compliance management 13 Discovery and inventory management 12 Groups 13 Image management 15 Notifications 14 Patch management 15 Reports 16 Security 16 Software distribution infrastructure 14 User experience 17 Web Services component 18 notification 521 online Information center 547 patch management 410 Peer-to-peer file sharing 271 Ports used 53 prerequisite software 43 reporting 498 resource manager 309 Scalability 58 SOAP interface 548 software management 237 components 237 Depot server 237 device management service 237 File repository 237 Regions 237 software catalog 237 Software Package Editor 237 The dynamic content distribution service 237 zones 237
854
depot server 237 device management service 237 file repository 237 region 237 software catalog 237 Software Package Editor 237 Supported platforms 42 Tivoli common agent 309 Topology Installer Launcher 62 User security 527 Web page 120 Web Services 18 what is new? 12 working accross firewalls 52 gateway manager and service 57 ports used 53 Proxy relay 57 Proxy relay collector 55 Tivoli queries 648 Tivoli Remote Control 605 Tivoli ReportManager 691 Tivoli tasks 633 TivoliAgentRecovery 311 TME Desktop Admin 664 TMF queries 665 TMF task 665 tmrname.xml 636 top level policy region 663, 694 top toolbar frame 170 topology configuration 668 Topology Installer Launcher 67 requirements 67 Expect 68 Ping localhost 68 X Window System connections 68 Topology Installer Launcher (TIL) 62 TPM_Region 663, 694 TpmLiteSoapService 557 Track traffic 356 transitions 24 Traverse Folder/Execute File 355 Troubleshooting Agent Manager 314 Tivoli common agent 339 two-node topology 66 typed group 650
U
umask 0002 85 umask command 85 Unattended installation on Linux 120 unauthorized guest access 353 Unidentified Software Components 209 unidirectional firewall rules 57 uninstall process 286 UNIX services 352 unqualified host name TivoliAgentRecovery 311 unsecured HTTP connection 310 untyped group 650 update the data center model 218 Upload Depot 40 USB devices 587 Use SSL 240 User interface consolidation 23 User notification 525 User roles 528 User security Access Permission group 530 case study 532 concepts 528 User authentication 528 User authorization 528 Access groups 529 Enable access control 531 Permission groups 530 roles 528 user-friendly interface 10
V
Verify operation 672 version info 716 VLAN 25
W
Wake-on-LAN 481, 673 Web Services 18 Web Services Definition Language (WSDL) 552 Web Services Resource Framework (WSRF) 18, 37 Web User Interface 603 Web-based distance learning 5 WebSphere Application Server 87 Windows 2003 Service Pack 1 412 Windows CE 673 Windows Native Firewall 355
Index
855
Windows screen saver 351 Windows services 356 Windows Tivoli Provisioning Manager server 270 Windows Update Agent (WUA) 424 Windows XP patches 414 Windows XP targets 177 wlookup -ar 614 Workflow Composer functions 398 Compile a workflow 398 Edit workflow text 398 Export the workflow 398 Open a workflow file 398 Run the workflow 398 Workflow Composer window 398 workflow definition 24 Workflow Editor window 398 Workflow Parameter Name 444 wpatch command 617 wrepmgrcfg command 698 Write Extended Attributes 355 wrpmgcfg 656 wsusscan.cab 413 wsusscan.log file 417 WsusscanToDcm.sh 417, 449 wsusscn.cab 415
X
X Window System 68 X.509 digital certificates 309 xlC.rte 6.0 run-time code 85 xmlimport 627 xmlimport.cmd 578 XYZ Corporation 295
Z
Zone Alarm Integrity Flex Firewall 355 Zones 266 creating 266
856
Deployment Guide Series: IBM Tivoli Provisioning Manager V5.1

(1.5 spine) 1.5<-> 1.998 789 <->1051 pages
(1.0 spine) 0.875<->1.498 460 <-> 788 pages
(0.5 spine) 0.475<->0.875 250 <-> 459 pages
(0.2spine) 0.17<->0.473 90<->249 pages
(0.1spine) 0.1<->0.169 53<->89 pages
Deployment Guide Series: IBM Tivoli Provisioning Manager
(2.5 spine) 2.5<->nnn.n 1315<-> nnnn pages
Deployment Guide Series: IBM Tivoli Provisioning Manager
(2.0 spine) 2.0 <-> 2.498 1052 <-> 1314 pages
Back cover

Learn best practices for planning, deploying and customizing TPM V5.1 All new features are explained with real life scenarios Also covers TPM for Software
This redbook is a deployment guide for both Tivoli Provisioning Manager Version 5.1 and Tivoli Provisioning Manager for Software Version 5.1. The new version of Tivoli Provisioning Manager comes in two packaging: Tivoli Provisioning Manager Version 5.1, which is the new version of Tivoli Provisioning Manager that includes also part of the services currently provided by Tivoli Management Framework plus most of the features formerly referred to as Tivoli Configuration Manager in the context of the Service Oriented Architecture (SOA) infrastructure. Tivoli Provisioning Manager for Software Version 5.1 which introduces coexistence with an existing Tivoli Management Framework installation and provides a natural progression path from Tivoli Configuration Manager 4.2.3. In this redbook we cover Tivoli Provisioning Manager in Part 1 and Tivoli Provisioning Manager for Software in Part 2. The target audience of the redbook is Tivoli Configuration Manager Version 4.2.X and Tivoli Provisioning Manager Version 3.1 specialists. If your background is on Tivoli Configuration Manager, you might want to skip Part 1 and start from Part 2, where we discuss Tivoli Provisioning Manager for Software, migration and co-existence considerations with an existing Tivoli Configuration Manager environment. To learn more about new capabilities of the Tivoli Provisioning Manager V5.1, we also suggest you read Part 1. If you are coming from the Tivoli Provisioning Manager Version 3.1 background, Part 2 of the book is probably not for you.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks
SG24-7261-00
ISBN

Deployment Guide Series IBM Tivoli Provisioning Manager Version 5.1 Sg247261

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Deployment Guide Series IBM Tivoli Provisioning Manager Version 5.1 Sg247261

Hochgeladen von

Copyright:

Verfügbare Formate

Front cover

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Copyright IBM Corp. 2006. All rights reserved.

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

6.3.1 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6 6.3.7 6.3.8

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Copyright IBM Corp. 2006. All rights reserved.

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

7-56 7-57 7-58 7-59 7-60 7-61 7-62

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

14-41 14-42 14-43 14-44 14-45 14-46 14-47 14-48 14-49

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Copyright IBM Corp. 2006. All rights reserved.

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Copyright IBM Corp. 2006. All rights reserved.

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

14-5 14-6 14-7 14-8 14-9

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Copyright IBM Corp. 2006. All rights reserved.

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

The team that wrote this redbook

Copyright IBM Corp. 2006. All rights reserved.

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Become a published author

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

IBM Tivoli Provisioning Manager V5.1

Copyright IBM Corp. 2006. All rights reserved.

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Tivoli Provisioning Manager V5.1 overview

Copyright IBM Corp. 2006. All rights reserved.

1.2 Service Oriented Architecture (SOA)

1.2.1 Why IBM SOA?

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Figure 1-1 The IBM SOA reference architecture

1.2.2 The SOA lifecycle

Chapter 1. Tivoli Provisioning Manager V5.1 overview

Figure 1-2 Service Oriented Architecture (SOA) lifecycle

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Governance and processes

1.3 Open Services Gateway Initiative (OSGi)

1.4 IBM Service Management Framework (SMF)

Chapter 1. Tivoli Provisioning Manager V5.1 overview

1.5 Tivoli Provisioning family of products

1.5.1 IBM Tivoli Provisioning Manager for Software Version 5.1

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

1.5.2 IBM Tivoli Provisioning Manager Version 5.1

Chapter 1. Tivoli Provisioning Manager V5.1 overview

1.5.3 IBM Tivoli Provisioning Manager Express Version 4.1

1.5.4 IBM Tivoli Provisioning Manager OEM Edition

1.5.5 IBM Tivoli Provisoning Manager for OS deployment Version 5.1

Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1

Chapter 1. Tivoli Provisioning Manager V5.1 overview

a. IBM Tivoli Service Management

1.6 Tivoli Provisioning Manager V5.1 new features

1.6.1 Discovery and inventory management