Certification Guide Series IBM Tivoli Provisioning Manager V5.1 Sg247262

Front cover
Certification Guide Series

IBM Tivoli Provisioning Manager V5.1
Helps you become a certified Tivoli Provisioning Manager V5.1 Explains the certification path and prerequisites you require Includes best practices for Software Distribution
Vasfi Gucer David Campbell Martin Caesar Markus Helbig Fabrizio Salustri Petra Unglaub
ibm.com/redbooks
International Technical Support Organization Certification Guide Series: IBM Tivoli Provisioning Manager V5.1 January 2007
SG24-7262-00
Note: Before using this information and the product it supports, read the information in Notices on page xv.
First Edition (January 2007) This edition applies to IBM Tivoli Provisioning Manager V5.1.
Copyright International Business Machines Corporation 2007. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Chapter 1. Certification overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 IBM Professional Certification Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1 Benefits of certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2 Tivoli Software Professional Certification . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Tivoli Provisioning Manager V5.1 Implementation certification . . . . . . . . . . 7 1.2.1 Test 898 objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2.2 How to get your 15% discount on the Tivoli Provisioning Manager V5.1 certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3 Recommended resources for study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.1 Courses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.2 Publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Chapter 2. Planning and architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Tivoli Provisioning Manager V5.1 components . . . . . . . . . . . . . . . . . . . . . 12 2.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.1 Scalable Distribution Infrastructure for Tivoli Provisioning Manager v.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 Supported Platforms for Tivoli Provisioning Manager version 5.1. . . . . . . 21 2.4 Infrastructure deployment considerations . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4.1 Demo installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.4.2 Small Data Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.4.3 Small branch office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4.4 Large data center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4.5 Large branch office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4.6 System management across firewalls. . . . . . . . . . . . . . . . . . . . . . . . 25
Copyright IBM Corp. 2007. All rights reserved.
iii
2.4.7 Ports used by Scalable Distribution Infrastructure components . . . . 26 Chapter 3. Installing Tivoli Provisioning Manager V5.1 . . . . . . . . . . . . . . . 29 3.1 Installation methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.1 Regular installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.2 Silent installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.3 Fast Start installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2 Topology Installer Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3 Supported installation topologies and operating system versions. . . . . . . 31 3.3.1 AIX and Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.2 Solaris (Sun SPARC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.3.3 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4 Account required by the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.5 Preinstallation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.5.1 Topology Installer Launcher requirements . . . . . . . . . . . . . . . . . . . . 39 3.5.2 Tivoli Provisioning Manager server requirements . . . . . . . . . . . . . . . 40 3.5.3 Additional software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.5.4 Prerequisite software versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.6 Installing behind a firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.7 Overview of the installation flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.7.1 Invoking the installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.7.2 Installation phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.8 Installation log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.8.1 Installer logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.8.2 Tivoli common directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.8.3 Directory containing output from the installation . . . . . . . . . . . . . . . . 47 3.9 Post installation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.9.1 Changing default passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.9.2 Importing sample data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.10 Automation Package Developer Environment (APDE) installation . . . . . 50 3.10.1 Automation Package Developer Environment installation requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.10.2 Installing the Automation Package Developer Environment . . . . . . 52 3.10.3 Configuring database connectivity . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.10.4 Configuring deployment engine connectivity. . . . . . . . . . . . . . . . . . 58 3.10.5 Starting the Automation Package Developer Environment . . . . . . . 59 3.10.6 Configuring Automation Package Developer Environment preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.10.7 Automation Package Developer Environment views . . . . . . . . . . . 61 Chapter 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1 Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.1.1 Discovery scan types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
iv
Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
4.1.2 Tivoli Provisioning Manager Inventory Discovery . . . . . . . . . . . . . . . 65 4.1.3 Network discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.1.4 IBM discovery library reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.1.5 Microsoft Active Directory discovery . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.1.6 Run a discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.2 Service access points (SAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.3 Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.4 Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.4.1 Creating a static group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.4.2 Creating a dynamic group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5.1 Creating a customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.5.2 Creating a resource pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.5.3 Creating an administrative domain . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.5.4 Creating a cluster domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.6 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.7 Automation packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.7.1 Install an automation package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.7.2 Updating an automation package . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.7.3 Creating an automation package . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.7.4 Creating a workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.8 Software Package Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Chapter 5. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.1 Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.1.1 Recording the symptoms of the problem . . . . . . . . . . . . . . . . . . . . . 90 5.1.2 Recreating the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.1.3 Eliminating possible causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2 Directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.3 Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.3.1 Log file types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.3.2 Subsystem messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.3.3 Setting log level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.4 Workflow troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.1 Setting log level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.2 Workflow execution logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.5 Agent installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.5.1 Time drift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.5.2 RXA problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.5.3 Service access point (SAP) problems . . . . . . . . . . . . . . . . . . . . . . . 106 5.5.4 Communication issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 5.6 Depot issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.7 Performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Contents
5.7.1 Configuring maximum number of concurrent jobs . . . . . . . . . . . . . 112 5.7.2 Workflow performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.7.3 Software Package Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Chapter 6. Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.1 Accessing the console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.2 Managing security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.2.1 Creating a security role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.2.2 Creating an access group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.2.3 Creating a permission group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.2.4 Associate objects to an access group . . . . . . . . . . . . . . . . . . . . . . . 122 6.2.5 Adding a new user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 6.2.6 Assigning a security role to a user . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.2.7 Associating access and permission groups to a user . . . . . . . . . . . 126 6.2.8 Enabling access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 6.3 Network discovery and agent distribution . . . . . . . . . . . . . . . . . . . . . . . . 127 6.3.1 Preparing network discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6.3.2 Discovery policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6.3.3 Performing the discovery task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.3.4 Installing Tivoli Common Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.4 Software Package Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 6.4.1 Using the Software Package Editor . . . . . . . . . . . . . . . . . . . . . . . . 134 6.4.2 Saving a software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 6.5 Compliance management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.5.1 Adding software compliance check . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.5.2 Adding security compliance check . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.5.3 Running inventory scan and compliance check . . . . . . . . . . . . . . . 140 6.5.4 Handle recommendation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 6.5.5 Verifying changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 6.6 Software Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 6.6.1 Software stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 6.6.2 Software Catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 6.7 Virtual servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 6.7.1 Installing tcdriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 6.7.2 Creating host platform server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 6.7.3 Adding resource to host platform server . . . . . . . . . . . . . . . . . . . . . 148 6.7.4 Creating virtual server template . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 6.7.5 Adding resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 6.7.6 Allocating the virtual server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 6.8 Imaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 6.8.1 Installing a boot server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 6.8.2 Capturing an image with Rembo Boot Server . . . . . . . . . . . . . . . . . 156 6.8.3 Deploying an image with Rembo Boot Server . . . . . . . . . . . . . . . . 160
vi
6.9 Software distribution and installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 6.9.1 Software distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 6.9.2 Software installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 6.9.3 Requirements on target endpoints . . . . . . . . . . . . . . . . . . . . . . . . . 163 6.9.4 User role for software distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 163 6.10 Web services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 6.10.1 Extensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 6.10.2 Simple Object Access Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 6.10.3 Web services description language . . . . . . . . . . . . . . . . . . . . . . . 165 6.10.4 Web Services Resource Framework. . . . . . . . . . . . . . . . . . . . . . . 166 6.11 Using Automation Package Development Environment . . . . . . . . . . . . 167 6.11.1 Creating automation packages . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 6.11.2 Creating new workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 6.11.3 Working with Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 6.11.4 Modify existing automation packages . . . . . . . . . . . . . . . . . . . . . . 170 6.11.5 Workflow syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 6.11.6 Exporting created or modified workflows . . . . . . . . . . . . . . . . . . . 173 Chapter 7. Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 7.1 The Data Center Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 7.1.1 What is Data Center Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 7.1.2 Data Center Model objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 7.1.3 Customer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 7.1.4 Application tier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 7.1.5 Resource pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 7.1.6 Management operations and Logical Device Operations . . . . . . . . 177 7.1.7 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 7.1.8 Device drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 7.2 Scalable Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 7.2.1 File repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 7.2.2 Software Catalog, Software Products and Software Installables . . 179 7.2.3 Software stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 7.2.4 The dynamic content delivery service . . . . . . . . . . . . . . . . . . . . . . . 180 7.2.5 The dynamic content delivery service Management Center . . . . . . 181 7.2.6 Depot server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 7.2.7 Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 7.2.8 Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 7.2.9 Device Management Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 7.2.10 Peer-to-peer file sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 7.2.11 Publishing to depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 7.2.12 Inside the distribution process. . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 7.3 Tivoli Common Agent Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 7.3.1 Agent Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Contents
vii
7.3.2 Resource manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 7.3.3 Tivoli Common Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 7.4 Software Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 7.5 Security model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 7.5.1 User authentication and accounts. . . . . . . . . . . . . . . . . . . . . . . . . . 190 7.5.2 User authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 7.5.3 User roles and accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 7.5.4 Access groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 7.5.5 Permission groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 7.5.6 Access Permission group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Chapter 8. Sample questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 8.1 Sample questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 8.2 Answer Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
viii
Figures
2-1 2-2 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 4-1 4-2 4-3 4-4 4-5 4-6 Tivoli Provisioning Manager architecture . . . . . . . . . . . . . . . . . . . . . . . . . 12 Tivoli Provisioning Manager Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 One-node AIX topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Solaris 9 one-node topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Solaris 9 or Solaris 10 two-node topology. . . . . . . . . . . . . . . . . . . . . . . . . 35 Windows one-node topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Windows two-node topology with Microsoft Active Directory . . . . . . . . . . 37 Windows two-node topology with Tivoli Directory Server . . . . . . . . . . . . . 38 APDE architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Automation Package view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Add service access point dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Add credentials to service access point . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Service access point (SAP) configured for common agent . . . . . . . . . . . . 72 Add static group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Add dynamic group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Web interface in Tivoli Provisioning Manager and Tivoli Provisioning Manager for Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4-7 Open Software Package Editor in Eclipse . . . . . . . . . . . . . . . . . . . . . . . . 85 4-8 Software Package Editor settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4-9 Select file repository for software package block . . . . . . . . . . . . . . . . . . . 87 5-1 Stop workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5-2 Workflow log details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5-3 Workflow log timedrift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5-4 Disable simple file sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5-5 SAP definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5-6 Tivoli common agent install credentials . . . . . . . . . . . . . . . . . . . . . . . . . 108 5-7 RXA credentials for UNIX Tivoli common agent installation . . . . . . . . . . 109 6-1 Digital certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6-2 Login screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6-3 Add a new security role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6-4 Add new access group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6-5 Add new permission group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 6-6 New user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6-7 Assign user roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 6-8 Discovery policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 6-9 Software Package Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 6-10 Check Disk Space Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 6-11 Example software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
ix
6-12 6-13 6-14 6-15
Add external software catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Add Boot Server Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Starting the Rembo Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Rembo Toolkit renamed to Tivoli Provisioning Manager for OS Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 6-16 Image capture on source computer . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 6-17 Workflow related components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 6-18 Import workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 7-1 Distribution process: high level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 7-2 Managed system life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Tables
2-1 Supported platforms for Tivoli Provisioning Manager V5.1 and Tivoli common agent V1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2-2 Ports used by Scalable Distribution Infrastructure components . . . . . . . . 26 3-1 Supported topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3-2 Hardware and software requirements for the Topology Installer . . . . . . . 39 3-3 Prerequisite software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3-4 Communication port used by Tivoli Provisioning Manager . . . . . . . . . . . . 42 3-5 Default user names and passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4-1 Available report views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5-1 Tivoli Provisioning Manager directory structure . . . . . . . . . . . . . . . . . . . . 92 5-2 Logfile locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5-3 Subsystem codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5-4 Tivoli common agent port requirements . . . . . . . . . . . . . . . . . . . . . . . . . 109 6-1 Rembo product integrated into IBM Tivoli software . . . . . . . . . . . . . . . . 153
xi
xii
Examples
3-1 3-2 3-3 3-4 4-1 4-2 4-3 5-1 5-2 5-3 5-4 5-5 6-1 Installation log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Registering the node and the database . . . . . . . . . . . . . . . . . . . . . . . . . . 54 .jar file location update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 .jar file location update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Command listing automation packages . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Workflow deletes target deviceID from data center model . . . . . . . . . . . . 85 Import server certificate to java keystore . . . . . . . . . . . . . . . . . . . . . . . . . 87 log4j.prop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 TImedrift error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Failing RXA access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Missing SAP definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 eclipse.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 soapclient.cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
xiii
xiv
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.
xv
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Redbooks (logo) ibm.com pSeries xSeries zSeries AIX 5L AIX Cloudscape DB2 Universal Database DB2 IBM Library Reader PowerPC Redbooks Tivoli WebSphere
The following terms are trademarks of other companies: Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries. and Oracle are registered trademarks of Oracle Corporation and/or its affiliates. Snapshot, and the Network Appliance logo are trademarks or registered trademarks of Network Appliance, Inc. in the U.S. and other countries. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. Java, JDBC, JRE, JVM, J2EE, Solaris, Sun, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Active Directory, Excel, Internet Explorer, Microsoft, Windows Server, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. i386, Intel, Pentium, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.
xvi
Preface
IBM Tivoli Provisioning Manager, built on a service-oriented architecture (SOA), enhances usability for executing changes while keeping server and desktop software compliant. Tivoli Provisioning Manager helps organizations with provisioning, configuration and maintenance of servers and virtual servers, operating systems, middleware, applications, storage and network devices acting as routers, switches, firewalls, and load balancers. This IBM Redbook is a study guide for IBM Tivoli Provisioning Manager V5.1 and is aimed at the people who want to get an IBM Professional Certification for this product. The IBM Tivoli Provisioning Manager V5.1 Certification, offered through the Professional Certification Program from IBM, is designed to validate the skills required of technical professionals who work in the implementation of the IBM Tivoli Provisioning Manager V5.1 product. This book provides a combination of theory and practical experience needed for a general understanding of the subject matter. It also provides sample questions that will help in the evaluation of personal progress and provide familiarity with the types of questions that will be encountered in the exam. This publication does not replace practical experience, nor is it designed to be a stand-alone guide for any subject. Instead, it is an effective tool that, when combined with education activities and experience, can be a very useful preparation guide for the exam. For your convenience, we structure the chapters based on the sections of the Tivoli Provisioning Manager V5.1 Implementation Certification test, such as Planning, Installation, Administration, and so on, so studying each chapter will help you prepare for one section of the exam.
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, Poughkeepsie 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 platform software. He actively presents at various Tivoli Technical User
xvii
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. 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 specializes in Tivoli Configuration Manager. He has worked with many UK and international customers including several of the UK's largest financial institutions. Martin Caesar is an IT Specialist working for IBM Software Group Services for Tivoli in Germany. He has worked with Tivoli products since 1999. He has designed and implemented solutions in several projects based on the Tivoli Configuration Manager product. The experience he has includes installing and configuring the product for specific situations and requirements. He has an IBM Certified Deployment Professional certification and is ITIL Certified. He holds a diploma in Physics from the Technical University Berlin. Markus Helbig is an IBM Tivoli software support specialist since 1999. His skills include IBM Tivoli Management Framework V 3.x & 4.x, IBM Tivoli Monitoring V 5.x, 6.x, as well as Tivoli Configuration Manager 4.x. Fabrizio Salustri is a software support specialist working for Italy IMT in Tivoli Customer Support within IBM Global Services. He has worked for IBM since 1996, and has extensive experience with the 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 an IBM Tivoli Monitoring 6.1 Deployment Professional Certification in April 2006. Petra Unglaub-Lloyd is a Level 2 Software Engineer in Austin, Texas. She has 10 years of experience in the Tivoli Support field. She holds a degree from Hardin-Simmons University and the University of Bayreuth, Germany. Her areas of expertise include Level 2 defect support for IBM Tivoli Framework and IBM Tivoli Configuration Manager. Thanks to the following people for their contributions to this project: Arzu Gucer, Sarita Povaiah International Technical Support Organization, Poughkeepsie Center Kristin Wall Gibson, Elizabeth Purzer IBM US
xviii
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
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
xix
xx
Chapter 1.
Certification overview
This chapter provides an overview of the skill requirements to obtain an IBM Advanced Technical Expert certification. We designed the following sections to provide a comprehensive review of specific topics that are essential for obtaining the certification: IBM Professional Certification Program on page 2 Tivoli Provisioning Manager V5.1 Implementation certification on page 7 Recommended resources for study on page 8
1.1 IBM Professional Certification Program

Having the right skills for the job is critical in the growing global marketplace. IBM Professional Certification, designed to validate skill and proficiency in the latest IBM solution and product technology, can help provide that competitive edge. The IBM Professional Certification Program is available on the Web at:
http://www.ibm.com/certify/index.shtml
The Professional Certification Program from IBM offers a business solution for skilled technical professionals seeking to demonstrate their expertise to the world. This program is designed to validate your skills and demonstrate your proficiency in the latest IBM technology and solutions. In addition, professional certification will help you excel at your job by giving you and your employer the confidence that your skills have been tested. You will be able to deliver higher levels of service and technical expertise than non-certified employees and move on a faster career track. Professional certification puts your career in your control. The certification requirements are difficult, however, they are not overwhelming either. It is a rigorous process that differentiates you from everyone else. The mission of IBM Professional Certification is to: Provide a reliable, valid, and fair method of assessing skills and knowledge. Provide IBM with a method of building and validating the skills of individuals and organizations. Develop a loyal community of highly-skilled certified professionals who recommend, sell, service, support, and use IBM products and solutions. The Professional Certification Program from IBM has developed certification role names to guide you in your professional development. The certification role names include IBM Certified Specialist, IBM Certified Solutions/Systems Expert, and IBM Certified Advanced Technical Expert for technical professionals who sell, service, and support IBM solutions. For technical professionals in application development, the certification roles include IBM Certified Developer Associate and IBM Certified Developer. An IBM Certified Instructor certifies the professional instructor. The Professional Certification Program from IBM provides you with a structured program leading to an internationally recognized qualification. The program is designed for flexibility by allowing you to select your role, prepare for and take tests at your own pace, and, in some cases, select from a choice of elective tests best suited to your abilities and needs. Some roles also offer a shortcut by giving credit for a certification obtained in other industry certification programs.
You can be a network administrator, systems integrator, network integrator, solution architect, solution developer, value-added reseller, technical coordinator, sales representative, or educational trainer. Regardless of your role, you can start charting your course through the Professional Certification Program from IBM today.
1.1.1 Benefits of certification

Certification is a tool to help objectively measure the performance of a professional on a given job at a defined skill level. Therefore, it is beneficial for individuals who want to validate their own skills and performance levels, their employees, or both. For optimum benefit, the certification tests must reflect the critical tasks required for a job, the skill levels of each task, and the frequency by which a task needs to be performed. IBM prides itself in designing comprehensive, documented processes that ensure that IBM certification tests remain relevant to the work environment of potential certification candidates. In addition to assessing job skills and performance levels, professional certification can also provide such benefits as: For employees: Promotes recognition as an IBM certified professional Helps to create advantages in interviews Assists in salary increases, corporate advancement, or both Increases self-esteem Provides continuing professional benefits Measures the effectiveness of training Reduces course redundancy and unnecessary expenses Provides objective benchmarks for validating skills Makes long-range planning easier Helps to manage professional development Aids as a hiring tool Contributes to competitive advantage Increases productivity Increases morale and loyalty Provides independent validation of technical skills Creates competitive advantage and business opportunities Enhances prestige of the team Contributes to IBM requirements for various IBM Business Partner programs
For employers:
For IBM Business Partners and consultants:
Chapter 1. Certification overview
Specific benefits can vary by country (region) and role. In general, after you become certified, you should receive the following benefits: Industry recognition Certification may accelerate your career potential by validating your professional competency and increasing your ability to provide solid, capable technical support. Program credentials As a certified professional, you receive your certificate of completion and the certification mark associated with your role for use in advertisements and business literature through e-mail. You can also request a hardcopy certificate, which includes a wallet-size certificate. The Professional Certification Program from IBM acknowledges the individual as a technical professional. The certification mark is for the exclusive use of the certified individual. Ongoing technical vitality IBM Certified professionals are included in mailings from the Professional Certification Program from IBM.
1.1.2 Tivoli Software Professional Certification

The IBM Tivoli Professional Certification program offers certification testing that sets the standard for qualified product consultants, administrators, architects, and partners. The program also offers an internationally recognized qualification for technical professionals seeking to apply their expertise in today's complex business environment. The program is designed for those who implement, buy, sell, service, and support IBM Tivoli solutions and want to deliver higher levels of service and technical expertise. Whether you are a Tivoli customer, partner, or technical professional wanting to put your career on the fast track, you can start on the road to becoming a Tivoli Certified Professional today.
Benefits of Tivoli certification

Tivoli certification provides the following benefits: For the individual: IBM Certified certificate and use of logos on business cards
Note: Certificates are sent by e-mail. However, a paper copy of the certificate along with a laminated wallet card can also be requested by sending an e-mail to the following address: mailto:certify@us.ibm.com Recognition of your technical skills by your peers and management Enhanced career opportunities Focus for your professional development For the IBM Business Partner: Confidence in the skills of your employees Enhanced partnership benefits from the IBM Business Partner program Billing your employees out at higher rates Strengthens your proposals to customers Demonstrates the depth of technical skills available to prospective customers For the customer: Confidence in the services professionals handling your implementation Ease of hiring competent employees to manage your Tivoli environment Enhanced return on investment (ROI) through more thorough integration with Tivoli and third-party products Ease of selecting a Tivoli Business Partner that meets your specific needs
Certification checklist
Here is the certification checklist: 1. Select the certification that you want to pursue. 2. Determine which test or tests are required by reading the certification role description. 3. Prepare for the test, using the following resources provided: Test objectives Recommended educational resources Sample/assessment test Other reference materials Opportunities for experience
Note: These resources are available from each certification description page, as well as from the Test information page. 4. Register to take a test by contacting one of our worldwide testing vendors: Thomson Prometric Pearson Virtual University Enterprises (VUE) Note: When providing your name and address to the testing vendor, be sure to specify your name exactly as you want it to appear on your certificate. 5. Take the test. Be sure to keep the Examination Score Report provided upon test completion as your record of taking the test. Note: After taking a test, your test results and demographic data (including name, address, e-mail, and phone number) are sent from the testing vendor to IBM for processing (allow two to three days for transmittal and processing). After all the tests required for a certification are passed and received by IBM, your certificate will be issued. 6. Repeat steps 3 through 5 until all the required tests are successfully completed for the desired certification role. If additional requirements are needed (such as an other vendor certification or exam), follow the instructions on the certification description page to submit these requirements to IBM. 7. After you complete your certification requirements, you will be sent an e-mail asking you to accept the terms of the IBM Certification Agreement before receiving the certificate. 8. Upon acceptance of the terms of the IBM Certification Agreement, an e-mail will be sent containing the following electronic deliverables: A Certification Certificate in PDF format, which can be printed in either color or black and white A set of graphic files of the IBM Professional Certification mark associated with the certification achieved Guidelines for the use of the IBM Professional Certification mark 9. To avoid unnecessary delay in receiving your certificate, ensure that we have your current e-mail on file by keeping your profile up-to-date. If you do not have an e-mail address on file, your certificate will be sent through postal mail.
After you receive a certificate by e-mail, you can also contact IBM to request that a hardcopy certificate be sent by postal mail by contacting: mailto:certify@us.ibm.com Note: IBM reserves the right to change or delete any portion of the program, including the terms and conditions of the IBM Certification Agreement, at any time without notice. Some certification roles offered through the IBM Professional Certification Program require recertification.
1.2 Tivoli Provisioning Manager V5.1 Implementation certification

We can categorize the certification process as follows: Job role description/target audience: A Tivoli Certified Consultant Tivoli Provisioning Manager V5.1 is a technical professional responsible for planning, installation, configuration, operations, administration, and maintenance of an Tivoli Provisioning Manager V5.1 solution. This individual will be expected to perform these tasks with limited assistance from peers, product documentation, and support resources. To attain the IBM Certified Deployment Professional - Tivoli Provisioning Manager V5.1 Implementation certification, candidates must pass one test. Required prerequisites: Strong working knowledge of Tivoli Provisioning Manager V5.1 infrastructure components Working knowledge of operating system and networking and firewall concepts Basic knowledge of supported databases Basic knowledge of protocols, including HTTP Core requirement: In order to be certified, you must select Test 898 - Tivoli Provisioning Manager V5.1 Implementation: Test 898 objectives Test 898 sample test Test 898 recommended educational resources Number of questions: 84
Duration in minutes: 105 Format: Multiple choice Required passing score: 55%
1.2.1 Test 898 objectives

For the most updated objectives of the Tivoli Provisioning Manager V5.1Implementation certification test, go to the Tivoli Certification Web site and select the Tivoli Provisioning Manager V5.1 Implementation certification test link:
http://www-03.ibm.com/certify/tests/obj898.shtml
1.2.2 How to get your 15% discount on the Tivoli Provisioning Manager V5.1 certification
You can receive a 15% discount on the Tivoli Provisioning Manager V5.1 certification, if taken at any Thomson Prometric testing center. Just remember to use the code 15T898.
1.3 Recommended resources for study

Courses and publications are offered to help you prepare for the certification tests. The courses are recommended, but not required, before taking a certification test. If you want to purchase Web-based training courses or are unable to locate a Web-based course or classroom course at the time and location you desire, contact one of our delivery management teams at: Americas: mailto:tivamedu@us.ibm.com EMEA: mailto:tived@uk.ibm.com AP: mailto:tivtrainingap@au1.ibm.com Note: Course offerings are continuously being added and updated. If you do not see the courses listed in your geography, contact the delivery management team.
1.3.1 Courses
Course names and course numbers vary depending on the education delivery arm used in each geography. Refer to the Tivoli software education Web site to find the appropriate course and education delivery vendor for each geography. General training information is also available at IBM IT Training at:
http://ibm.com/training
1.3.2 Publications
Before taking the test 898, Tivoli Provisioning Manager V5.1 Implementation, we recommend that you review Tivoli Provisioning Manager V5.1 guides and IBM Redbooks. For the online publications of Tivoli Provisioning Manager V5.1, refer to the following link:
http://publib.boulder.ibm.com/infocenter/tivihelp/v13r1/index.jsp
IBM Tivoli Provisioning Manager V5.1 redbooks

You can refer to Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1, SG24-7261. This book focuses on the planning and deployment of Tivoli Provisioning Manager V5.1 in production environments. The target audience for this book is IT specialists who will be working on new Tivoli Provisioning Manager V5.1 installations.
10
Chapter 2.
Planning and architecture

This chapter provides information about successfully planning a proper architecture for Tivoli Provisioning Manager version 5.1. It will summarize how components interact. In this chapter, the following topics are discussed. We will explore different scenarios based on the number of agents, network restrictions, hardware availability and supported operating systems. It will furthermore provide advise about the configuration that is to be chosen, depending on the size of the environment to be managed. This chapter includes the following sections: Tivoli Provisioning Manager V5.1 components on page 12 Scalability on page 15 Supported Platforms for Tivoli Provisioning Manager version 5.1 on page 21 Infrastructure deployment considerations on page 22
11
2.1 Tivoli Provisioning Manager V5.1 components

Figure 2-1 shows the architecture of a Tivoli Provisioning Manager.
Figure 2-1 Tivoli Provisioning Manager architecture
If Tivoli Provisioning Manager is configured properly, it automates complex provisioning tasks across servers, applications, networks and storage to reduce IT workload. It reduces human error and increases resource utilization.
12
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 the physical and logical assets that the Tivoli Provisioning Manager manages. 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. Automation An automation package is a collection of workflows, scripts, 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. Compliance and remediation Compliance management allows you to examine the software and security setup on a target computer in your managed infrastructure. If the desired configuration does not match, noncompliance occurs and recommendations on how to fix it are generated. 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.
Chapter 2. Planning and architecture
13
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 Tivoli Provisioning Manager Network discovery Tivoli Provisioning Manager Inventory discovery IBM Discovery library reader
Deployment infrastructure Tivoli Provisioning Manager supports reconfiguring and reallocation of resources in your managed environment using two different deployment infrastructures: 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 includes branch office management. Deployment engine infrastructure The deployment engine infrastructure is responsible for automated provisioning. Web Services allow you to access the Tivoli Provisioning Manager data center model directly rather than launching the Web interface. By using the Web Services, you can access, manipulate, or change objects directly in the data center model. Note: The computer you are using to access the Web interface must be on the same network as the provisioning server. You must use Microsoft Internet Explorer 6.0.29 or later or Firefox 1.5 or later. 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.
14
Operator and administrator console The Web-based operator and administrator console allows you to interact with the Tivoli Provisioning Manager 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. 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.2 Scalability
A distributed networking infrastructure inherits scalable characteristics by design. 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 Delivery Service component has been, in fact, proven to be able to manage large infrastructure with optimal performance. The following features of Dynamic
15
Content Delivery Service component contributes efficiently to scalability and reliability of Tivoli Provisioning Manager V5.1 in the following ways: 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. 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 mobile computer 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, the distribution will be completed, but Tivoli common agent 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 an adaptive bandwidth control that works. This reduces performance problems related to network overload. Dynamic Content Delivery Service supports checkpoint or restarts 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 download 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 therefore plays a key role. Device Management Service components also has some configurable parameters that might impact the performance. For example, the polling mechanism for new jobs between agents and Tivoli Provisioning Manager has a
16
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, 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 a Tivoli Provisioning Manager implementation, consider the following factors Number of physical systems and platform types to be managed Location of targets and available bandwidth 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
2.2.1 Scalable Distribution Infrastructure for Tivoli Provisioning Manager v.5.1

The Scalable 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 a large number of targets through intermediate depot components and 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. Each of them can perform its management activity through specific subcomponents installed on the Tivoli Provisioning Manager server and on the managed systems.
17
Device Management Service Federator

A device manager federator is installed on the provisioning server at the enterprise and is configured to act as a federated server. The federator implements a job distribution policy that pushes incoming jobs to all of the regional branch office agents. Note: 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. 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 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. 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 a subagent of the Tivoli Common Agent and communicates with federating agents, polling for new jobs, with a default value of 60 minutes. They are 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 files stored on each depot server and replicates files between depots. It also authorizes clients to download files and creates download plans.
18
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. Note: 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 Management 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.
19
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 sources for these files during downloads by their neighbors. Dynamic content delivery 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 delivery 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.
Figure 2-2 Tivoli Provisioning Manager Server
20
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 certificates, registration, tracking of common agents, resource managers, status collection and forwarding.
Tivoli common agent

Tivoli common agent installed on depot servers and on target systems, is a common container for all the subagents. It provides shared system resources and secure connectivity. Tivoli common agent subagents actually allow to use it as an agent for several Tivoli products.
2.3 Supported Platforms for Tivoli Provisioning Manager version 5.1

The Table 2-1 shows the supported platforms for Tivoli Provisioning Manager V5.1 and Tivoli common agent V1.3.
Table 2-1 Supported platforms for Tivoli Provisioning Manager V5.1 and Tivoli common agent V1.3 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
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
21
Operating Systems Linux Intel Family
Tivoli Provisioning Manager server 5.1 RHEL 4.0 32 bit update 3 SLES 9.0 32 bit SP3
Tivoli Common Agent 1.3 RHEL 3.0 32 bit RHEL 4.0 32 bit SLES 8.0 32 bit SLES 9.0 32 bit 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 AMD64/EM64T Linux i/p Series Family (64-bit)
Linux zSeries
Note: Since depot is implemented as a subagent, it is supported on the same platforms as Tivoli common agent.
2.4 Infrastructure deployment considerations

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. 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
22
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 acting as the application server, an embedded database server (Cloudscape) and utilizes OS-based authentication. Small footprint, about 1 GB of memory and 5 GB of diskspace is required. Note: Lightweight Infrastructure 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.
2.4.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 be used as an upload depot. To minimize the number of involved systems, this second machine can act both as depot and as target. This should allow to demonstrate main SOA infrastructure capabilities using only two systems. The Light Stack Tivoli Provisioning Manager should only be used for Test and Proof of Concept (POC) environments. It is not recommended to run production environments on the Light Stack Tivoli Provisioning Manager.
2.4.2 Small Data Center

A small data center scenario consist of a single local area network (LAN) hosting a limited number of servers to be managed. 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
23
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
2.4.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 on the specific characteristics of the company, you may have a standard branch office environment with dozens of desktops, or a 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. 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 systems. A peer-to-peer configuration 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. Note: Using the central depot server, and then taking advantage of peer-to-peer sharing is the main advantage of this configuration, thus having a single machine performing the download of large files across a slow link.
2.4.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. In this scenario, we suggest the installation of a Tivoli Provisioning Manager depot in the central management LAN. Depending on the number of systems to be managed in this local network, you can take into consideration a direct
24
connection between local servers and the upload depot, or a local depot hierarchy. Remote systems connected across 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 can be explored depending on the specific environment to be managed. Note: Consideration of the customers network topology can aid in properly placing the depot servers.
2.4.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 Small branch office on page 24 has shown 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 depots per branch allows you to optimize software. 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, take into consideration connections between each managed system in the branch (depot included) and Tivoli Provisioning Manager server.
2.4.6 System management across firewalls

Managing desktops or servers across firewalls is a common problem while performing software deployment. Typical requirements for a solution to manage systems across firewalls are: Port consolidation: opening as few ports as possible to minimize impact on firewall configuration. Firewall transversal solution: implies capability to operate across multiple firewall zones in such a way as to permit a more secure network security configuration in which each firewall has all ports needed by the product open.
25
Note: The Tivoli Provisioning Manager V5.1, the version that is generally available 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 fix pack 1, which is currently not available. In the following sections, we will discuss the options that manage agents across firewalls. In particular, Ports used by Scalable Distribution Infrastructure components on page 26 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.
2.4.7 Ports used by Scalable Distribution Infrastructure components

Table 2-2 provides the ports used by Scalable Distribution Infrastructure components. Note: Simple Network Management Protocol (SNMP) requires port 161 to be opened for traffic from management servers to managed devices. Common Agent Services require 9511,9512 and 9513, SSH port 22, SMB port 139, while Web Client requires port 9045 and 9046 for such communications.
Table 2-2 Ports used by Scalable Distribution Infrastructure components Source system Tivoli Provisioning Manager server Depot Tivoli common agent Depot Source Component CDS Management Center CDS depot server CDS subagent CDS depot server Source port Any Destination system Depot Destination component CDS depot server Destination port 2100 Connection security Secure SSL
Any Any
Depot Depot
CDS depot server CDS depot server CDS Management Center
2100 2100
Secure SSL Secure SSL
Any
Tivoli Provisioning Manager
9045 9046
Secure SSL
26
Source system Tivoli common agent Tivoli common agent Tivoli Provisioning Manager Tivoli common agent Tivoli common agent Tivoli common agent Tivoli common agent
Source Component DMS subagent CDS subagent Agent Manager Nonstop process Tivoli common agent Tivoli common agent Tivoli common agent
Source port Any
Destination system Tivoli Provisioning Manager Tivoli Provisioning Manager Tivoli common agent Tivoli common agent Tivoli Provisioning Manager Tivoli Provisioning Manager Tivoli Provisioning Manager
Destination component DMS federated agent CDS Management Center Tivoli common agent Tivoli common agent Agent Manager Agent Manager
Destination port 9045 9046 9010 9015 9510
Connection security Secure SSL
Any
Secure SSL
Any
Secure SSL
Any
9514 9515 9511
Unsecure
Any
Secure SSL
Any
9512
Secure SSL with Client Authenticatio n Unsecure
Any
Agent Manager
9513
27
28
Chapter 3.
Installing Tivoli Provisioning Manager V5.1

This chapter describes the Tivoli Provisioning Manager 5.1 installation process. We both cover UNIX and Windows operating systems to show the differences of these two platforms. The chapter contains the following sections: Installation methods on page 30 Topology Installer Launcher on page 31 Supported installation topologies and operating system versions on page 31 Account required by the installation on page 39 Preinstallation checklist on page 39 Installing behind a firewall on page 42 Overview of the installation flow on page 43 Installation log files on page 46 Post installation steps on page 47 Automation Package Developer Environment (APDE) installation on page 50
29
3.1 Installation methods

There are several methods that you can use for installation: Regular installation through the Topology Installer Launcher Silent installation Fast Start installation We provide more details about these methods in the following section.
3.1.1 Regular installation

A regular installation provides greater scalability and flexible deployment options: Install all components on a single node, or install the directory server on a separate node. Choose the middleware that you want to use for Tivoli Provisioning Manager, including more powerful database, application server, and authentication server options. Note: The availability of these installation options varies by operating system. Refer to the Installation Guide for your operating system for more details. This installation uses the Topology Installer Launcher that has been introduced with Tivoli Provisioning Manager V5.1. Refer to 3.2, Topology Installer Launcher on page 31 for details.
3.1.2 Silent installation

A silent installation provides you with the ability to predefine the settings for a regular installation and then run an unattended installation. It is useful for deploying the same installation to multiple environments.
3.1.3 Fast Start installation

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.
30
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.2 Topology Installer Launcher

The Topology Installer Launcher introduces an important enhancement regarding the installation mechanism. It is mainly a unified installer that allows you to install Tivoli Provisioning Manager and the required prerequisite software on multiple computers in a distributed topology. The Topology Installer Launcher 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 Cygwin (for Windows operating system only) WebSphere 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 Topology Installer Launcher 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 Topology Installer Launcher can perform installation on each node in parallel.
3.3 Supported installation topologies and operating system versions

The supported topologies are determined by the operating system that you use. You can have: one-node topology
Chapter 3. Installing Tivoli Provisioning Manager V5.1
31
In a local one-node topology, the Tivoli Provisioning Manager and all the prerequisite software are installed on the same computer. two-node topology 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. Important: At the GA version of the code, the two-node topology is only supported on Windows and Solaris operating systems. The installer can be invoked in two different ways: Local The installer runs on the same machine as the Tivoli Provisioning Manager server. Remote The installer runs on another system than the Tivoli Provisioning Manager server. Table 3-1 summarizes the supported topologies by operating system.
Table 3-1 Supported topologies Operating system AIX Linux on Intel Linux on PowerPC Linux on zSeries(31 Bit) Linux on zSeries(64 Bit) Solaris (Sun SPARC) Installer invocation Local Local Supported topology one-node only one-node only
Remote
one-node or two-node for Solaris 9 two-node for Solaris 10 one-node two-node (with Tivoli Directory Server or Microsoft Active Directory)
Windows
Remote
32
3.3.1 AIX and Linux

You must run the Topology Installer Launcher on the same computer where you are installing Tivoli Provisioning Manager server and its related prerequisite software. Figure 3-1 shows a diagram of the one-node installation valid for both AIX and Linux machines.
Figure 3-1 One-node AIX topology
The following operating system versions are supported for AIX and Linux: AIX AIX 5.2 64 bit ML7 AIX 5.3 64 bit ML1 Linux Red Hat Advanced Server 4.0 32 bit with Update 3 SUSE LINUX Server 9, Enterprise Edition 32 bit with SP3
33
3.3.2 Solaris (Sun SPARC)

You must run the Topology Installer Launcher on one computer and remotely install Tivoli Provisioning Manager on a separate computer. Based on your operating system you can have: Solaris 9 You can install all components on a single node or install the directory server on a separate node. Solaris 10 You must install the directory server on a separate node. Figure 3-2 shows a diagram of the one-node installation on Solaris 9 machines.
Figure 3-2 Solaris 9 one-node topology
As you can see in the above diagram the database of the Tivoli Provisioning Manager server can be both DB2 or Oracle. This is true only for Solaris operating systems.
34
Figure 3-3 shows a diagram of the two-node installation on Solaris 9 or Solaris10 machines.
Figure 3-3 Solaris 9 or Solaris 10 two-node topology
In this case, the directory server node must have a DB2 database required by IBM Tivoli Directory Server. The following are the operating system versions supported for Solaris: Sun SPARC Server with Solaris 9 Sun SPARC Server with Solaris 10
35
3.3.3 Windows
You must run the installer on one computer and remotely install Tivoli Provisioning Manager on a separate computer. Figure 3-4 shows a diagram of the one-node installation on Windows machines.
Figure 3-4 Windows one-node topology
36
Figure 3-5 shows a diagram of the two-node installation on Windows with Microsoft Active Directory as directory server.
Figure 3-5 Windows two-node topology with Microsoft Active Directory
37
Figure 3-6 shows a diagram of the two-node installation on Windows with Tivoli Directory Server as directory server.
Figure 3-6 Windows two-node topology with Tivoli Directory Server
Follows the operating system versions supported for Windows: Windows Server 2003 Standard Edition Service Pack 1 Windows Server 2003 Enterprise Edition Service Pack 1 Windows XP This operating systems is not licensed as a server by the Microsoft End User License Agreement (EULA). Tivoli products that function as a server on this operating systems are supported for demonstration purpose only. Therefore, Windows XP is only supported for the FastStart installation.
38
3.4 Account required by the installation

The installation must be performed using these accounts for UNIX and Windows: UNIX AIX, Linux and Solaris require you to log in as root user Windows Windows requires you to log in as Administrator account
3.5 Preinstallation checklist

In this section, we provide some details of the requirements for the Tivoli Provisioning Manager server installation.
3.5.1 Topology Installer Launcher requirements

The requirements shown in Table 3-2 are related to the machine used to run the Topology Installer Launcher software while running an installation.
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 Installer and image repository: 7 GB Installer and image repository: 7 GB Installer and image repository: 7 GB /opt directory: 2 GB RAM Minimum 2 GB
Linux SLES 9 with SP3 RedHat 4.0 with Update 3 Solaris 9 Solaris 10
32 bit IBM compatible PC
2.8 GHz Intel Pentium 4 processor or equivalent 1GHz CPU
Minimum 2 GB
Sun SPARC
Minimum 2 GB
39
Operating system Windows 2003 Server EE with SP1 2003 Server SE with SP1
Server type 32 bit IBM compatible PC
Processor speed 2.8 GHz Intel Pentium 4 processor or equivalent
Minimum free disk space /tmp directory: 6 GB
RAM Minimum 2 GB
3.5.2 Tivoli Provisioning Manager server requirements

Each operating system also has hardware and software requirements for the Tivoli Provisioning Manager server target machine. All these requirements, are detailed in specific documents, called Preinstallation checklist, that you can download from the IBM Software support site on the Web at: http://www-1.ibm.com/support/docview.wss?rs=0&uid=swg21249380
3.5.3 Additional software requirements

In addition to the requirements for the Topology Installer Launcher and the Tivoli Provisioning Manager server machines, we want to highlight some of them that represent common causes of failures during the installation.
Cygwin software for Windows

Cygwin v1.5.10 or higher must be installed on both the Topology Installer Launcher and the Tivoli Provisioning Manager server machines on Windows operating systems. The Topology Installer Launcher can automatically perform this installation if you run the installer on a Windows computer. Important: Make sure you check the following: Before installing the Cygwin software, make sure that c:\cygwin\bin is the first path in the %PATH% variable of your Topology Installer Launcher and Tivoli Provisioning Manager server machines. Ensure that only one Cygwin installation is on the computer. If an ssh service is already configured and started on the target machine for the Tivoli Provisioning Manager server installation, make sure to stop the service to avoid failures during the target validation phase.
40
If the installer is a UNIX or Linux computer and remotely install Tivoli Provisioning Manager on a Windows computer, you must manually install Cygwin on the target Windows computer.
Static IP address
The following is true for all platforms:
The Tivoli Provisioning Manager server must have a static IP address and must be registered in a Domain Name Server (DNS).
GNU tar
There is an additional requirement for UNIX platforms:
The Tivoli Provisioning Manager server must have the GNU tar binary to be the first in the $PATH variable of the root user on UNIX platforms.
3.5.4 Prerequisite software versions

Table 3-3 lists the required base software version for the prerequisite software. It details also the fix pack required for each software.
Table 3-3 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
41
3.6 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 to avoid failures during the installation. In a remote installation the Topology Installer Launcher 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-4 are opened to the firewall.
Table 3-4 Communication port used by Tivoli Provisioning Manager Request DHCP REQUEST DHCP REPLY PROXY DHCP TFTP BootDiscovery MTFTPPort MTFTPClients NBPServer FileServerPort FileMCAST- Address FASTPort SSH Protocol UDP (broadcast) UDP UDP UDP UDP (multicast) UDP UDP (multicast) UDP UDP UDP UDP TCP Source Port any 67 any any any any any any any any any any Destination Port 67 68 4011 69 4011 4015 8500 4012 4013 10000 4025 22 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 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
42
Request Telnet TS SNMP SNMP-TRAP SMB / NetBIOS Agent manager WebSphere Application Server 6.0
Protocol TCP TCP UDP UDP TCP TCP TCP
Source Port any any any any any any any
Destination Port 23 3389 161 162 139 9511,9512, 9513 9080,9082, 9043,9045, 9046
From managed servers provisioning server provisioning server managed servers provisioning server provisioning server provisioning server
To provisioning server managed servers managed servers provisioning server 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.7 Overview of the installation flow

During the installation, several actions take place, some of which also depend on the topology and installation settings chosen at installation time.
3.7.1 Invoking the installer

To start the Tivoli Provisioning Manager wizard on an AIX box, perform the following steps: 1. Log in as root on the system. Note: If you are using the su command to change to root, ensure that you run su -.
43
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. 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 The installer invocation on other UNIX or Linux platforms is exactly the same except for the setup file name that is followed by the corresponding operating system, for example mount_point/setuplinux.bin for a Linux machine. In a Windows operating system, the installer is started by mount_point\setupwin32.exe executable file.
3.7.2 Installation phases

We can briefly summarize the process in these phases: 1. Topology Installer Launcher installation During this phase, the Tivoli Provisioning Manager Embedded Edition (eTPM) installation takes place. The eTPM is currently used in the Tivoli Provisioning Manager Installer as the backend to run workflows and to perform the install. 2. CITScanner scan utility Once the Topology Installer Launcher is installed, you provide through the installation dialog some information about both the installer machine and the
44
target server. At this point, the Common Inventory Technology (CIT) is installed on the system, and a scan utility is executed against the Tivoli Provisioning Manager server machine to verify the information provided (credentials and authorizations) and the status of the installation and configuration of the prerequisite software. 3. Prerequisite software Tivoli Provisioning Manager configuration There is a series of dialogs that allows you to specify the configuration information for the prerequisite software. These information are used to build response file for each prerequisite software, used to perform a silent installation and a subsequent configuration of them. 4. Location of the installation images After a validation summary of the space required by the prerequisite software, you are asked to provide details about the installation images location that can be either the installation media, or an image repository, or a local installation image on the target server in case of a remote installation. 5. Provisioning server installation In this phase, the real installation and configuration of the prerequisite and Tivoli Provisioning Manager software takes place. The software is installed in this order: WebSphere Application Server 6.0 installation WebSphere Application Server 6.0, Fix Pack 2 installation WebSphere Application Server 6.0, Fix Pack 11 installation DB2 Universal Database Enterprise Server Edition 8.2 DB2 Universal Database Enterprise Server Edition 8.2, Fix Pack 11 Tivoli Directory Server 6.0 Tivoli Directory Server 6.0, Fix Pack 1 Tivoli Provisioning Manager Agent Manager Tivoli Provisioning Manager for Dynamic Content Delivery Tivoli Provisioning Manager for Job Management Service
6. Installation complete When all the previous steps are completed, the Tivoli Provisioning Manager server is ready to be used and you can start the Web User Interface. 7. Post installation steps Some steps can be executed at the end of the installation. They are described in the section Post installation steps on page 47.
45
3.8 Installation log files

Because multiple components are installed during installation, there are several log files that you might need to check to resolve an installation error.
3.8.1 Installer logs

Before the installer starts, the main log for setting up and starting the installer is located in the following file: /tmp/tclog_til/launcher/tcinstall.log While the installer is running, the main log for the installer is located in the following file: installer_dir/workspace/.metadata/.log Here, installer_dir is the directory where the installer is located. This file identifies errors that occur during installation and also contains parameter values that were used by the installer. The error messages might indicate that you need to check additional log files for specific components. The maximum file size of the log is 1 MB. If the log becomes larger than 1 MB, multiple files are created. The .log file is the most recent file. While the installer is installing software, you can also view log information on the installation log tab. The log file for the tcdriver-manager automation package tool can also contain information for general troubleshooting. It is located in installer_dir/logs/tcdrivermanager.log
3.8.2 Tivoli common directory

The Tivoli common directory is a common parent directory that stores log files from multiple Tivoli products. Each product stores logging information in a separate subdirectory within the Tivoli common directory. If you are installing Tivoli Provisioning Manager for the first time as the first Tivoli software product on your system that uses the Tivoli common directory, the installation wizard prompts you to specify a location for it. This location is used by Tivoli Provisioning Manager and other Tivoli products. The default location is: /opt/ibm/tivoli/common
46
3.8.3 Directory containing output from the installation

The following directory contains the logs file for the installation and configuration of the Tivoli Provisioning Manager and prerequisite software. UNIX or Linux $TIO_LOGS/install directory Windows %TIO_LOGS%\install directory Example 3-1 shows a file listing of a Tivoli Provisioning Manager server after the installation.
Example 3-1 Installation log files Follows the file listing of the $TIO_LOGS/install directory of an AIX Tivoli Provisioning Manager server:
[tioadmin@paris][/usr/ibm/tivoli/common/COP/logs/install]-> ls -al total 7976 drwxrwx--x 2 root tivoli 4096 Sep 04 19:52 . drwxrwx--x 9 root tivoli 4096 Nov 28 17:58 .. -rw-rw-r-1 root system 775299 Sep 04 19:52 IBM_DB2_Alphablox_8.4_InstallLog.log -rw-rw-r-1 root system 360 Sep 04 19:52 TcStart.log -rw-rw-r-1 root system 335 Sep 04 19:52 TcStop.log -rw-rw-r-1 root system 53 Sep 04 19:52 add_user_to_group.log -rw-rw-r-1 root system 3075 Sep 04 19:52 call_was_config.log -rw-rw-r-1 root system 4236 Sep 04 19:52 call_was_deploy.log -rw-rw-r-1 root system 107 Sep 04 19:52 create_wasprofile.log -rw-rw-r-1 root system 4050 Sep 04 19:52 db2_prereqs.log -rw-rw-r-1 root system 8545 Sep 04 19:52 db2config.log -rw-rw-r-1 root system 269847 Sep 04 19:52 depcheckWizard_0.log -rw-rw-r-1 root system 7709 Sep 04 19:52 ibmds_config.log -rw-rw-r-1 root system 0 Sep 04 19:52 ibmds_config_err.log -rw-rw-r-1 root system 10 Sep 04 19:52 listWASProfiles.log -rw-r--r-1 root system 2629240 Sep 04 19:42 reinit.log -rw-rw-r-1 root system 329169 Sep 04 19:52 tcinstall.log -rw-rw-r-1 root system 471 Sep 04 19:52 tpmportdef.properties -rw-rw-r-1 root system 0 Sep 04 19:52 was_unixsetup.log
3.9 Post installation steps

This section describes the configuration tasks to perform after the installation.
47
3.9.1 Changing default passwords

During Tivoli Provisioning Manager installation, a default set of administrator accounts are created for Tivoli Provisioning Manager and associated software components. After installation, you can change the default passwords for these administrator accounts from the command line. Refer to the product documentation for detailed instructions on how to change the default passwords for these users. Note: You can only change the password for one user name at a time. After a new installation of Tivoli Provisioning Manager, the tioldap and tiodb user names are set to expire after 90 days. Table 3-5 summarizes the administrators and describes their main role within Tivoli Provisioning Manager.
Table 3-5 Default user names and passwords User name tioadmin Default password user-defined at installation time Description Defined in the operating system Used to logon on the operating system. Used to install Tivoli Provisioning Manager Used to log in on the Web User Interface for a FastStart installation on Windows tioldap tioldap Defined in Tivoli Directory Server Used by WebSphere Application Server to connect to the Tivoli Directory Server This account must have rights to search user accounts
48
User name wasadmin
Default password wasadmin
Description Defined in Tivoli Directory Server Used by WebSphere Application Server as the administrator account Used to start, stop, and manage WebSphere
tioappadmin
tioappadmin
Defined in Tivoli Directory Server Used to log on to the Web User Interface The default Tivoli Provisioning Manager user that is initially configured with full access rights
tiointernal
tiointernal
Defined in Tivoli Directory Server Used by Tivoli Provisioning Manager for system initiated actions
3.9.2 Importing sample data

This is an optional configuration task. The data model in Tivoli Provisioning Manager, is a representation of all of the physical and logical that Tivoli Provisioning Manager manages. If you are importing data into the data model for the first time in a test environment, you can import the sample XML file called venice.xml located in the $TIO_HOME/xml folder, as a template for your own data model. To import the venice.xml file to your data model, follow the steps below: 1. Log in as root. 2. Ensure the database is running. 3. Open a command window and run the following command, which will enable you to import properly formed XML file to populate the data model: "$TIO_HOME/tools/xmlimport.sh" "file://$TIO_HOME/xml/venice.xml"
49
You have now populated the data model with sample data. Note: For more information on xmlimport or configuring the data center, refer to the information center.
3.10 Automation Package Developer Environment (APDE) installation

The Automation Package Developer Environment (APDE) is an Eclipse-based plug-in environment that you can use to customize existing automation packages or create new automation packages. The Eclipse platform is structured as a core runtime engine that includes additional features that are installed as plug-ins. A plug-in contributes additional functionality to the Eclipse environment platform. The Automation Package Developer Environment connects to the Tivoli Provisioning Manager server database so that you can work directly with objects in the data center model and existing automation packages to build your own automation packages. Figure 3-7 describes the APDE architecture.
Figure 3-7 APDE architecture
50
3.10.1 Automation Package Developer Environment installation requirements

Ensure that the computer you are using to run the Automation Package Developer Environment meets installation requirements.
Software
The Automation Package Developer Environment requires Eclipse software development kit (SDK) 3.1.2. Version 3.2 is not supported. You must use the full Eclipse SDK. The Eclipse Platform does not contain all the necessary components required by Automation Package Developer Environment. Eclipse requires the IBM Java runtime environment (JRE), Version 1.4.2 or later. The Automation Package Developer Environment installation can use an existing JRE installation, or you can install the JRE included with the Automation Package Developer Environment. An Eclipse installation is included with Tivoli Intelligent Orchestrator or Tivoli Provisioning Manager in the TIO_HOME\eclipse directory. If you want to obtain the latest version of Eclipse, you can download it from this site: http://www.eclipse.org/downloads/index.php If you need to start Tomcat from your Eclipse environment, you must install the full Eclipse Web Tools Platform. The latest version is available on the Web at: http://download.eclipse.org/webtools/downloads/
Operating system
The Automation Package Developer Environment is tested on Windows and Linux operating systems. If you are running it on a computer other than the Tivoli Provisioning Manager server, the computer must be running a version of Windows or Linux supported by Eclipse 3.1.2 or later. Note: The Software Package Editor included with the Automation Package Developer Environment is only supported on Windows.
Hardware
The Automation Package Developer Environment requires a minimum of 256 MB of random access memory (RAM) plus the amount of RAM required to compile workflows and any Java code in your automation packages. If multiple users use the Automation Package Developer Environment concurrently, a minimum of 400 MB per user is recommended.
51
Connectivity
Automation Package Developer Environment requires access to the Automation Package Developer Environment database to use all available features. If you want to run new workflows that call Java classes, Automation Package Developer Environment must also have access to the deployment engine. If the Automation Package Developer Environment is installed on a computer other than the Tivoli Intelligent Orchestrator or Tivoli Provisioning Manager server, the following additional requirements must be met: DB2 The database client must be installed on the same computer as the Automation Package Developer Environment. To run workflows that call Java classes, you must create a shared directory that you will use to create your automation packages. The shared directory must be available to both the Automation Package Developer Environment and the Tivoli Intelligent Orchestrator or Tivoli Provisioning Manager server. For example, you can create a shared directory on the Tivoli Intelligent Orchestrator or Tivoli Provisioning Manager and map to that directory from the computer where Automation Package Developer Environment is installed.
3.10.2 Installing the Automation Package Developer Environment

You can install Automation Package Developer Environment on the Tivoli Provisioning Manager server or on a separate computer that connects to the database. A separate connection should only be used when you are working with a Tivoli Provisioning Manager server in a test or development environment. Automation Package Developer Environment uses an embedded database to cache information about workflows, automation packages, objects in the data center model, and device drivers. The database client is only required if your product topology uses DB2 Universal Database for its database and if you are using a JDBC Type 2 driver to communicate with the provisioning server. Note: If you have a JDBC Type 4 driver, the DB2 Universal Database client is not required. To install the Automation Package Developer Environment follow these steps: 1. Verify that the IBM JRE java\bin directory is in your PATH environment variable. For example: PATH=C:\IBM\WebSphere\AppServer\java\jre\bin If more than one JRE is installed, make sure the IBM JRE is the first one in the path. You can check whether the IBM JRE is in your path by opening a
52
command prompt and running java -version. You should see something similar to: java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn1420-20040626 (JIT enabled: jitc)) 2. If you are installing Automation Package Developer Environment on a separate computer copy the files you require to your local computer. The Eclipse SDK that you downloaded or copied from the provisioning server. The Eclipse SDK on the provisioning server is located in TIO_HOME\eclipse. The Automation Package Developer Environment files in apde.zip. The apde.zip file is located in the TIO_HOME\apde directory. 3. Create a directory for Automation Package Developer Environment. For example, APDE_HOME. 4. Copy the Eclipse SDK files to the directory you created. If you downloaded the Eclipse SDK, extract the contents of the zipped file to the directory. The zipped extracts contents to an eclipse subdirectory. If you are updating an Automation Package Developer Environment installation, overwrite the existing files if you are prompted to replace them. 5. Extract the contents of apde.zip to the directory you created.
3.10.3 Configuring database connectivity

To use Automation Package Developer Environment, you must configure database connectivity and import authentication keys. To configure the database connectivity, perform the following steps: 1. DB2: Verify that the local database client is installed on the same computer as the APDE. Note: This step is not required if you have a JDBC Type 4 driver con communication with the Tivoli Provisioning Manager server. 2. DB2: Catalog the database on the provisioning server. Run the following commands in a command window: catalog tcpip node node-name remote hostname server port catalog database database-name as alias at node node-name Here, node-name is a local alias for the database node. hostname is the host name or IP address of the database server. port is the port number of the
53
database instance. database-name is the name of the database. The default is tc. alias is an alternate alias for the database. Refer to Example 3-2 for the command execution and output check.
Example 3-2 Registering the node and the database
You must first catalog the tcpip node using this command once logged in the system with the instance owner user: $ db2 catalog tcpip node test remote paris.itsc.austin.ibm.com server 50000 You receive an output like the following: DB20000I The CATALOG TCPIP NODE command completed successfully. DB21056W Directory changes may not be effective until the directory cache is refreshed. Then you can catalog the database to the just created node using this command: $ db2 catalog database TC as TC1 at node test The output looks like the following: DB20000I The CATALOG DATABASE command completed successfully. DB21056W Directory changes may not be effective until the directory cache is refreshed. You can list the properties of the newly created node and database using these commands: db2 list node directory The output looks like the following: Node 3 entry: Node name Comment Directory entry type Protocol Hostname Service name = = = = = = TEST LOCAL TCPIP paris.itsc.austin.ibm.com 50000
54
db2 list database directory The output looks like the following: Database 2 entry: Database alias Database name Node name Database release level Comment Directory entry type Catalog database partition number Alternate server hostname Alternate server port number = = = = = = = = = TC1 TC TEST a.00 Remote -1
Note: This step is not required if you have a JDBC Type 4 driver con communication with the Tivoli Provisioning Manager server. 3. Cloudscape: If you are configuring a remote connection, update dcm.xml file with the fully qualified host name (FQHN) of the Tivoli Provisioning Manager server using the following procedure: a. Open the file TIO_HOME\config\dcm.xml. b. Find the following line with the database URL, for example: <url>jdbc:derby://localhost:1527/C:/Program Files/IBM/tivoli/tpm/derby/databases/TC</url> c. Change the text localhost to the fully qualified host name of the Tivoli Provisioning Manager server. For example: <url>jdbc:derby://example.com:1527/C:/Program Files/IBM/tivoli/tpm/derby/databases/TC</url> d. Restart the Tivoli Provisioning Manager server for the changes to take effect. 4. If you are configuring a remote connection to the database, copy the following files from the TIO_HOME\config directory on the Tivoli Provisioning Manager server: crypto.xml DB2 and Cloudscape: dcm.xml Oracle: dcm-ORA.xml
55
Note: The files can be copied in any directory. You will then point to that directory in a subsequent step. 5. Edit the dcm.xml file and in the <classpath> element change the path of the .jar files to the location where they are stored in your local Eclipse installation. Follow Example 3-3.
Example 3-3 .jar file location update <classpath> <pathelement location="C:\Program Files\SQLLIB\java\db2jcc.jar" /> <pathelement location="C:\Program Files\SQLLIB\java\db2jcc_license_cu.jar" /> </classpath>
6. Start Eclipse. From the APDE_HOME\eclipse directory, run eclipse.exe. 7. When prompted to select a workspace, select the directory where you want to store automation packages you create. If you want the ability to run workflows in automation packages that call new Java classes, specify the shared directory as described in Automation Package Developer Environment installation requirements. 8. Click Window Preferences. 9. Expand Automation Packages, and click Encryption. 10.A default encryption key is provided and is used to encrypt sensitive information that is saved to the database. However, you can import other encryption keys to encrypt all passwords. Click Import and select the TIO_HOME\config directory or the local directory where you copied the crypto.xml file. For DB2 Universal Database, the default value for the heap size variable, APP_CTL_HEAP_SZ, is 128. If you get a warning regarding insufficient heap size, you can change the size. To check the current value of APP_CTL_HEAP_SZ, you can run the following command: db2 get db cfg for <TIO database name> To increase the heap size: a. Log on to the DB2 Universal Database server locally, using a DB2 Universal Database administrator account: db2 connect to <databasename> user <username> using <password> b. Run the following command: db2 update db cfg for tc using APP_CTL_HEAP_SZ 1024
56
c. By default, the installer sets the heap size variable, APPLHEAPSZ, to 3072. Consider setting the APPLHEAPSZ variable to 3072 if you are not using the installer. To do this, use the following command to update your DB2 Universal Database configuration: db2 update db cfg for tc using APPLHEAPSZ 3072 If you stop using the Automation Package Developer Environment, you should restore APP_CTL_HEAP_SZ to its original value, depending on the amount of memory on the DB2 Universal Database server. For example, if you are running many workflows and APP_CTL_HEAP_SZ is set too high, you might run out of DB2 Universal Database database memory. 11.Click Database. 12.Next to Import configuration field, click Import, and select the TIO_HOME\config directory or the local directory where you copied dcm.xml. The values for the remaining fields are filled. 13.If you are configuring a remote connection to the database, change the following information: DB2 In the Import driver field, type the full name and path to the file that contains the Java Database Connectivity (JDBC) driver on your local computer. For example, C:\IBM\SQLLIB\java\db2java.zip. Click Add. Change database alias in the DB URL and Database Name fields to the alias specified in step 2. For example, if you used the alias TC1, the values are jdbc:db2:TC1 and TC1 respectively.
Cloudscape In your Automation Package Developer Environment workspace folder, open the .metadata\.plugins\com.ibm.tivoli.orchestrator.tcdriverdevelopmen t\config\dcm.xml file. In the <classpath> element, change the path of the .jar files to the location where they are stored in your local Eclipse installation. Follow Example 3-4.
Example 3-4 .jar file location update <classpath> <pathelement <pathelement <pathelement <pathelement </classpath> location="C:\APDE_HOME\eclipse\plugins\org.apache.derby\derby.jar" /> location="C:\APDE_HOME\eclipse\plugins\org.apache.derby\derbynet.jar" /> location="C:\APDE_HOME\eclipse\plugins\org.apache.derby\derbyclient.jar" /> location="C:\APDE_HOME\eclipse\plugins\org.apache.derby\derbytools.jar" />
57
3.10.4 Configuring deployment engine connectivity

You can configure your development environment to dynamically activate automation packages so that Automation Package Developer Environment can automatically load the Java classes required to run workflows.
Prerequisites
If you are running the Automation Package Developer Environment on a separate computer, you must map a directory from the Tivoli Intelligent Orchestrator or Tivoli Provisioning Manager computer and use that as the parent path of your workspace. If the Automation Package Developer Environment is on a UNIX or Linux computer, you must configure one of the following: Install Samba or a similar implementation of the Microsoft networking system on the Tivoli Intelligent Orchestrator or Tivoli Provisioning Manager computer. Configure firewalls to allow traffic with the Server Message Block (SMB) protocol. Install an implementation of the Network File System (NFS) protocol on the computer where you installed the Automation Package Developer Environment. Configure firewalls to allow traffic with the NFS protocol. Attention: The configuration described in this section is intended for a development environment only. The configuration sets up a connection to the deployment engine over a port that does not require authentication. Configuring connectivity with the deployment engine is required for to work with new automation packages that contains Java classes. Those Java classes must be loaded and available to the deployment engine if you want to run a workflow without manually installing the automation package first. There are two main configuration steps: 1. Configure the Automation Package Developer Environment with information required to start the deployment engine. 2. Ensure that Tivoli Intelligent Orchestrator or Tivoli Provisioning Manager is running with the -dev option. To configure connectivity with the deployment engine follow this procedure: 1. Click Window Preferences. 2. In the Preferences dialog box, click Automation Package Deployment Engine.
58
3. Specify the deployment engine options: Deployment engine port The port number that the deployment engine uses to listen for requests to install an automation package. The default value is 3166. Host name or IP address The host name or IP address of the Tivoli Provisioning Manager or Tivoli Intelligent Orchestrator server. The default value is localhost. Remote directory The path to the shared directory from the Tivoli Provisioning Manager or Tivoli Intelligent Orchestrator server. Local directory The path to the shared directory from the Automation Package Developer Environment server. For example, if you created a directory called /home/tioadmin/share on the Tivoli Intelligent Orchestrator or Tivoli Provisioning Manager server and mapped that directory as R:\ on the Automation Package Developer Environment computer, the Remote directory value is /home/tioadmin/share and the Local directory value is R:\. 4. To open port 3166, Tivoli Intelligent Orchestrator or Tivoli Provisioning Manager must be running in development mode. To start the server in development mode, run the startup script with the -dev option as follows: On Windows tio.cmd -dev On UNIX and Linux tio.sh -dev
3.10.5 Starting the Automation Package Developer Environment

To start Automation Package Developer Environment, perform the following steps: 1. In the Eclipse installation directory, run the appropriate command: On Windows: eclipseLauncher.bat On UNIX and Linux: eclipseLauncher.sh 2. To display the Automation Package view, click Window Open Perspective Other.
59
3. Click Automation Package. The Automation Package view is displayed ad shown in Figure 3-8.
Figure 3-8 Automation Package view
Note: If this is not the first time you have installed Automation Package Developer Environment, you might have to remove all files and directories in the $APDE/eclipse/configuration/ directory, except the config.ini file, to activate latest installation. If you will be working on both workflows and Java classes for your automation packages, it is recommended that you use the same workspace for Java and workflows.
60
3.10.6 Configuring Automation Package Developer Environment preferences

In the Eclipse environment, a perspective provides a specific set of functionality used to complete a task. The Automation Package perspective is the workspace that is used to write workflows, and create and build automation packages. You can configure this perspective by performing the following steps: 1. Click Window Preferences. 2. Click Automation Package. Refer to the online Information Center or the product documentation for a complete list of all the parameters you can customize.
3.10.7 Automation Package Developer Environment views

The Automation Package Developer Environment perspective includes several views that help you to create automation packages and workflows. Refer to the online Information Center or the product documentation for a complete list of all the parameters you can customize.
61
62
Chapter 4.
Configuration
Tivoli Provisioning Manager provides a number of out-of-the-box functionalities such as network discovery and predefined reports. However, some configuration is still necessary. This chapter describes the following topics: Discovery on page 64 Service access points (SAP) on page 70 Credentials on page 71 Groups on page 73 Applications on page 74 Reports on page 78 Automation packages on page 81 Software Package Editor on page 85
63
4.1 Discovery
Discovery is the capability to discover new devices and configuration changes for computers, switches, subnets, software, and images. In addition to other third-party discovery methods that can be used, Tivoli Provisioning Manager provides the following types of discovery methods: Microsoft Active Directory discovery Tivoli Provisioning Manager network discovery Tivoli Provisioning Manager Inventory discovery IBM Discovery library reader Rembo hardware discovery
4.1.1 Discovery scan types

From the Web interface you find the discoveries located in Inventory Manage Inventory Discovery Configurations. You can modify an existing discovery by clicking Properties in the action context menu of that discovery. In the discovery configuration dialog, you must select one of the following discovery scan types: Devices Software Other The available drop-down list in Discovery Method depends on the selected scan type. The IBM discovery library reader and Tivoli Provisioning Manager Inventory discovery are available in both scan types: devices and software.
Devices scan type

The following discovery methods are available in the devices scan type: Discover Computers using SSH Discover Devices (computers, switches, routers) using SNMP Discover Windows Computers using Windows SMB IBM Discovery Library Reader Microsoft Active Directory Discovery Netview Discovery Rembo Hardware Discovery Tivoli Provisioning Manager Inventory Discovery Tivoli Provisioning Manager Security Compliance Manager Scan
64
Software scan type

The following discovery methods are available in the software scan type: AIX Fix scan IBM Discovery Library Reader Microsoft Updates Discovery Rembo Hardware Discovery Tivoli Provisioning Manager Discovery Tivoli Provisioning Manager Security Compliance Manager Scan
Other scan type

The other scan type uses discovery methods for more specific discovery types or applications.
4.1.2 Tivoli Provisioning Manager Inventory Discovery

You can use the Tivoli Provisioning Manager Inventory discovery to perform a hardware scan or software scan, or both, using the registry or software signature feature. Software signatures are the set of unique information that identifies a software application, such as the name, version, and file size of an application. A hardware scan, if selected, gathers details about computer type, serial number, disk size, CPU, memory, partition, network interface, IP address and other hardware information. A software registry scan reads runs on Windows targets only and reads the installed software from the registry. However, a software registry scan does not discover information about the installed operating system and version. A software signature scan identifies all installed software including the operating system and version based on the software signatures. Using selected signatures limits the software scan. This is useful when a corporate policy only allows to scan for certain software products. The Tivoli Provisioning Manager Inventory discovery requires the Tivoli Common Agent on the targets in order to perform the inventory scan. The Tivoli Common Agent can be installed separately on a target, or when a computer is created using the Add Computer wizard.
4.1.3 Network discovery

The Tivoli Provisioning Manager network discovery allows you to discover devices over Secure Shell (SSH), Server Message Block (SMB), and Simple Network Management Protocol (SNMP) protocols.
Chapter 4. Configuration
65
Network discovery using SSH or Windows SMB

A network discovery using SSH scans the network on the specified range or subnet on port 22. A discovery using Windows SMB scans the network on port 139 (RPC) and port 145 (NetBIOS over TCP/IP). The requirements for a Windows SMB scan are described in Requirements on target endpoints on page 163. The SSH and Windows SMB network discoveries runs agentless. Both discovery scans return host name, network interfaces, and IP addresses for each computer.
Create a discovery using SSH or Windows SMB

From the Web interface, select Inventory Manage Discovery Discovery Configuration click Edit Add Discovery Configuration. 1. Enter a name for the discovery (required). 2. Enter a description for the discovery. 3. Select the discover type devices from the provided options. 4. Select one of the following discovery methods from the drop-down list: Discover Computers using SSH Discover Windows Computer using SMB 5. Click Next. 6. In the Discovery Parameter page, enter an IP Address Range or a Subnetwork. You can have multiple IP address ranges and subnetworks in one discovery scan. 7. In the Credentials section specify a user ID and password to use for the remote authentication. If you specify more than one user ID and password, the Tivoli Provisioning Manager server will try to connect each IP address with each user name until it finds a valid one. 8. The Credentials Search Key has the default value ssh for SSH discovery and rxa for Windows SMB discovery. 9. The IP Address Response Timeout in Milliseconds has the default value 15000. In slow networks, you should increase this value. 10.Click Finish.
66
Discover devices using SNMP

The SNMP discovery gathers computer, switches and routers. The SNMP discovery requires the SNMP Agent installed and configured on the target systems. From the Web interface, select Inventory Manage Discovery Discovery Configuration click Edit Add Discovery Configuration. 1. Enter a name for the discovery (required). 2. Enter a description for the discovery (optional). 3. Select the discover type devices from the provided options. 4. In the Discovery Method drop-down list, select Discover Devices (computers, switches, routers) using SNMP. 5. Click Next. 6. In the Discovery Parameter page, enter the following parameter values: IP Address Ranges Subnetworks Credentials Search Key IP Address Response Timeout 1 in Milliseconds IP Address Response Timeout 2 in Milliseconds IP Address Response Timeout 3 in Milliseconds SNMP Communities Values
7. Click Finish.
4.1.4 IBM discovery library reader

The discovery library reader is a consumer of books that are discovered by IBM applications or third-party vendors (authors). Books are XML files that contain discovery information, and identify resources and their relationships. They contain the information about the network that is known to the discovery product at that particular time. Both IBM and third-party vendors use adapters to produce books that will be used by Tivoli Provisioning Manager discovery library reader. IBM applications use adapters and the vendors use integrators to produce books that contain discovery information. Tivoli Provisioning Manager will read the books and update the data center model with the following information: Computers (host name, domain) IP Protocol endpoints
67
LAN Protocol endpoint Software installations Software instances Generic applications IP, NIC, OS Apache Server and configurations (including port and Web module) WebSphere Application Server and configurations (for example, cells, clusters, and nodes) DB2 Universal Database instances and configurations (for example, tables spaces, and TCP port) Subnetworks Software modules which include generic applications, operating systems, DB2 Universal Database, WebSphere Application Server, and Apache HTTP Server. You must create a book from an adapter from an IBM application or third-party vendor before running an IBM discovery library reader. The following example uses a sample book from the directory $TIO_HOME/xml/samplebook. From the Web interface, select Inventory Manage Discovery Discovery Configuration click Edit Add Discovery Configuration. 1. Enter a name for the discovery (required). 2. Enter a description for the discovery. 3. The IBM discovery library reader is located in both discover types, Devices and Software. Select one. 4. In the Discovery Method list, select IBM Discovery Library Reader. 5. Click Next. 6. In the Discovery Parameters page, enter the following parameter values: book.source.name is defined inside the book under the tag <cdm:Name>. drift.repository.dir is the directory where results are written to. drift.save.elements is true. repository.dir is the directory where the books are read from. This must be different from the drift.repository.dir directory. 7. Click Finish. If the specified repository.dir contains files other than book XML files, the discovery scan will fail.
68
4.1.5 Microsoft Active Directory discovery

You can use Microsoft Active Directory discovery to import all of your existing Microsoft Active Directory groups and computer information into Tivoli Provisioning Manager. From the Web interface, select Inventory Manage Discovery Discovery Configuration click Edit Add Discovery Configuration. 1. Enter a name for the discovery (required). 2. Enter a description for the discovery (optional). 3. Select Devices from the Discover type options. 4. In the Discovery Method the list, select Microsoft Active Directory Discovery. 5. Click Next. 6. In the Discovery Parameter page, enter Active Directory Information: Server Name (required) Base Distinguished Name (required) User ID (required) Password (required) Default Access Group (required) Filters User defined search command Filter LDAP Attributes (example: objectSid and objectGUID) Discover groups Discover organizational units Gateway IP Subnet Mask
Dynamic IPs (DHCP) (default is true). 7. Click Finish.
4.1.6 Run a discovery

To run a discovery, perform the following steps: 1. From the Web interface, select Inventory Manage Discovery Discovery Configuration.
69
2. Select a discovery and click the Run action button next to the discovery. Some discoveries, like for example Tivoli Provisioning Manager Inventory discovery, require to select the targets at the time initiating the discovery. 3. Click Finish to run or to schedule the discovery.
4.2 Service access points (SAP)

Service access points (SAP) are a combination of protocols and credentials. For example, the Remote Execution and Access (RXE) service access point provides a user name and password for authentication and the network protocol for communication (SSH or Windows SMB). From the Web interface, select Inventory Manage Inventory and select an asset type, for example Computer. In the Credentials tab click Edit Add Service Access Point. Enter the settings as shown in the dialog in Figure 4-1.
Figure 4-1 Add service access point dialog
In the dialog shown in Figure 4-1, perform the following steps: 1. Enter a name. 2. Select a protocol type from the list. 3. Select one role for the type: Host or Client. 4. Optionally, you can specify additional information in Other Type.
70
5. Enter a domain. 6. Enter any optional information in Context. 7. The Port value automatically updates to the default port for the protocol selected in the Type list, for example, port 22 for the SSH protocol. 8. The Authentication check box is by default enabled. If authentication is required, specific credentials must be defined, corresponding to the selected type of protocol. 9. Click Save.
4.3 Credentials
Depending on the protocol type in the service access point, you also need to associate credentials. From the Web interface, select Inventory Manage Inventory and find the asset to modify the service access point. For example, click Computers and select one. In the Credentials tab you can use the use the wizard Edit Add Credentials, or you can clone existing credentials from one computer and copy them to one or more target computers using Edit Clone Credentials. You can also add credentials to a particular service access point using the action context menu as shown in Figure 4-2.
Figure 4-2 Add credentials to service access point
71
1. Click the action context menu next to the service access point. 2. Select Add Credentials:password from the action menu. 3. Enter an alias in the Search Key field that uniquely identifies the user name and password pair you will be using to access the service (required). 4. Enter a user name used to authenticate with (required). 5. Enter a password. 6. Optionally, enter an enable password for special administrator operations on the server. 7. Optionally, type the key fingerprint for the server. 8. This credential is set as default when you check the box. You can have no more than one default credential in a service access point. 9. Click Save. A service access point is optionally associated to one or more logical operations. For example, if the SSH-Server service access point is associated with the device operations file-transfer, execute-command, and ping, then the Tivoli Provisioning Manager server uses secure copy (scp) and secure shell (ssh) to copy files and execute commands on the remote computer. The ping operation checks for a response from the remote sshd daemon. Figure 4-3 shows the configured service access points and their associated device operations for a Linux computer with the common agent installed. The SSH-Server service access point is automatically added during a discovery using SSH. The Agent-Server is added after the Tivoli Common Agent installation. The RXA-BootStrap-Server is created during the common agent installation on Linux targets.
Figure 4-3 Service access point (SAP) configured for common agent
72
4.4 Groups
Defining groups and their members is a way of organizing devices and helping to perform actions such as software distribution, running script and workflow tasks, and managing compliance. Members can belong to multiple groups. Group members can be selected manually or using queries. In static Groups members are added or removed manually. In dynamic Groups the members are assigned dynamically based on reports. Groups are found in Inventory Manage Inventory Groups.
4.4.1 Creating a static group

Select Edit Add Group from the Web interface and enter the fields in the dialog as shown in Figure 4-4.
Figure 4-4 Add static group
1. Enter a name (required). 2. Enter a description. 3. Select a type from the list, for example, computer, switch, software definition, boot server. 4. In the Group Members field, choose Select the group members. 5. Leave the search box empty or type a search pattern and click Search.
73
6. Select one or more available members and add them to the Assigned Members field. 7. Click Save.
4.4.2 Creating a dynamic group

Select Edit Add Group from the Web interface and enter the fields in the dialog as shown Figure 4-5.
Figure 4-5 Add dynamic group
1. Enter a name (required). 2. Enter a description. 3. Select a type from the list, for example, computer, switch, software definition, boot server. 4. In Group Members, click Select a report to populate members. 5. Select a report category from the list under Report Category. 6. Select one report from the Available Reports list, for example, inventory, compliance, discovery. 7. Click Save.
4.5 Applications
Application management can be challenging because the products and services that businesses offer are often supported by a heterogeneous hardware infrastructure and distributed software components with complex relationships and dependencies. Each application includes one or more application tiers. A
74
group of servers shares the processing workload for each tier. A tier can include dedicated servers that are available exclusively to the tier and overflow servers from a resource pool that are allocated to the tier based on demand for resources. In the Web interface, the Applications section contains the following entries: Customers Resource pools Administrative domains Cluster domains Service catalog Resource reservation Note: The Web interface in Tivoli Provisioning Manager for Software does not contain the Applications section. Figure 4-6 compares the Web interfaces for Tivoli Provisioning Manager and Tivoli Provisioning Manager for Software.
Figure 4-6 Web interface in Tivoli Provisioning Manager and Tivoli Provisioning Manager for Software
4.5.1 Creating a customer

If you host or manage application environments for different customers or areas of your business, you can model the organization of your infrastructure. For each customer, you can model application solutions and application tiers that support common business functionality within each application. In the Web interface, select Applications Customers and click Edit Add customer. Perform the following steps:
75
1. Enter a name. 2. Click Save.
4.5.2 Creating a resource pool

A resource pool is a container of available computers and servers that support one or more application tiers. When an application tier requires more capacity, it can provision a managed system from its associated resource pool. When demand is low, provisioned systems are returned to the resource pool so that they are available to other applications In the Web interface, the resource pools are located in Applications Resource Pools. Click Edit Add Resource Pool to open the dialog window. 1. 2. 3. 4. Enter a name (required). Select a server template from the list. Select a locale from the list. Click Save.
After creating a new resource pool, you can add one or more computers into the resource pool. Use one of the following ways to add computers: You can manually add new computers using the add server wizard in Applications Resource Pools, select a resource pool, and click Edit Add Server. In the Belongs To list, select the resource pool. You can add existing computers from Inventory Manage Inventory Computers and click Properties next to a computer action context menu. In the dialog select a resource pool from the Belongs To drop down list.
4.5.3 Creating an administrative domain

An administrative domain is a set of one or more servers that are managed from a single point. In the Web interface, select Applications Administrative Domains and click Edit Add Administrative Domain. 1. Enter a name (required). 2. Enter a description. 3. Select a software definition to associate with. 4. Select a locale. 5. Click Save.
76
4.5.4 Creating a cluster domain

The cluster domain models integrated with Tivoli Provisioning Manager enable you to achieve high availability and scalability for applications that are very important to your business. Applications can include database, e-mail, and Web-based services. Cluster domain nodes can be configured for either availability or scalability. A cluster domain is a virtual collection of physical elements such as computer systems and logical elements such as software instances, that can provide services to a client as a single unit. A cluster domain can consist of two or more cluster domain nodes that can run on one or more computer systems, working together to provide a higher level of availability and scalability. Two cluster domain types can be described: Peer domain: This cluster domain consists of two or more peer cluster domain nodes organized in such a way as to have one online node called a master node, and one or more online or offline nodes called standby nodes. Each cluster domain node is aware of all other nodes, and administration commands can be issued from any node in the peer domain. All cluster domain nodes have a consistent view of the domain membership. Clustering software is installed and configured on all of the nodes in the cluster, to monitor the status of the cluster domain. Management server domain: This cluster domain has a management node that is used to administer a number of redundancy nodes. Only the management node has knowledge of the whole domain. The managed cluster domain nodes know only about the node managing them. They know nothing of each other. Clustering software is installed on the management node only, and administration commands are issued only from the management node to administer all the redundancy nodes. For a large data center, a management server domain can contain more than one management nodes to administer the redundancy nodes. In the Web interface, select Applications Cluster Domains and click Edit Add Cluster Domain. 1. 2. 3. 4. 5. 6. 7. 8. 9. Enter a name (required). Enter a description. Select Cluster Domain Type peer or management server (required). Select Target State. Select a software definition to associate with. Select an administrative software definition. Select a cluster virtual IP. Enter a port. Click Save.
77
4.6 Reports
Reports are used to retrieve current information about data center inventory, activity, and system compliance. You find the following report categories in the Web interface reports: Audit reports Inventory reports Compliance reports Discovery reports Deployment reports Other reports You can edit existing reports or create new ones. Click Edit Add a Report in a report category and enter the settings in the wizard: 1. When the Report Description dialog is displayed: a. b. c. d. e. f. Enter a name (required). Enter a description. Select a category. Enter a type. Select an access group from the list. Click Next.
2. When the Report Constraints dialog is displayed: a. Select one or more views from Available Views to include in the report. b. Optionally apply report filters using the Available Fields. c. Click Next. 3. When the Report Layout dialog is displayed: a. Select the fields to show in the report design. b. Optionally apply a calculation to any selected field, for example, count. c. Select the order. This equals the ORDER BY statement in SQL. d. Select the grouping. This equals the GROUP BY statement in SQL. e. Select the format from the output drop down list, for example, PDF, HTML, CSV. f. Selecting a Drill Down Field enables the option to click the selected field in the report result. The field then provides a link to the object information page. g. Click Next. 4. The Report Summary dialog is displayed. a. You can modify and verify the SQL statement of the report.
78
b. Click Verify to make sure the report runs successfully and returns a result. c. Select Now to save and run the report immediately, schedule a time to run, or select Save without Running. d. Click Finish. Table 4-1 shows a selection of available views from the report constraints page, and how they relate to the actual views and column names in the database.
Table 4-1 Available report views View name and description access group: all The access groups associated to a user. Database view accessgroup_cus_view Column name END_USER_ID NAME IS_SUPERUSER INSTANCE_ACCESS_ROLE_ID ACCESS_DOMAIN_ID ACCESS_GROUP ACCESS_GROUP_DESCRIPTION SYSTEM_ID USERNAME INSTALL_TIME TYPE RESOURCE_ID OPERATION MANAGED_SYSTEM_ID USERNAME INSTALL_TIME SOFTWARE_MODULE_ID INSTALL_STATE SERVER_ID AGENT_UNIQUE_NAME DESCRIPTION LAST_CONTACT_TS LAST_ATTEMPT_TS AGENT_START_TS LAST_BOOT_TS LAST_ERROR_MSG_TS LAST_ERROR_MSG LAST_REPORT_TS
base_audit: all Changes to software or hardware on computers.
base_audit_view
base_deployment: all Identifies the software that has changed on computers. endpoints: all Tivoli Common Agent status information.
base_deployment_view
endpoint_inv_view
79
View name and description hardware inventory: all Details about the hardware on computers.
Database view hardware_inventory_view
Column name SYSTEM_ID TYPE RESOURCE_NAME RESOURCE_ID GROUP_NAME MANAGED PARTITIONABLE PROPERTY PROPERTY_VALUE SYSTEM_ID TYPE RESOURCE_NAME RESOURCE_ID GROUP_NAME MANAGED PARTITIONABLE PROPERTY PROPERTY_VALUE USERNAME SUCCESSFULL_LOGIN ENTRY_POINT TIME_OF_LOGIN MANAGED_SYSTEM_ID MODULE_ID OS_NAME OS_VERSION RESOURCE_ID MODULE_ID SYSTEM_ID IS_PENDING CURRENT_STATE DESIRED_STATE MODULE_ID SOFTWARE VENDOR VERSION DESCRIPTION TYPE
hardware inventory: all Details about the hardware on computers. login history: all Tracks login history. os: all Information about operating systems. software instance: all The software that is installed on computers, without details.
hardware_inventory_view
login_aud_view
os_info_view
instance_on_sys_base_view
software: all The available software in software catalog.
software_info_view
80
View name and description software_computer: all Detailed information about the software on computers.
Database view software_server_view
Column name SOFTWARE VERSION SERVER_NAME OS_NAME OS_VERSION POOL TIER CUSTOMER_NAME APPLICATION_NAME STATE MODULE_ID SERVER_ID TYPE DESCRIPTION CURRENT_STATE DESIRED_STATE MANAGED_SYSTEM_ID USERNAME INSTALL_TIME MODULE_ID INSTALL_STATE SOFTWARE VENDOR VERSION DESCRIPTION
software history: all Changes made to software on computers.
software_aud_view
4.7 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. An automation package has a .tcdriver extension and is centrally stored on the Tivoli Provisioning Manager server in the $TIO_HOME/drivers directory of a UNIX server and the %TIO_HOME%\drivers directory of a Windows server.
4.7.1 Install an automation package

An automation package must be installed in order to make it available to Tivoli Provisioning Manager. You can manually install automation packages or you can configure your development environment to dynamically install automation packages as they are required.
81
You can manually install an automation package from the command line interface. In the $TIO_HOME/tools directory, use the tc-driver-manager.cmd on Windows server and tc-driver-manager.sh on UNIX/Linux server. Perform the following steps to install the rembo automation package on a Tivoli Provisioning Manager for Software server on a Windows platform: 1. Copy the rembo.tcdriver file to the %TIO_HOME%\driver directory. 2. Open a Cygwin shell. 3. Execute the $TIO_HOME/tools/tc-driver-manager.cmd i rembo or $TIO_HOME/tools/tc-driver-manager.cmd installDriver rembo command. You can verify the successful installation with the tc-driver-manager.cmd l or tc-driver-manager.cmd listAllStr command. Example 4-1 shows the output from the command on a Tivoli Provisioning Manager for Software server.
Example 4-1 Command listing automation packages
tc-driver-manager.cmd l TC Driver Name ============== ... rembo ... Version Status ================= ============= 5.1.0.0.1918.41.12 installed
The rembo automation package is provided with the Tivoli Provisioning Manager for OS deployment Component. The Rembo Toolkit is described in 6.8, Imaging on page 152. Note: Tivoli Provisioning Manager already includes the Rembo automation package.
4.7.2 Updating an automation package

You must uninstall an existing automation package, before installing a newer version of the same automation package, or use the forceInstallDriver option for the installation, for example: tc-driver-manager.cmd fid rembo
82
The tc-driver-manager.cmd command has also the following options: forceInstallDriver | fid: Uninstalls and reinstalls the automation package. forceUnInstallDriver | fud: Uninstalls the automation package. getDescription | desc: Retrieves automation package description. getDriverStatus | stat: Shows automation package status. installDriver | i: Installs a new automation package. installNoItems | ini: Installs the automation package on the command line without creating workflows described in the Items section of the driver manifest. listAllStr | l: Lists all currently installed drivers. listDeviceModels | ld: Lists all device models. listInstalledDeviceModels | lid: Lists all installed device models. uninstallAllDrivers | ua: Uninstalls all automation packages. uninstallDriver | u: Uninstalls the specified automation package.
4.7.3 Creating an automation package

You need the Automation Package Developer Environment (APDE) to create or modify automation packages. The APDE is an Eclipse base graphical interface. Before creating a new automation package, create a new automation package project by performing the following steps: 1. Start Eclipse. 2. In the Eclipse menu, click Window Open Perspective Automation Package. 3. In the Eclipse menu, click File New Project. 4. In the dialog window, select Automation Package Automation package project and click Next. 5. Enter a Project Name (no whitespaces) and click Next. 6. Select any automation packages that contain workflows or other resources that your new automation package requires. If you need to add dependencies later, you can update the project tc-driver.xml file after the automation project package is created. 7. Click Finish.
83
Package Explorer view shows the following files and folders that are stored in the automation package project folder: src contains any script files that are run on the deployment engine device. They are not copied to the device. doc contains general documentation for using the automation package in HTML format. When you create a new automation package, a new documentation file is automatically created with the name of the automation package. For example, if the automation package is called MyPackage, the documentation file is called MyPackage.html. META-INF with the manifest file that defines the OSGi bundle. An automation package is configured as an OSGi bundle. repository contains scripts that are copied to the target computer and run on the computer. TC-INF contains the manifest file for the automation packages, the file is always called tc-driver.xml. workflow contains a collection of workflows that have been developed to operate the device associated with this automation package. xml contains XML that the automation package uses to add or change information in the data center model. build.xml file is used to package the contents of the automation package into a single .tcdriver file.
4.7.4 Creating a workflow

Workflows contain steps and actions that the Tivoli Provisioning Manager server performs. You can create new workflows in the Web interface by selecting Automation Workflows or use the APDE. In the APDE, create a project before creating a workflow. In the workflow editor in APDE, you can use the content assist while writing commands. Press Ctrl-Shift to get a list of possible commands or options, for example type DCMQuery(/ and press Ctrl-Shift to get all objects in the data center model. However, you cannot modify predefined workflows that comes with the product, you need to make a copy first. When using the Web interface, you just need to rename an existing workflow and compile it in order to copy the workflow. The following example shows a workflow that deletes the selected target device from the data center model. When set as favorite task, this workflow deletes one or multiple computers. The target computers are specified when running the workflow.
84
Example 4-2 Workflow deletes target deviceID from data center model
workflow ComputerDelete (in DeviceID) LocaleInsensitive var idname = DCMQuery(/Server[@id=$DeviceID]/@name) log debug "Deleting computer " + idname DCMDelete(/Server[@id=$DeviceID]/)
4.8 Software Package Editor

The Eclipse based Software Package Editor is integrated to the Automation Package Developer Environment (APDE). 1. Run the eclipseLaucher.bat from the eclipse directory. 2. From the Eclipse interface, select Window Show View Other. 3. Select Software Package Editor as show in Figure 4-7. 4. Click OK.
Figure 4-7 Open Software Package Editor in Eclipse
In order to open and save a software package from a file repository on the Tivoli Provisioning Manager server, you must specify the connection settings. 1. From the Eclipse interface select Window Preferences.
85
2. Select Software Package Editor. 3. Enter the settings as shown in Figure 4-8. The host name, port, user name, and password settings are the same used to log in to the Web interface https://hostname:port/tcWebUI. Make sure to select Use SSL.
Figure 4-8 Software Package Editor settings
Import the certificate from the Tivoli Provisioning Manager server by performing the following steps: 1. Open a Web browser and navigate to the login page as described in Accessing the console on page 118. 2. When the digital certificate shown in Figure 6-1 on page 118 appears, click View Certificate. 3. In the Details tab, click Copy to File. 4. Click Next in the certificate export wizard. 5. Leave the format DER encoded binary X.509 (.cer) and click Next. 6. Enter a path and filename, for example, C:\temp\tpmsrv.cer, and click Next. 7. Click Finish. Open a command line prompt and change to the java location in your eclipse directory. Example 4-3 is Eclipse installed in C:\APDE\eclipse and java in C:\APDE\eclipse\java\jre\bin.
86
Example 4-3 Import server certificate to java keystore
cd C:\APDE\eclipse\java\jre\bin keytool -import -v -keystore "..\lib\security\cacerts" -file \temp\tpmsrv.cer -storepass "changeit" -alias helsinki Owner: CN=helsinki.itsc.austin.ibm.com, CN=../agentmanager/eclipse/plugins/Agent Manager, CN=CTGEM, CN=EC105180641A11D9B6B10011099B9740, CN=Agent Manager, DC=itsc, DC=austin, DC=ibm, DC=com Issuer: CN=TivoliAgentManagerCA, DC=itsc, DC=austin, DC=ibm, DC=com Serial number: 3 Valid from: Tue Nov 14 17:34:06 CST 2006 until: Fri Nov 11 17:49:06 CST 2016 Certificate fingerprints: MD5: 39:F5:EA:FF:84:86:41:3B:3A:18:5B:10:BA:F7:49:72 SHA1: FA:10:72:59:0D:34:6E:53:87:71:5D:D9:44:44:16:09:5B:7B:91:2F Trust this certificate? [no]: y Certificate was added to keystore [Saving ..\lib\security\cacerts] After configuring the Software Package Editor preferences as described previously, you can now open software packages from fileserver and save to fileserver. When saving to a fileserver, a dialog window prompts to select which file repository to use as shown in Figure 4-9.
Figure 4-9 Select file repository for software package block
87
88
Chapter 5.
Troubleshooting
This chapter discusses troubleshooting of Tivoli Provisioning Manager V5.1 components and has the following sections: Essentials on page 90 Directory structure on page 91 Log Files on page 93 Workflow troubleshooting on page 100 Agent installation on page 102 Depot issues on page 110 Performance tuning on page 112
89
5.1 Essentials
This section provides information about how to troubleshoot a problem with Tivoli Provisioning Manager, including instructions for searching knowledge bases, downloading fixes, and obtaining support. For detailed problem determination information, refer to the Problem Determination Guide available on the Web at: http://publib.boulder.ibm.com/infocenter/tivihelp/v13r1/topic/com.ibm.t ivoli.tpm.doc/pubs/TPM51ProblemDeterminationGuide.pdf Troubleshooting is the process of finding and eliminating the cause of a problem. Whenever you have a problem with Tivoli Provisioning Manager, the troubleshooting process begins as soon as you ask yourself, what happened? A basic troubleshooting strategy at a high level involves: Recording the symptoms Recreating the problem Eliminating possible causes If you cannot identify the cause of a problem, you might want to seek the assistance of the Tivoli Support team, who will be able to pinpoint the cause of the problem and recommend ways to recover from specific situations.
5.1.1 Recording the symptoms of the problem

Depending on the type of problem you have, whether it be with your application, your server, or your tools, you might receive a message that indicates something is wrong. Always record the error message that you see. As simple as this may sound, error messages often contain codes that make more sense as you investigate your problem further. You might also receive multiple error messages that look similar, but have subtle differences. By recording the details of each one, you can learn more about where the problem exists. Sources of error messages: Web interface Command-line interface Log files Error dialog boxes
5.1.2 Recreating the problem

Think back to what steps you were doing that led you to this problem. Try those steps again to see if you can easily recreate this problem. If you have a
90
consistently repeatable test case, you can have an easier time determining what solutions are necessary. How did you first notice the problem? Did you do anything different that made you notice the problem? Is the process that is causing the problem a new procedure, or has it worked successfully before? If this process worked before, what has changed? The change can refer to any type of change made to the system, ranging from adding new hardware or software, to configuration changes you might have made to existing software. What was the first symptom of this problem that you witnessed? Were there other symptoms occurring around that time? Does the same problem occur elsewhere? Is only one computer system experiencing the problem or are multiple systems experiencing the same problem? What messages are generated that can indicate what the problem is?
5.1.3 Eliminating possible causes

Narrow the scope of your problem by eliminating components that are not causing the problem. By using a process of elimination, you can simplify your problem and avoid wasting time in other areas. Consult the information that comes with the product and other available resources to help you with your elimination process: Has anyone else experienced this problem? Is there a fix you can apply? You can find more information on the Web at: http://www-306.ibm.com/software/sysmgmt/products/support/IBMTivoliProvi sioningManager.html
5.2 Directory structure

To enable yourself to troubleshoot any issue observed with Tivoli Provisioning Manager, you should know the directory structure and where to find what information, file or utility. During installation of Tivoli Provisioning Manager, the tioadmin user is created.
Chapter 5. Troubleshooting
91
On UNIX Tivoli Provisioning Manager server the .TCprofile script (default location is /opt/ibm/tivoli/tpm), used to source the needed variables like $TIO_HOME, is added to .profile of the tioadmin user. So in case you want to use the mentioned path variables you need to log in as tioadmin user or use the su command. On Windows the Tivoli Provisioning Manager environment variables are added to the system variables, for example as %TIO_HOME%. Whenever an environment variable is mentioned in this chapter it will be the UNIX version, hence remember to use the Windows version when you are working on Windows machines. Table 5-1 is an excerpt of the directory structure of Tivoli Provisioning Manager containing the most important directories you should know for troubleshooting purposes:
Table 5-1 Tivoli Provisioning Manager directory structure Directory $TIO_HOME/config $TIO_HOME/repository $TIO_HOME/soapclient $TIO_HOME/xml $TIO_HOME/tioprofile $TIO_HOME/tools $TIO_HOME/drivers Contents Contains all Tivoli Provisioning Manager configuration data entered during installation Local software repository Contains all soap scripts Contains all data center model xml files. xmlimport.dtd defines the format of the xml files to be imported Default location of WebSphere profile created by Tivoli Provisioning Manager Contains utilities used to manage Tivoli Provisioning Manager from CLI Automation package repository. Source location for tc-drivermanager command to install/remove automation packages Contains installation image apde.zip, which contains the Eclipse plugins for APDE and SPE to be installed on dedicated machines Contains eclipse image prepared to use SPE locally on Tivoli Provisioning Manager server Contains the program to uninstall Tivoli Provisioning Manager Default location for self created APDE packages
$TIO_HOME/apde
$TIO_HOME/eclipse $TIO_HOME/_uninst $TIO_HOME/workspace
92
Directory $TIO_HOME/config $TIO_HOME/repository $TIO_HOME/soapclient $TIO_HOME/xml $TIO_HOME/tioprofile $TIO_HOME/tools $TIO_LOGS
Contents Contains all Tivoli Provisioning Manager configuration data entered during installation Local software repository Contains all soap scripts Contains all data center model xml files. xmlimport.dtd defines the format of the xml files to be imported Default location of WebSphere profile created by Tivoli Provisioning Manager Contains utilities used to manage Tivoli Provisioning Manager from CLI Default logfile location
5.3 Log Files

The $TIO_LOGS directory contains separate folders for the subsystems which are part of Tivoli Provisioning Manager. Additionally there are also logfiles which are located outside $TIO_LOGS. These are the logfiles for the prerequisite components. Most important are the WebSphere log files as the WebSphere Application Server (WAS) is central to Tivoli Provisioning Manager and its components. All components, DB2 Universal Database, IBM Tivoli Directory Server, SOAP, user interface, deployment engine, policy engine, command line tools, interact with WAS. If you do not know where to start with a problem that you have encountered, start with WAS logs in: $WAS_PROFILE_HOME/logs/server1 The Table 5-2 is an overview for the directories contain the log files for the matching subsystem.
Table 5-2 Logfile locations Path $TIO_LOGS/ $TIO_LOGS/j2ee Description Common log files WebSphere JVM log files
93
Path $TIO_LOGS/install $TIO_LOGS/deploymentengine $TIO_LOGS/policyengine $TIO_LOGS/tcdrivermanager.log $TIO_LOGS/agentshellserver $TIO:_HOME/../common/ctgde/logs $WAS_PROFILE_HOME/logs/server1
Description Installation logfiles Deployment Engine JVM logfiles Policy Engine JVM logfiles Automationpackage log Agentshellserver log files Distribution log files WebSphere server1 log files containing SystemOut.log, startServer.log, stopServer.log, SystemErr.log
5.3.1 Log file types

Each Tivoli Provisioning Manager JVM directory includes the following log files: console.log Stores all event logs including messages, traces, and debugging information. msg.log Stores the globalized event messages so the user can understand a problem and take action to try and resolve the problem.trace.log stores errors that are reviewed by IBM Tivoli Support. cbe.log Stores all error messages in Common Base Event format.
5.3.2 Subsystem messages

To help you finding the correct log file to a message you may receive, every subsystem has its own set of messages which identifies the type of message and the origin subsystem. The message ID consists of 10 alphanumeric characters where the sequence is COPYYY###Z: COP This is the product identifier representing the current release of the software. YYY
94
This is the subsystem code. Table 5-3 contains all codes and the name of the matching subsystem.
Table 5-3 Subsystem codes Subsystemcode COPCOM COPDEX COPJDS COPJEE COPPEZ COPTCA COPTDM COPUTL Subsystem Common Deployment engine Job distribution service J2EE Policy engine Common agent TCdrivermanager Utilities Logdirectory/Logfile $TIO_LOGS/ $TIO_LOGS/deploymentengine $TIO_LOGS/ $TIO_LOGS/j2ee $TIO_LOGS/policyengine $TIO_LOGS/ $TIO_LOGS/tcdrivermanager.log $TIO_LOGS/
Z This is the severity code indicator, and includes the following indicators: I Information message W Warning message E Error message You can find a complete list of all messages in Chapter 10 of Tivoli Provisioning Manager Problem Determination and Troubleshooting Guide available on the Web at: http://publib.boulder.ibm.com/infocenter/tivihelp/v13r1/topic/com.ibm.t ivoli.tpm.doc/pubs/TPM51ProblemDeterminationGuide.pdf
5.3.3 Setting log level

Log data in Tivoli Provisioning Manager is managed by log4j, an established open source logging tool. You can update the logging level by editing log4j.prop to change the log level. The log4j.prop file defines the default configuration for
95
message, trace, and Common Base Event logs. The log4j.prop file is located in $TIO_HOME/config. After setting the log level in log4j.prop, the changes take effect immediately without any manual intervenience, as the log4j setting are reloaded by the Tivoli Provisioning Manager server 60 seconds after you save the log4j.prop file. Each log file is set to a unique log level for Tivoli Provisioning Manager using the log4j.appender.filename.threshold= parameter. Example 5-1 shows the default log4j.prop file.
Example 5-1 log4j.prop
# output directory. Can be overwritten with -Dkanaha.logs=<directory> # kanaha.logs=logs # message formats # normal used to write to console.log # error used to format error messages (prints location of a problem) # module is meant for messages written module specific files # output.normal=%d{ISO8601} %-5p [%t] (%13F:%L) %c{2}: %m%n output.error=%d{ISO8601} %-5p [%t] (%13F:%L): %m%n output.module=%d{ISO8601} %-5p [%t] (%13F:%L): %m%n # # configure root category # note that this configuration is inherited by all other categories (see # example below if you want to suppress this behaviour) # log4j.rootCategory=DEBUG, consolefile, errorfile, messagefile # everything goes to console.log # rolling by log size. For other rolling options, see see http://logging.apache.org/log4j/docs/api/index.html # log4j.appender.consolefile=org.apache.log4j.RollingFileAppender log4j.appender.consolefile.MaxFileSize=100MB log4j.appender.consolefile.MaxBackupIndex=10 log4j.appender.consolefile.File=${kanaha.logs}/console.log log4j.appender.consolefile.layout=org.apache.log4j.PatternLayout log4j.appender.consolefile.layout.ConversionPattern=${output.normal} log4j.appender.consolefile.threshold=debug log4j.appender.consolefile.append=true
96
# errors to trace log file, for FFDC # rolling by log size # log4j.appender.errorfile=org.apache.log4j.RollingFileAppender log4j.appender.errorfile.MaxFileSize=10MB log4j.appender.errorfile.MaxBackupIndex=10 log4j.appender.errorfile.File=${kanaha.logs}/trace.log log4j.appender.errorfile.layout=org.apache.log4j.PatternLayout log4j.appender.errorfile.layout.ConversionPattern=${output.error} log4j.appender.errorfile.threshold=error log4j.appender.errorfile.append=true # globalized message log to msg.log (user log) # rolling by log size # log4j.appender.messagefile=org.apache.log4j.RollingFileAppender log4j.appender.messagefile.MaxFileSize=10MB log4j.appender.messagefile.MaxBackupIndex=10 log4j.appender.messagefile.File=${kanaha.logs}/msg.log log4j.appender.messagefile.layout=org.apache.log4j.PatternLayout log4j.appender.messagefile.layout.ConversionPattern=${output.normal} log4j.appender.messagefile.threshold=MSG_INFO#com.thinkdynamics.kanaha.util.logging.M essageLevel log4j.appender.messagefile.append=true # configure root category # note that this configuration is inherited by all other categories (see # example below if you want to suppress this behaviour) # log4j.rootCategory=DEBUG, consolefile, errorfile, messagefile # everything goes to console.log # rolling by log size. For other rolling options, see see http://logging.apache.org/log4j/docs/api/index.html # log4j.appender.consolefile=org.apache.log4j.RollingFileAppender log4j.appender.consolefile.MaxFileSize=100MB log4j.appender.consolefile.MaxBackupIndex=10 log4j.appender.consolefile.File=${kanaha.logs}/console.log log4j.appender.consolefile.layout=org.apache.log4j.PatternLayout log4j.appender.consolefile.layout.ConversionPattern=${output.normal} log4j.appender.consolefile.threshold=debug log4j.appender.consolefile.append=true
97
# errors to trace log file, for FFDC # rolling by log size # log4j.appender.errorfile=org.apache.log4j.RollingFileAppender log4j.appender.errorfile.MaxFileSize=10MB log4j.appender.errorfile.MaxBackupIndex=10 log4j.appender.errorfile.File=${kanaha.logs}/trace.log log4j.appender.errorfile.layout=org.apache.log4j.PatternLayout log4j.appender.errorfile.layout.ConversionPattern=${output.error} log4j.appender.errorfile.threshold=error log4j.appender.errorfile.append=true # globalized message log to msg.log (user log) # rolling by log size # log4j.appender.messagefile=org.apache.log4j.RollingFileAppender log4j.appender.messagefile.MaxFileSize=10MB log4j.appender.messagefile.MaxBackupIndex=10 log4j.appender.messagefile.File=${kanaha.logs}/msg.log log4j.appender.messagefile.layout=org.apache.log4j.PatternLayout log4j.appender.messagefile.layout.ConversionPattern=${output.normal} log4j.appender.messagefile.threshold=MSG_INFO#com.thinkdynamics.kanaha.util.logging.M essageLevel log4j.appender.messagefile.append=true # suppress annoying messages from datacentermodel # log4j.category.com.thinkdynamics.kanaha.datacentermodel=INFO # suppress annoying messages from dataacquisition # log4j.category.com.thinkdynamics.kanaha.dataacquisitionengine=INFO # suppress annoying messages from org.apache # log4j.category.org.apache=INFO # write heart beat messages to heartbeat.log only (not to console.log) # log4j.category.com.thinkdynamics.kanaha.util.heartbeat=DEBUG, heartbeat log4j.appender.heartbeat=org.apache.log4j.RollingFileAppender log4j.appender.heartbeat.MaxFileSize=100KB log4j.appender.heartbeat.File=${kanaha.logs}/heartbeat.log log4j.appender.heartbeat.layout=org.apache.log4j.PatternLayout log4j.appender.heartbeat.layout.ConversionPattern=${output.normal}
98
log4j.appender.heartbeat.append=false log4j.additivity.com.thinkdynamics.kanaha.util.heartbeat=false # CBEs # all categories and levels in CBE format (by redirection done in TIOLogger customized logger class) log4j.category.com.thinkdynamics.kanaha.util.logging.cbe.logger=ERROR, cbe log4j.appender.cbe=org.apache.log4j.RollingFileAppender log4j.appender.cbe.MaxFileSize=10MB log4j.appender.cbe.MaxBackupIndex=10 log4j.appender.cbe.File=${kanaha.logs}/cbe.log log4j.appender.cbe.layout=org.apache.log4j.PatternLayout log4j.appender.cbe.append=false log4j.renderer.org.eclipse.hyades.logging.events.cbe.CommonBaseEvent=com.thinkdynamic s.kanaha.util.logging.cbe.CBERenderer log4j.additivity.com.thinkdynamics.kanaha.util.logging.cbe.logger=false You can change following parameters separately for console-, message-, cbe-, error- and heartbeat log file: MaxFileSize Maximum size for the logfile. When the logfile is reached it will be indexed by a adding a continuous number and a new is created MaxBackupIndex Maximum number of backup files to be kept until they are removed, default is 10. File The name of the logfile layout Pattern layout class used for the logfile Threshold This is the log level. The valid values are: DEBUG ERROR INFO WARN
You can find more details on the home page of the log4j apache project on the Web at: http://logging.apache.org/log4j/docs/index.html
99
5.4 Workflow troubleshooting

All deployment engine runtime results are logged to the $TIO_LOGS/logs/deploymentengine/console.log file. If you are looking for additional details to help determine why a particular transition within a workflow has failed, review this log file first.
5.4.1 Setting log level

The standard functionality of Tivoli Provisioning Manager is to suppress stack trace Java exception error messages within the user interface, and the actual commands that have been run and issued by the deployment engine at each transition. It is important that you understand exactly which commands are being issued by the deployment engine at runtime (for debug purposes), and to achieve this, you must enable debug mode in two places: The log4j.prop file within $TIO_HOME/config/log4j.prop should have lines that read: log4j.appender.errorfile.threshold=debug log4j.appender.consolefile.threshold=debug Alternatively, in the absence of either of these two lines, the file should contain a single line that reads: log4j.rootCategory=DEBUG, consolefile, errorfile This line sets the console file and error file thresholds to debug if their specific threshold is not set. Note: Described above is the default functionality. Debug mode is enabled for console.log files for a standard installation. By only configuring the log4j settings, debug mode (default) will still suppress stack trace error messages from the error window within the Tivoli Provisioning Manager user interface when you run workflows, but will not log actual commands issued by the deployment engine. To enable this level of logging, you must define a global variable by performing the following steps: a. Select System Management Global Settings and select the Variables tab. b. Name the variable debug, with a component of Deployment Engine, and a value of true. This will enable full debug mode when you run workflows for both the Tivoli Provisioning Manager user interface and the log file.
100
Note: When you add this variable, the change takes effect immediately for each instance that a workflow is run.
5.4.2 Workflow execution logs

For all errors that occur when you run your workflow, check the run history by performing the following steps: 1. After you run a workflow, the Workflow Status page is displayed. Click the request ID of that workflow. The Workflow Execution Logs page is displayed. Note: SOA operation will have no request ID so it is not possible to perform this step. 2. Select Actions Error. The error page is displayed. You can use the displayed error code for further analysis. In case you have to remove a workflow log, follow these steps: 1. Navigate to Automation Workflow status. 2. Select the workflow log matching your Request ID and select the properties button at the right end of the record. 3. In the dialog that appears, select Delete. 4. Confirm the deletion by pressing OK. Note: You can only remove workflow logs of completed workflows, in case the workflow status is in-progress the Delete option is not available. If your workflow does not complete, you need to stop it manually, you can do this in the following order: 1. Navigate to Automation Workflow status. 2. Click the request ID matching the hanging workflow.
101
3. In the Status section of the workflow view that appears, select the button near the in-progress message as shown in Figure 5-1.
Figure 5-1 Stop workflow
4. Select Stop Execution.
5.5 Agent installation

In this section, we will discuss the most common reasons for issues with the Tivoli common agent installation. To start the debugging of a failing installation attempt you should check the regarding workflow log as described in Workflow execution logs on page 101 and perform the following steps: 1. Select Automation Workflow Status or Task Management Track Task from the Tivoli Provisioning Manager Web user interface (UI). 2. Select the matching request ID to open the workflow log. Tip: Choose the suitable log level of your purpose by checking or unchecking the check boxes for Debug | Info | Warning | Error.
102
3. Locate the failing step and select the magnify symbol to get the dialog box shown in Figure 5-2.
Figure 5-2 Workflow log details
4. If you do not get any details there, select the properties button in the Status section of the workflow view direct right from the failed status. 5. In the appearing dialog box, select Error. 6. Use the shown error code for problem determination and further debugging.
5.5.1 Time drift

The agent installation verifies the time settings on the target box before starting to copy the installation images. In case the system time differs for more that two hours from the time on the Tivoli Provisioning Manager server the installation will abort.
103
This can be verified in the workflow log as described earlier, so you will get view as shown in Figure 5-3.
Figure 5-3 Workflow log timedrift
Example 5-2 shows the error message for this scenario.

Example 5-2 TImedrift error
ERROR CODE: COPDEX123EworkflowThrownException ERROR MESSAGE: COPDEX123E The workflow threw a CheckTimeWindowException exception. The message is Cannot Install Agent if clocks are not within 2 hours. Click to collapseERROR DETAIL:
TCA_CheckTimeWindow(line:25, column:5) Install_Agent(line:33, column:5) com.ibm.tivoli.orchestrator.de.engine.WorkflowThrownException: COPDEX123E The workflow threw a CheckTimeWindowException exception. The message is Cannot Install Agent if clocks are not within 2 hours. If you see this error, please make sure the time settings on target system and Tivoli Provisioning Manager server match.
104
5.5.2 RXA problems

Target systems are accessed using RXA (Tivoli Remote Execution and Access) protocol. The following Windows system settings are required for RXA: The target endpoints must have remote registry administration enabled. 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) must be enabled on the endpoints, to ensure successful communication through RXA. On UNIX systems SSH deamon must be configured and running. Example 5-3 shows the typical error message displayed when one of these requirements are not met.
Example 5-3 Failing RXA access
ERROR CODE: COPCOM494ErxaCannotConnectToEndpoint ERROR MESSAGE: COPCOM494E Cannot connect to the endpoint using RXA. Click to collapseERROR DETAIL:
RXA_Execute_Command(line:25, column:10) ServiceAccessPoint.ExecuteCommand(line:29, column:3) Default_Device_Execute_Command(line:26, column:9) Device.ExecuteCommand(line:29, column:3) TCA_GetTime(line:25, column:5) TCA_CheckTimeWindow(line:14, column:2) Install_Agent(line:33, column:5) com.ibm.tivoli.orchestrator.rxa.exception.RXAException: COPCOM494E Cannot connect to the endpoint using RXA.
If you see this error code make sure the requirements are fulfilled. A typical reason for missing those requirements is if the Microsoft firewall service coming with Windows XP Servicepack 2 is enabled and blocking ports. So make
105
sure the Windows firewall is disabled or allows access to the PRC and NetBIOS port. To verify if remote registry is enabled, verify if the service is running in the service manager or run net start from any Windows command window. If remote registry is not running, start it using net start remote registry. To verify if Simple File Sharing is disabled, select Start Settings Control Panel Folder Options View as shown in Figure 5-4.
Figure 5-4 Disable simple file sharing
On UNIX systems, verify that SSH connection is possible by establishing a connection from Tivoli Provisioning Manager server to the target system using the ssh command and the credentials used for the Install Agent task.
5.5.3 Service access point (SAP) problems

For every computer to be accessed by Tivoli Provisioning Manager a service access point (SAP) is defined. This definition can be found in the credentials
106
view of the computer. If this SAP definition is missing, the installation of the Tivoli common agent on this computer will fail with the message displayed in Example 5-4.
Example 5-4 Missing SAP definition
ERROR CODE: COPTDM017EcannotFindDefaultProtocolEndPoint ERROR MESSAGE: COPTDM017E The system cannot find the default protocol endpoint for device ID "7716", operation "execute-command". Click to collapseERROR DETAIL:
Get_Default_SAP_For_Operation(line:13, column:8) Default_Device_Execute_Command(line:25, column:9) Device.ExecuteCommand(line:29, column:3) TCA_GetTime(line:25, column:5) TCA_CheckTimeWindow(line:14, column:2) Install_Agent(line:33, column:5) If you observe this message while debugging the Tivoli common agent installation workflow, verify the service access point definitions for the target computer in the credentials view. Valid service access point definitions for computers are: RXA Server for Windows SSH Server for UNIX/Linux
107
Figure 5-5 is shows a valid service access point definition for a Windows computer.
Figure 5-5 SAP definition
If the service access point definition is missing or wrong, you can add it by selecting Edit Add Service Access Point. In case of a non-Windows target system which was discovered using SSH, you have to provide the credentials separately for the installation as no default SAP is created. To provide this information, select the Credentials check box below the computer or group list in the install Tivoli common agent dialog box and provide the user name and password as to be seen in Figure 5-6.
Figure 5-6 Tivoli common agent install credentials
108
This will cause a new SAP call RXA-Bootstrap-Server to be created for this computer as documented in Figure 5-7.
Figure 5-7 RXA credentials for UNIX Tivoli common agent installation
Without this additional SAP the Install_Agent workflow will not start and following message will be displayed: COPJEE420W The Computer "ankara.itsc.austin.ibm.com" has no Service Access Point defined.
5.5.4 Communication issues

In RXA problems on page 105 is already mentioned that port 135 and 139 need to be open for Windows computers to install Tivoli common agent. Table 5-4 contains all ports that need to be opened between Tivoli common agent and Tivoli Provisioning Manager server. Use this reference for configuring the firewall in your environment. For the installation itself ports 9511, 9512 and 9513 are required.
Table 5-4 Tivoli common agent port requirements Port 2100 Use Enables communication between: The common agent and the Content Delivery Service depot servers Content Delivery Service depot servers The Content Delivery Service management center and the Content Delivery Service depot servers
109
Port 9010 or 9015 9510 9514 or 9515
Use Enable communication between the common agent and the content delivery service management center. The default common agent listening port. Nonstop. The Nonstop agent service monitors processes on the agent, to make sure they are running and available. The service automatically restarts the processes it monitors if they stop. Registering agents and resource managers Providing configuration updates Renewing and revoking certificates Querying the registry for agent information Requesting ID resets Requesting updates to the certificate revocation list Requesting agent manager information Downloading the truststore file Agent recovery service
9511 9512
9513
To successfully install the common agent on target endpoints, you must also ensure that ports 80 (WebContainerPort) and 443 (WebContainerSSLPort) are free on the endpoints. If the common agent installation is attempted on an endpoint that already uses ports 80 or 443, the common agent installation will fail. For more information, refer to the preinstall.log file located in the $LWI_DIR/ep/runtime/agent/logs directory. The Tivoli common agent listens on those ports as configured in config.properties on the Tivoli common agent in the $LWI_DIR/config subdirectory: com.ibm.osg.webcontainer.port=80 com.ibm.osg.webcontainer.port.secure=443 A working DNS name resolution between target machine and agent manager is also required for a successful Tivoli common agent installation. This includes full qualified domain names.
5.6 Depot issues

When a distribution fails, you should first verify if the depot is active and its configuration, for example, has enough space free in depot directory for the package.
110
This can be done by selecting Inventory Infrastructure Management Depots. The record of the depot will show either active or inactive, in case it is inactive make sure that the Tivoli common agent is running on the depot server. Alternatively you can try to connect the depot directly using telnet: telnet <depot-server-hostname> 2100 syst Here, <depot-server-hostname> is the FQDN of the computer hosting the depot 2100 is the default depot listening port. A properly working depot will answer in the following way: DS:<depot-server-hostname>=1.3.0.0 To verify the depot configuration, you need to select the properties button and the end of the depot record and select Properties from the context menu that appears. In case the depot is working correctly, make sure the Tivoli common agent is running on the target box. For this purpose you can use the agentcli cmd locally on the agent as described in Installing Tivoli Common Agent on page 132. If you verified that the Tivoli common agent is running on depot and target you should examine the CDS logs which are located on the Tivoli Provisioning Manager server under $TIO_HOME/../common/ctgde/logs. The log level for the CDS logfiles can be adjusted in the $TIO_HOME/CDS/logprop/cdsLog.properties file. In this file you can set the debug level to one of the following levels: ERROR Only error messages are logged. No tracing is logged. WARN Only warning and error messages are logged. No tracing is logged. INFO All messages (informational, warning and error) are logged. No tracing is logged. DEBUG_MIN
111
All messages are logged. Minimal tracing information is logged. DEBUG_MID All messages are logged. Moderate tracing information is logged. DEBUG_MAX All messages are logged. All tracing information is logged. The debug level can be set for each of the following CDS component separately: DownloadGrid DownloadGridSecurity Distribution Agent Monitor Agent P2P Server Client Admin GUI logger Client P2P Depot Server
5.7 Performance tuning

This section is an excerpt of possible performance issues occurring with Tivoli Provisioning Manager 5.1 and recommendations to solve them.
5.7.1 Configuring maximum number of concurrent jobs

The concurrency level determines the number of parallel deployments that are permitted within a task. You can adjust the concurrency level to optimize deployments in your environment. Many tasks, such as patch installation, can perform deployments on multiple targets. A single task can combine more than one workflow to perform a series of actions on specified targets. For example, instead of installing a patch on individual computers, you can run the Install Patch wizard to apply a patch to a group of computers. If you are creating a task to install a patch on 50 computers, and the concurrency level is set to 5, Tivoli Provisioning Manager performs five installations at a time. By default, the concurrency level is set to 1. Modify this setting if you want to run a job concurrently on multiple targets. The appropriate concurrency setting depends on:
112
The type of tasks you are performing. For example, installing a software stack on multiple targets takes more processing resources than changing a password. The processing capabilities of the provisioning server and target devices. If the concurrency level is set too high for your environment, performance will be slow. For example, the recommended concurrency level for patch management is between 5 and 10. To configure the concurrency level: 1. 2. 3. 4. 5. In the navigation pane, expand System Management. Select Global Settings. The Configuration tab is displayed. Select the Variables tab. Locate the default concurrency level row. Select Actions Properties. Change the value and then select Save.
All new tasks will use the specified value. Note: You can also set the default value in the default.xml which is located in $TIO_installdir\xml. You will have to reset the defaults if you re-initialize the data center. Workflows for jobs that can run concurrently should be designed to lock and release resources.
5.7.2 Workflow performance

If you need to execute multiple commands on a target server from a workflow, you can improve the performance of this workflow significantly when using a scriptlet instead of spawning every command separately. This is done using the scriptlet keyword which includes the following: Syntax scriptlet parameters language=script_language target=script_target credentials key=cred_key <<delimiter script_text delimiter Parameter Input parameters for the scriptlet, separated by commas. language Specifies the language of the script. script-language
113
The language of the script could be: bash perl expect vbscript
target Specifies the target of the script. script_target The ID of the target of the script. You can use a variable or a data center model query to specify the target. credentialskey Specifies the credentials key for the target computer. cred_key The credentials key that you use for running commands on the target computer. delimiter The script delimiter. The typical script delimiter is <<EOF. script_text The text of the script. The following keywords are supported within the script: TIOsetVAR variable value: Sets a workflow variable from a scriptlet, where variable is the name of the variable and value is the value of the variable in quotation marks. TIOlog levelmessage: Logs information to the workflow log where level is the log level and message is the message to add to the log in quotation marks. TIOthrow variablemessage: Throws an exception from the scriptlet, where variable is the variable to represent the exception and message is the error message in quotation marks.
5.7.3 Software Package Editor

If you experience performance problems when using the Software Package Editor, verify the following conditions: Enabling host access Before launching the Software Package Editor on a UNIX system, enable host access to the X server by entering the xhost + command.
114
Different domains If the Software Package Editor is on a managed node that is installed on a network domain different from the Tivoli management region domain, to start the Software Package Editor, specify the domain where the managed node resides, on the Tivoli management region. To specify a new domain on a UNIX Tivoli management region, add an entry to the /etc/resolv.conf file. To specify a new domain on a Windows Tivoli Management region, add the required DNS to the DNS list for the TCP/IP settings. Accessing remote drives Performance of the Software Package Editor can be degraded if remote drives that were not accessible when the Software Package Editor was launched have since been mapped to the machine. Large software packages Any operation launched from the Software Package Editor hangs if the software package being processed is too large. To correct the problem, tune the mx256m value in the eclipse.ini file. Increase the value gradually by small increments until you find the optimal value for your environment. For example, replace mx256m with mx384m and then continue to increase this value until the machine performance improves as shown in Example 5-5.
Example 5-5 eclipse.ini
default eclipse.ini: -vmargs -Xms40m -Xmx256m modified eclipse.ini -vmargs -Xms40m -Xmx384m
115
116
Chapter 6.
Administration
This chapter discusses the administration of Tivoli Provisioning Manager V5.1 and has the following sections: Accessing the console on page 118 Managing security on page 119 Network discovery and agent distribution on page 127 Software Package Editor on page 133 Compliance management on page 139 Software Management on page 143 Virtual servers on page 146 Imaging on page 152 Software distribution and installation on page 162 Web services on page 164 Using Automation Package Development Environment on page 167
117
6.1 Accessing the console

To access the console perform the following steps: 1. Open a Web browser and enter the Web address of the Tivoli Provisioning Manager V5.1 application: https://hostname:port/tcWebUI/ For example: https://helsinki:9045/tcWebUI/ 2. Accept the digital certificate as shown in Figure 6-1.
Figure 6-1 Digital certificate
A login page similar to Figure 6-2 is displayed.
118
3. Log in with a valid user ID and password. During a FastStart installation on Windows a default user tioadmin is created with a password specified at installation time. The Full Enterprise installation has the default user tioappadmin.
Figure 6-2 Login screen
The language displayed in the Web interface depends on the language preference set in the browser options.
6.2 Managing security

The security concept of Tivoli Provisioning Manager is part of the data center model. Security information such as user group and role definitions, are stored in a Lightweight Directory Access Protocol (LDAP) database, which is maintained by the Tivoli Directory Server delivered with Tivoli Provisioning Manager. The following describes the steps to be followed in order to work with the security concepts of Tivoli Provisioning Manager. For details about the security connect and how it works please see chapter Security model on page 190.
Chapter 6. Administration
119
6.2.1 Creating a security role

Tivoli Provisioning Manager comes with a number of predefined security roles. You can assign the following predefined security roles to your users: System Administrator Inventory Specialist Software Operator Change Approver Service Subscriber Storage Administrator Network Administrator Software Package Creator Automation Package Developer These roles are sets of predefined permissions. The aim of the security role concept is to limit the access to a specific data center model to a set of users. Basically, these permissions control who can see what, who can run what action on what object. To create your own security roles, perform the following steps: 1. In the navigation pane, expand System Management. 2. Click Manage Security Security Roles. 3. Click Edit Add Role to open the dialog in Figure 6-3.
Figure 6-3 Add a new security role
4. Fill in the required fields, which are marked with an asterisk.
120
5. From the Available Permissions box, select the permissions you wish to include in the new role and add them to the Assigned Permissions box. 6. Click Save to quit this dialog and create the security role.
6.2.2 Creating an access group

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 that group. You can also nest access groups. To create an access group perform the following steps: 1. In the navigation pane, expand System Management. 2. Click Manage Security Access Groups. 3. Click Edit Add Access Group to open the dialog in Figure 6-4.
Figure 6-4 Add new access group
4. Type the name and description of this new access group. 5. Click Save to create the access group and close this dialog. Note: If you wish to create a nested group you must select a Parent Group other than -none-.
6.2.3 Creating a permission group

A permission group identifies a set of related resources and specifies the access privilege that applies to individual objects. It authorizes a group of users to perform particular actions on a group of Tivoli Provisioning Manager resources. After creating an access group, you must add the permissions that are allowed for that group.
121
To create a new permission group complete the following steps: 1. In the navigation pane, expand System Management Manage Security Permission Group. 2. Click Edit Add Permission Group to open the dialog shown in Figure 6-5.
Figure 6-5 Add new permission group
3. Enter the Name and Description of this new group. 4. Select the permissions in the Available Permissions box, and click Add. These permissions will now appear in the Assigned Permissions box. 5. Click Save to close the dialog and create the permission group.
6.2.4 Associate objects to an access group

Adding data center objects which must be protected by an access group, is done on the data center object itself. Examples of objects belonging to access groups are: Computers Software groups Software definitions Nested access groups Here is an example for a Software Definition: 1. Type the name of the object in the search bar of the Tivoli Provisioning Manager Web console.
122
Note: The find tool provides you with the matching name in the result list, and also with a symbol pointing to the object type so that you can distinguish between, for example a Software Product and a Software Definition with identical names. 2. From the search list, select the item which matches the object you want to manipulate. 3. Click the Edit button to open the context menu and select Add to access group.... . This will open a dialog box where you can select all the existing access groups. 4. Click Save to add the object and close the dialog. Note: To remove the object, expand System Management Manage Security Access Groups, select the affected group to open it, and open the context menu of the object in question by selecting the Properties button and clicking Remove.
6.2.5 Adding a new user

It is recommended that all users working with Tivoli Provisioning Manager have their own unique user ID. To add a new user complete the following steps: 1. Log on to the Tivoli Provisioning Manager Web console with a user ID that has been assigned the system administrator role. By default this role is assigned to the tioappadmin user which is created during installation.
123
2. Select System Management Manage User Edit addUser to display the new user dialog shown in Figure 6-6.
Figure 6-6 New user
3. In the dialog box: Fill in the mandatory fields, which are marked with an asterisk:
1
Given Name Family Name Default Access Group1 Notification Method Notification Language New Password Confirm Password E-Mail Superuser check box Address
Optionally, you can fill in the following fields and check boxes:
For details see Associating access and permission groups to a user on page 126.
124
Telephone numbers - Work - Mobile - Home
Force Password Change on the Next Logon check box
Note: You can change all of these values later by opening the properties dialog box for the concerned user. Select System Management Manage User and right-click the Properties button at the end of the user record. Select Properties or Delete to modify or remove this user. 4. Finally, to create the new user ID click the Save button.
6.2.6 Assigning a security role to a user

When you create a new user, there is no security role assigned to the user by default. If you do not configure the role, then the new user will not be able to have access control within the system, if access control is turned on and the user is not a superuser.
125
To assign a security role to a user perform the following steps: 1. In the navigation pane, expand System Management. 2. Click Manage Users to open the dialog box shown in Figure 6-7.
Figure 6-7 Assign user roles
3. Select the user name to which you want to add a security role. 4. Click Edit Configure Roles. 5. Select the security roles in the Available Roles list and click Add. The selected security roles will now be displayed in the Assigned Roles box. 6. Click Save.
6.2.7 Associating access and permission groups to a user

After a new user is created you must assign access permissions to that user. The user will be performing the operations on the resources associated with the assigned access permissions. To assign an access permission: 1. In the navigation pane, click System Management Manage Users. 2. Select the user to whom you want to assign an access permission. 3. Select Edit Assign Access Permissions. 4. Select an Available Permission and an Available Access Group from the respective boxes. 5. Click Save. The updated access group and access permission group will be displayed in the Access Permissions box.
126
The access permissions have now been assigned to the user. If the user did not previously belong to the access group that the available permissions were associated with, the access group is automatically added to the access permissions of the user.
6.2.8 Enabling access control

Access control can be turned on or off in the system. By default, access control is not enabled. As soon as access control is turned on, only users with the security officer role can change the access control. To enable access control: 1. In the navigation pane, expand System Management Global Settings. 2. Select On in the Access Control list. 3. Click Apply.
6.3 Network discovery and agent distribution

After installing Tivoli Provisioning Manager, your first step must be to discover the network for the devices to be added to your data center. In the Web interface, you will find all inventory discovery scans in the left pane: Inventory Manage Discovery Discovery Configurations. You can run one of the predefined discovery configurations or create a new discovery configuration. The discovery runs either agentless using the SSH or Windows SMB protocols or the SNMP, or agent-based using the Tivoli Provisioning Manager Inventory discovery on targets where the Tivoli common agent is installed. The requirements on target endpoints to run an inventory discovery are the same for software distribution as described in Requirements on target endpoints on page 163. Network discovery will check and automatically find the available hardware information and populate it to the data center for all devices for which you have provided the correct IP and credentials information. To be able to perform certain management tasks with Tivoli Provisioning Manager on the new discovered devices, you must deploy the Tivoli Common Agent on those devices. The following section describes how this is done.
127
Alternatively, if you wish to just add a single computer you can use the Add Computer feature by selecting Inventory Manage Inventory Computers to add the device and install the Tivoli Common Agent in just one step.
6.3.1 Preparing network discovery

There are three protocols supported by Tivoli Provisioning Manager to discover new devices running a network discovery: Secure Shell (SSH) Server Message Block (SMB) Simple network management protocol (SNMP) The first step would be to determine which of the devices you want to discover, can answer requests for which protocol. By default Windows machines can be discovered using SMB in case the SMB protocol ports are not blocked by a firewall. The ssh daemon might be configured and running on UNIX machines in your environment. SNMP will be running on network devices such as routers switches and so on. After you verify which device is speaking which protocol, collect the IP or IP-range and the credentials for it. That is, the user ID and password for SMB/SSH, and the community name/password for SNMP. To provide this information to Tivoli Provisioning Manager perform the following steps: 1. Log on to the Tivoli Provisioning Manager Web console. 2. In the navigation pane, expand Inventory. 3. Select Manage Discovery Discovery Configurations. 4. Select Edit Add Discovery Configuration. 5. Enter a name and description of the discovery configuration. 6. In the Discover list, select Devices. 7. Select the Discovery Method from one of the following options: Discover Computers using SSH Discover Windows Computers using SMB
128
Note: Ensure that Microsoft File and Print Sharing for Microsoft Networks is enabled for the ports to be activated. Discover Network Devices using SNMP 8. Click Next. 9. Fill in any necessary discovery parameters and their values such as: IP Address ranges Subnetworks Credentials Important: If credentials are required as discovery parameters, ensure that the proper credentials such as user IDs and passwords are specified properly, so that connections with target systems and lockouts with security policies an enterprise may have in place are avoided. In addition, ensure that the credentials that you provide in Tivoli Provisioning Manager are kept up-to-date as credentials change on the target system in an enterprise that the discovery method is trying to manage. 10.Click Finish to save this operation. A dialog will appear asking for confirmation. Click OK. The page will refresh and an information dialog will indicate the newly created task. Click the task name to view its status.
Creating an inventory discovery scan

Perform the following steps in the Discovery Configurations section in order to create an Tivoli Provisioning Manager Inventory discovery: 1. Click Edit Add Discovery Configuration. 2. In the dialog, enter a name and description for the discovery. Choose one of the options: Device, Software or Other. For example, select the Device option, and from the drop down menu select Tivoli Provision Manager Inventory Discovery to run a full scan using the CIT scanner on systems with the Tivoli Common Agent installed. 3. The next page shows the Discovery Parameters. For the Tivoli Provisioning Manager Inventory Discovery select Hardware, Software or both. For the Software scan you can select one of the three options: Use the registry. Use the software signatures. Use selected signatures.
129
6.3.2 Discovery policy

A discovery policy defines what actions Tivoli Provisioning Manager takes when new devices are detected, a device is changed, or when a device is removed from the network. These configuration changes can be detected for software or hardware and either manual processes or automated policies can be used to respond to a deviation. You can create a discovery policy to either update the data center model directly or create configuration change records for new, changed, or deleted devices. The same discovery policy can be configured to update the data center model directly. Configuration changes are useful for testing the data center model resource changes for using a discovery configuration. When the system is in production, it is recommended to change the discovery policy for all discovery object types to be Update Device. You can define a different discovery policy for each device type that a discovery configuration supports. In addition, you can define a different set of policies for each discovery configuration and discovery library adapter. There are two kinds of actions that can be chosen on discovery policies: Updating the data center model This method automatically updates the data center model with the discovered data while adding or replacing previously existing values with newly discovered ones. You are not able to review the configuration changes prior to the data center model being updated. Creating a change record This method requires manual intervention to process. It allows you the options to view changed records prior to the data center model being updated and then can decide whether they want to apply the configuration changes. A discovery policy is automatically assigned to a device type within a discovery configuration. A device is set with the following default policy: Add Policy Add Device. Update Policy Update Device. Delete Policy Track Configuration Change.
130
Perform the following steps to add a discovery policy to the discovery library configuration: By default the discovery library in Tivoli Provisioning Manager uses the IBM Discovery Library Reader Configuration to import new data center models as describes inIBM discovery library reader on page 67. Within this configuration you can add following policy types as discovery policy: Blade chassis admin server Boot server File repository Image Load balancer Software definition Switch Third Party Software Package Perform the following steps: 1. In the navigation pane, expand Inventory. 2. Select Manage Discovery Discovery Configurations. 3. Select Discovery Library Reader for Tivoli Application Dependency Discovery Manager. 4. The dialog shows the following menu tabs: General Parameter Workflows Change Records
5. Select the General tab. 6. .Select the Add button in the Discovery Policy section to open the dialog in Figure 6-8.
Figure 6-8 Discovery policy
131
7. Select Add Device, Update Device and Delete Device for New Policy, Update Policy and Remove Policy respectively. 8. Select Save.
6.3.3 Performing the discovery task

To run the discovery you must perform the following steps: 1. In the navigation pane, expand Inventory. 2. Click Manage Discovery Discovery Configurations. 3. Select the just created Discovery Configuration. 4. Select the properties button at the end of the record. 5. Click Run from the context menu. 6. Click Submit in the Initiate Discovery dialog. 7. In the Track Task dialog which is displayed, you can verify the proceed and result of the scan. 8. After the discovery task is completed select Inventory Manage Inventory Computers to verify if the discovery was successful. Note: This is an appropriate time to make the new discovered device a member of a group and an access group. 9. To do this, select the check box of the new device and expand the Assign Computer to dialog. 10.Select the Group and Access Group from the list at the bottom of the Computers list. 11.Click Proceed.
6.3.4 Installing Tivoli Common Agent

To install Tivoli Common Agent, complete the following steps: 1. Expand Software Management Install Common Agent. 2. Select TCA_Stack from the Select Agent dialog. 3. Select the computer or group depending on whether you want to install on a single computer or to a group of computers. 4. Select the check box of the target computer/group. 5. Click Submit.
132
To verify if the installation was successful you can use the agentcli cmd locally on the Tivoli common agent machine. It is located in $LWI_DIR/runtime/agent and used in the following way: agentcli service_name command In the agentcli cmd: service_name Is the name of the service you want contact. A complete list of all valid services can be obtained by running: agentcli cli list. command The actual command you wish to run against the service specified before. All available commands for a specific service and the usage of it are listed when using agentcli <service-name> help. To verify if the agent is running you can use agentcli connector alive. Another useful option of agentcli is agentcli deployer list bundles. it will show you all installed bundles for this agent. So you can verify not only if the agent is running but also if all necessary bundles are available.
6.4 Software Package Editor

The Software Package Editor is a graphical user interface for creating and modifying software packages. The Software Package Editor can store software packages in the software package block (*.spb) format locally on the workstation or remote in a Tivoli Provisioning Manager file repository. In the previous version with Tivoli Configuration Manager, the software package blocks are stored on the source host. This section shows an example of creating a simple software package that copies an installation file to a target machine and starts the installation. Note: Software package installations must always run unattended without any user interventions on the target.
133
6.4.1 Using the Software Package Editor

The Software Package Editor is launched on a Windows machine from the eclipse directory by running the eclipseLauncher.bat script. Figure 6-9 shows the Software Package Editor welcome screen.
Figure 6-9 Software Package Editor
When creating a new software package, first define the properties by clicking the Properties icon or select Edit Properties from the menu. In the General Package Properties window, enter a name and title for the software package. Optionally, in the Log file window specify a path on the targets, if you want to write a log file for the install operations.
Check disk space action

In a software package, always start with checking disk space on the target. Perform the following steps: 1. You can find the Check disk space icon in the System action tab or by selecting Edit Insert System action Check disk space.
134
2. In the Check Disk Space Properties dialog box shown in Figure 6-10 specify the following settings: In the Caption field, enter a descriptive name. In the Drive field, specify a drive name for Windows targets and a file system for UNIX targets. In the Volume field, specify the value to check for, measured in Byte, KiloByte, MegaByte or GigaByte. 3. Click Add and repeat these steps for as many drives or file systems as necessary.
Figure 6-10 Check Disk Space Properties
During a software package installation, the drive or file system is checked for available space. If the requirement is met, the installation process continues, otherwise it fails, and the distribution reports an error. On UNIX systems, if the specified file system does not exist on the target, the check continues to search backwards in the specified file system until a match is found. If no matching file system is found, the check is performed on the root ( / ) file system.
135
Adding directory object

A software package contains one or more directories and files. Before adding files to a software package, you must define one or more source directories from where the files are copied. Perform the following steps: 1. On the right pane, on the Add object tab, click the Directory icon or select Edit Insert Add object Directory. 2. In the Add Directory Properties dialog box, specify a location for the source on the local workstation and a location for the destination on the targets. If you right double-click in a field, the Variable List Editor opens. Create a new variable or choose an existing variable from the list. Click OK, and the variable is inserted in the previous dialog. The Properties dialog also provides the following options: Replace if existing (default is true) Replace if target is newer (default is false) Remove if modified (default is true) When you click the Advanced button in the Add Directory Properties dialog, a new window opens. The General tab provides, among others, the option Descend directories, that results in adding all files and subdirectories from the source directory to the software package. The Temporary option, if selected, removes the directory from the target machine after the installation. Without the Descend directory option, you must manually add one or more files to the directory. When you double-click the directory on the left pane, the right pane shows the contents of the directory. The Add object tab now has a File icon. Add one or more directories or files to the software package. Tip: You can insert multiple files to a directory by clicking Edit Insert or from the context menu when you right-click a directory on the left pane, select Insert Multiple file/directory.
Execute Program action

The Execute Program action runs an executable or script on the target machine during an install or remove operation. Perform the following steps: 1. On the right pane, in the Program tab click the Execute Program icon or click Edit Insert Execute program. The Execute Program Properties dialog opens. Here, perform the following steps: In Caption, write a descriptive text. In Path, write the path and filename to execute. In Exit Code, add one or more return codes between 0 and 65535. In the Advanced dialog, specify the following:
136
Arguments passed to the executed program A Working Directory where the program runs The option User Input Required allows the program to open a window The Error and Output file contains standard output and standard error
Figure 6-11 shows an example of a simple software package with the following three actions and objects: Check disk space system action Add directory and file object Execute program action
Figure 6-11 Example software package
137
6.4.2 Saving a software package

The Software Package Editor can store a software package in three different formats: Software package (*.sp) format is a binary file that contains all references to the objects and files within the software package but not the files themselves. Software package definition (*.spd) format contains the same information as the software package (*.sp) format but stored in a readable text format. Software package block (*.spb) format contains all objects together with the actual files in a zipped format. The *.sp and *.spd formats are non-built formats, however, the software package block (*.spb) format is the built format. A software package is stored locally on the workstation or uploaded to a file repository on the Tivoli Provisioning Manager server. To save a software package click the Save package to local file system icon or Save package to repository. Alternately, select File Save Save to local file system or File Save Save to repository. Note: Targets for software distribution must have a SOA service access point defined. You must run the workflow Create_SOA_Endpoint_Operation_SAP on the targets before distributing software.
138
6.5 Compliance management

In order to define your desired set up, you can create compliance checks. Compliance checks are a simple compliant state definition for computer systems that are used to detect, report, and remediate any noncompliance. After you have defined compliance checks, you have defined the compliant state of your target computer or group of target computers. The compliant state is how you want your computer to be. Next, you can run an inventory scan to check the actual state of your computer. The actual state is what the actual set up of the computer is. If the compliant state does not match the actual state, noncompliance occurs. Recommendations are then generated, which you can follow to fix the noncompliance issue.
6.5.1 Adding software compliance check

You can use software compliance checks to define the standard inventory for a target computer or a group of target computers. The software inventory on a managed system can include a variety of software resources, such as installed software or software patches, software instances, application data, configuration files, and other software-related data. To add a software compliance check to a single computer or group of target computers, you must perform the following steps: 1. From the navigation bar, expand Inventory Manage Inventory Computers/Groups. 2. Select the computer or group of computers you wish to modify. 3. Click the Compliance tab Edit Add Software Compliance Checks. 4. Type the name of the software compliance check you wish to add (asterisk for all available) and click Search. 5. Move the relevant items from the Available Software list to the Selected Software list. 6. Click Save to close the dialog and add the software compliance checks.
6.5.2 Adding security compliance check

You can also define security compliance checks for a computer or a group of target computers, which can be used to check various settings, such as your user password settings.
139
There are a number of default security compliance checks predefined for specific platforms. You can use them as they are, or modify them according to your requirements, for example, the Remote Root Login compliance check prepared for AIX only has default settings to not allow remote login, but you can change these settings to allow remote login in case it makes sense for a specific computer. For a complete listing of predefined security compliance checks visit the following: http://publib.boulder.ibm.com/infocenter/tivihelp/v13r1/index.jsp?topic =/com.ibm.tivoli.tpm.cmp.doc/compliance/rscm_secattrb.html To add a security compliance check to a single computer or a group, perform the following steps: 1. From the navigation bar, expand Inventory Manage Inventory Computers/Groups. 2. Select the computer or group of computers you wish to modify. 3. Click the Compliance tab Edit Add Security Compliance Checks. 4. Move the security compliance check you wish to add from Available Compliance Checks to Selected Compliance Checks. 5. Click Save to close the dialog and add the selected security compliance checks. 6. Afterwards you can, and must, modify the selected security compliance check properties to meet your requirements by selecting the Properties button for the security compliance check you just added. For instance, the User Password Settings check should be modified to match your company policy regarding: Minimum password length Maximum password age (days) Minimum password reuse count Note: The predefined security checks Operating System Patches and Updates and Restrict Other Software have no properties that you can change.
6.5.3 Running inventory scan and compliance check

After you have added one or more compliance checks you must run an inventory scan, followed by a compliance check to verify whether the computer or group of computers is compliant or not.
140
This is done in the following order: 1. From the navigation bar, expand Inventory Manage Inventory Computers/Groups. 2. Select the computer or group of computers you wish to modify. 3. Click the Compliance tab Run Run Inventory Scan. 4. Verify that the inventory scan was successful: Task Management Track Task. 5. Repeat steps 1 and 2. 6. Click the Compliance tab Run Run Compliance Check.
6.5.4 Handle recommendation

The result of the compliance check will be displayed in the Compliance tab after the previous check runs successfully. In case the result is not compliant a recommendation is added to the Recommendations tab. In such a case, perform the following steps: 1. From the navigation bar, expand Inventory Manage Inventory Computers/Groups. 2. Select the computer or group of computers you wish to modify. 3. Click the Recommendations tab. 4. Select the check box before one or more issues which are to be handled in the same way, and then select one of the following actions: Open: Open an issue you have 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. To enable automatic remediation for security recommendations, you must develop security remediation workflows and set them as the default for each compliance check type. By default, all security recommendations are associated with a placeholder workflow that does not perform any remediation. Schedule: Implements an approved recommendation using the Install Software page, so you cannot use this action for security recommendations.
141
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. In order for automated remediation to work, the software you are trying to install or uninstall must have been set up properly in Tivoli Provisioning Manager. For example, a software configuration template must exist for the software you want to work with. If you are trying to install software using automated remediation, the remediation workflow will only work if the following is true: A software configuration template exists that matches the software called for by the noncompliance recommendation exists. The software configuration template must be populated with the appropriate default values or parameters. Otherwise, install the software manually.
6.5.5 Verifying changes

After you have performed the changes recommended by workflow, you can manually verify if the computer or group of computers is now compliant. This is done by performing the following steps: 1. From the navigation bar, expand Inventory Manage Inventory Computers/Groups. 2. Select the computer or group of computers you wish to modify. 3. Click the Compliance tab Run Run Inventory Scan. 4. Verify that the inventory scan was successful by selecting Task Management Track Task. 5. Repeat steps 1 and 2. 6. Click the Compliance tab Run Run Compliance Check. 7. Check the results in the Compliance tab.
142
6.6 Software Management

There are a variety of options available for managing your library of software, administering infrastructure that stores and deploys software, and managing deployment of the software. The following pages describe the use of software stacks and software catalogs in Tivoli Provisioning Manager.
6.6.1 Software stack

A software stack is a special Software Definition type that includes an installable file, a software product, a software patch, an image or other software stacks. Using software stacks provides a method to install bundled software in a specific sequence on target systems. The software definitions order in the modules list determines the installation order of the software stack. In Tivoli Configuration Manager this functionality is provided by using nested software packages. The software stacks are located in the Web interface on the left pane in Software Management Manage Software Catalog Software Stacks. When selecting a software stack, the associated entries in the data center model are listed on the General, Variables, Workflows, and Credentials tabs. The General tab lists the following entries: Modules Installables Groups Requirements and Capabilities Configuration Templates
Modules
The Modules entry contains software definitions, software patches or other software stacks. You can add one of these items by selecting Edit Add Stack Entry. Every software definition must include at least one installable file. If there is a software definition listed in the modules section, then the software stack must also include an iterator in the installables section. The provisioning server uses the iterator to install the software stack. If you do not include an iterator, the provisioning server assumes that the software definitions are only in the software stack to model the contents of the software stack.
143
Installables
The Installables entry lists images associated with the software stack. The installables can also contain a special list entry called Iterator. The iterator indicates that the provisioning server must use the software definitions in the modules list to install the software stack. A software stack can include one ore more images. When there is more than one image in the list of installables, then the provisioning server decides which image to install on the target system based on the requirements for each image. An image installation is started from a boot server. A software stack containing one or more images is normally used to deploy new systems or to re-image existing target systems. The installables can contain both an iterator and one or more images. The placement of the iterator in the installables list determines when the Provisioning Manager uses the software definitions to install the software stack instead of the installable Images. If the iterator is the first item in the list, the software definitions are installed instead of the images. If the iterator is the last item in the list, the provisioning server only installs the software definitions if the target system does not meet the requirements in all the images listed in the software stack. An iterator is typically listed at the end of the installables list.
Groups
Software groups help you to organize your software in ways that are meaningful in your organization. For example, you might want to categorize software by department or area within your organization. Using a group is a convenient way to do such operations as operating system install, software distribution, install, or uninstall, and running script and workflow tasks. You add, modify or delete software groups from the Web interface by selecting Software Management Manage Software Catalog Groups.
Requirements and capabilities

The requirements defined in the software stack only apply to images listed in the software stack. The requirements for software definitions are defined within the individual software definitions and the configuration template for the software stack.
Configuration templates
When you add software definitions to a software stack, a copy of the software configuration templates for each software definition is used to build the configuration template for the entire software stack. When you modify an entry in the software stack, the original configuration template in the software definition is not changed.
144
A software configuration template is used to create a software resource on the target system. Settings in software configuration templates are defined by parameters. Each parameter can have one or more predefined values so that a software installer can easily select a valid value during installation. The parameter can have fixed values or values that can be selected or changed at installation time. The following options are also available for each parameter: Define the type value that is required: a string, integer, or boolean value. Select the default value. Indicate if the parameter is optional or required. Indicate if the value is fixed or if a software installer can change the value at installation time. Indicate if the value is encrypted. Indicate if the parameter is hidden from software installers during installation. There are several ways to create a software configuration template. You can copy an existing configuration template from a software definition and modify the parameters. Click Software Management Manage Software Catalog and select Operating Systems, Software Products, Patches, or Software Stacks. Select one item from the list on the right pane and click Edit Define Configuration Template. In the New Configuration Template dialog select Copy from a software definition. You can also create an empty software configuration template and manually add all the parameters, requirements, and capabilities that you require. Click Create an empty template in the New Configuration Template dialog. The Software Resource Type drop down menu provides the options: Application Deployment, Foreign configuration, and Installation. The Multiplicity Type drop down menu provides the option to restrict the number of instances the template can be used in software definitions.
6.6.2 Software Catalog

The software catalog is the place where the Tivoli Provisioning Manager server stores all the information about available software. You can manually add an entry to the Software Catalog, or a process can automatically update the Software Catalog.
File server
A file server in Tivoli Provisioning Manager is the actual server that stores the software, images, and other files that you want to install on target systems. You
145
can change the settings or add a file server by selecting Inventory Infrastructure Management File Repositories.
External software catalog

An external software catalog is a special file server that maintains a current library of software available from a file repository. The Windows Server Update Services (WSUS) is one example of a process that automatically adds software to an external software catalog. You modify the settings or deploy a software catalog by selecting Inventory Infrastructure Management External Software Catalogs. You can add an external software catalog by selecting Edit Add Software Catalog, and entering the fields as shown in Figure 6-12.
Figure 6-12 Add external software catalog
6.7 Virtual servers

Virtual servers reside on host platform servers. It is important to understand the relationship between a host platform server and its associated virtual servers. The resources that you can assign to a virtual server depend on the resources supported by the host platform server. The prerequisites for a virtual server in Tivoli Provisioning Manager are: Host platform server with appropriate resources Virtual server template with appropriate requirements Appropriate tcdriver in $TIO_HOME/drivers
146
In the following, how to manage the creation of a virtual server will be described.
6.7.1 Installing tcdriver

Normally a vmware-4 tcdriver is already available in Tivoli Provisioning Manager. In case you need to install a different driver use either of the following: %TIO_HOME%\tools\tc-driver-manager.cmd on Windows $TIO_HOME\tools\tc-driver-manager.sh on UNIX To import your own tcdriver, perform the following steps: 1. Open the command line interface on the Tivoli Provisioning Manager server. 2. Change to %TIO_HOME%\tools on Windows or $TIO_HOME/tools on UNIX. 3. Stop the Tivoli Provisioning Manager server. 4. Run tc-driver-manager.cmd l or tc-driver-manager.sh l to list all installed tcdrivers. 5. Run tc-driver-manager.cmd i <package_name> or tc-driver-manager.sh i <package_name>. Note: <package_name> is the name of the tcdriver file to be installed, but without the .tcdriver extension. 6. Verify whether the installation is successful by using the cmd from Step 4. 7. Start the Tivoli Provisioning Manager server.
147
6.7.2 Creating host platform server

1. In the navigation pane, expand Inventory. 2. Select Inventory Manage Inventory Computers. 3. Select Edit Add Host Platform Server. 4. Type the name of the new host platform server in the Name field. 5. Optionally, assign the virtual host to an application tier or a resource pool from the Belongs to drop-down list. 6. If this host platform server is associated with a specific locale, select the Locale list. 7. Click Save. Note: When the host is created, a virtual switch is created in the form host-platform-name- switch. A virtual port is created on this virtual switch for every virtual NIC (network interface card) on the virtual servers that are allocated to this host platform server.
6.7.3 Adding resource to host platform server

A virtual server requires at least a physical volume on the host platform server that it can allocate. The amount of physical volume is defined by the Virtual Server Template (for details see Creating virtual server template on page 149). To add a resource to a host platform server: 1. Select Inventory Manage Inventory Computers. The list of available computers in the data center model is displayed. 2. Identify the host platform server that you want to add a resource to. 3. Select Edit Add Other Resources. 4. Complete the fields as follows: a. Select the type of resource to add in the Resource Type list. b. Type a name for the resource in the Name field. c. Optionally, type a resource group name in the Resource Group Name field. This name is for a logical group to which you want to assign the resource. Using logical groups allows a resource allocation request to specify a resource group name, ensuring resources are allocated using only host platform resources with the specified resource group name. d. Select the Managed check box if this resource is to be managed.
148
e. Select the Partitiontable check box if this resource is to be subdivided during allocation. This property specifies whether the resource can be subdivided or must be allocated as a single, whole unit. Select the check box if you want to share the resource or leave it blank. f. Click Save. 5. The resources are now added to a host platform server.
6.7.4 Creating virtual server template

Tivoli Provisioning Manager provides three types of server templates. As we are using one of them at this point, a summary of how the templates are to be used within Tivoli Provisioning Manager is given. The three types of templates available are:
Storage templates
A storage template is a reusable set of storage requirements and configurations with a hierarchy that mirrors the model to be realized. Templates can be defined once, and each workflow operation will take its input values from the currently selected template.
Computer templates
A computer template defines the compliant state for installed software and software configuration on the system. It can contain the following data center model objects: Network interface Software definition Storage template Route In Tivoli Provisioning Manager you must define the systems that you want to manage. You have several different methods to add new systems: Manually, using the Add Computer wizard in the Web interface Automatically, using an inventory discovery Importing, a system from an xml-file As you add new systems to Tivoli Provisioning Manager, assign them to appropriate application tiers and resource pools. If you need to manage compliance separately for specific systems, you must assign computer templates to the individual systems that you want to manage separately.
149
Create a computer template from the Web interface by selecting Inventory Manage Templates Computer Templates, then click Edit Add Computer Template. Provide a name for the computer template and select a resource pool to associate with. After creating a computer template, click the computer template and specify network routes, network interface cards, software definitions and storage templates.
Virtual server templates

Virtual server templates are used to allocate virtual servers. A virtual server
template has various requirements such as the amount of memory, the size of the hard disk and so on. To be able to allocate a virtual server you must have at least a single virtual server template. You can create a virtual server template by performing the following steps: 1. In the navigation pane, expand Inventory Manage Templates. 2. Select Edit Add a Server Template. The New Virtual Server Template window is displayed. 3. Type a unique name for the new virtual server template. Note: The name of a virtual server template has nothing to do with the name of the virtual servers you create with it. 4. Click Save to close the dialog and create the template.
6.7.5 Adding resource requirements

To be able to use the newly created virtual server template, you must add the hard disk requirement for the virtual server. To add a resource requirement, perform the following steps: 1. In the navigation pane, expand Inventory Manage Templates. 2. Select Virtual Server Templates and identify the template that you want to work with from the Manage Virtual Templates page. 3. Select Edit Add a Resource Requirement. The New Resource Requirement dialog is displayed. 4. Select the type of resource you are adding in the Resource Type list. 5. Specify whether the requirement is to be dedicated to the virtual server or not by selecting or clearing the Shared check box.
150
Note: When a resource is not shared, the corresponding resource on the host platform server is decremented when a virtual server is allocated. If the resource is shared, the corresponding resource on the host platform server is not decremented and the same resource can be simultaneously assigned to as many virtual servers as required. 6. Optionally, select a resource group name in the Resource Group Name list. 7. Other fields may appear in this dialog. This is determined by your selection in the Resource Type list: Host Platform Quantity This field is displayed for the Hard Disk, Memory, User defined resource, Hardware Platform, CPU and Generic resource types. In each case, the quantity is measured differently and refers to the quantity on the host platform. For Hard Disks, the quantity is measured in Gigabytes (GB). For Memory, the quantity is measured in Megabytes (MB). For CPUs, the quantity is measured in Shares (portions of the whole). For Generic resources, the quantity has no specific measurement type, since it is meant to be generic. Virtual Server Quantity This field is displayed for Memory, NICs, User defined resource, Hardware Platform, CPUs and Generic resource types. In each case, the quantity is measured differently and refers to the quantity on the virtual server. For Memory, the quantity is measured in Megabytes (MB). For NICs, the quantity is measured in NICs (only a whole NIC can be specified, but there can be multiple NICs available). For CPUs, the quantity is measured in Shares (portions of the whole). For Generic resources, the quantity has no specific measurement type, since it is meant to be generic. Type the desired values in the fields as appropriate. 8. Click Save. The template is updated with the new requirement.
6.7.6 Allocating the virtual server

Finally, to create the data center model object for the virtual server you must allocate the virtual server to a host platform server. This is done in the following order: 1. Select Inventory Manage Inventory Computers. The list of available computers in the data center model is displayed.
151
2. Select Edit Allocate a Virtual Server. In the New Virtual Server window, complete the fields as follows: a. Type the name of the new virtual server in the Name field. b. Clear the Failed check box. c. Select a virtual server template from the Associated Server Template list. As soon as a virtual server is allocated (created), there is no further connection to the template used to create it. Altering or deleting that template has no effect on the servers created with it. d. Select a host server from the Host Platform list. e. Select the Use Logical device Operation check box to run the logical operation. Note: If you select this check box, then the Belongs to and Locale drop-down lists are disabled automatically. If you are entering configuration data about this server that does not require a data center model update, clear the Use Logical device Operation or the system will try to set up the device again. f. Optionally, assign the virtual host to a resource pool or application tier from the Belongs to list. g. If this virtual server is associated with a specific locale, select the locale from the Locale list. h. Select the Ignored By the Resource Broker check box if you want the computer to be ignored by the resource broker. This setting is typically enabled when you are performing maintenance on the computer and want to prevent provisioning of the computer by the policy engine. i. Click Save.
6.8 Imaging
Tivoli Provisioning Manager includes support for the following types of boot servers: Network Installation Management (NIM) for AIX Ignite-UX for HP-UX IBM Remote Deployment Manager KickStart for Linux Microsoft Automated Deployment Services (ADS) Rembo Toolkit Jumpstart for Solaris
152
Tivoli Provisioning Manager V5.1 includes the Rembo Toolkit 4.0 that can capture operating system images from source systems and redeploy these images to other target systems with similar hardware resources. Rembo Technology, a company headquartered in Geneva, Switzerland, is a leading provider of operating system (OS) imaging and bare metal installation technology. Rembo has two primary products, Rembo Auto-Deploy and Rembo Toolkit. The Rembo server provides a PXE Boot server, that allows computers based on x86 architecture to perform a network boot. The Rembo products are now fully integrated into the IBM Tivoli software portfolio. The successor to Rembo Auto-Deploy is renamed Tivoli Provisioning Manager for OS Deployment, a standalone product. The successor to Rembo Toolkit is Tivoli Provisioning Manager for OS Deployment Embedded Edition. Note: Tivoli Provisioning Manager for Software uses Tivoli Provisioning Manager for OS Deployment Embedded Edition, the direct successor to the Rembo Toolkit. In order to use the Rembo server in Tivoli Provisioning Manager for Software, you must install the Tivoli Provisioning Manager for OS Deployment Embedded Edition, which is a separate product provided as automation package. The automation package rembo.tcdriver is contained in the Tivoli Provisioning Manager for OS Deployment component. Table 6-1 shows how the Rembo software is renamed in the IBM portfolio.
Table 6-1 Rembo product integrated into IBM Tivoli software IBM Tivoli product Tivoli Provisioning Manager Tivoli Provisioning Manager for Software Rembo product Rembo Toolkit Rembo Toolkit Description Is included in Tivoli Provisioning Manager Is not included in Tivoli Provisioning Manager for Software, but is an optional addition Standalone product Is direct successor to Rembo Auto-Deploy
Tivoli Provisioning Manager for OS Deployment
Rembo Auto-Deploy
153
IBM Tivoli product Tivoli Provisioning Manager for OS Deployment Embedded Edition
Rembo product Rembo Toolkit
Description Stand alone product Is direct successor to Rembo Toolkit Provided as automation package for use in Tivoli Provisioning Manager for Software
6.8.1 Installing a boot server

You can deploy any supported boot server from Inventory Infrastructure Management Boot Servers. Click Edit Add Boot Server Wizard to start the installation. When you select Rembo in the Boot Server list, as shown in Figure 6-13, the Rembo Toolkit 4.0 will be installed and configured on the computer you choose from the next page. For all boot server types other than Rembo, only the Tivoli Provisioning Manager software boot server object is created and the computer object for the boot server is updated in the DCM. The following example describes the Rembo boot server installation using the boot server wizard: 1. In the Select Server Type page, select Rembo and click Next. 2. In the Select Target page, select a computer for the Rembo Toolkit installation. The target list shows only computers that matches the operating system prerequisite for the Rembo Toolkit. Click Next. 3. In the Configuration page, enter the boot server administration user name and password (required) and click Next. 4. In the Schedule page, enter a task name (required), select Now or a date and time for the installation, and click Next. 5. Verify the information the Summary page and click Finish.
154
Figure 6-13 Add Boot Server Wizard
The computer target for a Rembo server must meet the following requirements before starting the installation: The computer must either have a RXA service access point defined or a common agent installed. The computer must have an operating system defined. You can in the computers software tab click Edit Add Software Installation and select an operating system from the Software Definition drop-down list. If the computer has the common agent installed, an Inventory scan adds the operating system to the computer software tab. The Rembo server can be installed on the following platforms: Windows 2003, Windows XP, or Windows 2000 computer RedHat Enterprise Linux (RHEL), Version 3 and Version 4 SuSE Linux Enterprise Server (SLES), Version 9 The Rembo server supports image capture from the following operating systems and platforms: Windows 2000 Server and Windows 2003 Server Windows 2000, Windows XP, and Windows XP 64 bit Linux Fedora Core, V3, V4 and higher (i386) Red Hat Enterprise Linux, V3 and V4 (i386)
155
SuSE Linux Professional V9 (i386) SuSE Linux Enterprise Server V9 (i386) Debian GNU-Linux V3.1 (Sarge) (i386) Sun Solaris (Sparc): V8, V9, and V10 (Sparc) The Rembo server supports capturing and installing the file systems FAT12/16/32, NTFS, EXT2/EXT3, and ISO 9660.
6.8.2 Capturing an image with Rembo Boot Server

To capture an image with Rembo Boot Server, perform the following steps: 1. Check the Rembo Boot server status from the Web interface by clicking Inventory Manage Inventory Computer on the left pane and then select the computer on the right pane where the Rembo Toolkit 4.0 is installed. 2. Click the Software tab and below the Software Resources expand the Rembo Toolkit 4.0 section. If the status shows Not running, then click the context menu on the right side and click Start as shown in Figure 6-14.
Figure 6-14 Starting the Rembo Toolkit
156
The Tivoli Provisioning Manager V5.1 Fixpack 1 provides an updated version of Rembo Toolkit that is renamed to Tivoli Provisioning Manager for OS Deployment Embedded Edition as shown in Figure 6-15.
Figure 6-15 Rembo Toolkit renamed to Tivoli Provisioning Manager for OS Deployment
Preparing the Sysprep tool for Windows images

On Windows systems the Sysprep tool is run before the image capture starts. Therefor you need to copy the correct versions of sysprep.exe and setupcl.exe to the %TIO_HOME%\repository\rembo\<winos> directory on the Tivoli Provisioning Manager server where <winos> is the operating system of the captured image: win2k: Windows 2000 win2k3: Windows 2003 winxp: Windows XP For example the Sysprep tool is copied to the %TIO_HOME%\repository\rembo\win2k folder before capturing an image from a Windows 2000 operating system. You can extract sysprep.exe and setupcl.exe from the support\tools\deploy.cap file located on the Windows installation CD. Always use the deploy.cap from the latest service pack for each operating system available from the Microsoft download site. The deployment tools are different for each Microsoft operating system. They are provided through the following links: Windows 2000 SP4: sp4DeployTools.exe http://support.microsoft.com/kb/820196 Windows XP SP2: WindowsXP-KB838080-SP2-DeployTools-ENU.cab http://support.microsoft.com/kb/838080 Windows 2003 SP1: WindowsServer2003-KB892778-SP1-DeployTools-x86-ENU.cab http://support.microsoft.com/kb/892778
157
Defining operating system

Before capturing an image, you must define the operating system for the machine from where the image is captured. From Inventory Manage Inventory Computers click the source computer for the image. In the Software tab click Edit Add Software Installation, enter a descriptive name for the image and select the computer operating system from the Software Definition pull-down menu. Leave the Software Installation selection empty and the Configuration Templates unchanged.
Enabling the boot from network interface card

In the Computer General tab it is important to edit the Network Interface Properties and check the Netboot enabled box.
Discovering operating system attributes

These steps are not required when capturing a Linux operating system. Run a Windows Configuration Discovery on the source computer for the captured image to get operating system attributes like product key, computer name, owner, company, time zone, and other system information. These attributes will be added to the target computer when you install the image. Click Inventory Manage Inventory Discovery Configurations and select Run on the right side next to Windows Configuration Discovery. In the Display drop down menu select by Computer and select the computer where you want to run the discovery. Click Submit and notice the status on the Track Tasks view.
Discovering local users

These steps are not necessary on Linux systems. Run a Windows Local Users Discovery from Inventory Manage Inventory Discovery Configurations. Select the computer for the image source and click Submit.
Setting Administrator password

These steps are not necessary on Linux. After the local users are discovered, you must set the password for the Administrator account. The password is stored in the DCM and allows the Rembo Boot Server to access the computer during the capture process and to log in after rebooting the machine. Find the computer that you are capturing the image from, click Inventory Manage Inventory Computer and select the computer. In the Software tab in the Software Resource section, click the operating system you previously have added and open the Software Installation page. On the right side next to the Administrator user click Update DCM Password and enter the password in the dialog box.
158
Setting the BIOS startup sequence

In the computer BIOS settings you need to set the startup sequence to boot from network first and then from hard disk. This ensures that the computer first sends a request to a PXE boot server. If the computer receives no response, then it continues to boot from the hard disk.
Starting the image capture process

Select Software Management Manage Software Catalog Images on the left pane. You can also directly select a source computer from Inventory Manage Inventory Computers. On the right pane click Edit Capture Image to start the Capture Image wizard. 1. Select the Source Computer from where the image is captured. 2. Select the Boot Server and the Image type Golden_Master. The Golden_Master image is used to deploy other target computers. The snapshot image creates a backup that can be used to restore the original computer. 3. In the Image Information you can change the default name for the image and enter a description. The Post Execute Status drop down menu defines which action to perform after the image capture: Reboot System or Power Down System. 4. In the Schedule, click Next. 5. In the Summary window, click Finish to start the capture process. There are different logical device operations for the image types Golden_Master and snapshot: Golden_master image This workflow implements the BootServer.CaptureImage device operation. Snapshot image This workflow implements the BootServer.CaptureBackupImage device operation.
159
For the Golden_Master image the Tivoli Provisioning Manager server copies the sysprep.exe and setupcl.exe files to the source computer and performs the Sysprep process. The computer then reboots in the network into the Rembo Boot server and starts the image capture process. Figure 6-16 shows the screen on the source computer during the capture process.
Figure 6-16 Image capture on source computer
6.8.3 Deploying an image with Rembo Boot Server

The Rembo Boot Server can deploy an image to machines that boot in the network into the PXE server.
Requirements
Before you can deploy an image to a target computer that already has an operating system installed, you must add the hardware resources for that
160
computer. Select the target computer from Inventory Manage Inventory Computers. 1. In the General tab, click Edit Add other Resources. 2. In the dialog window, select Hard Disk from the Resource Type list. 3. Enter the name (required) disk-0 for the first disk (disk-1 for the second) and click OK. 4. In the General tab, expand the disk-0 section within Hardware Resources, enter a value for the disk.size and click Add. Specify the disk.size in the format nnG, for example, 20G when specifying 20 gigabyte. 5. Enter a disk.order value 0 and click Add. 6. For every additional hard disk, repeat the steps 1. to 5. and increment disk.order by 1. 7. In the General tab, click Edit Add other Resources. 8. In the dialog window, select Resource Type CPU from the list. 9. Enter the name (required) CPU-0 for the first CPU. 10.In the General tab, expand the CPU-0 section within Hardware Resources, select values for the cpu-family and cpu-type parameters, for example intel and 32-Bit, and click Add for each parameter. You can also add the hardware resources to a computer using a Rembo Hardware Discovery or a Tivoli Provisioning Manager Inventory Discovery. A Rembo Hardware Discovery runs on a target computer even when no operating system is installed. The Rembo Hardware Discovery only needs the serial number of the computer, specified as a parameter in the Discovery Configuration. To do this: 1. Verify that the network card has the Netboot check box enabled. 2. In the target computer BIOS, set the boot order to start from network first.
Installing image
To install an image complete the following steps: 1. From the left pane select Software Management Install Images. Select the image you want to install. Select one or more target computers to install the image on. The hardware resources of the target computer must be similar to the hardware resources of the captured image. 2. Click the Advanced button to open the Customize Configuration page and provide information for the storage settings for the target computer and other
161
configuration settings for the Stack Template entry. When you change the size for a partition, the available space on the disk is updated automatically. 3. Click Submit to start the image installation. The target computer reboots from the Rembo Boot Server and starts downloading and installing the image. In a 100 Mb network it takes about 10 minutes to download a 4.5 GB image from the boot server.
6.9 Software distribution and installation

You can distribute and install software products, software patches and software stacks defined in the Software Catalog. You have the option to perform the distribution and installation at the same time, or to split the distribution and installation into two different tasks.
6.9.1 Software distribution

The distribution operation downloads the software to endpoints without installing the software on the targets. This can be done by performing the following steps: 1. In the Web interface, click Software Management Distribute and select Software Product, Patches, or Software Stack. On the right pane make one or more selections of the software you want to distribute. 2. On the same page, in Select Computers check the box on one or more computers where you want to distribute the software. 3. Click the Advanced button to change the configuration template for the selected software. 4. Click Submit.
6.9.2 Software installation

The installation operation installs the software on endpoints. If the software has not been previously downloaded though a distribution operation, the install operation performs both the distribution and installation on endpoints. 1. In the Web interface, click Software Management Install and select Software Product, Patches, or Software Stack. On the right pane make one or more selections of the software you want to install. 2. On the same page, in Select Computers check the box on one or more computers where you want to install the software.
162
3. Click the Advanced button to change the configuration template for the selected software. 4. Click Submit.
6.9.3 Requirements on target endpoints

The Tivoli Provisioning Manager must communicate and have remote access to software distribution targets. These targets must have the Tivoli Common Agent installed or use the IBM Tivoli Remote Execution and Access (RXA). The RXA service access point provides authentication with a user ID and password and uses the SSH or Windows SMB protocols. When using the RXA with Windows SMB, the targets must also have: Remote registry administration enabled Default hidden administrative disk shares (for example, C$ or D$) Both ports 135 (RPC) and 139 (NetBIOS over TCP/IP) enabled Simple File Sharing disabled (only on Windows XP targets) The service access point must have the device operations file-transfer and execute-command defined for the software distribution targets.
6.9.4 User role for software distribution

The Tivoli Provisioning Manager provides a number of predefined user roles with assigned permissions. You can add user roles and define the groups they have permission to perform operations on. The predefined Software Operation role has system wide access permission to: Publish, distribute, install, and remove software Access and perform tasks from the Software Catalog Generate reports related to software management Create software stacks Create activity plans Manage software views Access and initiate tasks from the inventory view
163
6.10 Web services

Web services in Tivoli Provisioning Manager allows computers in a network to connect dynamically, and run transactions in real time with minimal human interaction. Using the Simple Object Access Protocol (SOAP) commands, you can manage and configure the environment. The simplest Web services stack would consist of HTTP for the network layer, SOAP for the Extensible Markup Language (XML) messaging layer and Web services description language (WSDL) for the service description layer.
6.10.1 Extensible Markup Language

XML is the markup language that underlies most of the specifications used for Web services. XML is a generic language that can be used to describe any kind of content in a structured way, separated from its presentation to a specific device. XML format is used in Tivoli Provisioning Manager to, for example, export and import data center models. For this purpose Tivoli Provisioning Manager delivers the scripts: $TIO_HOME/tools/dcmexport.sh (%TIO_HOME%\tools\dcmexport.cmd on Windows) $TIO_HOME/tools/xmlimport.sh ((%TIO_HOME%\tools\xmlimport.cmd on Windows) The usage for this command is: dcmexport -d <file_name> xmlimport file: <file_name> <file_name> is the name of the file including the path to it where the XML data should be stored in or read from. Note: This XML file must adhere to the rules specified in the $TIO_HOME/xml/xmlimport.dtd file.
6.10.2 Simple Object Access Protocol

SOAP, which is similar to JDBC, is a network, transport, and programming language and platform neutral protocol that allows a client to call a remote
164
service. The message format is XML. XML-based messaging, represents the use of XML as the basis for the messaging protocol. SOAP commands covered by scripts can be found in the directories $TIO_HOME/soapclient/tpmlteSoap on UNIX and %TIO_HOME%\soapclient\tpmlteSoap on Windows. The directories contains the Scrips with cmd-extension for Windows and sh-extension for UNIX versions of the SOAP commands. You can find a complete list of delivered scripts with their description and usage on the Web at: http://publib.boulder.ibm.com/infocenter/tivihelp/v13r1/index.jsp?topic =/com.ibm.tivoli.tpm.soa.doc/soap/rsoa_cmdline.html
6.10.3 Web services description language

WSDL is an XML-based interface and implementation description language. The service provider uses a WSDL document in order to specify the operations a Web service provides, as well as the parameters and data types of these operations. A WSDL document also contains the service access information. You can run SOAP commands and SOAP scripts from the command line. SOAP scripts enable you to easily run common SOAP commands. You can run commands from the Tivoli Provisioning Manager server or from another computer. Use the following syntax for a SOAP command: From a DOS command window or UNIX soapcli username password wsdl_location operation parameters From a bash environment on a Windows server soapcli_bash4win username password wsdl_location operation parameters The parameters are as follows: username: Your Tivoli Provisioning Manager user name password: Your Tivoli Provisioning Manager password wsdl_location: the WSDL file is available on the Web at: http://hostname:port/ws/pid/wsdlservicename?wsdl The Web address includes the following parameters: hostname: is the fully qualified domain name of the Tivoli Provisioning Manager server
165
port: is the port number (the default is 8777) wsdlservicename: is the name of the WSDL Service. The following are some of the WSDL services that are supported in Tivoli Provisioning Manager: TpmLiteSoapService CredentialsManagerService SPOfferingService SPSubscriptionService EffectiveModeService OperationsModeService FaultManagementService RecommendationsSerivice ResourceInformationService
operation: The WSDL operation that you want to run parameters: The parameters for the specified method or operation Example 6-1 shows how to use WDSL operation to invoke a logical device operation from command line. The first example is an installation of a patch and verification of the return code based on the execution status. The second example is adding a computer to an application tier:
Example 6-1 soapclient.cmd
soapcli.cmd username password wsdl_location executeDeploymentRequest \ Application.nonDisruptiveUpgrade app_id patch_id soapcli.cmd username password wsdl_location findDeploymentStatus \ request_ID soapcli.cmd username password wsdl_location Cluster.AddServer \ "ClusterID=786"
6.10.4 Web Services Resource Framework

The Web Services Resource Framework (WSRF) defines a generic and open framework for modeling and accessing resources using stateful Web Services. Tivoli Provisioning Manager provides WSRF services in an OSGi environment. The WSRF services allow you to access the data center model directly rather than launching the Web interface. Using the WSRF services you can access, manipulate, or change objects in the data center model.
166
To learn more about each registered WSRF service, see the corresponding Web Services Description Language (WSDL) explanation using the following URL format: http://hostname:8777/ws/pid/service For example, to see the WSDL information for an Application WSRF service, type: http://localhost:8777/ws/pid/Application Note: In order to access the WSDL explanation for each WSRF service Tivoli Provisioning Manager must be started. Similarly, you can learn more about the resource properties for each service using the following URL format: http://hostname:8777/ws/rid/service For example, to see the WSDL information for the Application resource properties, type: http://localhost:8777/ws/rid/Application
6.11 Using Automation Package Development Environment

Automation packages are collections of commands, shell scripts, workflows, logical device operations, and Java plug-ins that apply to the operation of a specific type of software component or a physical device.
167
In the larger context of automated provisioning, a workflow represents the real implementation of a specific IT process. Workflows interact with other workflow-related components to provide automated provisioning. Figure 6-17 will help to understand the role of workflows in Tivoli Provisioning Manager.
Figure 6-17 Workflow related components
An automation package is an installation unit that consists of the scripts, workflows, documentation and Java files for a particular device or software package. An automation package has a .tcdriver extension and is centrally stored in the TIO_HOME\drivers directory of the server. The recommended approach for developing and managing workflows and automation packages is to use the Automation Package Development Environment (APDE). APDE runs on the Eclipse environment like the Software Package Editor, on either a dedicated Windows or Linux machine. Chapter 3, Installing Tivoli Provisioning Manager V5.1 on page 29 describes how it is installed.
168
6.11.1 Creating automation packages

Before you can create workflows or other items for the automation package, you must create a new automation package project. To create a new automation package complete the following steps: 1. Start Eclipse by running: eclipseLauncher.bat on Windows platforms eclipseLauncher.sh on UNIX platforms 2. Ensure that the Automation Package perspective is displayed. To switch perspectives, select Window Open Perspective Automation Package. 3. From the Eclipse menu, select File New Project. 4. Expand Automation Package and select Automation Package Project. Click Next. 5. Type <project_name> for the automation package name, and specify the path where you want to store it. The default directory is a subfolder in the current workspace with the name specified project name. Click Next. 6. The example automation package does not require resources from other automation packages. Click Finish. The new project is created in the Package Explorer view.
6.11.2 Creating new workflow

After you create a new automation package project, you can create workflow (.wkf) files that contain the code to operate a specific device. To create a new workflow: 1. From the Eclipse menu, select File New Workflow File. 2. Specify the workflow name and its relation to logical device operations: If this workflow is a logical device operation, select Logical Device Operation. If this workflow implements a logical device operation, select the logical device operation from the list. 3. To add the workflow to an existing device driver in the automation package, select the device driver from the list. 4. Click Finish. A new workflow is displayed in the editor.
169
6.11.3 Working with Workflows

You can view a list of workflows that are installed in the database. From the list, you can delete a workflow, run a workflow and view workflow source code. 1. Click the Workflows tab. A list of installed items is displayed. 2. You can filter the list of items by typing the name or part of the name of the workflow. 3. You can select a workflow in the list and perform any of the following actions: To view workflow source code, click the Show workflow source code icon. The source code of the workflow is displayed in the Workflow Source window. To delete the workflow, click the delete workflow icon. To run the workflow, click the Execute the selected workflow icon. You can view the results of the workflow in the Execution Results view.
6.11.4 Modify existing automation packages

It is possible to modify the workflows of existing automation packages using APDE. Therefore a database connection to the Tivoli Provisioning Manager server which runs in development mode is required. For details refer to Chapter 3, Installing Tivoli Provisioning Manager V5.1 on page 29. Perform the following steps to modify an existing workflow: 1. Start Eclipse by running: eclipseLauncher.bat on Windows platforms eclipseLauncher.sh on UNIX platforms 2. Ensure that the Automation Package perspective is displayed. To switch perspectives, select Window Open Perspective Automation Package.
170
3. Import a workflow for the Tivoli Provisioning Manager server by selecting File Import... File system Next to open the dialog displayed in Figure 6-18.
Figure 6-18 Import workflow
4. Select Browse... to navigate to the workflow directory of the automation package you wish to modify. Note: In case you are using the APDE on a machine other than the Tivoli Provisioning Manager server, make sure you have connection to the Tivoli Provisioning Manager server file system using SMB or NFS.
171
The default location for the workflows is either of the following: $TIO_HOME/eclipse/plugins/<package_name>/workflow on UNIX %TIO_HOME%\eclipse\plugins\<package_name>\workflow on Windows 5. Select the workflow you want to edit and use the second Browse... dialog box to identify the project to which you wish to import the workflow. 6. In the Package Explorer navigate to the just imported workflow and double click it, the workflow code appears in the workflow editor and you can now manipulate it.
6.11.5 Workflow syntax

The complete syntax of workflows is available on the Web at: http://publib.boulder.ibm.com/infocenter/tivihelp/v13r1/topic/com.ibm.t ivoli.tpm.wkf.doc/workflows/rwkf_syntax.html A short summary of the most important syntax rules is given next. A workflow file starts with the workflow keyword followed by the workflow name, parameters, the implements keyword followed by the name of the device operation. By default the localeInsensitive keyword is the last part of the workflow as follows: workflow <workflow_name> (parameters <parameter_name>) implements <ldo_name> LocaleInsensitive The valid parameters are: in | out | inout in: is an input parameter out: is an output parameter inout: is both an input and an output parameter encrypted Encrypts the variable of the parameter array Specifies that the value of the parameter is an array implements ldo-name Specifies that the workflow implements a logical device operation ldo-name Is the name of the device operation LocaleInsenseitive
172
Specifies that the workflow is designed to work in all locales. The LocaleInsenseitive keyword is inserted in a workflow by default. If you want to check the locale of a particular device, you can use the checkDeviceLocale workflow keyword. A workflow fails if the locale of the target device does not match the locale specified in the workflow.
6.11.6 Exporting created or modified workflows

There are two options to export a newly created or modified existing workflow to save the caches you made: Exporting to file Uploading changes to data center model
Exporting to file
1. Select File Export. 2. In the Export wizard, select File System Next. 3. Select the destination directory for the file, and then click Finish.
Uploading changes to data center model

To activate your changes in the data center model you must perform the following steps: 1. Select the modified workflow in the Package Explorer and highlight it. 2. Select Workflow Compile from the Eclipse menu. Important: The exported workflows (.wkf files) are ASCII files which can be edited. Ensure that they are saved in UTF-8 format only.
173
174
Chapter 7.
Infrastructure
This chapter provides an overview of the infrastructure components and methodologies of Tivoli Provisioning Manager including: The Data Center Model Scalable Distribution Infrastructure including the Tivoli Common Agent The Software Lifecycle The Security Model
175
7.1 The Data Center Model

This section presents a high level overview of the Data Center Model (DCM) in Tivoli Provisioning Manager.
7.1.1 What is Data Center Model

DCM is a model of physical assets in a data center and the enterprise with a logical organizational structure to give it context. DCM 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. Whenever changes are made, the ramifications of these 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 Local Area Network), and so on. All of these relationships must be clearly understood so that when the server is moved, it is returned to the correct pool, changed to the correct VLAN if necessary, and so on. DCM captures all these relationships and maintains them appropriately when reallocating resources. DCM is implemented as a relational database. When software is installed on a computer using the IBM Tivoli Provisioning Manager V5.1 interface, it is installed on the physical machine and the DCM is updated to update the logical model in the DCM. If management operations such as software installs, computer network re-configuration, and so on, are performed outside the IBM 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.
7.1.2 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. For example, information used to connect to remote systems. This information is modeled as a ServiceAccessPoint DCM object.
176
7.1.3 Customer
A customer owns applications. Customers can be unique corporations or departments within a single corporation.
7.1.4 Application tier

This is a grouping or container for like resources or servers that support an application. Automated resource allocation and deallocation occurs at the cluster level.
7.1.5 Resource pool

This is a container of available (deallocated) servers that support one or more application clusters. This is also referred to as a spare pool.
7.1.6 Management operations and Logical Device 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 these 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 the generic operations are associated with logical devices, they are called Logical Device Operations
(LDOs).
Note: You can create your own custom LDOs by creating a new LDO type Workflow in the Automation Package Developer Environment. 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).
Examples of Logical Device Operations

