Certification guide series ibm tivoli provisioning manager v5.1 sg247262
Upcoming SlideShare
Loading in...5
×
 

Certification guide series ibm tivoli provisioning manager v5.1 sg247262

on

  • 1,146 views

 

Statistics

Views

Total Views
1,146
Views on SlideShare
1,146
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Certification guide series ibm tivoli provisioning manager v5.1 sg247262 Certification guide series ibm tivoli provisioning manager v5.1 sg247262 Document Transcript

  • Front coverCertification Guide SeriesIBM Tivoli ProvisioningManager V5.1Helps you become a certified TivoliProvisioning Manager V5.1Explains the certification pathand prerequisites you requireIncludes best practicesfor Software Distribution Vasfi Gucer David Campbell Martin Caesar Markus Helbig Fabrizio Salustri Petra Unglaubibm.com/redbooks
  • International Technical Support OrganizationCertification Guide Series: IBM Tivoli ProvisioningManager V5.1January 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 ADPSchedule 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64iv 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.2 Service access points (SAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.3 Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.4 Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.4.1 Creating a static group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.4.2 Creating a dynamic group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.6 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.8 Software Package Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Chapter 5. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.2 Directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.3 Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.3.1 Log file types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.3.2 Subsystem messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.3.3 Setting log level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.4 Workflow troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.1 Setting log level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4.2 Workflow execution logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.6 Depot issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105.7 Performance tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Contents v
  • 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 . . . . . . . . . . . . . . . . 160vi Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 1636.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. . . . . . . . . . . . . . . . . . . . . . . 1666.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 . . . . . . . . . . . . . . . . . . . 173Chapter 7. Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787.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. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1857.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203viii Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Figures 2-1 Tivoli Provisioning Manager architecture . . . . . . . . . . . . . . . . . . . . . . . . . 12 2-2 Tivoli Provisioning Manager Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3-1 One-node AIX topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3-2 Solaris 9 one-node topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3-3 Solaris 9 or Solaris 10 two-node topology. . . . . . . . . . . . . . . . . . . . . . . . . 35 3-4 Windows one-node topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3-5 Windows two-node topology with Microsoft Active Directory . . . . . . . . . . 37 3-6 Windows two-node topology with Tivoli Directory Server . . . . . . . . . . . . . 38 3-7 APDE architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3-8 Automation Package view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4-1 Add service access point dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4-2 Add credentials to service access point . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4-3 Service access point (SAP) configured for common agent . . . . . . . . . . . . 72 4-4 Add static group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4-5 Add dynamic group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4-6 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© Copyright IBM Corp. 2007. All rights reserved. ix
  • 6-12 Add external software catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 6-13 Add Boot Server Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 6-14 Starting the Rembo Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 6-15 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189x Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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© Copyright IBM Corp. 2007. All rights reserved. xi
  • xii Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Examples 3-1 Installation log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3-2 Registering the node and the database . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3-3 .jar file location update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3-4 .jar file location update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4-1 Command listing automation packages . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4-2 Workflow deletes target deviceID from data center model . . . . . . . . . . . . 85 4-3 Import server certificate to java keystore . . . . . . . . . . . . . . . . . . . . . . . . . 87 5-1 log4j.prop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5-2 TImedrift error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5-3 Failing RXA access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5-4 Missing SAP definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5-5 eclipse.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6-1 soapclient.cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166© Copyright IBM Corp. 2007. All rights reserved. xiii
  • xiv Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • NoticesThis 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. Consultyour 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 IBMproduct, program, or service may be used. Any functionally equivalent product, program, or service thatdoes not infringe any IBM intellectual property right may be used instead. However, it is the usersresponsibility 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 licenseinquiries, 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 suchprovisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATIONPROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS ORIMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimerof 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 madeto the information herein; these changes will be incorporated in new editions of the publication. IBM maymake improvements and/or changes in the product(s) and/or the program(s) described in this publication atany time without notice.Any references in this information to non-IBM Web sites are provided for convenience only and do not in anymanner serve as an endorsement of those Web sites. The materials at those Web sites are not part of thematerials 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 withoutincurring any obligation to you.Information concerning non-IBM products was obtained from the suppliers of those products, their publishedannouncements or other publicly available sources. IBM has not tested those products and cannot confirmthe accuracy of performance, compatibility or any other claims related to non-IBM products. Questions onthe 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 themas 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 businessenterprise is entirely coincidental.COPYRIGHT LICENSE:This information contains sample application programs in source language, which illustrate programmingtechniques on various operating platforms. You may copy, modify, and distribute these sample programs inany form without payment to IBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operating platform for which thesample 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.© Copyright IBM Corp. 2007. All rights reserved. xv
  • TrademarksThe following terms are trademarks of the International Business Machines Corporation in the United States,other countries, or both: Redbooks (logo) ™ AIX® PowerPC® ibm.com® Cloudscape™ Redbooks™ pSeries® DB2 Universal Database™ Tivoli® xSeries® DB2® WebSphere® zSeries® IBM® AIX 5L™ Library Reader™The following terms are trademarks of other companies:Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or itsaffiliates.SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several othercountries.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 GovernmentCommerce, 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 SunMicrosystems, Inc. in the United States, other countries, or both.Active Directory, Excel, Internet Explorer, Microsoft, Windows Server, Windows, and the Windows logo aretrademarks 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 registeredtrademarks 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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© Copyright IBM Corp. 2007. All rights reserved. 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 UKs 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 USxviii Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Youll 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, youll 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.htmlComments 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 1 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© Copyright IBM Corp. 2007. All rights reserved. 1
  • 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.2 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 For employers: – 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 For IBM Business Partners and consultants: – Provides independent validation of technical skills – Creates competitive advantage and business opportunities – Enhances prestige of the team – Contributes to IBM requirements for various IBM Business Partner programs Chapter 1. Certification overview 3
  • 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 todays 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 cards4 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 needsCertification checklistHere 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 Chapter 1. Certification overview 5
  • 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.6 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Chapter 1. Certification overview 7
  • – 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.shtml1.2.2 How to get your 15% discount on the Tivoli ProvisioningManager 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/training8 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 1. Certification overview 9
  • 10 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 2 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© Copyright IBM Corp. 2007. All rights reserved. 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Chapter 2. Planning and architecture 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 a16 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 consoles2.2.1 Scalable Distribution Infrastructure for TivoliProvisioning 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. Chapter 2. Planning and architecture 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • DepotA depot server is a system that stores files in a designated directory ready fordistribution to target systems. Depot servers can also replicate these files toother 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. Chapter 2. Planning and architecture 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 Server20 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 ProvisioningManager 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 Tivoli Provisioning Manager Tivoli Common Agent 1.3 server 5.1 IBM AIX 5L v5.2 64 bit ML7 5L v5.1 (32 and 64 bit) 5L v5.3 64 bit Power5 ML1 5L v5.2 (32 and 64 bit) 5L v5.3 (32 and 64 bit) Sun™ Solaris™ 9 on Sun SPARC Server 8 (32 and 64 bit) 10 on Sun SPARC Server 9 (32 and 64 bit) 10(32 and 64 bit) HP-UX - 11i (32 and 64 bit) Windows® 2000 - Professional SP2 Server SP4 Advanced Server SP2 Windows XP Professional SP1(fast start only) Professional SP1 Professional SP2 (fast start only) Professional SP2 Windows Server® 2003 Standard Edition SP1 Standard Edition Enterprise Edition SP1 Standard x64 Edition Enterprise Edition Enterprise x64 Edition Chapter 2. Planning and architecture 21
  • Operating Systems Tivoli Provisioning Manager Tivoli Common Agent 1.3 server 5.1 Linux® Intel® Family RHEL 4.0 32 bit update 3 RHEL 3.0 32 bit SLES 9.0 32 bit SP3 RHEL 4.0 32 bit SLES 8.0 32 bit SLES 9.0 32 bit Linux AMD64/EM64T - REHL 4.0 64 bit SLES 9.0 64 bit Linux i/p Series Family (64-bit) - RHEL 3.0 RHEL 4.0 SLES 8.0 SLES 9.0 Linux zSeries® - SLES 8.0 31 bit SLES 9.0 64 bit 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 office22 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Chapter 2. Planning and architecture 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 center2.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 direct24 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 customer’s 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. Chapter 2. Planning and architecture 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 Source Source Destination Destination Destination Connection system Component port system component port security Tivoli CDS Any Depot CDS depot 2100 Secure SSL Provisioning Management server Manager Center server Depot CDS depot Any Depot CDS depot 2100 Secure SSL server server Tivoli CDS Any Depot CDS depot 2100 Secure SSL common subagent server agent Depot CDS depot Any Tivoli CDS 9045 Secure SSL server Provisioning Management 9046 Manager Center26 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Source Source Source Destination Destination Destination Connectionsystem Component port system component port securityTivoli DMS Any Tivoli DMS 9045 Secure SSLcommon subagent Provisioning federated 9046agent Manager agentTivoli CDS Any Tivoli CDS 9010 Secure SSLcommon subagent Provisioning Management 9015agent Manager CenterTivoli Agent Any Tivoli Tivoli 9510 Secure SSLProvisioning Manager common commonManager agent agentTivoli Nonstop Any Tivoli Tivoli 9514 Unsecurecommon process common common 9515agent agent agentTivoli Tivoli Any Tivoli Agent 9511 Secure SSLcommon common Provisioning Manageragent agent ManagerTivoli Tivoli Any Tivoli Agent 9512 Secure SSLcommon common Provisioning Manager with Clientagent agent Manager Authenticatio nTivoli Tivoli Any Tivoli Agent 9513 Unsecurecommon common Provisioning Manageragent agent Manager Chapter 2. Planning and architecture 27
  • 28 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 3 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© Copyright IBM Corp. 2007. All rights reserved. 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 operatingsystem 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 Installer invocation Supported topology AIX Local one-node only Linux on Intel Local one-node only Linux on PowerPC® Linux on zSeries(31 Bit) Linux on zSeries(64 Bit) Solaris (Sun SPARC) Remote one-node or two-node for Solaris 9 two-node for Solaris 10 Windows Remote one-node two-node (with Tivoli Directory Server or Microsoft Active Directory)32 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Chapter 3. Installing Tivoli Provisioning Manager V5.1 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Figure 3-3 shows a diagram of the two-node installation on Solaris 9 or Solaris10machines.Figure 3-3 Solaris 9 or Solaris 10 two-node topologyIn this case, the directory server node must have a DB2 database required byIBM 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 Chapter 3. Installing Tivoli Provisioning Manager V5.1 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 topology36 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Figure 3-5 shows a diagram of the two-node installation on Windows withMicrosoft Active Directory as directory server.Figure 3-5 Windows two-node topology with Microsoft Active Directory Chapter 3. Installing Tivoli Provisioning Manager V5.1 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 account3.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 Server type Processor Minimum free RAM system speed disk space AIX 5.2 IBM pSeries® 1GHz CPU Installer and Minimum 2 GB AIX 5.3 image repository: 7 GB Linux 32 bit IBM 2.8 GHz Intel Installer and Minimum 2 GB SLES 9 with compatible PC Pentium® 4 image SP3 processor or repository: 7 RedHat 4.0 equivalent GB with Update 3 Solaris 9 Sun SPARC 1GHz CPU Installer and Minimum 2 GB Solaris 10 image repository: 7 GB /opt directory: 2 GB Chapter 3. Installing Tivoli Provisioning Manager V5.1 39
  • Operating Server type Processor Minimum free RAM system speed disk space Windows 32 bit IBM 2.8 GHz Intel /tmp directory: Minimum 2 GB 2003 Server compatible PC Pentium 4 6 GB EE with SP1 processor or 2003 Server equivalent SE with SP13.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=swg212493803.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:cygwinbin 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Supported applications Database DB2 Universal Database Enterprise Server Edition 8.2, Fix Pack 11 Application server WebSphere Application Server 6.0, Fix Pack 2 with latest interim fix. In case you plan to use an existing user account on an existing directory server with Tivoli Provisioning Manager, user IDs cannot contain double-byte characters. Directory server Tivoli Directory Server 6.0, Fix Pack 1 Web browser 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 Chapter 3. Installing Tivoli Provisioning Manager V5.1 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 Protocol Source Destination From To Port Port DHCP REQUEST UDP any 67 managed provisioning (broadcast) servers server DHCP REPLY UDP 67 68 provisioning managed server servers PROXY DHCP UDP any 4011 managed provisioning servers server TFTP UDP any 69 managed provisioning servers server BootDiscovery UDP any 4011 managed provisioning (multicast) servers server MTFTPPort UDP any 4015 managed provisioning servers server MTFTPClients UDP any 8500 provisioning managed (multicast) server servers NBPServer UDP any 4012 managed provisioning servers server FileServerPort UDP any 4013 managed provisioning servers server FileMCAST- Address UDP any 10000 provisioning managed server servers FASTPort UDP any 4025 managed provisioning servers server SSH TCP any 22 provisioning managed server servers42 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Request Protocol Source Destination From To Port Port Telnet TCP any 23 managed provisioning servers server TS TCP any 3389 provisioning managed server servers SNMP UDP any 161 provisioning managed server servers SNMP-TRAP UDP any 162 managed provisioning servers server SMB / NetBIOS TCP any 139 provisioning managed server servers Agent manager TCP any 9511,9512, provisioning managed 9513 server servers WebSphere Application TCP any 9080,9082, provisioning managed Server 6.0 9043,9045, server servers 9046 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 -. Chapter 3. Installing Tivoli Provisioning Manager V5.1 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_pointsetupwin32.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 the44 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Service6. 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. Chapter 3. Installing Tivoli Provisioning Manager V5.1 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.log3.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/common46 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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.log3.9 Post installation steps This section describes the configuration tasks to perform after the installation. Chapter 3. Installing Tivoli Provisioning Manager V5.1 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 Default password Description tioadmin user-defined at installation Defined in the time 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 accounts48 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • User name Default password Description wasadmin wasadmin 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 actions3.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" Chapter 3. Installing Tivoli Provisioning Manager V5.1 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 architecture50 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 3.10.1 Automation Package Developer Environmentinstallation 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_HOMEeclipse 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. Chapter 3. Installing Tivoli Provisioning Manager V5.1 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 javabin directory is in your PATH environment variable. For example: PATH=C:IBMWebSphereAppServerjavajrebin 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 a52 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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_HOMEeclipse. – The Automation Package Developer Environment files in apde.zip. The apde.zip file is located in the TIO_HOMEapde 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 Chapter 3. Installing Tivoli Provisioning Manager V5.1 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 = TEST Comment = Directory entry type = LOCAL Protocol = TCPIP Hostname = paris.itsc.austin.ibm.com Service name = 5000054 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • db2 list database directoryThe output looks like the following:Database 2 entry: Database alias = TC1 Database name = TC Node name = TEST Database release level = a.00 Comment = Directory entry type = Remote Catalog database partition number = -1 Alternate server hostname = Alternate server port number = 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_HOMEconfigdcm.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_HOMEconfig directory on the Tivoli Provisioning Manager server: – crypto.xml – DB2 and Cloudscape: dcm.xml – Oracle: dcm-ORA.xml Chapter 3. Installing Tivoli Provisioning Manager V5.1 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 FilesSQLLIBjavadb2jcc.jar" /> <pathelement location="C:Program FilesSQLLIBjavadb2jcc_license_cu.jar" /> </classpath> 6. Start Eclipse. From the APDE_HOMEeclipse 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_HOMEconfig 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 102456 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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_HOMEconfig 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:IBMSQLLIBjavadb2java.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.pluginscom.ibm.tivoli.orchestrator.tcdriverdevelopmen tconfigdcm.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 location="C:APDE_HOMEeclipsepluginsorg.apache.derbyderby.jar" /> <pathelement location="C:APDE_HOMEeclipsepluginsorg.apache.derbyderbynet.jar" /> <pathelement location="C:APDE_HOMEeclipsepluginsorg.apache.derbyderbyclient.jar" /> <pathelement location="C:APDE_HOMEeclipsepluginsorg.apache.derbyderbytools.jar" /></classpath> Chapter 3. Installing Tivoli Provisioning Manager V5.1 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 -dev3.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. Chapter 3. Installing Tivoli Provisioning Manager V5.1 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 3.10.6 Configuring Automation Package DeveloperEnvironment 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. Chapter 3. Installing Tivoli Provisioning Manager V5.1 61
  • 62 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 4 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© Copyright IBM Corp. 2007. All rights reserved. 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 discovery4.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 Scan64 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Chapter 4. Configuration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 4. 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Chapter 4. Configuration 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 agent72 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 4. Configuration 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. A74 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Software4.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: Chapter 4. Configuration 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. Enter a name (required). 2. Select a server template from the list. 3. Select a locale from the list. 4. 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Enter a name (required). 2. Enter a description. 3. Select Cluster Domain Type peer or management server (required). 4. Select Target State. 5. Select a software definition to associate with. 6. Select an administrative software definition. 7. Select a cluster virtual IP. 8. Enter a port. 9. Click Save. Chapter 4. Configuration 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. Enter a name (required). b. Enter a description. c. Select a category. d. Enter a type. e. Select an access group from the list. f. 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Database view Column name access group: all accessgroup_cus_view END_USER_ID NAME The access groups associated IS_SUPERUSER to a user. INSTANCE_ACCESS_ROLE_ID ACCESS_DOMAIN_ID ACCESS_GROUP ACCESS_GROUP_DESCRIPTION base_audit: all base_audit_view SYSTEM_ID USERNAME Changes to software or INSTALL_TIME hardware on computers. TYPE RESOURCE_ID OPERATION base_deployment: all base_deployment_view MANAGED_SYSTEM_ID USERNAME Identifies the software that has INSTALL_TIME changed on computers. SOFTWARE_MODULE_ID INSTALL_STATE endpoints: all endpoint_inv_view SERVER_ID AGENT_UNIQUE_NAME Tivoli Common Agent status DESCRIPTION information. LAST_CONTACT_TS LAST_ATTEMPT_TS AGENT_START_TS LAST_BOOT_TS LAST_ERROR_MSG_TS LAST_ERROR_MSG LAST_REPORT_TS Chapter 4. Configuration 79
  • View name and description Database view Column name hardware inventory: all hardware_inventory_view SYSTEM_ID TYPE Details about the hardware on RESOURCE_NAME computers. RESOURCE_ID GROUP_NAME MANAGED PARTITIONABLE PROPERTY PROPERTY_VALUE hardware inventory: all hardware_inventory_view SYSTEM_ID TYPE RESOURCE_NAME Details about the hardware on RESOURCE_ID GROUP_NAME computers. MANAGED PARTITIONABLE PROPERTY PROPERTY_VALUE login history: all login_aud_view USERNAME SUCCESSFULL_LOGIN Tracks login history. ENTRY_POINT TIME_OF_LOGIN os: all os_info_view MANAGED_SYSTEM_ID MODULE_ID Information about operating OS_NAME systems. OS_VERSION software instance: all instance_on_sys_base_view RESOURCE_ID MODULE_ID The software that is installed on SYSTEM_ID computers, without details. IS_PENDING CURRENT_STATE DESIRED_STATE software: all software_info_view MODULE_ID SOFTWARE The available software in VENDOR software catalog. VERSION DESCRIPTION TYPE80 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • View name and description Database view Column namesoftware_computer: all software_server_view SOFTWARE VERSIONDetailed information about the SERVER_NAMEsoftware on computers. OS_NAME OS_VERSION POOL TIER CUSTOMER_NAME APPLICATION_NAME STATE MODULE_ID SERVER_ID TYPE DESCRIPTION CURRENT_STATE DESIRED_STATEsoftware history: all software_aud_view MANAGED_SYSTEM_ID USERNAMEChanges made to software on INSTALL_TIMEcomputers. MODULE_ID INSTALL_STATE SOFTWARE VENDOR VERSION DESCRIPTION4.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. Chapter 4. Configuration 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 Version Status ============== ================= ============= ... rembo 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 rembo82 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 4. Configuration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 4. Configuration 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:temptpmsrv.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:APDEeclipse and java in C:APDEeclipsejavajrebin.86 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Example 4-3 Import server certificate to java keystorecd C:APDEeclipsejavajrebinkeytool -import -v -keystore "..libsecuritycacerts" -filetemptpmsrv.cer -storepass "changeit" -alias helsinkiOwner: CN=helsinki.itsc.austin.ibm.com,CN=../agentmanager/eclipse/plugins/AgentManager, CN=CTGEM, CN=EC105180641A11D9B6B10011099B9740, CN=AgentManager, DC=itsc, DC=austin, DC=ibm, DC=comIssuer: CN=TivoliAgentManagerCA, DC=itsc, DC=austin, DC=ibm, DC=comSerial number: 3Valid from: Tue Nov 14 17:34:06 CST 2006 until: Fri Nov 11 17:49:06 CST2016Certificate 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:2FTrust this certificate? [no]: yCertificate was added to keystore[Saving ..libsecuritycacerts]After configuring the Software Package Editor preferences as describedpreviously, you can now open software packages from fileserver and save tofileserver. When saving to a fileserver, a dialog window prompts to select whichfile repository to use as shown in Figure 4-9.Figure 4-9 Select file repository for software package block Chapter 4. Configuration 87
  • 88 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 5 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© Copyright IBM Corp. 2007. All rights reserved. 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 boxes5.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 a90 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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.html5.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 Contents $TIO_HOME/config Contains all Tivoli Provisioning Manager configuration data entered during installation $TIO_HOME/repository Local software repository $TIO_HOME/soapclient Contains all soap scripts $TIO_HOME/xml Contains all data center model xml files. xmlimport.dtd defines the format of the xml files to be imported $TIO_HOME/tioprofile Default location of WebSphere profile created by Tivoli Provisioning Manager $TIO_HOME/tools Contains utilities used to manage Tivoli Provisioning Manager from CLI $TIO_HOME/drivers Automation package repository. Source location for tc-drivermanager command to install/remove automation packages $TIO_HOME/apde Contains installation image apde.zip, which contains the Eclipse plugins for APDE and SPE to be installed on dedicated machines $TIO_HOME/eclipse Contains eclipse image prepared to use SPE locally on Tivoli Provisioning Manager server $TIO_HOME/_uninst Contains the program to uninstall Tivoli Provisioning Manager $TIO_HOME/workspace Default location for self created APDE packages92 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Directory Contents $TIO_HOME/config Contains all Tivoli Provisioning Manager configuration data entered during installation $TIO_HOME/repository Local software repository $TIO_HOME/soapclient Contains all soap scripts $TIO_HOME/xml Contains all data center model xml files. xmlimport.dtd defines the format of the xml files to be imported $TIO_HOME/tioprofile Default location of WebSphere profile created by Tivoli Provisioning Manager $TIO_HOME/tools Contains utilities used to manage Tivoli Provisioning Manager from CLI $TIO_LOGS Default logfile location5.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 Description $TIO_LOGS/ Common log files $TIO_LOGS/j2ee WebSphere JVM™ log files Chapter 5. Troubleshooting 93
  • Path Description $TIO_LOGS/install Installation logfiles $TIO_LOGS/deploymentengine Deployment Engine JVM logfiles $TIO_LOGS/policyengine Policy Engine JVM logfiles $TIO_LOGS/tcdrivermanager.log Automationpackage log $TIO_LOGS/agentshellserver Agentshellserver log files $TIO:_HOME/../common/ctgde/logs Distribution log files $WAS_PROFILE_HOME/logs/server1 WebSphere server1 log files containing SystemOut.log, startServer.log, stopServer.log, SystemErr.log5.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. YYY94 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • This is the subsystem code. Table 5-3 contains all codes and the name of the matching subsystem. Table 5-3 Subsystem codes Subsystem- Subsystem Logdirectory/Logfile code COPCOM Common $TIO_LOGS/ COPDEX Deployment engine $TIO_LOGS/deploymentengine COPJDS Job distribution service $TIO_LOGS/ COPJEE J2EE™ $TIO_LOGS/j2ee COPPEZ Policy engine $TIO_LOGS/policyengine COPTCA Common agent $TIO_LOGS/ COPTDM TCdrivermanager $TIO_LOGS/tcdrivermanager.log COPUTL Utilities $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.pdf5.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 Chapter 5. Troubleshooting 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%noutput.error=%d{ISO8601} %-5p [%t] (%13F:%L): %m%noutput.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 seehttp://logging.apache.org/log4j/docs/api/index.html#log4j.appender.consolefile=org.apache.log4j.RollingFileAppenderlog4j.appender.consolefile.MaxFileSize=100MBlog4j.appender.consolefile.MaxBackupIndex=10log4j.appender.consolefile.File=${kanaha.logs}/console.loglog4j.appender.consolefile.layout=org.apache.log4j.PatternLayoutlog4j.appender.consolefile.layout.ConversionPattern=${output.normal}log4j.appender.consolefile.threshold=debuglog4j.appender.consolefile.append=true96 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • # errors to trace log file, for FFDC# rolling by log size#log4j.appender.errorfile=org.apache.log4j.RollingFileAppenderlog4j.appender.errorfile.MaxFileSize=10MBlog4j.appender.errorfile.MaxBackupIndex=10log4j.appender.errorfile.File=${kanaha.logs}/trace.loglog4j.appender.errorfile.layout=org.apache.log4j.PatternLayoutlog4j.appender.errorfile.layout.ConversionPattern=${output.error}log4j.appender.errorfile.threshold=errorlog4j.appender.errorfile.append=true# globalized message log to msg.log (user log)# rolling by log size#log4j.appender.messagefile=org.apache.log4j.RollingFileAppenderlog4j.appender.messagefile.MaxFileSize=10MBlog4j.appender.messagefile.MaxBackupIndex=10log4j.appender.messagefile.File=${kanaha.logs}/msg.loglog4j.appender.messagefile.layout=org.apache.log4j.PatternLayoutlog4j.appender.messagefile.layout.ConversionPattern=${output.normal}log4j.appender.messagefile.threshold=MSG_INFO#com.thinkdynamics.kanaha.util.logging.MessageLevellog4j.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 seehttp://logging.apache.org/log4j/docs/api/index.html#log4j.appender.consolefile=org.apache.log4j.RollingFileAppenderlog4j.appender.consolefile.MaxFileSize=100MBlog4j.appender.consolefile.MaxBackupIndex=10log4j.appender.consolefile.File=${kanaha.logs}/console.loglog4j.appender.consolefile.layout=org.apache.log4j.PatternLayoutlog4j.appender.consolefile.layout.ConversionPattern=${output.normal}log4j.appender.consolefile.threshold=debuglog4j.appender.consolefile.append=true Chapter 5. Troubleshooting 97
  • # errors to trace log file, for FFDC# rolling by log size#log4j.appender.errorfile=org.apache.log4j.RollingFileAppenderlog4j.appender.errorfile.MaxFileSize=10MBlog4j.appender.errorfile.MaxBackupIndex=10log4j.appender.errorfile.File=${kanaha.logs}/trace.loglog4j.appender.errorfile.layout=org.apache.log4j.PatternLayoutlog4j.appender.errorfile.layout.ConversionPattern=${output.error}log4j.appender.errorfile.threshold=errorlog4j.appender.errorfile.append=true# globalized message log to msg.log (user log)# rolling by log size#log4j.appender.messagefile=org.apache.log4j.RollingFileAppenderlog4j.appender.messagefile.MaxFileSize=10MBlog4j.appender.messagefile.MaxBackupIndex=10log4j.appender.messagefile.File=${kanaha.logs}/msg.loglog4j.appender.messagefile.layout=org.apache.log4j.PatternLayoutlog4j.appender.messagefile.layout.ConversionPattern=${output.normal}log4j.appender.messagefile.threshold=MSG_INFO#com.thinkdynamics.kanaha.util.logging.MessageLevellog4j.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, heartbeatlog4j.appender.heartbeat=org.apache.log4j.RollingFileAppenderlog4j.appender.heartbeat.MaxFileSize=100KBlog4j.appender.heartbeat.File=${kanaha.logs}/heartbeat.loglog4j.appender.heartbeat.layout=org.apache.log4j.PatternLayoutlog4j.appender.heartbeat.layout.ConversionPattern=${output.normal}98 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • log4j.appender.heartbeat.append=falselog4j.additivity.com.thinkdynamics.kanaha.util.heartbeat=false# CBEs# all categories and levels in CBE format (by redirection done in TIOLoggercustomized logger class)log4j.category.com.thinkdynamics.kanaha.util.logging.cbe.logger=ERROR, cbelog4j.appender.cbe=org.apache.log4j.RollingFileAppenderlog4j.appender.cbe.MaxFileSize=10MBlog4j.appender.cbe.MaxBackupIndex=10log4j.appender.cbe.File=${kanaha.logs}/cbe.loglog4j.appender.cbe.layout=org.apache.log4j.PatternLayoutlog4j.appender.cbe.append=falselog4j.renderer.org.eclipse.hyades.logging.events.cbe.CommonBaseEvent=com.thinkdynamics.kanaha.util.logging.cbe.CBERendererlog4j.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 Chapter 5. Troubleshooting 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 5. Troubleshooting 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 5. Troubleshooting 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Chapter 5. Troubleshooting 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 credentials106 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • view of the computer. If this SAP definition is missing, the installation of the Tivolicommon agent on this computer will fail with the message displayed inExample 5-4.Example 5-4 Missing SAP definitionERROR CODE: COPTDM017EcannotFindDefaultProtocolEndPointERROR MESSAGE: COPTDM017E The system cannot find the default protocol endpoint fordevice 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 agentinstallation workflow, verify the service access point definitions for the targetcomputer in the credentials view.Valid service access point definitions for computers are: RXA Server for Windows SSH Server for UNIX/Linux Chapter 5. Troubleshooting 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 credentials108 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Use 2100 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 Chapter 5. Troubleshooting 109
  • Port Use 9010 or 9015 Enable communication between the common agent and the content delivery service management center. 9510 The default common agent listening port. 9514 or 9515 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. 9511 Registering agents and resource managers 9512 Providing configuration updates Renewing and revoking certificates Querying the registry for agent information Requesting ID resets 9513 Requesting updates to the certificate revocation list Requesting agent manager information Downloading the truststore file Agent recovery service 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 inactivemake 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> 2100systHere, <depot-server-hostname> is the FQDN of the computer hosting the depot2100 is the default depot listening port.A properly working depot will answer in the following way:DS:<depot-server-hostname>=1.3.0.0To verify the depot configuration, you need to select the properties button andthe end of the depot record and select Properties from the context menu thatappears.In case the depot is working correctly, make sure the Tivoli common agent isrunning on the target box.For this purpose you can use the agentcli cmd locally on the agent as describedin “Installing Tivoli Common Agent” on page 132.If you verified that the Tivoli common agent is running on depot and target youshould examine the CDS logs which are located on the Tivoli ProvisioningManager 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 Chapter 5. Troubleshooting 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 Server5.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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. In the navigation pane, expand System Management. 2. Select Global Settings. The Configuration tab is displayed. 3. Select the Variables tab. 4. Locate the default concurrency level row. Select Actions → Properties. 5. 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_installdirxml. 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 Chapter 5. Troubleshooting 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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.inidefault eclipse.ini:-vmargs-Xms40m-Xmx256mmodified eclipse.ini-vmargs-Xms40m-Xmx384m Chapter 5. Troubleshooting 115
  • 116 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 6 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© Copyright IBM Corp. 2007. All rights reserved. 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 6. Administration 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: • Given Name • Family Name • Default Access Group1 • Notification Method • Notification Language • New Password • Confirm Password – Optionally, you can fill in the following fields and check boxes: • E-Mail • Superuser check box • Address 1 For details see “Associating access and permission groups to a user” on page 126.124 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • • 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. Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 6. Administration 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 SMB128 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Note: Ensure that Microsoft File and Print Sharing for Microsoft Networks is enabled for the ports to be activated. – Discover Network Devices using SNMP8. 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 scanPerform the following steps in the Discovery Configurations section in order tocreate 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. Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Perform the following steps to add a discovery policy to the discovery libraryconfiguration:By default the discovery library in Tivoli Provisioning Manager uses the IBMDiscovery Library Reader Configuration to import new data center models asdescribes in“IBM 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 PackagePerform 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 Records5. 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 Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 PropertiesDuring a software package installation, the drive or file system is checked foravailable space. If the requirement is met, the installation process continues,otherwise it fails, and the distribution reports an error. On UNIX systems, if thespecified file system does not exist on the target, the check continues to searchbackwards in the specified file system until a match is found. If no matching filesystem is found, the check is performed on the root ( / ) file system. Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • • 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 errorFigure 6-11 shows an example of a simple software package with the followingthree actions and objects: Check disk space system action Add directory and file object Execute program actionFigure 6-11 Example software package Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Chapter 6. Administration 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 catalog6.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/drivers146 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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%toolstc-driver-manager.cmd on Windows $TIO_HOMEtoolstc-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. Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 6. Administration 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 Solaris152 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Tivoli Provisioning Manager V5.1 includes the Rembo Toolkit 4.0 that cancapture operating system images from source systems and redeploy theseimages to other target systems with similar hardware resources.Rembo Technology, a company headquartered in Geneva, Switzerland, is aleading provider of operating system (OS) imaging and bare metal installationtechnology. Rembo has two primary products, Rembo Auto-Deploy and RemboToolkit. The Rembo server provides a PXE Boot server, that allows computersbased on x86 architecture to perform a network boot.The Rembo products are now fully integrated into the IBM Tivoli softwareportfolio. The successor to Rembo Auto-Deploy is renamed Tivoli ProvisioningManager for OS Deployment, a standalone product. The successor to RemboToolkit 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 EmbeddedEdition, which is a separate product provided as automation package. Theautomation package rembo.tcdriver is contained in the Tivoli ProvisioningManager 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 Rembo product Description Tivoli Provisioning Rembo Toolkit Is included in Tivoli Manager Provisioning Manager Tivoli Provisioning Rembo Toolkit Is not included in Tivoli Manager for Software Provisioning Manager for Software, but is an optional addition Tivoli Provisioning Rembo Auto-Deploy Standalone product Manager for OS Is direct successor to Deployment Rembo Auto-Deploy Chapter 6. Administration 153
  • IBM Tivoli product Rembo product Description Tivoli Provisioning Rembo Toolkit Stand alone product Manager for OS Is direct successor to Deployment Embedded Rembo Toolkit Edition Provided as automation package for use in Tivoli Provisioning Manager for Software6.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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Figure 6-13 Add Boot Server WizardThe computer target for a Rembo server must meet the following requirementsbefore 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 9The Rembo server supports image capture from the following operating systemsand 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) Chapter 6. Administration 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 Toolkit156 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • The Tivoli Provisioning Manager V5.1 Fixpack 1 provides an updated version ofRembo Toolkit that is renamed to Tivoli Provisioning Manager for OSDeployment Embedded Edition as shown in Figure 6-15.Figure 6-15 Rembo Toolkit renamed to Tivoli Provisioning Manager for OS DeploymentPreparing the Sysprep tool for Windows imagesOn 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 tothe %TIO_HOME%repositoryrembo<winos> directory on the TivoliProvisioning Manager server where <winos> is the operating system of thecaptured image: win2k: Windows 2000 win2k3: Windows 2003 winxp: Windows XPFor example the Sysprep tool is copied to the%TIO_HOME%repositoryrembowin2k folder before capturing an image from aWindows 2000 operating system.You can extract sysprep.exe and setupcl.exe from the supporttoolsdeploy.capfile located on the Windows installation CD. Always use the deploy.cap from thelatest service pack for each operating system available from the Microsoftdownload site. The deployment tools are different for each Microsoft operatingsystem. 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 Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Setting the BIOS startup sequenceIn the computer BIOS settings you need to set the startup sequence to boot fromnetwork first and then from hard disk. This ensures that the computer first sendsa request to a PXE boot server. If the computer receives no response, then itcontinues to boot from the hard disk.Starting the image capture processSelect Software Management → Manage Software Catalog → Images on theleft pane. You can also directly select a source computer from Inventory →Manage Inventory → Computers. On the right pane click Edit → CaptureImage 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_Masterand snapshot: Golden_master image This workflow implements the BootServer.CaptureImage device operation. Snapshot™ image This workflow implements the BootServer.CaptureBackupImage device operation. Chapter 6. Administration 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 computer6.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 that160 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 RemboHardware Discovery or a Tivoli Provisioning Manager Inventory Discovery. ARembo Hardware Discovery runs on a target computer even when no operatingsystem is installed. The Rembo Hardware Discovery only needs the serialnumber of the computer, specified as a parameter in the DiscoveryConfiguration.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 imageTo 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 Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 Chapter 6. Administration 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%toolsdcmexport.cmd on Windows) $TIO_HOME/tools/xmlimport.sh ((%TIO_HOME%toolsxmlimport.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 remote164 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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%soapclienttpmlteSoap 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.html6.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 Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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/Application6.11 Using Automation Package DevelopmentEnvironment 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. Chapter 6. Administration 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_HOMEdrivers 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 6. Administration 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 workflow4. 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. Chapter 6. Administration 171
  • The default location for the workflows is either of the following: – $TIO_HOME/eclipse/plugins/<package_name>/workflow on UNIX – %TIO_HOME%eclipseplugins<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 LocaleInsenseitive172 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 6. Administration 173
  • 174 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 7 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© Copyright IBM Corp. 2007. All rights reserved. 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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.Uninstall7.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 .tcdriver178 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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 agent7.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 Chapter 7. Infrastructure 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 7. Infrastructure 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 7. Infrastructure 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 7. Infrastructure 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 3 2 TPM publishes file into DMS Job instructs client Management Center content delivery service to download file and populates depots Management Center install 5 4 6 Client Installs and sends Clients download file DMS updates TPM result to DMS 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 application186 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 7. Infrastructure 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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. Chapter 7. Infrastructure 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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.RemoveFile7.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. Chapter 7. Infrastructure 191
  • 192 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 8 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.© Copyright IBM Corp. 2007. All rights reserved. 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 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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-ins6. 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 defined9. 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 Server196 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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%driver16.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 Chapter 8. Sample questions 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. d198 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 8. b9. c10.c11.a12.b, e13.d14.b15.d16.c17.a18.c19.a20.c21.a, b, d22.a, d23.a24.c25.a26.a, b, d27.a, d Chapter 8. Sample questions 199
  • 200 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • 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-7261Online 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.jsHow 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© Copyright IBM Corp. 2007. All rights reserved. 201
  • Help from IBM IBM Support and downloads ibm.com/support IBM Global Services ibm.com/services202 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • IndexA B Blade chassis admin server 131accessing remote drives 115 boot server 131adaptive bandwidth control 182 build.xml 84administrative domain 76 built format 138APDE 50 bulk data distribution 180application management 74 creating a cluster domain 77 management server domain 77 C peer domain 77 cbe.log 94 creating a customer 75 certification creating a resource pool 76 checklist 5 creating an administrative domain 76 IBM Certificationapplication tier 76 certification certificate 6assessment test 5 IBM Professional Certification mark 6associating SAP credentials 71 IBM Professional Certification Program 2audit report 78 benefits 3automation package 168 Tivoli Software Professional Certification 4Automation Package Developer Environment 50 benefits 4 APDE views 61 CIT 45 configuring APDE preferences 61 CIT Scanner scan utility 44 configuring database connectivity 53 cloudscape 23, 55, 57, 183 configuring deployment engine connectivity 58 cluster domain 77 prerequisites 58 code 15T890 8 creating automation packages 169 Common Agent Services 187 creating new workflow 169 agent manager 21 exporting created or modified workflows 173 Common Base Event format 94 installation 52 Common Base Event logs 96 installation requirements 51 Common Inventory Technology 45 connectivity 52 compliance management 139 hardware 51 adding a software compliance check 139 operating system 51 adding security compliance check 139 software 51 handling recommendation 141 modifying existing automation packages 170 running inventory scan and compliance check starting the APDE 59 140 using 167 verifying changes 142 working with workflows 170 compliance report 78automation packages 81 computer DCM object 176 creating 83 console.log 94 creating a workflow 84 continuous operation 188 installation 81 copy file 177 updating 82 creating virtual server template 149available bandwidth 182 credentials search key 66© Copyright IBM Corp. 2007. All rights reserved. 203
  • D creating a change record 130data center model 176 delete policy 130 application tier 177 update policy 130 customer 177 updating the data center model 130 device drivers 178 discovery report 78 management operations and LDO 177 distribution agent 181 objects 176 doc 84 resource pool 177 download manager 181 workflow 178 dynamic content delivery service 180DB2 57 management center 181DCM 176 dynamic content delivery servicesdeployment report 78 management center 18depot 19 dynamic content delivery services subagent 20depot issues 110depot server 181 EDevice Management Server 183 eclipse environment 168Device Management Service 183 eclipse installation 56–57 concepts 184 eDMS servers 183 device management federating agents 183 enabling host access 114 Device manager enabling the boot from network interface card 158 jes.properties file 184 examination score report 6 polling interval execute command 177 how to change 184 execute program action 136 subagents 184 Extensible Markup Language 164 device manager subagents 184 federator 18 sending jobs to TCA 184 F Service Access Point 184 file repository 87, 131, 179device management service forceInstallDriver 82 concepts 184 job management service 183 G jobs 183 General Package Properties window 134 server 183 Golden_master image 159device management service federating agent 18 groups 73, 144device management service federator 18 creating a dynamic group 74device manager subagent 18 creating a static group 73discovering operating system attributes 158discovery 64 IBM Discovery Library Reader 64 H Microsoft Active Directory 64, 69 heartbeat function 188 Rembo hardware discovery 64 host platform quantity 151 scan types 64 devices 64 I others 65 IBM Certification software 65 agreement 6 Tivoli Provisioning Manager Inventory 64 Professional Certification mark 6 Tivoli Provisioning Manager network 64 Test 898 7discovery policy 130 IBM Discovery Library Reader 67 add policy 130 configuration 131204 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • IBM Tivoli Provisioning Manager redbooks 9 Logical Device Operations 177IBM TPM redbooks 9 LWI 23imaging 152 capturing an image with Rembo Boot Server 156 M management center 181 defining operating system 158 managing security 119 deploying an image with Rembo Boot Server adding a new user 123 160 assigning a security role to a user 125 installing a boot server 154 associating access and permission groups to a installing an image 161 user 126 preparing the Sysprep tool for Windows images associating objects to an access group 122 157 creating a permission group 121 setting the BIOS startup sequence 159 creating a security role 120 starting the image capture process 159 creating an access group 121implements ldo-name 172 enabling access control 127inside the distribution process 185 MaxBackupIndex 99 overview 186 MaxFileSize 99install patch wizard 112 maximum password age 140installing behind a firewall 42 META-INF 84Installing Tivoli Provisioning Manager V5.1 29 Microsoft Active Directory 37installing Tivoli Provisioning Manager V5.1 29 Microsoft End User License Agreement 38inventory report 78 Microsoft Windows Server Update Services 179IP Address Response Timeout 66 minimum password length 140 minimum password reuse count 140J monitoring agentjob management service 183 181 msg.log 94 mx256m value 115Llarge branch office 25large data center 24 Nlarge software packages 115 NAT 185LDAP 119, 190 NAT environments 185LDAP registry 190 Network Address Translation 185LDO 177 network discovery and agent distribution 127ldo-name 172 creating an inventory discovery scan 129Light Stack Tivoli Provisioning Manager 23 preparing network discovery 128Lightweight Directory Access Protocol 119, 190 non-built formats 138Lightweight Infrastructure 23load balancer 131LocaleInsenseitive 172 O OAMPI 17LocalFileRepository 179 object wrapping 179log files 93 Open Services Gateway Initiative 187log4j 95 OSGi bundles 187log4j.prop 95 OSGi 187logfile types 94logging tool 95logical device 177 PLogical Device Operation 177 package explorer 84 Index 205
  • Pearson Virtual University Enterprises 6 Speer manager 181 SAP 70, 184peer-to-peer file sharing 185 saving a software package 138performance tuning 112 scalability 15 configuring maximum number of concurrent jobs scalable distribution 179 112 Scalable Distribution Infrastructure workflow performance 113 componentsperforming the discovery task 132 ports used 26preferred upload servers 182 scriptlet keyword 113pre-installation checklist 39 Secure Shell 128 additional software requirements 40 security model 190 Cygwin software for Windows 40 security officer 127 GNU tar 41 Server Message Block 128 static IP address 41 Service Access Points 70 prerequisite software versions 41 credentials 71 TIL requirements 39 setting administrator password 158preparing the Sysprep tool for Windows images setting loglevel 95157 Simple Network Management Protocol 128publishing to depots 185 Simple Object Access Protocol 164PXE Boot server 153 small branch office 24 small data center 23 SMB protocol 43Rrecertification 7 snapshot image 159recommended educational resources 5 SNMP discovery 67recommended publications 9 SOA Service Access Point 184recommended resources for study 8 SOAP 164, 184Redbooks Web site 201 software catalog 145, 180 Contact us xix external software catalog 146regions 182 file server 145Rembo Auto-Deploy 153 software definition 179Rembo Automation Package 82 software distribution 162Rembo Technology 153 software installable 176, 179Rembo Toolkit 82, 153 software installation 162Rembo Toolkit 4.0 153 Software Installation Engine (SIE) 180rembo.tcdriver is 153 Software Installation objects 180Remote Execution and Access 70 Software Life Cycle 189report constraint 78 software management 143report description 78 software package 138, 179report layout 78 software package block 133, 179–180report summary 78 software package block format 138reports 78 software package definition format 138repository 84 Software Package Editor 85, 114, 133, 179requirements on target endpoints 163 adding directory object 136resource pool 76 checking disk space action 134return on investment 5 execute program action 136ROI 5 saving a software package 138RXA-BootStrap-Server 72 using the SPE 134 software product 179 software product requirement 180206 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • software resource 179 security credentials 188software stack 143, 179–180 services 186 configuration templates 144 updates 188 installables 144 Tivoli Intelligent Orchestrator 52, 58 modules 143 Tivoli Provisioning Manager requirements and capabilities 144 accessing the console 118SoftwareInstallable DCM object 176 Automation Package Developer Environmentsrc 84 15ssh daemon 128 components 12SSH discovery 66 demo installation 23SSH protocol 43 fully qualified host name 55SSH-Server service access point 72 IBM Open Process Automation Library 15static group 73 infrastructure deployment considerations 22subsystem messages 94 installationsuperuser 125, 190 fast start installation 30supported installation topologies and OS versions regular installation 3031 silent installation 30 account required 39 installation infrastructure AIX and Linux 33 fast start installation 23 one-node topology 31 full enterprise installation 23 Solaris 34 installation log files two-node topology 32 directory containing output from installation Windows 36 47switch 177 installer logs 46switch DCM object 176 Tivoli common directory 46system management accross firewalls 25 installing behind a firewall 42 installing log files 46 inventory discovery 65T network discovery 65TC-INF 84 Creating discovery using SSH or WindowsThomson Prometric 6 SMB 66tioadmin user 91 discovering devices using SNMP 67TIOlog levelmessage 114 using SSH or Windows SMB 66TIOsetVAR variable value 114 operator and administrator console 15TIOthrow variablemessage 114 overview of the installation flow 43Tivoli Certified Consultant 7 installation phases 44Tivoli Common Agent 21, 187 invoking the installer 43 agent installation 102 post installation steps 45, 47 communication issues 109 changing default passwords 48 RXA problems 105 importing sample data 49 service access point problems 106 provisioning server installation 45 time drift 103 provisioning sever agent manager 187 automation 13 certificates 188 compliance and remediation 13 features 188 data center model 13 heartbeat function 188 deployment infrastructure 14 installation 132 discovery 14 managed endpoint 187 provisioning database 13 resource manager 187 reporting 13 Index 207
  • run a discovery 69 storage templates 149 Scalable Distribution Infrastructure 17 installing tcdriver 147 Device Management Service 17 virtual server templates 150 Dynamic Content Delivery Service 17 VLAN 176 Tivoli Common Agent Services 17 supported platforms 21 user directory 15 W WAS 93Tivoli Provisioning Manager Certification web services 164 getting your 15% discount 8 Web Services Description Language 165Tivoli Provisioning Manager Embedded Edition 44 Web Services Resource Framework 166Tivoli Provisioning Manager for OS Deployment Em- web-based courses for certification 8bedded Edition 153 WebSphere Application Server 93Tivoli Provisioning Manager JVM directory 94 Windows Server Update Services 146Tivoli Provisioning Manager V5.1 Windows SMB discovery 66 implementation certification 7 workflow 84, 178Tivoli software education 8 workflow syntax 172Tivoli Software Professional Certification 4 workflow troubleshooting 100 Benefits 4 setting loglevel 100 test 898 objectives 8 workflow execution logs 101Topology Installer Launcher 31 WSDL 165TPM directory structure 91 WSRF 166TPM essentials 90 eliminating possible causes 91 recording the symptoms of the problem 90 X recreating the problem 90 x86 architecture 153 XML 84, 164Uuploading 182 Zuser role for software distribution 163 zones 182user roles 190user security access groups 190 access permission group 191 permission groups 191 user authentication 190 user authorization 190 user roles and accounts 190Vvirtual server quantity 151virtual 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 149208 Certification Guide Series: IBM Tivoli Provisioning Manager V5.1
  • Certification Guide Series: IBM Tivoli Provisioning Manager V5.1 (0.2”spine) 0.17”<->0.473” 90<->249 pages
  • Back cover ®Certification Guide SeriesIBM Tivoli ProvisioningManager V5.1Helps you become a IBM Tivoli Provisioning Manager, built on a Service Orientedcertified Tivoli Architecture, enhances usability for executing changes while INTERNATIONALProvisioning keeping server and desktop software compliant. It helps TECHNICALManager V5.1 organizations with provisioning, configuration and SUPPORTprofessional maintenance of servers and virtual servers, operating ORGANIZATION systems, middleware, applications, storage and network devices acting as routers, switches, firewalls, and loadExplains the balancers. This IBM Redbook is a study guide for IBM Tivolicertification path Provisioning Manager V5.1 for people who want to get an BUILDING TECHNICALand prerequisites IBM Professional Certification for this product. INFORMATION BASED ONyou require PRACTICAL EXPERIENCE The IBM Tivoli Provisioning Manager V5.1 Certification, offered through the Professional Certification Program fromIncludes best IBM Redbooks are developed by IBM, is designed to validate the skills required of technicalpractices for the IBM International Technical professionals who work in the implementation of the IBM Support Organization. ExpertsSoftware Tivoli Provisioning Manager V5.1 product.This book provides from IBM, Customers andDistribution a combination of theory and practical experience needed for Partners from around the world a general understanding of the subject matter and sample create timely technical questions that will help in the evaluation of personal progress information based on realistic scenarios. Specific and provide familiarity with the types of questions in the recommendations are provided exam. to help you implement IT The chapters are based on the sections of the Tivoli solutions more effectively in your environment. Provisioning Manager V5.1 Implementation Certification test. Studying each chapter will help you prepare for one section of the exam. For more information: ibm.com/redbooks SG24-7262-00 ISBN 0738489611