Some examples of LDOs are as follows: Cluster.AddRepairedServer Cluster.AddServer Cluster.LiveUpgrade Cluster.RemoveFailedServer Cluster.RemoveServer
Chapter 7. Infrastructure
177
Cluster.RollingUpgrade Firewall.AddACL Firewall.DisableACL Firewall.EnableACL Firewall.RemoveACL Software.CheckStatus Software.Install Software.Start Software.Stop Software.Uninstall
7.1.7 Workflows
Workflows are the instructions that the deployment engine executes when it is carrying out a management task. Typically, these commands will be executed on one or more target computers or devices. These instructions are expressed in a script-like language and can call LDOs and other workflows. Parameters can be passed to workflows at run time and can be looked up by the workflow when it is running, allowing for modular and reusable workflows. Workflows can extract data from the DCM by performing queries and can also make changes to the DCM.
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. An LDO can be implemented by multiple workflows.
7.1.8 Device drivers

Device drivers are also referred to as TC drivers, Automation Packages, device models or simply drivers, A device driver is a collection or 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 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. Automation Packages are stored in the TIO_HOME/drivers directory and have the file extension .tcdriver
178
7.2 Scalable Distribution

This section describes Software Distribution and the Scalable Distribution Infrastructure (SDI) components within Tivoli Provisioning Manager. It covers the following components: Software Products and the Software Catalog Dynamic content distribution service. This is also referred to by the abbreviation DCD or by the legacy name Content Distribution Service. Device Management Service, sometimes called the Job Management Service. Common Agent Services including the Tivoli common agent
7.2.1 File repository

A file repository is a server that stores installable software images and other files that are to be installed on managed systems. File repositories hold operating system images or can link to external software catalogs, such as Microsoft Windows Server Update Services, to provide software updates. A file repository called LocalFileRepository is automatically created on the Tivoli Provisioning Manager server with the directory path set to TIO_HOME/repository.
7.2.2 Software Catalog, Software Products and Software Installables

The terms Software Product and Software Definition are often used interchangeably. A Software Definition is used to store information about a piece of software and how it is installed, while a Software Resource is used to describe how the software is installed on a specific computer. A Software Installable is the actual software package or image file that is distributed and installed on a target system. A Software Package is an object wrapping of one or more Software Installable binary files. For Software Package Block type Software Products the installable is a single SPB file. 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). The Software Package Blocks that you create can either be imported manually or imported automatically by uploading to the file repository by the Software
179
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 complete set of Software Installation objects associated with a computer represents its Software Catalog. Note: With the exception of Software Package Block type Software Products, a Software Product can contain multiple Software Installable files.
Software Product requirement

A requirement is defined as any dependencies that an object has. For Software Package Block type Software Products there is only one requirement that must be specified, This is the Software Installation Engine (SIE) must be installed on the target computer. The SIE is a subagent of Tivoli common agent and implements the Software Package Block Handler to install Software Package Block software installable images, the SIE is automatically installed when you install the Tivoli Common Agent.
7.2.3 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.
7.2.4 The dynamic content delivery service

The dynamic content delivery service is a highly-scalable system for bulk data distribution. Its features include publishing files to depots and, automatic replication of files between depots. It optionally includes adaptive bandwidth control and peer-to-peer distribution. Its components include the Management Center, Depots, Zones and Regions.
180
7.2.5 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. It performs the following key functions: Maintains a list of the files stored on each depot server Stores the configuration of each depot server Publishes files to depot servers Replicates uploaded files between depots Authorizes clients to download a file Creates download plans Stores information about files and download statistics The Management Center has a number of subcomponents, which are not presented on the graphical user interface (GUI). These are listed below in order to present a complete picture: 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.
7.2.6 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 in order to optimize network traffic. In some ways depots are similar to Tivoli Configuration Manager 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 and can optionally be assigned a Domain Name System (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.
181
One or more depot servers can be designated as preferred upload servers. Uploaded files are sent to these servers before others. If no preferred upload server is available, another depot server is selected to receive the uploaded file. Here, 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 optionally possible to configure the bandwidth used by distributions from a depot, either by specifying an explicit bandwidth in kbps 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 the best use of slow networks as Tivoli Provisioning Manager uses the available bandwidth when the network is quiet, but slows down if other applications start using the network, and speeds up the distribution again when the network becomes less utilized. Note: The default behavior is not to restrict bandwidth utilization. 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.
7.2.7 Regions
Regions are used to logically group depot servers that are located near one
another to optimize upload, replication, and download times.
7.2.8 Zones
Zones are logical groupings of computers that have TCP/IP addresses within
single consecutive ranges, 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 (WANs). Zones are typically created to limit network traffic to within a subnet or a 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. Note: Each Region can contain multiple Zones but each Zone can be in only one Region.
182
7.2.9 Device Management Service

The Device Management Service provides a flexible solution for managing various devices, mainly by performing actions called Jobs, which are targeted to individual Tivoli Common Agent devices or to groups of devices that are configured to use a service-oriented architecture Service Access Point (SOA SAP). 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. The Device Management Service tracks the progress of jobs and maintains a history of past jobs. The Device Management Service is also referred to as the Job Management Service, notably during the installation process. In general use the Device Management Service is hidden and transparent to the operator.
Device management server

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

Device management federating agents are referred to as eDMS servers. At the time of writing, remote federating agents were not available but are expected to be included in a future release. As of now, 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 use Cloudscape databases. The agents periodically poll 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 jobs 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.
183
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. The polling interval is set on the managed system by changing the value of PollingInterval in the file CA_HOME/jes.properties. The agent must be restarted for changes to take effect. Many of these parameters can be set centrally by modifying the Tivoli common agent Subagent JES before the Tivoli Common Agent is delivered and installed.
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 in which 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 to the agents, reducing the load on the federated agents.
SOA Service Access Point SOA 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 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.
184
7.2.10 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 these files during downloads by their neighbors. The list of files held by a peer is maintained by the Dynamic Content Distribution Service Peer Manager. Peers periodically contact the peer manager to refresh the information held. Peers that do not report are marked as inactive and are not included as sources in download plans. For network address translation (NAT) environments both the local and remote TCP/IP address is stored by the peer manager and 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.
7.2.11 Publishing to depots

It is 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.
7.2.12 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.
185
Distribution process overview

At a very high level the distribution, install and the result process consists of six stages as shown in Figure 7-1.
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 7-1 Distribution process: high level
These stages are as follows: 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 when they contact DMS. 4. After authorization by the dynamic content delivery service management center, the client subagent receives a download plan and downloads the file from one or more depots or peers, or both and computes a checksum to ensure the integrity of the downloaded file. 5. The client runs installation instructions and returns the result to DMS. 6. The DMS updates the results into Tivoli Provisioning Manager.
7.3 Tivoli Common Agent Services

Tivoli Provisioning Manager uses Tivoli Common Agent Services for software distribution and desired state management. Today, many management applications can deploy the agent software across user systems or application
186
servers. The deployed agent collects data from and performs operations on managed resources on behalf of a Tivoli management application. Tivoli Common Agent Services consists of the Common Agent, the Agent Manager and the Resource manager.
7.3.1 Agent Manager

The Agent Manager is the server component of the Tivoli 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.
Registration Service
The Agent Manager includes a registration service which handles security certificates, registration, tracking of Common Agents and Resource Managers, and status collection and forwarding.
7.3.2 Resource manager

Each product that uses Tivoli Common Agent Services has its own Resource manager and subagents. For example, Tivoli Provisioning Manager for Software has a Resource manager and subagents for software distribution and software inventory scanning.
7.3.3 Tivoli Common Agent

Tivoli Provisioning Manager uses the Tivoli Common Agent for software management features, including software distribution and software compliance management. 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.
187
The Common Agent Services code is installed once on a managed endpoint. Each supported application will implement product-specific subagents that run under the common agent. 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 expiry 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.
188
7.4 Software Life Cycle

Tivoli Provisioning Manager for Software provides you with the capability of automating the processes in the life cycle of your managed systems. A typical managed system life cycle is illustrated in Figure 7-2.
Figure 7-2 Managed system life cycle
To populate the DCM with the physical and logical assets to be managed by Tivoli Provisioning Manager you will generally start by performing a discovery. This will find the devices and the operating systems, and software installed on them. Tivoli Provisioning Manager can install a new operating system onto the managed systems as required. Tivoli Provisioning Manager for Software records all the software defined in the data model in the Software Catalog. Software Packages are stored in file repositories linked to the Software Catalog. Tivoli Provisioning Manager can install the required software on each computer. By using the compliance checks in Tivoli Provisioning Manager it is possible to determine which devices are compliant or not. Tivoli Provisioning Manager can then remediate the noncompliant systems by installing the appropriate software or take other actions to bring the systems into compliance. Tivoli Provisioning Manager can be configured to automatically retrieve patches from third party repositories and apply these as necessary after approval.
189
When it is determined that some of the systems in the enterprise can be redeployed, Tivoli Provisioning Manager can reinstall the operating system or replace the installed software stack with different applications.
7.5 Security model

This section discusses the Tivoli Provisioning Manager security model.
7.5.1 User authentication and accounts

Authentication is needed for all users that access the Tivoli Provisioning Manager server. User IDs and passwords are stored in the Lightweight Directory Access Protocol (LDAP) server. The encryption of the passwords is governed by the LDAP registry. A user can be given the superuser property. A superuser is not restricted by access group permissions and thus has full control over all devices and actions in the DCM.
7.5.2 User authorization

User authorization is based on the combination of user roles, access groups and permissions groups.
7.5.3 User roles and accounts

Tivoli Provisioning Manager uses role-based security. User roles are primarily used to control what a user can access in the user interface. A role is defined as a set of basic permissions. User roles are stored in the LDAP registry. A user can have multiple roles. Only a user with the correct set of roles can log on and view the pages in the user interface.
7.5.4 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.
190
7.5.5 Permission groups

Permission groups define what kind of access a user has to 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
7.5.6 Access Permission group

By combining access groups and permission groups you declare what kind of operations users are allowed to perform on which objects or groups of objects.
191
192
Chapter 8.
Sample questions
This chapter provides a number of sample questions that are based on the actual Tivoli Provisioning Manager V5.1 certification questions. Please note that these are only sample questions deriving from and not the actual questions on the certification test. You will also find the answer key at the end of the chapter.
193
8.1 Sample questions

1. What is the minimum number of servers that must be configured to support the scalable distribution infrastructure? (Choose one.) a. One b. Two c. Three d. Four 2. Which statement is true about software distribution using the scalable distribution infrastructure? (Choose one). a. The device management service contacts the Tivoli Common Agent whenever a distribution is ready for that device. b. The dynamic content distribution service contacts the Tivoli Common Agents whenever a distribution is ready for that device c. The Tivoli Common Agent contacts the dynamic content distribution service and requests distributions. d. Files can only be distributed from depot servers to Tivoli Common Agents. e. Files distributed to Tivoli Common Agents can be cached on the device. 3. Which of these statements are true about software distribution using the scalable distribution infrastructure? (Choose two.) a. Files are automatically removed from a depot when their distribution is complete if they were not explicitly published to the depot. b. Files can be unpublished from selected depot servers. c. The dynamic content distribution service will select depots from within the same region as the target if any are available. d. A Tivoli Common Agent can act as a peer for any other Tivoli Common Agent in the enterprise. e. A zone can be defined with both an IP address range and a domain. 4. Which of these statements is true regarding workflows and Logical Device Operations? (Choose one.) a. Workflows can read but not write to the data centre model. b. Simple scripts can be embedded within workflows. c. No Logical Device Operations are provided by default. d. You can not create custom Logical Device Operations.
194
e. Devices can be associated with a maximum of one Logical Device Operation. 5. What can be contained within an Automation Package? (Choose three.) a. Commands b. Workflows c. Software Package Blocks d. Operating System Images e. Java plug-ins 6. Regarding user security, which of these is correct (Choose one.) a. Users can only be restricted to accessing specific resources b. Users can only be restricted to perform specific operations. c. Users can be restricted to accessing specific resources and performing specific operations. d. Users can assume the authorization of other users. 7. When looking at the life cycle of a managed computer, what must be performed before software can be installed on the device? (Choose one.) a. The Operating System must be installed by Tivoli Provisioning Manager. b. Windows computers must have been discovered using the Microsoft Active Directory discovery configuration. c. The device must be redeployed to a specific depot server. d. The device must be present in the data center model. 8. What behavior will be observed when the credentials for a UNIX target box are not delivered separately for the install_agent workflow. a. The workflow will use the credentials provided for the network discovery configuration (ssh) b. The workflow will fail with message: missing credentials c. The workflow will refuse to start with message: no access point defined 9. Which is the message format of deployment engine messages: a. COPDEP###Z b. COPDEX###Z c. TPMDEX###Z d. TPMCOM###Z
Chapter 8. Sample questions
195
10.In which file the log level for the Deployment Engine JVM logfiles can be adjusted: a. $TIO_LOGS/config/log4j.config b. $TIO_HOME/xml/logging.xml c. $TIO_HOME/config/log4j.prop d. $TIO_LOGS/deploymentengine/log.conf 11.How can you make sure a depot is active? a. Run agentcli depotserver alive locally on the Tivoli common agent hosting the agent. b. Select Reports Deployment and select Run for report: which depot is active ? c. Select Inventory Infrastructure Management Depots. 12.In which output styles can report results be displayed? (Choose two) a. GIF (Gif Image) b. HTML with Graph c. XLS (Microsoft Excel file) d. TXT (Text file) e. CSV (Comma Separated Value file) f. ZIP (Compressed zip file) 13.Where do you navigate in the web interface in order to find what objects were discovered by which discovery configuration? a. Inventory Manage Inventory Computers b. Inventory Manage Discovery Discovered Computers c. Reports Inventory d. Reports Discovery 14.Which information is required to perform a Windows SMB network discovery? a. The Windows domain of all targets. b. User name and password to connect on all targets. c. The full qualified hostname of the targets d. Credentials associated with a service access point for all targets. 15.Where are automation packages stored? a. In the File Repository on the Tivoli Provisioning Manager Server
196
b. On the Tivoli Provisioning Manager Server in the directory %TIO_HOME%\bin c. On the Tivoli Provisioning Manager Server in the directory %TIO_HOME%\packages d. On the Tivoli Provisioning Manager Server in the directory %TIO_HOME%\driver 16.On which server must you install the Rembo Toolkit? a. The Rembo Toolkit is included in Tivoli Provisioning Manager for Software. b. On a PXE Boot server. c. On any managed computer that has a RXA service access point defined d. On a Depot server where the Rembo Agent is installed. 17.What is the purpose of a software stack? a. You can consistently install the same software in the correct order and with the same configuration. b. A software stack automatically updates the software catalog by using the Windows Server Update Service (WSUS). c. You can bundle several software package blocks in a zipped format. d. A software stack includes multiple iterators. 18.What is a software configuration template? a. New access groups are created from software configuration templates. b. You can create a favorite task based on software configuration templates. c. A software configuration template is used to create a software resource on target systems d. An image stores hardware requirements in a software configuration template. 19.Determining the communication protocols and services to be used between the management servers and the managed devices, which statement is true about the IBM Tivoli Provisioning Manager? a. Simple Network Management Protocol (SNMP) requires port 161 to be opened for traffic from management servers to devices b. SNMP requires port 161 to be opened for traffic from devices to management servers c. SNMP requires port 160 to be opened for traffic from management servers to devices
197
d. SNMP requires port 160 to be opened for traffic from devices to management servers 20.{Which three topologies can be installed by the IBM Tivoli Provisioning Manager V5.1 Installer on a Solaris platform? (Choose three.) a. Remote Installation, Single-node server, for Solaris 9 b. Remote Installation, Two-node server, for Solaris 9 c. Local Installation, Single-node server, for Solaris 10 d. Remote Installation, Two-node server for Solaris 10 e. Local Installation, Three-node server, for Solaris 9 21.Which of these statements are true about Cygwin installation for Windows operating system? (Choose two.) a. The Topology Installer Launcher can automatically perform this installation if you run the installer on a Windows computer. b. The Topology Installer Launcher can not automatically perform this installation if you run the installer on a Windows computer. c. If the Topology Installer Launcher is on Linux and remotely install Tivoli Provisioning Manager on a Windows computer, the Cygwin is installed automatically on the target Windows computer. d. If the Topology Installer Launcher is on Linux and remotely install Tivoli Provisioning Manager on a Windows computer, you must manually install Cygwin on the target Windows computer. e. If the Topology Installer Launcher is on Linux and remotely install Tivoli Provisioning Manager on a Windows computer, the Cygwin is not required.
8.2 Answer Key

Answers: 1. b 2. e 3. a, c 4. b 5. a, b, e 6. c 7. d
198
8. b 9. c 10.c 11.a 12.b, e 13.d 14.b 15.d 16.c 17.a 18.c 19.a 20.c 21.a, b, d 22.a, d 23.a 24.c 25.a 26.a, b, d 27.a, d
199
200
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 201. Note that some of the documents referenced here may be available in softcopy only. Deployment Guide Series: IBM Tivoli Provisioning Manager Version 5.1, SG24-7261
Online resources
These Web sites are also relevant as further information sources: Tivoli Provisioning Manager V5.1 Implementation certification test link
http://www-03.ibm.com/certify/tests/obj898.shtml
IBM Professional Certification Program Web site:

http://www.ibm.com/certify/index.shtml
IBM IT Training Web site:

http://ibm.com/training
Tivoli Provisioning Manager V5.1 online publications Web site:

http://publib.boulder.ibm.com/infocenter/tivihelp/v13r1/index.js
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
201
Help from IBM

IBM Support and downloads ibm.com/support IBM Global Services ibm.com/services
202
Index
A
accessing remote drives 115 adaptive bandwidth control 182 administrative domain 76 APDE 50 application management 74 creating a cluster domain 77 management server domain 77 peer domain 77 creating a customer 75 creating a resource pool 76 creating an administrative domain 76 application tier 76 assessment test 5 associating SAP credentials 71 audit report 78 automation package 168 Automation Package Developer Environment 50 APDE views 61 configuring APDE preferences 61 configuring database connectivity 53 configuring deployment engine connectivity 58 prerequisites 58 creating automation packages 169 creating new workflow 169 exporting created or modified workflows 173 installation 52 installation requirements 51 connectivity 52 hardware 51 operating system 51 software 51 modifying existing automation packages 170 starting the APDE 59 using 167 working with workflows 170 automation packages 81 creating 83 creating a workflow 84 installation 81 updating 82 available bandwidth 182
B
Blade chassis admin server 131 boot server 131 build.xml 84 built format 138 bulk data distribution 180
C
cbe.log 94 certification checklist 5 IBM Certification certification certificate 6 IBM Professional Certification mark 6 IBM Professional Certification Program 2 benefits 3 Tivoli Software Professional Certification 4 benefits 4 CIT 45 CIT Scanner scan utility 44 cloudscape 23, 55, 57, 183 cluster domain 77 code 15T890 8 Common Agent Services 187 agent manager 21 Common Base Event format 94 Common Base Event logs 96 Common Inventory Technology 45 compliance management 139 adding a software compliance check 139 adding security compliance check 139 handling recommendation 141 running inventory scan and compliance check 140 verifying changes 142 compliance report 78 computer DCM object 176 console.log 94 continuous operation 188 copy file 177 creating virtual server template 149 credentials search key 66
203
D
data center model 176 application tier 177 customer 177 device drivers 178 management operations and LDO 177 objects 176 resource pool 177 workflow 178 DB2 57 DCM 176 deployment report 78 depot 19 depot issues 110 depot server 181 Device Management Server 183 Device Management Service 183 concepts 184 device management federating agents 183 Device manager jes.properties file 184 polling interval how to change 184 subagents 184 device manager subagents 184 federator 18 sending jobs to TCA 184 Service Access Point 184 device management service concepts 184 job management service 183 jobs 183 server 183 device management service federating agent 18 device management service federator 18 device manager subagent 18 discovering operating system attributes 158 discovery 64 IBM Discovery Library Reader 64 Microsoft Active Directory 64, 69 Rembo hardware discovery 64 scan types 64 devices 64 others 65 software 65 Tivoli Provisioning Manager Inventory 64 Tivoli Provisioning Manager network 64 discovery policy 130 add policy 130
creating a change record 130 delete policy 130 update policy 130 updating the data center model 130 discovery report 78 distribution agent 181 doc 84 download manager 181 dynamic content delivery service 180 management center 181 dynamic content delivery services management center 18 dynamic content delivery services subagent 20
E
eclipse environment 168 eclipse installation 5657 eDMS servers 183 enabling host access 114 enabling the boot from network interface card 158 examination score report 6 execute command 177 execute program action 136 Extensible Markup Language 164
F
file repository 87, 131, 179 forceInstallDriver 82
G
General Package Properties window 134 Golden_master image 159 groups 73, 144 creating a dynamic group 74 creating a static group 73
H
heartbeat function 188 host platform quantity 151
I
IBM Certification agreement 6 Professional Certification mark 6 Test 898 7 IBM Discovery Library Reader 67 configuration 131
204
IBM Tivoli Provisioning Manager redbooks 9 IBM TPM redbooks 9 imaging 152 capturing an image with Rembo Boot Server 156 defining operating system 158 deploying an image with Rembo Boot Server 160 installing a boot server 154 installing an image 161 preparing the Sysprep tool for Windows images 157 setting the BIOS startup sequence 159 starting the image capture process 159 implements ldo-name 172 inside the distribution process 185 overview 186 install patch wizard 112 installing behind a firewall 42 Installing Tivoli Provisioning Manager V5.1 29 installing Tivoli Provisioning Manager V5.1 29 inventory report 78 IP Address Response Timeout 66
Logical Device Operations 177 LWI 23
M
management center 181 managing security 119 adding a new user 123 assigning a security role to a user 125 associating access and permission groups to a user 126 associating objects to an access group 122 creating a permission group 121 creating a security role 120 creating an access group 121 enabling access control 127 MaxBackupIndex 99 MaxFileSize 99 maximum password age 140 META-INF 84 Microsoft Active Directory 37 Microsoft End User License Agreement 38 Microsoft Windows Server Update Services 179 minimum password length 140 minimum password reuse count 140 monitoring agent 181 msg.log 94 mx256m value 115
J
job management service 183
L
large branch office 25 large data center 24 large software packages 115 LDAP 119, 190 LDAP registry 190 LDO 177 ldo-name 172 Light Stack Tivoli Provisioning Manager 23 Lightweight Directory Access Protocol 119, 190 Lightweight Infrastructure 23 load balancer 131 LocaleInsenseitive 172 LocalFileRepository 179 log files 93 log4j 95 log4j.prop 95 logfile types 94 logging tool 95 logical device 177 Logical Device Operation 177
N
NAT 185 NAT environments 185 Network Address Translation 185 network discovery and agent distribution 127 creating an inventory discovery scan 129 preparing network discovery 128 non-built formats 138
O
OAMPI 17 object wrapping 179 Open Services Gateway Initiative 187 OSGi bundles 187 OSGi 187
P
package explorer 84
Index
205
Pearson Virtual University Enterprises 6 peer manager 181 peer-to-peer file sharing 185 performance tuning 112 configuring maximum number of concurrent jobs 112 workflow performance 113 performing the discovery task 132 preferred upload servers 182 pre-installation checklist 39 additional software requirements 40 Cygwin software for Windows 40 GNU tar 41 static IP address 41 prerequisite software versions 41 TIL requirements 39 preparing the Sysprep tool for Windows images 157 publishing to depots 185 PXE Boot server 153
S
SAP 70, 184 saving a software package 138 scalability 15 scalable distribution 179 Scalable Distribution Infrastructure components ports used 26 scriptlet keyword 113 Secure Shell 128 security model 190 security officer 127 Server Message Block 128 Service Access Points 70 credentials 71 setting administrator password 158 setting loglevel 95 Simple Network Management Protocol 128 Simple Object Access Protocol 164 small branch office 24 small data center 23 SMB protocol 43 snapshot image 159 SNMP discovery 67 SOA Service Access Point 184 SOAP 164, 184 software catalog 145, 180 external software catalog 146 file server 145 software definition 179 software distribution 162 software installable 176, 179 software installation 162 Software Installation Engine (SIE) 180 Software Installation objects 180 Software Life Cycle 189 software management 143 software package 138, 179 software package block 133, 179180 software package block format 138 software package definition format 138 Software Package Editor 85, 114, 133, 179 adding directory object 136 checking disk space action 134 execute program action 136 saving a software package 138 using the SPE 134 software product 179 software product requirement 180
R
recertification 7 recommended educational resources 5 recommended publications 9 recommended resources for study 8 Redbooks Web site 201 Contact us xix regions 182 Rembo Auto-Deploy 153 Rembo Automation Package 82 Rembo Technology 153 Rembo Toolkit 82, 153 Rembo Toolkit 4.0 153 rembo.tcdriver is 153 Remote Execution and Access 70 report constraint 78 report description 78 report layout 78 report summary 78 reports 78 repository 84 requirements on target endpoints 163 resource pool 76 return on investment 5 ROI 5 RXA-BootStrap-Server 72
206
software resource 179 software stack 143, 179180 configuration templates 144 installables 144 modules 143 requirements and capabilities 144 SoftwareInstallable DCM object 176 src 84 ssh daemon 128 SSH discovery 66 SSH protocol 43 SSH-Server service access point 72 static group 73 subsystem messages 94 superuser 125, 190 supported installation topologies and OS versions 31 account required 39 AIX and Linux 33 one-node topology 31 Solaris 34 two-node topology 32 Windows 36 switch 177 switch DCM object 176 system management accross firewalls 25
T
TC-INF 84 Thomson Prometric 6 tioadmin user 91 TIOlog levelmessage 114 TIOsetVAR variable value 114 TIOthrow variablemessage 114 Tivoli Certified Consultant 7 Tivoli Common Agent 21, 187 agent installation 102 communication issues 109 RXA problems 105 service access point problems 106 time drift 103 agent manager 187 certificates 188 features 188 heartbeat function 188 installation 132 managed endpoint 187 resource manager 187
security credentials 188 services 186 updates 188 Tivoli Intelligent Orchestrator 52, 58 Tivoli Provisioning Manager accessing the console 118 Automation Package Developer Environment 15 components 12 demo installation 23 fully qualified host name 55 IBM Open Process Automation Library 15 infrastructure deployment considerations 22 installation fast start installation 30 regular installation 30 silent installation 30 installation infrastructure fast start installation 23 full enterprise installation 23 installation log files directory containing output from installation 47 installer logs 46 Tivoli common directory 46 installing behind a firewall 42 installing log files 46 inventory discovery 65 network discovery 65 Creating discovery using SSH or Windows SMB 66 discovering devices using SNMP 67 using SSH or Windows SMB 66 operator and administrator console 15 overview of the installation flow 43 installation phases 44 invoking the installer 43 post installation steps 45, 47 changing default passwords 48 importing sample data 49 provisioning server installation 45 provisioning sever automation 13 compliance and remediation 13 data center model 13 deployment infrastructure 14 discovery 14 provisioning database 13 reporting 13
Index
207
run a discovery 69 Scalable Distribution Infrastructure 17 Device Management Service 17 Dynamic Content Delivery Service 17 Tivoli Common Agent Services 17 supported platforms 21 user directory 15 Tivoli Provisioning Manager Certification getting your 15% discount 8 Tivoli Provisioning Manager Embedded Edition 44 Tivoli Provisioning Manager for OS Deployment Embedded Edition 153 Tivoli Provisioning Manager JVM directory 94 Tivoli Provisioning Manager V5.1 implementation certification 7 Tivoli software education 8 Tivoli Software Professional Certification 4 Benefits 4 test 898 objectives 8 Topology Installer Launcher 31 TPM directory structure 91 TPM essentials 90 eliminating possible causes 91 recording the symptoms of the problem 90 recreating the problem 90
storage templates 149 installing tcdriver 147 virtual server templates 150 VLAN 176
W
WAS 93 web services 164 Web Services Description Language 165 Web Services Resource Framework 166 web-based courses for certification 8 WebSphere Application Server 93 Windows Server Update Services 146 Windows SMB discovery 66 workflow 84, 178 workflow syntax 172 workflow troubleshooting 100 setting loglevel 100 workflow execution logs 101 WSDL 165 WSRF 166
X
x86 architecture 153 XML 84, 164
U
uploading 182 user role for software distribution 163 user roles 190 user security access groups 190 access permission group 191 permission groups 191 user authentication 190 user authorization 190 user roles and accounts 190
Z
zones 182
V
virtual server quantity 151 virtual servers 146 adding resource requirements 150 adding resource to host platform server 148 allocating the virtual server 151 creating a host platform server 148 creating a virtual server template 149 creating virtual server tepmlate 149 computer templates 149
208
(0.2spine) 0.17<->0.473 90<->249 pages
Back cover
Certification Guide Series IBM Tivoli Provisioning Manager V5.1

Helps you become a certified Tivoli Provisioning Manager V5.1 professional Explains the certification path and prerequisites you require Includes best practices for Software Distribution
IBM Tivoli Provisioning Manager, built on a Service Oriented Architecture, enhances usability for executing changes while keeping server and desktop software compliant. It helps organizations with provisioning, configuration and maintenance of servers and virtual servers, operating systems, middleware, applications, storage and network devices acting as routers, switches, firewalls, and load balancers. This IBM Redbook is a study guide for IBM Tivoli Provisioning Manager V5.1 for people who want to get an IBM Professional Certification for this product. The IBM Tivoli Provisioning Manager V5.1 Certification, offered through the Professional Certification Program from IBM, is designed to validate the skills required of technical professionals who work in the implementation of the IBM Tivoli Provisioning Manager V5.1 product.This book provides a combination of theory and practical experience needed for a general understanding of the subject matter and sample questions that will help in the evaluation of personal progress and provide familiarity with the types of questions in the exam. The chapters are based on the sections of the Tivoli Provisioning Manager V5.1 Implementation Certification test. Studying each chapter will help you prepare for one section of the exam.
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-7262-00 ISBN 0738489611

Certification Guide Series IBM Tivoli Provisioning Manager V5.1 Sg247262

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Certification Guide Series IBM Tivoli Provisioning Manager V5.1 Sg247262

Uploaded by

Copyright:

Available Formats

Front cover

Certification Guide Series

Copyright IBM Corp. 2007. All rights reserved.

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Copyright IBM Corp. 2007. All rights reserved.

6-12 6-13 6-14 6-15

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Copyright IBM Corp. 2007. All rights reserved.

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Copyright IBM Corp. 2007. All rights reserved.

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Copyright IBM Corp. 2007. All rights reserved.

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

The team that wrote this redbook

Copyright IBM Corp. 2007. All rights reserved.

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Become a published author

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Copyright IBM Corp. 2007. All rights reserved.

1.1 IBM Professional Certification Program

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

1.1.1 Benefits of certification

For IBM Business Partners and consultants:

Chapter 1. Certification overview

1.1.2 Tivoli Software Professional Certification

Benefits of Tivoli certification

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Chapter 1. Certification overview

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

1.2 Tivoli Provisioning Manager V5.1 Implementation certification

Chapter 1. Certification overview

1.2.1 Test 898 objectives

1.3 Recommended resources for study

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

IBM Tivoli Provisioning Manager V5.1 redbooks

Chapter 1. Certification overview

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Planning and architecture

Copyright IBM Corp. 2007. All rights reserved.

2.1 Tivoli Provisioning Manager V5.1 components

Figure 2-1 Tivoli Provisioning Manager architecture

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Chapter 2. Planning and architecture

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Chapter 2. Planning and architecture

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

2.2.1 Scalable Distribution Infrastructure for Tivoli Provisioning Manager v.5.1

Chapter 2. Planning and architecture

Device Management Service Federator

Device Management Service Federating Agent

Device manager subagent

Dynamic content delivery services management center

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Chapter 2. Planning and architecture

Dynamic content delivery services subagent

Figure 2-2 Tivoli Provisioning Manager Server

Certification Guide Series: IBM Tivoli Provisioning Manager V5.1

Common Agent Services Agent Manager

Tivoli common agent

2.3 Supported Platforms for Tivoli Provisioning Manager version 5.1

HP-UX Windows 2000