TPM User Guide

Provisioning Manager
Version 7.2
Provisioning User Guide
Provisioning Manager
Version 7.2
Provisioning User Guide
Note Before using this information and the product it supports, read the information in Notices on page 1255.
Last updated: July 2011 This edition applies to Tivoli Provisioning Manager 7.2.0.2 and to all subsequent releases and modifications until otherwise indicated in new editions. The material in this document is an excerpt from the Tivoli Provisioning Manager 7.2.0.2 information center and is provided for convenience. This document should be used in conjunction with the information center. Copyright IBM Corporation 2003, 2011. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Chapter 1. Overview . . . . . . . . . 1
What's new in this version. . . . . . . . . . 1 Information center updates . . . . . . . . . 9 Getting started basics . . . . . . . . . . . 10 Tivoli Provisioning Manager overview . . . . . 13 Component architecture . . . . . . . . . 14 Deployment infrastructure . . . . . . . . 17 Managing your system life cycle . . . . . . 20 First steps . . . . . . . . . . . . . . . 26 Tutorial: Learning the user interface . . . . . . 27 Logging on to the provisioning server . . . . 28 Start Center . . . . . . . . . . . . . 29 Opening an application . . . . . . . . . 30 Searching and table filtering . . . . . . . . 30 Help while you work . . . . . . . . . . 32 Configuring system settings . . . . . . . . . 32 Changing the automatic logoff setting . . . . 32 Configuring the List view to be empty by default 34 Moving Tivoli Provisioning Manager to the top of the information center . . . . . . . . . 34 Notifications overview. . . . . . . . . . 34 System variable and locale attributes . . . . . 36 Everyday tasks . . . . . . . . . . . . . 37 Finding the object ID of a data model object . . 37 Setting up email notification for automation packages . . . . . . . . . . . . . . 38 Provisioning groups . . . . . . . . . . 38 Provisioning computers . . . . . . . . . 45 Frequently asked questions (FAQs) . . . . . . 55 Installation directories and other paths . . . . . 56 Troubleshooting . . . . . . . . . . . . . 59 Troubleshooting aids . . . . . . . . . . 59 Logging on or logging off problems . . . . . 60 Other problems . . . . . . . . . . . . 65 Enabling the Applications tab in the Security Group application . . . . . . . . . . . 93 Configuring failed login limits on the LDAP server . . . . . . . . . . . . . . . 94 Preventing cross-site scripting . . . . . . . 95 Configuring the Web browser to use a certificate 95 Changing passwords . . . . . . . . . . 96 Configuring form base authentication . . . . 99 Importing a certificate for the provisioning Web interface . . . . . . . . . . . . . . 100 Managing users and security groups . . . . 102 Configuring SSL communication for Tivoli Provisioning Manager and DB2 9.5 . . . . . 103 Auditing changes . . . . . . . . . . . . 111 LDAP user and group management . . . . . . 113 Lightweight Directory Access Protocol . . . . 113 LDAP synchronization . . . . . . . . . 114 LDAP configuration information for Web service 114 Attribute mapping from LDAP to IBM Tivoli Provisioning Manager . . . . . . . . . 118 Troubleshooting security. . . . . . . . . . 119 Access control problems and limitations . . . 120 Reference. . . . . . . . . . . . . . . 132 Role based security groups . . . . . . . . 132 Conditional user interface . . . . . . . . 144 Single Sign-on (SSO) . . . . . . . . . . 144
Chapter 3. Discovering IT resources

Discovery basics . . . . . . . . . . . Discovery process . . . . . . . . . . . Requirements . . . . . . . . . . . . User roles and requirements . . . . . . Software requirements . . . . . . . . Regular discoveries . . . . . . . . . . Network resource discovery . . . . . . Provisioning Inventory discovery overview . Discovering operating systems and correlating them programmatically . . . . . . . . Automatic Agent discovery by device . . . Microsoft Active Directory discovery . . . Running Microsoft Updates discovery . . . Discovering Solaris zones . . . . . . . Discovering AIX workload partitions . . . Discovering virtual centers . . . . . . . Discovering virtual servers . . . . . . . Discovering PCI devices . . . . . . . . Discovering WebSphere Application Server software instances . . . . . . . . . . TADDM discovery . . . . . . . . . Discovery library adapter . . . . . . . Enabling the Network Address Translation support . . . . . . . . . . . . . Verifying discovered resources. . . . . . . Identifying discovered resources . . . . .
145
. . . . . . . . . . . . . . . . . 146 150 152 153 153 153 154 162 195 195 195 198 199 200 200 201 202
Chapter 2. Controlling user access
. . 75
75 78 78 79 79 79 80 80 85 89 89 89 91
Controlling user access basics . . . . . . . . Security process . . . . . . . . . . . . . Components . . . . . . . . . . . . . . Integration with IBM Service Management . . . . Requirements . . . . . . . . . . . . . . User roles and requirements . . . . . . . . Managing user access . . . . . . . . . . . Tutorial: manage security and access permissions using LDAP . . . . . . . . . . . . . Tutorial: manage security and access permissions using Maximo authentication . . . . . . . Everyday tasks for security . . . . . . . . . Update Tivoli Provisioning Manager certificate in the Java truststore . . . . . . . . . . . Creating a duplicate maxadmin user for Tivoli Provisioning Manager . . . . . . . . . . Configuring Tivoli Provisioning Manager for PKCS12 for Microsoft Active Directory . . . .
. 203 . 203 . 223 . 226 . 227 . 227
Copyright IBM Corp. 2003, 2011
iii
Verifying discovered Microsoft Active Directory resources . . . . . . . . . . . . . . Discovery consolidation rules using different discovery configurations. . . . . . . . . Discovery consolidation rules for different software installations . . . . . . . . . . Tutorial: Discovering your environment . . . . Part 1: Discovering your resources . . . . . Part 2: Managing discovered resources . . . . Tutorial: Replicating business applications from TADDM . . . . . . . . . . . . . . . Part 1: Defining business applications on TADDM server to be replicated into Tivoli Provisioning Manager . . . . . . . . . Part 2: Discovering business applications on Tivoli Provisioning Manager server . . . . . Part 3: Viewing discovered business applications Troubleshooting discovery . . . . . . . . . Log files for troubleshooting discovery . . . . Discovery problems and limitations . . . . .
227 229 230 230 231 233 234
Tivoli Provisioning Manager for OS Deployment boot server configuration . . . . . . . . OS deployment server replication . . . . . Modifying OS configuration parameters . . . Hardware compatibility list. . . . . . . . Installing and uninstalling the web interface extension . . . . . . . . . . . . . .
354 357 360 379 384
Chapter 5. Managing virtual images
387
387 391 392 392 392 392 396
234 237 238 239 244 245
Chapter 4. Deploying operating systems. . . . . . . . . . . . . . 259

Operating system management basics . . . . . Tivoli Provisioning Manager for OS Deployment overview . . . . . . . . . . . . . . . Upgrade to Tivoli Provisioning Manager for Images . . . . . . . . . . . . . . Components for managing virtual images . . . Operating system management process. . . . Image deployment process . . . . . . . . Hardware and operating systems images overview . . . . . . . . . . . . . . Network boot . . . . . . . . . . . . Requirements . . . . . . . . . . . . . User roles and requirements . . . . . . . Server system requirements . . . . . . . Target system requirements. . . . . . . . Setting up additional child OS deployment servers . . . . . . . . . . . . . . Windows Preinstallation Environment (WinPE) Setting up for Solaris deployments . . . . . Specifics for PowerPC targets on AIX and Linux Prerequisites for VMware targets . . . . . . Discovering an OS deployment server . . . . DHCP server requirements and configuration Tutorial: Managing operating systems . . . . . Part 1: Creating an image . . . . . . . . Part 2: Configuring image properties . . . . Part 3: Creating software modules . . . . . Part 4: Binding rules . . . . . . . . . . Part 5: Installing an image . . . . . . . . Security . . . . . . . . . . . . . . . Avoiding new vulnerability issues . . . . . Backup server files . . . . . . . . . . Rogue PXE servers . . . . . . . . . . Network security constraints . . . . . . . Reference. . . . . . . . . . . . . . . Upgrading Tivoli Provisioning Manager for OS Deployment to a later version . . . . . . . 261 264 265 265 268 269 269 273 279 279 280 281 283 286 292 294 295 295 296 301 303 323 332 347 349 350 350 350 350 351 351 352
Virtual image management basics . . . . . . Tivoli Provisioning Manager for Images overview Managing different hypervisors . . . . . . Managing different virtual images . . . . . Backing up and restoring images . . . . . . Components for managing virtual images . . . . Obtaining Tivoli Provisioning Manager for Images Upgrading Tivoli Provisioning Manager for OS Deployment to Tivoli Provisioning Manager for Images . . . . . . . . . . . . . . . Image deployment process . . . . . . . . . Managed image types . . . . . . . . . . Network boot . . . . . . . . . . . . . Booting targets without using PXE . . . . . Requirements . . . . . . . . . . . . . User roles and requirements . . . . . . . Web interface prerequisites . . . . . . . . Hypervisor requirements . . . . . . . . Server system requirements . . . . . . . Target system requirements. . . . . . . . Setting up additional child OS deployment servers . . . . . . . . . . . . . . Windows Preinstallation Environment (WinPE) Prerequisites for VMware targets . . . . . . DHCP server requirements and configuration Installing the web interface extension . . . . . Installing and uninstalling the web interface extension . . . . . . . . . . . . . . Virtual image tasks . . . . . . . . . . . Synchronizing images . . . . . . . . . Capturing virtual images . . . . . . . . Deploying virtual images . . . . . . . . Replicating virtual images . . . . . . . . Exporting virtual images . . . . . . . . Importing virtual images . . . . . . . . Tutorial: Managing virtual images . . . . . . Part 1: Setting up for virtual image management Part 2: Creating and managing virtual images Part 3: Creating software modules . . . . . Part 4: Binding rules . . . . . . . . . . Part 5: Installing a virtual image . . . . . . Reference. . . . . . . . . . . . . . . Upgrading Tivoli Provisioning Manager for Images to a later version . . . . . . . . Tivoli Provisioning Manager for OS Deployment boot server configuration . . . . . . . . OS deployment server replication . . . . . Modifying OS configuration parameters . . . Hardware compatibility list. . . . . . . .
397 398 399 399 401 406 406 407 407 410 411 414 417 423 423 428 429 430 430 431 432 433 434 436 437 439 443 447 459 461 462 462 464 468 470 490
iv
IBM Tivoli Provisioning Manager Version 7.2.0.2 User Guide
Chapter 6. Managing images in the image library . . . . . . . . . . . 497

Image library basics . . . . . . . . . . . Requirements . . . . . . . . . . . . . User roles and requirements . . . . . . . Configuring an image repository . . . . . . Master images . . . . . . . . . . . . . Synchronizing the image library . . . . . . Capturing master images . . . . . . . . Deploying a master image to create a new virtual server . . . . . . . . . . . . Creating a version of an existing image. . . . Deploying a master image on an existing virtual server . . . . . . . . . . . . . . . Composite images . . . . . . . . . . . . Software prerequisites for composite images . . Creating composite images . . . . . . . . Deploying a composite image to create new virtual servers . . . . . . . . . . . . Capturing a version of a composite master image . . . . . . . . . . . . . . . Saved Images . . . . . . . . . . . . . Saving images . . . . . . . . . . . . Creating or replacing virtual servers from saved images . . . . . . . . . . . . . . Publishing an image . . . . . . . . . . . Associating a security group with a provisioning group . . . . . . . . . . Unpublishing images . . . . . . . . . . Troubleshooting image library management . . . Log files . . . . . . . . . . . . . . Image library problems and limitations. . . . 498 501 501 502 504 505 507 507 509 510 510 511 512 514 516 517 519 520 520 521 522 522 522 524
Chapter 7. Deploying software . . . . 529

Software deployment basics . . . . . . . Software distribution process overview . . . . Components. . . . . . . . . . . . Setting up scalable distribution infrastructure Publishing software to depot servers . . . Unpublishing files from depot servers . . . Requirements . . . . . . . . . . . . User roles and requirements . . . . . . Hardware and software prerequisites . . . Tutorial: Software deployment. . . . . . . Part 1: Discovery . . . . . . . . . . Part 2: Configuration . . . . . . . . . Part 3: Software publication, distribution, and installation . . . . . . . . . . . . Unpublishing the software and uninstalling the common agent . . . . . . . . . . . Distributing and installing software . . . . . Distributing software products . . . . . Canceling software distributions . . . . . Canceling distributions . . . . . . . . Determining the status of SDI tasks . . . . Installing software products . . . . . . Installing individual patches on UNIX and Linux . . . . . . . . . . . . . . Installing individual patches on Windows . . Installing software stacks . . . . . . . . 529 . 533 . 534 538 . 543 . 545 . 546 . 546 . 547 . 567 . 568 . 572 . 575 . . . . . . . 581 582 583 605 606 606 607
Installing WebSphere Application Server with settings from a discovered installation . . . Performing maintenance operations on target computers . . . . . . . . . . . . Simple software product distribution . . . . Software product distribution requirements . Defining software products for distribution . Installing simple software products . . . . Troubleshooting simple software product distribution . . . . . . . . . . . . Uninstalling software . . . . . . . . . . Uninstalling software products . . . . . Uninstalling patches . . . . . . . . . Uninstalling software stacks . . . . . . Installing Tivoli Common Agent Services . . . Tivoli Common Agent . . . . . . . . Tivoli Common Agent Services ports . . . Tivoli Common Agent Stack configuration template parameters . . . . . . . . . Installing the common agent . . . . . . Configuring the common agent . . . . . Configuring dynamic content delivery . . . Configuring the device manager service . . Upgrading the common agents . . . . . Uninstalling the common agent . . . . . Agent registration . . . . . . . . . . Agent manager . . . . . . . . . . . Administering installed software . . . . . . Software concepts . . . . . . . . . . Rollback . . . . . . . . . . . . . Viewing software resources. . . . . . . Adding a top level software resource for a software installation . . . . . . . . . Adding child software resources . . . . . Updating the data model with changes to software resources . . . . . . . . . . Upgrading software resources . . . . . . Cluster domains overview . . . . . . . Configuring Wake on LAN (WOL) . . . . Configuring firewall components . . . . . Packaging software for distribution . . . . Troubleshooting software distribution . . . . Deploying software troubleshooting checklist Recovering from software provisioning problems . . . . . . . . . . . . . Log files . . . . . . . . . . . . . Software deployment problems and limitations Reference. . . . . . . . . . . . . . Configuring RSA credentials and service access points . . . . . . . . . . . . . . Bulk data distribution and storage . . . . Job distribution and management . . . .
. 612 . . . . . . . . . . . . . . . . . . . . . . . . . . 613 618 620 622 624 625 626 626 627 628 628 630 631 633 634 651 657 662 667 669 675 682 689 691 717 719
. 719 . 720 . . . . . . . 721 722 722 737 739 750 751 756
. 760 . 761 763 . 809 . 809 . 810 . 822
Chapter 8. Checking compliance . . . 827

Compliance basics . . . . . . . Compliance process . . . . . . Requirements . . . . . . . . User roles and requirements . . Oracle and WebSphere Application prerequisites. . . . . . . . Software prerequisites . . . . . . . . . . . . . . . . Server . . . . . . . . . . . . . . . . 828 833 835 835
. 609 . 609 . 611
. 836 . 837
Contents
Compliance checks export and import tools . . Exporting compliance checks for selected computers or groups . . . . . . . . . Exporting compliance checks for all computers and groups . . . . . . . . . . . . Importing compliance checks for selected computers or groups . . . . . . . . . Importing compliance checks for all computers and groups . . . . . . . . . . . . Importing compliance checks to different target computers . . . . . . . . . . . . Tutorial: Managing compliance . . . . . . Part 1: Creating compliance checks . . . . Part 2 Recommendations . . . . . . . Example: Running a Sarbanes-Oxley compliance report . . . . . . . . . . . . . . . Example: Running a SOX report . . . . . . Example: Defining a multiple-rule security compliance check . . . . . . . . . . . Example: Restricting software . . . . . . . Allowed software scenario . . . . . . . Prohibited software scenario . . . . . . Example: User-defined compliance checks . . . Defining a compliance check . . . . . . . Adding user-defined security compliance checks Troubleshooting compliance . . . . . . . Log files . . . . . . . . . . . . . Compliance problems and limitations . . . Reference. . . . . . . . . . . . . . Security compliance reference . . . . . . Running recommendations for DB2 . . . . Running recommendations for Oracle . . . Running recommendations for WebSphere Application Server . . . . . . . . . Running recommendations for IBM HTTP Server . . . . . . . . . . . . . .
. 839 . 840 . 841 . 841 . 842 . . . . 843 844 845 851
. 853 . 853 . . . . . . . . . . . . . 854 855 855 856 856 857 857 858 863 864 869 869 873 874
Using Sun Update Connection Enterprise to manage patches in Solaris environments . . . 984 Registering a group of computers with Sun Update Connection . . . . . . . . . . 985 Managing patches in HP-UX environments . . . 985 Troubleshooting SDI Windows patch management 989 Patch management troubleshooting checklist 992 Log files . . . . . . . . . . . . . . 996 Patch management problems and limitations 997 Reference . . . . . . . . . . . . . . 1004 Publishing software to depot servers . . . . 1004 Unpublishing files from depot servers . . . . 1006 Manually defining patches . . . . . . . 1007 Installing individual patches on UNIX and Linux . . . . . . . . . . . . . . 1009 Installing individual patches on Windows . . 1010 Uninstalling patches . . . . . . . . . . 1011
Chapter 10. Configuring virtual servers . . . . . . . . . . . . . 1013

Virtualization basics . . . . . . . . . . . Managing virtualization with LPARs . . . . . Managing virtualization with AIX WPARs . . . Managing virtualization with KVM . . . . . Managing IBM System p virtualization with VMControl . . . . . . . . . . . . . . Creating a VMControl computer . . . . . Copying the SSL certificate . . . . . . . Creating a service access point on the VMControl virtual server . . . . . . . . Registering a VMControl boot server . . . . Verifying that the VMControl boot server exists Running the VMControl discovery . . . . . Supported VMControl activities . . . . . . VMControl virtual server templates . . . . Virtual server template parameters . . . . . Adjusting the timeout value for a VMControl job . . . . . . . . . . . . . . . Uninstalling the VMControl virtual infrastructure automation package . . . . . Managing virtualization with Hyper-V . . . . System p Server data flow quick reference . . . Live Partition Mobility for System p server . . . Tutorial: Managing virtual servers and host platform servers using VMware . . . . . . . VMware virtualization process . . . . . . Requirements . . . . . . . . . . . . Part 1: Configuring and deploying the ESX server and the VMware VirtualCenter . . . . Part 2: Setting up the environment . . . . . Part 3: Discovering VMware virtual servers Part 4: Creating a virtual server . . . . . . Part 5: Performing virtual server activities . . Tutorial: Creating virtual Fibre Channel adapters Requirements . . . . . . . . . . . . Part 1 Adding virtual Fibre Channel adapters to LPARs . . . . . . . . . . . . . Part 2 Setting up email notification and deleting virtual Fibre Channel adapters . . . Tutorial: Managing virtual servers and host platform servers using Solaris Zones . . . . . 1013 1016 1026 1030 1040 1041 1041 1042 1043 1043 1043 1044 1047 1047 1048 1048 1049 1055 1056 1058 1059 1060 1061 1064 1066 1071 1075 1078 1079 1080 1083 1084
. 874 . 875
Chapter 9. Deploying patches . . . . 877

Patch management basics . . . . . . . . . Cross platform feature support . . . . . . . Managing patches in Windows environments. . . Windows environments using the scalable distribution infrastructure . . . . . . . . Managing patches in Windows environments using the deployment engine . . . . . . . Managing patches in AIX environments . . . . Patch management process . . . . . . . . Components for AIX environments . . . . . Tutorial: Managing patches in AIX environments Managing patches in Red Hat Enterprise Linux environments . . . . . . . . . . . . . Red Hat Enterprise Linux environments . . . Managing patches in Red Hat Enterprise Linux 4 environments . . . . . . . . . . . . Managing patches in SUSE Linux Enterprise Server environments . . . . . . . . . . . . . SUSE Linux Enterprise Server 11 environments SUSE Linux Enterprise Server 10 environments Managing patches in Solaris environments . . . Solaris environments using Sun Update Connection . . . . . . . . . . . . . 877 884 886 887 911 913 914 915 917 928 928 949 952 952 971 974 975
vi
Solaris Zones virtualization process . . Requirements . . . . . . . . . . Part 1: Setting up the environment . . . Part 2: Creating a Solaris Zone . . . . Part 3: Performing Solaris Zone activities . Verifying results . . . . . . . . . . Troubleshooting virtualization management . Log files. . . . . . . . . . . . Virtualization problems and limitations .
. . . . . . . . .
. . . . . . . . .
1086 1087 1087 1089 1093 1095 1095 1096 1101
Chapter 11. High availability disaster recovery . . . . . . . . . . . . . 1109

High availability disaster recovery basics . . . High availability considerations and provisioning architecture . . . . . . . . . . . . . Solution constraints . . . . . . . . . . Solution architecture. . . . . . . . . . Solution architecture. . . . . . . . . Tivoli System Automation for Multiplatforms integration . . . . . . . . . . . . Solution installation and configuration . . . Tivoli Provisioning Manager server primary installation . . . . . . . . . . . . Tivoli Provisioning Manager server secondary installation . . . . . . . . . . . . Tivoli System Automation for Multiplatforms installation and configuration. . . . . . Enabling the HADR support for Provisioning Manager for OS Deployment . . . . . . Disaster recovery . . . . . . . . . . . Alternative technologies . . . . . . . . . 1109 . . . . 1110 1113 1116 1117
Adding ACL access rules . . . . . . . Enabling IP or host name addressing for the scalable distribution infrastructure . . . . . IPv6 addressing . . . . . . . . . . . IPv6 support in Tivoli Provisioning Manager Enabling IPv6 in the operating system. . . Enabling IPv6 for the provisioning server . EUI 64 MAC addresses . . . . . . . . Specifying an EUI 64 MAC address . . . Managing storage . . . . . . . . . . SAN optimization . . . . . . . . . Storage devices and templates . . . . . SAN and SAN fabrics . . . . . . . . Fibre channel switches . . . . . . . .
. 1146 . 1146 . 1148 1149 . 1151 . 1152 . 1153 . 1154 . 1154 . 1154 . 1155 . 1156 . 1156
Chapter 13. Managing provisioning tasks . . . . . . . . . . . . . . 1157

Task management basics . . . . . . . . Requirements . . . . . . . . . . . . User roles and requirements . . . . . . Managing provisioning task definitions . . . Provisioning tasks: provisioning workflows, scripts, and activity plans . . . . . . . Creating provisioning task definitions . . . Setting a concurrency level for provisioning tasks . . . . . . . . . . . . . . Sharing provisioning task definitions . . . Unsharing provisioning task definitions . . Viewing provisioning task history . . . . Submitting and tracking provisioning tasks . . Running a provisioning task . . . . . . Tracking a provisioning task . . . . . . Keeping the target list accurate for tracking tasks . . . . . . . . . . . . . . Tracking provisioning tasks on specific computers . . . . . . . . . . . . Rerunning a provisioning task . . . . . Setting a time limit for a provisioning task Restricting the access needed for rerunning a provisioning task . . . . . . . . . . Enabling automatic refresh for tracking tasks Displaying a graphical view of your recent provisioning tasks . . . . . . . . . Managing submitted provisioning tasks . . . Editing a provisioning task . . . . . . Rescheduling provisioning tasks. . . . . Canceling in progress provisioning tasks . . Removing provisioning tasks . . . . . . Retrieving provisioning task information . . Bookmarking a provisioning task . . . . Creating a group from the provisioning task results . . . . . . . . . . . . . Provisioning tasks in IBM Service Management Adding provisioning tasks to processes . . Attaching an assisted workflow . . . . . Claiming and initiating a provisioning task as part of a process . . . . . . . . . . Setting the value of the work order number Troubleshooting task management . . . . . . . . . 1157 1160 1160 1161
. 1119 . 1120 . 1120 . 1120 . 1122 . 1127 . 1127 . 1129
. 1161 . 1161 . . . . . . . 1162 1163 1164 1164 1164 1164 1165
Chapter 12. Managing network resources . . . . . . . . . . . . 1131

Managing switches . . . . . . . . . . . Adding a switch . . . . . . . . . . . Configuring load balancer networking. . . . . Configuring additional resources for computers Network interface IP addresses . . . . . . Adding network interface cards to computers Defining network interfaces for computers Managing a load balancer . . . . . . . . . Configuring load balancer switch functionality Configuring the load balancer as a router . . Subnetworks . . . . . . . . . . . . . Adding blocked IPs for a subnetwork . . . . . Adding a new VLAN . . . . . . . . . . Adding VLANs to switches . . . . . . . . Trunking . . . . . . . . . . . . . . Trunk encapsulation . . . . . . . . . . Trunk negotiation . . . . . . . . . . Remote administration . . . . . . . . . . Power units and outlets . . . . . . . . Terminal servers . . . . . . . . . . . Blade servers . . . . . . . . . . . . Rebooting and initializing . . . . . . . . Trunking negotiation . . . . . . . . . . Example: Establishing trunking connections between switches . . . . . . . . . . . Managing access control lists . . . . . . . . 1132 1132 1132 1133 1133 1134 1135 1136 1137 1137 1138 1138 1139 1139 1140 1141 1141 1142 1142 1143 1143 1143 1144 1144 1145
. 1166 . 1167 . 1167 1168 . 1169 1169 . . . . . . . . 1169 1170 1170 1171 1171 1172 1173 1173
. 1174 1174 . 1175 . 1176 . 1177 1179 . 1180
Contents
vii
Hardware Management Console error messages appear scrambled in a non-English locale. . . . . . . . . . . . . . web interface does not refresh with new data Provisioning tasks cannot be scheduled and submitted from web interface . . . . . Cannot delete shared provisioning tasks . . Provisioning tasks remain in progress after recovery . . . . . . . . . . . . . SSH error occurs during task . . . . . . Install software task fails for extracted installable file . . . . . . . . . . . Task error after using the clean-updeployment-requests command . . . . .
. 1180 1181 . 1181 . 1182 . 1183 . 1183 . 1184 . 1185
Cannot open report after generating request pages. . . . . . . . . . . . . . . 1208 Exported ad hoc report PDF file does not open 1209
Chapter 15. Integrating with other IBM products . . . . . . . . . . . 1211

Configuring single sign-on with Tivoli Monitoring Configuring integration with IBM Tivoli Storage Productivity Center . . . . . . . . . . . Launching Tivoli Provisioning Manager from other products . . . . . . . . . . . . Creating and using change windows . . . . . Example: Adding attribute information manually Example: Adding discovered type information Managing events with Tivoli Enterprise Console Customizing attributes for TEC events . . . Event logging when event transmission fails Configuring Tivoli Provisioning Manager to send events . . . . . . . . . . . . Setting up Tivoli Enterprise Console . . . . Configuring Tivoli Enterprise Console to receive workflow events . . . . . . . . Enabling and disabling the transmission of workflow failure events . . . . . . . . Automating tasks using process workflows . . . Runbook automation basics . . . . . . . Runbook automation process . . . . . . . Requirements . . . . . . . . . . . . Customizing the length of the ACTION attribute . . . . . . . . . . . . . . Installing the runbook automation adapter PMP package . . . . . . . . . . . . Configuring the Tivoli Provisioning Manager runbook automation adapter . . . . . . . Generating process workflow artifacts . . . . Building process workflows . . . . . . . Running process workflows . . . . . . . Troubleshooting the runbook automation . . . 1211 1214 1218 1220 1222 1223 1225 1226 1226 1227 1228 1228 1229 1229 1231 1235 1238 1240 1240 1241 1245 1247 1248 1249
Chapter 14. Reports . . . . . . . . 1187

Getting started with reports . . . . . . . . Predefined reports . . . . . . . . . . . Provisioning Computer reports . . . . . . Provisioning Groups compliance report . . . Patch reports . . . . . . . . . . . . Discovery Configuration reports. . . . . . Provisioning Task Tracking reports . . . . . Provisioning Global Settings report . . . . . Provisioning Workflows report . . . . . . Virtualization Management report . . . . . Other reports . . . . . . . . . . . . Creating ad hoc reports . . . . . . . . . Report object structures and report view objects Running reports . . . . . . . . . . . . Reporting extended attributes . . . . . . . Extended attributes in the Properties table Business value key performance indicators . . . Updating the Start Center . . . . . . . . . Configuring the KPIs . . . . . . . . . . Troubleshooting and Reporting problems. . . . Corrupted text when importing non-English CSV reports to Excel . . . . . . . . . Garbled text displayed when exporting reports into CSV . . . . . . . . . . . . . Missing information when reports are saved in CSV format . . . . . . . . . . . . Error when importing reports . . . . . . Microsoft Internet Explorer 7 hangs when viewing multiple report results . . . . . . 1188 1190 1190 1193 1193 1194 1194 1195 1195 1195 1196 1196 1198 1200 1202 1202 1203 1204 1204 1205 1205 1207 1207 1208 1208
Notices . . . . . . . . . . . . . 1255 Index . . . . . . . . . . . . . . 1259
viii
Chapter 1. Overview
Provisioning applications help you automate your IT processes and optimize resource utilization to address changing business demands and meet service level agreements. Tivoli Provisioning Manager offers smart solutions for software, server, storage, and network automation. The following topics describe basic aspects of provisioning and Tivoli Provisioning Manager and help you get started with different areas of the product:
What's new in this version

This section provides a summary of new product features and enhancements to existing functions. This information center is updated periodically. For a summary of changes to the documentation, see Information center updates on page 9. v v Tivoli Provisioning Manager 7.2.0.2 v Tivoli Provisioning Manager 7.2.0.1 on page 4 v Tivoli Provisioning Manager 7.2 on page 6
Tivoli Provisioning Manager 7.2.0.2

Feature Fix Pack 2 Installation Guide Description Detailed instructions for installing Tivoli Provisioning Manager V7.2 Fix Pack 2. Fix Pack 1 must be installed on your system before you can apply Fix Pack 2. Updated fix pack installation and configuration procedures: v Update the base services v Install the Maximo base services 7.1.1.8 hotfix v Update the core components v Update the web components v New planning worksheet for verifying the user requirements v Upgrade DB2 to version 9.7 to improve performance and scalability Tivoli Common Agent and WebSphere upgrades Important: If you are upgrading WebSphere Application Server, you need to follow a particular roadmap, depending on the platform on which your Tivoli Provisioning Manager server is running. You need to follow a roadmap for your system-specific environment to ensure that your Tivoli Common Agent Services continue to function correctly. Installation Guide Increased accessibility of the installation documentation. Tivoli Common Agent and WebSphere upgrades Resources v Tivoli Provisioning Manager 7.2, Fix Pack 2 Installation Guide - PDF version v Fix Pack 2 installation overview v Fix Pack 2 installation process v Updating the base services v Installing the Maximo Base Services 7.1.1.8 hotfix v Updating core components v Updating web components v Planning worksheet for user requirements v Optional: Upgrading DB2 to version 9.7
v Tivoli Provisioning Manager 7.2, Fix Pack 1 Installation Guide v Tivoli Provisioning Manager v7.2, Quick Installation Guide for Windows v Version 7.2 Installation guide v Tivoli Provisioning Manager V7.1.1 to V7.2 Upgrade Guide
Feature Runbook automation
Description New automation capability to initiate Tivoli Provisioning Manager provisioning tasks from a Maximo instance using out-of-the-box, customizable process workflows. The integration with Tivoli Provisioning Manager is ensured through the web services. New capability of saving images of LPARS with multiple disks is now available. New capability to create LPARs with virtual Fibre Channel adapters. Added support for multiple virtual disks for VMWare and native p (including pBlades) during and after deployment. This also includes support for save and restore. Added support for resizing of disks after deployment on VMWare, native p (including pBlades), and KVM. For virtualization currency, added support for WCA 2.0.0.3 and WCA 3.0 and VMControl 2.3.1.2 and Systems Director 6.2.1.2. Managing virtualization with LPARs Important: Virtual machines managed by Integrated Virtualization Manager that you created before Tivoli Provisioning Manager Fix Pack 2 do not have disk data objects. You must run the Integrated Virtualization Manager Discovery in Tivoli Provisioning Manager Fix Pack 2 before saving a computer. If you do not run the discovery before saving a computer, you will not be able to restore the saved images. Email notification is now supported for virtual Fibre Channel adapters allocation and NPIV resources.
Resources Automating tasks using process workflows on page 1229
Virtualization
Managing virtualization with LPARs on page 1016 Tutorial: Creating virtual Fibre Channel adapters on page 1078 Chapter 10, Configuring virtual servers, on page 1013
Managing virtualization with LPARs on page 1016
Setting up email notification for virtual Fibre Channel adapter allocation on page 1084
Network
Added support for the creation of subnet objects with the same IP address. New capability to create IPv6 64-bit MAC addresses. EUI 64 MAC addresses on page 1153 Acquiring patches over the scalable distribution infrastructure on page 891 Managing patches in Windows environments using the deployment engine on page 911
Patch management
Added information about patch acquisition options and using a WSUS server on Windows platforms using the scalable distribution infrastructure. Added instructions about patch acquisition on Windows platforms using the deployment engine.
Feature Automation
Description Added target automation support for: v AIX 7.1 v Microsoft Windows Server 2008 R2 SP1 v Microsoft Windows HPC (High Performance Computing) 2008 R2 v Microsoft Windows 7 SP1 v Red Hat Enterprise Linux 6 v Red Hat Enterprise Linux 5.6 v SUSE Linux Enterprise Server 10 SP4 v VMware vSphere 4.0 and 4.1, vCenter 4.0 and 4.1, Virtual Infrastructure 3 Updated the corresponding Tivoli Provisioning Manager automation packages for the additional target OS support. Improvements to the VMWare automation package include, for example: v Enhanced performance for discovery of virtual machines v Discovery limited to templates and or clusters only v Newly added support for raw disks The following automation packages are available on the IBM Integrated Service Management Library: v Oracle 11g v Build Forge v DB2 v VMware_Virtual_Infrastructure Updated the Automation Package Developer Environment installation and configuration procedures. Added Automation Package Developer Environment support with Eclipse 3.6 for both 32-bit and 64-bit.
Resources Developer basics
IBM Integrated Service Management Library
v Installing and configuring APDE v Installing Automation Package Developer Environment automatically using a shell script v Installing and configuring Automation Package Developer Environment manually Installing the common agent and subagents using a stand-alone installation on page 641 Changing the default polling interval on page 542 Tivoli Provisioning Manager communication ports Changing the automatic logoff setting on page 32 Collecting data with IBM Support Assistant
Tivoli Common Agent
Updated Tivoli Common Agent stand-alone installation procedure. Added instructions for changing the default polling interval.
Miscellaneous
A list of Tivoli Provisioning Manager port requirements is now available. Added procedure for changing the automatic logoff setting. Updated the IBM Support Assistant for Tivoli Provisioning Manager to collect logs from target computers.
Troubleshooting
Added aids for diagnosing and resolving problems in various areas: v installation v discovery v software distribution v compliance v patch management v Automation Package Developer Environment
v Troubleshooting installation v Troubleshooting discovery on page 239 v Troubleshooting software distribution on page 751 v Troubleshooting compliance on page 858 v Troubleshooting SDI Windows patch management on page 989 v Troubleshooting Automation Package Developer Environment
Chapter 1. Overview
Feature
Description
Resources
Information center Revamped Basics pages for easy access to information. v Controlling user access basics on page 75 enhancements v Discovery basics on page 146 v Operating system management basics on page 261 v Virtual image management basics on page 387 v Image library basics on page 498 v Software deployment basics on page 529 v Compliance basics on page 828 v Patch management basics on page 877 v Virtualization basics on page 1013 v High availability disaster recovery basics on page 1109 v Developer basics
Tivoli Provisioning Manager 7.2.0.1

Feature Fix Pack 1 Installation Guide Description Detailed instructions for installing Tivoli Provisioning Manager V7.2 Fix Pack 1. You can also use these instructions if you have Tivoli Provisioning Manager 7.2 with an interim fix installed. v Update the core components v Update the web components v New platform supported for installation: Red Hat Enterprise Linux 5 Update 5 Installation Guide Increased usability of the installation documentation: separated PDF guides per UNIX operating system. Resources v Tivoli Provisioning Manager 7.2 Fix Pack 1 Installation Guide - PDF version v Fix pack installation overview v Fix pack installation process v Update core components v Update web components v Supported platforms and compatibility v Installation Guide for AIX - PDF version v Installation Guide for Red Hat Linux and SUSE Linux 10 - PDF version v Installation Guide for Solaris and SUSE Linux 11PDF version Image Library v New support of OVF composite virtual appliances on Linux virtual machines for KVM and VMWare. v New support of single and composite image revisions on Linux virtual machines for KVM and VMWare. New capability to publish and unpublish images to more than one group at the same time. New search feature for images using advanced selection methods. Operating system and image management New support of WinPE 3.0 deployment engines. New driver binding method available for golden master images, snapshot images, and unattended setup images. Managing multiple WinPE 3.0 deployment engines on page 289 Binding drivers to Windows images on page 324 Publishing an image on page 520 Composite images on page 510
Feature Automation
Description Updated the following automation packages: v Jumpstart v Kickstart The following automation packages are now available on the IBM Integrated Service Management Library: v Build Forge v DB2 Updated the Automation Package Developer Environment installation and configuration procedures.
Resources Developer basics
IBM Integrated Service Management Library
Installing and configuring APDE
SOAP services Troubleshooting
Added Tivoli Provisioning Manager WSDL-compliant URLs. Added a troubleshooting aid for diagnosing and resolving discovery errors.
Using Tivoli Provisioning Manager URLs to get the WSDL v Troubleshooting discovery v Troubleshooting software distribution v Troubleshooting compliance Patch management troubleshooting checklist on page 992 Getting started basics on page 10
Added a troubleshooting checklist for diagnosing patch management issues. Added a summary of troubleshooting aids on the Getting started basics page. See the Troubleshooting tab. Information center Added a new section for demo videos. enhancements Added a new section for provisioning publications. Enhanced searching: From the Search tab on the information center Welcome page, you can launch your search focusing in specific areas: v IBM Support Portal v Tivoli Provisioning Manager wiki v Integrated Services Management Library v IBM website v Enhanced searching: Added links to message documentation to search for message IDs in the IBM Support Portal or using Google.
Demos Tivoli Provisioning Manager Publications Welcome page
Messages
Chapter 1. Overview
Tivoli Provisioning Manager 7.2

Feature Installation Description v New platform is supported for the administrative workstation: Red Hat Enterprise Linux 5. v New platforms and versions are supported for installation: SUSE Linux Enterprise Server 11 (x86 64-bit and IBM System z 64-bit) and Microsoft Windows Server 2008 R2. v New version of supported base services: 7.1.1.6. v Prerequisites checker: an automated tool to verify if the required packages for UNIX and Linux are installed on your system v Support for changing the host name for the provisioning server. v Support for Maximo authentication and support for changing the default user and password for the installation. v Enhanced files security by setting the umask to 022 for all installation files. v Enhanced look and feel of the installation launchpad. v Support for backing up from the launchpad. You can now back up the deployment engine database for both the custom and default installations. For DB2, you can back up the database when the database is installed on a separate computer. v Increased usability of the installation documentation: separated PDF guides per operating system (Windows and UNIX/Linux). Upgrade v Enhanced upgrade process by separating the base services and web components upgrade. v Streamlined upgrade documentation for pre-upgrade and postupgrade tasks. v Automation packages verifier: an automated tool to check if the automation packages in your environment are correct before upgrading from version 7.1.1 to version 7.2. Compliance v Run a report to determine if you are compliant with Sarbanes-Oxley Act standards. v Run compliance checks on Windows Server 2008 R2 and SUSE Linux Enterprise Server 11. v A unified interface to run and schedule remediation actions. v Enhanced compliance validation and remediation operations that run more quickly. v You can edit software configuration remediation parameters. Discovery v Run a discovery from the Provisioning Groups and the Provisioning Computers applications. v Discover virtual servers. v Specify new or existing computer group during network discovery. v RSA credentials are supported during network discovery. v Discovering attributes of selected computers on page 51 v Discovering attributes of selected groups on page 42 v Discovering virtual servers on page 201 v Specifying a new or an existing group when running the network discovery on page 158 v Upgrade tasks. v Preinstallation tasks for upgrading to Tivoli Provisioning Manager 7.2. v Postinstallation tasks for Tivoli Provisioning Manager version 7.2. v Verify automation packages. Resources v Supported platforms and compatibility v Multiserver deployment v Changing the host name for the provisioning server v Tivoli Provisioning Manager Installation Guide PDF version
v Example: Running a Sarbanes-Oxley compliance report on page 853 v Implementing recommendations on page 852 v Editing software configuration remediation parameters on page 849
v TADDM server versions 7.1.2.6 and 7.2 are supported. v Discovering computers using the RSA credentials on page 157 v Software requirements on page 153
Feature Integration with IBM Service Management Managing software packages
Description v Enhanced software change management and software deployment process due to integration with IBM Service Management. v The maximum size of a software package block of 4 GB has been eliminated. v Software package block files (.SPB files) can now be imported using the web interface, and not only from the Software Package Editor. v You can set a timeout value for installing software package blocks in a DE infrastructure.
Resources
v Importing software package blocks from the Web interface on page 703 v Setting a time out value for installing software package blocks in a DE infrastructure on page 580
Operating system Optional integration with IBM Tivoli Provisioning v Virtual image management basics Manager for Images, which provides a superset of Tivoli and image v Tivoli Provisioning Manager for Images Provisioning Manager for OS Deployment functions. management overview on page 391 Designed to replace Tivoli Provisioning Manager for OS Deployment, Tivoli Provisioning Manager for Images provides all the Tivoli Provisioning Manager for OS Deployment functions plus a set of important virtualization features. The additional virtualization functions enable you to capture virtual images from virtual or physical machines and discover virtual machines and images from various hypervisors. Tivoli Provisioning Manager for Images provides: v Easy management and maintenance of virtual images and physical server images, including content customization and ability to modify images offline. v Tutorial: Managing virtual images on page 437
v More efficient management of image distribution, discovery, capture, replication, storage, and deployment. v Hardware-independent snapshots of server images, to improve agility, flexibility, and recovery of servers. v Server consolidation through image conversions, and quick deployment to various environments. v Management of multiple hypervisor environments by converting images to various formats. v Simplified storage of thousands of images. Patch management v Tivoli Provisioning Manager provides patch management capabilities for SUSE Linux Enterprise Server 11. v Support for patch management on Solaris zones. v New option provides patch acquisition capabilities for Microsoft Windows security bulletins. v Ability to uninstall patches on Windows target computers. v Support extended to Windows Server 2008 R2, and Windows 7. Reporting v Ad hoc Tivoli Provisioning Manager reports enabled by default for several Tivoli Provisioning Manager applications. v New report object structures available for ad hoc reports. v New predefined reports available. v Creating ad hoc reports on page 1196 v Report object structures and report view objects on page 1198 v Predefined reports on page 1190 v Tutorial: Managing patches in SUSE Linux Enterprise Server 11 environments on page 955 v Acquiring patches on page 904 v Cross platform feature support on page 884
Chapter 1. Overview
Feature Scalable distribution infrastructure
Description v New option to stop active distributions. v Support for SUSE Linux Enterprise Server 11, Windows Server 2008 R2, and Windows 7. v You can run a prerequisite check on agents using either a script or a workflow.
Resources v Canceling software distributions on page 605 v Checking prerequisites globally on page 637 v Checking prerequisites locally on page 637
Security
v New option to use Maximo authentication. v Data model object finder shows only objects that users are authorized to see.
v Tutorial: manage security and access permissions using Maximo authentication on page 85 v Lesson 5: Enabling instance level security for data model object finder on page 84 v Quick server provisioning on page 52
Server management Serviceability
v A new streamlined application called Server Provisioning that simplifies creating a physical computer or virtual server. v Enhanced retrievability of troubleshooting information by providing it together with the feature that the information belongs to. v Improved error messages consistency and recovery steps. v Detailed and consolidated logs information for easy troubleshooting.
Target computers
v New sudo support for agent installation. v You can use defined temporary directories on the target computers to best manage disk storage on managed resources.
v Installing the common agent on page 570 v Overriding the temporary directory during SPB installation on page 607
Task management and user interface
v Enhanced task tracking capabilities by providing a progress indicator to monitor tasks that are in progress. v A new user interface skin is available. This skin increases spacing in the user interface views and provides icons that are larger.
Virtualization
v System p Live Partition Mobility support. v Embedded virtualization structures. Consolidated view of the host platform server and associated virtual servers. v KVM hypervisor support. KVM is an open source hypervisor from Red Hat. v VMware vSphere4 integration. Support includes using clusters, the toleration of vNetwork Distributed Switch (vDS) and the ability to use multiple VirtualCenters. v OVF deployment with KVM support. Discover images that have OVF metadata.
v Live Partition Mobility for System p server on page 1056 v Managing virtualization with KVM on page 1030 v Tutorial: Managing virtual servers and host platform servers using VMware on page 1058
Image Library
A new application for cataloging all of the images in the v Chapter 6, Managing images in the image provisioning server. Three new applications are included library, on page 497 in the Image Library: v Configuring an image repository on page 502 1. Image repositories: Represents the managed systems v Master images on page 504 where images are physically located. v Saved Images on page 517 2. Master images: Templates containing hardware and software resources that are used to fully provision new computers. Capture master images and deploy the images onto existing computers and virtual servers, or deploy them to create new computers or virtual servers. 3. Saved images: For virtual servers only, saved images are backups of various states of virtual servers. Use saved images to restore a virtual server, even if the original virtual server has been deleted from the provisioning database.
Feature Workflows
Description v When running commands from provisioning workflows, sudo can be automatically used for the commands that require another user's permission. v Enhanced structure of automation packages documentation for new automation packages. v Increased organization and retrievability of automation packages documentation.
Resources v Running workflow commands using sudo v v Automation packages v Customizing provisioning workflows
v Ability to customize provisioning workflows with extension point LDOs.
Information center updates

This information center is updated periodically. The current version is at 7.2.0.2-IF00001 level. This section provides a summary of changes to the documentation. Details on Tivoli Provisioning Manager 7.2.0.2-IF00001 are available in the readme. v IF00001
IF00001
Table 1. Information center updates
Feature Installation Updates Added new disk space requirements for Tivoli logging directory. Added new documentation for reinstalling the agent manager with bundled JVM on Solaris. Added new documentation to sync Maximo business objects after installing Tivoli Provisioning Manager V7.2, Fix Pack 2. Upgrade Updated the support matrix for upgrading WebSphere Application Server. Added new documentation to bypass the device manager federator upgrade before upgrading Tivoli Provisioning Manager to version 7.2 Runbook automation Added new automation capability to initiate Tivoli Provisioning Manager provisioning tasks from a Maximo instance using out-of-the-box, customizable process workflows. The integration with Tivoli Provisioning Manager is ensured through the web services. Upgrading WebSphere Application Server to Fix Pack 6.1.0.35 Bypass device manager federator upgrade Updated sections Verify the disk space requirements Reinstall the agent manager with bundled JVM Sync Maximo business objects APAR IV02712
Automating tasks using process workflows on page 1229
Security
Updated documentation to configure DMS for Configuring DMS for SSL DB2 connection a secure socket layer DB2 connection. Update Tivoli Provisioning Manager certificate in the Java truststore on page 89 Updated documentation to update the Java truststore when a new certificate is generated by the WebSphere Application Server.
Chapter 1. Overview
Table 1. Information center updates (continued)

Feature Automation Updates v Automation support for Windows 2008 Data Center Edition v HyperV improvements: Support for Image Library Integration Support for Modify Server and Modify Disk v VMware improvements: Support for synchronizing master images from a source to a destination repository Support for uploading an image from a VMWare host to a VMWare datastore Support for creating virtual servers from templates of existing virtual servers v Automation support for Oracle11g v Libvirt support for KVM on SUSE Linux Enterprise Server 11 SP1 Networking Endpoints Added new stand-alone application for fibre channel switches. Agents from one Tivoli Provisioning Manager instance can now be migrated to another instance. Migration from version 5.x to 7.x is supported. Dynaminc content delivery serviceability: you Configuring dynamic content delivery on page 657 can specify the temporary directory for file publishing. Command line tools Enhancements to the ccimport command. You can add, update, and delete compliance checks through xml file. You can cancel a single deployment request. Software management Task management Virtualization Miscellaneous You can now duplicate software stacks. Detailed task status notification is available. When creating LPARS, you can set adapters to be required. Workflow parameter description fields are now available in the Provisioning Task Definition and Run Provisioning Task area. Red Hat Enterprise Linux 5.7 and 6.1 are supported on targets. You can use a wrapper to handle password encryption when performing a task via web service interface. IBM Tivoli Provisioning Manager for OS Deployment 7.1.1.6 is supported. Encrypted password for LWI SOAP interface Detailed task status notification on page 35 Managing virtualization with LPARs on page 1016 Writing new provisioning workflows in the provisioning workflow composer cancelrequests command Fibre channel switches on page 1156 Updated sections Developer basics APAR
Getting started basics

Learn the basic concepts and skills that you need to use the product. v Benefits on page 11 v Key terms on page 11 v Troubleshooting on page 12
10
v Resources on page 13
Benefits
v Use discovery to identify new assets and changes to assets. v Save time and reduce costs by quickly deploying applications. Leverage image library and image mobility support. v Improve utilization of server resources by dynamically moving workloads v Use included automation packages for provisioning numerous types of resources, or build your own automation v Support for large virtualized environments by scaling automation for enterprise needs v Manage compliance with automated remediation of noncompliance issues
Key terms
automation package A collection of commands, shell scripts, provisioning workflows, logical management operations, and Java plug-ins that applies to the operation of a specific type of software component or a physical device. provisioning The process of configuring servers, software, networks, and storage resources. provisioning workflow A program that is used to manage an environment. The program consists of a sequential series of steps that are performed to accomplish a particular provisioning task. scalable distribution infrastructure A solution that ensures fast and reliable software distribution to large numbers of target computers in a variety of topologies. It enables central management of software distribution, and relies on core services such as Tivoli Common Agent services, the dynamic content delivery, and device manager service to perform the actual software distribution and federated job management operations. Start Center A Start Center contains links to actions, applications, data, records, and reports that are relevant to your role. A Start Center organizes everything you need to get started, and provides it in one convenient location.
Chapter 1. Overview
11
Troubleshooting
If you encounter a problem with the product, refer to the following resources: Installation problems Refer to the troubleshooting section of the installation guides. v Troubleshooting the fix pack installation v Troubleshooting installation Troubleshooting aids Check the troubleshooting section related to the area you are working with first. Some sections of the documentation have a troubleshooting aid to guide you through the process of diagnosing problems for a particular product area. They provide information about how a task is processed and where to look for problem determination information when an error occurs during a step in the process. v Troubleshooting security on page 119 v Troubleshooting discovery on page 239 v Troubleshooting operating systems management v Troubleshooting virtual images management v Troubleshooting image library management on page 522 v Troubleshooting software distribution on page 751 v Troubleshooting compliance on page 858 v Troubleshooting SDI Windows patch management on page 989 v Patch management troubleshooting checklist on page 992 v Troubleshooting virtualization management on page 1095 v Troubleshooting task management on page 1180 v Troubleshooting and Reporting problems on page 1205 v Troubleshooting Automation Package Developer Environment v Automation Package Developer Environment troubleshooting checklist v Troubleshooting provisioning workflows v Activity Plan Editor troubleshooting v Software Package Editor troubleshooting If a troubleshooting aid is not available in the area you are working with, check Troubleshooting section. For example, if you are working with reports, refer to Troubleshooting section under Managing reports. Messages If you received an error message with an ID such as COPCOM004E, search this information center for the message ID or browse through the full list in the Messages section. Search other IBM resources Search the Search the IBM Support Portal for technotes and other documentation about the problem. You can perform a quick search of the IBM Support Portal and other resources on the Search tab of the information center Welcome page. Gather diagnostic data for the product The Support Information section of the information center provides additional troubleshooting resources and tools to help you collect data for problem determination.
12
Resources
Use the following resources to get started with the product: v Tutorials and demos v Tivoli Provisioning Manager overview v First steps on page 26 v For a description of a field in the Tivoli Provisioning Manager console, press Alt+F1.
Tivoli Provisioning Manager overview

Introduction to Tivoli Provisioning Manager. Many organizations face challenges in managing their existing IT resources, evaluating their effectiveness in supporting business needs, and determining how to meet future needs with existing or new resources. To effectively respond to change, financial pressures, and competition, businesses need to maintain an environment that is flexible, responsive, and makes optimal use of available resources. There are two aspects to creating such an environment: A flexible business model Many organizations have difficulty responding to change. In some organizations, processes might be too rigid and difficult to adapt to different situations. Conversely, other organizations struggle with processes that are unclear, inconsistent, or duplicated by participants in the processes. To effectively respond to change, businesses must clearly define their end-to-end automation flows. For maximum flexibility and consistent implementation, subprocesses must be designed as components that can be customized or reused in larger processes. A flexible IT environment To support changing business needs and priorities, the IT infrastructure that supports the operations and applications in a business must be optimized for allocation based on demand and for repurposing in different business contexts. You can develop an optimized IT environment by: Modeling your automation flows You can capture your automation flows in provisioning workflows. These provisioning workflows can automatically and consistently perform the configuration tasks that you might currently perform manually. You can customize existing provisioning workflows, or create new ones to support your existing tools and processes. Provisioning workflows can be used to automate processes such as configuring and allocating computers or installing, configuring, and patching software. They can be large and complex, or consist of a single command. The automation of configuration tasks is called automated provisioning. Modeling your enterprise resources The virtual representation of your enterprise is managed in a data model. Virtualization exists on several levels to provide flexible configuration in different contexts: v Each resource is represented by a data object. When you make a change to a resource, the data object is updated in the data model. If a change is made outside of Tivoli Provisioning Manager, the external change can be identified by comparing it with the data object in the data model. v For some assets, the data model stores data about the resource and data about deploying or provisioning the resource separately to provide a range of implementation options. For example, when a software package is added to the software catalog, you define the software
Chapter 1. Overview
13
package as an installable file. You can then create software definitions that describe different configuration requirements and configuration options for installing the same software package.
Component architecture
Tivoli Provisioning Manager consists of a provisioning server, a Web-based operator and administrator console, and an Automation Package Developer Environment.Tivoli Provisioning Manager consists of an Automation Package Developer Environment. The following diagram illustrates the main product components, and how they interact with your managed IT infrastructure and other applications in your environment.
Operator and administrator console External management applications
Provisioning server
Automation
Devices - Computers and virtual servers - Network devices - Storage
Web Services interface
Compliance and remediation
Reporting
Patch management
Data model
Provisioning database
Software provisioning Tivoli Provisioning Manager for OS Deployment/ Tivoli Provisioning Manager for Images Discovery
Image management
Deployment infrastructures
Scalable Distribution Infrastructure

Agent manager
Deployment engine
Dynamic Content Delivery
Device Manager Service
Managed IT infrastructure
Automation Package Development Environment
Content distribution system depot (TCA)
IBM Open Process Automation Library
Federated job management system
Target (TCA)
User Directory (LDAP)
Target (TCA)
Target (TCA)
Legend
TCA = Tivoli Common Agent
Target (TCA)
14
Product components
Provisioning server The provisioning server is the server on which Tivoli Provisioning Manager is installed. The provisioning server contains the following components:
Table 2. Provisioning server components Component Provisioning database Data model Description The provisioning database is the physical database for Tivoli Provisioning Manager. The provisioning database holds the data model. The data model is a representation of all the physical and logical assets that are managed by the provisioning applications, such as computers, switches, load balancers, application software, virtual LANs, and security policies. It tracks hardware and associated allocations to applications, and changes to configuration. When a provisioning workflow successfully completes a requested change, the data model is updated to reflect the current infrastructure. The data model also stores information about allocated and deallocated computers in resource pools for tier management. This information can include computer identifiers, resource pool size, the number of available and idle computers, computer priority, and similar information. Discovery and configuration management also use the data model to identify configuration changes that are made outside of the provisioning applications. You can review changes and use the change information to restore an asset to a previously known state. Automation An automation package is a collection of provisioning workflows, scripts, and other commands and tools that apply to the operation of a specific type of software component or a physical device. The deployment engine manages the deployment of provisioning workflows and associated components in an automation package. You can use automation packages to automate the provisioning of software, patches, images, and operating systems, as well as devices, including computers, network devices, and storage. Compliance and remediation Compliance management allows you to examine the software and security setup that you have on a target computer (or a group of computers) in your managed infrastructure and then compare that setup with the setup that you want in order to determine if they match. If they do not match, noncompliance occurs, and recommendations (remediation) on how to fix the noncompliance issues are generated. Reports allow you to retrieve current information about enterprise inventory, activity, and system compliance. The reporting functions include: v Predefined reports. v A Web-based query builder, which you can use to customize existing reports or create new reports. v Access to information in the data model using views. v Sharing of report definitions using import and export capabilities in the web interface. v Charts and graphs. v The ability to schedule reports to run at a later time or at repeating intervals. v E-mail report distribution and notification. v Integration with vendor reporting software.
Reporting
Chapter 1. Overview
15
Table 2. Provisioning server components (continued) Component Discovery Description Discovery provides automated processes that help you find resources, as well as changes to existing resources, within your enterprise or managed IT infrastructure. You can use the following discovery technologies: v Microsoft Active Directory discovery: Discovers computers by organizational unit, Microsoft Active Directory groups, and computer attributes defined in Microsoft Active Directory. v Tivoli Provisioning Manager network discovery: Discovers computers, their host name and networking information, new resources and changes to existing managed resources. v Tivoli Provisioning Manager Inventory discovery: Discovers configuration changes and hardware and software on devices. v TADDM discovery: Imports the information of IT resources and their relationships from Tivoli Application Dependency Discovery Manager (TADDM) into the data model. Deployment infrastructure You can reconfigure and reallocate resources in your managed environment using two different deployment infrastructures: a scalable distribution infrastructure, and a deployment engine infrastructure. For more information about these infrastructures, see Deployment infrastructures. Tivoli Provisioning Manager for OS Deployment is a database-driven, PXE-based deployment solution. You can use Tivoli Provisioning Manager for OS Deployment to perform the following tasks using source servers: v Windows cloning (capturing a golden master image) and unattended setup v AIX unattended setup v Linux cloning (not supported on Linux PPC), and unattended setup v Solaris unattended setup v VMWare ESX unattended setup New with Tivoli Provisioning Manager version 7.2, you can opt to upgrade your Tivoli Provisioning Manager for OS Deployment to Tivoli Provisioning Manager for Imagesto gain access to an important set of virtualization features that are not available in Tivoli Provisioning Manager for OS Deployment.
Tivoli Provisioning Manager for OS Deployment, Tivoli Provisioning Manager for Images
Web Services interface By using Web Services, including Web Services Resource Framework (WSRF) services, you can access the data model directly without launching the web interface. You can use Web Services to access, manipulate, or change objects directly in the data model. Operator and administrator console By using the Web-based operator and administrator console, you interact with the provisioning server. The operator and administrator console provide a graphical representation of the IT assets, 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 Automation Package Developer Environment (APDE) is an Eclipse-based plug-in environment that automation package developers can use to create or customize automation packages. IBM Integrated Service Management Library The IBM Integrated Service Management Library 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, and documentation. User directory Tivoli Provisioning Manager integrates with several directory servers, allowing you to manage your user accounts and user authentication with a directory server of your choice.
16
External management applications Tivoli Provisioning Manager includes the capability to integrate with external system management applications, including IBM IT Service Management and other vendor software.
Deployment infrastructure
You can reconfigure and reallocate the resources in your managed environment using two different deployment infrastructures. The following deployment infrastructures are supported: v Scalable distribution infrastructure v Deployment engine infrastructure on page 20
Choosing a deployment infrastructure

Which deployment infrastructure you use depends on the following factors: v Your existing infrastructure. v The number of managed target computers and the size of the managed environment. v What function you want to use. You can use two software patch, inventory and distribution methods: scalable distribution infrastructure or deployment engine. The deployment engine infrastructure is used for automating operations on smaller sets of managed target computers and is the default infrastructure for some of the automation packages provided. The scalable distribution infrastructure provides: v Scalable design: You can add depot servers to accommodate the needs of your network. v Optional peer-to-peer file sharing: A file can be downloaded from peer systems that have previously downloaded the same file. v Adaptive bandwidth control: You can throttle the transfer rate from both depot servers and peers to minimize the impact of downloads on existing network traffic from other applications.
Scalable distribution infrastructure

The scalable distribution infrastructure allows you to centrally manage software distribution, while existing core services such as the dynamic content delivery and device management service perform the actual software distribution and federated job management operations.
Chapter 1. Overview
17

Provisioning server
Dynamic Content Delivery Service Management Center
Device Manager Federator
Agent Manager
Distribution server m Distribution server 1

Device Manager Federated Agent
Dynamic Content Delivery Service Depot
...
2 1
Common Agent target computer - Device Manager Subagent
- Dynamic Content Delivery

Service Subagent
- Common Agent
The scalable distribution infrastructure includes the following main components: Provisioning server The provisioning server is the server on which Tivoli Provisioning Manager is installed. The following components of the scalable distribution infrastructure are installed on the provisioning server:
18
Table 3. Scalable distribution infrastructure components on the provisioning server Component The dynamic content delivery management center Description v Provides centralized control of the upload, replication, and download of files. v Monitors the state of depot servers and stores file data and download statistics. v The dynamic content delivery management center implements a distribution policy that sends bulk data to some or all the distributed depot servers in advance of when it is needed. The device manager federator v Is installed on the provisioning server and is configured to act as a federated server. v Implements a job distribution policy that sends incoming jobs to all the regional agents. The agent manager Tivoli Provisioning Manager uses the Tivoli Common Agent Services for software distribution and compliance. Tivoli Common Agent Services provides an infrastructure for managing the computer systems in your environment. v The agent manager is the server component of the Tivoli Common Agent Services. Through its functions, the clients get information about agents and resource managers. v It enables secure connections between managed target computers, maintains the database information about the target computers and the software running on them, and processes queries against that database from resource managers. v It includes a registration service, which handles security certificates, registration, tracking of common agents and resource managers, and status collection and forwarding.
Distribution servers The provisioning server connects to distribution servers, or directly to the target computers. The distribution servers contain the following components:
Table 4. Distribution server components Component The device manager federated agent Description v Agents are installed on distribution servers and are configured to communicate with the federator to get command jobs and to distribute them to the set of clients installed on the target computers. v The agents on the distribution server periodically communicate with the federator and detect when there is network connectivity. The dynamic content delivery v Depots ensure communication between the management server and the clients installed on target computers. v The dynamic content delivery depots communicate with the management server to get data requested by the target computers.
Tivoli Common Agent targets Distribution servers connect to the target computers. The target computers contain the following components:
Table 5. Target computer components Component The device manager subagent The dynamic content delivery subagent Description Clients are installed as device manager subagents on the target computers at the branch and are used for receiving job tasks and returning results to the agents. Subagents are installed on all the managed systems or target computers to download files from depot servers or from other clients.
Chapter 1. Overview
19
Table 5. Target computer components (continued) Component Tivoli Common Agent Description v Tivoli Common Agent is installed on the target computers and acts as a common container for all the subagents. v The deployed agent software collects data from, and performs operations on, managed resources on behalf of a Tivoli management application. It provides shared system resources and secure connectivity.
Deployment engine infrastructure

The deployment engine is used for automating operations on smaller sets of managed target computers and runs the automation packages that are available. The deployment engine: v Creates, stores, and runs provisioning workflows and communicates their success or failure in performing an operation. v Runs the provisioning workflows against the managed target computers, using any available native communication protocol. The provisioning workflows can be triggered by commands from an administrator, by external tools that send SOAP commands, or by recommendations from the policy engine.
Managing your system life cycle

Provisioning applications provide you with the capability of automating the processes in the life cycle of your managed systems. The following diagram illustrates how provisioning can help you automate your managed system life cycle:
Operating system installation Software installation
Discovery
Compliance
Redeploy
Patch and upgrade management
You want to create a list of what resources are available in your enterprise, and which operating systems and software are on each resource. The automated process of finding resources within an enterprise is called discovery. The discovered inventory is then recorded in the data model. The data model is a centralized repository on the provisioning server that represents all the physical and logical assets that you manage using provisioning applications.
20
You discover that several resources in your enterprise need a new operating system. Using provisioning applications, you install the correct operating system on each computer. These computers now need software. All the software defined in the data model is recorded in the software catalog. Software packages are stored in file repositories linked to the software catalog. From the software catalog, you install the required software on each computer. After installing operating systems and software, you can ensure that all computers in your enterprise have an antivirus program with up-to-date virus definitions. Using compliance checks, you determine which computers are noncompliant. You can then remediate the noncompliant systems by installing the antivirus application and definition file. A few days later you need to apply a patch to all the computers that have the Windows operating system installed. You retrieve the available patches from the third-party repository and then query the computers in your enterprise to see which computers need the patches. You then approve the patches to be installed and distribute and install the patches. Finally, you determine that some of the older computers in your enterprise can be reused. You need to replace the operating systems with a newer version or the installed software stack with different applications. The entire cycle starts over again.
Discovering enterprise resources

You are provided with the automated processes to discover devices and configuration changes for the computers, switches, subnetworks, software, and images within your enterprise. You can create an inventory of what resources are available in your enterprise, and which operating systems and software are on each device. The following diagram illustrates how discovery is automated:
Chapter 1. Overview
21
Provisioning server
1
Discover hardware
2
List of hardware populates the data model
Enterprise
3
Scan the target computers
4
Populate the data model with hardware attributes, software catalog, and inventory of software
5
Organize inventory into groups
6
Report on inventory
1. Run an inventory discovery task to look for hardware within the IT enterprise. You discover hardware including computers, operating systems, CD-ROM, hard disks, hard disk size, memory, input/output devices such as USB devices, network printers, and processor-related information. 2. An inventory with the discovered hardware is generated. This inventory is recorded in the data model. The data model is a centralized repository on the provisioning server that represents all the physical and logical assets that you manage using provisioning applications. 3. Run another inventory discovery task to look for software on each device for which you require this information. You then scan those specific target computers previously discovered in the enterprise. 4. An inventory of the discovered software, including discovered operating systems, is generated. This inventory is recorded in the data model in the software catalog. 5. You can organize the discovered devices and software by using provisioning groups. In dynamic groups, target computers are assigned using queries against the data model by referencing inventory attributes. Additional groups can be defined by additional data model attribute queries. You can also create static groups where you assign target computers manually. 6. You can now generate reports showing the current information about the managed assets, including reports on available software, currently installed software, and hardware activity. You can also generate reports showing the last discovery scan results by target computer and by discovery scan type. The report data is extracted directly from the data model.
Managing operating systems

You can use automated processes to manage your operating systems, including installing operating system software, and capturing and restoring disk images.
22
The following diagram illustrates a typical operating system installation process:

Provisioning server
Data model
Target
Target
Target
Boot server
Target
First, you discover what devices exist in the enterprise that you want to manage and what operating systems exist on these devices. This information is then recorded in the data model. The data model is a centralized repository on the provisioning server that represents all the physical and logical assets that you manage using provisioning applications. Then, the target and operating system installation requirements are registered with the associated boot manager or boot server. The boot server then installs the appropriate operating system image on the appropriate target computer.
Distributing and installing software

You can use automated processes to distribute and install software to all the targets in your enterprise. The following diagram illustrates a typical software distribution process:
Provisioning server
Data model
Target
Inventory
Target
Target
Software catalog
Target
File repositories
Distribution technologies
The details of all the discovered software that you already installed in your enterprise, and all the software available to your enterprise, are recorded in the software catalog in the data model. The software itself is stored on servers that you use to store software centrally. These servers are called file repositories.
Chapter 1. Overview
23
To install software, you have the option of distributing the software to the targets to be installed immediately or at a scheduled time. You can choose to distribute and install software on a single target, or on groups of targets, on targets running as application tiers, or on targets in resource pools. You can also distribute and install a single software product or multiple software products.
Managing compliance
The compliance management capabilities help you determine if the installed software and security settings in your enterprise match the setup you want. If systems are noncompliant, you get recommendations to fix noncompliant systems. The following diagram illustrates a typical compliance process:
Discover computers
Install common agent
Define compliance checks
Run compliance checks
Run scan and compliance checks
Review and approve recommendations
Verify compliance
Perform recommended action
Legend Provisioning Administrator Provisioning Configuration Librarian Compliance Analyst Deployment Specialist
1. You discover what software is installed and which applicable security settings exist on each target computer in your enterprise. 2. An inventory of the discovered software and security settings for each target computer is generated. This information is recorded in the data model. The data model is a centralized repository on the provisioning server that represents all the physical and logical assets that you manage using provisioning applications. 3. To determine if the software and security on your enterprise matches your requirements, you create compliance checks. Compliance checks define the compliant state of your target computer or group of target computers and are used to detect, report, and remediate any noncompliance. The inventory in the data model is then compared with the compliant state defined in the compliance check. 4. If the compliant state does not match the actual state of the target computer, noncompliance occurs. A report of the noncompliant issues, which recommends corrective actions, is generated. 5. After reviewing the recommended actions, you select and approve the corrective actions you want to take, and then run these actions. A follow-up scan shall show that your target computers are now compliant.
24
Managing patches and upgrades

You can deploy missing software patches to computers in your enterprise. You can also check the software installation status of multiple target computers. The following diagram illustrates a typical patch management process:
Provisioning server
1
Available patches Retrieve available patches
Third party patch repository
Data model
2 Query target for patches 3 Target returns list of required patches
Target
Target
Administrator approves patches to be installed
Target
Target
Approval process
Install approved patches
1. The details of all software patches and upgrades that you already have installed in your enterprise, and all patches available to your enterprise, are stored in the provisioning server. You can set up your patch management process so that you automatically receive the updates from third-party patch repositories and add them to the patch catalog. 2. You can discover what level of software, including patches, exists on each target in your enterprise. 3. An inventory of the discovered software and patches is generated and a list of software and patches that are required for each target is recommended. This information is recorded in the data model. The data model is a centralized repository on the provisioning server that represents all the physical and logical assets that you manage using provisioning applications. 4. You review the list of recommended patches and approve the patches that you want to install. 5. You install the approved patches on the corresponding targets. A follow-up scan shows that your targets have the approved patches installed.
Chapter 1. Overview
25
First steps
Learn how to get started with Tivoli Provisioning Manager. Depending on your role and goals, you can start with different areas of the product:
Get started with the user interface

Table 6. Basic user interface actions Actions and concepts Launching the user interface Description The Tivoli Provisioning Manager user interface is Web-based. It can be accessed with a Web browser by entering https://host_name:port/maximo, where hostname is the fully qualified domain name of the provisioning server and port is the provisioning server port number. For security reasons, you must log on to the provisioning server and log off when you stop using it. Learn how to customize the appearance and behavior of the user interface accessed by different users based on their security group assignment. An application is a computer program or software component that provides functions in direct support of a specific business process or processes. Users have access to specific applications based on the security group they belong to. Security group definitions: Predefined security groups Full list of applications available for a security group: Security groups and application access rights Search and filter There are several search and table filtering options available in Tivoli Provisioning Manager. These options include the ability to use advanced search, create search queries, and use wildcard characters in your search strings.
Logging on. Logging off Customizing the interface Opening an application
Get started with a provisioning scenario

Table 7. Provisioning scenarios Scenario Controlling user access Description Learn about: v Security components and security process v Integration with IBM Service Management v Creating new users v Adding users to security groups v Using predefined security groups or creating new security groups v Customizing access to provisioning groups and applications Discovering IT resources Learn about: v Discovery roles v Discovery process v Troubleshooting discovery errors Deploying operating systems Learn about: v Discovering, managing, and deploying images v Operating system basics v Operating system management and deployment processes Operating system management basics on page 261 Discovery basics on page 146 Basic information Controlling user access basics on page 75
26
Table 7. Provisioning scenarios (continued) Scenario Deploying software Description Learn about: v Scalable distribution infrastructure components v Scalable distribution infrastructure process v Troubleshooting software deployment errors Checking compliance Learn about: v Compliance roles v Compliance process v Troubleshooting compliance errors Deploying patches Learn about: v Patch management basics v Patch management process v Troubleshooting patch management Configuring virtual servers Learn about: v Virtualization roles v Virtualization components v Troubleshooting virtualization errors High availability disaster recovery Learn about: v High availability considerations v Solution constraints and architecture v Disaster recovery Managing provisioning tasks Learn about: v Task management roles v How to create and track a provisioning task v Provisioning tasks in IBM Service Management Task management basics on page 1157 High availability disaster recovery basics on page 1109 Virtualization basics on page 1013 Patch management basics on page 877 Compliance basics on page 828 Basic information Software deployment basics on page 529
Get started with tutorials and demos

v Tutorials v Demos
Get started with reports

Click Reports in the navigation bar to display a menu of modules and applications. Select an application on which you want to run reports. To learn more about running reports, customizing reports and creating new reports, go to Chapter 14, Reports, on page 1187 or see the Report Developer Guide.
Tutorial: Learning the user interface

Learn how to get started with Tivoli Provisioning Manager. You can also learn about the user interface by watching the demonstration video: Exploring the user interface (04:11).
Learning objectives
v Logging on and logging off v Using the Start Center
Chapter 1. Overview
27
v Opening an application v Searching and filtering v Getting help while you work
Time required
This tutorial should take approximately 30 minutes to finish. If you explore other concepts related to this tutorial, it could take longer to complete.
Logging on to the provisioning server

For security reasons, you must log on to the provisioning server and sign off when you finish using it.
Before you begin

v You must have an appropriate Web browser. The following Web browsers are supported: Internet Explorer version 6.0 or 7.0 with the latest patch Firefox 3.0 Note: The only UNIX platform on which Firefox has been certified is Red Hat Linux.
AIX To get a browser for AIX, go to http://www-03.ibm.com/systems/power/software/aix/ browsers/index.html. Depending on your current operating system configuration, you might need to install some additional packages before you can install the browser. To obtain the required packages, go to http://www.ibm.com/systems/p/os/aix/linux/toolbox/download.html
v You must know the fully qualified domain name, for example, hostname.domain.com, and port number for the provisioning server. v You must know your user name and password for the provisioning server. v The provisioning server must be running. To sign on to the provisioning server:
Procedure
1. Open the Web browser and enter: https://host_name:port/maximo where hostname is the fully qualified domain name of the provisioning server and port is the provisioning server port number. The default secure port number (using https://) is 9443. 2. In the Log On window, type your User ID and Password and click Log On.
Results
You are now signed on to the provisioning server, which displays the appropriate Start Center.
Signing off the provisioning server

To prevent unauthorized access to the web interface, log off the provisioning server after you have completed your tasks. By default, you are automatically logged off after 30 minutes of inactivity.
Procedure
Click Sign Out to sign out of the web interface.
28
Results
You are now signed out of the web interface.
What to do next
You must completely close all tabs and exit the browser after logging off the web interface to completely end the session. If you do not exit the browser after logging off, another user can open a new tab and access the web interface without logging on.
Start Center
A Start Center contains links to actions, applications, data, records, and reports that are relevant to your job. A Start Center organizes everything you need to get started, and provides it in one convenient location. The first time that you log on to the system, you see a Start Center that is based on a template for the security group that you are assigned to. Start Centers are assigned to security groups by a system administrator. If your user name is assigned to more than one security group, you might have more than one Start Center. Start Centers can be customized to suit your needs. Each column in the Start Center can be configured to display one or more portlets, or windows, which display data, links, or reports that are available in a specific application. The portlets that make up a specific Start Center are often chosen to support a particular job function, and can include any of the following:
Table 8. Start Center components Component Quick Insert Description The Quick Insert portlet in your Start Center is used to display actions that you perform frequently. Clicking an action in the portlet takes you directly to the task without having to drill down through other menus. Use Favorite Applications to create a list of the applications that you use most frequently. This list can then be used to start these applications from your Start Center. This specific query portlet displays the results of a saved query. IBM Tivoli Unified Process (ITUP) documents processes are based on industry best practices and is designed to help users to easily understand processes, the relationships between processes, and the roles and tools involved in an efficient process implementation. Displays your workflow inbox, which contains records that have been routed to you and that require an action, for example, review and approval. Displays bulletin board messages. It is used to create, post, and view messages, and to broadcast information to system users. Result sets are a set of records that matches the criteria specified in a query to the database for predefined process request queries.
Favorite Applications ITUP documents
Inbox/ Assignments Bulletin Board Result sets
Note: For more information about Start Centers, see the Product Reference guide.
Multiple start centers

If your user name is assigned to more than one security group, the system displays each Start Center as a separate tab, one for each Start Center. To view a different Start Center, click the tab for that Start Center. You can manage multiple Start Centers using the Display Settings link. This link allows you to: v Change the name of a Start Center. v Indicate if a Start Center is displayed or hidden.
Chapter 1. Overview
29
v Indicate which Start Center appears as the first tab (default).
Opening an application
An application is a computer program or software component that provides functions in direct support of specific business processes. There are several ways to open an application directly from the Start Center. 1. You can use any of the following methods to open an application: v Go To menu: To open an application, click the Go To link, then select the module and application. For example, to open the Provisioning Computers application, click Go To > Deployment > Provisioning Computers. The Go To menu is typically available from within applications. v Favorite Applications portlet: Click the application link in the Favorite applications portlet to open an application. v Inbox/Assignments portlet: Click the record ID to open an application and view a record that has been assigned to you for action. v Quick Insert portlet: Click the link in the Quick Insert portlet to open an application and insert a new record. v Result sets are a set of records that matches the criteria specified in a query to the database for predefined process request queries. 2. When the application opens, the List tab displays items that you can work with in the application. To view details about an item, select the item in the list and then click the tab that you want to view. For example, the Provisioning Computers application has a Software tab that displays installed software a computer based on the data in the Tivoli Provisioning Manager database. 3. To return to the Start Center, click Start Center at the top of the page. Note: For more information about opening applications, see the Product Reference guide.
Searching and table filtering

There are several search and table filtering options available in Tivoli Provisioning Manager. These options include the ability to use advanced search, create search queries, and use wildcard characters in your search strings. When you open an application, the system displays the List tab. You can run several actions from the List tab:
Basic searches
Search using saved queries The Query field in the toolbar contains a menu that includes any queries you have created and saved for an application, and two additional search options: v All Records. v All Bookmarks. If you perform a query from this menu, the system executes it immediately.
Using the search toolbar

Advanced Search Advanced Search in the search toolbar allows you to perform several different search-related actions. If you click it, the following options are available: v More Search Fields. Click this option to access additional record fields for query by example (QBE) searches.
30
v Where Clause. Click to view your current structured query language (SQL) WHERE clause or to construct a new WHERE clause to use to search the database. v View Search Tips. Click to view a help topic containing tips for searching the database. Save Query The Save Query button in the search toolbar activates the following options: v Save Current Query. Click to name and save your current query so that you can reuse it at a later time. v View/Manage Queries. Click to view and manage your saved queries for the current application.
Using the find field to search

Search using the Find field You can use the Find field in the toolbar to search for a single record by the record ID or key field. You can use the Find field to search from any tab in the application. You must know the exact record ID to search using the Find field. To search using the Find field, complete the following steps: v Enter a record ID in the Find field. v Click the Quick Key Search button.
Using the table filter to refine search results

Table filter You can use the Filter field in a List page to search for records that match a specified string of text. To Filter button, then enter your search string and click Enter or . When see a filter field, click the your results are returned, click the appropriate link to go to the details tab. If you don't enter anything in the Filter field, and click Enter, all records for the List page are listed. To filter using different criteria, click Wildcard characters If you do not know the exact value for a field that you want to use in a query, you can search using the partial value plus a wildcard character. A wildcard character is a special symbol that represents one or more characters. v The * and % character are both treated as full wildcards. Use these characters to match any non-null values. v The _ (underscore) character acts as a single character wildcard. v If you specify a wildcard while using a partial string for searching, you must manually add a % wildcard at the end of your search string for the search to be performed correctly. For example: Get_Parents%. Sorting tables You can sort columns with underlined headings. To sort a column, click the heading. You can sort only one column at a time, and that column displays an icon in the column header. Note: You cannot sort or filter several or all columns.
Chapter 1. Overview
31
For more information, see the Product reference guide.
Help while you work

Tivoli Provisioning Manager provides interactive assistance to help you learn about the product capabilities, and how to use them for everyday tasks. You can use the following forms of assistance: Click Alt+F1 in a field to access information about it. You can also access Additional Help in this dialog. Click Help in the menu to access the help system: v Go to Help > More Help to find details about the user interface. v For more information about the provisioning tasks, open the Welcome to Provisioning page directly from the Help menu by selecting Help > Welcome > Welcome to Provisioning. Search the Tivoli Provisioning Manager information center: enter a query in the Search field, and click Go. to locate topics in the help system using index keywords. You can input the Click the Index tab keywords in the input field. For the Software Package Editor (SPE) and Application Package Editor (APE), context-sensitive help is available. For more information see: v Viewing information in the information center section in the provisioning help system. v Tivoli Provisioning Manager Wiki at http://www.ibm.com/developerworks/wikis/display/ tivoliprovisioningmanager/Home
Configuring system settings

This section contains information about configuring general settings such as automatic logoff and notification.
Changing the automatic logoff setting

The default automatic logoff value is 30 minutes. You might want to change the default setting depending on your security needs. The automatic logoff is configured to automatically timeout after a period of 30 minutes of inactivity. To extend the default period to more than 30 minutes, you change the web.xml configuration file.
Procedure
1. Back up the web.xml file. On Windows, the web.xml file is normally located in the MAXIMO_HOME\applications\maximo\maximouiweb\webmodule\WEB-INF directory. On UNIX systems, the default location is the MAXIMO_HOME/maximo/applications/maximo/maximouiweb/webmodule/WEB-INF directory. MAXIMO_HOME is the directory where the base services are installed. On Windows, the default path is c:\IBM\SMP. On UNIX systems, the default path is /opt/IBM/SMP. 2. Open the web.xml file in a text editor. 3. In the <session-config> section, search for the session timeout tag, named <session-timeout>. In the following code example, the automatic timeout is set to timeout after 90 minutes.
32
<session-config>  <session-timeout>90</session-timeout> </session-config>
4. Change the existing value in the <session-timeout> tag to the value you want to specify as the new logoff value. 5. Save and close the web.xml file. 6. Rebuild the Maximo EAR file on the administrative workstation to invoke the changes. To rebuild the Maximo EAR, run one of the following scripts, depending on your platform: a. On Windows systems, run the buildmaximoear script, located in the C:\Maximo\deployment directory on the administrative workstation. b. On UNIX systems, run the buildmaximoear.sh script, located in the /opt/IBM/SMP/maximo/ deployment directory on the administrative workstation. 7. Deploy the Maximo EAR to WebSphere Application Server. You can deploy the Maximo EAR using WebSphere Application Server or you can use the command line. To view command line instructions about how to deploy the Maximo EAR file, see Manually deploying the EAR file. To deploy the Maximo EAR on WebSphere Application Server, complete a process similar to the following example on WebSphere Application Server v6.1.0.29: a. Log on to WebSphere Application Server. b. Click Applications, then Enterprise Applications. c. Uninstall the previous Maximo EAR before you begin redeploying the new one because updating the existing Maximo EAR can cause caching issues. d. Click Install. e. If WebSphere Application Server is on the administrative workstation, navigate to the location of the Maximo EAR by clicking Local File System. If you do not have direct access to the administrative workstation on which the Maximo EAR is located, click Remote File System and navigate to the Maximo EAR location, for example on Windows C:\ibm\SMP\maximo\deployment\ default, and click the file. f. Click OK, then click Next. g. On the Select installation options screen, make sure that the Maximo installation is selected. If there are multiple Maximo installations on your WebSphere Application Server environment, click the specific application name for the installation. Then click Next. h. On the Map modules to servers screen, select the web server and application server in the Clusters and Servers box, select all of the modules, then click Apply. i. Click Next. j. On the Map virtual hosts for Web modules screen, click the options for your installation and change the Virtual host options to the host you have set up for the Maximo application. Click Next. k. On the Summary page, review the summary and click Finish. l. After the Maximo EAR file has installed, click Save to save your changes. The Maximo EAR is now deployed to the server. m. Go to the WAS console and from the navigation tree, click Applications > Enterprise Applications. Then click MAXIMO > Class loading and update detection. For WAR class Loader Policy, the Class loader for each WAR file in application option is selected by default. Click the Single class loader for application option. Click Save to save your changes. n. Restart Tivoli Provisioning Manager. If you have problems logging into Tivoli Provisioning Manager after rebuilding the Maximo EAR, see https://www-304.ibm.com/support/ docview.wss?uid=swg21321974 for information about how to resolve the issue.
Chapter 1. Overview
33
Results
You have configured the automatic timeout to a time length of your choice.
Configuring the List view to be empty by default

Many provisioning applications automatically display entries on the List tab by default. If there are many entries, displaying the list can impact performance. You can use the Application Designer to configure the list view to be empty by default.
Procedure
1. Click Go To > System Configuration > Platform Configuration > Application Designer. 2. On the Applications tab, find the application that you want to modify. To find provisioning applications, type tp in the Application filter field and then press Enter. Click the application name in the search results A preview of the application is displayed on the Workspace tab. 3. In the application preview, click the name of the application next to the Filter heading. 4. On the toolbar, click Control Properties . 5. In the Table Properties window: a. Select the Start Empty check box. b. Clear the Row Details Expanded check box. 6. Close the Table Properties window. 7. Click Save .
Moving Tivoli Provisioning Manager to the top of the information center

The Tivoli Provisioning Manager at the top, of the list of information centers. To move the Tivoli Provisioning Manager information center to the top:
Procedure
1. In the WebSphere Application Server installation directory, find the file preferences.ini in the following locations: Windows
%WAS_HOME%\systemApps\isclite.ear\iehs.war\WEB-INF\lib\eclipse\plugins\org.eclipse.help.base_3.0.0 %WAS_HOME%\systemApps\isclite.ear\iehs.war\WEB-INF\lib\eclipse\plugins\org.eclipse.help.base_3.0.1
UNIX
$WAS_HOME/systemApps/isclite.ear/iehs.war/WEB-INF/lib/eclipse/plugins/org.eclipse.help.base_3.0.0 $WAS_HOME/systemApps/isclite.ear/iehs.war/WEB-INF/lib/eclipse/plugins/org.eclipse.help.base_3.0.1
2. Add the following line to both files.

org.eclipse.help/baseTOCS=/com.ibm.tivoli.tpm.doc/tpm_nav.xml
3. Restart WebSphere Application Server.
Notifications overview
Users often need an audible or visible indication that their task or workflow has started, finished, or has encountered an error. Such notifications allow the user to continue working on other tasks, rather than monitoring the progress of a software distribution or installation process. You can configure Tivoli Provisioning Manager to send e-mail notifications to users, updating them on the status of a specific task or workflow. The following mail server settings are required when you configure the notifications feature:
34
v v v v
SMTP Server Name: The address of the mail server that will be used to send notification e-mails. SMTP Server Port: The port number of the mail server. User ID logon SMTP Server: The server user ID that you use to authenticate to the mail server. User Password: The password that you use to authenticate to the mail server.
To configure mail server settings: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Notification tab. You also have to configure Maximo to send e-mail notifications: 1. Log on to the administrative user interface https://<hostname>:9443/maximo/ui 2. Click Go To > System Configuration > Platform Configuration > System Properties. Set up the following global properties: a. Ensure that the global property mail.smtp.host is pointing to your SMTP server. b. Click Instance Properties > New Row and create two entries for username and password like the following: v mail.smtp.user = <username> v mxe.hostname = <password> 3. Ensure that you apply the changes after saving. To apply the changes, select the check box next to the property and click Select Action > Live Refresh, and click OK. 4. Restart the Maximo server after the configuration change, because the instance system properties cannot be refreshed in live mode. 5. In the self-service user interface, set the e-mail addresses of the users to receive e-mail notifications in the Primary E-mail field for the users. Notifications are available for the following features: v Reports v Software management activities such as installing, distributing, and publishing v Discovery activities v Compliance v Tasks
Detailed task status notification

By default, the task status email notification provides a generic update about the task status. By creating a global property, you enable detailed task status notification, which includes information about subtasks. If you run a task on a group of computers, the task is broken down in subtasks. If only one subtask fails, the status notification reports a generic task failure, without indicating that only one particular subtask failed. To obtain detailed notification about subtask status, create a global property:
Procedure
1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Variables tab, and then click New Row. 3. In the Variable field, type NotificationAPIFailureDetails. In the Component field, click Entire System. Set the Value field to true. 4. Save your configuration.
Chapter 1. Overview
35
Results
This procedure enables detailed task status notification. The message specifies which subtask failed, indicates the targets and deployment request ID.
Example
v Before enabling detailed status notification:
COPAPM018E The execution of activity plan "Install Common Agent 1421" (ID: "1421") has failed.
v After enabling detailed status notification:

COPAPM045E The execution of activity plan "Install Common Agent 1428" (ID: "1428") has failed. The following subtasks and targets failed: Task: Install Common Agent 6769 Targets: target1.example.com (request ID: 10922) target2.emample.com (request ID: 10923) For more information about the error, view the task details in the Provisioning Task Tracking application.
System variable and locale attributes

Variables
In Tivoli Provisioning Manager, variables represent additional attributes that you might want to add to an object, and to extend that object's model to meet any needs that you have. For example, if you want to include a serial number with software or hardware, you can create a variable to represent it. In turn, provisioning workflows can use the serial number for a number of tasks that might include passing the variable to an external tool.
Locales
A locale is a language and country specific code. By default, Tivoli Provisioning Manager supports the following locales: en_US United States English fr_FR de_DE German it_IT Italian French
es_ES Spanish pt_BR Brazilian Portuguese zh_CN Simplified Chinese zh_TW Traditional Chinese ko_KR Korean ja_JP Japanese
ru_RU Russian
36
hu_HU Hungarian pl_PL Polish cs_CZ Czech
System variables
Some enterprise environments might require adjustments to system variables defined in Tivoli Provisioning Manager. Attention: Do not modify system variables unless you have been instructed to do so by IBM Tivoli Software Support or the product documentation. Improper configuration of system variables can cause unpredictable system behavior.
Configuring variables for tool integration

Tivoli Provisioning Manager allows you to create user-defined variables for the following enterprise objects: v v v v v Computers Switches Boot servers Blade servers Access Control Lists (ACLs)
v Load balancers v Power units v Routers v Software products, patches and stacks v Resource pools v Discovery These variables, typically tool.toolname variables, allow the user to run external tools to help manage enterprise devices.
Everyday tasks
This section contains some common everyday tasks
Finding the object ID of a data model object

If you need the device ID of a data model object for use in a provisioning workflow or for other purposes, you can look up the ID based on the name of the object.
Procedure
1. On the Start Center, locate the Data model object finder. 2. In the Object filter, type the name or part of the name of the data model object and press Enter.
Results
A list of data model objects that match the search criteria are displayed with the corresponding object IDs.
Chapter 1. Overview
37
Tip: When you are running a provisioning workflow in the Provisioning Workflows application, the Data model object finder is also available to search for object IDs.
Setting up email notification for automation packages

You can set up email notification to send emails from automation packages. Tivoli Provisioning Manager provides a Java method that you can use to specify email addresses, subject, and message to send email from automation packages. You use a Java helper in the event framework bundle to send emails from automation packages.
Procedure
1. Open the META-INF/MANIFEST.MF file for your automation package. 2. Add the following to the Require-Bundle section of the META-INF/MANIFEST.MF file:
eventframework;resolution:=optional
3. Use the TPMEmailHelper Java helper method for the email notification. The method is:
public void sendEmail(String[] addresses, String subject, String content);
For example:
array addresses = {"test1@ibm.com", "test2@ibm.com", "test3@ibm.com"} var subject = "My subject" var message = "My message" Java[com.ibm.tivoli.tpm.event.util.TPMEmailHelper#sendEmail(addresses, subject, message)]
For information about the required mail server settings for email notification, see Notifications overview on page 34.
Example
To view an example of email notification used in an automation packages, see Setting up email notification for virtual Fibre Channel adapter allocation on page 1084.
Provisioning groups
Having a provisioning group is a way of organizing resources and facilitating actions such as software distribution, running script and workflow tasks, and managing compliance. You can create groups based on categories that make sense in your organization. Using a group is a convenient way to do operations such as installing an operating system, distributing, installing, or uninstalling software, and running script and workflow tasks. Resources can belong to more than one group. You can select group members manually or using queries. Groups selected manually are static; members are added or removed manually. Groups defined by queries change dynamically to include members matching the conditions of the query upon which they are based. The following examples show what a group can be based on: v You can create a group for configuration compliance management that has a set of common compliance checks associated with it. You can then add all the resources or resource groups that need to comply with these compliance checks to this group. All of the resources in the added groups will then need to comply with the inherited compliance checks or else they will be noncompliant. v You can create groups based on member type. For example, you can place all resources or power units into a single group or create untyped groups that include multiple resource types. v You can assign queries to a group.
38
Creating groups
Defining groups and their members is a way of organizing managed resources to facilitate software distribution, compliance management, and other options. Administrators can create groups that meet the organizational needs of their responsibilities. You can individually add members to a group or you can add multiple members at the same time. You can also define group members using a query. Groups selected manually are static; devices can be added or removed as required. Groups assigned by queries change dynamically to include resources matching the condition of the query. Creating static groups: Static groups are created manually by selecting the resources that you want to group together, based on a user-defined criteria. You can create a static group in one of the following ways: 1. You can select specific resources. 2. You can select specific groups of resources. 3. You can import resources using a text file. To create a static group: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. . 2. Click New 3. Type the group name and description. 4. From the Member Type list, select the type of resource that you want to include in the group. Note: You cannot change the type after a group has been created. 5. From the Group Type list, select Static. 6. To assign group members, depending on your needs, perform one of the following choices: v Click Add Members to select one or more resources that you want to add to the group. v Click Add Groups to select one or more groups of resources that you want to add to the group. v Click Add From Text File to browse for the text file that you want to use to add the resources to the group. Note: When this option is used, the specified file is opened and read one line at a time with the assumption that each line contains one resource name. When the text file is saved, the encoding format must be either ANSI or UTF-8. 7. Click Save .
Creating dynamic groups: Before you begin Before creating a dynamic group, ensure you create and save the query that the dynamic group must be based on. Create the query for the dynamic group by navigating to the appropriate application to configure the filter, for example use the Provisioning Computers application to create a query to have all Red Hat Linux target computers in the dynamic group by performing the following steps: 1. Click Go To > Deployment > Provisioning Computers. 2. In the Operating System field, type the filter information. For example, type %Red%Hat%.
Chapter 1. Overview
39
3. Press Enter to verify that the filter retrieves all the Red Hat Linux target computers that are in the database. 4. Click Save Query to store the filter as a query. Type a Query Name and a description to identify the query. 5. Click OK. Groups assigned by queries change dynamically to include devices matching the results of a query. To create a dynamic group: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. . 2. Click New 3. Type the group name and description. 4. From the Member Type list, select the type of resource that you want to include in the group. Note: You cannot change the type after a group has been created. 5. From the Group Type list, select Dynamic. 6. From the Query list, select the query that you want to use to populate the group. 7. (Optional) From the Select Group list, depending on your needs, you can create empty static groups, which will be populated by the dynamic group data. You can use these static groups mainly for tracking purposes, because they capture a snapshot of a dynamic situation on specific dates or under specific circumstances. 8. Click Save Results Whenever a dynamic group is accessed, the membership is recalculated based upon the criteria defined in the query that was used to create it. .
Removing groups
You can remove groups that you no longer need. Removing a group does not delete the members of the group from the data model. To remove a group, perform the following steps:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. 2. Locate and open the group that you want to remove. 3. From the Select Action menu click Delete Provisioning Group. 4. Click Yes for confirmation.
Adding computers to groups

To facilitate patch management and compliance management, you can organize your resources into provisioning groups. Groups are created based on categories that make sense in your organization. Groups to be placed in other groups and members can be in multiple groups at the same time. To add a computer to a group, perform the following steps:
40
Procedure
Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. Locate and select the computer that you want to add to a provisioning group. Click Assign To Provisioning Group. Select the group that you want to add the computer to from the Groups list. You can add the computer to multiple groups. 5. Click OK. 1. 2. 3. 4. 6. Click Save .
Nesting groups
In addition to adding members to groups individually, you can also nest groups by identifying groups as members of other groups (parent groups). The nesting of groups enables the creation of hierarchical relationships that can be used to define inherited group membership. A nested group is defined as a child group that is referenced by the parent group. For example, you might want to add a group of a specific member type to a group that you want to contain all members in the data model. Nested groups inherit the same compliance rules, recommendations, and properties as the parent group, whereas parent groups are not affected by the properties of any subgroups. Note: Only compatible group types can be nested. A group can only be nested if it does not already share any group members with the parent. To nest groups, perform the following steps:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. 2. Find the group that you want to change and click its name. 3. Click Add Groups. Only groups that are compatible to the parent group type will be listed. 4. From the list select one or more groups that you want to add to the parent group and click OK. These groups will appear in the Members list. 5. Click Save .
Adding and removing members within a static group

You can add and remove members only from static groups. Members cannot be added to or removed from a dynamic group, because the membership of a dynamic group is defined by a query, not a list. You might need to modify the members of existing provisioning groups. For example, you might want to add a member that has been recently added to the database. If ownership for a member changes, or if the responsibilities of the owner changes, you might also need to change group associations. If a member belongs to more than one group, removing it from one group does not remove it from other groups that it belongs to. Adding members to a group: To add members to a group, perform the following steps: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. 2. Find the group that you want to change and click its name.
Chapter 1. Overview
41
3. Click Add Members. 4. From the list select one or more members that you want to add to the group and click OK. These members will appear in the Members list. 5. Click Save .
Viewing group members: Viewing a list of members in a group is useful for reviewing relationships between devices. You can use this list to view the type of each member of the group, the IP address, and operating system for members where applicable. To view the members of a group, perform the following steps: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. 2. Find the group that you want to view and click its name. 3. From the Members list you can click a member name to view its hardware and software details. Removing members from a group: You can only remove devices from static groups. The membership of a dynamic group will only change based on the results of queries that are run each time the group is viewed, changed, or used. To remove a member from a group, perform the following steps: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. 2. 3. 4. 5. Find the group that you want to change and click its name. From the Members list identify the member you want to remove. Click Mark Row for Delete . These members are removed from the Members list. Click OK for confirmation. .
6. Click Save
Discovering attributes of selected groups

If you want to quickly discover the attributes of specific groups, you can use the Provisioning Group page.
Before you begin

The target computers must already be defined in Tivoli Provisioning Manager. The selected provisioning group must be of type Computer or untyped, and must contain at least one target computer. To discover the attributes of selected groups from the Provisioning Group application, perform the following steps:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. 2. In the Provisioning Groups page, select one or more groups. The system checks that the selected provisioning groups are computer groups. In case untyped groups are selected, the system verifies that at least one computer is contained in the group. 3. Click Run Discovery from the Select Action menu. The service access point of each computer is checked by the system.
42
4. If one or more computers in the groups do not have a service access point (SAP) defined, the Add credentials dialog is displayed by the Web interface. Enter the missing credentials. 5. (Optional) If you want to exclude from the discovery the computers with the missing credentials, select the Ignore computers with no SAP ? check box. 6. Click OK. 7. On the Run Discovery dialog, you can specify the provisioning task name, the scheduling and the event notification options for the provisioning task. 8. Click Submit to perform the discovery.
Results
If some selected computers do not have a service access point (SAP) defined, the missing SAP are created after running the discovery. Also, the hardware and software information is updated on the selected computers after performing the network discovery.
Example: Combining two different queries in the same group

It can be very useful to combine the conditions of two dynamic groups with the same object type, when you want to have a single dynamic group that works with two different queries.
To combine the conditions of two dynamic groups having the same object type, perform the following steps:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. . 2. Click New 3. Type the group name and description for the first dynamic group you create. 4. From the Member Type list, select the type of resource that you want to include in the group. 5. From the Group Type list, select Dynamic. 6. From the Query list, select the query that you want to use to populate the first group. 7. Click Save .
8. Click New . 9. Type the group name and description for the second dynamic group you create. 10. From the Member Type list, select the same type of resource that you have specified for the first dynamic group you have created. 11. From the Group Type list, select Dynamic. 12. From the Query list, select the query that you want to use to populate the second group. 13. Click Save .
. 14. Click New 15. Type the group name and description for the static group you create. 16. From the Member Type list, select the same type of resource that you have specified for the dynamic groups you have created. 17. From the Group Type list, select Static. 18. Click Add Groups. Only groups that are compatible to the parent group type will be listed. 19. From the list select the two dynamic groups that you want to add to the parent group and click OK. These groups will appear in the Members list.
Chapter 1. Overview
43
20. Click Save
Example: Protecting groups created for security purpose

It can be very useful to protect provisioning groups using the appropriate security constraints, when these provisioning groups represent general groups for managing security. Issues might arise when a regular user has update permission on the entire Provisioning Group application. To avoid this issue, all the provisioning groups, which have been created for managing security, can be grouped together and security constraints can be applied to them. In this way, regular users will have read-only access to these groups. Regular users must not have access to update provisioning groups used for managing security, while they can have access to the provisioning groups created for a general purpose.
Grouping together the provisioning groups for security purposes: Assuming that a regular user has access to the provisioning groups ServerWithWin and ServerWithLinux for security reasons because he needs to specify the accesses to a set of servers with Windows and Linux platforms. The best approach is to create another group which contains all the provisioning groups for security purposes. To group together the provisioning groups for security purposes, perform the following steps: Procedure 1. Click Go To > Deployment > Provisioning Groups. 2. 3. 4. 5. Click New . Create an untyped static group naming it for example ParentGroupsForSec. Click Add Groups. Add to ParentGroupsForSec the two groups ServerWithWin and ServerWithLinux. .
6. Click Save Results
The two groups have been added to the parent group. Defining the provisioning group security constraints: For securing the access to the groups for security purposes, it is now essential to correctly define a condition to be used for data restriction. In this scenario, it is recommended to grant only user read access to the group ParentGroupsForSec and its member groups ServerWithWin and ServerWithLinux. To define this condition, perform the following steps: Procedure 1. Click Go To > Administration > Conditional Expression Manager. 2. Click New Row. 3. Specify a name for the new condition, for example CondForSecP. 4. From the Type list select EXPRESSION. 5. In the Expression field, enter the following:
(EXISTS (select 1 from group_membership gm, tpgroup g where g.name = ParentGroupsForSec AND g.id=gm.group_id and is_nested_group=Y and gm.dcm_object_id=:id)) OR (:name = ParentGroupsForSec )
6. Enable Always Evaluate?.
44
7. Click Save Results
The new condition has been defined and saved. Creating a data restriction using the new condition: After creating the condition, it is now essential to create a read-only data restriction to the security group. In this way, all users in that security group will have read-only access to the provisioning group ParentGroupsForSec and its member groups (ServerWithWin and ServerWithLinux in this scenario) as enforced by the condition. To create a read-only data restriction, perform the following steps: Procedure 1. Click Go To > Security > Security Groups. 2. Locate and click the security group to which belong the users you want to grant read-only access. 3. 4. 5. 6. Click the Data Restrictions tab. Click New Row. From the Object list select TPGROUP. From the Type list select READONLY.
7. From the Condition list select Select Value. 8. Select the name of the new condition you have created, in this scenario CondForSecP. 9. Click Save Results The read-only data restriction has been created. What to do next After the condition is created and the read-only data restriction is set, you can try to log on as a regular user and access the TPGROUP application. You will see all the provisioning groups but for the ParentGroupsForSec, ServerWithWin, and ServerWithLinux groups, you will only have read-only access. .
Provisioning computers
The data model represents the physical and logical assets under Tivoli Provisioning Manager management, such as switches, load balancers, software, and more. The data model keeps track of IT assets and configuration changes associated with them. It also tracks their allocation to customer applications. This can include not only servers and networking components, but also other computers that can perform substantial computations that are now categorized in Tivoli Provisioning Manager under a broad term called computers. Computers can be managed in application tiers.
Chapter 1. Overview
45
Computer types
The following table shows the types of systems managed by Tivoli Provisioning Manager
Table 9. System types managed by Tivoli Provisioning Manager System type Computers
Systems that are required to run the operating systems of The type of systems that fall into this category are: the application, and the application itself. These systems v Blade Servers : These are systems that are used must belong to or be assigned to resource pools. primarily to reduce space restrictions and redundancy. v Virtual Servers and Host platform Servers: These systems typically share their resources with other systems - an effective method to cut down costs. Systems that are required to either boot up or provide network access to other computers. The type of systems that fall into this category are: v Boot Servers: These systems are defined when you need to provision workstations or other systems without any installed software. Each boot server is associated with one or more image stacks (a software stack that is installed as a single image). v Terminal Servers: These systems provide network access to other workstations or systems with broken network connections or to other systems that have no built-in network support. Using Tivoli Provisioning Manager you cannot only manage the system types, but also other computers that can perform substantial computations, including numerous arithmetic operations and logic operations. In the data model they are defined as Traditional computers. Traditional computers can be used by application tiers or resource pools. The type of computers that fall into this category are: v Notebook computers v Desktop computers or even pervasive devices. v Systems that provide facilities to other stations. Some of the examples are a Web server, Application server, file server, a printer server, or a mail server.
Computer details
Quickly and at a glance, you can see a high-level summary and status of the computer. You can clarify what actions you need to take and perform on the computer such as edit or add an agent, work with groups, and capture images. You can also run an inventory scan on the computer from this page to get the latest discovery results. Tivoli Provisioning Manager can help you quickly review your computer's details in one simple view. This snapshot can help you determine at a quick glance, which distribution framework (deployment engine or scalable distribution infrastructure) is on this computer, and even allowing you to evaluate if any compliance configuration checks need to be setup or if already setup, have known issues. This is an efficient way to view and manage installed software, patches, and operating systems for a computer. The General tab: Use this tab to see the configuration, last known status, and membership of the computer. Specifically, this page is divided into the following areas: Configuation details This section lists the computer management IP, the operating system, the locale, any available description, and the disk capacity. The initial discovery feature will populate the management IP and operating system. All other information (except the location) is discovered by discovery scans. The location can be entered using the computer properties menu. Last Known Status details This section highlights the information about the deployment framework that the computer is using and which agent is installed.
46
The Framework field provides the infrastructure type that is used to manage the computer. Framework types can be either the deployment engine or the scalable distribution infrastructure.
v The Agent field provides the agent type and version information if available. The Tivoli Common Agentis used by the scalable distribution infrastructure v The Compliance field provides a summary of the three levels of compliance checks: security, software, and patch. The status will indicate the number of issues within each different compliance level and a link to the Recommendations tab to remediate. If no compliance checks have been created, the field will indicate that a compliance check configuration is required. v The Authority field provides a list of the access groups who are authorized on this computer. Membership details This section highlights the groups and applications that are associated with the computer. If there are no resource pools or application tiers associated with the computer the fields will display Not associated. If there are associations, the type of association will be listed with a link to the object. If the computer is a virtual server, this area will also show the host platform server. If this computer is a host platform server, this area will show a link to list all the virtual servers. Recent Discovery Scan This area will display when the most recent changes have been made using discovery to the data model. Information will include the discovery method, scan type, and time of discovery. You can access additional information by clicking on another specific tab for the computer or direct links in the computer status view: v The Hardware tab: Use this tab to see the network resources, hardware resources, and storage resources that are identified with the computer. v The Software tab: You can view the software installed on the computer, such as software resources, software installations, instances, configurations. v The Compliance tab: Use this tab to review the software compliance status of a computer and its compliance deviations from the required state. v The Variables tab: Use this tab to view and configure the variables for the computer. v The Workflows tab: Workflows must be assigned to hardware, infrastructure, and software assets so that Tivoli Provisioning Manager can run the appropriate commands for provisioning or deprovisioning them. You can assign workflows to the selected computer from here. v The Discovery tab: Before a device can be monitored for configuration changes, it must first be associated with an existing discovery technology. The discovery technology must then be configured further to associate the correct logical management operation and workflows. You can associate a discovery technology from this tab. v The Credentials tab: The credentials for the identified computer can be viewed on this tab. This tab contains SAPs, if the credentials are associated with SAPs
Computer management and monitoring

In order to properly manage your computer, you need to quickly view its configuration and health status. You need to review the following items: 1. Is there an agent installed? If so, verify its state. 2. Is the computer communicating? You can find this out if the credentials are set up. Tip: You can run the TCA-PingAgent workflow to see if the service access point is active. 3. Are there any compliance issues that need to be resolved or does compliance checking need to be configured? 4. Are there tasks running against this computer? What do the logs indicate? 5. If the computer is acting as:
Chapter 1. Overview
47
v Firewall: Are the access rules set up? v Router: How many routers are there? v Virtual server: Does it need to be powered on or off? In addition to the quick review of the computer's health, you might need to perform additional actions against it, for example: 1. 2. 3. 4. 5. Installing agents (if not already installed) Installing images Configuring compliance Adding hardware and software resources Managing computers remotely
Adding or deleting a computer

If you want to quickly add a computer, you can use the Add Computer page. Using the different tabs, you can specify the IP address, credentials, and security group. If you are adding a system that you want to assign to a resource pool or dedicate to an application tier, you can also specify the resource pool or application tier. This task outlines how to add a computer to the data model.
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. In the Provisioning Computers page, click Add Computer from the Select Action menu. 3. Enter the information needed to add the computer. 4. Click Save .
Results
Tivoli Provisioning Manager adds the computer to the data model with the specified name and credentials, and can optionally install the Tivoli Common Agent. Depending on how you plan to use the system, you might need to perform additional configuration tasks. For example, you might want to assign specific workflows to the computer, set up monitoring, or install software. Creating a virtual server: This task outlines how to create a virtual server from an existing provisioning computer and add it to the data model. Procedure v Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. v For the rest of the procedure, click here. The procedure is the same as when accessing the function from the Virtualization Management page. Deleting computers: You can delete all types of computers, if they are no longer required. Note: Boot servers, terminal servers and blade servers are not displayed on the Provisioning Computers page. To delete boot servers and terminal servers, go the respective server type and then delete the server.
48
Deleting a single computer: To delete a computer from the Provisioning Computers application, follow these steps: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. To list all available computers in the data model, click Search . 3. Identify the computer that you want to delete, and then click the Delete Computer button on the same row. Note: A workflow task named DeleteComputersFromDCM is immediately invoked without any scheduling options. After the task is submitted, a popup window is displayed asking you to either leave the Provisioning Computers page and navigate to the Provisioning Task Tracking page, to monitor the task execution status while the computer is deleted, or to remain on the Provisioning Computers page. 4. When prompted, click Yes. Results The computer is now removed from the Tivoli Provisioning Manager database, and if the computer is a virtual server it is also destroyed. Deleting multiple computers: You can delete multiple computers at the same time. Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Search for the computers that you want to delete. Expand Advanced Search and select More Search Fields. Find the computers by filtering the search. For example, you can find computers and virtual servers by provisioning group, host platform, operating system, and so on. 3. To enable selecting multiple computers, click the Select Records checkbox at the bottom of the list of computers. 4. Select the computers that you want to delete from the data model. 5. Click Select Action > Delete Computers. The computers that you selected for deletion are listed. 6. Click one of the following: v Click Delete Record to delete the computers from the provisioning data model. Note: Only the MAXADMIN and TPDEVELOPER users can see the Delete Record option in this window. Delete Record saves the changes to the provisioning server but does not update the VMware VirtualCenter. This option is typically used for testing purposes. v Click OK to delete the computers. If the computers are virtual computers, they are also destroyed. 7. Schedule the computers to be deleted, or click OK to delete them immediately. Results When the provisioning task completes, the selected computers are deleted from the data model.
Managing computers remotely

You can perform many different functions such as rebooting hardware, software, or generic devices, initializing the computer, or powering it on or off. v Turning computers on and off on page 50
Chapter 1. Overview
49
v Rebooting computers v Initializing computers v Deleting computers on page 51 Turning computers on and off: You can turn computers on and off easily using the Web interface. Note: Device.PowerOn and Device.PowerOff are used for virtual machines and blade servers, for which a number of automation packages are available. A generic implementation of Device.PowerOn and Device.PowerOff for physical stand-alone servers is not available. These logical device operations must not be invoked for real systems. To turn on or off the computer, perform the following steps: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Click on the computer that you want to power on or off. 3. From the Select Action menu, click Manage > Power On or Power Off. Results The provisioning workflow that implements the Device.PowerOn or Device.PowerOff logical management operation runs. If the provisioning workflow is run successfully, the selected device is turned on or off. Rebooting computers: A device reboot is typically required when the device has stopped responding and you need to power it off and on again. The Generic Restart is a combination of software and hardware reboot mechanisms, and is performed by initiating the provisioning workflow that implements the Device.Reboot logical device operation where Device is the name of the device on which you want to do a generic reboot. The following steps are taken during a generic reboot: 1. The system verifies whether a reboot_preference data center model property is defined for the device you want to reboot. This data center model property specifies which reboot method to use for that specific device. If none found, an asynchronous software reboot is initiated first. 2. If the asynchronous software reboot fails, a synchronous software reboot is attempted. 3. If the synchronous software reboot is unsuccessful, a hardware reboot is performed. To perform a device generic restart, perform the following steps: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Identify and click the device that requires a reboot. 3. From the Select Action menu, click Manage > Generic Restart . 4. Click OK. Initializing computers: Prerequisites: The computers must belong to a resource pool to be initialized.
50
Initializing devices resets the devices to the starting value. This value is the value before the device was configured. To initialize a computer, perform the following steps: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Identify and click the computer that is assigned to a resource pool that you want to initialize. 3. From the Select Action menu, click Manage > Initialize. Results The SparePool.InitializeServer logical management operation is run. Deleting computers: To delete a computer, perform the following steps: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Identify and click the computer that you want to delete. 3. From the Select Action menu, click Delete Computers. 4. Click OK.
Discovering attributes of selected computers

If you want to quickly discover the attributes of a specific computer, you can use the Provisioning Computer page.
Before you begin

The target computers must already be defined in Tivoli Provisioning Manager. To discover the attributes of a selected computer from the Provisioning Computer application, perform the following steps:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. In the Provisioning Computers page, select one or more computers. 3. Click Run Discovery from the Select Action menu. The service access point of each selected computer is checked by the system. 4. If one or more computers in the list do not have a service access point (SAP) defined, the Add credentials dialog is displayed by the Web interface. Enter the missing credentials. 5. (Optional) If you want to exclude from the discovery the computers with the missing credentials, select the Ignore computers with no SAP ? check box. 6. Click OK. 7. On the Run Discovery dialog, you can specify the provisioning task name, the scheduling and the event notification options for the provisioning task. 8. Click Submit to perform the discovery.
Chapter 1. Overview
51
Results
If some selected computers do not have a service access point (SAP) defined, the missing SAP are created after running the discovery. Also, the hardware and software information is updated on the selected computers after performing the network discovery.
Quick server provisioning

The following procedure allows you to setup a new server (physical or virtual) using a simplified process from a single Tivoli Provisioning Manager web interface. Quick server provisioning allows you to use a simplified process to quickly set up a server (physical or virtual) with the required data such as server name, IP addresses, MAC addresses. You may choose an operating system and software stacks to install on the server. You may also choose one or more provisioning groups (physical server only) to which the server will belong. Note: For quick server provisioning to work, the server must already be part of the data model. Provisioning a physical server To quickly provision a physical server: 1. Click Go To > Deployment > Server Provisioning. 2. Select the Provision Physical Server radio button. 3. Enter the Computer Name for the server. 4. Enter the MAC Address for the server. 5. Select an Operating System Stack to be installed on the server by choosing Select Value from the detail menu and clicking on the appropriate software stack. You can also select Go To Software Stacks from the detail menu to review the software stacks available, or create a new software stack. 6. (Optional) Click Select Software to choose the software to be installed on the server. a. In the Select Software dialog, place a checkmark next to the software to install on the server. b. Click OK. 7. (Optional) Click Assign to Static Group to assign this server to a provisioning group. a. In the Assign to Static Group dialog, place a checkmark next to the provisioning group(s) to which the server will belong. b. Click OK. You can click Add New Group to create a provisioning group. 8. Click Submit. The physical server object is defined in the data model and an Activity Plan Instance is created to perform the activities you selected. The operating system is installed using the Tivoli Provisioning Manager for OS Deployment. If both operating system and software are selected, the operating system is installed first, and the software is installed only if the operating system is installed successfully. Provisioning a virtual server To quickly provision a virtual server: 1. Click Go To > Deployment > Server Provisioning. 2. Select the Provision Virtual Server radio button. 3. 4. 5. 6. to select the Virtualization Type (virtualization technology) to be used by the server. Click to select the Host Platform that houses the server. Click Enter the name of the virtual server in the Virtual Server field. Select a Virtual Server Template used to create the virtual server by choosing Select Value from the detail menu and clicking on the appropriate virtual server template.
52
v You can also select Go To Virtual Server Templates from the detail menu to review the virtual server templates available, or create a virtual server template. 7. (Optional) Select the Software Stack to be installed on the virtual server by choosing Select Value detail menu and clicking on the appropriate software stack. This field is used for from the operating system-related software only if the virtual server template requires an operating system. If the virtual server template is packaged with an operating system, that system is automatically populated in this field. You can also select Go To Software Stacks from the detail menu to review the software stacks available, or create a software stack. 8. In the Resource Requirements section, review or edit resource types included in the virtual server template as required. Click New Resource Requirement to add a new resource type to the virtual server template. 9. In the Variables section, review or edit variables included in the virtual server template as required. Click New Row to add a new variable to the virtual server template. 10. (Optional) Click Select Software to choose the software to be installed on the virtual server. a. In the Select Software dialog, place a checkmark next to the software stack to install on the virtual server. b. Click OK. 11. Click Submit. The virtual server object is defined in the data model and an Activity Plan Instance is created to perform the activities you selected. The virtual server is created based on virtual server template specifications. If both operating system and software stacks were selected, the operating system is installed first, and the software stack(s) is installed only if the operating system is installed successfully. Removing empty virtual servers: Configure the host platform server so that empty virtual servers are removed if they fail to be created without the intended software stack deployment. When you create a virtual server and deploy a software stack on the virtual server in the same task, if the software stack deployment fails, the empty virtual server will still be created. You can configure the host platform server so that the empty virtual server will be deleted automatically. Otherwise, you have to manually find and delete the virtual server from the Virtualization Management application. Follow these steps to configure the host platform server: Procedure 1. 2. 3. 4. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. Select the host platform server from the list. On the Variables tab, click New Row. In the following fields, specify the following information: v Variable: Type Roll_Back. v Component: Select Entire system. v Value: Type true. 5. Click Save Results Any virtual servers that are created on this host platform server without the intended software stack will be automatically deleted.
Chapter 1. Overview
53
Adding computers to resource pools: A resource pool is a container of available computers and servers that support one or more application tiers. The resource pool is also referred to as a spare pool. 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. The decision on how to organize resource pools is an economical and response-time one. You can allocate all the systems in one resource pool, or have two pools, one with systems running Windows, one with systems running Linux, and so on. The more specialized the pool, the better the response time for allocation (the resource is already in an advanced state of readiness), however this arrangement prevents timely, optimal reallocation between pools. With one generic pool only, the allocation time increases, as an operating system must be installed first, and so on. However, the allocation can be optimal among all running environments requiring dynamic allocation of resources. To configure resource pools, perform the following steps: Procedure 1. Click Go To > Administration > Provisioning > Resource Pools. The Resource Pools page lists all the resource pools that are available in the system. . 2. Click New 3. Complete the fields as follows: a. In the Resource Pool field, type a name for the new resource pool. b. Select the computer template to which you want to associate the resource pool to from the Computer Template list. A computer template defines the required state for managed systems in a resource pool. c. If this resource pool is associated with a specific locale, select the locale from the Locale list. . 4. Click Save 5. Optional: To change any parameters for external tools that manage this resource pool, click the Variables tab of the resource pool that you have created and make the required changes. What to do next The resource pool is added. You can perform the following actions with an existing resource pool: v To remove a resource pool, click Mark Row for Delete. If there are computers contained in the resource pool, a list of other resource pools is displayed. Select a new parent resource pool for the computers. If there are no computers in the resource pool, a confirmation window is displayed. Click Yes to confirm the deletion. Adding computers to resource pools: Computers in the data model can be allocated to any application tier associated with the resource pool that the computer belongs to. Allocation of the computer to the application tier is based on demand for the available resources in the pool. To add a computer to a resource pool or an application tier:
54
Procedure 1. Click Go To > Administration > Provisioning > Resource Pools. All the resource pools that are available in the system are listed. 2. Identify and click the resource pool to which you want to add a computer. 3. Click Add Computers from the Select Action menu. 4. From the list, select one or more computers that you want to associate to the resource pool and click OK. Results The computers are now added to the resource pool.
Provisioning computer page displayed faster

You can create a new global variable, which allows you to display the computer general page much quicker. To faster display the general page of a selected computer from the Provisioning Computers application, perform the following steps:
Procedure
1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click Variables. 3. 4. 5. 6. Click Add Variable from the Edit menu. Specify compliance-summary-ui in the Key field. Specify Compliance Configuration in the Component field. Specify true in the Value field.
Results
After creating this variable and setting the variable to true, on the Computer tab of the Provisioning Computers application, in the Last Known Status section, the Compliance field will have one the following values, depending on the results of the compliance checks: v Yes v No v Configuration Required.
Frequently asked questions (FAQs)

Find answers to some common questions about Tivoli Provisioning Manager. You can find out more information about the web interface in the Product Reference guide. How can I refresh the contents of a page or table? Automatic refresh is not available in Tivoli Provisioning Manager. To refresh the Start Center information, click Update Start Center. Other pages that show status (such as the Provisioning Task Tracking page) can be refreshed by clicking Select Action > Refresh Page. In a table, you can click to refresh it.
How can I return to the previous page? You cannot use the Back button in a browser to return to a previous page. Doing so might cause Tivoli Provisioning Manager to stop functioning or exit suddenly.
Chapter 1. Overview
55
To reach a prior panel, return to the Go To menu and use it to access your application again. You might also be able to follow the breadcrumb navigation available for some applications. How do I populate the List tab? To find records, use the filter fields and then click Enter or then click . . If you cannot see the filter fields,
For more search options, click the Advanced Search button and select the search option you want to work with. To enter a record, click .
To see details about a record, you can click it (if it is underlined), or expand it if it has an arrow next to it. The db-truncation value controls the list display value for the web interface. If required, you can change it: Click Go To > Administration > Provisioning > Provisioning Global Settings.. Click Variables, then select the db-truncation option and change the value. Note: Some pages can be very slow if you raise this value too high. How do I see a list of users or create a user? Click Go To > Security > Users. To see a list of all users defined for Tivoli Provisioning Manager, leave the filter fields blank and click Enter. To create a user, click . You can also create a user using LDAP: Lesson 1: Creating a user and a security group on page 80 To review a user profile, click the underlined user name. How do I create a portlet in the Start Center? Return to the Start Center by clicking Start Center. Click Change Content/Layout, then decide if you want your new portlet in the left or right column and click Select Content. Change the Display Name to the name you want to call your portlet (for example, New Portlet) and click Finished. The new portlet is now displayed in the Start Center. To add applications to it, click .
How do I access the Provisioning Task Tracking page? There is a direct link to this page in the Favorite Applications section of the Start Center. How do I access the Discovery Wizards or Discovery Configurations page? There is a direct link to these pages in the Favorite Applications section of the Start Center. You will not see these links if you do not have the access right to perform these tasks. What do I do if I cannot see an application or tab? You might need to modify the signature options, which specify privileges for using applications, menu options, and toolbar items. Click System Configuration > Platform Configuration > Application Designer, then click the application you want to work with, and click Select Action > Add/Modify Signature Options..
Installation directories and other paths

The following variables are used to represent installation and other directory paths. In some cases, the variable name matches the name of an environment variable that is set in the operating system. For example, TIO_HOME represents the environment variable: v v
Windows UNIX
%TIO_HOME%
Linux
TIO_HOME
56
Table 10. Path variables Path variable AM_HOME Component The agent manager Default directory v
Windows C:\Program Files\IBM\AgentManager UNIX Linux
v APDE_HOME DB2_HOME Automation Package Developer Environment DB2
/opt/IBM/
AgentManager APDE_HOME/eclipse
SystemDrive:\Program Files\IBM\SQLLIB
AIX Linux Solaris
Windows
/opt/ibm/db2/V9.5 SystemDrive is the disk drive that contains the hardware-specific files used to start Windows. Typically, the system drive is C. DCD_HOME Tivoli Provisioning Manager for dynamic content delivery v
Windows Windows
%Program Files%\IBM\tivoli\
Linux
CDS v
UNIX Windows
/opt/IBM/tivoli/CDS
DMS_HOME
The device manager service installation directory
C:\Program Files\ibm\DeviceManager
UNIX Linux
v ECLIPSE_HOME HTTP_HOME Eclipse IBM HTTP Server
/opt/IBM/
DeviceManager Defined by the user. v

Windows C:\Program Files\IBM\HTTPServer AIX Solaris Windows UNIX
v v ITM_HOME Tivoli Monitoring agent v v JAVA_HOME Java Runtime Environment
/usr/IBM/HTTPServer
Linux
/opt/IBM/HTTPServer
C:\ibm\tivoli\ITM
Linux
/opt/IBM/tivoli/ITM
v For Automation Package Developer Environment, APDE_HOME\java\jre. For example:

Windows UNIX
C:\APDE\java\jre
Linux
/opt/APDE/java/jre v For IBM Tivoli Provisioning Manager, WAS_HOME/java MAXIMO_HOME The base services v v
Windows UNIX
C:\IBM\SMP
Linux
/opt/IBM/SMP
Chapter 1. Overview
57
Table 10. Path variables (continued) Path variable

AIX Windows Linux
Component Middleware installer directory
Default directory v v v
Windows AIX Linux
C:\ibm\tivoli\mwi\workspace /ibm/tivoli/mwi/workspace /root/ibm/tivoli/mwi/
MWI_workspace
workspace
UNIX
ORACLE_HOME Oracle Database
$ORACLE_BASE/product/version/db_1, where $ORACLE_BASE is the directory in which all Oracle Database software is installed: v /u01/app/oracle/product/10.2.0/db_1 (for Oracle 10g) v /u01/app/oracle/product/11.1.0/db_1 (for Oracle 11g)
OSD_DATADIR
Tivoli Provisioning Manager for OS Deployment data directory
Default data directory for Tivoli Provisioning Manager for OS Deployment parent servers: v v
Windows UNIX
%SYSTEMDRIVE%\tpmfosd files
Linux
/opt/tpmfosd_files
Default data directory for Tivoli Provisioning Manager for OS Deployment child servers: v v OSD_HOME Tivoli Provisioning Manager for OS Deployment installation directory
Windows UNIX
%SYSTEMDRIVE%\TPMfOSd Files
Linux
/opt/tpmfosd/
tpmfos/files Parent servers, installed by the Tivoli Provisioning Manager installer: v

Windows
%COMMONPROGRAMFILES%\IBM
Linux
Tivoli v
UNIX
/opt/IBM/tpmfos
Child servers, installed by the Tivoli Provisioning Manager for OS Deployment workflows: v
Windows
%COMMONPROGRAMFILES%\IBM
Linux
Tivoli v TCA_HOME common agent v v v TDS_HOME Tivoli Directory Server

UNIX Windows AIX Linux
/opt/tpmfosd/tpmfos
C:\Program Files\tivoli\ep /usr/tivoli/ep

Solaris HP UX
/opt/tivoli/ep v
Windows C:\Program Files\IBM\LDAP\V6.2 UNIX Linux
v TIO_HOME Tivoli Provisioning Manager v
/opt/IBM/ldap/V6.2
Windows C:\Program Files\IBM\tivoli\tpm UNIX Linux
/opt/IBM/tivoli/tpm
58
Table 10. Path variables (continued) Path variable TIO_LOGS Component Tivoli Provisioning Manager runtime logs Default directory v
Windows C:\Program Files\IBM\tivoli\common\COP\logs UNIX Linux
v Windows directory for temporary files
/usr/ibm/tivoli/
common/COP/logs
Windows
%TEMP%
When logged on as Administrator, C:\Documents and Settings\Administrator\ Local Settings\Temp v

Windows C:\Program Files\IBM\WebSphere\AppServer AIX Linux
WAS_HOME
WebSphere Application Server
v v
/usr/IBM/WebSphere/AppServer
Solaris
/opt/IBM/WebSphere/
AppServer
Troubleshooting
This section provides some quick tips for troubleshooting. Refer to this section if you have problems logging on, or if you are encountering a general problem that is not related to a specific product feature. For quick links to troubleshooting resources, see the Troubleshooting tab in Getting started basics on page 10.
Troubleshooting aids
A troubleshooting aid guides you through the process of diagnosing problems for a particular area of the product. A troubleshooting checklist identifies common problems and recommendations on how to resolve them. The following troubleshooting aids and checklists are available: v Troubleshooting security on page 119 v Troubleshooting discovery on page 239 v Troubleshooting operating systems management v Troubleshooting virtual images management v Troubleshooting image library management on page 522 v Troubleshooting software distribution on page 751 v Troubleshooting compliance on page 858 v Troubleshooting SDI Windows patch management on page 989 v v v v v v v Patch management troubleshooting checklist on page 992 Troubleshooting virtualization management on page 1095 Troubleshooting task management on page 1180 Troubleshooting and Reporting problems on page 1205 Troubleshooting Automation Package Developer Environment Automation Package Developer Environment troubleshooting checklist Troubleshooting provisioning workflows
v Activity Plan Editor troubleshooting

Chapter 1. Overview
59
v Software Package Editor troubleshooting
Logging on or logging off problems

This section describes how to recover from Tivoli Provisioning Manager logon problems.
Unable to log on to the web interface

If the LDAP server is shut down, you cannot access the web interface.
Symptoms
You are getting errors when trying to access the web interface.
Causes
The Lightweight Directory Access Protocol (LDAP) server might be shut down.
Resolving the problem

Solution 1 Check the status of the LDAP server. On the LDAP server, from the LDAP_install_dir/current_version/ bin directory, where current_version is the LDAP version, run the following command:
ibmdirctl -D user_name -w password status
Note: The default LDAP installation directory is /opt/IBM/ldap/current_version/bin If the LDAP server is running, a confirmation message is displayed. If the LDAP server is not running, start the LDAP server by running the following command:
ibmdirctl -D user_name -w password start
Solution 2 Run the Tivoli Directory Server Web Administration tool to check the status of the LDAP server. 1. Make sure that the Tivoli Directory Server Web Administration tool is installed on the WAS server. For information on how to install it, go to http://www.ibm.com/developerworks/tivoli/library/twebadmin/index.html. 2. In a Web browser, go to http://host_name:9080/IDSWebApp/IDSjsp/Login.jsp 3. Log in with the appropriate user name and password. The Tivoli Directory Server Web Administration tool starts. 4. If you cannot log in, you need to start the LDAP server. On the LDAP server, from the LDAP_Install_dir/appsrv/bin directory, run:
startServer [.sh|.bat] server1
5. In the Tivoli Directory Server Web Administration tool, in the navigation bar, click Server administration. The status of the LDAP server is displayed. 6. If the server is not running, click Start or Restart to start the LDAP server.
Problems logging on to computer with Turkish locale

You cannot log in if English language characters are not supported.
Symptoms
After successfully installing Tivoli Provisioning Manager on a computer running a Turkish locale, you are unable to log in.
60
Causes
Tivoli Provisioning Manager can be installed on a computer running any locale but the user will see English if the locale is not one of the supported languages. Turkish is not one of the supported languages. When the user logs in, the default Turkish locale does not recognize the English language.

To fix the problem, configure the WebSphere Application Server Java Virtual Machine (JVM) argument to recognize and handle the English language characters. To configure the WebSphere Application Server Java Virtual Machine (JVM) argument: 1. Log in to the WebSphere Application Server Administrative Console. 2. Navigate to Servers > Application servers > server1 > Java and Process Management > Process Definition > Java Virtual Machine. 3. Add the following at the end of the Generic JVM arguments field:
-Duser.language=en
4. Click Apply > Save to save your configuration changes. 5. Restart WebSphere Application Server to refresh your configuration changes.
User cannot change password

When changing your password, you must follow all password policy parameters, such as length and number of alphabetic characters.
Symptoms
You cannot change your password.
Causes
The password policy parameters are incorrect (such as minimum length, minimum number of alphabetic characters, and other parameters), so the LDAP server cannot validate the password.

Run the Tivoli Directory Server Web Administration tool to check the password policy. Tip: Use this method for a two-node directory server installation. 1. From LDAP_Install\appsrv\bin, run: v v
UNIX Windows Linux
: startServer.sh
: startServer.bat
and use the following syntax:

startServer server1
2. In a Web browser, go to http://hostname:9080/IDSWebApp/IDSjsp/Login.jsp 3. Log in with the appropriate user name and password. The Tivoli Directory Server Web Administration tool starts. 4. In the navigation bar click Server administration and then click Manage security properties. 5. In the main window: a. Click Password policy to check whether the password syntax is enabled or not. b. Click Password validation to check the password syntax.
Chapter 1. Overview
61
6. Change your password again based on the specified password syntax.
User is not logged off when session expires

Any user is able to work from an expired session in Tivoli Provisioning Manager without logging on until the configured LTPA timeout occurs.
Symptoms
If a session in Tivoli Provisioning Manager is left idle until it expires, any user is then able to access the session without validating their credentials. Some pages might have exception messages because the user is not validated.
Causes
This is a security issue. If users log on to Tivoli Provisioning Manager and leave the session idle for longer than the HTTP Session timeout value configured in WebSphere Application Server, user information is not invalidated and user credentials remain available until the configured LTPA token timeout occurs.

To fix this behavior so that the user is automatically logged out after the HTTP session timeout period, you must install fix PK25740 and then configure WebSphere Application Server. The user who is installing the fix must: v Be logged on as a user with Administrative rights. v Have version 6.0.2.2 or later of the update installer. Check the version number in the C:\Program Files\IBM\WebSphere\AppServer\updateinstaller\version.txt file. The update installer can be downloaded from the following link: http://www-1.ibm.com/support/ docview.wss?rs=180&uid=swg21205991. To install the fix and configure WebSphere Application Server: 1. Copy the file pk25740.pak to the WAS_HOME\updateinstaller\maintenance directory. 2. Stop WebSphere Application Server. 3. Change to the WAS_HOME\bin directory and run the following command: v
Windows
: setupCmdLine.bat v
UNIX
: . ./setupCmdLine.sh. Notice the space between the periods. The special form for this command sources the command to make the setting active for all processes started from the command shell. 4. Start the update installer. Change to the WAS_HOME\updateinstaller directory and run the following command: v
Windows
: update.bat v
UNIX
62
: ./update.sh 5. In the installer, enter the installation location of WebSphere Application Server and select Install maintenance package. 6. Enter the file name of the fix: pk25740.pak. 7. Install the maintenance package. 8. When the installation is complete, log on to the WebSphere Application Server administrative console as tioadmin at the following URL: http://<hostname:port>/admin. where hostname is the fully-qualified domain name of the Tivoli Provisioning Manager computer and port is the WebSphere Application Server Admin host secure port that you defined during installation. The default port number is 9044. For example:
https://tpmserver.example.com:9044/admin
9. 10. 11. 12.
Click Security > Global Security. Under Custom Properties, click New. In the Name field, enter com.ibm.ws.security.web.logoutOnHTTPSessionExpire. In the Values field, enter true.
13. Click Apply and Save to save the changes to your configuration. 14. Restart WebSphere Application Server.
New user cannot see Start Center

When changing your password, you must follow all password policy parameters, such as length and number of alphabetic characters.
Symptoms
You add a new user using the WebSphere Administrative Console and then log on as that user shortly after the user account is created. Logon is successful, but you cannot see the Start Center for the user.
Causes
The Start Center is created for users in the Maximo database. The following settings influence how often user information is updated in the database: v The WebSphere Application Server Virtual Member Manager synchronization interval. v WebSphere Application Server search cache timeout. WebSphere Application Server uses the cache to save data retrieved from the LDAP server to improve performance. By default, synchronization occurs every 5 minutes and the cache timeout interval is 10 minutes. Because the cache timeout is longer than the synchronization interval, new user information is not provided to the Maximo database until the cache timeout expires.

The WebSphere Application Server search cache helps to improve performance. If you do not need users to log on immediately after creating the new user account, you can ask users to wait for 10 minutes before logging on. If you want to change the synchronization interval or the cache timeout, perform the following steps: v To view or change the WebSphere Application Server VMM synchronization interval: 1. Click Go To > System Configuration > Platform Configuration > Cron Task Setup.. 2. Type VMM in the Cron Task field, and press Enter. 3. In the search results, click VMMSYNC.
Chapter 1. Overview
63
4. In the Cron Task Instances section, change the synchronization interval in the Schedule field as required. v To change the search cache timeout: 1. Login to the WebSphere Administrative Console, then navigate to Security > Secure administration, applications, and infrastructure. 2. Locate the User account repository section and pick Federated repositories from the Available realm definition field, and then click Configure. 3. Click the repository link in the Repository identifier, for example ISMITDS. 4. In the Caches section, ensure that Cache the search results is enabled and change the value of Cache times out to the required value.
The base services shortcut does not work

The base services shortcut does not work after the core components installation.
Symptoms
After the installation of Tivoli Provisioning Manager , the Maximo Console shortcut from the Start menu of the administrative workstation does not work.
Causes
The shortcut was created during bases services installation. During the core components installation, the port is updated to the port provided by the user.

Update the shortcut to point to the following Web address:
https://<host_name>:<port>/maximo
where host_name is the host name of the provisioning server, and port is the port specified by the user during core components installation. The default value is 9443.
Error JSPG0227E when accessing the Web interface

JSPG0227E error displays when accessing the Web interface.
Symptoms
The following error is generated when you access the Web interface:
HTTP Error Code: 500 Error Message: JSPG0227E: Exception caught while translating /webclient/components/page.jsp: java.lang.reflect.InvocationTargetException
Causes
WebSphere Application Server cannot access the /opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/ temp due to conflicting file permission.

To resolve this problem: v Run the following command on the provisioning server after the Web component installation:
cd /opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/ chown -R tioadmin:tioadmin temp
v Log in again.
64
Other problems
This section describes how to recover from miscellaneous Tivoli Provisioning Manager problems.
An error occurs after a successful Tivoli Provisioning Manager 7.2 default install on Win2K8R2 SE 64-bit
Symptoms
The following log files display error messages that occur after a successful Tivoli Provisioning Manager 7.2 default install on Win2K8 R2 SE 64-bit. v TIO_LOGS/trace.log v TIO_LOGS/console.log v TIO_LOGS/install_wrapper/tcinstall.log Note: For the default location of TIO_LOGS, click here.
2010-06-04 01:23:29,274 ERROR [Workflow Dispatcher] (WorkflowDispatcher.java:243) runtime.WorkflowDispatcher: COPDEX040E An unexpected deployment engine exception occurred: java.lang.ClassNotFoundException: com.ibm.tivoli.orchestrator.de.dto.maximo.DeploymentRequestDAO. com.ibm.tivoli.tpm.metadata.MetadataException: java.lang.ClassNotFoundException: com.ibm.tivoli.orchestrator.de.dto.maximo.DeploymentRequestDAO at com.ibm.tivoli.tpm.metadata.dao.DAOFactory.getDAO(DAOFactory.java:26) at com.ibm.tivoli.tpm.metadata.dao.DAOFactory.getDAO(DAOFactory.java:41) at com.ibm.tivoli.orchestrator.de.dto.oracle.DTOFactoryImpl.getDeploymentRequestDto( DTOFactoryImpl.java:87) at com.ibm.tivoli.ldo.runtime.WorkflowDispatcher.pollDatabase (WorkflowDispatcher.java:163) at com.ibm.tivoli.ldo.runtime.WorkflowDispatcher.run(WorkflowDispatcher.java:230) Caused by: java.lang.ClassNotFoundException: com.ibm.tivoli.orchestrator.de.dto.maximo.DeploymentRequestDAO at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass (BundleLoader.java:405) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass (BundleLoader.java:350) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass (DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:605) at com.ibm.tivoli.tpm.common.resource.TpmClassLoader.forName (TpmClassLoader.java:20) at com.ibm.tivoli.tpm.metadata.dao.DAOFactory.getDAO(DAOFactory.java:23) ... 4 more 2010-06-04 01:23:29,337 DEBUG [Thread-18] (DeploymentEngine.java:75) engine.DeploymentEngine: DeploymentEngine is shutting down
2010-06-03 22:29:18,168 DEBUG [TCAupgrade_CreateSPBs(10001)] (WorkflowExecutionMonitor.java:134) komodor.WorkflowExecutionMonitor: 0Failing workflow: TCAupgrade_CreateSPB_for_platform.java with exception: com.ibm.tivoli.orchestrator.de.engine.WorkflowThrownException: Command failed. Return code = 1 at com.ibm.tivoli.ldo.runtime.WkfBase.throwException(WkfBase.java:26) at com.ibm.tivoli.tpm.wkf.SWDDiscCLI.Build_SPB_from_SPD.execute (Build_SPB_from_SPD.java:185)
Causes
This is caused by a known issue during the creation of the software package block (SPB). This error occurs when the Tivoli Provisioning Manager engine is being stopped or the system is being shutdown.

The above error message is a known issue and should be viewed as a warning.
The information center for non-English languages is displayed in English

The information center is English by default. Download a version of the information center that is in your preferred non-English language.
Chapter 1. Overview
65
Symptoms
When you click Information Center on the web interface, the information center displays in English, even if the provisioning server was installed in a different language.
Causes
The information center is English by default.

Download a version of the information center that is in your preferred non-English language. To do this: 1. Set your browser to the locale for your language. 2. If not already in the information center from the Internet, go to the information center at http://publib.boulder.ibm.com/infocenter/tivihelp/v20r1/. 3. On the Welcome page, under the Documentation updates heading, click Tivoli documentation. 4. Select Downloads from the lower left of the Contents list. 5. Follow the instructions provided to update the information center included with the product.
Cannot execute commands as a non-administrator in Cygwin

When using RSA credentials for SSH SAP on Cygwin, users not in the administrator group cannot execute commands using Tivoli Provisioning Manager.
Symptoms
When a non-adminstrator user with RSA credentials for SSH SAP attempts to run workflows to a Windows Cygwin target (part of the data model) using Tivoli Provisioning Manager, the following error occurs:
Execution failed with error: COPCOM123E A shell command error occurred: Exit code=-1, Error stream="3 [main] sshd 1576 C:\cygwin\usr\sbin\sshd.exe: *** fatal error - could notload user32, Win32 error 1114", Output stream="".
Causes
This error is caused by a bug in Cygwin 1.7 and higher.

To successfully execute commands via Tivoli Provisioning Manager automated workflows on Cygwin using RSA credentials for SSH SAP, the user must be part of the administrator group.
German thousand separator not respected by the Storage Template application

In the German numbering convention, the period is used as a thousand separator (1.000) and the comma is used as a decimal point (1,0). In the Storage Template application, the field Consumable Size wrongly translates numbers in German that have a thousand separator in them. For example, 1.200KB would be translated into 1,2KB.
Symptoms
In the German numbering convention, the period is used as a thousand separator (1.000) and the comma is used as a decimal point (1,0). In the Storage Template application, the field Consumable Size wrongly translates numbers in German that use a thousand separator. For example, 1.200KB would be translated into 1,2KB. This limitation also applies to other non-English numbering conventions.
Causes 66
Currently, the Storage Template application respects the English numbering convention only. It does not respect non-English numbering conventions, for example, German (period as a thousand separator) or Russian (space as thousand separator).

This is a limitation of the Storage Template application. Enter numbers that use a thousand separator and a decimal point in the English numbering convention only (period for decimal point, comma for a thousand separator) when using the Storage Template application.
Object selection is cleared after searching for another object

You can either search for and add one object at a time, or use multiple search items in a field, separating them with "and" symbols (&) or commas (,).
Symptoms
If you select an object in a dialog or a table, and then search for a different term, your original item selection is cleared.
Causes
Only the last searched object (or objects) is displayed when searching.

You can either search for and add one object at a time, or use multiple search items in a field, separating them with "and" symbols (&) or commas (,).
Cannot create graph containing data model objects

If the graph is based on DCMOBJECTTYPE.DESCRIPTION in the Chart Options tab, then this is a current limitation.
Symptoms
In a portlet of type All DCM Objects (generally named Data model object finder), the graph that represents the result set is not created.
Causes
This is a base services limitation.

Click the pencil icon to open the portlet options, and then see the Chart Options tab. If it shows that the graph is based on DCMOBJECTTYPE.DESCRIPTION, then this is a current limitation. To restore the original list view, select a different Display By Attribute, for example Type_id, and select List View from the graph.
Error when primary Tivoli Provisioning Manager server is disabled

The file system does not release the lwi.lck file after the primary server is disabled. Reboot the secondary server and then restart Tivoli Provisioning Manager.
Symptoms
When the primary Tivoli Provisioning Manager server is disabled and the user attempts to manually open Tivoli Provisioning Manager from the secondary server, the following message appears:
ALR0027I: Waiting for the currently running lightweight run time to exit.
Chapter 1. Overview
67
Causes
The file system does not release the lwi.lck file after the primary server is disabled.

Reboot the secondary server and then restart Tivoli Provisioning Manager.
The provisioning server does not start on Windows

In this configuration, IBM Tivoli Directory Server might treat DB2 as if it has started, even if it has not.
Symptoms
The provisioning server does not start on Windows, and a message appears in the WebSphere Application Server log (SystemOut.log in the %WAS_HOME%\logs\server1 directory) similar to the following:
3c450cad LdapRegistryI E SECJ0352E: Could not get the users matching the pattern wasadmin because of the following exception javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]
Causes
In this configuration, IBM Tivoli Directory Server might treat DB2 as if it has started, even if it has not.

Try stopping your IBM Tivoli Directory Server service and then starting it again. Then start the provisioning server again. To prevent this problem from occurring each time you reboot: 1. Go to Start > Settings > Control Panel > Administrative Tools > Services 2. Right-click the IBM Tivoli Directory Server service and select Properties. 3. In the Start type list, select Manual.
The provisioning server does not start on Linux

When using a non-login shell on Linux, make sure that the .TCprofile script is sourced.
Symptoms
When using a non-login shell on Linux, the provisioning server does not start from GNOME or KDE terminals. The following symptoms might appear: 1. The output of the tioStatus command shows that the deployment engine, policy engine, and the DMS result server did not start:
ADMU0116I: Tool information is being logged in file /opt/ibm/tivoli/tpm/tioprofile/logs/server1/serverStatus.log ADMU0128I: Starting tool with the tioprofile profile ADMU0500I: Retrieving server status for server1 ADMU0508I: The Application Server "server1" is STARTED 2007-10-20 21:13:29,824 INFO log4j configureAndWatch is started with configuration file: /opt/ibm/tivoli/tpm/config/log4j-util.prop 2007-10-20 21:14:00,115 INFO COPCOM422I The deployment engine is not started. 2007-10-20 21:14:00,986 INFO COPCOM424I The policy engine is not started. 2007-10-20 21:14:00,989 INFO COPCOM484I The agent shell server is started. 2007-10-20 21:14:01,000 INFO COPCOM560I The activity plan engine is started. 2007-10-20 21:14:01,002 INFO COPCOM585I The SOAP service is started. 2007-10-20 21:14:01,018 INFO COPCOM588I The DMS Result Server is not started.
68
2. Displaying the value of the LD_LIBRARY_PATH environment variable from a command shell (for example, echo $LD_LIBRARY_PATH) returns null. 3. A message appears in the $TIO_LOGS/console.log file:
COPCOM093E The JDBC driver caused an SQL exception. com.thinkdynamics.kanaha.datacentermodel.DataCenterSystemException: COPCOM093E The JDBC driver caused an SQL exception. ... Caused by: com.ibm.db2.jcc.a.SqlException: Failure in loading T2 native library db2jcct2 at com.ibm.db2.jcc.t2.a.a(a.java:31) at com.ibm.db2.jcc.t2.T2Configuration.<clinit>(T2Configuration.java:75) at com.ibm.db2.jcc.DB2SimpleDataSource.getConnection (DB2SimpleDataSource.java:183) at com.ibm.db2.jcc.DB2SimpleDataSource.getConnection (DB2SimpleDataSource.java:144) at org.apache.commons.dbcp.DataSourceConnectionFactory.createConnection (DataSourceConnectionFactory.java:42) at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject (PoolableConnectionFactory.java:290) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject (GenericObjectPool.java:771) at org.apache.commons.dbcp.PoolingDataSource.getConnection( PoolingDataSource.java:95) at com.thinkdynamics.kanaha.datacentermodel.inprocess. ConnectionManager.getConn(ConnectionManager.java:93)
Causes
When starting from a non-login shell, .TCprofile is not sourced and therefore LD_LIBRARY_PATH is not set properly.

To make sure that the .TCprofile script is sourced on non-login shells, add the following lines to the .bashrc file in the home directory for tioadmin (for example, /home/tioadmin/.bashrc). In the lines below, you must replace /opt/ibm/tivoli/tpm/ with TIO_HOME on your system.
# The following three lines have been added by IBM Tivoli if [ -f /opt/ibm/tivoli/tpm/.TCprofile ]; then . /opt/ibm/tivoli/tpm/.TCprofile fi
To ensure that the .TCprofile script does not run twice, remove the above lines from the .bash_profile and .profile files in the tioadmin home directory.
Error running the versionInfo command

The versionInfo command is not supported for Windows-64 bit computers.
Symptoms
An error occurs when you run the versionInfo command on a Windows 64bit computer.
Causes
This command is not supported for Windows-64 bit computers.
Turning on auditing causes configdb script error

Turning on auditing can cause an error to occur when executing the configdb script.
Symptoms
Chapter 1. Overview
69
After turning on auditing within Maximo, running the configdb script results in the following error message:
SQLCODE=-670, SQLSTATE=54010
Causes Resolving the problem

After auditing is enabled, the name of the auditing table is displayed in the Audit Table field. 1. Copy and paste this name in the Find field and search for this audit table. 2. Click on the audit table name in the search result. 3. Click on the arrow beside the Storage Partition field and select IBM32KSPACE. 4. Click the Save toolbar button. 5. Stop the server. 6. Run the configdb script again. Now the script will run without error.
Database lock timeout error

Frequently committing to a database will cause a lock timeout error. This possibility can be reduced by changing the database registry settings.
Symptoms
You receive the following error:
COPCOM093E The JDBC driver caused an SQL exception. COPJEE272E (Problem ID: UI449932). com.thinkdynamics.kanaha.datacentermodel .DataCenterSystemException: COPCOM093E The JDBC driver caused an SQL exception
Causes
This is caused by frequency committing to a database, causing a lock timeout. In the $TIO_LOGS/j2ee file, you will find this information:
Caused by: com.thinkdynamics.kanaha.util.exception.DatabaseDeadlockException: DB2 SQL error: SQLCODE: -911, SQLSTATE: 40001, SQLERRMC: 68
The error 68 indicates that a lock timeout occurred

To reduce the possibility of database lock timeouts, run the following commands to configure the database registry: db2set DB2_SKIPINSERTED=YES db2set DB2_SKIPDELETED=YES and db2set DB2_EVALUNCOMMITTED=YES_DEFERISCANFETCH When you turn on these settings, remember to recycle the instance (that is, stop the database and then start it again).
Logs exceed the file system capacity on UNIX

When the log directory is on the same file system as Tivoli Provisioning Manager, it can reach or exceed the capacity of the file system. This can prevent the application from creating new log files.
Symptoms
70
When the log directory is on the same file system as Tivoli Provisioning Manager, it can reach or exceed the capacity of the file system. This can prevent the application from creating new log files.
Causes
The capacity of the file system is not large enough.

Try one of the following solutions: v Determine whether other processes are using the file system on which the logs are located. If so, create a dedicated file system for logging so that the file system is not affected by any process other than logging. Refer to your operating system manual for the required procedures. v Extend the size of the file system on which the log is located. Alternatively, free up space on the same file system to resolve the problem for the time being. v If current messages in the logs require attention, resolve the problems so that the messages will not be displayed again. To prevent this problem from occurring in future, investigate and modify the size of the file system as required. v Manually archive the log files to increase the amount of available storage space on the file system. v Set the maximum log file size for the console.log file and the msg.log file to a smaller value.
Cannot import XML

Shut down Tivoli Provisioning Manager before you run an XML import, and then restart it when the XML import is completed.
Symptoms
Tivoli Provisioning Manager does not function as you would expect when you run an XML import while all the Tivoli Provisioning Manager processes are running.
Causes
Tivoli Provisioning Manager processes cache some information, and they depend on JMS messages for notification when events occur (for example, when the system runs logical management operations and workflows). However, an XML import does not send any notifications to the Tivoli Provisioning Manager processes. It just loads the database.

Shut down Tivoli Provisioning Manager before you run an XML import, and then restart it when the XML import is completed. Refer to the following topics for instructions on how to start and stop Tivoli Provisioning Manager: v v
Windows UNIX
Starting and stopping the provisioning server on Windows

Linux
Starting or stopping the provisioning server on UNIX or Linux
Error messages are displayed in English while working in a non-English locale

This is a localization issue. You need to change a setting in WebSphere Administrative Console to display error messages in the language of your locale.
Symptoms
You are working in a non-English locale, and error messages are only being displayed in English.
Causes
Chapter 1. Overview
71
This is a localization issue.

To 1. 2. 3. resolve this issue: Log on to the WebSphere Administrative Console In the left panel, click Servers > Application Servers. In the right panel, click MXServer > Java and Process Management > Process Definition -> Java Virtual Machine. 4. Add your TIO_HOME/nls path into the class path field. 5. Click Apply > Save to save your change.
6. Return to the Application Server page, and select MXServer. Stop the server and then restart it. All error messages must now be displayed in the language of your locale.
EMAILTYPE translation errors

The WORK keyword was translated in some languages which break the security code on non-English install of Tivoli Provisioning Manager
Symptoms
New users are created successfully. But those users are not listed in the user interface. This can only happen on a non-English installation of Tivoli Provisioning Manager.
Causes
The value of the EMAILTYPE domain was translated.

Workaround on non-English provisioning server: 1. Login to Maximo UI as a admin user 2. Go To > SystemConfiguration > Platform Configuration > Domains > Emailtype 3. Change the entry to WORK 4. Restart the server and any outstanding VMMSync tasks. .
Default insert site configuration does not take effect or is not persistent for the user
This can occur if the default insert site has not been configured. If it has been configured, then the configuration might not have taken effect.
Symptoms
You receive the error BMXAA0012E - Cannot insert/update a record without a default insert site when trying to do an action that requires a default insert site to be configured. This can occur even if you do have a default insert site configured, but is not active.
Causes
This can occur if the default insert site has not been configured. If it has been configured, then the configuration might not have taken effect (for example, you have not logged out of your sessions yet).
72
Additionally, configuration and usage of sites in conjunction with the MAXADMIN user (that is, the user is configured for mxe.adminuserid) could cause system problems because background sessions for that user might be active frequently.

All of your sessions must be logged out in order for the default site configuration to take effect. If you are not able to log out properly (for example, because of a disconnected network or because you closed the browser without signing out), the configuration will take effect after all of your sessions have timed out or after the server is restarted. Note: We do not recommended that you use the MAXADMIN ID (mxe.adminuserid) in conjunction with any configuration or operations requiring site configuration.
Chapter 1. Overview
73
74

User access control is an integral part of protecting customer services, corporate and customer data, and day-to-day operations. Ensuring that employees in your organization have the appropriate access level is only a part of your overall company security strategy. To get your employees the most adequate user access level, you need to control who has access to which provisioning applications. With user access control based on predefined and customizable security groups you can adequately protect business assets and resources in the data model with a minimal amount of administrative effort. To control user access, you need to make some decisions: 1. Define what resources must be protected: v Hardware resources v Software resources 2. Decide if you can apply the predefined security group structure. v If not, what users and groups of users have access to these protected resources. 3. Decide what type of access must be permitted to those resources. 4. Apply the appropriate access controls on these resources to ensure that only the assigned groups of users can access them. There are some security features that help you protect your enterprise: v Predefined and customizable security roles and access control for users in security groups. v Secure communication within the enterprise with certificate-based authentication.
Controlling user access basics

Find out more about the operating system management, the key terms, who are the users that perform access control checks, and what are the requirements that you need to know. Review the troubleshooting information and the log files names and location for this feature and also additional resources that help you complete your access control tasks. v v v v v v Process User roles on page 76 Requirements on page 76 Key terms on page 77 Troubleshooting on page 77 Log files on page 77
Process
Security includes the following processes: 1. You define what resources must be protected. 2. You decide what groups of users can have access to these protected resources. You also need to decide what type of access to allow to those resources. 3. You must apply the appropriate access controls on these resources to ensure that only the assigned user groups can access them.
75
User roles
You must be assigned to the appropriate user role to manage security configuration. For more information about predefined security roles that are available in Tivoli Provisioning Manager, see Predefined security groups on page 134.
Table 11. User roles Role MAXADMIN Description Manages security Skills Access rights
Thorough knowledge of the To control user access, the security configuration and provisioning administrator requirements. role is required.
Requirements
User roles and requirements on page 79 Target computer requirements: Requirements for Windows target computers on page 556 Requirements for Red Hat Linux target computers on page 560 Requirements for SUSE Linux Enterprise Server (SLES) target computers on page 561 Requirements for AIX target computers on page 562 Requirements for Solaris Operating Environment target computers on page 563 Requirements for HP-UX target computers on page 565 v Components on page 78
76
Key terms
access permission The access privilege that applies to an object. access permission group A group of access permissions. application One or more computer programs or software components that provide functions in direct support of a specific business process or processes. authentication In computer security, verification of the identity of a user or process and the construction of a data structure that contains the privileges that were granted to the user or process. Contrast with authorization. authorization The process of granting a user either complete or restricted access to an object, resource, or function. Contrast with authentication. security group A group defined for the purpose of providing access to applications and optionally to collections of data. role A set of job responsibilities related to a service management process. Each role is implemented as a security group, which gives users with that role access to a set of applications and a start center with role-appropriate information.
instance level security Access permissions that specify what actions a user can perform on specific resource in the Tivoli Provisioning Manager data model. workflow security A security mechanism to ensure that users process the correct set of permissions to run the particular workflow.
Troubleshooting
v Troubleshooting security on page 119 v ../com.ibm.support.tpm.doc/messages/rtrbmsg_tpm.dita v Support information about security v Support information about user access v Contacting Support
Log files
If you encounter security errors, check the following log for details: %TIO_LOGS%/console.log
77
Resources
v Tutorial: manage security and access permissions using LDAP on page 80 v Tutorial: manage security and access permissions using Maximo authentication on page 85 v Managing users and security groups v Role based security groups on page 132 v Conditional user interface on page 144 v Single Sign-on (SSO) on page 144 v Security v For a description of a field in the Tivoli Provisioning Manager console, press Alt+F1.
Related links Chapter 2, Controlling user access, on page 75 Requirements on page 79 Troubleshooting security on page 119 Tutorial: manage security and access permissions using LDAP on page 80 Tutorial: manage security and access permissions using Maximo authentication on page 85
Security process
It is important to understand the overall user access control process before you start managing security with Tivoli Provisioning Manager. Security includes the following processes: 1. You define what resources must be protected. 2. You decide what groups of users can have access to these protected resources. You also need to decide what type of access to allow to those resources. 3. You must apply the appropriate access controls on these resources to ensure that only the assigned user groups can access them.
Components
The Tivoli Provisioning Manager uses the Maximo security framework for both authentication and instance access control. Maximo, in turn, uses Websphere to perform the authentication service. In terms of instance access control, Tivoli Provisioning Manager makes use of the Maximo security framework with security groups containing the resources to be protected, security constraints defining the permissions, and the users to be enforced by the constraints. Tivoli Provisioning Manager security consists of the following components: Tivoli Provisioning Manager static groups A provisioning static group defines the members. A member can be either a provisioning object or another provisioning group. Each provisioning object is associated with a type, for example a computer object has a computer object type. A static group can be typed or untyped. A typed static group contains only the objects of that type whereas an untyped group contains objects of any type. Both typed and untyped static groups can be used for security purposes. Tivoli Provisioning Manager dynamic groups A provisioning dynamic group defines its members by a query. A query is a SQL where clause. Objects are retrieved if and only if the object properties satisfy the query. A query has a type in which it can only apply to the resources of that type. A query defined for a computer type can only apply to computer resources. A dynamic group can be typed or untyped. A typed dynamic group contains only the query of that type. After the dynamic group type is set, it cannot be
78
changed. An untyped dynamic group can contain a query of any type at any time. Only typed dynamic groups can be used for security purposes. Tivoli Provisioning Manager security manager Tivoli Provisioning Manager security manager manages the bridging between the provisioning groups and the Maximo security framework. It manages all of the conditions and data restrictions required for security. It also manages the security on workflows. Users can run protected workflows only if they have the correct set of permissions on the resources specified by the workflow definition. IBM Maximo Asset Management components v Security framework v v v v Condition Security group SQL expression Permission
For a detailed description of the Maximo components, go to IBM Maximo Asset Management online documentation.
Integration with IBM Service Management

If you use IBM Service Management processes, you can use an IBM Service Management workflow for security. Some of the predefined security groups in Tivoli Provisioning Manager are compatible with IBM Service Management. IBM Service Management provides an infrastructure where business processes can be performed in a consistent, reliable, and predictable manner. Use the following roles aligned for the IBM Service Management workflow for security: v TPADMIN Administrator v TPCOMPLIANCEANALYST Compliance Analyst v TPCONFIGURATIONLIBRARIAN Provisioning Configuration Librarian v TPDEPLOYMENTSPECIALIST Deployment Specialist v TPDEVELOPER Automation Package Developer v TPWEBSERVICEUSER Web Service Interface User For the complete list of roles and predefined security groups, see the Predefined security groups on page 134 section.
Requirements
Before you proceed with setting up the user access control, ensure that all software, hardware, and access rights requirements are met.
User roles and requirements

To perform the tasks involved in controlling user access, ensure that you have the required knowledge and access rights to perform your role.
Table 12. User roles Role MAXADMIN Description Manages security Skills Access rights
Thorough knowledge of the To control user access, the security configuration and provisioning administrator requirements. role is required.
79
Managing user access

Tivoli Provisioning Manager supports LDAP authentication and Maximo authentication.
Supported configurations
You can manage user access using LDAP authentication or Maximo authentication. The following tutorials describe how to manage user access using LDAP authentication and Maximo authentication: v Tutorial: manage security and access permissions using LDAP v Tutorial: manage security and access permissions using Maximo authentication on page 85
Tutorial: manage security and access permissions using LDAP

This tutorial demonstrates security management using the security group configuration and it shows how to assign access permissions using LDAP. Completing the tasks in this tutorial allows you to manage access to resources in your environment and provides a fast and reliable way to protect your systems.
Learning objectives
To manage security, you must be assigned and logged in as a MAXADMIN security group member. MAXADMIN is the only security group from which members can configure security and user access control.
In this tutorial, you learn how to: v Create new users v Add users to security groups v Use the predefined security groups, and modify them so that they suit your environment v Create new security groups v Customize access to provisioning groups and applications Allow one hour to create new users, assign them to security groups and customize their access to provisioning applications if required.
Part 1: Setting up users and security groups

Before starting to control user access, you need to set up the users and the security groups. You also need to set up the data synchronization option between the VMM and Tivoli Provisioning Manager.
Learning objectives
After completing the lessons in this module you will be able to perform the following tasks: v Create a user and a security group in LDAP v Assign user to a security group v Enable the synchronization between the VMM and the Tivoli Provisioning Manager to import the user and security group settings into the system.
Time required
This part takes approximately 30 minutes. Lesson 1: Creating a user and a security group:
80
Before setting up security for your resources managed by Tivoli Provisioning Manager, you must have users created in a system that can access and modify the resources. You can create a user and a group with an LDAP script or using any LDAP management tool. Tip: The WebSphere Administrative Console 6.1 manages users and groups in LDAP. This topic describes the steps that help you to create a user and a security group in this interface. To create a user in WebSphere Administrative Console 6.1 using Tivoli Directory Server, complete the following steps: 1. Go to Users and Groups, and select to Manage Users. 2. Click Search to list existing users in the LDAP. 3. Click Create..., and enter the information in all relevant fields, then click Create. 4. Click Close to return to the user list. You have created a user and the entry displays in the list of users. To create a security group in WebSphere Administrative Console 6.1 using Tivoli Directory Server, complete the following steps: 1. Go to Users and Groups, and select Manage Groups. 2. Click Search to list existing groups in the LDAP. 3. Click Create..., and enter the information in all relevant fields, then click Create. 4. Click Close to return to the group list. You have now created a security group and the entry now appears in the group list. To view the newly created users and groups in Tivoli Provisioning Manager, you must import them into the system. Configure the synchronization between the Virtual Member Manager, which is an LDAP interface, and Tivoli Provisioning Manager by completing the procedures in one of the following lessons. Lesson 2: Adding users to security groups: After you have created users, you assign them to one of the predefined security groups. Security groups are the user containers that provide the ability to manage users for security purposes. Tivoli Provisioning Manager provides predefined security groups that you can use and, if necessary, modify to suit your enterprise environment. You can assign an individual user to more than one security group. Users have permission to perform only those operations that are mapped to their security group assignments. Note: For security groups created using LDAP, users can only be added using LDAP. To assign a user to a security group in WebSphere Administrative Console 6.1, complete the following steps: 1. Go to Users and Groups and click Manage Users. 2. Click Search to list the existing users in LDAP. 3. 4. 5. 6. From the list, click the user that you want to assign to a security group. Click the Groups tab, click Add..., and then Search. Select the group to which you want to add the user and click Add. Click Close. The group to which the user has been added is displayed.
You have configured the user to perform the operations that are mapped to their security group assignments.
81
Lesson 3: Configuring user and security group synchronization: After you have created users and groups, you must import them into Tivoli Provisioning Manager by setting up synchronization between the Virtual Member Manager and the system. You have just created users in LDAP using the WebSphere Administrative Console. Now you must import them into Tivoli Provisioning Manager using the Virtual Member Manager synchronization option. Complete the following steps to import the users you have created into Tivoli Provisioning Manager: 1. If necessary, log on to Tivoli Provisioning Manager. 2. Click Go To > System Configuration > Platform Configuration > Cron Task Setup. 3. Type VMMSync into the Cron Task field and press Enter. 4. Activate the Virtual Member Manager synchronization by clicking the Active check box. 5. To keep the history of all of the activities of the VMM Sync Cron task, check the Keep History check box and type 50 in the Max Number of History Records field. By typing 50, you are specifying that you want to keep the 50 most recent records. 6. To ensure that you retrieve the user or security name from LDAP correctly, complete the following steps: a. Click the Next Page arrow on the Parameters tab. b. Select userMapping c. Change the displayName value in the Value field from the <column name="DISPLAYNAME" type="ALN">displayName<\column> expression to an appropriate attribute value defined in LDAP, for example, uid as in <column name="DISPLAYNAME" type="ALN">uid<\column>. Tip: For the list of all attributes available in LDAP, see the Person DataObject for user attributes and the Group DataObject for security group attributes. For information about the attribute mapping between LDAP and Tivoli Provisioning Manager, see Attribute mapping from LDAP to IBM Tivoli Provisioning Manager on page 118. . 7. Save the changes by clicking 8. To view all of the imported objects, restart Tivoli Provisioning Manager. You have now activated the synchronization between Virtual Member Manager and Tivoli Provisioning Manager. You have chosen to keep the history of synchronization activities and specified to keep the 50 most recent records.
Part 2: Assigning permissions to security groups

After you have set up users for Tivoli Provisioning Manager and grouped them into security groups, you can begin assigning permissions to the groups to grant the users access to resources.
Learning objectives
After completing the lessons in this module, you will understand the concepts and know how to do the following: v v v v Assign workflow permissions to security groups Assign read/write permissions to security groups Assign read-only permissions to security groups Modify the access permissions for a given security group
Attention: Adding any type of permission is related to specifying a restriction for a particular security group. Each security group can only have one restriction of the same type.
82
Time required
This module takes approximately 30 minutes. Lesson 1: Assigning read/write type of permissions to security groups: You can grant a security group access to resources by authorizing the group to have read or write access to the resources. You can control whether a resource is read-only or writable for the users in a security group by assigning read or write permissions. Attention: If you define no restriction on a resource type, the security group is granted full access to the resource by default. To add read/write access to a security group, complete the following steps: 1. From Tivoli Provisioning Manager, Click Go To > Security > Security Group. 2. Click the security group for which you want to add permissions. 3. Click the Provisioning Permissions tab, and click Read/Write Permissions. v To add read-only permission, click Add Read-only Permissions, and choose the provisioning group of resources to which you want to add read-only access. Note: The read-only permission restricts user access to viewing data only. To learn how to customize the access to applications of your choice, see Lesson 3: Customizing access to provisioning applications on page 84. v To add read/write permission, click Add Read/Write Permissions, and choose the provisioning group of resources to which you want to add read/write access. Tip: In case you modify the condition for the data restriction generated by the provisioning permission application, you can reset it to its original state by clicking Reset Condition. Important: You can grant a permission for each type of object. Check the group object type before granting new permissions. 4. Save the group configuration changes by clicking .
You have now assigned read/write access to a security group by associating the resources in provisioning group with the users in the security group. Lesson 2: Assigning workflow permissions to security groups: Accessing a provisioning workflow represents having the ability to modify the real implementation of a specific IT process. Learn about how you can grant permissions to workflow processes. To assign a workflow permission to a security group: 1. Log on to Tivoli Provisioning Manager. Click Go To > Security > Security Group. 2. Select the security group for which you want to add workflow permission. 3. Click the Provisioning Permissions tab, and click Workflow Permissions. 4. Add the access to a workflow by clicking New Row, and specifying Provisioning Group and Permission Group. Use to choose from the existing groups.
. 5. Save the settings by clicking 6. Enable the workflow permission by clicking Go To > Security > Security Group, and choosing the security group for which you want to add workflow permission. 7. Go to the Data Restrictions tab, and click New Row.
83
8. Specify TPACCESSDOMAIN for Object using
, and specify QUALIFIED for the Type field also using
. Verify that the Reevaluate? box is checked, and choose TPMWKFCOND for the Condition field. 9. Save the settings by clicking .
You have now assigned the workflow permission to a security group by matching it with the resources in a particular provisioning group and permissions specified in the permission group of your choice. Lesson 3: Customizing access to provisioning applications: Tivoli Provisioning Manager provides six security groups and associated start centers. By modifying a predefined security group you can configure it to have a customized access control to applications of your choice. You can either add or remove access to applications. To grant or revoke access to applications for a specific security group: 1. Log on to Tivoli Provisioning Manager. Click Go To > Security > Security Group. 2. Click the security group that you want to modify. 3. Click the Applications tab, and click the application for which you want to modify access. Clicking the application opens an options table for that particular application. 4. Click the option that you want to modify, check it for granting access, or mark as unchecked to revoke access. 5. Save the new group configuration by clicking .
You have now modified the predefined security group definition to match your environment needs. Lesson 4: Creating custom security groups: Apart from the predefined security groups and associated particular start centers you can create your own security groups that suit your enterprise needs. This lesson shows how to set one up and how to configure it to have a customized access control to applications of your choice. Note: You are also able to create security groups using LDAP. This, however, implies the need to assign users to the groups through LDAP only. To create a security group from the user interface: 1. Log on to Tivoli Provisioning Manager. Click Go To > Security > Security Group. . 2. Click the 3. Enter the information in the appropriate fields. You can define a Long Description and Start Center Template for the new group, and mark it to be Independent of Other Groups. 4. Save the new group definition by clicking You have now created a custom security group. Add users to the newly created security group by following the instructions in Lesson 2: Adding users to security groups on page 81. Additionally, you can modify the user access control by Customizing access to provisioning applications described in Part 2, Lesson 3. For more information about dependent and independent groups, see Chapter 2: Security of the Maximo Asset Manager System Administrator Guide. Lesson 5: Enabling instance level security for data model object finder: .
84
You can enable instance level security for the data model object finder. By enabling instance level security for the data model object finder, you can ensure that users can only view objects that they are authorized to view when they use the data model object finder. If you do not enable instance level security for the data model object finder, users can view all objects. However, users can only view those objects and cannot modify objects unless they have write permissions to those objects. To enable instance level security for the data model object finder, you manage the permissions based on the groups to which users belong. Complete the following steps to enable instance level security in the data model object finder: 1. Log on to Tivoli Provisioning Manager. Click Go To > Security > Security Group. 2. Click the group to which the user for whom you are enabling security belongs. 3. Click Select Action > Enable DcmFinder Security. You have now enabled instance level security for the data model object finder.
Tutorial: manage security and access permissions using Maximo authentication

This tutorial demonstrates security management using the security group configuration and it describes how to assign access permissions using Maximo authentication. The tasks described in this tutorial provide you with information about managing access to resources in your environment.
Learning objectives
To manage security, you must be assigned and logged in as a MAXADMIN security group member. MAXADMIN is the only security group from which members can configure security and user access control.
In this tutorial, you learn how to: v Create new users in Maximo v Add the new Maximo users to security groups v Use the predefined security groups, and modify them so that they suit your environment v Create new security groups v Customize access to provisioning groups and provisioning applications Allow one hour to create new users, assign them to security groups, and customize their access to provisioning application if required.
Part 1: Setting up users and security groups in Maximo

As part of managing user access in Maximo, you need to set up Maximo users and groups. Before starting to control user access, you need to set up the users and the security groups. Before you can set up users and groups in Maximo, you must have specified the Maximo option during your Tivoli Provisioning Manager installation.
Learning objectives
After completing the lessons in this module, you will be able to perform the following tasks: v Create a user and a security group in Maximo v Assign user to a Maximo security group
85
Time required
This part takes approximately 30 minutes. Lesson 1: Creating a user and a security group in Maximo: Before setting up security for the resources managed by Tivoli Provisioning Manager, you must create users in a system that can access and modify the resources. To 1. 2. 3. create a user in Maximo, complete the following steps: Click Go To > Security > Users. Click the New Users icon. Complete the fields in the Users page, as required. For more information, see the Maximo Asset Manager System Administrator Guide
You have now created a user and the entry displays in the user list. To create a security group in Maximo, complete the following steps: 1. Click Go To > Security > Security Group. 2. Click the New Group icon. 3. Complete the fields in the Security Group page, as required. For more information, see the Maximo Asset Manager System Administrator Guide. You have now created a security group and the entry is included in the group list. See the troubleshooting section if you have problems with passwords and the send password by email function. Lesson 2: Adding users to Maximo security groups: After you have created users, you need to assign them to one of the predefined security groups. Security groups are the user groupings that provide the ability to manage users for security purposes. Tivoli Provisioning Manager provides predefined security groups that you can implement and, if necessary, modify to suit your enterprise environment. You can assign an individual user to more than one security group. Users have permission to perform only those operations that are mapped to their security group assignments. To assign a user to a Maximo security group, see the Maximo Asset Manager System Administrator Guide. You have configured the user to perform the operations that are mapped to their Maximo security group assignments.
Part 2: Assigning permissions to Maximo security groups

After you have set up users for Tivoli Provisioning Manager and grouped them into security groups, you can begin assigning permissions to the groups to grant users access to resources.
Learning objectives
After completing the lessons in this module, you will understand the concepts and know how to do the following tasks: v Assign workflow permissions to security groups v Assign read/write permissions to security groups
86
v Assign read-only permissions to security groups v Modify the access permissions for a given security group Attention: Adding any type of permission is related to specifying a restriction for a particular security group. Each security group can only have one restriction of the same type.
Time required
This module takes approximately 30 minutes. Lesson 1: Assigning read/write type of permissions to security groups: You can grant a security group access to resources by authorizing the group to have read/write access to the resources. You can control whether a resource is read-only or writable for the users in a security group by assigning read/write permissions. Attention: If you do not define restrictions on a resource type, the security group is granted full access to it by default. To add read/write access to a security group: 1. Log on to Tivoli Provisioning Manager. Click Go To > Security > Security Group. 2. Click the security group for which you want to add workflow permission. 3. Click the Provisioning Permissions tab, and click Read/Write Permissions. v To add read-only permission, click Add Read-only Permissions, and click the provisioning group of resources to which you want to add read-only access. Note: The read-only permission restricts user access to viewing data only. To learn how to customize the access to applications of your choice, see Lesson 3: Customizing access to provisioning applications on page 84. v To add read/write permission, click Add Read/Write Permissions, and click the provisioning group of resources to which you want to add read/write access. Tip: In case you modify the condition for the data restriction generated by the provisioning permission application, you can reset it to its original state by clicking Reset Condition. Important: You can grant a permission for each type of object. Check the group object type before granting new permissions. 4. Save the group configuration changes by clicking .
You have now assigned read/write access to a security group by associating the resources in provisioning group with the users in the security group. Lesson 2: Assigning workflow permissions to security groups: Accessing a provisioning workflow provides the ability to modify the real implementation of a specific IT process. Learn how you can grant permissions to workflow processes. To 1. 2. 3. assign a workflow permission to a security group: Log on to Tivoli Provisioning Manager. Click Go To > Security > Security Group. Select the security group for which you want to add workflow permission. Click the Provisioning Permissions tab, and click Workflow Permissions.
87
4. Add the access to a workflow by clicking New Row, and specifying Provisioning Group and Permission Group. Use to choose from the existing groups.
. 5. Save the settings by clicking 6. Enable the workflow permission by clicking Go To > Security > Security Group, and choosing the security group for which you want to add workflow permission. 7. Go to the Data Restrictions tab, and click New Row. 8. Specify TPACCESSDOMAIN for Object using , and specify QUALIFIED for the Type field also using
. Verify that the Reevaluate? box is checked, and choose TPMWKFCOND for the Condition field. 9. Save the settings by clicking .
You have now assigned the workflow permission to a security group by matching it with the resources in a particular provisioning group and permissions specified in the permission group of your choice. Lesson 3: Customizing access to provisioning applications: Tivoli Provisioning Manager provides six predefined security groups and associated start centers. However, by modifying a predefined security group, you can configure it to have customized access control to applications of your choice. You can either add or remove access to applications. To grant or revoke access to applications for a specific security group: 1. Log on to Tivoli Provisioning Manager. Click Go To > Security > Security Groups. 2. Select the security group for which you want to modify. 3. Go to Applications tab, and click the application for which you want to modify the access. Clicking the application opens an options table for that particular application. 4. Click the option that you want to modify, check it for granting access, or mark as unchecked for revoking. 5. Save the new group configuration by clicking .
You have now modified the predefined security group definition to match your environment needs. Lesson 4: Enabling instance level security for data model object finder: You can enable instance level security for the data model object finder. By enabling instance level security for the data model object finder, you can ensure that users can only view objects that they are authorized to view when they use the data model object finder. If you do not enable instance level security for the data model object finder, users can view all objects. However, users can only view those objects and cannot modify objects unless they have write permissions to those objects. To enable instance level security for the data model object finder, you manage the permissions based on the groups to which users belong. Complete the following steps to enable instance level security in the data model object finder: 1. Log on to Tivoli Provisioning Manager. Click Go To > Security > Security Group. 2. Click the group to which the user for whom you are enabling security belongs. 3. Click Select Action > Enable DcmFinder Security. You have now enabled instance level security for the data model object finder.
88
Everyday tasks for security

This section describes how to complete various everyday and also once-off tasks for security. It describes how to complete many of the configuration tasks required for the security of your users and resources.
Update Tivoli Provisioning Manager certificate in the Java truststore

You can update the Java truststore when a new certificate is generated by the WebSphere Application Server. Tivoli Provisioning Manager certificate expiration period is one year. To verify the certification expiration date, run:
<WAS_HOME>\java\jre\bin\keytool -v -list -keystore <TIO_HOME>/cert/tpmKeyStore.jks -storepass <password> -storetype jks -alias tpmuicert
WebSphere Application Server key management regenerates the expiring certificate every 365 days. To manually change the expiration date and modify the validity period of your certificate, see Creating a self-signed certificate. Perform the steps in this procedure for Tivoli Provisioning Manager engine SSL to work when a new certificate is generated, either automatically by WebSphere Application Server or manually by the user.
Procedure
1. Stop Tivoli Provisioning Manager:
tio.cmd|.sh stop -t
2. Back up the keystore files:

<TIO_HOME>/cert/cliKeyStore.jks <TIO_HOME>/cert/cliTrustStore.jks
3. Copy tpmKeyStore.jks to cliTrustStore.jks 4. Copy tpmTrustStore.jks to cliKeyStore.jks 5. Export the Tivoli Provisioning Manager certificate: cd <WAS_HOME>\java\jre\bin
keytool -export -alias tpmuicert -storepass <tpm key store password> -file <TIO_HOME>/cert/tpmnewui.cer -keystore <TIO_HOME>/cert/tpmKeyStore.jks -storetype jks
6. Import the new Tivoli Provisioning Manager certificate to the Java truststore:
keytool -import -trustcacerts -alias tpmnewcert -keystore <JAVA_HOME>/jre/lib/security/cacerts -storetype jks -storepass <changeit> -file <TIO_HOME>/cert/tpmnewui.cer -noprompt
Where, <JAVA_HOME> is <WAS_HOME>/java. 7. Start Tivoli Provisioning Manager:

tio.cmd|.sh start -t
Creating a duplicate maxadmin user for Tivoli Provisioning Manager

Depending on your topology, you might need to create a user ID other than the maxadmin user, which has the same permissions as maxadmin. For example, if you have more than one Tivoli Provisioning Manager installation, you might want to create more than one maxadmin user. To do this, you create a user equivalent to the maxadmin user but with a different name. In Tivoli Provisioning Manager v7.2, you can create this maxadmin equivalent user during the Tivoli Provisioning Manager installation. You can use the procedure described here to create a duplicate maxadmin user after the installation has completed. The
89
following procedure applies to LDAP user and group management. The name of the maxadmin user is assumed to be new_maxadmin. The procedure described here is applied to Tivoli Provisioning Manager using LDAP authentication and authorization.
Procedure
1. Create a new administration user in WebSphere Application Server and assign all roles to the user. 2. Use VMMSYNC to add the new user to Tivoli Provisioning Manager, then stop Tivoli Provisioning Manager. 3. Modify the maximo.properties file in $WAS_HOME/profiles/ctgAppSrv01/installedApps/ctgCell01/ MAXIMO.ear/properties.jar. Use the -xvf option to unjar the file, and -cvf to rejar the file. Modify maximo.properties by adding the following two lines after mxe.db.schemaowner=maximo, where the value for mxe.adminuserid is in uppercase font but the value for mxe.adminuserloginid is in lowercase:
mxe.adminuserid=<NEW_MAXADMIN> mxe.adminuserloginid=<new_maxadmin>
Note: When adding the previous two lines, replace the existing lines:
mxe.adminuserid=maxadmin mxe.adminuserloginid=maxadmin
A sample maximo.properties file is available as follows:

mxe.db.url=jdbc:db2://<db_hostname>:50005/maxdb71 mxe.db.driver=com.ibm.db2.jcc.DB2Driver mxe.db.user=maximo mxe.encrypted=true mxe.registry.port=13400 mxe.rmi.port=0 mxe.name=MXServer mxe.db.schemaowner=maximo mxe.adminuserid=<NEW_MAXADMIN> mxe.adminuserloginid=<new_maxadmin> mxe.encrypted=true
4. Copy the updated maximo.properties file to $TIO_HOME/lwi/runtime/tpm/eclipse/plugins/tpm_pmp/ properties and $TIO_HOME/eclipse/plugins/tpm_pmp/properties. 5. Update the RunAs users cron task to include the new administration user, where <new_maxadmin> is in lowercase:
UPDATE MAXIMO.CRONTASKINSTANCE SET RUNASUSERID = <new_maxadmin> WHERE RUNASUSERID = MAXADMIN;
6. Update the dynamic content delivery database to use the new admin user by completing the following configuration steps in the dynamic content delivery console: a. Log in to the dynamic content delivery console using the administrator configured during the installation, that is, maxadmin. b. Change the URL to https://<hostname>:9045/admin/configuration, where the change is marked in bold font. c. Click AG_EMBEDDED_APP_ID. A prompt displays. d. Remove the tpm value and click OK. The property is changed. e. Log off and log back on using the original URL https://<hostname>:9045/admin/main.jsp. A Users application is displayed. If you move your mouse over it you see different options for managing users. f. Check if the new administration user is displayed under Users. Create this user if it does not exist. g. Log on as the new user. h. When the log on is successful, log on to https://<hostname>:9045/admin/configuration using maxadmin.
90
i. Click AG_EMBEDDED_APP_ID. A prompt displays. j. Add the tpm value for the AG_EMBEDDED_APP_ID property. 7. Update the CREDENTIALS_PASSWORD table with the new administration user by running the following command, where the value of USER_NAME is in lowercase:
UPDATE MAXIMO.credentials_password SET USER_NAME= <new_maxadmin> WHERE USER_NAME= maxadmin;
8. If the new administration user has a different password than the original maxadmin user, you must update the password, as follows:
$TIO_HOME/tools/changePassword.sh c tpmuiadm n <new_password>
9. Check if mxe.LDAPUserMgmt is disabled, as follows: a. Log on to Tivoli Provisioning Manager as the new maxadmin user you created. b. In the Tivoli Provisioning Manager user interface, click Go To -> System Configuration -> Platform Configuration -> System Properties. c. In the Global Properties filter, type mxe.LDAPUserMgmt and press Enter. d. Check if the value is 0. If the value is not 0, set it to 0 by running the following command:
UPDATE MAXIMO.MAXPROPVALUE SET PROPVALUE = 0 WHERE PROPNAME = mxe.LDAPUserMgmt;
For more information about the mxe.LDAPUserMgmt property, see http://www-01.ibm.com/ support/docview.wss?uid=swg21316588 10. Move the existing queries from the maxadmin user to the new admin user by running the following command, where the value of OWNER is in uppercase:
UPDATE MAXIMO.QUERY SET OWNER= <new_maxadmin> WHERE OWNER= MAXADMIN;
11. Restart Tivoli Provisioning Manager. 12. Optional: Delete the maxadmin user from the Tivoli Provisioning Manager user interface. a. Log on to Tivoli Provisioning Manager. b. Click Go To > Security > Users. c. Click the maxadmin user. d. From the User tab, clear the System Account check box. e. Click Save. f. From the Select Action menu, delete the user. 13. Enable LDAP user management as follows:
UPDATE MAXIMO.MAXPROPVALUE SET PROPVALUE = 1 WHERE PROPNAME = mxe.LDAPUserMgmt;
14. Restart Tivoli Provisioning Manager. 15. Log on to the Start Center UI using the new administration user, use the Display Settings link to hide or show the display tabs for the new administration user.
Results
You have created a new administration user with the same permissions as the maxadmin user. Repeat tasks issued from the maxadmin user will fail. The solution to this problem is to delete the repeated tasks and add them back using the new administration user that you have created.
Configuring Tivoli Provisioning Manager for PKCS12 for Microsoft Active Directory
You can configure Tivoli Provisioning Manager to communicate with Microsoft Active Directory with a PKCS12 certificate using Transport Layer Security (TLS) protocol. This configuration applies to both FIPS and non-FIPS implementations. To perform the configuration, you specify settings for the truststore file and communication protocol in the user-factory.xml file. To enable this functionality, Tivoli Provisioning Manager provides an implementation of CustomSSLSocketFactory for secure communication to LDAP using TLS protocol and PKCS12 type keystore files.
91
To complete this task, your system must meet the following requirements: v You must have a Microsoft Active Directory certificate generated for LDAP. v The truststore file in PKCS12 format must be created. If you are not using PKCS12, you can also perform this configuration for a JKS truststore and a non-Transport Layer Security protocol environment, for example, SSL.
Procedure
1. Copy the com.ibm.tivoli.tpm.security.realm.CustomSSLSocketFactory.jar jar file from %TIO_HOME%\eclipse\plugins\com.ibm.tivoli.tpm.security.realm to %TIO_HOME%\lwi\lib 2. The user-factory.xml file contains new configuration settings that provide support for PKCS12. To complete the configuration, you modify these settings. The default location of the user-factory.xml file is %TIO_HOME%\config\user-factory.xml. The following table describes the configuration settings.
Table 13. Configuration settings for PKCS12 Configuration setting com.ibm.tivoli.tpm.security.realm.SSLTrustStore Description The truststore file location. Specify the absolute path of the PKCS 12 truststore file. The encrypted truststore password. The truststore type JKS or PKCS12. The SSL protocol, SSLv3 or TLS.
com.ibm.tivoli.tpm.security.realm.SSLTrustStorePassword com.ibm.tivoli.tpm.security.realm.SSLTrustStoreType com.ibm.tivoli.tpm.security.realm.SSLProtocol
Specify the following settings in the user-factory.xml file: a. The truststore file location, for example c:/testing/trustStore.p12. b. The encrypted truststore file password. c. The truststore type, PKCS12, or, if you are using JKS truststore, you can specify JKS. d. The SSL protocol, TLS, or, if you are using SSLv3 protocol, you can specify SSLv3. 3. Import the Microsoft Active Directory certificate into the truststore that is specified in the com.ibm.tivoli.tpm.security.realm.SSLTrustStore variable in the user-factory.xml file. 4. Restart Tivoli Provisioning Manager. The configuration settings that you specified are enabled when you restart Tivoli Provisioning Manager. Tivoli Provisioning Manager can now communicate with Microsoft Active Directory with a PKCS12 certificate using Transport Layer Security protocol. Note: If you are starting Tivoli Provisioning Manager and a message displays in the console.log and SystemOut.log log files that the CustomSSLSocketFactory class cannot be found, check if there is a com.ibm.tivoli.tpm.security.realm.CustomSSLSocketFactory.jar file in the %LWI_HOME%\lib directory. If not, contact IBM Support. Note: If you are running the soapcli.sh or soapcli.cmd command under %TIO_HOME%/soapclient/ tpmletSoap directory and if you are using a different keystore and truststore, see the instructions at Enabling SSL for TPM.
Example
A sample user-factory.xml file configured for PKCS12 using TLS protocol is as follows:
<ldapRegistry> <initial-context-factory>com.sun.jndi.ldap.LdapCtxFactory</initial-context-factory> <server>vm-tpm-s11.tpmserver.example.com</server> <ldap-port>389</ldap-port> <ldaps-port>636</ldaps-port> <ssl-for-binding>true</ssl-for-binding>
92
<baseDN>ou=users,ou=SWG,o=IBM,c=US</baseDN> <subtree /> <bindingUserName useDN="True">cn=root</bindingUserName> <bindingPassword>YrAjONjSjSPFV6KCj7o3iQ==</bindingPassword> <userSecurityName>uid</userSecurityName> <userUniqueId>dn</userUniqueId> <userDisplayNameAttr>cn</userDisplayNameAttr> <userFilter>(&(uid=%v)(objectclass=inetOrgPerson))</userFilter> <groupSecurityName>cn</groupSecurityName> <groupUniqueId>dn</groupUniqueId> <groupDisplayNameAttr>cn</groupDisplayNameAttr> <groupFilter>(&(cn=%v)(|(objectclass=groupOfURLs)(|(objectclass=groupOfNames) (objectclass=groupOfUniqueNames))))</groupFilter> <groupMember>ibm-allGroups</groupMember> <userMember>ibm-allMembers</userMember> <attributes> <name>cn</name> <first-name>fn</first-name> <last-name>sn</last-name> <home-phone>homeTelephoneNumber</home-phone> <business-phone>businessTelephoneNumber</business-phone> <mobile-phone>mobileTelephoneNumber</mobile-phone> <email>mail</email> <address>postalAddress</address> </attributes>  <com.ibm.tivoli.tpm.security.realm.SSLTrustStore> c:/testing/trustStore.p12 </com.ibm.tivoli.tpm.security.realm.SSLTrustStore> <com.ibm.tivoli.tpm.security.realm.SSLTrustStorePassword> YrAjONjSjSPFV6KCj7o3iQ== </com.ibm.tivoli.tpm.security.realm.SSLTrustStorePassword> <com.ibm.tivoli.tpm.security.realm.SSLTrustStoreType> pkcs12 </com.ibm.tivoli.tpm.security.realm.SSLTrustStoreType> <com.ibm.tivoli.tpm.security.realm.SSLProtocol> TLS </com.ibm.tivoli.tpm.security.realm.SSLProtocol> </ldapRegistry>
Enabling the Applications tab in the Security Group application

This topic provides reference information about enabling the Applications tab in the Security Group application in Tivoli Provisioning Manager. This tab is disabled by default in Tivoli Provisioning Manager version 7.2. Use this information to enable the Applications tab in your Tivoli Provisioning Manager Security Group application. The Applications tab is disabled in Tivoli Provisioning Manager version 7.2 to shift the responsibility for configuring permissions to UI resources to MAXADMIN users. The reason for this is that the Applications tab has access to configuring Tivoli Provisioning Manager UI and also the Tivoli Process Automation Engine native UI resources. If you need to re-enable the Applications tab in the Security Group application, complete the following steps:
Procedure
1. Log in to Tivoli Provisioning Manager as the MAXADMIN user. 2. Click Go To > Security > Security Group.
93
3. 4. 5. 6. 7.
Click the TPADMIN security group. Click the Applications tab. Use the filter to search for and select Security Group. Select the Grant Access option for the Delete Group signature option. Select the Grant Access option for the Read Global Data signature option.
8. Save your changes.
Results
Your have now enabled the Applications tab in the Security Group application.
Configuring failed login limits on the LDAP server

You can configure the LDAP server to block login access after a specific number of failed login attempts.
Procedure
v To configure Tivoli Directory Server: 1. Enable the administration password policy and modify the default settings by issuing the following command:
idsldapmodify -D cn=root -w password -i pwdPolicy.ldif
where pwdPolicy.ldif contains the following information:

dn: cn=pwdPolicy Admin,cn=Configuration changetype: modify replace: ibm-slapdConfigPwdPolicyOn ibm-slapdConfigPwdPolicyOn: true dn: cn=pwdpolicy,cn=ibmPolicies changetype: modify replace:ibm-pwdpolicy ibm-pwdpolicy: true replace: pwdlockout pwdlockout: TRUE #select TRUE to enable, FALSE to disable replace:pwdmaxfailure pwdmaxfailure: 3 # Maximum number of failures that will lockout the user replace:pwdfailurecountinterval pwdfailurecountinterval: 60 # Maximum number of failure should happen in this interval to lockout the user. It is in seconds. replace:pwdLockoutDuration pwdLockoutDuration: 0 # Value of pwdlockoutduration is in seconds. 0 means locked until reset by the administrator.
2. You must restart the Tivoli Provisioning Manager server for the changes to take effect. For more information see: ../com.ibm.tivoli.tpm.ins.doc/install/tlog_startserver_win.dita ../com.ibm.tivoli.tpm.ins.doc/install/tlog_startserver_ulx.dita v To configure Microsoft Active Directory, follow the instructions in "Apply or modify account lockout policy" help in the Microsoft documentation.
94
Results
After completing this procedure, if a user tries to log on using a wrong password more than three times he gets locked out of the system. To verify which users are locked from the system run the command:
ldapsearch -D cn=root -w password -b "dc=ibm,dc=com" -s sub "(pwdAccountLockedTime=*)"
Note: "dc=ibm,dc=com" might assume a different value. Issue the ldapsearch command to see this value. To unlock a user, run the command:
idsldapmodify -D cn=root -w password -i unlockAccount.ldif -k
Note: The unlockAccount.ldif file has the following content, assuming that the locked user is a tester:
dn:cn=tester,dc=ibm,dc=com changetype:modify replace: ibm-pwdAccountLocked ibm-pwdAccountLocked: FALSE
Preventing cross-site scripting

You can prevent cross-site scripting and SQL injection attacks. For information about how to prevent cross-site scripting and SQL injection attacks, see: http://www-01.ibm.com/support/docview.wss?rs=0&q1=maximo+cross+site&q2=filter &uid=swg21389946&loc=en_US&cs=utf-8&cc=us&lang=en
Configuring the Web browser to use a certificate

To trust the default Tivoli Provisioning Manager certificate, import the certificate to the Web browser. Instructions for the Microsoft Internet Explorer and the Mozilla Firefox Web browsers are provided.
Importing the certificate to Microsoft Internet Explorer 7

To trust the default Tivoli Provisioning Manager certificate in Internet Explorer 7, complete the following steps:
Procedure
1. Launch Tivoli Provisioning Manager. For example, https://<fully_qualified_domain_name>:9443/ maximo. 2. At the error message stating that the security certificate was not issued by a trusted certificate authority, click Continue to this website (not recommended) to be directed to the login screen. 3. On the security bar, click Certificate Error. 4. In the Untrusted Certificate window, click View certificates. 5. A message that the certificate cannot be verified is displayed. Click Install Certificate to launch the Certificate Import Wizard. 6. On the Welcome page, click Next. 7. On the Certificate Store panel, select Automatically select the certificate store based on the type of certificate. 8. To import the certificate, click Next and then click Finish. 9. A security warning will alert you that you are installing a certificate from your provisioning server, <fully_qualified_domain_name>. Click Yes to continue the installation. 10. When the installation completes, restart the Web browser. 11. Launch Tivoli Provisioning Manager. The login page will display without the certificate error now.
95
Importing the certificate to Mozilla Firefox

Procedure
1. Launch Tivoli Provisioning Manager. For example, https://<fully_qualified_domain_name>:9443/ maximo. An error is returned stating that the Web site is certified by an unknown authority. 2. Select Accept this certificate permanently. This will be the only time you will have to accept the certificate until the certificate expires.
Results
The certificate is now imported to the Web browser.
Changing passwords
Changing the Maximo user and database password
To change the Maximo user password and the database password, run the changePassword command, update the password on the operating system level, and then update the maximo.properties file.
Before you begin

Windows 2008 Select the Run as administrator option for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide.
Review the password restrictions and unsupported characters listed in the Installation Guide: Verify requirements for user names, database names, and user passwords To change the maximo user password and the database password, follow these steps:
Procedure
1. Stop the provisioning server. For more information, see the detailed documentation for the tio command 2. Start WebSphere Application Server. v
Windows
%TIO_HOME%\tools\tio.cmd start -w
UNIX Linux $TIO_HOME/tools/tio.sh start -w v 3. Run the changePassword command.
v v
%TIO_HOME%\tools\changePassword.cmd -c database -u wasadmin -p <wasadmin_password> -n <new_ maximo_password>

Windows
UNIX Linux $TIO_HOME/tools/changePassword.sh -c database -u wasadmin -p <wasadmin_password> -n <new_maximo_password> 4. Stop WebSphere Application Server.
Windows
%TIO_HOME%\tools\tio.cmd stop -w
UNIX Linux $TIO_HOME/tools/tio.sh stop -w v 5. Change the maximo password at the operating system level. 6. On the administrative workstation, update the maximo.properties file with the new maximo password. a. Back up the <Maximo_HOME>\applications\Maximo\properties\maximo.properties file. For example, save the maximo.properties file in another location on the administrative workstation. b. In the <Maximo_HOME>\applications\Maximo\properties\maximo.properties file, remove the encrypted value and mxe.encrypted=true. The encrypted value is at the end of the file. c. If the following line is included in the maximo.properties file, remove it:
96
mxe.crontask.donotrun=ALL
d. Add the following line to the maximo.properties file:

mxe.db.password=<new_maximo_password>.
e. To encrypt the maximo.properties file, run the encryptproperties command, located in MAXIMO_HOME\maximo\tools\maximo
Windows UNIX
encryptproperties.bat
encryptproperties.sh f. Open the new maximo.properties file and verify that it contains an encryption string at the end. For example:
mxe.rmi.port=0 mxe.crontask.donotrun=ALL mxe.report.birt.disablequeuemanager=1 mxe.db.driver=com.ibm.db2.jcc.DB2Driver mxe.db.schemaowner=maximo mxe.name=MXServer mxe.db.url=jdbc:db2://vm-tpm-s126.tpmserver.example.com:50005/MAXDB71 mxe.registry.port=13400 mxe.db.user=maximo mxe.encrypted=true <81>3<82>g^CAc^KPAo^?<89><86>_A"Ac<8a><8c>^Bu^SA^O^G[g^FWA9AA ^D}<9a>9Y{ASA< TA-^R<88> ~
7. Change the maximo.properties file on the provisioning server: a. Copy the new maximo.properties file from the Administrative Workstation to the following folders on the provisioning server:
%TIO_HOME/lwi/runtime/tpm/eclipse/plugins/tpm_pmp/properties %TIO_HOME/eclipse/plugins/tpm_pmp/properties
b. Change the directory.

cd %WAS_HOME/profiles/ctgAppSrv01/installedApps/ctgCell01/MAXIMO.ear
c. Create a temporary directory, for example, temp and then change to that directory: cd temp d. Run the following command copy the maximo.properties file with the modified encrypted password to the temp directory, replacing the original one:
JAVA_HOME\bin\jar -xvf WAS_HOME\profiles\ctgAppSrv01\installedApps\ctgCell01\Maximo.ear\properties.jar .
e. Run the following command to repackage the properties.jar file with the updated password in the maximo.properties file. After the command has run, you can delete the temp directory and its contents.
JAVA_HOME\bin\jar -cvf WAS_HOME\profiles\ctgAppSrv01\installedApps\ctgCell01\Maximo.ear\properties.jar .
f. Depending on your platform, navigate to %TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\tpm_pmp\ properties or $TIO_HOME/lwi/runtime/tpm/eclipse/plugins/tpm_pmp/properties and ensure that the following lines are included and have the correct values:
mxe.crontask.donotrun=ALL mxe.report.birt.disablequeuemanager=1 mxe.rmi.enabled=0
8. Start the provisioning server. v

Windows
%TIO_HOME%\tools\tio.cmd start -t
UNIX Linux $TIO_HOME/tools/tio.sh start -t v 9. Log into the provisioning Web interface using the new maximo password.
Results
The maximo user password and database password is changed.
97
Note: To verify that the user is changed after this procedure, start Tivoli Provisioning Manager and look for following message in <WAS_INSTALL>\profiles\ctgAppSrv01\logs\MXServer\SystemOut.log. If that message is present it verifies the database connection.
BMXAA6451I BMXAA6385I BMXAA6388I BMXAA6389I BMXAA6390I BMXAA6391I Connection BMXAA6453I - The database manager is psdi.server.DBManager@43164316 - Connecting to the database at: jdbc:db2://vm-tpm-s122.tpmserver.example.com:50005/maxdb71 - Database product: DB2/NT - Database product version: SQL09053 -- 9.5 - Database driver: IBM DB2 JDBC Universal Driver Architecture - Database driver version: 3.53.70 pool initialized with 8 free connections. - The server is connecting to database version: V7115-149
Changing the wasadmin user password

To change the password, use the changePassword tool and then change the wasadmin password in the LDAP server.
Before you begin

Windows 2008 Select the Run as administrator option for all of the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide.
Procedure
1. Stop the provisioning server. v v
Windows UNIX
%TIO_HOME%\tools\tio.cmd stop
Linux
$TIO_HOME/tools/tio.sh stop
For more information , see the detailed documentation for the tio command 2. Start WebSphere Application Server. v
Windows
%TIO_HOME%\tools\tio.cmd start -w
UNIX Linux $TIO_HOME/tools/tio.sh start -w v 3. Run the changePassword tool.
v v
Windows %TIO_HOME%\tools\changePassword.cmd -c wasadmin -u wasadmin -p <wasadmin_password> -n <new_password>
$TIO_HOME/tools/changePassword.sh -c wasadmin -u wasadmin -p <wasadmin_password> -n <new_password>

UNIX Linux Windows
4. Stop WebSphere Application Server. v %TIO_HOME%\tools\tio.cmd stop -w
UNIX Linux $TIO_HOME/tools/tio.sh stop -w v 5. Change the wasadmin password in the LDAP server. 6. Start the provisioning server.
Windows
%TIO_HOME%\tools\tio.cmd start -t
UNIX Linux $TIO_HOME/tools/tio.sh start -t v 7. Verify that the password works by logging on to the WebSphere Application Server Administrative Console: http://<host_name>:9060/admin
Results
The wasadmin password is now changed.
98
Configuring form base authentication

This topic describes how to configure form base login for Tivoli Provisioning Manager. The predefined Tivoli Provisioning Manager installation configures the authentication service for basic authentication. With the basic authentication service, a pop-up window prompts users for their user name and password. You can change this to login form authentication. To configure your Tivoli Provisioning Manager installation for form base authentication, you modify settings in the web.xml file on the administrative workstation. Then you build and redeploy the Maximo EAR file. For information about the operating systems that are supported for the administrative workstation, see Multiserver deployment. Complete the following steps to change the base authentication to form base authentication:
Procedure
1. Back up the master copy of the web.xml file located in the administration workstation SMP location. On Windows, back up the web.xml file located in C:\ibm\SMP\maximo\applications\maximo\ maximouiweb\webmodule\WEB-INF directory. On UNIX platforms, the web.xml file is located in the %WAS_HOME%/profiles/ctgAppSrv01/installedApps/ctgCell01/MAXIMO.ear/maximouiweb.war/WEBINF directory. 2. Open the web.xml file, and comment out the following configuration that specifies the BASIC authentication method:
<login-config> <auth-method>BASIC</auth-method> <realm-name>MAXIMO Web Application Realm</realm-name> </login-config>
3. Uncomment the following configuration that defines the FORM base authentication:
<login-config> <auth-method>FORM</auth-method> <realm-name>MAXIMO Web Application Realm</realm-name> <form-login-config> <form-login-page> /webclient/login/login.jsp?appservauth=true</form-login-page> <form-error-page>/webclient/login/loginerror.jsp</form-error-page> </form-login-config> </login-config>
4. Save the web.xml file. 5. Rebuild the Maximo EAR file on the administrative workstation to invoke the changes. To rebuild the Maximo EAR, run one of the following scripts, depending on your platform: a. On Windows systems, run the buildmaximoear script, located in the C:\Maximo\deployment directory on the administrative workstation. b. On UNIX systems, run the buildmaximoear.sh script, located in the /opt/IBM/SMP/maximo/ deployment directory on the administrative workstation. 6. Deploy the Maximo EAR to WebSphere Application Server. You can deploy the Maximo EAR using WebSphere Application Server or you can use the command line. To view command line instructions about how to deploy the Maximo EAR file, see Manually deploying the EAR file. To deploy the Maximo EAR on WebSphere Application Server, complete a process similar to the following example on WebSphere Application Server v6.1.0.29: a. Log on to WebSphere Application Server. b. Click Applications, then Enterprise Applications. c. Uninstall the previous Maximo EAR before you begin redeploying the new one because updating the existing Maximo EAR can cause caching issues. d. Click Install. e. If WebSphere Application Server is on the administrative workstation, navigate to the location of the Maximo EAR by clicking Local File System. If you do not have direct access to the
99
administrative workstation on which the Maximo EAR is located, click Remote File System and navigate to the Maximo EAR location, for example on Windows C:\ibm\SMP\maximo\deployment\ default, and click the file. f. Click OK, then click Next. g. On the Select installation options screen, make sure that the Maximo installation is selected. If there are multiple Maximo installations on your WebSphere Application Server environment, click the specific application name for the installation. Then click Next. h. On the Map modules to servers screen, select the web server and application server in the Clusters and Servers box, select all of the modules, then click Apply. i. Click Next. j. On the Map virtual hosts for Web modules screen, click the options for your installation and change the Virtual host options to the host you have set up for the Maximo application. Click Next. k. On the Summary page, review the summary and click Finish. l. After the Maximo EAR file has installed, click Save to save your changes. The Maximo EAR is now deployed to the server. m. Go to the WAS console and from the navigation tree, click Applications > Enterprise Applications. Then click MAXIMO > Class loading and update detection. For WAR class Loader Policy, the Class loader for each WAR file in application option is selected by default. Click the Single class loader for application option. Click Save to save your changes. n. Restart Tivoli Provisioning Manager. If you have problems logging into Tivoli Provisioning Manager after rebuilding the Maximo EAR, see https://www-304.ibm.com/support/ docview.wss?uid=swg21321974 for information about how to resolve the issue.
Results
You have now changed the authentication to form base login. You can access the Tivoli Provisioning Manager system using the same URL where a login form is used instead of basic authentication.
Importing a certificate for the provisioning Web interface

After you install Tivoli Provisioning Manager, you can import a certificate to WebSphere Application Server that is issued by a well-known certificate authority. This is an optional task, but using certificate from a trusted certificate authority is more secure than using the self-signed certificate that was configured during the installation. To import a certificate into the WebSphere Application Server environment for the provisioning Web interface, complete the following tasks on WebSphere Application Server.
Identify the virtual host of the provisioning Web interface

Procedure
1. Log into the WebSphere Application Server administrative console. 2. Click Applications > Enterprise Applications and select the Maximo application. 3. Click Virtual Hosts. 4. Look for the MAXIMO Web Application. Ensure that the default value is maximo_host.
Specify the port for the provisioning Web interface

Procedure
1. Click Environment > Virtual Hosts. 2. Select the maximo_host virtual host. 3. In the Port column, click Host Aliases. Ensure that the default value of the port for the virtual host is 9443.
100
Verify the SSL profile for the port

Procedure
1. Click Servers > Application Servers. 2. Click MXServer > Ports. Find the port for the virtual host, 9443. 3. Click View associated transports. In the list of transport chains, WCInboundDefaultSecure should be listed by default. 4. Select the WCInboundDefaultSecure transport. Ensure that under SSL inbound channel (SSL 2), the SSL configuration with a default value of TpmSSLProfile is listed.
Importing the certificate

Verify the keystore and truststore for the SSL provisioning profile and then import the certificate into the keystore
Procedure
1. Click Security > SSL certificate and key management. 2. Select Manage endpoint security configurations. 3. Under Inbound > nodes, open the node called ctgNode01(NodeDefaultSSLSettings, null). 4. Open Servers and select MXServer. 5. Click SSL configuration. In the list of SSL profiles, find the TpmSSLProfile. The displayed page contains information about the truststore and keystore. The default values are TpmTrustStore and TpmKeyStore, respectively. 6. Select Keystores and certificates to find the location of the keystore. Find the TpmKeyStore and note the location. 7. To import a certificate with the keytool, run the following command:
keytool v import v alias <cert_alias> -keystore <keystore_location> -storepass <keystore_ password> -file <cert_file_location>
where cert_alias is the name of the certificate. keystore_location is the location of the TpmKeyStore. keystore_ password is the password of the keystore. cert_file_location is the location of the certificate. Note: This step is based on importing the certificate with the keytool that is provided as part of the JDK. Interfaces may be different, depending on what tool is used. For more information about using the keytool, type keytool, without any parameters, to display the Help feature.
Setting the default certificate to be sent to the Web client

After a certificate is imported into the keystore, configure it to use that specific certificate for the server SSL communication.
Procedure
1. Click Security > SSL certificate and key management. 2. Click Manage endpoint security configurations. 3. Expand the inbound nodes in the Local Topology window. Open the node called ctgNode01(NodeDefaultSSLSettings, null)). Open Servers and select MXServer. 4. To display the SSL profiles, click SSL configuration. Find the TpmSSLProfile. 5. Click get certificate aliases. Under Default server certificate alias, select the certificate alias that was imported.
101
6. Click OKSave. 7. Start the provisioning server again.
Managing users and security groups

This topic provides reference information about the user and security group management. Tivoli Provisioning Manager provides a set of predefined users and security groups that can be easily applied to your environment. However, new users and groups can be created and the existing ones modified. Read about the way you can manage the users and security groups at all times and on a temporarily basis.
Operations on users and security groups can be divided on the basis of the duration of their effects. They can be either done at all times or to last temporarily.
Managing users and security groups at all times

You can manage security in Tivoli Provisioning Manager by performing operations in LDAP on which the user and security group data is stored. For this purpose, use an LDAP script or any LDAP management tool such as WebSphere Administrative Console 6.1. You need to be an LDAP administrator to perform the regular management functions such as creating, updating, or removing a user or security group in LDAP. The changes you introduce are regularly synchronized into Tivoli Provisioning Manager system by the VMMSYNC cron task. Depending on the amount of data modified in LDAP: v Changes to a corporate LDAP generally have to go through the corporation change management process. The time it takes to implement the changes made to the corporate LDAP varies a lot between different corporations. v It takes minutes to synchronize data between LDAP and the Tivoli Provisioning Manager database. Data is synchronized by the VMMSYNC cron task. If you delete users or security groups on the LDAP directory server, these users or security groups are not deleted in the database. This restriction serves audit purposes and various industry regulations.
Managing users and security groups temporarily

The changes introduced to user and security group data in LDAP are synchronized on a regular basis by the VMMSYNC cron task. Nevertheless, temporary changes to Tivoli Provisioning Manager system can be introduced for the duration of the intermittent time between running of the task. They can be introduced locally for a given period and then overwritten with data from LDAP by the scheduled cron task. To set the time period, you must stop the scheduled VMMSYNC cron task from running at that time. In this example, the Tivoli Provisioning Manager administrator wants to grant a user temporary access to assets that on a regular basis are defined for a different security group. To change the user group affiliation temporarily: 1. Log on to the Tivoli Provisioning Manager system as MAXADMIN. 2. Stop the VMMSYNC cron task by going to GoTo > System Configuration > Platform Configuration > Cron Task Setup, and searching for VMMSYNC in the Cron Task field. Go to the given Cron Task tab, clear the Active option, and save the settings. 3. Alter the Tivoli Provisioning Manager administrator, TPADMIN, access rights so that the user can modify the membership information for the security group you want to assign: a. Click the GoTo > Security > Security Groups, and type in the name of the group that you want to assign the user to.
102
4. 5. 6. 7. 8.
b. Go to the Group tab of the selected group, and from the Select Action select the Authorize Group Reassignment option. c. Click Select Users, choose the TPADMIN from the list, and click OK. Confirm by clicking OK again. Log on again to Tivoli Provisioning Manager system, this time as TPADMIN. GoTo > Security > Security Groups. In the Group field type in the name of the group you want to add the user to, and search for it. Go to Users tab, and click Select Users. Choose the user for whom you want to add the new privilege, and click OK. to save the new settings.
9. Click
You have now temporarily added new privileges to a user of your choice. The change will be overwritten with the information from LDAP as soon as the next VMMSYNC cron task will be run.
Configuring SSL communication for Tivoli Provisioning Manager and DB2 9.5
To deploy a system that is fully FIPS (Federal Information Processing Standard) enabled, you require a FIPS-compliant secure socket layer (SSL) configuration between Tivoli Provisioning Manager and DB2. To set up a FIPS-compliant SSL configuration between Tivoli Provisioning Manager and DB2, you must perform a number of configuration tasks, each of which is described in detail in the following sections.
Task 1 Upgrading the JDBC version

With FIPS enabled, the JDBC version included with Tivoli Provisioning Manager 7.2 does not function correctly when SSL is used for communication between Tivoli Provisioning Manager and DB2. To avoid this issue, upgrade your JDBC version. Complete the following steps to upgrade the version of JDBC that was installed with Tivoli Provisioning Manager:
Procedure
1. Go to http://www-01.ibm.com/support/docview.wss?rs=71&uid=swg21363866. 2. Search for and download the v9.5 FP6 DB2 level (3.59.81 JDBC driver version). 3. Install the 3.59.81 version of the JDBC driver in the locations described here: a. Log on to WebSphere Application Server. b. Click Environment > WebSphere Variables > DB2_JDBC_DRIVER_PATH. There might be two entries for DB2_JDBC_DRIVER_PATH. Search for the one at ctgNode01, that is, Node=ctgNode01. c. Note the value of DB2_JDBC_DRIVER_PATH variable. d. Stop Tivoli Provisioning Manager. e. Replace the db2jcc.jar file with the 3.59.81 version of the JDBC driver that you downloaded, at the location specified in the DB2_JDBC_DRIVER_PATH variable. f. Replace the JDBC driver in the %TIO_HOME%/lwi/runtime/tpm/eclipse/plugins/tpm_pmp/maximoLibs directory with the new JDBC driver that you downloaded. g. Start Tivoli Provisioning Manager.
Results
You have upgraded your version of JDBC. Now proceed to configure DB2 for SSL.
103
Task 2 Configuring SSL for DB2

DB2 supports the SSL communication protocol and opens a port exclusively for SSL communication. This task is for DB2 installed in a Windows environment.
Procedure
1. The GSKit is a set of programmable interfaces that allows applications to be SSL enabled. You need a GSKit for SSL communication for DB2. DB2 uses gsk7 to provide SSL support and requires the libraries on the system path. iKeyman, which is used to manage truststore files, keystore files, and certificates, is part of the GSKit installed with Tivoli Provisioning Manager. It is available in the following location:
C:\program Files\IBM\gsk7\bin\gsk7ikm.exe
There is also a copy of iKeyman, bundled with DB2, available in the following location:
<DB2_INSTALL_PATH>\SQLLIB\java\jdk\jre\bin\ikeyman.exe
v Use the following link for general information about the GSKit http://www-01.ibm.com/support/ docview.wss?rs=71&context=SSEPGG&dc=DA400&uid=swg21249656&loc=en_US&cs=UTF-8 &lang=en&rss=ct71db2. v To get the DB2 security plug-ins required for SSL support, download them from https://www14.software.ibm.com/webapp/iwm/web/reg/pick.do?lang=en_US&source=swg-dmdb2ldap&S_TACT=swg-dm-db2ldap. 2. After you have installed the GSKit, set the environment variables. You need to be logged in as an administration user, for example tioadmin, to complete this step. Click Start > Run and enter sysdm.cpl to launch the System Properties. Click Advanced > Environment Variables. In the System variables list, create the environment variables listed in the following table, if necessary, and set them to the values provided.
Table 14. Environment variable settings Variable JAVA_HOME PATH CLASSPATH LIB Variable value C:\Program Files\IBM\SQLLIB\java\jdk\jre; Note: Use the JDK path for the JRE installed with DB2. C:\Program Files\IBM\gsk7\lib;%PATH%; C:\Program Files\IBM\gsk7\classes\cfwk.zip;C:\Program Files\IBM\gsk7\classes\ gsk7cls.jar;%CLASSPATH%; C:\Program Files\IBM\gsk7\lib;C:\PROGRA~1\IBM\SQLLIB\LIB;%LIB%
Note: If you are using a 64-bit platform, you need to need to set your environment variables and reference the GSKit utilities relative to the GSK7_64 installed directory. 3. Create a server keystore file and certificate. DB2 SSL configuration requires a CMS-type keystore and a certificate for SSL communication. Use iKeyman to create a CMS keystore, as follows: a. Run C:\Program Files\IBM\gsk7\bin> gsk7ikm.exe. b. Create a new Key Database file, key.kdb of type CMS. Provide a password and make a note of this password. c. Create a new self-signed certificate, define the key label (it can be anything, such as SSLLabel), and provide the organization name. For the version, specify X509-V3 and 1024 for the key size. The other items are optional. d. Click OK. The new certificate is displayed in the menu. e. Click the certificate and click View/Edit from the right pane. Make sure that Set the Certificate as the Default is selected.
104
f. Click the certificate (for example, SSLLabel) and click Extract Certificate. In the Extract a certificate to a File dialog that opens, select Base64-encoded ASCII data from the Data type drop-down list. You can use the default name, cert.arm. g. Click OK. 4. Configure the DB2 environment, as follows: a. In the command window, run the following command:
set db2instance=ctginst1
b. The DB2COMM registry variable sets communication protocols for the current DB2 instance. If the DB2COMM registry variable is undefined or set to null, no protocol connection managers are started when the database manager is started. Set the DB2COMM registry variable using the following command:
db2set DB2COMM=SSL,TCPIP
c. If it does not exist, create the SSLconfig.ini file in the C:\Documents and Settings\All_Users\ Application Data\IBM\DB2\DB2COPY1\ctginst1 directory. Modify the path, port, and password as required. Include the following data with values similar to those provided:
DB2_SSL_KEYSTORE_FILE= (the location of the key.kdb created in the previous step) DB2_SSL_LISTENER=30171 (check the services file for an unassigned port number C:\WINDOWS\system32\drivers\etc\services file) DB2_SSL_KEYSTORE_PW=xxxxxx (the password provided when creating the key.kdb) DB2_SSL_KEYSTORE_LABEL=SSLLabel (the key label specified for the self-signed certificate)
d. Increase the security on the SSLconfig.ini file by modifying the security permissions for the db2admin user, as follows: 1) Right click the SSLconfig.ini file in Windows and click Properties. 2) Click the Security tab. 3) Click Add to add security permissions for the db2admin user and no other user. 4) Set the following permissions on the SSLconfig.ini file for the db2admin user: v Check the Full Control option. v Check the Modify option. v Check the Read and Execute option. v Check the Read option. v Check the Write option. 5) Save the permissions changes for the SSLconfig.ini file. e. Check that there are no instances connected to the database and then stop and start DB2 using db2stop and db2start commands from the command window. Check that DB2 starts without any errors. If the following message is displayed after you start DB2, check the db2diag.log file:
10/30/2007 16:19:15 0 0 SQL5043N Support for one or more communications protocols failed to start successfully. However, core database manager functionality started successfully. SQL1063N DB2START processing was successful.
For more information about this error in the db2diag.log file, see the following document http://www.redbooks.ibm.com/redbooks/pdfs/sg247555.pdf. f. If the following error is displayed after you start DB2, reboot the server:
CTGINST1-0 : The service has returned a service-specific error code. 09/24/2010 23:27:56 0 0 SQL1042C An unexpected system error occurred. SQL1032N No start database manager command was issued. SQLSTATE=57019
5. A signer certificate is the trusted certificate entry that is normally in a truststore file. Import the signer certificate for the database into the WebSphere Application Server truststore file: a. Copy the cert.arm file that you exported in the previous step to WebSphere Application Server. b. Log on to the admin console, http://hostname:9060/admin. c. Click Security -> SSL certificate and key management, then click the Key stores and certificates link under the Related items.
105
d. Click CellDefaultTrustStore. A path to the truststore file is displayed. If you want to use a different tool to import the certificate into the truststore file, note the location of the truststore file. Otherwise, complete the following steps to import the signer certificate using the WebSphere Application Server interface. e. Click Signer certificates. f. Click Retrieve from port, enter the host name of the DB2 server, the SSL port number (for example, 30171), and the alias of the certificate that you are importing (for example, SSLLabel). g. Click Retrieve signer information and click OK to import the certificate. If you see any error messages, make sure that the entries you made in the SSLConfig.ini file are correct and that there are no syntax errors. 6. Import the signer certificate into the Common Agent Services web component: a. Log on to the admin console, http://hostname:21001/admin b. Go to Security -> SSL certificate and key management, click the Key stores and certificates link under the Related items. c. Click NodeDefaultTrustStore. The path to the truststore file is displayed. If you want to use a different tool to import the certificate into the truststore, make a note of the location of the truststore file from this page. Otherwise, complete the following steps to import the signer certificate using the WebSphere Application Server interface. d. Click Signer certificates. e. Click Retrieve from port, enter the host name of the DB2 server, the SSL port number (for example, 30171), and the alias of the certificate to be imported (for example, SSLLabel). f. Click Retrieve signer information, click OK to import the certificate.
Results
You have configured DB2 for SSL. Now proceed to configure the deployment engine for SSL DB2 connection.
Task 3 Configuring MXServer for SSL DB2 communication

To configure Tivoli Provisioning Manager 7.2 to use SSL communication with DB2, you must configure the MXServer to initiate SSL database communications. Complete the following steps:
Procedure
1. Make sure that the location of your truststore file exists, then update the maximo.properties file by replacing the following line:
mxe.db.url=jdbc:db2://<db2-server>:50005/MAXDB71
With this line. All of this text should be on a single line.

mxe.db.url=jdbc:db2://<db2-server>:<30171>/MAXDB71:sslConnection=true; sslTrustStoreLocation=c:/keystores/DeploymentEngine/detruststore.p12;sslTrustStorePassword=password;
For example:
mxe.db.url=jdbc:db2://vip-tpm-s73.tpmserver.example.com:<30171>/maxdb71:sslConnection=true; sslTrustStoreLocation=c:/keystores/DeploymentEngine/detruststore.p12;sslTrustStorePassword=password;
You must update the maximo.properties file with this change in the following two locations: v %TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\tpm_pmp\properties\ v %TIO_HOME%\eclipse\plugins\tpm_pmp\properties\ 2. Increase the security on the maximo.properties file by modifying the security permissions for the tioadmin user, as follows: a. Right click the maximo.properties file in Windows and click Properties. b. Click the Security tab.
106
c. Click Add to add security permissions for the tioadmin user and no other user. d. Set the following permissions on the maximo.properties file for the tioadmin user: v Check the Full Control option. v Check the Modify option. v Check the Read and Execute option. v Check the Read option. v Check the Write option. e. Save the permissions changes for the maximo.properties file. 3. Restart Tivoli Provisioning Manager.
Results
You have configured MXServer for SSL DB2 communication. Now proceed to configure the CDS data source in WebSphere Application Server.
Task 4 Configuring the CDS data source in WebSphere Application Server

You must configure the CDS data source in WebSphere Application Server. Complete the following steps to configure the CDS data source in WebSphere Application Server:
Procedure
1. Log on to http://<tpm-hostname>:9060/admin as wasadmin. 2. Click Resources > JDBC > Data Sources and click CDSDataSource. 3. Change the port number for the SSL port being configured in the SSLconfig.ini, port number 30171 in this example. 4. Click Apply to apply the change of port number. 5. Click Custom properties, click New to create the sslConnection property with the following values: v Name: sslConnection v Value: true v Type: java.lang.Boolean 6. Click OK to add the new variable. 7. Click CDSDataSource to return to the CDSDataSource data source panel. 8. Click Test connection. The following error might be displayed:
Changes have been made to the node, <nodename>, which have not been synchronized. You must synchronize these changes to the master configuration before performing this action.
a. Click the synchronize link to synchronize the changes in the node level with the master configuration. b. Check the Synchronize changes with Nodes. c. Click Save, then OK. d. Click CDSDataSource to return to the CDSDataSource data source panel. e. Click Test connection. The following message displays if the connection is successful:
The test connection operation for data source CDSDataSource on server MXServer at node <nodename> was successful.
Results
You have configured the CDS data source in WebSphere Application Server. Now proceed to configure the Agent Manager
107
Task 5 Configuring the Agent Manager

You must configure the Agent Manager in WebSphere Application Server. Complete the following steps to configure the agent manager:
Procedure
1. Log on to http://<tpm-hostname>:21001/admin as wasadmin. 2. Click Resources > JDBC > Data sources and click AgentRegistry. 3. Change the port number to the SSL port being configured in the SSLconfig.ini file, 30171 in this example. 4. Click Apply to apply the port number change. 5. Click the Custom properties, then click New to create the sslConnection property with the following values: v Name: sslConnection v Value: true v Type: java.lang.Boolean 6. Click OK to add the new variable. 7. Click AgentRegistry to go back to the AgentRegistry data source panel. 8. Click Test connection. The following error message might be displayed:
Changes have been made to the node, <nodename>, which have not been synchronized. You must synchronize these changes to the master configuration before performing this action.
a. Click the synchronize link to synchronize the changes in the node level to the master configuration. b. Check the Synchronize changes with Nodes. c. Click Save, then OK. d. Click AgentRegistry to return to the AgentRegistry data source panel. e. Click Test connection. The following message is displayed if the connection is successful:
The test connection operation for data source AgentRegistry on server server1 at node <nodename> was successful.
9. Restart Tivoli Provisioning Manager.
Results
You have configured the Agent Manager. Now proceed to configure DMS for SSL DB2 connection.
Task 6 Configuring the device manager service for SSL DB2 connection
You must configure the device manager service for a secure socket layer DB2 connection. You must modify the Transaction.properties file and specify the clear text password.
Procedure
1. Open the Transaction.properties file:
WAS_HOME\profiles\ctgAppSrv01\installedApps\ctgCell01\DMS_WebApp.ear\dmserver.war \WEB-INF\classes
2. In the Transaction.properties file, replace:

JDBC.dbConnect=jdbc\:db2\://db-server-hostname\:50005/MAXDB71\:currentSchema\=MAXIMO
with:
JDBC.dbConnect=jdbc\:db2\://db-server-hostname\:30171/MAXDB71\:currentSchema\=MAXIMO; sslConnection\=true;sslTrustStoreLocation\=c\:/keystores/DeploymentEngine /detruststore.pkcs;sslTrustStorePassword\=password;
108
where, sslConnection The setting to notify Java Database Connectivity to use the secure socket layer to communicate to the database. sslTrustStoreLocation The location of the truststore containing the certificate of the DB2 server for the secure socket layer communication. sslTrustPassword The clear text password for the truststore. 3. To encrypt the sslTrustStorePassword value: v Install Tivoli Provisioning Manager 7.1.1-IF00007; or v Run Tivoli Provisioning Manager change password script with old database password. To set the new password:
dmsetpw -new new_password -db -user WASusername -password WASpassword
where, new_password Specifies the new password for the database user or the WebSphere Portal Server user. db Identifies if the password is changing for the database user.
user WASusername Identifies the WebSphere Application Server user name for the WebSphere Application Server user name. password WASpassword Identifies the WebSphere Application Server password for the WebSphere Application Server user name. 4. Restart Tivoli Provisioning Manager.
Results
You have configured the device manager service for SSL DB2 connection. Now proceed to configure dcm.xml for SSL DB2 connection.
Task 7 Configuring dcm.xml for SSL DB2 connection

Tivoli Provisioning Manager contains a configuration file called dcm.xml. The dcm.xml file contains DB2 connection information. The information is used for installing Tivoli Provisioning Manager and is used for the dcmexport.cmd tool. The dcm.xml file is not used at run time. You can configure the dcm.xml file for SSL communication. To configure the Tivoli Provisioning Manager dcm.xml file for SSL communication, complete the following steps:
Procedure
1. Open the %TIO_HOME%/config/dcm.xml file in a text editor. 2. In the URL, update the port number with the SSL port number. In this example, the SSL port number is 30171, so replace:
<url>jdbc:db2://<db-hostname>:50005/MAXDB71</url>
with:
<url>jdbc:db2://<db-hostname>:30171/MAXDB71</url>
3. Create a truststore file and import the DB2 certificate into the truststore file. You can create the truststore file using IKEYMan. The truststore file that you create must be the same type specified in
109
the keystore.type property in the %WAS_HOME%/java/jre/lib/security/java.security file. Note that when FIPS is enabled, the keystore.type is set to pkcs12 as follows:
keystore.type=pkcs12
4. To encrypt the password of the truststore file, run the encrypt.cmd from the %TIO_HOME%/tools directory. 5. Add the following new settings to the dcm.xml file to enable SSL:
<SSL-enabled>true</SSL-enabled> <trustStore>location of the truststore</trustStore> <trustStorePassword>UAFmTeSxKPmERDmQdQlNOg==</trustStorePassword>
A sample dcm.xml file is as follows:

<config> <database> <classpath> <pathelement location="C:/Program Files/IBM/SQLLIB/java/db2jcc.jar" /> <pathelement location="C:/Program Files/IBM/SQLLIB/java/db2jcc_license_cu.jar" /> </classpath> <type>db2jcc</type> <url>jdbc:db2://vip-tpm-s73.tpmserver.example.com:30171/MAXDB71</url> <name>MAXDB71</name> <schema>maximo</schema> <username>maximo</username> <password>dGCHjPgz0AiERDmQdQlNOg==</password> <appcommitenabled>true</appcommitenabled> <SSL-enabled>true</SSL-enabled> <trustStore>c:/keystores/DeploymentEngine/dcmtruststore.p12</trustStore> <trustStorePassword>UAFmTeSxKPmERDmQdQlNOg==</trustStorePassword> </database> </config>
Results
You have configured dcm.xml for SSL DB2. Now you can configure SSL-only communication.
Task 8 Configuring SSL-only configuration

You have already configured the DB2COMM registry variable for both TCP/IP and SSL communication in a previous task. If you have completed all of the configuration tasks described in this document and if you can start Tivoli Provisioning Manager without any errors, you can now configure SSL-only communication in DB2. To do this, you change the DB2COMM registry variable to specify SSL only. Complete the following steps to set the DB2COMM registry variable to SSL.
Procedure
1. Log on to DB2. 2. Set the DB2COMM registry variable using the following command:
db2set DB2COMM=SSL
3. Ensure that Tivoli Provisioning Manager is stopped. 4. Restart DB2. 5. Start Tivoli Provisioning Manager.
Results
You have now configured Tivoli Provisioning Manager to communicate with DB2 using the secure socket layer protocol.
110
Task 9 Configuring remote SSL for DB2 client (optional)

Tivoli Provisioning Manager does not require a DB2 client to connect to a remote DB2 database. Tivoli Provisioning Manager uses JDBC driver 4. If you are using JDBC driver version 4, you do not need to complete this configuration as Tivoli Provisioning Manager. If you want to connect to the remote SSL DB2 database, you can configure your system to connect to a remote SSL DB2 database. This is an optional task. You do not need to complete this task if you are using JDBC driver 4. If you want, you can configure your system to connect to a remote SSL DB2 database. To configure your system to connect to a remote SSL DB2 database, follow the instructions at http://publib.boulder.ibm.com/ infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/t0053518.htm. Note that the DB2 client in this scenario is the Tivoli Provisioning Manager server.
Auditing changes
Electronic signatures, audit records, and login tracking provide an additional level of security control and auditing capability. You can enable electronic signatures, login tracking, and audit records for Tivoli Provisioning Manager. Enabling these features provides you with greater tracking ability. Login tracking Login tracking controls the number of login attempts allowed and displays the current login status of the user. Information about how to enable login tracking is available in the Maximo online help. You can access this information by completing the following steps in Tivoli Provisioning Manager: 1. Click Go To > Security > Security Group. 2. Click Help and then Help. 3. Go to Overview > About Login Tracking. Note: When user accounts are managed on an LDAP server, you must configure the LDAP server to enforce limits on maximum login attempts and block login access if users exceed the limit. For more information, see Configuring failed login limits on the LDAP server on page 94. Electronic signatures Electronic signatures ensure that the individual saving or changing a record or accessing a specific action is the same individual who is logged in. When this feature is enabled and users try to save a change to a field, they must authenticate before they can continue. Information about how to enable electronic signatures is available in the Maximo online help. Electronic audit records Electronic audit records provide an audit trail by tracking changes on the records. Each time users add, delete, or modify the value of an attribute and save the change, an audit record is written to the audit object corresponding to the regular database object. Information about how to enable auditing and electronic signatures is available in the Maximo online help. You can access this information by completing the following steps in Tivoli Provisioning Manager: 1. Click Go To > System Configuration > Platform Configuration > Database Configuration. 2. Click Help and then Help. 3. Go to How Do I > Enable Electronic Signatures and Electronic Audit Records. Note: For information about configuring the database for the audit table creation in the Maximo online help, see the Database Configuration section in System Administrator's Guide.
111
Note: If you configured the database using Admin mode, you must restart Tivoli Provisioning Manager for the changes to take effect. For more information, see Starting and stopping the provisioning server on Windows or Starting or stopping the provisioning server on UNIX or Linux, depending on your platform. When you search for tables on which to enable audit, some tables are view-only. If you search for part of the table name using the Filter or Find field, the table might not display in the search results. Use the full table name in the Find filter field when you search for a provisioning table to audit. The following table lists some of the important provisioning applications tables.
Table 15. Table names Table name SOFTWARE_RESOURCE RESOURCE SOFTWARE_MODULE HOST_PLATFORM SERVER Table name to use for searches TP_SOFTWARERESOURCE TP_RESOURCE TP_SOFTWAREMODULE TP_HOSTPLATFORM TP_SERVER
On DB2 only, you can fix long audit columns after you configure the database in Maximo: 1. Log on to the provisioning server as tioadmin. 2. Run the following command: v Windows: %TIO_HOME%\migration\scripts\FixLongAuditColumn.cmd v UNIX or Linux: $TIO_HOME/migration/scripts/FixLongAuditColumn.sh After you run this command, a log file is available in $TIO_LOGS/migration/fixLongAuditColumn.log. Audit tables track the changes to objects when auditing is enabled on the objects. When auditing is enabled on an object, a corresponding audit table is created in the database where the users can see these changes. This audit table has a column called EAUDITUSERNAME that keeps track of the name of the user who changed the object. When a change is made from the UI on this object, the EAUDITUSERNAME column records the name of the user who is logged in, for example, SmithJ. However, if a change is made using a workflow, such as discovering a computer using Initial Discovery, these workflows always run as MAXADMIN and EAUDITUSERNAME column has MAXADMIN as its value rather than the name of the user who is logged in. For more information about electronic signatures, audit records, and login tracking features, see Electronic Signatures and Audit Records section in System Administrator's Guide. Auditing reports There are several auditing reports provided: v A report for user login history, tp_loginTrackingDetail, is available. You must enable login tracking to use the tp_loginTrackingDetail report. If login tracking is not enabled, the report is not displayed, and no error messages are provided. v You can also use a report to monitor user sessions, user_session.rptdesign. This report provides a bar chart that shows you the active and inactive user sessions for a given date range. v There is also a predefined report for user types, usertype.rptdesign. Use this report to see a bar chart of how many user sessions are active, inactive, and blocked. You can also create other reports as required. For more information about creating reports, see the Report Developer's Guide. Related links Chapter 14, Reports, on page 1187
112
Predefined reports on page 1190 Getting started with reports on page 1188
LDAP user and group management

You can use LDAP for Tivoli Provisioning Manager user and security group management. LDAP authentication and user management: Tivoli Provisioning Manager supports an LDAP implementation for user authentication and management. Users are managed centrally on the LDAP server and are assigned access based on your business needs. Tivoli Provisioning Manager uses the information in the user registry to authenticate users, but it cannot modify the user registry.
Table 16. Capabilities of LDAP. Capability Adding users LDAP User accounts are created on the LDAP server. You then synchronize the Tivoli Provisioning Manager server with the LDAP one. This activates the new users logging to the Tivoli Provisioning Manager Web interface. For more information about data mapping and synchronizing, see the section about Application Server Security in Chapter 2: Security of System Administrator Guide of Maximo Asset Manager . You can remove a user from Tivoli Provisioning Manager from the Web interface. The actual user account must be removed from the LDAP server separately. The Tivoli Directory Server database can be configured for high availability disaster recovery. Microsoft Active Directory can be backed up as part of a system backup. For more information, see http://technet2.microsoft.com/windowsserver/en/ library/f66ee9e4-96d7-4f74-a2fe-d669194bf5a21033.mspx.
Removing users Protecting data
For more information about configuring LDAP authentication, see the Tivoli Provisioning Manager Version 7.2 Installation Guide.
Lightweight Directory Access Protocol

Lightweight Directory Access Protocol (LDAP) is a user registry in which authentication is performed using an LDAP binding. LDAP allows you to delegate write or read access based on your specific needs. LDAP uses the existing information in your user registry so when you configure the provisioning server to support LDAP, no new users can be created using the user interface. Only the LDAP implementation that is used for authentication is supported. This type of LDAP implementation does not require write access. The LDAP configurations are performed by the product installation. For the user interface, the LDAP configuration is performed as part of the WebSphere configuration during Tivoli Provisioning Manager installation. For Web service interface, additional configuration is performed separately as a result of the XML file in $TIO_HOME/config/user-factory.xml. The supported LDAPs are IBM Tivoli Directory Server V6.1 and Microsoft Windows Active Directory. For detailed information about configuring the provisioning server for LDAP, see the Installation Guide.
Custom user registry for LDAP

This section is primary for configuring LDAP for the Web service interface. For the user interface, the settings are configured under WebSphere.
113
To configure LDAP, you must identify a custom user registry to specify how the provisioning server accesses the information in your LDAP. A user registry authenticates a user and retrieves information about users and groups to perform security-related functions, including authentication and authorization. A custom user registry is a customer-implemented user registry. It can support virtually any type of an account repository and provides considerable flexibility in adapting product security to various environments. Before configuring LDAP, you need to do the following v Ensure that the custom user registry (CUR) is implemented. Two sample custom user registries for accessing the following general LDAP: IBM Tivoli Directory Server:
com.ibm.tivoli.websphere.customSecurity.sample.IDSCurImplementation
Microsoft Active Directory (MSAD):

com.ibm.tivoli.websphere.customSecurity.sample.MSADCurImplementation
If these samples, do not suit your system requirements, you can implement your own custom user registry. To create your own, see the WebSphere Application Server documentation on custom user registries for more information. v Identify a user to be used to access the WebSphere Application Server administrative console. The two custom user registry samples identify the user that logs in to the WebSphere Application Server administrative console. The user that you identify must be an existing user in your LDAP. For more information, see the sample information for LDAP.
LDAP synchronization
Use the synchronization option for keeping your Tivoli Provisioning Manager and LDAP servers updated. When you change user and group structure and attributes in LDAP, you must import the changes into the Tivoli Provisioning Manager system. WebSphere Application Server provides a general capability called Virtual Member Management which allows multiple LDAPs and custom user registries to be plugged in underneath WebSphere Application Server, and, thus, display as a single logical user repository to any WebSphere Application Server application such as Tivoli Provisioning Manager. While the users are defined and maintained in the repositories, Tivoli Provisioning Manager needs to know who they and the group to which they belong. You can keep Tivoli Provisioning Manager up-to-date by running a periodic task known as VMM Sync Cron task. 1. In Tivoli Provisioning Manager, click Go To > System Configuration > Platform Configuration > Cron Task Setup. 2. Type the VMMSync into the Cron Task field and click Enter. 3. Activate the Virtual Member Manager synchronization by clicking the Active? check box. 4. To keep the history of all the activities of the VMM Sync Cron task, check the Keep History? check box and type 50 in the Max Number of History Records field. 5. Save the changes by clicking 6. Click .
for the list of available security groups, and select the appropriate one.
LDAP configuration information for Web service

For the Web service interface, Tivoli Provisioning Manager requires additional configuration in the user-factory.xml file. This additional configuration is separate from the LDAP configuration in Maximo VMM, in which the Web service interface requires direct access to LDAP to perform an authentication check. The Lightweight Directory Access Protocol (LDAP) for Web service interface documentation
114
provides sample configurations using Tivoli Directory Server and Microsoft Active Directory (MSAD). Correctly configuring the user-factory.xml file enables the authentication service to be performed for the Web service interface.
Tivoli Directory Server LDAP configuration for Web service interface

A sample of user-factory.xml for configuring Tivoli Directory Server LDAP is available in the following code example. The user-factory.xml file is mainly for configuring the Web service interface security. The configuration information required for the Web service interface security is as follows:
<user-database> <ws-security>true</ws-security> <ws-security-role>TPWEBSERVICEUSER</ws-security-role> <custom-user-registry>com.ibm.tivoli.websphere.customSecurity.sample.IDSCurImplementation </custom-user-registry> <user-factory>com.ibm.tivoli.tpm.userAndRoleFactory.IDSReadOnlyUserAndDBGroupFactory </user-factory> <authentication-realm>com.ibm.tivoli.tpm.security.realm.authentication.CustomLdapRegistry Realm</authentication-realm> <read-only>LDAP</read-only> <update-password>true</update-password> <!-The user-object is used for the creating and updating user in LDAP, This is only needed when read-only is false, i.e. write to ldap is permitted --> <user-object>  <ldap-class>thinkControlUser</ldap-class>  </user-object> <public-key>MIHwMIGoBgcqhkjOOAQBMIGcAkEA/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRp H5t9jQTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFwIVAJYu3cw2nLqOuyYO5rahJtk0bjjFAkBnhHGyepz0TukaScUUf bGpqvJE8FpDTWSGkx0tFCcbnjUDC3H9c9oXkGmzLik1Yw4cIGI1TQ2iCmxBblC+eUykA0MAAkA3uYsiYPh4gKWr H/SAzuZA4Xq9dDJIYHzBoUSCVwziUivB+tFLR5E0W26oD/Cbvty2iGwz/K sBgDhuaXCINffv</public-key> <ldapRegistries> <ldapRegistry> <initial-context-factory>com.sun.jndi.ldap.LdapCtxFactory</initial-context-factory> <server>tpmbvtwin4.tpmserver.example.com</server> <ldap-port>389</ldap-port> <ldaps-port>636</ldaps-port> <ssl-for-binding></ssl-for-binding> <baseDN>ou=users,ou=SWG,o=IBM,c=US</baseDN>  <subtree /> <bindingUserName useDN="True">cn=root</bindingUserName> <bindingPassword>xajkjE+64MkNsyYivQHFkg==</bindingPassword>  <userSecurityName>uid</userSecurityName> <userUniqueId>dn</userUniqueId> <userDisplayNameAttr>cn</userDisplayNameAttr> <userFilter>(&(uid=%v)(objectclass=inetOrgPerson))</userFilter> <groupSecurityName>cn</groupSecurityName> <groupUniqueId>dn</groupUniqueId> <groupDisplayNameAttr>cn</groupDisplayNameAttr> <groupFilter>(&(cn=%v)(|(objectclass=groupOfURLs)(|(objectclass=groupOfNames)( objectclass=groupOfUniqueNames)))) </groupFilter>  <groupMember>ibm-allGroups</groupMember> 
115
<userMember>ibm-allMembers</userMember> <attributes> <name>cn</name> <first-name>fn</first-name> <last-name>sn</last-name> <home-phone>homeTelephoneNumber</home-phone> <business-phone>businessTelephoneNumber</business-phone> <mobile-phone>mobileTelephoneNumber</mobile-phone> <email>mail</email> <address>postalAddress</address> </attributes> </ldapRegistry> </ldapRegistries> </user-database>
The information that is required for the Tivoli Directory Server LDAP sample implementation is specified in the ldapRegistries element in the user-factory.xml file. The following tables provide the information about how the ldapRegistry is constructed and configured for Tivoli Directory Server support.
Table 17. General LDAP server configuration Attribute ws-security Description Specifies if the Web service is enabled. True or false values indicate if the Web service security is turned on or off. The Web service is enabled if you specify true. The user role required to run Tivoli Provisioning Manager Web service commands. The default value is TPWEBSERVICEUSER. The host name of the Tivoli Directory Server. It must be a fully qualified host name. The non-secure socket layer (SSL) port for the LDAP protocol. This port number is normally 389. The SSL port for the LDAP protocol. This port number is normally 636. Specifies if the SSL is used for communication between Tivoli Provisioning Manager and Tivoli Directory Server. Additional configuration is required when you use the LDAPs protocol. See the related documentation for how the LDAPs is enabled in the Tivoli Directory Server. The base DN that Tivoli Provisioning Manager will search for in the user and group information. In Tivoli Directory Server, the base DN can be the suffix that the user and group information resides in. An additional way to specify the name of the context or object to search. For example, if the user information resides in an OU-TIO under the suffix specified in the baseDN element, specify OU=TIO under subtree to refine the search to the organization unit, TIO. bindingUserName bindingPassword The user name that is used to bind to the Tivoli Directory Server. The encrypted password that is used together with the bindingUserName to bind to the Tivoli Directory Server.
ws-security-role server ldap-port ldaps-port ssl-for-binding
baseDN
subtree
Table 18. User-specific LDAP server configuration information Attribute userSecurityName Description This is used for user authentication and authorization in WebSphere Application Server. The value of the attribute in Tivoli Directory Server is used to validate the user login name when accessing Tivoli Provisioning Manager. The unique identifier for the user. The value has to be unique for all registered Tivoli Directory Server directories. It has a value of dn.
userUniqueId
116
Table 18. User-specific LDAP server configuration information (continued) Attribute userDisplayNameAttr userFilter Description This is used to specify the attribute to store the display name of the user that is shown in the Web interface. This filter is used for searching for the user in the registry. It contains information such as the objectclass that the user belongs to. For example, (&(cn=%v)(objectclass=organizationalPerson) . The parameter %v is necessary because during the search, the %v is replaced with the real user name.
Microsoft Active Directory sample for LDAP

A sample of user-factory.xml file for configuring Microsoft Active Directory is available in the following code example. The user-factory.xml is mainly for the Web service interface security. The configuration information required for the Web service interface security is as follows:
<?xml version="1.0"?>  <user-database> <ws-security>true</ws-security> <ws-security-role>TPWEBSERVICEUSER</ws-security-role> <custom-user-registry>com.ibm.tivoli.websphere.customSecurity.sample.MSADCurImplementation </custom-user-registry> <user-factory>com.ibm.tivoli.tpm.userAndRoleFactory.MSADReadOnlyUserAndDBGroupFactory </user-factory> <authentication-realm>com.ibm.tivoli.tpm.security.realm.authentication.CustomLdap RegistryRealm</authenticationrealm> <read-only>true</read-only> <update-password>true</update-password> <public-key> MIHxMIGoBgcqhkjOOAQBMIGcAkEA/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t 9jQTxeEu0ImbzRMqzVDZkVG9xD7nN1k uFwIVAJYu3cw2nLqOuyYO5rahJtk0bjjFAkBnhHGyepz0TukaScUUfbGpqvJE8FpDTWSGkx0tFCcbnjU DC3H9c9oXkGmzLik1Yw4cIGI1TQ2iCmxBblC+eUykA0QAAkEA9+WHM8jyLAMuzmIOsLyQ+ojktcT/lR sSsc5aJFelnn0POIc8VZGA5OaEJ5AsFD9NWJpPwYL00WzqgKmer14bLQ== </public-key> <ldapRegistries> <ldapRegistry> <initial-context-factory>com.sun.jndi.ldap.LdapCtxFactory</initial-context-factory> <server>basquiat.tpmserver.example.com</server> <ldap-port>389</ldap-port> <ldaps-port>636</ldaps-port> <ssl-for-binding>false</ssl-for-binding> <domain>testing.ibm.com</domain> <bindingUserName>Administrator</bindingUserName> <bindingPassword>password</bindingPassword>  <userSecurityName>cn</userSecurityName> <userUniqueId>dn</userUniqueId> <userDisplayNameAttr>cn</userDisplayNameAttr> <userFilter>(&(sAMAccountName=%v)(objectcategory=user))</userFilter> <attributes> <first-name>givenName</first-name> <last-name>sn</last-name> <home-phone>homePhone</home-phone> <business-phone>telephoneNumber</business-phone> <mobile-phone>mobile</mobile-phone> <email>mail</email>
117
<address>streetAddress</address> </attributes> </ldapRegistry> </ldapRegistries> </user-database>
The information that is required for the Microsoft Active Directory LDAP sample implementation is mainly focused in the ldapRegistries element in the user-factory.xml file. The following tables provide the information about how the ldapRegistry is constructed and configured for Microsoft Active Directory support:
Table 19. General LDAP server configuration Attribute ws-security Description Specifies if the Web service security is enabled. True or false values indicate if the Web service security is turned on or off. The Web service security is enabled if you specify true. The user role required to run Tivoli Provisioning Manager Web service commands. The default value is TPWEBSERVICEUSER. The host name of the Microsoft Active Directory. It must be a fully qualified host name. The non-secure socket layer (SSL) port for the LDAP protocol. This port number is typically 389. The SSL port for the LDAP protocol. This port number is typically 636. Specifies if the SSL is used for communication between Tivoli Provisioning Manager and the Microsoft Active Directory. Additional configuration is required when you use the LDAP protocol. Refer to the related documentation for how LDAP is enabled in the Microsoft Active Directory. The domain value of the Microsoft Active Directory. The user name that is used to bind to the Microsoft Active Directory. The encrypted password that is used together with the bindingUserName to bind to the Microsoft Active Directory.
ws-security-role server ldap-port ldaps-port ssl-for-binding
domain bindingUserName bindingPassword
Table 20. User-specific LDAP server configuration information Attribute userSecurityName Description This is used for user authentication and authorization in WebSphere Application Server. The value of the attribute in Microsoft Active Directory is used to validate the user login name when accessing Tivoli Provisioning Manager. The unique identifier for the user. The value must be unique across all registered Microsoft Active Directory directories. It has a dn value. This is used to specify the attribute to store the display name of the user that is shown in the Web interface. This filter is used for searching for the user in the registry. It contains information such as the objectclass that the user belongs to. For example, (&(cn=%v)(objectclass=organizationalPerson) . The parameter %v is necessary because during the search, the %v is replaced with the real user name.
userUniqueId userDisplayNameAttr userFilter
Attribute mapping from LDAP to IBM Tivoli Provisioning Manager

If you create users in WebSphere Application Server and you are using WebSphere Application Server administration console to manage entities, you need to know how attributes are mapped to the user and
118
group in Tivoli Provisioning Manager. If you define an attribute in the LDAP entry, and you complete a VMM synchronization, the item can display in Tivoli Provisioning Manager. The following tables lists the mapping between LDAP attributes and Tivoli Provisioning Manager.
Table 21. User attribute mapping from LDAP to Tivoli Provisioning Manager LDAP attribute uid uid uid LDAP attribute uid givenName sn displayName street st l postalCode c LDAP attribute uid telephoneNumber LDAP attribute uid PERSONID Column name in MAXUSER table USERID LOGINID PERSONID Column name in PERSON table PERSONID FIRSTNAME LASTNAME DISPLAYNAME ADDRESSLINE1 STATEPROVINCE CITY POSTALCODE COUNTRY Column name in PHONE table PERSONID PHONENUM Column name in EMAIL table PERSONID EMAILADDRESS
Table 22. Group attribute mapping from LDAP to Tivoli Provisioning Manager LDAP attribute cn description Column name in MAXGROUP table GROUPNAME DESCRIPTION
Troubleshooting security
To help you to troubleshoot problems with security, gather as much information as possible about the error. Review the following list to assess the problem.
Procedure
1. Verify that all requirements for the scenario were met as described in Requirements on page 79. 2. Check the interface and log files for error messages. The console log file contains information for the scenario. %TIO_LOGS%/console.log
119
3. If there is an error message with a message ID, check the Tivoli Provisioning Manager ../com.ibm.support.tpm.doc/messages/rtrbmsg_tpm.dita section under Reference for a description of the error message. 4. Check the Tivoli Provisioning Manager Support technotes and FAQs or the latest available fix pack readme file for information about known issues or updates to the documentation.
Access control problems and limitations

This section provides troubleshooting guidance and information about product limitations.
VMMSYNC cron task does not synchronize information

Use debug mode on the cron task to determine whether this problem is because of incorrect LDAP setup, incorrect credentials, or because administrative mode is turned on.
Symptoms
When you run a VMMSYNC cron task, the information from LDAP does not get synchronized into the Tivoli Provisioning Manager system. No records created in LDAP can be seen in the user interface.
Causes
There are several possible causes for this: v Incorrect LDAP setup v Incorrect user credentials v Administrative mode is turned on for database configuration

To determine the cause of the problem, turn on debug mode for the cron task: 1. Click Go To > System Configuration > Platform Configuration > Logging. 2. In the Logger field, type crontask. 3. For each instance of crontaskmgr and crontask, select DEBUG in the Log Level field, and activate them by clicking the check box. 4. Save the settings by clicking the Save Logger button, and from the Select Action menu, click Apply Settings to activate the debug logging. The debug information is available in the SystemOut.log file in the %WAS_HOME%\profiles\ctgAppSrv01\ logs\MXServer directory.
The VMMSYNC cron task does not run

The task does not run if the LDAP distinguished names in the GroupMapping and UserMapping parameters contain quotation marks.
Symptoms
When you request the VMMSYNC cron task to run, the task does not work.
Causes
The LDAP distinguished names in the GroupMapping and UserMapping parameters contain quotation marks (" ").

Remove the quotation marks from the GroupMapping and UserMapping parameters.
120
Navigate to Go To > System Configuration > Platform Configuration > Cron Task Setup. In the list, find the VMMSYNC cron task. Click the VMMSYNC cron task. Click the Parameters tab and expand the GroupMapping parameter. In the Value field, find the LDAP information within the <basedn> tags and remove any quotation marks around the distinguished names. 6. Expand the UserMapping parameter and remove any quotation marks around the LDAP distinguished names within the <basedn> tags. 7. Click Save. 8. Restart the provisioning server. 1. 2. 3. 4. 5.
Provisioning groups can be modified without permission

Security groups created based on provisioning groups can be modified by users who do not have permission to change the groups.
Symptoms
A Tivoli Provisioning Manager user other than MAXADMIN has update permissions to provisioning groups applications, and can change provisioning groups created for security.
Causes
The security groups that are created based on provisioning groups have no security constraints set up.

To restrict security groups so that they can only be accessed by authorized users, group the provisioning groups created for security together, and then restrict the group access by performing the following actions: Group the provisioning groups with security functions: 1. Click Go To > Deployment > Provisioning Groups.. . 2. Create a static provisioning group by clicking the 3. Add the groups that you want to protect by clicking Add Groups and then save the settings by clicking .
Restrict the user access to the newly created group by creating appropriate conditions for the group: 1. Click Go To > Administration > Conditional Expression Manager. 2. Add a new condition by clicking New Row. 3. Define the name for the condition by choosing the EXPRESSION as its Type, and then type the following Expression:
(EXISTS (select 1 from group_membership gm, tpgroup g where g.name = new_group_name AND g.id=gm.group_id and is_nested_group=Y and gm.dcm_object_id=:id)) OR (:name = new_group_name)
where new_group_name is the name of the group defined in the step above. 4. Check the Always Evaluate? check box, and then click .
Create a data restriction with the new condition After the condition is created for the group, add a READONLY data restriction to it with the following actions:
121
1. 2. 3. 4. 5.
Click Go To > Security > Security Group. . Select the security groups that you created. Click the Data Restrictions tab, and then select New Row to create a data restriction. Define Object as TPGROUP, and Type as READONLY. Click Select Value from the Detail Menu list.
6. Select the newly selected condition name. 7. Save the settings by clicking .
You have now set a data restriction that restricts access to security groups that you want to protect.
Error when user adds a task to a plan

If the message BMXAA0024E - ADD is not allowed on WOACTIVITY is displayed, a default site is not configured for the user.
Symptoms
The message BMXAA0024E - ADD is not allowed on WOACTIVITY is displayed when a user attempts add a task to a plan in a work order using the Work Order Tracking application.
Causes
A default site is not configured for the user.

As a prerequisite, at least one site must be enabled and configured in the deployment. The user or administrator can configure the default site for the user from the Profile > Default Information panel for the user or via the Users application.
Duplicate records in provisioning group application

These are valid distinct function options. For example, one might be used in a menu and the other in a button.
Symptoms
Some records are listed twice when looking at provisioning applications in the Security Groups application.
Causes
Applications have the same labels for different sign options (option names) when displayed in the Security Groups > Applications tab. These are valid distinct function options. For example, one might be used in a menu and the other in a button.

You can modify this by enabling or disabling the options for a particular security group. This change is typically done in pairs.
Error when using special characters to create a user or role

The Distinguished Name (DN) syntax supported by the directory server does not support special characters. Use a backslash before including special characters in an attribute value in a distinguished name string.
122
Symptoms
If you include special characters like comma (,), equals (=), plus (+), less than (<), greater than (>), number sign (#), semicolon (;), backslash (\), and quotation marks (" ") in the user name or role name, the following error occurs:
COPCOM132E An error occurred during the LDAP operation: cn=#dffded: [LDAP: error code 34 - Invalid DN syntax].
Causes
The Distinguished Name (DN) syntax supported by the directory server does not support special characters. This is a known problem with IBM Tivoli Directory Server and is described in detail in the Tivoli Directory Server Administration Guide that is available in the Tivoli Software Information Center.

Enter a backslash (\) before using special characters or other characters in an attribute value in a distinguished name string.
User is not logged out of session on time out

The user is not automatically logged off when using basic authentication. Use the form base authentication instead.
Symptoms
When a session times out, the user is not logged off if basic authentication is being used.
Causes
The user is not automatically logged off when using basic authentication. If you click Refresh or press F5 after getting the timeout message, you return to the console without a password prompt.

To ensure that users are logged off when their session times out, use form base authentication instead of basic authentication.
New security group does not display in group list

It can take up to 1 minute for the page to refresh. To see the new group immediately, refresh the page manually.
Symptoms
When you add a new security group in a one-node Microsoft Active Directory (MSAD) setup, the group does not display immediately.
Causes
It can take up to 1 minute to refresh the page because the refresh interval for the Microsoft Active Directory server is 1 minute.

To see the new security group immediately, refresh the page manually.
123
Web browser has SSL security warnings

Security warnings display if you access Tivoli Provisioning Manager with an outdated version of a Web browser.
Symptoms
When you access Tivoli Provisioning Manager using secure socket layer (SSL), not all content is SSL enabled. After you submit the user name and password, you receive a warning message asking if content that is not encrypted with SSL during the initial login can be displayed.
Causes
The Web browser that you used to access Tivoli Provisioning Manager is outdated (for example, Internet Explorer 6). Use a new version of the Web browser to avoid the security warnings.

The Web browsers that you use to access Tivoli Provisioning Manager must be one of the following versions or newer: Internet Explorer Internet Explorer 7 Mozilla Firefox Firefox 2
Cannot change the user password

User passwords cannot be changed in the provisioning Web interface.
Symptoms
Errors occur when you try to change the user password in the provisioning Web interface.
Causes
Changing the user password in the Web interface is not supported.

Microsoft Active Directory Users can log on to the LDAP server using their user name and password to change their own user name and password. Tivoli Directory Server Tivoli Directory Server provides a Web Administration Tool for users to update their information and change passwords. The tool is not installed by default. See the documentation for details on how to install the Web Administration Tool: http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/ index.jsp?topic=/com.ibm.IBMDS.doc/install27.htm. After the Web Administration Tool is installed, change the user password: 1. Start the Web Administration Tool using the following command:
Windows UNIX
<install_path>\idstools\bin\startWebadminApp.bat <install_path>/idstools/bin/startWebadminApp
124
where install_path is the directory where you installed Tivoli Directory Server. For detailed instructions, see the topic called Starting the Web application server to use the Web Administration Tool: http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.IBMDS.doc/ install18.htm. 2. Users can launch the tool using the following Web address:
http://<hostname>:12100/IDSWebApp/IDSjsp/Login.jsp
where hostname is the host name of the Tivoli Directory Server. 3. Log on to the tool with your user name. 4. Click User properties > Change password. If users receive the following error when they try to change their password, they do not have permission to update their own password:
GLPWCO025W The password cannot be changed. The user does not have the authority to modify the password.
The LDAP administrator can update the permissions by running the following command:
ldapmodify -D <adminDN> -w <AdminPwd> -i <modifyACL.ldif>
For example:
ldapmodify -D cn=root -w password -i modifyACL.ldif
where the modifyACL.ldif file contains the following information, for example:
dn: cn=tioappadmin,dc=ibm,dc=com changetype: modify add: aclentry aclentry: access-id:cn=this:at.userpassword:rwsc
Replace cn=tioappadmin,dc=ibm,dc=com with your user dn. After the command is run, users must correct permission to update their own passwords.
Disable emailing of password when updating password

If you are using Maximo authentication and you are changing a password and the SMTP server is not set up, you must disable the Always Email Generated Password to Users (Never Display On Screen) option.
Symptoms
For Maximo authentication only, if the SMTP server is not set up correctly and you try to change a password without providing a valid email address, an error might occur and you might not be able to change the password. The following error messages are displayed: v BMXAA3813E - The password cannot be emailed to the user because SMTP Host is not set in the MXServer property file. This error message is displayed if the SMTP server is not set up correctly. v BMXAA3816E - An email message with the new password could not be sent to the user. This error message is displayed if the SMTP server is not configured correctly or if it is not currently online.
Causes
The problem occurs if the Always Email Generated Passwords to Users (Never Display On Screen) option is enabled. This option works correctly only if the SMTP server is set up and running and if you provide a valid email address for the user when you are changing the password.
125
To resolve the problem, you must set up the SMTP server to enable the email to be sent. However, you can use the following workaround to disable the email function: 1. Log in as the maxadmin user. 2. Click Go To > Security > Users. 3. Click Select Action -> Security Controls. 4. If the Always Email Generated Passwords to Users (Never Display On Screen) option is enabled, disable it by selecting the Allow Generated Passwords to Be Displayed On Screen option. Note: When you are creating a new user or updating an existing user password, disable the Always Email Generated Passwords to Users (Never Display On Screen) option. By disabling this option, you do not need to set up the SMTP server or provide email information for the user when creating a new user and password or updating an existing password.
Applications displaying in Favorite applications list

You can configure the Favorite applications list in Tivoli Provisioning Manager to display particular applications for particular users. However, this is distinct from granting the users access to those applications. Users cannot access particular applications unless you grant them explicit access permissions. The display in the Favorite applications list is merely a display.
Symptoms
Particular applications might display in the Favorite applications list for particular users.
Causes
You can configure the Favorites applications list to determine the applications that display in the list but this does not control actual access. You control access to applications using the Security functionality.

You can change the display of the Favorite applications list or you can provide the users with access to the particular application, depending on your requirements.
User MAXADMIN can log on when Maximo authentication is enabled

If you enable Maximo authentication and change the default administration user from MAXADMIN, the MAXADMIN user can still log on to the Tivoli Provisioning Manager application user interface.
Symptoms
After you install Tivoli Provisioning Manager and enable Maximo authentication and change the default admin user from MAXADMIN to something else, the MAXADMIN user is not disabled and can still log on to the Tivoli Provisioning Manager application web user interface. Additionally, you cannot log on as the default administration user that you specified.
Causes
There is a known issue with the base service installation.

Complete the following steps to disable the MAXADMIN user: 1. Log on to Tivoli Provisioning Manager as the Maximo administrator. 2. Click Go To > Security > Users. 3. Search for the MAXADMIN user.
126
4. 5. 6. 7. 8.
Click Click Click Click Click
the User tab. Select Action > Change Status. the New Status list. Inactive. OK.
Time lag for security changes to take effect

If you grant permissions to a particular group in Tivoli Provisioning Manager, you cannot locate that group in the Favorites Applications portlet until some time has passed.
Symptoms
After you grant permissions to a particular provisioning application group, you cannot immediately view the application in the Favorites Applications portlet.
Causes
This occurs because there is a time lag before the changes become effective. The server searches for changes periodically and your changes become effective only after they have been processed by the server.

You must wait approximately 15 minutes for the changes to take effect. Additionally, all users in the particular group must be logged out for the changes to take effect.
New users and groups are not synchronized

If you add new users and groups to your directory server, these users and groups should display in your Users application after synchronization. However, your Virtual Member Manager cache can sometimes affect the synchronization and the new users and groups might not display in the Users application.
Symptoms
New users and groups that you add to your directory server are not updated in the Users application after synchronization.
Causes
If the Virtual Member Manager cache is enabled and its timeout period is longer than the frequency with which the VMMSync cron task runs, new entries that you create are not synchronized.
Diagnosing the problem

If adjusting the timing between the cache and the VMMSync cron task does not result in entries being synchronized, the problem might be because you have added a new cron task to synchronize data from a newly federated directory server, or modified the existing VMMSync cron task to point to a new location in the directory information tree.

To ensure that new entries are synchronized, disable the cache for each directory server that you have federated under VMM, or update the VMMSync cron task frequency so that the cache expires before the next synchronization. Complete the following steps to disable the WebSphere Application Server VMM cache: 1. Log on to WebSphere Application Server.
127
2. 3. 4. 5. 6. 7. 8. 9. 10.
Click Security > Secure administration, applications, and infrastructure. Click Configure. Under Related Items, click Manage repositories. Click your repository identifier. From the Additional Properties menu, click Performance. Clear the Cache the attributes option. Clear the Cache the search results option Click Apply and then save. Restart Tivoli Provisioning Manager.
Only Latin characters are supported in user names and passwords

You cannot use non-Latin characters in user names and passwords used to log in to Tivoli Provisioning Manager. For example, you cannot use Chinese or Arabic characters in user names and passwords. Similarly, you cannot use special characters in user names or passwords.
Symptoms
You might encounter problems if you try to authenticate using user names or passwords that have non-Latin characters.

To resolve the problem, create user names and passwords that use only Latin characters. Tivoli Provisioning Manager supports basic Latin with ANSI characters and ANSI numbers from 32 to 127.
Error starting dynamic content delivery console on Firefox

If you are using a Firefox browser, you might experience a problem when starting the Dynamic Content Delivery console. If this problem occurs, you receive an error message stating that there is an existing certificate with the same serial number.
Symptoms
You receive an error message when trying to start the Dynamic Content Delivery console using a Firefox browser.
Causes
This error can occur if there is a certificate stored from a previous version and it uses the same serial number.

To correct this problem, complete the following steps: 1. In your Firefox browser, click Tools > Options > Advanced. 2. Click the Encryption tab and then View Certificates. 3. Click the Servers tab. 4. 5. 6. 7. 8. Remove all certificates for Tivoli Provisioning Manager. Close all instances of Firefox, and restart your Firefox browser. Log on to Maximo. You receive a message stating that the connection is not trusted. Click to confirm the I Understand the Risks and Add Exception messages. Click Confirm Security Exception.
128
9. Log on to the Dynamic Content Delivery administration console. You receive a message stating that the connection is not trusted. 10. Click I Understand the Risks, Add Exception, and Confirm Security Exception. You should now be able to log on to Maximo and the Dynamic Content Delivery console without any errors. If you are still having problems, check if there is another Tivoli Provisioning Manager server with the same certificate. If there is another Tivoli Provisioning Manager server with the same certificate, you need to delete that certificate also.
All objects are listed regardless of security

When adding members to a particular Tivoli Provisioning Manager group, users might see a list of all objects even though they do not have permission to access some of those objects.
Symptoms
Users might still see objects that they do not permission to access when adding new members to a Tivoli Provisioning Manager group.

To resolve the problem, you must enable instance level security for the data model object finder for the particular Tivoli Provisioning Manager group. To do this: 1. Log on as the MAXADMIN user. 2. Click Go To > Security > Security Group. 3. Click the security group of which the user is a member. 4. Click Select Action->Enable DcmFinder Security.
Removing users from Tivoli Provisioning Manager

You might receive an error if you try to remove users from Tivoli Provisioning Manager using the Maximo user interface.
Symptoms
You cannot delete users from Tivoli Provisioning Manager using the Maximo user interface. You receive the following error message when you try to delete users:
DMXAA0026E - The method cannot be called because application server security is enabled.
Environment
You are using LDAP to manage the user repository.

Complete the following steps to remove users from the Tivoli Provisioning Manager database: 1. Click Go To > Security > Security Group. 2. Click Select Action->Security Controls. 3. Check if login tracking is enabled. Enable login tracking if it is not enabled. Information about how to enable login tracking is available in the Maximo online help. 4. Stop Tivoli Provisioning Manager. 5. Enter the following SQL command:
UPDATE MAXIMO.MAXPROPVALUE SET PROPVALUE=0 WHERE PROPNAME = mxe.LDAPUserMgmt
6. Start Tivoli Provisioning Manager. 7. Ensure that the user is removed from the LDAP server.
129
8. 9. 10. 11.
Click Click Click Enter
Go To > Security > Users. the user that you want to remove. Select Action->Delete User. the following SQL command:
UPDATE MAXIMO.MAXPROPVALUE SET PROPVALUE=1 WHERE PROPNAME = mxe.LDAPUserMgmt
12. Restart Tivoli Provisioning Manager.
Error when importing a key or certificate to a keystore

Error when importing a key or certificate to a keystore.
Symptoms
When importing a key or certificate in to a keystore or truststore, the following error may be shown:
Java.io.IOException: Error in loading the keystore: Private key decryption error: (java.security.InvalidKeyException: Illegal key size)
Causes
The error is caused by the restricted policy on the JCE that is installed by default.

To download the unrestricted version: 1. Go to: https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk. 2. Log on. 3. Select Unrestricted JCE Policy files for SDK for all newer versions Version 1.4.2+ . 4. Click Continue to continue the download process. After the zip file is downloaded, there are 3 files in the zip: v readme.txt v local_policy.jar v US_export_policy.jar Update the JCE policy in the JAVA_HOME directory in the Windows environment: 1. Click Start > Control Panel > System 2. Under the Advanced Tab > Environment Variables 3. Note the value of the JAVA_HOME variable. 4. Replace the local_policy.jar and US_export_policy.jar in the %JAVA_HOME%\lib\security folder. Note: Do not rename or overwrite the original files, backup the original files to another location before replacing. 5. Go to the iKeyman or GSKit location. 6. Start iKeyman.exe or gsk7ikm.exe. Update the JCE policy for TPM environment: 1. Stop TPM. 2. Replace the local_policy.jar and US_export_policy.jar in %WAS_HOME%\java\jre\lib\security. 3. Start TPM.
130
Error after updating the maximo.properties file

Error after updating maximo.properties.
Symptoms
After updating the maximo.propertiesfile, when starting the provisioning server, an error similar to the following can be seen in the SystemOut.log.
javax.crypto.BadPaddingException
Causes
The problem is caused by the editor that is being used for updating the maximo.properties. The editor adds an extra character into the encrypted password section.

In order to avoid the addition of the new character, it is recommended to use notepad to edit the maximo.properties.
GSKit key manager does not recognize CMS key database type
When configuring DB2 for SSL communication, the GSKit key manager does not recognize the CMS key database type. Because of this, you cannot generate a new keystore file.
Symptoms
The GSKit key manager does not recognize the CMS key database type. You receive an error message stating that the CMS Java native library is not found.
Causes
This problem might occur if you have an older JDBC version that was installed with DB2 v 9.5 FP3a.

To resolve this problem, upgrade your JDBC version to the latest available version.
Instance level security for Maximo administrator user

The Maximo administrator user should not have instance level security. If you have instance level security defined for the Maximo administrator user, the deployment engine cannot start.
Symptoms
The following error message is displayed in the %TIO_LOGS%\tio_start_service.log file:
COPTDM094E The operation cannot be performed because the computer srvtivoli cannot be found in the data model. at com.thinkdynamics.kanaha.util.LocalServerUtil.getLocalServerId (LocalServerUtil.java:97) at com.thinkdynamics.kanaha.util.LocalServerUtil.getLocalServerName (LocalServerUtil.java:68) at com.ibm.tivoli.orchestrator.de.engine.DeploymentEngineSettings.getDeploy mentEngineInstanceName (DeploymentEngineSettings.java:91) at com.ibm.tivoli.orchestrator.de.engine.DeploymentEngine.start
131
(DeploymentEngine.java:69) at com.ibm.tivoli.orchestrator.de.OSGiDeploymentEngine.startComponent (OSGiDeploymentEngine.java:39) at com.ibm.tivoli.tpm.util.Activator$1.run
Or if you try to run tioStatus.sh, it returns the following error:

ERROR COPCOM607E The engine status is not available because of the following reason: Connection failed, check if TPM server was started successfully. (Connection refused).
Causes
This problem occurs because the Maximo administrator user cannot access the server on which Tivoli Provisioning Manager is running.

To fix this problem, complete the following steps: 1. Identify the Maximo administrator user. The default is maxadmin. To identify the Maximo administrator user: a. Log on to Tivoli Provisioning Manager. b. Click Go To > System Configuration > Platform Configuration > System Properties. c. Search for mxe.adminuserid. The value specified for mxe.adminuserid is the Maximo administrator user on your system. You can also identify the Maximo administrator user by running the following command from the database console:
SELECT propname,propvalue FROM maxpropvalue WHERE propname = mxe.adminuserid
2. Reconfigure the group membership so that the Maximo administrator user is no longer a member of the security group with instance level security defined. For information about how to configure instance level security, see Lesson 1: Assigning read/write type of permissions to security groups on page 83 and Lesson 2: Adding users to security groups on page 81. You can identify if the Maximo administrator user is a member of a security group by looking for the security restriction defined in the security group. 3. Restart Tivoli Provisioning Manager.
Reference
Reference information supports the tasks that you want to complete.
Role based security groups

Security in Tivoli Provisioning Manager is based on the concept of grouping users into security groups. However, a user as a member of security group has to be able to authenticate and be authorized to use appropriate resources. Authentication is about proving that you are who you say you are. Authorization is about what you are allowed to do. When authentication and authorization are set up, you can work with Tivoli Provisioning Manager to perform the accounting and logging of what has occurred in your data model.
What is a security group?

Security groups are user groupings based on the particular user roles, and are created for security purposes. They contain all of the security related attributes: v Security restrictions that provide different types of access to the resources or applications, such as read-only or read-write
132
v Conditions that provide lists of resources to be protected v Users to whom the security restrictions and conditions apply Tivoli Provisioning Manager provides predefined security groups that you can use and, if necessary, modify to suit your enterprise environment. A security group typically consists of multiple users. An individual user can be assigned to more than one security group. The primary group assignment determines which Start Center is open when a user logs on; users who are assigned to multiple security groups can tab to the Start Centers for their secondary groups. Users have permission to perform only those operations that are mapped to their security group assignments. From the Web interface, you can create user accounts and customize security roles to control access to features based on job responsibility. When a user logs on, they can only view information or make changes based on the access rights assigned to the account of the user. Tivoli Provisioning Manager uses read-only LDAP authentication. Before you create new user accounts in the Web interface, the users must first be created in LDAP. There are several settings that are configurable in security groups: v Start Center assignments v Application authorization and access v Data restrictions v Site, and location v Provisioning object, and provisioning groups Note: The read-only permission restricts user access to view data only. To learn how to customize the access to applications of your choice, see Lesson 3: Customizing access to provisioning applications on page 84. For more information about the settings configuration, refer to the System Administrator Guide of Maximo Asset Manager .
What is authentication?
Authentication is the process of verifying that the users are who they claim to be. Authentication is required for all users accessing the system. The user authentication process is always performed under SSL. v Authentication verifies who you are - it does nothing to say what you are permitted to do. It answers questions such as: Who is the user? Are the users really who they claim themselves to be? For more information about authentication service, see the section about Setting Up Authentication and Application Server Authentication in Chapter 2: Security of System Administrator Guide of Maximo Asset Manager .
What is authorization?
Authorization is the process of determining whether a user can perform a specific operation on a software or hardware resource. Authorization is determined from the access control information in Tivoli Provisioning Manager. v Authorization is about what you are allowed to do - it assumes that authentication has already happened. It answers questions such as: Is an Operator authorized to access xxx resources? Is an Operator authorized to perform yyy operation?
133
Is an Operator authorized to perform yyy operation on xxx resource? The access control information is what grants users access to your resources. Access control provides security to the data model in two ways: v Protects which users are allowed to access which resources. Users are permitted access to resources with assigned security roles. v Protects which users are allowed to perform which operations on resources. Access permissions (access groups and permission groups) define the operations that users are allowed to perform on specific resources. The different operations can range from managing servers, viewing reports, running discovery, and any of the other operations that are required to operate and manage your data model. In general, when a user attempts to access a protected resource, the access control information first determines what access controls are applicable for that user and then based on the access permissions of the user, it determines if the user is allowed to perform the requested operation on the given resource. Example In a scenario, an operator might have full access control over one application, such as monitoring, installing, patching, rebooting, and so on. In another case, that same operator will have limited access to another application, such as monitoring and rebooting.
How they work together?

To determine if someone is authorized to use the provisioning server, authentication data must be checked. The product has a logon authentication service that allows authorized enterprise personnel to access the system at log on. Users send their user names and passwords using SSL to the server system, which in turn compares their authentication information with its local database. If the provided user name and password are found to match, the user is considered authenticated. You can also configure Tivoli Provisioning Manager to authenticate users using a client certificate. As soon as authentication is validated, the system determines what level of access a particular authenticated user must have to secure resources that are controlled by Tivoli Provisioning Manager.
Predefined security groups

Tivoli Provisioning Manager provides definitions for security groups that are available for you to use predefined and that can be implemented in your enterprise. The groups are aligned with the user roles defined for the product.
134
Table 23. The operations that can be performed by members of TPADMIN security group.
Security Group TPADMIN Provisioning Administrator Provisioning Tasks Skills
v Runs initial discovery scans. Configures v Extensive knowledge on the provisioning environment. discovery scans required to maintain the network inventory. v Administration skills for relevant v Views and groups servers and software operating system and database according to needs of the environment. environments. Responsible for maintaining the catalog v Experience in installing and configuring (editing, deleting, grouping). Imports system management software. the necessary tools to enable target v System, application, and user security computers for receiving deployments. concepts and strategies. Might also set up the scans for new v Experience in planning and patches and import them into the implementing high availability inventory. Possible cooperation with the configurations. Deployment Specialist to prepare the target computers with the TCA or v Performance tuning and overall system WUA, to receive deployments. troubleshooting. v Manages the approvals of software for deployments and scanning of servers for patches. This includes working with a Deployment Specialist to determine the appropriate set of patches required for a specific platform or software product and then approving the patches that are needed. v Designs and tests deployments to ensure that they are ready for production. Works with the Deployment Specialist to prepare for regular deployment into the production environment. v Performs many complex tasks critical to the setup and operation of the deployment environment. This includes managing the overall deployment environment, performing the necessary duties to set it up and keep everything running smoothly by handling any problems that arise. v Regularly monitors the deployment environment to ensure that everything is going smoothly, including summary reports. When troubleshooting is needed, assists with determining the cause of any problems using available tools and information. Validates successful deployments to ensure that everything is working properly.
135
Table 24. The operations that can be performed by members of TPDEPLOYMENTSPECIALIST security group.
Security Group TPDEPLOYMENTSPECIALIST Deployment Specialist Provisioning Tasks v Performs day-to-day deployments of software (OS, patches, software) to computers. Can also deploy tools on to computers to facilitate future deployment tasks, such as the installation of an agent on a target computer. v Performs a limited set of tasks repeatedly and wants a user interface that is simple and fast to use, with no wasted clicks or unnecessary steps. The Deployment Specialist Role has an associated Start Center. This role maps to the ITUP Deployment Specialist. v Enables computers for patch management by installing TCA or WUA. v Installs patches, triggers installation of patches and monitors progress. v View tasks in progress and monitors problems. Validates that patches installed correctly. v Reviews computer or group compliance. Runs scheduled compliance checks. v Performs a visual inspection of computer inventory. Starts new scans to validate data progress. Skills v Administration skills for the relevant operating system and database environments. v Experience in installing and configuring system management software. v Advanced knowledge of the software available in the software catalog, and the software installation and configuration options. v Knowledge of running inventory scans and inventory and compliance reports to identify software required.
Table 25. The operations that can be performed by members of TPDEVELOPER security group..
Security Group TPDEVELOPER Automation Package Developer Provisioning Tasks v Accesses all of the software packaging tools and creates automation packages for deployment. v Views inventory, workflows, and task status. Uses the Software Package Editor. Has links to tools used for development and test. Skills v Understands general programming concepts and logic. v Knowledge of a scripting language, such as bash, perl, Expect, or VBScript. v Knowledge of Java. v Basic knowledge of Eclipse.
136
Table 26. The operations that can be performed by members of TPCOMPLIANCEANALYST security group.
Security Group TPCOMPLIANCEANALYST Compliance Analyst Provisioning Tasks v Guides policies for compliance within the organization and ensures that they are being followed to meet goals. v Checks the compliance of resources for which they are responsible. Helps guide policies for compliance within the organization and ensures that policies are being followed to meet goals. v Might also assist with specific compliance issues from both a technical and business perspective. v Uses Tivoli Provisioning Manager for reviewing and updating compliance data. v Analyzes list of missing patches and approves, rejects, or ignores it for a group or a computer. v Reviews new items in the catalog and approves, rejects, or ignores them for installation on a group or a computer. v Restricts patches to a group or a computer. v Defines groups for compliance.
Table 27. The operations that can be performed by members of TPCONFIGURATIONLIBRARIAN security group.
Security Group TPCONFIGURATIONLIBRARIAN Provisioning Configuration Librarian Provisioning Tasks v Is responsible for the inventory database and for maintaining its currency and accuracy. v Performs various scans as appropriate. Delegates regular scanning tasks (such as discovery or inventory scans) to others as part of their regular duties. v Updates records in the database to ensure accuracy. Skills v Understands the configuration requirements of the selected discovery technologies such as inventory discovery. v Advanced knowledge of the managed environment within the enterprise, including awareness of applications that can cause configuration changes outside the scope of Tivoli Provisioning Manager.
v Has access to run or schedule discovery v Ability to reconcile unexpected changes scanning and inventory tasks and can detected in the environment so they can edit them. either be accepted as changes in the v Creates and runs reports. inventory or remediated to restore the required state.
Table 28. The operations that can be performed by members of TPWEBSERVICEUSER security group.
Security Group TPWEBSERVICEUSER Web Service administrator Provisioning Tasks v Uses the Web service interface. Web service authentication is required for Dynamic Content Delivery authentication. Skills v Knowledge of Tivoli Provisioning Manager Web service interface.
Table 29. Automation package Developer TPDEVELOPER application authorization permissions Application TPDCMFIND TPDISCINIT TPSERVERS TPTASK TPTASKINV TPSTACK Display name Provisioning Object Finder Discovery Wizards Provisioning Computers Provisioning Task Tracking Provisioning Task Definitions Software Stacks X Read access only X X X X X Read/write access
137
Table 29. Automation package Developer TPDEVELOPER application authorization permissions (continued) Application TPSWPATCH TPVIRTUAL TPWFSTAT TPSWRES TPDISC TPWORKFLOW TPSTPOOL TPACL TPLDBAL TPFILEREP TPSWITCHS TPSTSUBST TPSAN TPCLSTDMN Display name Patches Virtualization Management Provisioning Software Resources Discovery Configurations Provisioning Workflows Storage Pools Access Control Lists Load Balancers File Repositories Switches Storage Subsystems Storage Area Networks Cluster Domains X X X X X X X X X X X Read access only X X X Read/write access
Security groups and application access rights

Each security group defined for Tivoli Provisioning Manager has specific access rights for the provisioning applications and for the other applications that are used from Tivoli Provisioning Manager. This topic lists the application access rights for the security groups. The following abbreviations are used in this topic: v R = Read v I = Insert v v v v C = Manage compliance S = Save (Update) D = Delete M = Manage, which is an overall access type under which the users in the group can perform general provisioning actions.
Note: If you have TPWEBSERVICEUSER permissions, you can run commands in the Web service interface, but you do not have user interface permissions to Tivoli Provisioning Manager.
Table 30. Provisioning administration applications
Provisioning Administrator RISDM RISDM Deployment Specialist Compliance Analyst Provisioning Configuration Librarian RS RS Automation Package Developer
Application Click Go To > Administration > Provisioning > Device Drivers. Click Go To > Administration > Provisioning > Device Driver Categories. Click Go To > Administration > Provisioning > Provisioning Workflows. Click Go To > Administration > Provisioning > Provisioning Workflow Status.
RISDM
RM
RISDM
RISDM
RISDM
RISDM
RISDM
138
Table 30. Provisioning administration applications (continued)

Provisioning Administrator RISDM Deployment Specialist R Compliance Analyst R Provisioning Configuration Librarian RS Automation Package Developer
Application Click Go To > Administration > Provisioning > Provisioning Global Settings. Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. Click Go To > Administration > Provisioning > Provisioning Customers. Click Go To > Administration > Provisioning > Resource Pools. Click Go To > Administration > Provisioning > Cluster Domains.
RISDM
RISDM
RISDM RISDM
RSM RSM
RM
R RS RISDM
Table 31. Deployment applications

Provisioning Administrator RISDM RISDM RISDM RISDM Deployment Specialist RSM RSM RISDM Compliance Analyst RC RC Provisioning Configuration Librarian RISD RISD RISDM Automation Package Developer RISDM
Application Click Go To > Deployment > Provisioning Computers. Click Go To > Deployment > Provisioning Groups. Click Go To > Deployment > OS Management > Boot Servers. Click Go To > Deployment > OS Management > Boot Server Installation. Click Go To > Deployment > OS Management > Images. Click Go To > Deployment > OS Management > Image Capture. Click Go To > Deployment > OS Management > Image Deployment. Click Go To > Deployment > OS Management > Image Replication. Click Go To > Deployment > OS Management > Unattended Setup Image. Click Go To > Deployment > OS Management > Hardware Configuration Image. Click Go To > Deployment > OS Management > Software Modules. Click Go To > Deployment > Software Management > Common Agent Installation. Click Go To > Deployment > Software Management > Software Product Publishing. Click Go To > Deployment > Software Management > Software Product Unpublishing.
RISDM RISDM RISDM RISDM RISDM
RSM RISDM RISDM RISDM RISDM
RISD RISDM
RISDM
RISDM
RISDM RISDM
RISDM RISDM
RISDM
RISDM
RISDM
RISDM
RISDM
139
Table 31. Deployment applications (continued)

Provisioning Administrator RISDM Deployment Specialist RISDM Compliance Analyst Provisioning Configuration Librarian Automation Package Developer
Application Click Go To > Deployment > Software Management > Software Product Distribution. Click Go To > Deployment > Software Management > Software Product Installation. Click Go To > Deployment > Software Management > Software Product Upgrade. Click Go To > Deployment > Software Management > Software Product Uninstallation. Click Go To > Deployment > Software Management > File Distribution. Click Go To > Deployment > Software Management > File Publishing. Click Go To > Deployment > Software Management > File Unpublishing. Click Go To > Deployment > Software Management > Software Stack Distribution. Click Go To > Deployment > Software Management > Software Configuration Templates. Click Go To > Deployment > Patch Management > Windows Update Agent Installation. Click Go To > Deployment > Patch Management > Patch Publishing.
RISDM
RISDM
RISDM
RISDM
RISDM
RISDM
RISDM
RISDM
RISDM
RISDM
RISDM
RISDM
RISDM
RISDM
RISDM
RSM
RISDM
RS
RISDM
RISDM
RISDM
RISDM RISDM RISDM RISDM RISDM
Click Go To > Deployment > Patch RISDM Management > Patch Unpublishing. Click Go To > Deployment > Patch Management > Patch Distribution. Click Go To > Deployment > Patch Management > Patch Installation. RISDM RISDM
Click Go To > Deployment > Patch RISDM Management > Patch Uninstallation.
Table 32. Discovery applications

Provisioning Administrator RISDM Deployment Specialist Compliance Analyst RISDM Provisioning Configuration Librarian RISDM Automation Package Developer R
Application Click Go To > Discovery > Provisioning Discovery > Discovery Wizards. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations.
RISDM
RISDM
RISDM
140
Table 33. IT infrastructure applications

Provisioning Administrator RISDM Deployment Specialist RSM Compliance Analyst RC Provisioning Configuration Librarian RISD Automation Package Developer R
Application Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. Click Go To > IT Infrastructure > Provisioning Inventory > File Repositories. Click Go To > IT Infrastructure > Provisioning Inventory > Access Control Lists. Click Go To > IT Infrastructure > Provisioning Inventory > Firewalls. Click Go To > IT Infrastructure > Provisioning Inventory > Load Balancers. Click Go To > IT Infrastructure > Provisioning Inventory > Routers. Click Go To > IT Infrastructure > Provisioning Inventory > Switches. Click Go To > IT Infrastructure > Provisioning Inventory > Unknown Resources. Click Go To > IT Infrastructure > Provisioning Inventory > Virtual LANs. Click Go To > IT Infrastructure > Provisioning Inventory > Subnetworks. Click Go To > IT Infrastructure > Provisioning Inventory > Storage Area Networks. Click Go To > IT Infrastructure > Provisioning Inventory > Storage Pools. Click Go To > IT Infrastructure > Provisioning Inventory > Storage Managers. Click Go To > IT Infrastructure > Provisioning Inventory > Storage Subsystems. Click Go To > IT Infrastructure > Provisioning Inventory > Computer Templates. Click Go To > IT Infrastructure > Provisioning Inventory > Virtual Server Templates. Click Go To > IT Infrastructure > Provisioning Inventory > Storage Templates.
RISDM
RSM
RISD
RISDM
RISDM
RSM
RC
RISD
RISDM
RSM
RISD
RISDM
RISDM
RSM
RISD
RISDM
RISDM RISDM
RSM RSM
RISD RISD RISDM
RISDM RISDM RISDM
RSM RSM RSM
RISD RISD RISD RISDM
RISDM
RSM
RISD
RISDM
RSM
RISD
RISDM
RSM
RISD
RISDM
RISDM
RSM
RISD
RISDM
RISDM
RSM
RISD
RISDM
RSM
RISD
RISDM
RISDM
RISDM
RISDM
RISDM
141
Table 33. IT infrastructure applications (continued)

Provisioning Administrator RISDM Deployment Specialist RSM Compliance Analyst Provisioning Configuration Librarian RISD Automation Package Developer
Application Click Go To > IT Infrastructure > Provisioning Inventory > Blade Servers. Click Go To > IT Infrastructure > Provisioning Inventory > Power Units. Click Go To > IT Infrastructure > Provisioning Inventory > Terminal Servers. Click Go To > IT Infrastructure > Software Catalog > Software Products.
RISDM
RSM
RISD
RISDM
RSM
RISD
RISDM
RSM
RISD
Click Go To > IT Infrastructure > RISDM Software Catalog > Software Stacks. Click Go To > IT Infrastructure > Software Catalog > Software Product Import. Click Go To > IT Infrastructure > Software Catalog > Software Validation. Click Go To > IT Infrastructure > Software Catalog > Software Signatures. Click Go To > IT Infrastructure > Software Catalog > Patches. Click Go To > IT Infrastructure > Software Catalog > Patch Acquisition. RISDM
RSM
RISD RISDM
RISDM
RSM
RISD
RISDM
RSM
RISDM
RISDM RISDM
RSM
RC
RISD RISDM
Table 34. Security applications

Provisioning Administrator RISDM RISDM RISDM Deployment Specialist R Compliance Analyst R Provisioning Configuration Librarian R Automation Package Developer
Application Click Go To > Security > Provisioning Permission Groups. Click Go To > Security > Users. Click Go To > Security > Security Group.
Table 35. Task management applications

Provisioning Administrator Deployment Specialist RDM Compliance Analyst Provisioning Configuration Librarian Automation Package Developer
Application
RISDM Click Go To > Task Management > Activities and Tasks. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. RISDM
RDM
RISDM
RISDM
RISDM
142
Table 35. Task management applications (continued)

Provisioning Administrator RISDM Deployment Specialist RISDM Compliance Analyst Provisioning Configuration Librarian RISD Automation Package Developer RISDM
Application Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. Click Go To > Task Management > Provisioning Tasks > Provisioning Workflow Status.
RISDM
RM
RISDM
RISDM
RISDM
Types of provisioning groups for security groups

Security groups are based on Tivoli Provisioning Manager provisioning groups to identify the resources to be protected. There is a variety of provisioning groups that can be used for security purposes. Tivoli Provisioning Manager supports different types of provisioning groups as bases for security groups: Static groups Groups with members statically managed. An object is a member of a static group if and only if it is explicitly contained in the group. Typed static groups Contain the objects as its members with a specific type. When a static typed group is used for security purposes, a condition is created, and a predefined SQL query is generated, and associated with the condition. A condition specifies the objects to be protected, and it is later being used by security restriction that is associated with the security group. A security restriction specifies the permissions on the protected resources. Untyped static groups Members of an untyped static group can be of any type. When it is used for security purpose, no condition is created until the objects are added to the group. Condition is created when an object with a type that does not exist for the untyped static group is added to the group. The newly created condition has an SQL query specific to query object with a specific type. The condition is then associated to the security restriction. When the final object of a given type is removed from an untyped static group, the condition and the associated security restriction will not be removed. Similarly to the typed static group, a query will be generated for each condition created for untyped static group. Dynamic groups Contain queries that are specified by the user, and the membership information is calculated at run time. For example, the query can be to retrieve all computers with Windows OS. Typed dynamic groups In typed dynamic groups, queries must be typed. For a typed dynamic group, the type of the dynamic group has to be the same as the type of the query associated to the group. In terms of security, each condition created for the dynamic group will make use of the query directly. Members of the group are calculated at run times to determine what resources to be protected. Untyped dynamic groups In untyped dynamic groups, there is no type associated with the group; thus, it is not required for the query to be the same type of the dynamic group. This type of dynamic group is not supported for security purpose.
143
Table 36. Supported provisioning groups for security purposes. Static groups Typed Supported for security purposes Membership SQL Nesting group properties Yes Generated query Untyped Yes Generated query Typed Yes User specify No nesting group supported Dynamic groups Untyped No N/A N/A
Supported for Supported for security, nested group security, nested has to be the same groups can be of any type type, typed or untyped
Conditional user interface

You can customize the appearance and behavior of the user interface accessed by different users, based on their security group assignment. A conditional user interface helps to channel the appropriate data to the appropriate users. The data can be restricted in two ways: v By definition, members of a particular security group can only access applications that have been assigned to them by design. The security group definitions provided with Tivoli Provisioning Manager come with the specific application authorizations. For details, see Security groups and application access rights. v Configurable user access to particular fields, sections, and tabs can be adjusted to suit the needs of your organization environment. You can define the access rights and other attributes such as color, labels, and editing state of controls by setting conditions on particular user interface instance. For more information about the conditional user interface, see Conditional User Interface in Application Developer Guide.
Single Sign-on (SSO)

Single sign-on (SSO) is the ability of a user to log on once and access multiple applications without having to log on to each application separately. It is multiserver session-based authentication that allows Web users to log on once to WebSphere Application Server, and then access any other WebSphere Application Server (in the same DNS domain) that are enabled for single sign-on without having to log in again. When a protected resource is located on the plug-in enhanced WebSphere Application Server, a client requesting that resource can be required to perform multiple logons when accessing different secure applications. Each log on is likely to require different logon identities. The problem of administering and maintaining multiple logon identities can often be solved with a single sign-on (SSO) mechanism. SSO allows the user to access a resource using only one initial logon. Any further logon requirements for resources on the WebSphere Application Server are handled transparently to the user.
Configuring logout for single sign-on

For information about enabling or configuring SSO, see the WebSphere Application Server documentation.
144

Discovery is the capability to discover IT resources and their relationships. This kind of information is stored into the data model. In this way you can use provisioning to manage your IT environment. Today's networks make it difficult for enterprises to track their IT resources efficiently. Without resource information up-to-date, it is very challenging to perform any type of administration such as operating system migrations, configuration compliance, and IT resource management. New hardware is added and old hardware is removed from the enterprise all the time. Ongoing software changes are being made constantly. Discovery and inventory management help with the manual maintenance of resources with which you can plan and audit your resources and inventory for your IT infrastructure. You can efficiently track your IT resources using an automated hardware and software inventory of resources. Discovery provides a way to find out, or discover, when the configuration of a resource or software information in the data model has changed. Provisioning, using discovery methods, automates the tracking and management of changes in an IT enterprise. Provisioning can discover computers, network resources such as routers, firewalls, middleware software, business applications. You can use different discoveries depending on the kind of the resources you want to discover. Each method enriches the configuration information of the resource: network discovery methods detect new resources, while inventory discovery methods populate hardware and software configuration of the resources. To effectively manage IT resources in your data model, you need to keep their configuration information up-to-date and to discover new resources because they are added to the IT infrastructure often. To perform this task, you can schedule periodic discoveries with the appropriate discovery methods. For example, to detect new resources in the network, you must schedule a weekly network discovery, and to keep the hardware and software information of the managed computers up-to-date you must schedule a monthly inventory discovery. Discovery helps you accurately answer the following questions: v What hardware do I have? v What software do I have? v What are the relationships and dependencies? v How will changes impact my business? In addition to non-IBM discovery methods and discovery automation packages that can be used with provisioning, the following types of discovery methods are available: Provisioning network discovery v For detecting network resources (such as computers and switches) and a minimal set of configuration information needed to manage these resources (such as host name, IP address, operating system), you must provide the resource credentials when performing a network discovery, during which a default Service Access Point (SAP) is created for that resource, otherwise the discovery reports an unknown resource with its IP address only. Provisioning Inventory discovery v For discovering and keeping the hardware and software configuration of the computers up-to-date in your environment.
145
TADDM Discovery v For importing the information of IT resources and their relationships with Tivoli Application Dependency Discovery Manager (TADDM) into the data model. Microsoft Active Directory discovery v For discovering resources by organizational unit. v For discovering Microsoft Active Directory groups. v For discovering resource attributes defined in Microsoft Active Directory.
Discovery basics
Find out more about the discovery process, the key terms for discovery, who are the users that perform discovery, and what are the requirements that you need to verify before running discovery. Review the troubleshooting information and the log files names and location for this feature and also additional resources that help you complete your discovery tasks. v Process on page 147 v User roles on page 147 v Requirements on page 148 v Key terms on page 148 v Troubleshooting on page 149 v Log files on page 149 v Resources on page 150
146
Process
A typical discovery process using Tivoli Provisioning Manager is depicted in the following diagram:
Discover computers
Discover hardware and software
List of computers populates the data model
List of hardware attributes, software catalog, inventory of software populates the data model
Organize computers into groups
Report on inventory
Database
Legend
Provisioning Administrator Provisioning Configuration Librarian
You want to create an inventory of what devices are available in the enterprise, and which operating systems and software are on each device. The following discovery flow describes how Tivoli Provisioning Manager can automate discovery: 1. Your first step is to discover which computers exist within the IT enterprise. Perform a network discovery of your computers.Tivoli Provisioning Manager can discover the operating system information of the computers. 2. Next, you need to find out which hardware and software is installed on your resources. You will run another discovery, an inventory scan, to detect hardware and software information about each resource. 3. Tivoli Provisioning Manager generates an inventory of the discovered software, including discovered operating systems. This inventory is recorded in the data model in the software catalog.
4. You can now generate reports showing the current information about data center inventory, including reports on available software, currently installed software, and hardware activity. You can also generate reports showing the last discovery scan results by target computer and discovery scan type. The report data is extracted directly from the data model.
User roles
You must be assigned to the appropriate user role to perform discovery operations.
147
Table 37. User roles Role Provisioning Administrator Description of role v Discover and group target computers. v Set up servers and infrastructure, including the installation of the Tivoli common agent on targets computers. Provisioning Configuration Librarian Access permissions User has access to everything in the web interface. He can also create new users and assign access control to users.
v Own the inventory database and is User that manages all inventory aspects, but performs tasks related to responsible for maintaining its software or hardware inventory only. accuracy. He can manage discovery scans, the v Run, schedule, and edit discovery software catalog and the software scanning and inventory tasks. signatures. He can also generate reports related to inventory, and can update or delete records within the inventory database.
Requirements
User roles and requirements on page 153 Target computer requirements: Requirements for Windows target computers on page 556 Requirements for Red Hat Linux target computers on page 560 Requirements for SUSE Linux Enterprise Server (SLES) target computers on page 561 Requirements for AIX target computers on page 562 Requirements for Solaris Operating Environment target computers on page 563 Requirements for HP-UX target computers on page 565 v Software requirements on page 153 v Requirements for common agent installation on page 547
Key terms
Discovered resources A group of resources that have been successfully discovered by provisioning. Unknown resources A group of resources that provisioning cannot log on to, when performing a network discovery. Unknown resources are generated after running a network discovery or an initial discovery in the following cases: v When the discovery protocol used, RXA, is correct but the provided user credentials are wrong. v When the discovery protocol used, RXA, is correct but the resource is not supported. v When a RXA-based network discovery is submitted without specifying the user credentials. v When the provided IP address can be reached by the ping command, but provisioning cannot discover any other information about the resource. Discovery wizard Using the discovery wizard application you can perform a more generic discovery.
148
Troubleshooting
v Troubleshooting discovery on page 239 v Log files for troubleshooting discovery on page 244 v Discovery problems and limitations on page 245 v Discovery messages v Support information about discovery v Contacting support
Log files
Follow the steps below and review the indicated log files to recover from problems that you might encounter when running discovery: v For any discovery v For the Tivoli Provisioning Manager Inventory Discovery v For any Inventory Discovery if the Tivoli Common Agent is not installed
For any discovery: 1. Check the log files and/or the workflow logs to determine the problem. On the Tivoli Provisioning Manager server: v
Windows
%TIO_LOGS%\console.log
UNIX Linux $TIO_LOGS/console.log v v Workflow logs available from the web interface 2. If the Inventory Discovery is involved, perform the checks described for the Inventory Discovery.
3. Resolve the cause and then try again. For the Tivoli Provisioning Manager Inventory Discovery: 1. Check the log files and/or the workflow logs to determine the problem. 2. If Common Inventory Technology (CIT) is run under the Tivoli common agent (TCA), check also the TCA logs. On the Tivoli Provisioning Manager server: v
Windows
UNIX Linux $TIO_LOGS/console.log v v Workflow logs available from the web interface On the target computer:
Windows
%ProgramFiles%\IBM\tivoli\common\CIT\logs\ traceCIT.log
UNIX Linux /usr/ibm/tivoli/common/CIT/logs/ traceCIT.log v For the TCA-based Inventory Discovery, on the target computer:
v CA_HOME/logs/error-log-n.xml v CA_HOME/logs/trace-log-n.xml and n = 0,1,2,... Note: You can also set a higher trace level modifying the following file:
$CA_HOME/../../../cit/ config/CitTrace.properties
149
where the default value for the CA_HOME variable is: v

Windows
%ProgramFiles%\Tivoli\ep\runtime\agent
UNIX Linux /usr/tivoli/ep/runtime/agent v 3. Resolve the cause and then try again.
For any Inventory Discovery if the Tivoli Common Agent is not installed: 1. Check the log files and/or the workflow logs to determine the problem. On the Tivoli Provisioning Manager server: v TIO_LOGS\console.log v $TIO_HOME/tmp/cit_subagent/platform/target_id_timestamp Note: By default this directory is deleted. You should set a property to keep it. On the computer: v /tmp/cit_discoveryId 2. If the Inventory Discovery is involved, perform the checks described for the Inventory Discovery. 3. Resolve the cause and then try again.
Resources
To learn more about discovery, refer to one of the following resources: v Tutorial: Discovering your environment on page 230 v Tutorial: Replicating business applications from TADDM on page 234 v Regular discoveries on page 153 v Verifying discovered resources on page 227 v For a description of a field in the Tivoli Provisioning Manager console, press Alt+F1.
Related links Chapter 3, Discovering IT resources, on page 145 Requirements on page 152 Troubleshooting discovery on page 239 Tutorial: Discovering your environment on page 230 Tutorial: Replicating business applications from TADDM on page 234
Discovery process
Tivoli Provisioning Manager provides you with automated processes to discover devices and configuration changes for the computers, switches, subnetworks, software, and images within your environment. The following diagram depicts typical discovery processes using Tivoli Provisioning Manager:
150
Discover computers
Discover hardware and software
List of computers populates the data model
List of hardware attributes, software catalog, inventory of software populates the data model
Organize computers into groups
Report on inventory
Database
Legend
Provisioning Administrator Provisioning Configuration Librarian
You want to create an inventory of what devices are available in the enterprise, and which operating systems and software are on each device. The following discovery flow describes how Tivoli Provisioning Manager can automate discovery: 1. Your first step is to discover which computers exist within the IT enterprise. Perform a network discovery of your computers.Tivoli Provisioning Manager can discover the operating system information of the computers. 2. Next, you need to find out which hardware and software is installed on your resources. You will run another discovery, an inventory scan, to detect hardware and software information about each resource. 3. Tivoli Provisioning Manager generates an inventory of the discovered software, including discovered operating systems. This inventory is recorded in the data model in the software catalog. 4. You can now generate reports showing the current information about data center inventory, including reports on available software, currently installed software, and hardware activity. You can also generate reports showing the last discovery scan results by target computer and discovery scan type. The report data is extracted directly from the data model.
Populating the data model

To manage IT resources from Tivoli Provisioning Manager, using the discovery wizard you must perform an initial discovery of computers in your environment, discovering their operating systems and their software. You can populate the data model by performing the following tasks: 1. Run a discovery of networked resources on the environment using the discovery wizard as described in Discovery wizard overview on page 231. 2. Review the discovered resources. 3. (Optional) Install the Tivoli Common Agent on the discovered resources. 4. Initiate or schedule a hardware and software scan on the environment.
151
Scheduling discovery
Different sections of your environment will likely have different rates of change. Identifying operational groups on your network by IP addresses, IP address ranges, subnetworks, and subnet ranges, enables you to schedule partitions of your infrastructure to have different discovery schedules, as appropriate. You can specify which targets the discovery can be run against, you can specify ranges, or discover everything known to a specific discovery method. For example, depending on the size of your environment and your operational needs, you can schedule Tivoli Provisioning Manager to perform a full discovery once every week, complete a discovery of a network once every day, and so on. The discovery schedule can be set up to repeat at certain intervals or to run once.
Managing configuration changes in the data model

After the data model has been populated, you need to ensure that all changes made to resources are made to the data model as well. Note: Using Tivoli Provisioning Manager to perform discovery operations for the computer where Tivoli Provisioning Manager is installed is not supported.
Requirements
Before you start working with discovery, ensure that you meet all requirements. When you run a discovery it searches for resources that are unknown to Tivoli Provisioning Manager and adds them to the data model. The discovery updates the data model with any new or changed information.
Computer requirements
For details about the target computer requirements, see the following topics: Requirements for Windows target computers on page 556 Requirements for Red Hat Linux target computers on page 560 Requirements Requirements Requirements Requirements for SUSE Linux Enterprise Server (SLES) target computers on page 561 for AIX target computers on page 562 for Solaris Operating Environment target computers on page 563 for HP-UX target computers on page 565
Common agent requirements

The common agent is required to take advantage of all discovery features. For details about the common agent requirements, see Requirements for common agent installation on page 547. If you do not plan to install the common agent on computers, consider configuring OpenSSH and OpenSSL to secure communication between Tivoli Provisioning Manager and the computers. For information about performing these tasks, see the Tivoli Provisioning Manager information center. Note: If you are using OpenSSH: v Use version 4.4 or higher. Version 4.3 has a known issue that can cause Expect scripts that the provisioning server runs on target computers to fail. v Ensure that you use password authentication to secure communication between the provisioning server and the targets.
152

To perform the tasks in discovery, ensure that you have the required knowledge and access rights to perform your role.
Table 38. User roles Role Provisioning Administrator Description of role v Discover and group target computers. v Set up servers and infrastructure, including the installation of the Tivoli common agent on targets computers. Provisioning Configuration Librarian Access permissions User has access to everything in the web interface. He can also create new users and assign access control to users.
v Own the inventory database and is User that manages all inventory aspects, but performs tasks related to responsible for maintaining its software or hardware inventory only. accuracy. He can manage discovery scans, the v Run, schedule, and edit discovery software catalog and the software scanning and inventory tasks. signatures. He can also generate reports related to inventory, and can update or delete records within the inventory database.
Software requirements
Ensure that you are using supported software required for discovery.
Software requirements for running TADDM discovery

To perform TADDM discoveries, you must have Tivoli Application Dependency Discovery Manager (TADDM) version 7.1.2.6 or TADDM 7.2 installed in your environment. The computers for which you want to monitor software information must have been discovered by TADDM and the resulting information mapped and copied into the data model. By default, Tivoli Provisioning Manager 7.2 supports TADDM version 7.2. To enable TADDM version 7.1.2.6, some manual steps are required. For more information about the steps to perform, see TADDM discovery failure on page 256.
Software requirements for running Inventory discovery in a scalable distribution infrastructure

To perform any discovery, in particular an Inventory discovery, of the computers in a scalable distribution infrastructure ensure you meet the following requirements: v Install the Tivoli Common Agent on these computers. v Install a depot server in your environment.
Regular discoveries
Discovery is a periodic task that keeps the data model up-to-date as an IT resource changes. To be able to update and manage your resources in your data model, you need to periodically populate it by performing discoveries using the various available discovery methods appropriate for your enterprise. Discoveries can be scheduled to run automatically at a specified date and time and, if necessary, to repeat on a regular basis to collect the information required. You can use different discoveries depending on the kind of the resources you want to discover:
153
Network discovery If you want Tivoli Provisioning Manager to discover your IT assets and gather information about all the resources that can be found, such as their network interfaces and IP addressing information. Software discovery Knowing what type of software and the details about that software helps to automate the process of documenting computer and application configurations, mapping interdependencies, and tracking changes in real-time. If you want Tivoli Provisioning Manager to install and monitor software, then there are a number of discovery configurations you can use: v You can use the Tivoli Provisioning Manager Inventory discovery to perform a hardware or inventory scan 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. Note: It is recommended, for scalability issues, that you install the Tivoli Common Agent on the target computers to perform the inventory scan. The Tivoli Common Agent can be installed separately or installed when a computer is created using the Add Computer wizard. The Tivoli Provisioning Manager Inventory discovery discovers the following operating systems: Windows Linux UNIX AIX Solaris v You can use Microsoft Active Directory discovery to import all of your existing Microsoft Active Directory groups and computer information into Tivoli Provisioning Manager. v You can discover all your software resources defined in the Change and Configuration Management Database. You can also correlate with an existing software module for all discovered software installations. If an existing software module cannot be found, then a placeholder software module will be created to associate it with the discovered software installation. v There are also other different discovery applications to do inventory scans on VMware and cluster system management systems as well. The discovery of any software, operating system or otherwise, is created as a software resource and will be associated with an existing software product if there is an appropriate match and can be viewed on the software tab of the resource.
Network resource discovery

Provisioning includes a simple and fast approach to discover your network resources using the network discovery. It also allows you to perform network resource discovery using other discovery methods or applications that you want to use. The provisioning network discovery allows you to discover your IT infrastructure over Secure Shell (SSH), Server Message Block (SMB), and Simple Network Management Protocol (SNMP) protocols to find network resources. This integrated discovery capability is provided with the product and easy to configure and use. You can create a discovery configuration specifying what you want to discover and specify its scope. The scope defines the boundary of a network that provisioning can access during discovery. This is identified using IP addresses, IP address ranges, and subnets.
154
You can select the scope elements when initiating a discovery to optionally restrict the number of components and subnets explored. You might want to do this when you need to focus on gathering information about a particular portion of your infrastructure, and do not want to spend the time discovering your entire network. Provisioning network discovery is separated in the following two ways: Remote Execution and Access (RXA) discovery Discovers Windows, Linux, AIX, Solaris and HP-UX resources using RXA that identifies if your resources are working over SMB or SSH protocols. For this reason, ensure that at least one of these two protocols is active on your computers. To discover the maximum number of data, you can specify the user IDs and passwords of the computers to access and the related protocol used by the computers, or you can provide the RSA credentials to obtain the same result. This information is optional. If credentials are not correct, discovered computers are added to the Unknown Resources group. Unknown resources are resources to which a network discovery cannot logon, either because it is not using the appropriate credentials to access the resource, or because the logon service is down. If you do not enter any user IDs and passwords, then a basic discovery is performed and only limited information, such as the host name and operating system, might be retrieved. Note: When SMB or SSH discoveries are used, computer host names are matched using the following algorithm: 1. The discovery looks for an existing server in the Data Center Model (DCM) that has the same discovered NIC MAC address of the management interface. 2. If no match is found, the discovery looks for an existing server in DCM that has same IP address and host name. 3. If no match is found, it creates a new server in DCM. Simple Network Management Protocol (SNMP) discovery Discovers resources, switches, routers, and virtual LANs. Note: The SNMP Agent must be installed and configured on the target computer. For RXA discovery, discovered data includes host name, MAC address, IP address, NIC, SSH service access points, credentials for run and copy file commands, and the OS type. The OS type will be captured as a hardware resource in the discovered object. Having the OS type will allow the installation of the Tivoli Common Agent after discovery. When deciding which of the two provisioning network discovery methods to choose, consider the following. v RXA is the recommended method for discovering Windows, UNIX and Linux variant operating systems. v SNMP is the recommended method for discovering networking resources (including VLANs on switches). Although it can be used to discover resources as well, only SNMP credentials are created, whereas RXA credentials provide more computer management capability.
Running Tivoli Provisioning Manager RXA discovery

Provisioning can discover information including networked resources, their network interfaces, IP addressing information and creates a hardware resource that defines the operating system running on the target computer.
Before you begin

By default, up to 2000 addresses can be discovered when you run a discovery. If the total number of IP addresses returned from a specified IP range, group of computers, or subnetworks exceeds 2000
155
addresses, the discovery fails. You can change the limit using the global variable MaxIpNumber. Take into consideration that a large limit might impact the time it takes for a discovery to complete. 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Variables tab. 3. Search for the variable MaxIpNumber. If the variable does not exist, click New Row to create the variable and set Variable to the name MaxIpNumber and Component to Entire System. 4. Set the Value of the variable to maximum number of addresses that a single discovery run can discover. It also creates credentials for each resource object based on the credential information supplied in the provisioning network discovery configuration profile. After the installation has completed successfully, the provisioning network discovery can be used to discover your IT assets and gather information about them. You can assign the discovered computers to a provisioning group. The provisioning network discovery will discover the network's hardware and immediately populate the data model with this information. Note: The network discovery does not necessarily use the fully qualified domain name of the computer to register the discovered computer in the data model. If the Tivoli Provisioning Manager server cannot retrieve a fully qualified domain name because of its network configuration, the value used to register the discovered computer is the output of the host name command performed against the target computer, and this might be the computer short name. The administrator must supply both IP (Host names, IP ranges, subnets, or all) and credential information to set up the discovery configuration. Both IPv4 and IPv6 addresses are supported by the RXA network discovery. After a computer is discovered using this discovery configuration, the service access points and credentials will be set up for that target computer. Note: When discovery is run to find resources, all resources in the specified IP range will be discovered and populated to the data model, however, if one resource fails, the discovery process will continue. Check the provisioning workflow execution logs for specific details on individual resource failures. To run a network discovery using RXA, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. . 2. Click New Discovery Configuration 3. Enter a name and description of the discovery configuration. 4. In the Category list, click Hardware Discovery. 5. Select Discover Computers using RXA from the Method menu. 6. Click OK. 7. (Optional) Select from Add Computers to Group the name of the provisioning group to which you want to assign the discovered computers. When you enter a group name in Add Computers to Group, a list of the computer groups in your environment is displayed. 8. Enter any necessary discovery parameters and their values such as: v Host names v IP Address ranges
156
Note: In case IPv6 addresses have been enabled, a consistency validation occurs when you enter the start and end of each IP range. Both must be either IPv4 or IPv6. This same consistency validation occurs for both addresses and masks if you specify subnetworks. v Subnetworks v Credentials Note: Ensure that the credentials and passwords specified are for the target computer and not the domain administrator ID. Note: The parameters Host names, IP Address ranges, and Subnetworks can also be imported using a flat text file. In the text file the parameters you specify must be preceded by the following keys: #HOSTNAMES Enter this key before specifying a list of host names in the file. To specify the list of host names use the following format:
hostname1 hostname2
#IPRANGES Enter this key before specifying a list of IP address ranges in the file. To specify the list of IP address ranges use the following format:
9.168.123.172-9.168.123.176 9.168.123.180
#SUBNETWORKS Enter this key before specifying a list of subnetworks in the file. To specify the list of subnetworks use the following format:
192.168.123.172-255.255.255.224 192.168.123.150-255.255.255.248
9. Click Save
Results
You have now created a new discovery configuration.
What to do next
You can now schedule the discovery or run it immediately to update the data model. To run the discovery immediately, select the newly created discovery configuration, and click Run Discovery to start the operation. You can view the status of the discovery task by performing the following action: v Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking.
Discovering computers using the RSA credentials

Provisioning can discover target computers which can be managed through the SSH Service Access Point (SAP) using the RSA credentials.
Before you begin

The target computers must have a working SSH connection with the Tivoli Provisioning Manager server using RSA authentication. Both public and private keys must already be generated on the Tivoli Provisioning Manager server for the tioadmin user. Ensure that the public key is also stored on the target computers.
157
Note: The common agent installation does not support RSA credentials for Windows target computers. When the network discovery is performed using the RSA credentials, a set of password credentials for SMB must also be used to discover the Windows target computers. To run a network discovery using the RSA credentials, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. 3. 4. 5. . Click New Discovery Configuration Enter a name and description of the discovery configuration. In the Category list, click Hardware Discovery. Select Discover Computers using RXA from the Method menu.
6. Click OK. 7. Click the Credentials tab. 8. In the RSA Credentials section, specify the following information: RSA User Name The user name of a RSA credential. This identifies the user being associated with the RSA key mechanism. Passphrase (Optional) The pass phrase of a RSA credential. This is the extra text identifier to perform authentication. (Optional) Confirm Passphrase (Optional) Enter the pass phrase of a RSA credential again. Private Key File Path Specify from the pull-down menu the location (relative path) of the RSA credential private key. Note: The RSA private key file must be stored under the directory $TIO_HOME/keys/ my_directory. The file name must be identity. 9. Click Run Discovery. 10. (Optional) Check the provisioning task name and set the notification and scheduling options for the discovery. 11. Click Submit.
Results
You have created or updated the Service Access Point (SAP) of the target computers with the RSA authentication. You can now manage these target computers using the RSA authentication, instead of the credential and password authentication.
Specifying a new or an existing group when running the network discovery

You can now specify a new computer group when running the network discovery using the discovery wizard application. To specify a computer group when running the network discovery, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Wizards. Or access the discovery wizard application by clicking directly the Start Center link. 2. Click New .
158
3. Enter a name and a description for the new discovery. The Discovery Wizard is a required field, while the description field is optional. 4. From the Type menu select Computers with related hardware and software information. 5. From the Target Source Type menu select Run network discovery. 6. Click OK. 7. In the Select Targets page of the wizard, from the Add Computers to Group menu you can specify to which existing provisioning group of computers you want to add the discovered resources, or you can create a new group of computers. Note: The Add Computers to Group menu is also available when running the following ready-to-use network discoveries provided by provisioning: v Computer Discovery v Computer and Inventory Discovery v Computer Discovery, Tivoli Common Agent Installation and Inventory Discovery 8. Review and submit the discovery as usual.
Results
You have added the resources discovered by a network discovery to an existing or a new computer group.
Running SNMP discovery

Perform this hardware discovery if you need to discover network resources such as computers, switches and routers using the SNMP protocol. This type of discovery enables you to discover your IT infrastructure over the SNMP protocol to find computers and network resources. To perform the SNMP discovery you need to install and start the SNMP agent on the target systems you want to discover. Moreover you need the right community to access the SNMP protocol on the system to be discovered. The following information is discovered for each resource: v Host name v Network interface card (NIC) v Network interface (IP address) v Switch port v SNMP credentials Note: The following parameters v Switch port mode v Trunk encapsulation type cannot be discovered by a network discovery using SNMP. They can only be set manually. The following network devices are supported by the SNMP discovery: v Cisco Catalyst 2950 v Cisco Catalyst 3500XL v Cisco Catalyst 3550 v Cisco Catalyst 37xx Stack v Cisco Catalyst 6509 IOS
159
v v v v v
Cisco Router 2620 Cisco Router 2621 Cisco Router 3725 Cisco Switch Extreme Networks Switch
v Foundry Switch v IBM Gigabit Ethernet Switch Module To run a discovery using SNMP, perform the following steps: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. 3. 4. 5. . Click New Discovery Configuration Enter a name and description of the discovery configuration. In the Category list, click Hardware Discovery. Select Discover Devices (computers, switches, routers) using SNMP from the Method menu.
6. Click OK. 7. Enter any necessary discovery parameters and their values such as: v IP Address ranges Note: IPv6 addresses are not supported by the SNMP discovery. v Subnetworks v SNMP Communities Note: The parameters IP Address ranges and Subnetworks can also be imported using a flat text file. In the text file the parameters you specify must be preceded by the following keys: #IPRANGES Enter this key before specifying a list of IP address ranges in the file. #SUBNETWORKS Enter this key before specifying a list of subnetworks in the file. 8. Click Save. 9. To run the discovery immediately, select the newly created discovery configuration, and click Run Discovery to start the operation. 10. (Optional) Click Schedule to set some scheduling options for the discovery configuration. 11. Click Submit. The scope of the discovery is limited to the specified IP ranges and subnetworks.
Unknown resources overview

Unknown resources are resources that provisioning cannot log on to, when performing a network discovery. Unknown resources are generated after running a network discovery or an initial discovery in the following cases: v When the discovery protocol used (RXA) is correct but the provided user credentials are wrong. v When the discovery protocol used (RXA) is correct but the resource is not supported. v When a RXA-based network discovery is submitted without specifying the user credentials. v When the provided IP address can be reached by the ping command, but provisioning cannot discover any other information about the resource. To display and manage unknown resources from the web interface, perform the following action:
160
1. Click Go To > IT Infrastructure > Provisioning Inventory > Unknown Resources. The Unknown Resources page is displayed. These are the main actions that you can perform from the Unknown Resources page: v Run Discovery if you want to run an additional discovery against a set of unknown resources, when the previous discovery ended with an error. Depending on the type of error, solve the problem that caused it, as for example correct the wrong credentials or start the login services, and then rerun the discovery. v Ignore Resource if you no longer intend to manage the unknown resource. It might be a printer or any other type of resource that provisioning cannot manage. You can reactivate the ignored resource later on if you want to manage it again. v Reactivate Resource if you want to edit the unknown resource and manually assign a resource type to that resource. You can delete the unknown resources using the SOAP client interface. The workflow name to use is Unknown_IP_Device_Delete. The parameter for the workflow is the IP address. Running this workflow will delete the unknown resources in the data model. Reactivating an unknown resource: If you know which type of resource is an unknown resource, you can mark as active an unknown resource that you had previously ignored. To manually reactivate an unknown resource, perform the following steps: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Unknown Resources. The Unknown Resources page is displayed. 2. In the resource list, identify and select the unknown resource you want to modify, and click Reactivate Resource from the Select Action menu. Ignoring unknown resources: If you no longer intend to manage an unknown resource, you can decide to ignore it. That resource will be ignored in the future discoveries. To ignore an unknown resource from the web interface, perform the following steps: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Unknown Resources. The Unknown Resources page is displayed. 2. In the resource list, identify and select the unknown resource you no longer want to manage, and click Ignore Resource from the Select Action menu. 3. Enter a reason for which you intend to ignore that resource. 4. Click OK. Rediscovering unknown resources: Run again a discovery configuration against a set of unknown resources, when the previous discovery ended with errors. Depending on the type of errors, solve the problems, as for example correct the wrong credentials or start the login services and then, rerun the discovery again. To rediscover an unknown resource from the web interface, perform the following steps:
161
Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Unknown Resources. The Unknown Resources page is displayed. 2. In the resource list, identify and select the unknown resource or the subset of unknown resources you want to discover again, and click Run Discovery from the Select Action menu. If you specify a set of unknown resources that have been discovered using the same discovery method, you are redirected to a discovery wizard pre-filled with the last configuration parameters used, such as the IP address range and the user credentials. If you select a set of unknown resources that have been discovered using different discovery methods, you are redirected to the first page of the discovery wizard on which you need to manually enter the configuration parameters. 3. Perform a network discovery.
Provisioning Inventory discovery overview

To discover in small environments the hardware and software resources using the provisioning Inventory discovery, you no longer need to have the common agent installed. When you perform an agentless discovery, the Common Inventory Technology is downloaded on each computer and used to collect hardware and software information. This operation can burden networks because the Common Inventory Technology download is repeated for each computer. For this reason the completion time for data collection can grow significantly with the size of the network. However, if you do not modify the default settings, after the first inventory discovery ends, provisioning keeps Common Inventory Technology installed on each computer and uses it for future discoveries. For more information about how to modify these default settings, see Removing Common Inventory Technology installation on page 170. When you perform the Inventory discovery in agentless mode, and the Common Inventory Technology (CIT) needs to be installed on the target computer, ensure that the following space requirements for each platform are taken into account:
Table 39. Space requirements by operating system for installing CIT Supported operating system AIX HP PA-RISC HP Itanium Linux x86 Linux for Power PC Linux s390 Solaris Sparc Sun Solaris x86 Windows Space requirements for the CIT installation 27 MB 18 MB 48 MB 12 MB 11 MB 10 MB 17 MB 15 MB 9 MB
On any target computer, provisioning Inventory discovery uses a configuration file which defines the scanning capabilities. In it, there is a default value for scanning software signatures. To perform an Inventory discovery on target computers with Red Hat Enterprise Linux 4.0, 5.0, and 6.0 operating systems, you need to install on the target computers the following prerequisites:
162
Table 40. Provisioning Inventory discovery prerequisites Target computer platform Red Hat Enterprise Linux version 4 Red Hat Enterprise Linux version 4 64-bit Prerequisite compatibility pack compat-libstdc++-33 1. libgcc-3.4.3-9 2. compat-libstdc++-33 Install these compatibility packs in the order specified. Red Hat Enterprise Linux version 6 and 5 SuSE Linux Enterprise Server version 10 SP 3 64-bit compat-libstdc++-33 libstdc++33-32bit
To run an Inventory discovery without downloading the Common Inventory Technology, you need to install the common agent and ensure that its listening port is open on target computers, otherwise inventory scans will fail. The default common agent port number is 9510. Note: If you already installed the common agent, the Inventory discovery requires that a depot server is installed to work in a scalable distribution infrastructure (SDI). If you already installed the common agent but you do not have a depot server in your environment, you must remove the sdi_host Service Access Point (SAP) from the Credentials tab of the provisioning computer. In this way, the discovery will run using a deployment engine infrastructure (DE). In UNIX environments, when running an Inventory discovery on a computer without an agent installed, which has been defined providing the root credentials, the Inventory discovery returns all the available computer data, while performing this discovery on a computer without an agent installed, which has been defined providing general credentials, the discovery returns only the data it is authorized to access.
Provisioning Inventory discovery performed in SDI infrastructures

In a scalable distribution infrastructure (SDI), when you perform a provisioning Inventory discovery, you can set some global variables to modify the Inventory discovery behavior depending on your needs. When performing an Inventory discovery on target computers in a SDI environment, these are the global variables that you can set:
Table 41. Provisioning Inventory discovery variables for SDI environments Variable name Discovery.Upload.HostName Description The host name of the computer on which the discovery upload servlet resides. The port number of the computer on which the discovery upload servlet listens. How the host name of the computer, on which the discovery upload servlet resides, is resolved. The discovery upload servlet URI. Default value If not set, the default value used is localhost. If not set, the default value used is 9046. If not set, the default value used is true. Note: This value is ignored, if the SDI.Use.Hostname variable is set. If not set, the default value used is /poBox.
Discovery.Upload.HostPort
Discovery.Upload.Server. Resolve.IP Discovery.Upload.URI
Setting the path for the Common Inventory Technology installation

You can specify where the Common Inventory Technology software is to be installed when running a Tivoli Provisioning Manager Inventory discovery on computers that do not have the common agent installed, or on computers with the common agent installed.
163
Before you begin

For information about the parameters that you can set to modify the Common Inventory Technology installation path, see Tivoli Common Agent Stack configuration template parameters on page 633. If you want to specify the path for the Common Inventory Technology installation, perform the following steps:
Procedure
Click Go To > Administration > Provisioning > Provisioning Global Settings. Click the Variables tab. Click New Row. In the Variable field, type the appropriate variable name, depending on your operating system. For Windows, the variable name is Cit_agentless_win_install_path. For UNIX and Linux, the variable name is Cit_agentless_unix_install_path. 5. In the Component list, select Entire system. 6. In the Value field, type the path where you want the Common Inventory Technology software to be installed. 7. Click Save. 1. 2. 3. 4.
Results
If these variables are not specified, Tivoli Provisioning Manager uses the following default paths: v (For Windows) %PROGRAMFILES%\tivoli\cit v (For UNIX and Linux) /opt/tivoli/cit
Discovering hardware using provisioning Inventory discovery

Provisioning can discover hardware resources using the Tivoli Provisioning Manager Inventory Discovery. Knowing what type of hardware resources and the details about that hardware helps to automate the process of documenting computer and application configurations, mapping interdependencies, and tracking changes in real-time. As part of the product installation, there is an existing provisioning Inventory discovery configuration provided, which is installed and configured. You can use it to run a Tivoli Provisioning Manager Inventory Discovery. If you want to run an Inventory scan on a specific computer, using the default discovery configuration provided with the product, perform the following steps: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. From the Select Action menu, click Run Discovery. The default values of this provided discovery configuration are the hardware and software signatures. You can also perform this action from the Provisioning Group application for a computer group or an untyped group containing computers. If you want to create a discovery configuration, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. . 2. Click New 3. Type the name and description for the inventory scan. 4. Click Hardware Discovery.
164
5. In the Method field, select Tivoli Provisioning Manager Inventory Discovery. 6. Click OK. 7. Select the type of discovery you want to perform: hardware discovery, software discovery, or both. 8. Click Save .
Results
You have now created a discovery configuration.
Example
The following table displays hardware information with examples that can be discovered with provisioning Inventory discovery:
Table 42. Hardware discovery types and examples Resource Computer Types Manufacturer Version Serial number Type Family Name Architecture Type Brand Model Disk Disk Disk Disk Disk Disk size security order model serial number manufacturer Examples IBM Phoenix FirstBIOS ThinkPad 99RCGV 2373 Windows Microsoft Windows 2003 Intel win2k3-2 IBM -[622158G]56411291648 bytes Yes 0 HTS726060M9AT00 230089-DK-00 Hitachi cdrom 1 MATSHITA MATSHITA UJDA755zDVD/ CDRW G3907 IBM 80 18 2 3071,44 MB Pentium M Intel 1700 32-bit 1 1 1
Platform
Disk
CD-ROM
Name Order Manufacturer Model Model Manufacturer Cylinder Sector Head Size Name Family Frequency Type corePerPackageCount logicalProcPerCore activeCoreCount
Floppy
Ram CPU
165
Table 42. Hardware discovery types and examples (continued) Resource Memory module Types Module size Max module size Socket name Packaging Memory type Note: This data is returned only for specific platforms. The currently supported platforms are Linux and Windows X86 workstations. Manufacturer Name Year manufactured Serial number Size Adapter name Colors Bios version Type Subtype Code page Examples 512 MB 1024 MB DIMM 1/Bank 0/1 SODIMM Synchronous
Monitor
IBM254D ThinkPad LCD 1400 x 1050 2004 4D:25:d400000 15 inch ATI MOBILITY FIRE GL T2 16777216 ati2mtag_M10GL/oem40.inf Standard 101/102-Key or Microsoft Natural PS/2 Keyboard Enhanced (101- or 102-key) 00000409 3 USB Human Interface Lexmark 3200 Color Jetprinter LPT1 My computer Lexmark 3200 Color Jetprinter Agere Agere Systems AC'97 Modem Agere modem Internal Modem COM3 115200 mbs 8N1 p123a psprint1:p123a IBM Infoprint Color 8 IBM Infoprint Color 8 2.0 1 USB Human Interface Device E:\ OS/2 HPFS | Win NTFS 638476288 bytes 17573036032 bytes 99RCGVH 50% 50% 50%
Video
Keyboard
Mouse Local printer
Buttons Model Name Port name Description Driver name Manufacturer Description Provider name Modem name Modem type Port Port speed Port settings Name Port name Description Driver name Version Port Production fsMountPoint: File system type: Free size: Total size: Serial number Node capacity Capacity sharePoolCapacity
Modem
Network printer
USB
Partition
LPAR
166
Table 42. Hardware discovery types and examples (continued) Resource Bios Types Vendor Version Power-on password Note: This resource contains data on the operating system only on System Management Basic Input/Output System (SMBIOS)-compliant systems. Locale Time zone Daylight Mac Model Type Manufacturer Connector Type Name Revision Other network resources Network interface IP Gateway IP Subnet mask IP Computer host name Mac address DHCP enabled Examples IBM 1RETDIWW (3.14) Disabled
Regional
English_Canada.1252 Eastern Standard Time Eastern Daylight Time 005056906307 Intel(R) PRO/1000 MT Ethernet Adapter Intel Ethernet 802.3 LSI LSI53C1020/1030 (PCI-X to Ultra320 SCSI Controller) 0x01
Network interface card
PCI device
The following table displays: v Names of the hardware discovery attributes v Descriptions of the hardware discovery attributes v Default unit of measures stored in the data model v Default unit of measures displayed by the Hardware tab of the Computer properties on the web interface.
Table 43. Hardware discovery attributes, descriptions, and default unit of measures Unit of measures stored in the data model Mega Herz (MHz) Bytes Unit of measures displayed by the web interface Mega Herz (MHz) This value is converted into MB or GB, depending on its size. This value is converted into MB or GB, depending on its size. Mega Bytes (MB) Mega Bytes (MB)
Hardware attributes cpu.frequency disk.size
Description The CPU speed in MHz The size of a physical hard disk
memory.size
The computer physical memory
Bytes
memoryModule.moduleSize MB memoryModule.maxModule SizeMB
Memory size in each memory module Maximum capacity of the memory for each memory module
Mega Bytes (MB) Mega Bytes (MB)
167
Table 43. Hardware discovery attributes, descriptions, and default unit of measures (continued) Unit of measures stored in the data model Inches Bits per second (bps) Bytes Unit of measures displayed by the web interface Inches Bits per second (bps) This value is converted into MB or GB, depending on its size. This value is converted into MB or GB, depending on its size.
Hardware attributes monitor.sizeInches modem.portSpeed partition.totalSize
Description The size of the monitor The modem port speed The total size of the partition
partition.freeSize
The total available disk space in the partition
Bytes
Note: For hardware component discovery, the unit of both disk size and RAM size are in bytes.
What to do next
You can now schedule the discovery or run it immediately to update the data model. To run the discovery immediately, select the discovery configuration, and click Run Discovery to start the operation. If available, select the targets that you want to run this discovery on. Note: For better performance, if you are selecting multiple targets, you can change the default concurrency level from 5 to a specific number. The concurrency level need not match the number of targets. To 1. 2. 3. make this change: Click Go To > Administration > Provisioning > Provisioning Global Settings. Click Variables. Expand default concurrency level.
4. Change the Value field to the amount that you want. For example, for 4 targets, enter 2 and click Save. You can view the status of the discovery task by clicking Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. Verifying the discovery for dual core processors: There are two scenarios where the inventory scan can show multiple processors found during the discovery process. 1. If the target computers that were discovered during an inventory scan have multiple CPUs, the scan will describe each processor information in a specific CPUn resource. 2. If a virtual server is running the provisioning Inventory discovery, the node capacity that contains the number of physical processors on the computer and the LPAR capacity (the number of physical processors dedicated to the logical partition or virtual workstation) is shown. For example, lpar.nodeCapacity=4.000000 lpar.capacity=2.000000
168
indicates that there are a total of four CPUs in the computer, and two of them are dedicated to this virtual workstation.
Discovering software using the provisioning Inventory discovery

Provisioning can discover software on resources using the Tivoli Provisioning Manager Inventory Discovery. Knowing what type of software and the details about that software helps to automate the process of documenting resource and application configurations, mapping interdependencies, and tracking changes in real-time. As part of the product installation, there is an existing Inventory discovery configuration provided, which is installed and configured. You can use it to run a Tivoli Provisioning Manager Inventory Discovery. The provisioning Inventory discovery discovers the following operating systems: v Windows v Linux v UNIX v AIX v Solaris If you want to run an Inventory scan on a specific computer, using the default discovery configuration provided with the product, perform the following steps: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Select the computer from the list. 3. From the Select Action menu, click Run Discovery. You can also perform this action from the Provisioning Group application for a computer group or an untyped group containing computers. If you want to create a discovery configuration, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. 3. 4. 5. 6. 7. 8. . Click New Type the name and description for the inventory scan. Click Software Discovery. In the Method field, select Tivoli Provisioning Manager Inventory Discovery. Click OK. Select the type of inventory scan you want to perform. If hardware, software, or both. Under Software, choose to scan the software by one of the following methods: v Use registry: Scans the registry of the resources. v Use software signatures: Scans for all available software signatures. Note: This will run an inventory scan to a target using all defined signatures in the signature catalogue to find any matches. It might take some time to complete the scan. v Use selected software signature: Filters by signature type. If this option is selected, then select the type of signature to search on from the list. Note: If you need to discover software on the same targets using both the registry and software signature software scan options, you must create two separate discovery configurations to run against the targets. Otherwise, the discovered software resources found during the first discovery will be replaced the second time you run discovery with the different software scan options.
169
9. Click Save
Results
What to do next
You can now schedule the discovery or run it immediately to update the data model. To run the discovery immediately, select the newly created discovery configuration, and click Run Discovery to start the operation. Note: For better performance, if you are selecting multiple targets, you can change the default concurrency level from 5 to a specific number. The concurrency level need not match the number of targets. To make this change: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click Variables. 3. Expand default concurrency level. 4. Change the Value field to the amount that you want. For example, for 4 targets, enter 2 and click Save. You can view the status of the discovery task by performing the following action: v Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking.
Removing Common Inventory Technology installation

You can remove the Common Inventory Technology software which was installed when running a provisioning Inventory Discovery on computers on which the common agent was not installed. If you want to remove this software, perform the following steps:
Procedure
1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Variables tab. 3. In the variable list, expand the CIT_UNINSTALL variable, which allows you to remove the Common Integration Technology software from the computers where this software has been installed during a provisioning Inventory Discovery. 4. Type true. 5. Click Save.
Results
The Common Integration Technology software is removed from the computers.
Adding software signatures

A software signature is a set of unique information that identifies a software application, such as the name, version, and file size of an application. You can associate one or more software signatures with a piece of software for scanning a target computer or a resource group. Adding custom software signatures using the web interface:
170
You can select one or more software signatures to be used for scanning a target computer or a resource group. You can use preinstalled software signatures or specify a subset of the software signatures to customize your inventory scan. Tip: The inventory scan will be faster if you only choose a subset of the software signature to be scanned on targets. Software signature correlation with a software definition (software module) can be created by using the software signature management feature. When the correlation is created, the software signature scan will find an existing software signature. It will then use this correlation to find which software module that this discovered software installation belongs to. Based on this information, the discovered software installation will be associated with a software module using this software signature correlation. To add a custom software signature in the web interface: Procedure 1. Click Go To > IT Infrastructure > Software Catalog > Software Signatures. 2. Click New signature. to create a new software signature, or modify to change an existing software
3. Specify the appropriate information such as software signature, software name, software version, platform, and variables. For example, Match Software Signature By supports: v by File Size v by Existence of OS registry key such as in the Windows registry v by Registry Key such as key name, entry, and value in the Windows registry 4. Click Save Results This information will be used to create a software signature, which can be used to scan a target computer to find a match. If there are no cached software signature files available on the file system, the user is required to run the importSoftwareSignature command in order to refresh the signature caching under %TIO_HOME%\tmp folder.. Only one set of signature caching files are created per OS. Refresh the signature caching files using the web interface: Tip: The inventory scan will be faster if you only choose a subset of the software signature to be scanned on targets. To refresh the signature caching files in the web interface: Procedure 1. Click Go To > IT Infrastructure > Software Catalog > Software Signatures. 2. From the Select Action list, click Refresh Signature Caching. Results This will refresh the signature caching files on the TPM server and will be used by the TPM inventory scan. This command will update the signature caching files from the file system that are stored in %TIO_HOME%\tmp Associating software signatures using the command line:
171
You can associate a specific software signature to an existing software definition from the command line by importing an XML file with the required information. Before you begin
Windows 2008 Select the option Run as administrator for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide.
If you want to import your own software signature using the command line, you must create your own file with the XML description of the software definition and the software signature that you want to associate with it. Do not modify the IBM-software-custom-signature.xml file that is provided with the product. Important: In order for the import command to recognize an edited or newly created software signature file, it is recommended that you use an editor that supports UTF-8. For example, you can use <TIO_HOME>\tio\eclipse\eclipse.exe but not notepad.exe. If you must use notepad.exe, you must remove the three bytes (called BOM) that are inserted at the top of the file. To import a software definition with a software signature. Procedure 1. Create an XML file with the software definition that you want to associate with the software signature. In many cases, the XML is defined in the automation package for the software. Check the xml subdirectory for an XML file with the software definition. 2. Add a software-signature element to the software definition with the software signature that you want to associate with the software. The following example shows an XML file with an AIX 5.1 software definition. The software-signature element is the last element in the software definition. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE datacenter PUBLIC "-//IBM//DTD XML Import//EN" "xmlimport.dtd"> <datacenter> <software-module name="AIX 5L Version 5.1" version="5.1" title="AIX 5L Version 5.1" vendor="IBM" locale="en_US" is-device-model="AIX Operating System"> <software-capability type="OS" name="os.family" value="AIX"/> <software-capability type="OS" name="os.distribution" value="AIX 5L"/> <software-capability type="OS" name="os.name" value="AIX 5L Version 5.1"/> <software-capability type="OS" name="os.version" value="5.1"/> <software-capability type="OS" name="os.servicepack" value="ML8"/> <software-requirement type="HARDWARE" name="cpu.family"> <software-requirement-value value="powerpc"/> </software-requirement> <software-requirement type="HARDWARE" name="cpu.type"> <software-requirement-value value="32-bit"/> <software-requirement-value value="64-bit"/> </software-requirement> <software-resource-template name="AIX Installation" software-resource-type= "INSTALLATION" software-resource-device-model="AIX Operating System" srt-definition="/AIX Installation" multiplicity-type="One" software-configuration-type="Regular" is-selected="true" is-default="true" is-deployable="true"> </software-resource-template> <software-signature signature-guid="bc.62.8b.f1.05.eb.11.db.a3.14.00.02.55.56.f2.7d" /> </software-module> </datacenter>
172
3. Import the file with the xmlimport command.

Windows
%TIO_HOME%\tools\xmlimport.cmd file:file name

UNIX
$TIO_HOME/tools/xmlimport.sh file:file name Where file name is the name of your XML file. Results The software signature is added to the software definition, which can be used to scan a target computer to find a match. Creating a custom software signature using the command line: You can create a custom software signature and import it using the importSoftwareSignature command. The importSoftwareSignature command will create a set of software signature caching files which will be used by inventory discovery to improve runtime performance. Before you begin
Create a custom software signature, then import it. When importing software signatures in an XML file, the GUID value need not be defined, or can be defined based on some unique parameters that you choose. You can create your own GUID value as part of the signature, if it is unique in scope, and then import it into the target computer. Or you can remove the signature-guid tag from the XML file, and have the import create a GUID value for this signature. Procedure 1. Create a software signature XML file. You can use the %TIO_HOME%\xml\samplebook\IBM-softwarecustom-signature.xml as a sample file to base your software signature XML file. Do not modify the IBM-software-custom-signature.xml file. 2. Import the software signature file with the importSoftwareSignature command:
Windows
From the %TIO_HOME%\tools directory, type:

Linux
importSoftwareSignature.cmd filename true

UNIX
From the $TIO_HOME/tools directory, type:
./importSoftwareSignature.sh filename true
Where filename is the fully qualified path of your software signature file and true means the signature type is custom. 3. After the signature is loaded into TPM server, the importSoftwareSignature command will create a set of signature caching files under the %TIO_HOME%\tmp directory. Only one set of signature caching files are created per OS. 4. Run the TPM inventory discovery from either the discovery wizard or from the TPM inventory discovery configuration page. The signature caching files on the file system under the %TIO_HOME%\tmp directory are used during the inventory discovery.
173
Results The software signature is added to provisioning. Refresh the signature caching files using the command line: Tip: The inventory scan will be faster if you only choose a subset of the software signature to be scanned on targets. Procedure To refresh the signature caching files in the command line: Windows From the %TIO_HOME%\tools directory, type:
importSoftwareSignature.cmd -UpdateSigCacheOnly
UNIX Linux
From the $TIO_HOME/tools directory, type:
./importSoftwareSignature.sh -UpdateSigCacheOnly
Results This will refresh the signature caching files on the TPM server and will be used by the TPM inventory scan. This command will update the signature caching files from the file system that are stored in %TIO_HOME%\tmp
Modifying the configuration file for software signature inventory scanning

On any target computer, Inventory discovery uses a configuration file which defines the scanning capabilities. In it, there is a default value for scanning software signatures. If you initiate a provisioning Inventory discovery scan for an already existing signature within 60 minutes of the last scan, then the scan would not be successful and use the cached value from the previous scan. You can change the default values in the configuration file if you want to perform scanning more frequently than this default value. To change the default value:
Procedure
1. Open the configuration file TPMconfig.xml in: v
Windows
\Program Files/tivoli/cit/bin/
Linux v /opt/tivoli/cit/bin/ 2. Find the attribute <Atribute name="maxDataAge" value"60">.
3. Change the value.
Results
You have now updated the default settings.
What to do next
You can now schedule the discovery or run it immediately to update the data model. To run the discovery immediately, on the newly created discovery configuration, click Run Discovery to start the operation. If available, select the targets that you want to run this discovery on.
174
Note: For better performance, if you are selecting multiple targets, you can change the default concurrency level from 5 to a specific number. The concurrency level need not match the number of targets. To 1. 2. 3. 4. do make this change: Click Go To > Administration > Provisioning > Provisioning Global Settings. Click Variables. Expand default concurrency level. Change the Value field to the amount that you want. For example, for 4 targets, enter 2. .
5. Click Save
You can view the status of the discovery task by performing the following action: v Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. You can also specify in the configuration file the directories to be excluded from the scan if you want to perform scanning excluding specific directories on the target computer. To specify the directories to be excluded from the scan: 1. Open the configuration file TPMconfig.xml on the target computer. 2. Locate the FSScan section of the file, which is the section that provides configuration information for the file system scanner. 3. Find the attribute excludeDirectory. 4. Edit the value for this attribute as follows:
<Attribute name="excludeDirectory" value="SystemDrive:/directory_name"/>
Note: Wildcards are also supported.
Custom inventory extensions

Custom inventory extensions are used to perform custom inventory scans. You can define inventory extensions when you want to discover on target computers any information that is not discovered by the Tivoli Provisioning Manager Inventory Discovery. To use a custom inventory extension, perform the following steps: v Set up the environment to create the inventory extension v Create the inventory extension on page 181 v Run the Inventory Discovery with the inventory extension on page 183 v Set up the environment to run the custom report on page 183 v Add the custom report to the list of reports on page 184 v Run the custom report on page 184 to display the information collected on the target computers by the inventory extension. Set up the environment to create the inventory extension: Before creating the inventory extension, you must perform the following steps to set up the environment. On the Tivoli Provisioning Manager server: 1. Create a custom table in the data model on page 176 to contain the collected information. 2. Create the pre and post scripts for the target computers on page 177 and distribute them for each target computer platform on which the inventory extension will run. 3. Create the properties file for the inventory extension on page 179. In the property file you define:
175
v v v v
The The The The
name of the inventory extension. name of the data model table containing the collected information. full path name of the scripts to be used for each platform. full path name of the output file containing the information collected on the target computer.
On each target computer: v Create the output files for the inventory extension data on page 178. Create a custom table in the data model: Before creating the inventory extension, you must create a custom table in the data model to contain the collected information. You can use the same table also to run reports generated by different inventory extensions. Before you begin When creating the custom tables in the data model, ensure that you follow these rules: v A column named discovery_id is mandatory and a foreign key to the discovery table must be set. v A column named server_id is mandatory and a foreign key to the server table must be set. When creating the custom tables, also the following rules are recommended: v Set the discovery_id column as not nullable. v Set the server_id column as not nullable. v Cascade the delete constraints on server_id and discovery_id. To create a custom table in the data model to contain the collected information, perform these actions: 1. Log on as Windows Administrator, or root for UNIX platforms, to the Tivoli Provisioning Manager server command line. 2. Create an SQL script file named my_table.sql. A sample SQL script file is the following:
DROP TABLE MY_TABLE; CREATE TABLE MY_TABLE( discovery_id server_id parameter endpoint network_interface value ); BIGINT NOT NULL, BIGINT NOT NULL, VARCHAR(255), VARCHAR(255), VARCHAR(255), VARCHAR(255)
ALTER TABLE my_table ADD FOREIGN KEY (server_id) REFERENCES SERVER(server_id) on DELETE CASCADE; ALTER TABLE my_table ADD FOREIGN KEY (discovery_id) REFERENCES DISCOVERY(discovery_id) on DELETE CASCADE; COMMIT;
3. On Windows platforms, in a command line window enter the command:

set db2instance=ctginst1
then type db2cw to open a new window from which you can run DB2 commands. On UNIX platforms, run the command:
su - ctginst1
176
4. In the new window, enter the command:

db2 connect to maxdb71 user maximo using xxx
where xxx Is the password associated to the Maximo user. 5. When you are connected to the database, enter the command:
db2 -tvf C:\myfilename.sql
where C:\myfilename.sql Is the full path name associated to your SQL script file. Create the pre and post scripts for the target computers: Create pre and post script files for each target platform where the inventory extension will run. Procedure 1. Create pre and post script files for each type of operating system on which you plan to run the inventory extension. You might use the pre script file to prepare the target computer to run the inventory extension. You might use the post script file to clean up the target computer after the inventory extension has been run. The pre and post script files run if they are commented out in the properties file you create for the inventory extension. 2. Manually distribute the scripts on the target computers on which the inventory extension will run. Ensure that the script files are the same files that you created for the operating system installed on the target computer. 3. Test on each target system that these script files run correctly. Example The following is a sample pre script file for Windows:
echo "Prescript start.....creating c:\test\my_table.windows.mif.backup" copy c:\test\my_table.windows.mif c:\test\my_table.windows.mif.backup echo "Postscript ends" EXIT
The following is a sample post script file for Windows:

echo "Postscript start.....deleting c:\test\my_table.windows.mif.backup" del c:\test\my_table.windows.mif.backup echo "Postscript ends" exit 0;
The following is a sample pre script file for UNIX:

#!/bin/bash echo "Prescript start.....creating /home/test/my_table.mif.backup" cp /home/test/my_table.mif /home/test/my_table.mif.backup echo "Prescript ends" exit 0;
The following is a sample post script file for UNIX:

#!/bin/bash echo "Postscript start.....deleting /home/test/my_table.mif.backup" rm /home/test/my_table.mif.backup echo "Postscript ends" exit 0;
177
Create the output files for the inventory extension data: The output file for the inventory extension custom data must be written in XML data format and must follow specific syntax rules. For compatibility reasons also the MIF file format is supported. The MIF file is automatically converted into XML format when the discovery configuration is run. When you define the XML output file for the inventory scan custom data, ensure that you follow these syntax rules:
<?xml version="1.0" encoding="UTF-8"?> <!ELEMENT custom-data (custom-table+)> <!ELEMENT custom-table (string-column+ | integer-column+)+> <!ATTLIST custom-table name CDATA #REQUIRED > <!ELEMENT integer-column EMPTY> <!ATTLIST integer-column name CDATA #REQUIRED length (32 | 64) #REQUIRED value CDATA #IMPLIED > <!ELEMENT string-column EMPTY> <!ATTLIST string-column name CDATA #REQUIRED length CDATA #IMPLIED value CDATA #IMPLIED >
The following is a sample XML file:

<custom-data> <custom-table name="my_table"> <string-column name="Parameter" length="255" value="parameter1" /> <string-column name="endpoint" length="255" value="endpoint_test" /> <string-column name="network_interface" length="255" value="eth0" /> <string-column name="value" length="255" value="9.168.100.80" /> </custom-table> </custom-data>
The following is a sample MIF file:

Start Component Name = "my_table.mif" Start Group id = 1 Name = "my_table" Class = "test_class" Start Attribute Name = "Parameter" Id = 1 Type = String(255) value = "rhel5_parameter1" End Attribute Start Attribute Name = "endpoint" Id = 2 Type = String(255) value = "rhel5_endpoint_test" End Attribute Start Attribute Name = "network_interface" Id = 3 Type = String(255) value = "rhel5_eth0"
178
End Attribute Start Attribute Name = "value" Id = 4 Type = String(255) value = "9.168.100.40" End Attribute End Group End Component
Results The output file that you created is the file that contains the data that is read by the inventory extension and saved into the custom table when the discovery configuration is run. It is your responsibility to create this file to satisfy your needs. Create the properties file for the inventory extension: Create a property file for the inventory extension in which you specify: v The name of the inventory extension. v The name of the table containing the collected data. v A specific stanza for each target platform where the inventory extension will run. Each specific stanza might contain any combination of pre, post, and output file information. The following is a sample properties file named my_file.properties:
# Name of the extension # # This is the name of the inventory extension that will be created. When you create the inventory extension also a # Discovery Configuration named <extName>_Discovery will be created. # You will then run that Discovery Configuration to collect data on the targets. # You can add this inventory extension also to other Discovery Configurations from the TPM Web interface. # extName=my_inventory
# Description of the extension # # This will be the name of the custom report that you will run to see the data collected on the targets by the inventory extension # extDescription=my inventory extension data
# Table fields # # This is the name of the custom table that will contain the data collected by the inventory extension # TABLE_1.NAME=my_table
# # Full path names on the targets of pre, post and output files # # Files for AIX operating systems targets
179
AIX=yes #pre_aix=/home/test/prescript.sh out_aix=/home/test/my_file.mif #post_aix=/home/test/postscript.sh # Files for HP-UX operating systems targets HPUX=no #pre_hpux=/home/test/prescript.sh out_hpux=/home/test/my_file.mif #post_hpux=/home/test/postscript.sh # Files for Solaris operating systems targets SOLARIS=no #pre_solaris=/export/home/test/prescript.sh out_solaris=/export/home/test/my_file.xml #post_solaris=/export/home/test/postscript.sh # Files for Linux operating systems targets LINUX=yes pre_linux=/home/test/prescript.sh out_linux=/home/test/my_file.xml post_linux=/home/test/postscript.sh # Files for Windows operating systems targets WINDOWS=yes #pre_windows=c:\\test\\prescript.windows.bat out_windows=c:\\test\\my_file.windows.mif #post_windows=c:\\test\\postscript.windows.bat # This is a dummy entry that you might use to address operating systems other than those selected above # # to use this entry set Unknown=yes and specify full path names for pre, post, and output files # Unknown=no pre_unknown=dummy out_unknown=dummy post_unknown=dummy
The following considerations apply to the properties file: v The extension name is a required parameter, but the extension description is optional. v The property names are not case sensitive. In the Table list section of the file, the following structure is supported:
# Table list TABLES = my_table,another_table
Note: This is a newer format. The older format was:

# Table list TABLE_1.NAME = my_table TABLE_2.NAME = another_table
Manually create the custom tables in the database. The following restrictions apply to this format: v The numbering following the TABLE tag must start from 1. v The numbering following the TABLE tag must be sequential.
180
The following considerations apply to the Operating System sections of the file: v These sections specify, for each operating system, if this inventory extension applies to that specific operating system. v If the section applies to the operating system (operating_system = yes), the command parses the pre, out, and post properties to enter the information in the appropriate files for that operating system. v If the section does not apply to the operating system (operating_system = no), the pre, out, and post properties are not read. v The Unknown section contains the default values for all the undefined operating systems. Create the inventory extension: Create the inventory extension to be used to collect the requested information about the target computers. To create the inventory extension, perform the following steps: Procedure 1. Log on as Provisioning Administrator (tioadmin) to the Tivoli Provisioning Manager server command line. 2. Run the InventoryExtension create command, as described in the inventoryExtension create command. 3. Verify that the inventory extension was created successfully: a. Check if the InventoryExtension create command output ends successfully. b. Run the InventoryExtension list command to check if the inventory extension is listed. c. For each inventory extension you create specifying that the report associated to the extension must be created, two files are generated named my_inventory.rptdesign and my_inventory.xml. Check if these files have been created in the TIO_HOME/tmp directory. d. Log on as maxadmin to the Tivoli Provisioning Manager Web interface. e. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. f. Filter for the inventory extension name. The my_inventory_Discovery configuration is displayed. Migrate inventory extensions from version 5.1.1.2: If you have Tivoli Provisioning Manager 5.1.1.2 inventory extensions you want to migrate to Tivoli Provisioning Manager 7.1.1, perform the following steps: 1. Run the command on Windows platforms:
TIO_HOME/migration/scripts/InvExtReportRegenFrom5112.cmd
or the command on UNIX platforms:

TIO_HOME/migration/scripts/InvExtReportRegenFrom5112.sh
By running these commands the inventory extension reports are created in the TIO_HOME/tmp directory. 2. Copy the generated files from the Tivoli Provisioning Manager server to the administrative workstation as described in Set up the environment to run the custom report on page 183. Get a DB2 database report: To get a DB2 report, follow this procedure: 1. From the DB2 command window, connect to the database using the following command:
db2 connect to <database_name> user <db2_admin> using <db2_admin_password>
181
For example, if your database name is TIODB, your DB2 administrator user ID is db2admin, and your DB2 administrator user password is db2adminpswd, this is the command to use:
db2 connect to TIODB user db2admin using db2adminpswd
2. Issue the following reorgchk. The command calculates statistics on the database to determine if tables need to be reorganized.
db2 reorgchk
Search for asterisks (*) in the REORG column of the report. This indicates that the table or index needs to be reorganized. For more information about how to read the output from the reorgchk command, see reorgchk command in DB2 information center. For more information about reorganizing tables, see "Table reorganization" in the DB2 information center. Setting up parameters for importing inventory extension reports: In preparation for importing inventory extension reports, you must customize the parameters in a properties file to use the correct port number and enable SSL for communication with the provisioning server. Procedure 1. On the administrative workstation, open the MAXIMO_HOME/maximo/reports/birt/tools/ reporttools.properties file and replace its contents with the following information:
maximo.report.birt.hostname=host_name maximo.report.birt.port=9443 maximo.report.birt.ssl=true maximo.report.birt.username=username maximo.report.birt.password=password maximo.report.birt.outputfolder=./../../birt
where MAXIMO_HOME The directory where the base services are installed. The default path is: v v
Windows UNIX
C:\IBM\SMP
Linux
/opt/IBM/SMP
host_name The fully-qualified host name (or IP address) of the provisioning server. username The default user name is maxadmin. 2. Copy the TIO_HOME/cert/tpmui.cer certificate file from the provisioning server to the administrative workstation. 3. Add the certificate from the provisioning server to the base services security keystore v
Windows
Go to the MAXIMO_HOMEjre/bin directory and run the following command:
keytool -import -trustcacerts -keystore MAXIMO_HOME/maximo/tools/java/jre/lib/security/cacerts -file CERT_LOC/tpmui.cer
where, CERT_LOC is the directory containing the certificate file. v

UNIX Linux
Go to the MAXIMO_HOME/jre/jre/bin directory and run the following command:
keytool -import -trustcacerts -keystore MAXIMO_HOME/maximo/tools/java/jre/lib/security/cacerts -file CERT_LOC/tpmui.cer
where, CERT_LOC is the directory containing the certificate file. If the Tivoli Provisioning Manager configuration does not require a separate administrative workstation, CERT_LOC is equivalent to TIO_HOME/cert. 4. When prompted for a password, type changeit. Enter yes to confirm the certificate has been added.
182
5. Verify that the timestamp of the MAXIMO_HOME/maximo/tools/java/jre/lib/security/cacerts file is updated.

UNIX Linux Back up the MAXIMO_HOME/maximo/tools/java/jre/lib/security/java.security file. 7. In the MAXIMO_HOME/maximo/tools/java/jre/lib/security/java.security file, enable the JSEE socket factories and disable the WebSphere Application Server socket factories by changing the lines:
6.
# Default JSSE socket factories #ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl #ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl # WebSphere socket factories (in cryptosf.jar) ssl.SocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLSocketFactory ssl.ServerSocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLServerSocketFactory
to
# Default JSSE socket factories ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl # WebSphere socket factories (in cryptosf.jar) # ssl.SocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLSocketFactory # ssl.ServerSocketFactory.provider=com.ibm.websphere.ssl.protocol.SSLServerSocketFactory
8. In the MAXIMO_HOME/maximo/reports/birt/tools directory, run the importreports.cmd|.sh reports command. 9. On the web interface, click Go To > Administration > Reporting > Report Administration and click Generate Request Pages. Set up the environment to run the custom report: Before you begin Before you import the inventory extension reports, perform the steps described in Setting up parameters for importing inventory extension reports on page 182. To set up the environment to run the custom report associated to the inventory extension, perform the following steps: Procedure 1. Log on as Windows Administrator, or root for UNIX platforms, to the Tivoli Provisioning Manager server command line. 2. Copy the two files generated for each inventory extension named my_extension.rptdesign and my_extension.xml from the Tivoli Provisioning Manager server to the administrative workstation directory maximo_inst_dir/reports/birt/reports/TPSERVERS. 3. Import the custom report by running the following command in the Administrative workstation:
Maximo_HOME\maximo\reports\birt\tools\importreports app TPSERVERS
What to do next The imported report can then be generated from the Tivoli Provisioning Manager Web interface. Run the Inventory Discovery with the inventory extension: Run the inventory extension that you created to register in the custom table the requested information collected on the target computers. To run the inventory extension perform the following steps:
183
Procedure 1. Log on as maxadmin to the Tivoli Provisioning Manager web interface. 2. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 3. Filter for the inventory extension name. The my_inventory_Discovery configuration is displayed. 4. Click the my_inventory_Discovery configuration. 5. Click Run Discovery. 6. Select the target computers for the discovery. 7. Verify that the task ends successfully from the Provisioning Task Tracking application. Add the custom report to the list of reports: To add the custom report associated to the inventory extension to the list of reports that can be run from the Tivoli Provisioning Manager Web interface, perform the following steps: Procedure 1. Log on to the Tivoli Provisioning Manager Web interface with at least Provisioning Configuration Librarian authorization. 2. 3. 4. 5. Click Go To > Administration > Reporting > Report Administration. Locate and select the report associated to the inventory extension. Click Generate Request Page. Verify that the command completes successfully.
What to do next The added report can then be run from the Tivoli Provisioning Manager Web interface. Run the custom report: To retrieve and display the information in the custom report associated to the inventory extension, perform the following steps: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Locate and select the provisioning computer on which you ran the inventory extension. 3. From the Select Action menu, click Run Report. 4. Select the custom report my_inventory_extension_data. 5. Click Run. What to do next In the report output you see the information collected on the target computers. Example: Defining a custom inventory extension for a target computer:
The inventory extensions are used to perform custom inventory scans. You can define inventory extensions when you want to discover on target computers any information which is not discovered by the Tivoli Provisioning Manager Inventory discovery.
In the following example, an inventory extension is defined and run on a target computer. To complete this task, you must be logged on as a Maximo user.
184
To define this inventory extension, perform the following steps: Procedure 1. Create the tables as described in Set up the environment to create the inventory extension on page 175. To be able to create the tables, ensure that you log on to the database as Maximo user. 2. Create on the Tivoli Provisioning Manager server the properties file named my_inv_extension.properties containing the extension name, description, and related custom scripts with full paths listed by platform. The properties file must have the structure described in inventoryExtension create command. Before running this command, log on as Provisioning Administrator (tioadmin) to the Tivoli Provisioning Manager server. 3. Manually copy on the target computers my_inv_extension.bat / my_inv_extension.sh and my_inv_extension.xml files. The location of these files is specified in my_inv_extension.properties. 4. Copy my_inv_extension.rptdesign and my_inv_extension.xml from the Tivoli Provisioning Manager server %TIO_HOME%/tmp directory to the directory maximo_inst_dir/reports/birt/reports/TPSERVERS of the administration client workstation. 5. Using the base services administration client workstation logged on as Administrator, move to the directory maximo_inst_dir/reports/birt/tools. 6. Run the importreports.cmd app TPSERVERS command from the base services console to import the newly-created report definition. Before you import the inventory extension reports, perform the steps described in Setting up parameters for importing inventory extension reports on page 182. 7. Discover the target computer by performing an RXA-based initial network discovery from the Tivoli Provisioning Manager Web interface. 8. From the discovery configuration run the discovery named my_inv_extension_name. 9. Check if on the target computer are stored the TXT files that verify if the inventory extension can run the command on the target. 10. Generate the report associated to my_inv_extension.xml as described in Add the custom report to the list of reports on page 184. 11. Run the report as described in Run the custom report on page 184. Example: Customizing the Inventory scan depending on specific needs: You can customize the inventory scan depending on your business needs.
In this example a specific customization of the Common Inventory Technology (CIT) configuration file is described, needed to customize the Inventory scan depending on your business needs.
Procedure 1. Customize the TPMconfig.xml file on the target computer, as described in Customizing the CIT configuration file on page 186. 2. Create and run the pre script file on the target computer, as described in Creating and running the pre script file on the target computer on page 186. 3. Create a custom table, as described in Creating a custom table in the data model on page 187. 4. Create the inventory extension, as described in Creating the properties file and the inventory extension on page 187. 5. Perform an Inventory Discovery, as described in Running the Inventory discovery using the inventory extension on page 188. 6. Import the reports associated to the inventory extension, as described in Importing the inventory extension reports on page 188. 7. Run the reports associated to the inventory extension, as described in Running the inventory extension reports on page 189.
185
Customizing the CIT configuration file: You can use the CIT scan script located on the target computer subagent directory to customize the inventory scan. Procedure 1. Locate the TPMconfig.xml file on the target computer. The default TPMconfig.xml file is as follows:
<FSScan version="1.0"> <IncludeDirectory value="C:\"/> <FileMask value="*.dll"/> <FileMask value="*.exe"/> <ExcludeFileMask value="w*"/> <AttributeMask value="rw?rw?rw?"/> <SizeMask value="lt200000"/> <SizeMask value="gt100000"/> <Age value="60"/> <Timeout value="1800"/> <OutputData value="BASIC"/> </FSScan>
2. Change the TPMconfig.xml file as follows:

<FSScan version="1.0"> <IncludeDirectory value="C:\"/> <FileMask value="*.dll"/> <FileMask value="*.exe"/> <Age value="60"/> <Timeout value="1800"/> <OutputData value="BASIC"/> </FSScan>
Note: If TPMconfig.xml does not exist, make the changes in config.xml. Results The Age parameter represents the age of the retrieved data, specified in minutes. The default value is 60 minutes. It means if the cache is younger than 60 minutes, the output file contains the files deleted between scans and the files created during this time will not be received. Setting this value to "0" would disable caching and therefore it would have a negative performance impact on the duration of the scan. Creating and running the pre script file on the target computer: Procedure 1. Create the pre script file as follows:
"c:\progra~1\tivoli\cit\bin\wscanfs.exe" c "c:\progra~1\tivoli\cit\bin\TPMconfig.xml" -o c:\Mydir\myoutput.mif m
2. Run the pre script file on the target computer and the output looks as follows:
C:\Mydir>type myoutput.mif START COMPONENT NAME = "Tivoli Inventory Basic File Scan MIF" START GROUP NAME = "TIV_Software_Files" CLASS = "DMTF|TIV_Software_Files|1.0" START ATTRIBUTE NAME = "File_Path" ID = 3 TYPE = STRING(1024) VALUE = "" END ATTRIBUTE START ATTRIBUTE NAME = "File_Name" ID = 4
186
TYPE = STRING(256) VALUE = "" END ATTRIBUTE START ATTRIBUTE NAME = "File_Size" ID = 5 TYPE = INTEGER VALUE = 0 END ATTRIBUTE START ATTRIBUTE NAME = "File_Type" ID = 6 TYPE = STRING(64) VALUE = "" END ATTRIBUTE KEY = 3,4 END GROUPSTART TABLE NAME = "TIV_Software_Files" ID = 1 CLASS = "DMTF|TIV_Software_Files|1.0" {"C:/Program Files/tivoli/cit/bin/","citxfs.dll",176128,"regular"} {"C:/Program Files/tivoli/cit/bin/","fsmon.exe",139264,"regular"} {"C:/Program Files/tivoli/cit/bin/","libbase.dll",102400,"regular"} {"C:/Program Files/tivoli/cit/bin/","libCcLogWrapper.dll",159744, "regular"} {"C:/Program Files/tivoli/cit/bin/","libcit.dll",139264,"regular"} {"C:/Program Files/tivoli/cit/bin/","provider_standard.dll",106496, "regular"} END TABLE END COMPONENT
Creating a custom table in the data model: Procedure 1. Define the custom table as follows:
C:\Mydir>type mytable.sql DROP TABBLE TIV_Software_Files; CREATE TABLE TIV_Software_Files( discovery_id BIGINT NOT NULL, server_id BIGINT NOT NULL, File_Path VARCHAR(1024), File_Name VARCHAR(256), File_Size BIGINT, File_Type VARCHAR(64) ); ALTER TABLE TIV_Software_Files ADD FOREIGN KEY (server_id) REFERENCES SERVER(server_id) on DELETE CASCADE; ALTER TABLE TIV_Software_Files ADD FOREIGN KEY (discovery_id) REFERENCES DISCOVERY(discovery_id) on DELETE CASCADE; COMMIT; }
2. Create the table in the data model by running the following commands:
set DB2INSTANCE=ctginst1 db2 connect to maxdb71 user maximo using password db2 -tvf C:\mytable.sql
Note: In this step the mentioned commands apply to a UNIX workstation. Creating the properties file and the inventory extension:
187
Procedure 1. Create the properties file for the inventory extension. Specify the following in my_file.properties:
extName=my_inventory2 TABLE_1.NAME=TIV_Software_Files # Files for Windows operating systems targets WINDOWS=yes pre_windows=c:\\Mydir\\mywscanfs.cmd out_windows=c:\\Mydir\\myoutput.mif #post_windows=c:\\test\\postscript.windows.bat
All other platforms are set to no. The post script is not needed in this case. 2. Create the inventory extension by running the following command:
C:\Program Files\IBM\tivoli\tpm\tools>inventoryExtension.cmd create -p c:\Mydir my_file.properties
The output of the command is as follows:

2010-05-05 17:48:51,578 INFO COPINV006I Parsing the command line arguments ... 2010-05-05 17:48:51,593 INFO COPINV007I Command line arguments parsed. 2010-05-05 17:48:51,593 INFO COPINV008I Start processing ... 2010-05-05 17:48:51,593 INFO Start parsing property file 2010-05-05 17:48:51,781 INFO Finished parsing property file 2010-05-05 17:48:51,828 INFO COPINV021I The specified extension: my_inventory2 has been registered. 2010-05-05 17:48:51,828 INFO Creating discovery configuration... 2010-05-05 17:48:53,031 INFO Discovery my_inventory2_Discovery successfully crated 2010-05-05 17:48:53,031 INFO Creating Report from BIRT Template 2010-05-05 17:48:53,031 INFO INFO: processing input file: tp_customScan.rptdesgn 2010-05-05 17:48:53,046 INFO INFO: destination report folder is: C:\Program Files\IBM\tivoli\tpm/tmp/ 2010-05-05 17:48:53,046 INFO INFO: createXMLFile for is: C:\Program Files\IBM\ tivoli\tpm/tmp/my_inventory2.rptdesign 2010-05-05 17:48:53,046 INFO INFO: processing input file: maximo_import_template.xml 2010-05-05 17:48:53,187 INFO INFO: destination report folder is: C:\Program Files\IBM\tivoli\tpm/tmp/ 2010-05-05 17:48:53,203 INFO INFO: createXMLFile for is: C:\Program Files\IBM\ tivoli\tpm/tmp/my_inventory2.xml 2010-05-05 17:48:53,203 INFO Report for my_inventory2 succesfully created 2010-05-05 17:48:53,203 INFO COPINV009I End processing. 2010-05-05 17:48:53,218 INFO COPINV005I The command ends with return code: 0 .
Running the Inventory discovery using the inventory extension: Procedure 1. Log on as maxadmin to the Tivoli Provisioning Manager Web interface. 2. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 3. Filter for the inventory extension name. The my_inventory2_Discovery configuration is displayed. 4. Click the my_inventory2_Discovery configuration. 5. Click Run Discovery. 6. Select the target computers on which you want to perform the discovery. 7. Verify that the task ends successfully from the Provisioning Task Tracking application. Importing the inventory extension reports: For more details about how to import the inventory extension reports, see Setting up parameters for importing inventory extension reports on page 182.
188
Procedure 1. Set up the parameters needed for importing inventory extension reports. On the administrative workstation, open the Maximo_HOME/maximo/reports/birt/tools/reporttools.properties file and replace its contents with the following information:
maximo.report.birt.hostname=tpm_fully_qualified_host_name maximo.report.birt.port=9443 maximo.report.birt.ssl=true maximo.report.birt.username=maxadmin maximo.report.birt.password=maxadmin_pwd maximo.report.birt.outputfolder=./../../birt
2. Copy the TIO_HOME/cert/tpmui.cer certificate from the provisioning server to the administrative workstation. 3. On the administrative workstation, import the certificate as follows:
C:\ibm\SMP\maximo\tools\java\jre\bin>keytool -import -trustcacerts -keystore C:\ibm\SMP\maximo\tools\java\jre\lib\security\cacerts -file c:\Progra~1\IBM\tivoli\tpm\cert\tpmui.cer
4. Enter the keystore password: changeit. Answer yes to the Trust this certificate? question. The certificate was now added to the keystore. 5. Copy the two files generated for each inventory extension named my_extension.rptdesign and my_extension.xml from the Tivoli Provisioning Manager server to the administrative workstation directory. 6. Import the custom report by running the following command:
Maximo_HOME\maximo\reports\birt\tools\importreports app TPSERVERS
For example on Windows:

C:\ibm\SMP\maximo\reports\birt\tools>importreports.cmd app TPSERVERS
7. Generate the imported report from the Tivoli Provisioning Manager Web interface as follows: a. Click Go To > Administration > Reporting > Report Administration. b. Locate and select the report associated to the inventory extension. c. Click Generate Request Page. Running the inventory extension reports: Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Locate and select the provisioning computer on which you ran the inventory extension. 3. Click Run Reports from the Select Action menu. 4. In the Reports dialog, search for the custom report by description, not by report name, entering a description for the report. 5. Click Submit to run the report. You do not need to enter a computer name in Server Name. A report is displayed. What to do next To run a custom inventory extension report on other target computers, you must copy the pre script file to the target computers. This can be done by creating a workflow. Example: Displaying CIT custom inventory extension data: You can display the Common Inventory Technology (CIT) custom inventory extension data directly in Tivoli Provisioning Manager.
189
In this example it is described how to set up a sample CIT custom inventory extension and feed that data back to Tivoli Provisioning Manager.
Procedure 1. Configure the managed system to execute the CIT custom inventory extension, as described in Preparing the managed system to provide additional inventory data. 2. Configure the server to store the additional data, as described in Preparing the server to store additional inventory data on page 191. 3. Create the CIT custom inventory extension, as described in Creating the CIT custom inventory extension in Tivoli Provisioning Manager on page 193. 4. Test the new custom inventory extension you created, as described in Testing the CIT custom inventory extension on page 193. 5. Display the CIT data in the provisioning application, as described in Changing the provisioning application to include the custom inventory extension data on page 194. Preparing the managed system to provide additional inventory data: You can prepare the managed system to execute the CIT custom inventory extension. When developing a custom scanner for CIT of your own, you would need to provide output data in a CIT-compatible format, which would either be a Management Information Format (MIF) file or an XML file, both with a predefined format. Because this scenario does not focus on the development of a completely custom scanner, you will use the wscanfs.exe command provided by the CIT scanner, which scans the file system for files. This command provides a suitable output. To use the command as a CIT Custom Inventory Extension, you need to prepare it on the target system. Previewing the MIF output of the wscanfs command: Before running the report, it is recommended, when using Tivoli Provisioning Manager, to run the command directly on the managed system. You will create a sample output as a MIF file on the managed system. Procedure 1. Log on to the managed system and open a command shell to run the following two commands:
cd c:\program files\tivoli\cit\bin wscanfs.exe -c TPMconfig.xml -o myoutput.mif -m
2. A myoutput.mif file is created containing the result of the CIT file system scanner with the configuration in the TPMconfig.xml file. The content of myoutput.mif is the following:
START COMPONENT NAME = "Tivoli Inventory Basic File Scan MIF" START GROUP NAME = "TIV_Software_Files" CLASS = "DMTF|TIV_Software_Files|1.0" START ATTRIBUTE NAME = "File_Path" ID = 3 TYPE = STRING(1024) VALUE = "" END ATTRIBUTE START ATTRIBUTE NAME = "File_Name"ID = 4 TYPE = STRING(256) VALUE = "" END ATTRIBUTE
190
START ATTRIBUTE NAME = "File_Size" ID = 5 TYPE = INTEGER VALUE = 0 END ATTRIBUTE START ATTRIBUTE NAME = "File_Type" ID = 6 TYPE = STRING(64) VALUE = "" END ATTRIBUTE KEY = 3,4 END GROUP START TABLE NAME = "TIV_Software_Files" ID = 1 CLASS = "DMTF|TIV_Software_Files|1.0" {"C:/Program Files/tivoli/cit/bin/","citxfs.dll",176128,"regular"} {"C:/Program Files/tivoli/cit/bin/","fsmon.exe",139264,"regular"} {"C:/Program Files/tivoli/cit/bin/","libbase.dll",102400,"regular"} {"C:/Program Files/tivoli/cit/bin/","libCcLogWrapper.dll",159744,"regular"} {"C:/Program Files/tivoli/cit/bin/","libcit.dll",139264,"regular"} {"C:/Program Files/tivoli/cit/bin/","provider_standard.dll",106496,"regular"} END TABLE END COMPONENT
Configuring the wscanfs config.xml file: On the managed system, in the c:\programfiles\tivoli\cit\bin directory, modify the original TPMconfig.xml file as follows:
<FSScan version="1.0"> <IncludeDirectory value="C:\"/> <SizeMask value="gt10000000"/> <Age value="60"/> <Timeout value="1800"/> <OutputData value="BASIC"/> </FSScan>
On the managed system, in a directory of your choice, crate a batch file to be called by the CIT custom inventory extension scan. For example, create a directory C:\test and a text file in that directory named mywscanfs.cmd and insert the following content:
"c:\program files\tivoli\cit\bin\wscanfs.exe" c "c:\program files\tivoli\cit\bin\config.xml" -o c:\test\myoutput.mif m
Note the path to the mywscanfs.cmd script, as you will need it later on to create a properties file on the Tivoli Provisioning Manager server. Preparing the server to store additional inventory data: Once the command to scan and collect the additional data is completed, you need to define a place, where the CIT scanner can write the collected data to. You can use a table in the database as a source for a report. To use the database table in the Tivoli Provisioning Manager applications, you will define that table using the Database Configuration application. Procedure 1. Log on to the Tivoli Provisioning Manager Wweb interface. 2. Click Go To > System Configuration > Platform Configuration > Database Configuration. 3. Click Advanced Search, clear the N in the Internal? field and click Find.
191
4. Ensure that there are no outstanding changes. If there are outstanding changes, communicate with whoever made this changes, and either discard them or apply them before continuing. 5. Click New Object and enter the following information:
Object: TIV_SOFTWARE_FILES Description: for example CIT Custom Inventory Extension fs scan Storage Partition: IBM32KSPACE Add Rowstamp?: No Entity: TIV_SOFTWARE_FILES
6. Navigate to the Attributes tab and perform the following changes to the attributes:
- Delete: Description o o o o o o o o o o o o New Row Attribute: DISCOVERY_ID Same as Object: TPDISCOVERY Same as Attribute: ID New Row Attribute: SERVER_ID Same as Object: TPSERVER Same as Attribute: ID New Row Attribute: File_Name Type: ALN Length: 256 New Row Attribute: File_Path Type: ALN Length: 1024
- New Row o Attribute: File_Size o Type: Integer o o o New Row Attribute: File_Type Type: ALN Length: 64
7. Navigate to the List tab and search for the TPSERVER object. 8. Select the TPSERVER object and go to the Relationships tab. 9. Create a new row with the following data:
Relationship: TIV_SOFTWARE_FILES Child Object: TIV_SOFTWARE_FILES Where Clause: server_id = :id
10. Save the TPSERVER object and go back to the List tab. Clear any filters that you have set. Now there should be one object with an outstanding change. Modifying the database table: Procedure 1. Stop the Tivoli Provisioning Manager server. 2. Back up the database. 3. Log on to the Administrative Workstation and open a command shell to run the following commands:
cd c:\IBM\SMP\maximo\tools\maximo configdb.bat
4. Log on to the database server of Tivoli Provisioning Manager and open the DB2 Control Center. 5. Select the Tivoli Provisioning Manager database and filter the table names such as TIV%, DISCOVERY, SERVER where any condition applies. The table tree should contain three tables:
192
v TIV_SOFTWARE_FILES v DISCOVERY v SERVER 6. Right-click the TIV_SOFTWARE_FILES tables, select Alter... and navigate to the Keys tab. 7. Select Add Foreign ... and add two foreign keys for:
Schema: MAXIMO MAXIMO Name: DISCOVERY SERVER Primary Key: DISCOVERY_ID SERVER_ID Foreign Key: DISCOVERY_ID SERVER_ID On delete: CASCADE CASCADE
and click OK. Note: If you prefer to create an SQL statement, the correct statement is as follows:
ALTER TABLE MAXIMO.TIV_Software_Files ADD FOREIGN KEY (server_id) REFERENCES SERVER(server_id) on DELETE CASCADE; ALTER TABLE MAXIMO.TIV_Software_Files ADD FOREIGN KEY (discovery_id) REFERENCES DISCOVERY(discovery_id) on DELETE CASCADE; COMMIT;
8. Right-click the TIV_SOFTWARE_FILES tables, select Alter... and go to the Columns tab. 9. Select TIV_SOFTWARE_FILESID and click Change.... Select the Value generation tab, select Identity with initial value 1 and increment 1, click OK twice. Note: If you prefer to create an SQL statement, the correct statement is as follows:
ALTER TABLE MAXIMO.TIV_SOFTWARE_FILES ALTER COLUMN TIV_SOFTWARE_FILESID SET GENERATED AS IDENTITY ( START WITH 1 INCREMENT BY 1 NO CACHE ) ;
10. Start the Tivoli Provisioning Manager server. Creating the CIT custom inventory extension in Tivoli Provisioning Manager: Before starting the CIT scan using the custom inventory extension, the extension must be known to Tivoli Provisioning Manager. To do this, a property file must be created, and this property file must then be added to the extension. Procedure 1. Log on to the Tivoli Provisioning Manager server command line interface as tioadmin. 2. Create in any directory you want (for example C:\tpm_temp) a new text file named my_inventory2.properties. 3. Edit the file and insert the following content:
extName=my_inventory2 TABLE_1.NAME=TIV_Software_Files # Files for Windows operating systems targets WINDOWS=yes pre_windows=c:\\test\\mywscanfs.cmd out_windows=c:\\test\\myoutput.mif #post_windows=c:\\test\\postscript.windows.bat
4. Save the file. 5. Run the following commands to add the my_inventory2.properties file to the CIT custom inventory extension of Tivoli Provisioning Manager:
cd %TIO_HOME%\tools inventoryExtensions.cmd create p c:\tpm_temp\my_inventory2.properties
Testing the CIT custom inventory extension:

193
Procedure 1. Log on to the Tivoli Provisioning Manager web interface. 2. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 3. Locate and select the my_inventory2_Discovery configuration. 4. Perform the discovery against the managed system running the Tivoli common agent (TCA). 5. Log on to the database server of Tivoli Provisioning Manager and connect to the database. 6. Issue the following SQL statement:
select * from maximo.TIV_SOFTWARE_FILES
Results The result should display some lines. If not, there was a problem writing to the database. Changing the provisioning application to include the custom inventory extension data: The collected additional CIT data can be displayed not only in a report, but also in the provisioning server application. This example will focus on modifying the existing Provisioning Computers application, so that you can select the managed system and see the additional data in the computer information. Before you modify the original Provisioning Computers application, you should make a backup of the original Provisioning Computers application by exporting and saving the XML application presentation using the Application Designer. If you update Tivoli Provisioning Manager and you have performed changes to the original Provisioning Computers application, restore the original application definition before applying the update, then update Tivoli Provisioning Manager, and later add your changes to the updated Provisioning Computers application. Procedure 1. Log on to the Tivoli Provisioning Manager web interface. 2. Click Go To > System Configuration > Platform Configuration > Application Designer. 3. Select the Provisioning Computers application and go to the Workspace tab. 4. Once the application has finished loading, click Export Application Definition in the toolbar to display the application presentation and save that XML to a different directory. 5. When the application is opened in the Application Designer, add your new additional data table. A good choice would be to drag a new tab from the Control Palette named Extended Discovery Results. Drag a new table from the Control Palette and drop it on the new tab. Additionally, drag and drop four more table columns to the new table. Close the Control Palette, select the table, and open the table properties. 6. In Label enter a name for the table such as CIT Custom Inventory Extension File Scan Results. 7. In Relationship enter TIV_SOFTWARE_FILES. 8. Select the table body, open its properties, and check Filterable? and Filter Expanded?. 9. Open the properties of all table columns and provide each table column with an attribute of the TIV_SOFTWARE_FILES object (DISCOVERY_ID, FILE_NAME, FILE_SIZE, FILE_TYPE, FILE_PATH). You can leave out SERVER_ID. Enter the attribute name in the Attribute field. 10. For the DISCOVERY_ID, you can also provide a Go To menu entry (use the menu type NORMAL), so that you can go to the Discovery Configurations application, select the appropriate discovery configuration and get the value. 11. Save the application. Results When you open the Provisioning Computers application and select the managed system for which you gathered the additional CIT data, there is now a new tab (or the table should appear where you created it) displaying the discovery results.
194
Discovering operating systems and correlating them programmatically

Use the software signatures to correlate operating system software installations. Operating system software installations can be programmatically correlated with operating system software definitions by using an Inventory Discovery and selecting to scan software with the Use software signature scan option. If the target operating system level has a software signature defined in the software catalogue, the matched software signature for the operating system of the target computer can be used to correlate between the operating system software installation discovered from the target computer with the operating system software definition programmatically.
Automatic Agent discovery by device

The IBM Tivoli Agent Manager Discovery Device is automatically triggered when performing specific actions on agents. The IBM Tivoli Agent Manager Discovery Device discovery configuration is automatically triggered if you perform on the agent one of the following operations: v Post Agent Install v During Agent Uninstall v Agent Stop v Agent Start v Agent Network information change (for example the IP address) v Agent Heartbeat (default is every 24 hours) To run manually this discovery configuration, perform the following steps: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. . 2. Click New Discovery Configuration 3. In the Method field, select IBM Tivoli Agent Manager Discovery Device.
Microsoft Active Directory discovery

Provisioning integrates with Microsoft Active Directory and populates the data model with data pertinent to the management of resources. Microsoft Active Directory is not just used for user authentication and authorization. Enterprises use it for managing resources and groups of resources. Many businesses store their organizational information in Microsoft Active Directory. This information can include the resources and the organization's geographic and administrative topology. Provisioning allows you to integrate with Microsoft Active Directory and consume the data directly into the data model. This eliminates the manual task of recreating the same information. The Microsoft Active Directorydiscovery configuration can discover the following type of information: v Resources by organizational unit v Microsoft Active Directory groups v Resource attributes such as Microsoft Active Directory domain, last logon, country code, logon count, distinguished name, and OS information. Note: Microsoft Active Directory discovery does not support discovery of IPv6 addresses.
195
When you identify the scope of the discovery, provisioning will automatically import the organizational data and reflect that data in the inventory by using the same group views in the web interface. Microsoft Active Directory discovery configuration can also support advanced search. Advanced search allows customer to input LDAP query scripts and this query is run against the Microsoft Active Directory server. The result of the MSAD query will be placed in a provisioning group. For example, to create a group using an MSAD query which will contain all resources and sub-organizations under the TivoliOU organizational unit, in the User Defined Search Command field of the Microsoft Active Directory discovery configuration, input the following: Note: These queries are case sensitive. (OU=TivoliOU) You can further refine the query against your LDAP registry. For example: To return all entries that are within the MyDept1 or MyDept3 departments: (|(OU=MyDept1)(OU=MyDept3)) To list all computers whose name starts with c: (CN=c*) To list all computers except the computer called camean: (&(CN=c*)(!(CN=camean))) To list all computers which start with c or h: (|(CN=c*)(CN=h*)) To list an organization unit and additional computers that start with f: (|(OU=SteveOU)(CN=f*)) To list all computers whose isCriticalSystemObject attribute is set to TRUE: (&(CN=*)(isCriticalSystemObject=TRUE)) To list all organization units and computers including the domain controllers: (&(objectclass=organizationalunit)) Tip: For the most recent results, run the Microsoft Active Directory discovery configuration first to synchronize with Microsoft Active Directory. You can customize the discovery by modifying the discovery schedules.
Running Microsoft Active Directory discovery

Provisioning can discover Microsoft Active Directory organization units, resources and software. This eliminates the manual task of recreating the same information. Provisioning defines the discovery scope with Microsoft Active Directory on the base domain name (for example DN = mydomain.com). It also defines the discovery scope with the login account, login password,
196
and discovery object types such as organization unit (OU), resource, and software. The provisioning discovery will search the Microsoft Active Directory environment starting from an entry based domain name and find the resources and software within the scope and populate the data model with this information. A Microsoft Active Directory discovery configuration is supplied with the product if you want to use it immediately. Otherwise, you can create your own discovery configuration. To create a Microsoft Active Directory discovery configuration, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. 3. 4. 5. . Click New Discovery Configuration Type a name and description for the configuration created. Click Hardware Discovery. In the Method field, select Microsoft Active Directory Discovery.
6. Click OK. 7. In the Active Directory Information tab, enter the following discovery parameters: a. In Server name specify the fully qualified host name of the Microsoft Active Directory server. b. In Base Distinguished Name specify the domain name path of the Microsoft Active Directory server. c. In User Id and Password specify the credentials of the Microsoft Active Directory server. Note: For example if the name of the Microsoft Active Directory server is exampleMSAD.com and the user ID that logs on to the Microsoft Active Directory server is Administrator, then enter exampleMSAD\Administrator in the User Id field. If you enter only Administrator you receive the following error message:
COPDEX040E An unexpected deployment engine exception occurred: class com.ibm.tivoli.orchestrator.discovery.msad.exception. MsadDiscoveryException: COPCOM675E The server "ldap://example.ibm.com:389/DC=exampleMSAD, DC=com" cannot be accessed or updated because the specified user account does not exist..
8. In the Filters tab, clear or leave selected the following check boxes you can use to filter the Microsoft Active Directory discovery results: v User Defined Search Command This option allows running any custom LDAP query from the discovery. To not overwrite any specific option on this custom query, any options which might change the query behavior or result are turned off. This includes the "Discover Groups" and "Discover Organizational units" check boxes which will not be displayed by the Web interface when the "User Defined Search Command" check box is selected. A root group, named MSAD Query : discoveryId, is created corresponding to the discovery performed. v Discover Groups If this check box is selected, the discovery will discover the servers within groups. v Discover Organizational units If this check box is selected, the discovery will discover the servers within organizational units. v Dynamic IPs (DHCP) This check box defines whether or not a DHCP network interface is populated based on the computer discovered by this discovery. For example, if the check box is selected, and a computer with a DHCP IP address is detected by the discovery, it is updated on the corresponding network interface. But if this option is not selected, and if the IP address from a computer discovered by the
197
Microsoft Active Directory discovery is DHCP, or the same IP is already defined in the data model in the DHCP IP range, the IP address is not populated in the network interface. Note: By default, Filter LDAP Attributes is enabled. This check box ensures that the discovery does not process specific LDAP attributes such as objectSid and objectGUID. If this check box is cleared, all discovered LDAP attributes are displayed in the web interface as resource variables. 9. Click Save .
Results
What to do next
You can now schedule the discovery or run it immediately to update the data model. To run the discovery immediately, on the newly created discovery configuration, click Run Discovery to start the operation. You can view the status of the discovery task by performing the following action: v Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking.
Running Microsoft Updates discovery

Provisioning can discover Microsoft updates and patches. This makes any updates and patches available from Microsoft known to the data model and eliminates the manual task of recreating the same information. The Microsoft Updates discovery configuration downloads the wsusscn2.cab file from the Microsoft Web site, extracts it, parses it, and populates the data model with this information. It also creates a software installable for each update and patch and provide a link to download the executable file. A Microsoft Updates discovery configuration is supplied with the product if you want to use it immediately. Otherwise, you can create your own discovery configuration. Tip: If you need to import all of your patches again, you can run the provisioning workflow CleanALLDiscoveredMSPatches to clean up the data model. If your provisioning server runs on UNIX platforms, and there is no Microsoft patch download server configured, you must perform an appropriate setup before running the Microsoft Updates Discovery discovery. To create a Microsoft Updates discovery configuration, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. . 2. Click New Discovery Configuration 3. Type a name and description for the configuration created. 4. 5. 6. 7. Click Software Discovery. In the Method field, select Microsoft Updates Discovery. Click OK. Specify the discovery parameters and enter their values. v Product: Specify one of the available software products.
198
v Locale: Specify the locale. v Severity: Specify the severity of the patches to be imported among the following options: Critical, Important,Moderate, Low. v Patch Status: Specify the patch status for all newly discovery patches among the following options: NEW, APPROVED, DISCONTINUED. If no selection is made, then the default will be Not Approved. Note: In order for objects to be considered when a WUA scan is run, then the Status must be APPROVED for the data model patch objects that are created as a result of the discovery can be approved in the data model. 8. Click Save.
Results
What to do next
Discovering Solaris zones

Provisioning can discover the host Solaris system and all its zones. This type of discovery can be performed on any server with Solaris 10 installed. This will make information available from the Solaris system and its zones known to the data model and eliminates the manual task of recreating the same information. The discovery initially verifies if the server has the supported operating system (Solaris 10). If this condition is met, the discovery then checks if the zone capability is supported. If the capability is present, the discovery flags the computer as a host platform and scans the host platform to detect its zones. To create discovery configuration, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. 3. 4. 5. 6. 7. . Click New Type a name and description for the configuration created. Click Other. In the Method field, select Solaris - HostPlatform and Zone Discovery. Click OK. Specify the discovery parameters and enter their values. .
8. Click Save
Results
199
What to do next
Discovering AIX workload partitions

Provisioning can discover AIX version 7.1 and 6.1 workload partitions. This type of discovery can be performed on any server with AIX 7.1 and 6.1 installed. This will make information available from the AIX 7.1 and 6.1 workload partitions (WPARs) known to the data model and eliminates the manual task of recreating the same information. The discovery initially verifies if the server has the required operating system and can support the workload partitions. If these conditions are met, the discovery flags the computer as a host platform and scans the host platform to detect any hosted workload partition. To create a discovery configuration that detects workload partitions, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. . 2. Click New 3. Type a name and description for the configuration created. 4. Click Other. 5. In the Method field, select AIX_WPAR_HostPlatform_Discovery. 6. Click OK. 7. Specify the discovery parameters and enter their values. 8. Click Save .
Results
What to do next
Discovering virtual centers

Provisioning can discover the virtual centers of your environment. This will make information available from your virtual centers known to the data model and eliminates the manual task of recreating the same information.
200
To create a discovery configuration for your virtual centers, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. 3. 4. 5. . Click New Type a name and description for the configuration created. Click Other. In the Method field, select VMware_VirtualCenter_Discovery.
6. Click OK. 7. Specify the discovery parameters and enter their values. 8. Click Save .
Results
What to do next
Discovering virtual servers

You can now discover the virtual servers of your environment using the discovery wizard application.
Before you begin

Ensure that all the virtualization prerequisites are met. You must install on the Tivoli Provisioning Manager server the SSL certificate if needed. For information, see Importing the SSL certificate. To discover the virtual servers of your environment, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Wizards. Or access the discovery wizard application by clicking directly the Start Center link. . 2. Click New 3. Enter a name and a description for the new discovery. The Discovery Wizard is a required field, while the description field is optional. 4. From the Type menu select Host Computers with hosted Virtual Servers. 5. From the Target Source Type menu, you must choose how to retrieve the targets by selecting one of the following options: Select from targets If you want to retrieve the targets from existing lists of computers or computer groups. Run network discovery If you want to display a RXA network discovery configuration page.
201
6. If you have selected Select from targets, on the Add Discovery Wizard Configuration dialog displayed you can select one or more of the following check boxes: v VMware Virtual Center v AIX LPARs v AIX WPARS v Solaris Zones v Linux KVM 7. If you have selected Run network discovery as Target Source Type, on the Add Discovery Wizard Configuration dialog displayed you can select one or more of the following check boxes: v AIX WPARS v Solaris Zones v Linux KVM 8. Click OK. 9. If you have selected Select from targets as Target Source Type, in the Select Targets page of the wizard, you can specify the provisioning computers or provisioning groups against which you want to run the discovery. For each target specify the Target Type. 10. In the Discovery page of the wizard, the type of discovery you will perform is listed. 11. In the Review and Submit page of the wizard, you can set scheduling options, notification options, and e-mail address information for the provisioning task and verify the provisioning task name. 12. Click Submit to perform the discovery.
Results
You have configured and submitted a discovery that detects the virtual servers of your environment. Note: After running successfully one of these virtualization discoveries using this wizard, the Virtualization Management application is populated with a list of host platforms. The following host platforms are displayed on the Host Platforms list if you run a virtual discovery on them from this wizard, even if they are just a normal server without any virtual machines: v AIX 6.1 or 7.1 (when running AIX WPARS option) v Solaris 10 or later (when running Solaris Zones option) v Linux (when running Linux KVM option)
Discovering PCI devices

You can now discover the PCI devices of your environment using the discovery configuration application or the discovery wizard application.
Before you begin

The target computers must already be discovered in Tivoli Provisioning Manager and must have a working Service Access Point (SAP) defined. To discover the PCI devices of your environment, perform the following steps:
Procedure
1. 2. 3. 4. Access either the discovery configuration application or the discovery wizard application. Open a new or an existing Tivoli Provisioning Manager Inventory Discovery. Select Hardware as type of discovery you want to perform. Select the target computers for the discovery.
5. Click Submit to perform the discovery.
202
Results
The system starts a Common Inventory Technology (CIT) scan on the target computers. CIT collects the information about the PCI devices and stores them in a CIT XML output file. The PCI device data is stored in the data model as a hardware resource. The data is then displayed in the provisioning computer application, after the discovery ends successfully.
Discovering WebSphere Application Server software instances

Provisioning can discover the WebSphere Application Server software instances in your enterprise allowing you to manage discovered WebSphere Application Server software resources. As part of the product installation, there is an existing IBM WebSphere Discovery discovery configuration provided, which is installed and configured. You can use it to run a discovery. This discovery is implemented as an automation package. When the provisioning workflow is run, it calls Java code to obtain the discovered resources from the WebSphere Application Server and then populates these resources into the data model.
Running IBM WebSphere Discovery

You can schedule the discovery or run it immediately to update the data model. To run the discovery immediately, on the IBM WebSphere Discovery discovery configuration, click Run Discovery to start the operation. If available, select the targets that you want to run this discovery on. You can view the status of the discovery task by performing the following action: v Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking.
Adding credentials to a WebSphere Application Server profile

After you run the WebSphere Application Server discovery configuration, you must add the credentials to the WebSphere Application Server profile, if it has instance level security enabled for it to be managed by provisioning. To add credentials to a WebSphere Application Server profile:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Search for the resource that is running WebSphere Application Server and click on it to view its details. 3. Click the Software tab. 4. In the Software Installations table, expand IBM WebSphere Application Server. 5. In the Configuration Template field, verify that the wsadmin.username parameter value is correct. 6. Enter a password in the wsadmin.password field. 7. Click Save .
TADDM discovery
TADDM discovery discovers computers and replicates hardware and software discovery data from the TADDM database to the data model. Replicated data include discovered computers, computer hardware, network resources, operating systems, software components, and composite applications such as DB2. The discovery can be run against a set of selected computers; it can also be run against one or more computers based on the fully qualified computer names.
203
When running this discovery, you can also select a file containing a list of the computers you intend to discover.
Types of discovery
TADDM provides two types of discovery - hardware discovery and software discovery. Using hardware discovery, you can discover: v Network resources v System resources Using software discovery, you can discover: v Installed software components v WebSphere Application Server v Oracle v v v v Web Servers WebLogic Server servers DB2 VMWare ESX
Hardware discovery
Network Resources You can discover network resources such as network interface IP addresses, netmask Gateway IP for route, computer host names, fully qualified domain names, network interface cards, switches, routers, and firewalls. Note: TADDM discovers the configured IPv6 addresses in addition to the IPv4 addresses. System Resources You can discover system resources such as CD-ROMs, diskette devices, hard disks, memory, and input/output devices such as USB devices Note: When you display the hardware properties of a Windows computer you discovered using the TADDM discovery, for diskette and CD-ROM devices specific entries are created. The same entries are duplicated and can be found also under the partition of the computer file system.
Software discovery
Installed software components You can discover all your software resources defined in the Change and Configuration Management Database. You can also correlate with an existing software module for all discovered software installations. If an existing software module cannot be found, then a placeholder software module will be created to associate it with the discovered software installation. IBM WebSphere Application Server You can discover WebSphere Application Server information such as the installation profile and path, the WebSphere server, version, and type, and the Websphere node and cell. Oracle You can discover: Oracle installations, Oracle servers, including Oracle configuration parameters such as: oracle_home and install-path. Web Servers You can discover the following for Web servers such as IBM HTTP Server, Apache Server, and Microsoft Internet Information Server (IIS): v Web server installations
204
v Web servers v Web server modules v Configuration parameter details such as server port, server root, and installation directory. WebLogic Server For WebLogic Server, you can discover server installations and instances, WebLogic Server configuration details such as BEA home, server root, and installation path. DB2 For DB2, you can discover DB2 installation and instances, and parameter details such as installation path and DB2 product key.
VMWare ESX You can discover information about the installed VMWare and defined virtual machines. Business applications You can discover information about configured business applications. Computer collections You can discover information about collections of computers in TADDM, which are imported as computer groups.
Supported TADDM versions

Tivoli Provisioning Manager version 7.2 supports by default the TADDM Discovery from TADDM version 7.2. If you are using TADDM version 7.1.2.x you must perform the following steps to enable the TADDM Discovery from TADDM version 7.1.2.x:
Procedure
1. The two jar files which relate to TADDM API are taddm-api-client.jar and platform-model.jar. The versions of these files that work with TADDM version 7.2 are stored under the $TIO_HOME/lwi/ runtime/tpm/eclipse/plugins/TADDMDiscovery/lib directory. While the versions of these files that work withTADDM version 7.1.2.x are archived in the $TIO_HOME/lwi/runtime/tpm/eclipse/ plugins/TADDMDiscovery/lib_7.1.2.x directory. 2. Copy the required versions of the two jar files to the following two locations, overwriting the existing jar files: v $TIO_HOME/lwi/runtime/tpm/eclipse/plugins/tpm_pmp/maximoLibs/ v $TIO_HOME/eclipse/plugins/tpm_pmp/maximoLibs/ 3. Stop Tivoli Provisioning Manager and start it again.
Discovering hardware and software with TADDM

Provisioning can discover the hardware and software resources using TADDM. It can also update existing resources already in the data model. This allows you to manage discovered resources from provisioning. This discovery is implemented as an automation package. When the provisioning workflow is run, it calls Java code to obtain the discovered resources from TADDM and then populates these resources into the data model. To modify the existing TADDM discovery configuration:
Procedure
1. 2. 3. 4. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. In the Method field, type TADDM Discovery. Select the Tivoli Application Dependency Discovery Manager Discovery. In the Server Information tab, provide the following TADDM server information: v Name: The name of the TADDM server that will perform the discovery. v Port Number: The port number of the server.
205
v User ID and Password: The credentials of the TADDM server. 5. In the Computer to be Discovered tab, specify the Fully Qualified Host Name of the computers you want to discover. All the hosts that you specify in this list will be discovered on the TADDM server. Note: If you want to discover all the resources on the TADDM server, do not specify any hosts in the discovery list. If you leave the list empty, all resources on the TADDM server will be discovered. Note: Before performing any software distribution operation on the computers imported from TADDM, you must manually add the service access point to them, because on the computers imported from TADDM the service access point is not automatically created 6. In the Scope tab, select the appropriate check boxes to determine what software information will be discovered on the TADDM servers. v Installed Software Components. Installed software components are software installations registered under the operating system of a computer. For example, on a Windows computer, they are registered in the registry editor, and for Linux, in the RPM package manager. If you select this option, all software installations that are in the operating systems registry for that computer will be discovered. Note: This option is different than the rest of the Software Discovery options as the other options discover composite application information, including detailed configuration information; whereas this option does not discovered detailed configuration information, only basic details about the software installation in the registry. v WebSphere Application Server. You can discover Websphere Application Server information such as the installation profile and path, the WebSphere server, version, and type, and the Websphere node and cell. v Oracle. You can discover Oracle information such as server and database instances, the product version, the home installation path and name, its software ID, and its port and base path. After the discovery is complete, the Oracle server can be started or stopped from provisioning if the appropriate credentials to access it are set. v Web Server. You can discover the following three types of Web servers: IBM HTTP Server, Apache Server, and Microsoft IIS. Different configuration details can be discovered for each Web server. Refer to the related information for more details. v WebLogic Server. You can discover Web Logic attributes such as servers, product version, installation path, J2EE application names and file paths, and the BEA home. v DB2. You can discover DB2 information such as servers, ports, the installation path, the DB2.ESE and DB2.ADCL files, and these parameters: uninstall_delete_users, db2_product_key default_DB2INSTANCE, das_group_name, das_user_name, fence_group_name, fence_group_id, fence_user_name, instance_user_name, instance_port ,db2_auth_type, db2_word_width, db2_auto_start. v VMWare ESX. You can discover information about the virtual computers in your environment. v Business Applications. You can discover information such as the business applications installed, their functional groups and application tier numbers. v Computer Collections. You can discover information about how the computers are grouped in your environment. 7. Click Save .
Results
206
What to do next
If you are using this discovery configuration to discover your own software, you need to provide a software resource mapping in the provisioning $TIO_HOME/lwi/runtime/tpm/eclipse/plugins/ TADDMDiscovery/resource/discovery-resource-map.xml file.
Discovering computer extended attributes from TADDM

Before you begin
In TADDM the computers have been defined with extended attributes and have been populated by running the appropriate discovery sensor. To scan your TADDM environment and populate the data model with the computer extended attributes, perform these steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. Click New. 3. Type the name and description for the discovery. 4. In the Category field, select Hardware Discovery. 5. In the Method field, select TADDM Discovery. 6. Click OK. 7. In the Server Information tab, provide the following TADDM server information: v Name: The fully qualified host name or the IP address of the TADDM server. v Port Number: The port number of the TADDM server. v User ID and Password: The TADDM server administration user ID and password. 8. (Optional) In the Computer to be Discovered tab, specify the fully qualified host name of the computers you want to discover. Only the computers that you specify in this list are replicated from the TADDM server. To specify the host names you can click either New Row and enter the computer host name or Add from File and browse for a file containing the fully qualified host names of the computers to discover. If you want to discover all the resources, do not specify any hosts in the discovery list. If you leave the list empty, all resources on the server will be replicated. 9. In the Scope tab, select the Extended Attributes? check box. 10. Click Save. 11. Run or schedule the discovery.
What to do next
The computer extended attributes which have been discovered from TADDM are now visible on the Variables tab of the selected provisioning computer.
Running TADDM discovery

For details about how to create a TADDM discovery, see Configuring the TADDM discovery on page 237. To scan your TADDM environment and populate the data model:
Procedure
On the newly created discovery configuration, click Run Discovery to start the operation.
207
Results
You have discovered the resources of your TADDM environment.
What to do next
Before performing any software distribution operation on the computers imported from TADDM, you must manually add the service access point to them, because on the computers imported from TADDM the service access point is not automatically created.
Defining the Service Access Point for computers discovered from TADDM
Ensure that you define the Service Access Point (SAP) for computers which have been detected using a TADDM discovery before running any recommendations on them. When a computer is discovered into the data model from TADDM, you need to create a SAP for a root or administrator user ID, before running any recommendations on this computer. To manually add the service access point to the computer, perform the following steps:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Identify and click the computer for which you want to add a SAP. 3. Click the Credentials tab. 4. Click Add Credentials > New Service Access Point. 5. Add the user name root or administrator. 6. Set a password for the root or administrator user ID. 7. In the Workflows tab, assign the appropriate workflows to the SAP. 8. Specify the Protocol Type and Application Protocol parameters. 9. Assign the created SAP to the Command execution and File Transfer sections. 10. Click Save .
What to do next
Now that you have manually added the service access point to the computers imported from TADDM, you can run any recommendations on them.
Ready-to-use operating system discovery

If target resources discovered using TADDM have any of the following operating systems levels, the operating system will automatically be programmatically associated with the provisioning operating system software module and software device driver, and no further action is required on your part. If, however, your operating system is not in the list, you must add the operating system resource mapping to the discovery-resource-map.xml file in order to map the software model programmatically: Mapping discovered software to software definitions on page 210
Windows
v v v v v v Windows Windows Windows Windows Windows Windows 2000 Server 2000 Advanced Server 2000 Professional (SP 4) 2000 Server (SP 4) 2000 Advanced Server (SP 4) Server 2003 Standard Edition
208
v v v v v v v v v v v v
Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows
Server Server Server Server Server
2003 2003 2003 2003 2003
Enterprise Edition Enterprise Edition (SP 1) Standard Edition (SP 1) R2 Enterprise Edition (SP 1) Data Center Edition (Build (Build (Build (Build 3790 3790 2195 2195 Multiprocessor Free) Uniprocessor Free) Multiprocessor Free) Uniprocessor Free)
Server 2003 - 5.2 Server 2003 - 5.2 2000 Server - 5.0 2000 Server - 5.0 XP Professional Vista Ultimate Vista Enterprise
v Windows 2008 Standard v Windows 2008 Enterprise
AIX
v AIX 4.3 v AIX 5.1 v AIX 5.2 v AIX 5.3
SUN
v Solaris 5.8 v Solaris 5.9 v Solaris 5.10 v Solaris 2.6 v Solaris 7 v Solaris 8 v Solaris 9 v Solaris 10
Linux - Red Hat

v v v v Red Red Red Red Hat Hat Hat Hat Enterprise Enterprise Enterprise Enterprise Linux AS release 3 Linux AS release 4 Linux ES release 3 Linux ES release 4
v Red Hat Enterprise Linux Server release 5 v Red Hat Enterprise Linux Server release 5.1 v v v v Red Red Red Red Hat Hat Hat Hat Enterprise Linux Server release 5.2 Linux release 7.3 (Valhalla) Linux release 8.0 (Psyche) Linux release 9
HP
v HP-UX 11.0 v HP-UX 11i v1
209
v HP-UX 11i v2
Linux - SLES
v SUSE LINUX Enterprise Server 8 v SUSE LINUX Enterprise Server 9 v SUSE LINUX Enterprise Server 10
Mapping discovered software to software definitions

After running the TADDM discovery configuration, the discovered software is associated or mapped to a corresponding software definition. These mappings are defined in the file discovery-resource-map.xml. Sometimes, you might need to manually map these associations and then run the TADDM discovery again for them to be stored in the data model. To manually map the software definition:
Procedure
1. Open the file discovery-resource-map.xml located in %TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\ TADDMDiscovery\resource. 2. Provide the following associations: v discovered-software-installation name: Must match the name of the installed software displayed on the Software tab of the target computer. v software-module name: Must match the name of the existing software product. 3. Save your changes. 4. Run the discovery configuration again to update the data model.
Example
Examples of these mappings for
Windows Windows
and
Linux
operating systems are as follows:
<discovered-software-installation name = "Windows Server 2003 Enterprise Edition (SP 1) - Microsoft(R) Windows(R) Serve2003, Enterprise Edition"> <device-model-element>Windows Operating System</device-model-element> <os-type>Windows</os-type> <software-module>Windows Server 2003 Enterprise Edition SP1</software-module> </discovered-software-installation>
Linux
<discovered-software-installation name = "Linux - Red Hat Enterprise Linux AS release 4 (Nahant Update 1)"> <device-model-element>redhat-linux-operating-system</device-model-element> <os-type>Linux</os-type> <software-module>Red Hat Enterprise Linux ES release 4 (Update 1)</software-module>
Custom composite application discovery

TADDM provides a set of Java interfaces that you can use to plug in your own discovery implementation for a composite application. You can use this discovery implementation to discover a composite application from the TADDM server and map it to the provisioning data model. This file outlines how to create a specific customized application discovery implementation for Microsoft SQL Server using TADDM.
210
The example source code you need to use can be found on your provisioning server in this directory: v Windows: %TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\TADDMDiscovery\example\ v UNIX: $TIO_HOME/lwi/runtime/tpm/eclipse/plugins/TADDMDiscovery/example/ In our example situation, you have a Microsoft SQL Server discovered using the TADDM server in your data center. You want to bring this discovered SQL Server composite application into the provisioning data model, and also model it properly. After this, you can create an automation package for managing this SQL Server and the configurations that you have brought into provisioning. The current TADDM discovery does not bring SQL Server applications into the data model by default. However, because the TADDM discovery does provide an external interface, you can implement your own discovery and bring the SQL Server into provisioning. The following TADDM discovery interfaces are available for customers:
public ModelObject[] queryTADDMApplication(CMDBApi api, ComputerSystem computerSystem) throws ApiException, AttributeNotSetException List<SoftwareResource> processApplication(Connection conn, CMDBApi api, ComputerSystem computerSystem, int discoveryId, Server server, ModelObject applications[], OperatingSystem theOs) throws TaddmDiscoveryException;
The Java interface queryTADDMApplication is used to query the TADDM server to get the list of the application objects and their child objects. It passes the TADDM resource object as an input parameter and returns the list of the applications found on that resource. The Java interface processApplication is then used to take the application list that is retrieved from the TADDM server, process it and populate it into provisioning. In order to discover the SQL Server, and populate it into provisioning, you will need to create a Java implementation, and implement the queryTADDMApplication and processApplication interface. To 1. 2. 3. complete this task, you must: Set up a development environment Design and implement a Java class to populate a SQL Server application on page 212 Compile the code and install the code on the provisioning server under the plug-in directory on page 213 4. Register the SQL Server software module and the device module in TADDMDiscovery automation package. on page 214 5. Run TADDM discovery to verify the new implementation on page 214
Set up a development environment

This step is to ensure sure that you can write and compile your new implementation code. You must have Java 5 SDK to compile the new code. You can use any source code editor you want to write the Java implementation. Include the following JAR library in the class path as the new code will require these JAR in order to compile properly. These JAR files are available from the provisioning server:
211
%TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\datacentermodel_1.0.jar %TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\com.ibm.tivoli.tpm.software.jar %TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\TADDMDiscovery\TADDMDiscovery.jar %TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\TADDMDiscovery\taddm-api-client.jar
Design and implement a Java class to populate a SQL Server application

You need to decide how to model the SQL Server application in provisioning. There are many ways to model this. For best practices purposes, model a single SQL Server software installation (to represent the software installation object for this SQL Server), a SQL Server instance as a software instance, and one or more SQL database instances as software resource configuration data in provisioning. Some SQL Server configuration information is stored in a software configuration template. Based on this design, you can start the implementation by creating a Java called MSSqlServerApplicationAdapterImpl.java. You can then implement it based on the ApplicationDiscoveryAdapter interface as shown:
public class MSSqlServerApplicationAdapterImpl extends DcmObjectHandler implements ApplicationDiscoveryAdapter { }
You can find this Java class on your provisioning server in this directory: v Windows: %TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\TADDMDiscovery\example\ v UNIX: $TIO_HOME/lwi/runtime/tpm/eclipse/plugins/TADDMDiscovery/example/ Note: DcmObjectHandler is a super class that includes some of the helper methods necessary for implementation. In this new class, you implement two interfaces as previously described.
public ModelObject[] queryTADDMApplication(CMDBApi api, ComputerSystem computer) throws ApiException, AttributeNotSetException { ModelObject[] mos = api.find("select * from SqlServer where host.guid=="+ computer.getGuid()+"", 3, null, null); return mos; }
Note: This API is deprecated, but is still working with TADDM 7.1.2. The first interface queryTADDMApplication queries the TADDM server and gets the application list. A TADDM query API api.find() can be used to retrieve the information that you are searching for. For example, in order to get a list of the SQL Server objects, the query select * from SqlServer where host.guid==xxx can be used. Another query example is: select * from WebLogicServer where host.guid==xxx. This is to get the list of the Web logic server objects for a given resource system from TADDM. The queryTADDMApplication method returns a set of TADDM objects that provisioning can use to process, then you need to implement the second interface processApplication. Based on the design, you need to perform the following tasks to bring the SQL Server object into the data model: 1. Collect all configuration data from TADDM for this SQL Server. The SQL Server objects were returned by the TADDM query - this step is to get all required configuration parameters for each SQL server that is discovered such as product name and version number.
212
2.
3.
4.
5. 6.
7.
Create or associate a software definition with the discovered SQL Server. The software definition and software installation mapping can be registered under %TIO_HOME%\lwi\runtime\tpm\eclipse\ plugins\TADDMDiscovery\resource\discovery-resource-map.xml. When a software definition is associated with a specific software installation, and when there is a device module defined for the given software module, the software installation object can be managed by provisioning right after its discovery. In this step, it will try to find a registered software module in discovery-resource-map.xml for the given software installation name. If it cannot find one, it will create a software definition with discovered software information such as product name, version, or vendor. Find the software configuration template for the given SQL Server installation name based on the software definition. A software configuration template is used to store all configuration parameters that are discovered. If you already had an automation package written in provisioning for the SQL Server, a software configuration template might already exist that can be used to store the configuration data; otherwise, this step will create a software configuration template to be used. Obtain the device driver from the resource-mapping.xml file. If there is an automation package written, the device driver name can be registered in resource-mapping.xml file and loaded by this step. Create a Microsoft SQL Server installation object in provisioning, and attach the device module and software definition to this new installation object. Clone the software configuration template from the software module and attach the cloned software configuration template to the newly created Microsoft SQL Server installation object, then update the software configuration template parameter values based on the configuration details discovered from TADDM. This software configuration template includes all the configuration parameters that are discovered from TADDM, and it can be used by the automation package to manage the object. After creating the installation object, the SQL Server instance needs to be created . For each server, one or more database instances will also be created as configuration data. Device drivers and software modules can also be attached to the server level.
Compile the code and install the code on the provisioning server under the plug-in directory
If you have all the required JARs included in your class path, you might be able to compile your code without having any issues. An example makefile for Windows is available in the following directory: %TIO_HOME%\lwi\runtime\ tpm\eclipse\plugins\TADDMDiscovery\example\compile.cmd. If you run compile.cmd under the example directory, it will produce a binary class called MSSqlServerApplicationAdapterImpl.class. Because this class uses example as its Java package name, when it is put under the example directory, TADDMDiscovery code is able to load it during the run time. If you implement your code under a different package (for example, com.mypackage,) you need to ensure that the binary class is put under %TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\ TADDMDiscovery\com\mypackage\*.class) You also need to register your Java implementation under %TIO_HOME%\lwi\runtime\tpm\eclipse\ plugins\TADDMDiscovery\resource\taddm-application-registry.xml. add the following to the file in order to register your implementation class:
<application name="SQL Server" type = "Custom Application" class-name="example.MSSqlServerApplicationAdapterImpl"/>
Restart your provisioning server to pick up the class.
213
Register the SQL Server software module and the device module in TADDMDiscovery automation package.
When you have an SQL Server automation package written, you can register the software module and the device driver under %TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\TADDMDiscovery\ resource\discovery-resource-map.xml. The software module and device module correlation is done programmatically during the discovery. You need to restart the provisioning server to pick up the changes.
Run TADDM discovery to verify the new implementation

You can use the default TADDM discovery to run your new discovery. Your application will not be displayed in the web interface, but, when you run the discovery configuration, it will load your implementation class, run SQL Server discovery, and populate resources and configurations to provisioning based on your implementation. To verify that the SQL Server has been populated into provisioning: 1. Log on to provisioning. 2. Search for the resource that was discovered using TADDM discovery. 3. In its Software tab, find a software installation called Microsoft SQL Server Installation.
Database discovery configuration details

During the TADDM discovery, Tivoli Provisioning Manager tries to detect all the parameters which are described in this topic, depending on the different database you are discovering. One or more parameters might be unavailable at run time, for example when TADDM was previously unable to discover the parameters from the target computers. In this case, these parameters are not replicated into Tivoli Provisioning Manager.
IBM DB2 Database

For this type of database, the following attributes will be discovered:
product name product version for each DB2 instance: instance name instance port instance guid name and value of every instance configuration parameter available from TADDM at run time.
For example these attributes might be discovered:

(HIGH PERFORMANCE IMPACT) agentpri aslheapsz audit_buf_sz intra_parallel java_heap_sz (MEDIUM PERFORMANCE IMPACT) comm_bandwidth conn_elapse dft_mon_bufpool dft_mon_lock dft_mon_sort dft_mon_stmt dft_mon_table
214
(LOW PERFORMANCE IMPACT) authentication cpuspeed datalinks diaglevel (NON-PERFORMANCE-RELATED) catalog_noauth clnt_krb_plugin clnt_pw_plugin dftdbpath
Note: Refer to the TADDM documentation for details about these configuration parameters (CDM class: Db2InstanceConfigValue). Refer to the DB2 documentation for details about the meaning of each specific parameter.
Oracle database
For this type of database, the following attributes will be discovered:
product name product version for each Oracle instance: instance home instance name instance port instance guid from the database which the instance works for: name and value of every "inizialization parameter" available from TADDM at run time. A few examples might be: AUDIT_FILE_DEST BACKUP_TAPE_IO_SLAVES OBJECT_CACHE_MAX_SIZE_PERCENT
Note: Refer to the TADDM documentation for details about these configuration parameters (CDM class: OracleInitValue). Refer to the Oracle documentation for details about the meaning of each specific parameter.
Web server discovery configuration details

You can discover numerous configuration details about supported Web servers using TADDM. You can discover details about the following Web servers: v IBM HTTP Server v Apache server on page 216 v Internet Information Services (IIS) on page 217
IBM HTTP Server

For IBM HTTP Server the following configuration details can be brought into the data model: v admin.Service.active v AfpaCache v AfpaLogFile v AccessFileName v v v v AllowOverride doc.active DefaultIcon DirectoryIndex
215
v v v v v v v v v v v v v v v v v v
DefaultType DocumentRoot ErrorLog FancyIndexing HostnameLookups Installation path and credentials Installation location ihsselectLocale.lang ihsService.active installAfpa LogLevel HeaderName KeepAlive KeepAliveTimeout LanguagePriority MaxKeepAliveRequests MaxRequestsPerChild NTService.user
v NTService.password v NTService.confirmPasswd v Options v v v v v v v v v v v v PidFile security.active ServerName ServerType ServerRoot ServerPort ServerAdmin ScoreBoardFile ScriptAlias Timeout TypesConfig UseCanonicalName
v Web server instance v Web modules v WebSpherePluginConfig
Apache server
For Apache server the following configuration details can be discovered and populated into the data model: v v v v v Server instance Server port Web modules runAs installDirectory
216
v installExecPath v installLogFile v installTMPDirectory v imagePath v ServerDomain v uninstallProductID v The following Apache directives: AccessFileName AddIconByEncoding AliasMatch DefaultIcon DefaultType DirectoryIndex DocumentRoot ErrorLog ForceLanguagePriority HeaderName HostnameLookups
IndexIgnore KeepAlive KeepAliveTimeout LanguagePriority LogLevel MaxKeepAliveRequests MaxRequestsPerChild PidFile ReadmeName ScriptAlias ServerAdmin ServerName ServerRoot ServerTokens ServerSignature Timeout TypesConfig UseCanonicalName UserDir
Internet Information Services (IIS)

For Internet Information Services, the following configuration details can be discovered: v Server instance v Server port v Web modules and Web module path v runAs v imagePath
217
v These metabase properties: AdminACL AllowKeepAlive AnonymousUserName AnonymousUserPass AppAllowClientDebug AppAllowDebugging AspAllowSessionState AppPoolId AspAppServiceFlags AspCodepage AspEnableAspHtmlFallback AspMaxDiskTemplateCacheFiles AspQueueTimeout AspScriptEngineCacheMax AspScriptLanguage AspEnableChunkedEncoding AspDiskTemplateCacheDirectory
AspQueueConnectionTestTime AspEnableParentPaths AspEnableApplicationRestart AspRequestQueueMax ApplicationDependencies AspBufferingLimit AspEnableTypelibCache
AspScriptErrorMessage AspKeepSessionIDSecure AspExecuteInMTA AspExceptionCatchEnable AspLogErrorRequests AspCalcLineNumber AspBufferingOn AspTrackThreadingModel AspErrorsToNTLog AspScriptFileCacheSize AspScriptTimeout AspLCID AspMaxRequestEntityAllowed AspSessionTimeout AspProcessorThreadMax AspSessionMax AspRunOnEndAnonymously
AspScriptErrorSentToBrowser AspAllowOutOfProcComponents AuthChangeURL
218
AuthExpiredUnsecureURL AuthExpiredURL AuthFlags AuthNotifyPwdExpURL AuthNotifyPwdExpUnsecureURL CacheISAPI CentralBinaryLoggingEnabled CGITimeout ConnectionTimeout ContentIndexed DefaultDoc DirBrowseFlags DownlevelAdminInstance HttpErrors IIs5IsolationModeEnabled InProcessIsapiApps LogFileDirectory LogFilePeriod
LogFileTruncateSize LogInUTF8 LogOdbcDataSource LogOdbcPassword LogOdbcTableName LogOdbcUserName LogPluginClsid LogType MaxBandwidth MaxConnections MaxGlobalBandwidth
MinFileBytesPerSec PasswordChangeFlags ScriptMaps WAMUserName WAMUserPass WebSvcExtRestrictionList
WebSphere Application Server discovery configuration details

During the TADDM discovery, Tivoli Provisioning Manager tries to detect all the parameters which are described in this topic. One or more parameters might be unavailable at run time, for example when TADDM was previously unable to discover the parameters from the target computers. In this case, these parameters are not replicated into Tivoli Provisioning Manager.
IBM WebSphere Application Server

For this type of resource, the following attributes will be discovered:
product name product version product type
219
for each node: node name node guid cell name which the node belongs to authMappingModule authDataAlias mappingConfigAlias globalSecuritySettings activeIIOPProtocol cacheTimeoutMsecs enableJava2SecRuntimeFiltering enabled enforceJava2Security issuePermissionWarning useDomainQualifiedUserNames useLocalSecurityServer ldapUserRegistry baseDN bindDN monitorInterval reuseConnection searchTimeout sslConfig sslEnabled for each application server belonging to the node: name guid appClassloaderPolicy appClassloadingMode ejbContainerAttributes defaultDatasourceJNDIName InactivePoolCleanupIntervalMsecs passivationDirectory jvmSettings bootClasspath classPath debugArgs debugMode disableJIT executableJarFileName genericJvmArguments hprofArguments initialHeapSizeMB maximumHeapSizeMB runHprof verboseModeClass verboseModeGarbageCollection verboseModeJNI sessionTuningParameters allowOverflow invalidationTimeout maxInMemSessionCount processMonitoringPolicy autoRestart maxStartupAttempts nodeRestartState pingIntervalSecs pingTimeoutMSecs webContainer enableServletCaching sessionAffinityFailoverServer sessionAffinityTimeout
220
Note: Refer to the TADDM documentation and to the IBM WebSphere Application Server documentation for details about these configuration parameters (CDM classes: WebSphere*). Refer to the IBM WebSphere Application Server documentation for details about the meaning of each specific parameter.
Weblogic Server discovery configuration details

During the TADDM discovery, Tivoli Provisioning Manager tries to detect all the parameters which are described in this topic. One or more parameters might be unavailable at run time, for example when TADDM was previously unable to discover the parameters from the target computers. In this case, these parameters are not replicated into Tivoli Provisioning Manager.
Weblogic Server
For this type of resource, the following attributes will be discovered: Weblogic platform installation object
resource-name Vendor Guid deviceModelId
Note: The parameters installDir and beaHome must be updated using the correct values on the target computer, because TADDM cannot discover them. Weblogic Server and Administration Server object
resource-name deviceModelId Guid RootDirectory ServerName IsAdminServer DomainName ConfigFileName ConfigFileURI CompleteHTTPMessageTimeout CompleteIIOPMessageTimeout CompleteT3MessageTimeout DefaultProtocol DefaultSecureProtocol DefaultTGIOPUser HelpPageURL IdleIIOPConnectionTimeout JavaCompiler: CmdLine JDBCLogFileName ListenThreadStartDelaySecs LoginTimeout LoginTimeoutMillis MaxHTTPMessageSize MaxIIOPMessageSize MaxT3MessageSize ServerStatus StdoutSeverityLevel TunnelingClientPingSecs ThreadPoolPercentSocketReaders TunnelingClientTimeoutSecs MaxIIOPMessageSize MaxT3MessageSize ZACPublishRoot HTTPDEnabled IIOPEnabled InstrumentStackTraceEnabled JDBCLoggingEnabled JMSDefaultConnectionFactoriesEnabled
221
LogRemoteExceptionsEnabled NativeIOEnabled ReverseDNSAllowed SSL.KeyEncrypted SSL.SslPort SSL.SslEnabled SSL.TwoWaySslEnabled SSL.ServerCertificateChainFileName StdoutDebugEnabled StdoutEnabled TGIOPEnabled TunnelingEnabled ZACEnabled Process.CmdLine Process.CWD Process.Decrement Process.Env Process.DisplayName Process.Increment Process.InitialSize Process.MaxSize Process.MinSize Process.Size Process.WindowsServiceList
Weblogic Server J2EE deployed application software configuration data

resource-name J2EEAPPURI Guid
JDBC connection pool configuration data

resource-name URL MaxCapacity InitialCapacity JDBCDriverName JDBCCapacityIncrement PreparedStatementCacheSize RefreshMinutes SupportsLocalTransaction TestConnectionsOnReserve TestTableName TestConnectionsOnRelease ShrinkingEnabled ShrinkPeriodMinutes LoginDelaySeconds SupportsLocalTransaction JNDIName Guid JDBCConnectionURL JDBCConnectionMaxCapacity JDBCConnectionInitialCapacity
JDBC data source configuration data

databasePort connectionPool jndiName dbType databaseName oracleDBHost resource-name StreamChunkSize RowPrefetchEnabled RowPrefetchSize TwoPhaseCommitEnabled
222
JMS configuration data

resource-name JNDIName Destinations BytesMaximum BytesPagingEnabled BytesThresholdHigh BytesThresholdLow MessageMaximum MessagesPagingEnabled MessagesThresholdHigh PagingStore Store.DisplayName Guid
Note: Refer to the TADDM documentation and to the Weblogic Server documentation for details about these configuration parameters.
Discovery library adapter

The discovery library adapter is a provisioning workflow that allows you to export hardware and software information that is in the provisioning data model and share this information to other products that can read and consume the network information. The discovery library adapter enables you to discover resources defined in the provisioning data model database, and then write provisioning resources into a discovery library book based on a common data model (CDM) schema.
Discovery process
The discovery library adapter takes the resources from provisioning and writes them back to discovery library books. The following diagram shows how discovery library adapters perform discovery and how products consume that information. There are two different discovery library adapters in this diagram: the provisioning discovery library adapter, represented with the orange numbers; and third party ones, represented with the blue numbers.
223
Discovery books
2 Generates
Provisioning server
XML
Discovery library adapters
2 Generates
1 Scans
Data center
3 Updates
IT Infrastructure
Discovery library adapters

Discovery library reader Vendor 1
1 Scans
3 Consumes
Vendor 2 Tivoli Change and Configuration Management Database
Vendor 3
Figure 1. Discovery process using discovery library adapters
Provisioning discovery library adapter

To get the most recent version of the provisioning discovery library adapter, visit the IBM Integrated Service Management Library. 1. The provisioning discovery library adapter runs an automation package to discover what is defined in the data model. 2. A discovery library book is produced. 3. The IBM TADDM consumes the discovery library book.
Generating a discovery library book for export

The discovery library adapter is a discovery application that allows you to discover hardware and software in the provisioning data model and share this information to other products that can read and consume the network information.
224
Before you begin

Using Tivoli Provisioning Manager version 7.2, the produced xml discovery library books can only be imported into TADDM version 7.2.x, not 7.1.x or earlier versions. The supported reference schema version for CDM is 2.10.6. The provisioning discovery library adapter is a bridge that allows information from the data model to be used in other configuration management databases. Such as any other discovery configuration, you can run the discovery immediately or schedule it to run periodically. To generate a discovery library book:
Procedure
1. Click Go To > Administration > Provisioning > Provisioning Workflows. 2. Identify and select one of the following provisioning workflows: v DiscoveryLibraryAdapter if you want to export into the book all the data model objects of your environment. v DiscoveryLibraryAdapterExportByDevices if you want to export into the book only the list of computers you specify. v DiscoveryLibraryAdapterExportBySoftwareProducts if you want to export into the book only the software catalog. 3. From the Select Action menu, click Run Workflow. 4. Specify the workflow parameters. 5. Click Run.
Results
The xml discovery library book is created in the location specified in the path and the creation date of the book corresponds to the Coordinated Universal Time (UTC) and not to the product timezone. Exporting the discovery library book to the IBM TADDM: If you want to export this newly created discovery library book to the IBM TADDM, you must ensure that the MAC address for each resource is defined in order for the TADDM to recognize the contents of the book. After you have run the DiscoveryLibraryAdapter provisioning workflow, you can verify if the resources have MAC addresses defined. Procedure 1. Click Go To > Administration > Provisioning > Provisioning Workflow Status. 2. Click the Deployment Request to view the status. For each resource, you will see a description similar to
There is no Primary Mac address found on the computer x. This computer will not be written into the book.
What to do next You can either automatically or manually add the MAC address to resources. Automatically Run provisioning Inventory discovery or provisioning network discovery
225
Manually For each resource, look at its Hardware tab, and for each network interface card, click NIC, and then specify the MAC addressin the MAC field. Note: Software installations for those resources without operating systems defined will also not be exported to the TADDM. To verify if the operating system is defined, perform the following steps: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. In the Operating System column, see if there is anything defined. After adding the MAC address, you need to generate the provisioning discovery library adapter again. Your book is now ready to be exported to the IBM TADDM. A Tivoli Directory Integrator (TDI): Discovery Library Integration Framework Plug-in for Tivoli Provisioning Manager can be downloaded from the Integrated Service Management Library website, and enables you to automate the Discovery Library Adapter (DLA) book creation from Tivoli Provisioning Manager and import it into TADDM. This procedure is valid for Tivoli Provisioning Manager 7.1 and has not been verified for Tivoli Provisioning Manager 7.1.1 and 7.2.
Modifying the MAC address for discovered computers

If you export a discovery library book generated using the discovery library adapter and then try to import it into TADDM, the computer will not be recognized by TADDM if the MAC address has not been defined for this computer. To create a MAC address for a computer perform either the provisioning network discovery or the provisioning Inventory discovery. MAC addresses are populated by both discoveries. If you need to modify later the MAC address for a discovered computer, perform these steps:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Select the computer to view the Hardware tab. 3. Expand the Local Area Connection table to find a network interface card. 4. Specify the MAC address in the MAC field. 5. Click Save .
Results
The MAC address is now added to the computer.
What to do next
You can now import the discovery library book into TADDM. You can view the status of the workflow by performing the following action: v Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking.
Enabling the Network Address Translation support

For both agent discovery configurations (IBM Tivoli Agent Manager Discovery and IBM Tivoli Agent Manager Discovery Device discovery configurations) an option is provided that will use the observed IP address as the management IP for each target computer. When this parameter is set, the agent discovery will not attempt to verify that the observed management IP is in the list of the supported IP addresses for that target computer, because in the Network Address Translation (NAT) that IP address would not be
226
present. This feature ensures that any operation initiated using the deployment engine (DE) correctly discovers the target computer using the NAT addressing. To enable the NAT addressing for the target computers, perform the following steps:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. . 2. Click New Discovery Configuration 3. In the Method field, select IBM Tivoli Agent Manager Discovery or IBM Tivoli Agent Manager Discovery Device. 4. Enable the NAT support by setting the Use Observed IP as network management IP property to true. 5. Run the agent manager discovery.
Results
You are now able to run the workflow using the deployment engine on the target computers discovered using the NAT addressing.
Verifying discovered resources

After running a discovery to populate the data model, you can validate the various resources in the web interface.
Identifying discovered resources

After running a scan, you can view the resources that are now populated into the data model. To view discovered resources:
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. From the Select Action menu, click Discovered Resources. 3. Filter the discovery configuration that was used to discover the resources. Note: Specify the discovery configuration by opening the filter available on this window, instead of clicking the name of the discovery configuration from the list which might cause the following error message:
BMXAA2278E - You do not have authorization for the Application Designer application.
4. From the Select Discovered Resources Type menu, select one of the available options. 5. Specify the time period of the last scan to search for resources that were discovered during that particular time period. A default time period is already pre-filled. 6. Click Search.
Results
A list of resources that have been found will be displayed.
Verifying discovered Microsoft Active Directory resources

After running discovery to populate the data model with your Microsoft Active Directory information, you can validate the various resources in the web interface.
227
Microsoft Active Directory discovery will find the following resources: v Computer information v Microsoft Active Directory groups
Verifying computer information

Attention: If you move computers from one domain to another in Microsoft Active Directory, then ensure that you also clean up any old entries in your Microsoft Active Directory configuration. Otherwise, these computers will be discovered and populated into the data model. Eventually, these computers will also get added to the inactive Microsoft Active Directory computers group when the last logon period is exceeded. To verify any computer information found on a Microsoft Active Directory computer, do the following:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Search for a computer that was discovered by the Microsoft Active Directory discovery configuration and click on it. 3. From the Computer page, verify the correct host name and networking information. 4. Click the Variables tab to verify the variable data and the last scan data. 5. Click the Software tab and verify the software information. 6. Optional: If any operating system information was discovered, it will be specified as a software installation on the computer. Click the Software tab to verify this information.
Verifying group information

You can validate group data found on one or more groups discovered by the Microsoft Active Directory discovery configuration. Note: On the Microsoft Active Directory computer, groups are found in organizational units (OU) under the domain name. For example, DN = mydomain.com. Not all groups can be discovered but only those groups that are associated with a computer. To verify if a group is associated with a computer, open the properties of the group and select Members.
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. 2. Search for a group that was discovered by the Microsoft Active Directory discovery configuration and click on it. 3. From the Group page, verify the group data.
Finding inactive computers

You can search for computers that have been inactive or unused after a specific number of days. A provisioning workflow is provided that will put these inactive computers into a group in the data model. You first need to enable this provisioning workflow and then the next time you run Microsoft Active Directory discovery configuration, it will put any inactive computers in a group in the data model To enable this provisioning workflow and see a list of inactive computers:
Procedure
1. Click Go To > Administration > Provisioning > Provisioning Workflows. 2. In the Name field, type MSAD and click Search. A list of Microsoft Active Directory provisioning workflows are displayed in the list.
228
3. 4. 5. 6. 7.
Find and click MSAD_Discovery_Profile_Update. From the Select Action menu, click Run Workflow. For the DiscoveryID, specify the object ID for the Microsoft Active Directory discovery configuration. Specify the days that the computer was last used. In the isScan field, type true to enable the provisioning workflow.
8. Click Run.
Results
The provisioning workflow is now enabled to find inactive computers and put them into a new group. The next time you run a Microsoft Active Directory inventory scan, any inactive computers will be put into the provisioning group called MSAD Inactive Computers Group <discoveryID>.
Discovery consolidation rules using different discovery configurations

Different discovered results are displayed in the data model when running discovery. There are various consolidation rules that provisioning will apply depending on which discovery application is used the next time updates are made to the data model. If the next time you run a discovery and you use a different discovery configuration, that discovery method would use certain criteria to locate an existing computer or resource first to see if there was a match in the data model before creating a new resource to the data model or updating it accordingly. Here are the consolidation rules for the following discovery configurations. Note: The rules are displayed in descending order. This means that when discovery is run, the first item in the list will be matched against existing resources. If nothing is found, then the second item will be looked on and so forth. Provisioning network discovery (RXA or SNMP) 1. The NIC MAC address of the management interface. 2. Both the IP address + the fully qualified host name. 3. The IP address + short name. This short name is the first part of the fully-qualified name. For example, if the fully-qualified name is mycomputer.location.ibm.com then the short name would be "mycomputer". Microsoft Active Directory discovery 1. The distinguished name (DN). 2. The fully-qualified name as device name. 3. The short name as device name + the IP address. 4. The IP address + the device name starting with the short name. This short name is the first part of the fully-qualified name. For example, if the fully-qualified name is mycomputer.location.ibm.com then the short name would be "mycomputer". TADDM discovery 1. The Global Unique Identifier (GUID) set by TADDM. 2. The NIC MAC address of the management interface. 3. Both the IP address + the fully qualified host name. 4. The IP address + short name. This short name is the first part of the fully-qualified name. For example, if the fully-qualified name is mycomputer.location.ibm.com then the short name would be "mycomputer".
229
Discovery consolidation rules for different software installations

There are various consolidation rules that provisioning will apply depending on which software installation is discovered the next time updates are made to the data model. If the next time you run a discovery and you discover a different software installation, that discovery would use certain criteria to locate an existing software installation first to see if there was a match in the data model before creating a new software installation to the data model or updating it accordingly. Here are the consolidation rules for the software installations. Note: The rules are displayed in descending order. This means that when discovery is run, the first item in the list will be matched against existing software installations. If nothing is found, then the second item will be looked on and so forth. Provisioning Inventory discovery If you perform a software signature scan: 1. The Global Unique Identifier (GUID) associated to the software signature. If you perform a registry scan: 1. The name and version of the software installation. 2. The name of the software installation only. TADDM discovery 1. The Global Unique Identifier (GUID) set by TADDM. 2. The name and version of the software installation.
Tutorial: Discovering your environment

This tutorial demonstrates how you can discover the resources of your environment and collect their information. For this tutorial, you will perform the following tasks: Create and run a specific discovery After installing Tivoli Provisioning Manager, you will perform a discovery for the first time. This discovery enables you to discover in your environment the resources that you specify using the discovery wizards application. Manage the collected information You can retrieve the collected information about your environment, and then you can decide how to manage the resources you have discovered.
Learning objectives
In this tutorial you will learn how to: v v v v Create a specific discovery Submit a specific discovery Track the discovery results Learn how to manage the collected information
This tutorial might take approximately 2 hours to finish. If you explore other concepts related to this tutorial, it can take longer to finish. Installation times are not included.
230
Part 1: Discovering your resources

To populate the provisioning database, named data model, with the network data of the target computers discovered in your environment, you must run a discovery after the product installation. For this part of the tutorial, you will perform the following tasks: Create a specific discovery After installing Tivoli Provisioning Manager, you must define a specific discovery using the discovery wizards application. Track the discovery results After running a specific discovery, you can monitor the displayed discovery results.
Discovery wizard overview

After installing the product, you can run a specific discovery to discover the resources of your environment and to populate the data model with all their hardware and software information. The scope of the provided discovery wizard is to perform a network discovery of the computers. In addition to the network discovery, you can choose to perform one or more of the following actions: v Install the common agent on these computers. v Detect their hardware and software information by performing an Inventory scan. v Run a Windows discovery.
Discovering your environment using the ready-to-use network discoveries

Initiate a network discovery using the discovery wizard application to start discovering your resources and to populate the data model with their data. To discover the computers in your environment leveraging the ready-to-use discoveries provided, perform the following steps: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Wizards. Or access the discovery wizard application by clicking directly the Start Center link. 2. Click the List tab. 3. Depending on your needs, run one of the following ready-to-use discoveries: v Use Computer Discovery to perform a network discovery of the computers in your environment. v Use Computer and Inventory Discovery to perform a network discovery of the computers and run a hardware and software scan on these computers. v Use Computer Discovery, Common Agent Installation and Inventory Discovery to perform a network discovery of the computers, install the common agent on these computers, and run a hardware and software scan.
Discovering your environment customizing your own network discovery

Perform a network discovery using the discovery wizard application to customize your own discovery. To discover the computers in your environment customizing your own discovery, perform the following steps: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Wizards. Or access the discovery wizard application by clicking directly the Start Center link. . 2. Click New 3. Enter a name and a description for the new discovery. The Discovery Wizard is a required field, while the description field is optional.
231
4. From the Target Source Type menu, you must choose how to retrieve the targets by selecting one of the following options: v Select from targets If you want to retrieve the targets from existing lists of computers or computer groups. v Run network discovery If you want to display a RXA network discovery configuration page. Note: If you want to create a provisioning group before running this network discovery, you can later on manually assign the discovered computers to it. 5. (Optional) Click Do you want to install the Tivoli Common Agent? to install the common agent on the computers you have specified. Use this option only if you have a depot server installed in your environment. 6. (Optional) Click Do you want to run the Tivoli Provisioning Manager Inventory Discovery? if you want to perform an inventory scan on these computers. You can specify the type of inventory scan you want to perform. If hardware scan, software scan, or both. 7. (Optional) Click Do you want to run the Windows Discovery? if you want to perform a discovery of Windows computers to detect Windows specific information such as user accounts and user domains. 8. Click OK. The Select Targets page is displayed. 9. Perform one of the following actions: a. If you have selected Select from targets you can specify which computers or groups of computers you want to discover from the list. To display the available lists, click Select and then either choose Computers or Groups from the menu. b. If you have selected Run network discovery specify which discovery parameters you want to use to discover your computers. The Run network discovery option gives you the possibility to define a valid range of IP addresses, host names of computers, or a subnetwork. All these parameters can be imported from a file or defined manually. 10. If you have performed step 6, click Inventory Discovery to display the related page. a. Select Hardware to perform a hardware scan on the computers discovered. b. Select Software to perform a software scan on the computers discovered. c. Click one of the following available options: v Use registry: Scans the registry of the resources. v Use software signature: Scans for all available software signatures. Note: This will run an inventory scan to a target using all defined signatures in the signature catalogue to find any matches. It might take some time to complete the scan. v Use selected software signature: Filters by signature type. If this option is selected, then select the type of signature to search on from the list. For details about how to create or modify software signatures, see Adding software signatures on page 170. 11. Click Review and Submit to display the related page. 12. In the Summary section, verify that all selections made in the wizard are correct. 13. (Optional) Click Schedule to specify some scheduling options for the new discovery, if you do not intend to run it immediately. 14. Click Submit. You have configured and submitted a discovery that detects the computers of your environment and their hardware and software information, installs the common agent, and performs a Windows discovery.
Tracking the discovery progress and rerunning the task

After running a specific discovery, you can monitor the discovery progress. After submitting any type of discovery, you are automatically redirected to the Provisioning Task Tracking page.
232
If you leave the discovery progress page, you can always monitor the discovery status later on, by performing the following actions using the web interface: 1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. 2. Click the task name from the displayed list to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status. 3. If the task you are monitoring is a discovery, when you select the Run Task Again option available from the Select Action menu, the target computers are not recalculated. If you run again the task, the target computers taken into account are the same computers that you specified initially in the discovery wizard. Even if new computers have been added after the discovery wizard creation, these are not considered by the task. Also the unknown resources, that provisioning could not reach for various reasons when performing a discovery, are not passed to the task.
Part 2: Managing discovered resources

After you have populated the provisioning database, named data model, with the hardware and software information of the target computers discovered in your environment, you can manage the discovered resources. For this part of the tutorial, you will perform the following tasks: Manage unknown resources You can decide if you want to either rediscover or ignore those resources that the system for various reasons cannot log on to. Collect information about discovered resources To retrieve the collected information about your environment, you can either run a predefined report or you can customize your own report.
Managing unknown resources

Unknown resources are resources that the system cannot log on to, when performing a network discovery, for various reasons. To manage the unknown resources perform the following actions using the web interface: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Unknown Resources. 2. Perform one of the following actions on these resources: a. Click Run Discovery if you want to run an additional discovery against a set of unknown resources, when the previous discovery ended with an error. Depending on the type of error, solve the problem that caused it, as for example correct the wrong credentials or start the login services, and then rerun the discovery. b. Click Ignore Resource if you no longer intend to manage the unknown resource. It might be a printer or any other type of resource that provisioning cannot manage. When you ignore a resource, this resource is no longer shown in the web interface. You can reactivate the ignored resource later on if you want to manage it again. c. Click Reactivate Resource if you want to undo the ignore operation for that resource. d. Click Save as if you want to save the resource as a known resource, manually editing the missing information.
Collecting discovery information

To retrieve the collected discovery information about your environment, you can run predefined reports or you can customize your own report. You can access and run the predefined reports either from the Start Center or by performing the following actions: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. Click Run Reports from the Select Action menu.
233
Tutorial: Replicating business applications from TADDM

This tutorial demonstrates how Tivoli Provisioning Manager can discover the business applications on computers from TADDM. You can discover all your business applications defined on TADDM and replicate them in the data model.
Learning objectives
In this tutorial you will: v Learn how to configure and run a discovery for business applications installed on your TADDM resources, to synchronize discovery data between TADDM and the data model. v Learn how to view discovered business applications in the data model. v See how business applications on your TADDM server are mapped on the Tivoli Provisioning Manager server.
Prerequisites
Before you start, you need the following: v A Tivoli Provisioning Manager server. v A TADDM server.
Part 1: Defining business applications on TADDM server to be replicated into Tivoli Provisioning Manager
In this section, you will learn how to define on the TADDM server the business applications manually, or by importing them using an XML file. You will also learn how business applications are structured, their naming conventions, and how they are mapped from TADDM into the Tivoli Provisioning Manager data model. This section contains the following lessons: Considerations on business applications Business applications consist of components grouped in functional groups in TADDM, while they have a tier-based structure in Tivoli Provisioning Manager. Guidelines for defining the business applications You can define the business applications on the TADDM server, either manually using a wizard, or importing them using application descriptor XML files. The XML descriptors must be deployed on the target computers of the data center. When TADDM discovers these computers, the XML descriptors enable TADDM to build the topologies of the distributed applications. Overriding the business application rules You can override the business application rules followed by the standard Tivoli Provisioning Manager behavior, by customizing the ba-naming.properties file. What you can override is the way how the tiers are numbered based on the functional group names, because you can specify these rules in the ba-naming.properties file.
Considerations on business applications

Business applications consist of components grouped in functional groups in TADDM, while they have a tier-based structure in Tivoli Provisioning Manager. For more details about concepts such as functional groups and business applications, refer to the Tivoli Application Dependency Discovery Manager: Application Dependency Discovery Manager User's Guide.
234
To every functional group located on theTADDM server corresponds a tier on the Tivoli Provisioning Manager server. Every functional group hosts a number of technologically homogenous components. Every component is based on a target computer. Every business application consists of one or more tiers, and every tier is hosted on one or more target computers. More computers might belong to a tier. In the current implementation, the following limitation applies: in Tivoli Provisioning Manager a computer can only serve in one single tier of one single business application of one single customer. If you have, in the TADDM environment, a computer which is used by multiple components across all business applications, this information will not correctly be reported into the Tivoli Provisioning Manager server. A customer name is a logical way of grouping business applications that belong to the same customer. The object customer only exists in Tivoli Provisioning Manager, while in TADDM the object customer is not defined. In the current implementation, we have assumed that a customer name can be embedded in the URL of the description page of the business application. With this assumption we can define a customer entity also in the TADDM domain.
Guidelines for defining the business applications

You can define the business applications on the TADDM server, either manually using a wizard, or importing them using application descriptor XML files. For more details about these procedures, refer to the Tivoli Application Dependency Discovery Manager: Application Dependency Discovery Manager User's Guide. To be supported and successfully discovered by the Tivoli Provisioning Manager server, the business applications must be created, on the TADDM server, following these guidelines: v The application tier name and tier number must be embedded in the name of the functional group. v The customer name must be embedded in the URL of the business application description page. When defining the business application functional groups, on the TADDM server, ensure you use the following naming conventions:
tierName.specificTechnology
Note: If you use this naming convention, the tier number is decided according to rules which are hard coded in Tivoli Provisioning Manager. or
tierName.tierNumber.specificTechnology
for example:
db.2.oracle
Where: tierName Is the name of the business application tier, such as db in this example. tierNumber Is the number corresponding to the business application tier, such as 2 in this example. specificTechnology Is the vendor specific technology used by the business application, such as oracle in this example.
235
When defining the business application descriptor pages, in URL format, on the TADDM server, ensure you use the following naming convention:
protocol://customerName.*/page
for example:
http://customer2.company.com/description.html
Where: protocol Is the protocol used to access the URL page, such as http. The URL page does not need to physically exist. It can also be a fake URL address. customerName Is the name of the customer, such as customer2. The name of a customer represents a logical group of business applications used by the same customer. The customer name is required in Tivoli Provisioning Manager for every business application, while such a concept does not exist in TADDM. Note: In case the customer name is missing, the business application is saved in a group named Default Customer. page Is the name of the HTML page which contains the description of the business application, such as description.html.
In Tivoli Provisioning Manager a properties file named ba-naming.properties is provided together with the TADDM-discovery tc-driver. The properties file is located in the resource folder of the driver. The purpose of this file is to completely customize the tier numbering rules, overriding the default rules of the product.
Overriding the business application rules

You can override the business application rules followed by the standard Tivoli Provisioning Manager behavior, by customizing the ba-naming.properties file. The following is a sample properties file provided by Tivoli Provisioning Manager:
#enabled= true => use this properties file #enabled=false => do NOT use these rules. Use the hardcoded rules instead. enabled=true #On the left the functional group name. #On the right, the desired tier number. #NOTICE: the keys cannot contain any blank! other.java=3 java.java=1 db.db2=2 db.mysql=2 web.iis=0 web.apache=5 web.sunone=5
This file contains key-value pairs. In particular the enabled key, which can be set to true or false, must be located. If its value is set to true, the embedded rules are not active and the rules defined inside the properties file are valid instead. Any other key of the properties file works as follows: the key is the name of a functional group, the assigned value is the arbitrary number that the user wants to assign to the tier, when created on the Tivoli Provisioning Manager server. For example, if in the properties file you have specified:
db.mysql=2
236
It means that: v A functional group named db.mysql will generate a tier named db.mysql. v The tier named db.mysql will have tier number 2.
Part 2: Discovering business applications on Tivoli Provisioning Manager server

Discovery provides a way to find out or discover new resources. When you discover resources, such as business applications, they become part of the data model. In this section, you will perform the following tasks: Configure the TADDM discovery By configuring a discovery configuration, you are setting up the discovery parameters and scope to populate the data model with your resources. Run the TADDM discovery The TADDM discovery configuration is used to discover the computers from TADDM and populate them into the data model.
Configuring the TADDM discovery

When you create a discovery configuration, you are defining the discovery method and the scope of the discovery that you want to perform. Using the TADDM discovery, you can discover not only hardware and software resources but also business applications known to TADDM. When this discovery is run, it calls Java code to obtain the discovered resources from TADDM and then populates these resources into the data model. To configure the discovery configuration: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. 3. 4. 5. 6. 7. Click New. Type the name and description for the discovery. In the Category field, select Hardware Discovery. In the Method field, select TADDM Discovery. Click OK. In the Server Information tab, provide the following TADDM server information: v Name: The fully qualified host name or the IP address of the TADDM server.
v Port Number: The port number of the TADDM server. v User ID and Password: The TADDM server administration user ID and password. 8. (Optional) In the Computer to be Discovered tab, specify the fully qualified host name of the computers you want to discover. Only the computers that you specify in this list are replicated from the TADDM server. To specify the host names you can click either New Row and enter the computer host name or Add from File and browse for a file containing the fully qualified host names of the computers to discover. If you want to discover all the resources, do not specify any hosts in the discovery list. If you leave the list empty, all resources on the server will be replicated. 9. In the Scope tab, select the Business Application check box to ensure that business applications will be discovered on the TADDM server. 10. Click Save. The TADDM discovery configuration is now configured and you are ready to run it.
Running TADDM discovery

Now that you have configured your discovery configuration, you can populate the Tivoli Provisioning Manager data model with your TADDM resources and discover their business applications.
237
To 1. 2. 3. 4.
scan the resources in your TADDM environment and populate the data model: Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. Locate and click the Tivoli Application Dependency Discovery Manager Discovery configuration. Click Run Discovery. (Optional) Set the available scheduling options, to perform a periodic discovery of your business applications and keep updated your TADDM resources in the data model. 5. Click Submit. You have now run a discovery to discover computers and business applications. These computers have been populated in the Tivoli Provisioning Manager data model. You can now view the list of the discovered resources defined on TADDM.
Part 3: Viewing discovered business applications

In this section, you will view the results of the discovery you have run against your TADDM resources. To do this, you will need to perform the following tasks: Display the discovered resources View and verify the resources and their business applications discovered from the TADDM server. Map the discovered results Map the business applications imported into the Tivoli Provisioning Manager data model with the business applications defined on the TADDM server.
Displaying and verifying discovered results

Now that you have run your discovery configuration to populate the Tivoli Provisioning Manager data model with your TADDM resources and discover their business applications, you can display the results of your discovery. To display the result of your TADDM discovery from the Web interface: 1. Click Go To > Security > Security Group. 2. Select the MAXADMIN group, in the Application tab filter for Application Tier, Provisioning Customers, and Provisioning Customer Application and grant full rights to all three of them. 3. Restart the server to reflect the changes. 4. Click Go To > Administration > Provisioning > Provisioning Customers. 5. Locate and click the name of the customer you want to search. You have now displayed the list of the discovered computers and their business applications. Verify that the discovered business applications are correctly imported into the data model. For each business application the following elements must be created and displayed by Tivoli Provisioning Manager: v Customer name v Application name v Functional group, named "tier" on Tivoli Provisioning Manager Also verify that the business applications already imported into the data model and then modified since the last discovery, are correctly updated and re-imported into the database. Business applications can be added, changed, or deleted on Tivoli Provisioning Manager, reflecting the new structure they have on TADDM. These changes include also the creation of a new customer name, while the delete operation of a customer is not automatically supported on Tivoli Provisioning Manager.
238
Mapping discovered business applications

Now that you have displayed and verified the results of your discovery, you can learn how business applications are imported from TADDM, by mapping business applications on TADDM with Tivoli Provisioning Manager discovered business applications. For example learn how computers are mapped with the different tiers. The computers defined on TADDM in the same tier are computers that belong either to the same functional group or to different functional groups, but have the same tier name.
Table 44. Computers defined on TADDM Computer name lab133065.romelab.it.ibm.com lab134065.romelab.it.ibm.com Functional group db.2.db2 db.2.oracle
Table 45. Same computers imported into Tivoli Provisioning Manager after the discovery Computer name lab133065.romelab.it.ibm.com lab134065.romelab.it.ibm.com Application tier db Tier number 2
In this example computers having different functional groups on TADDM are stored under the same application tier on Tivoli Provisioning Manager. In this example, the default naming rules are used, not the rules defined in the ba-naming.properties file.
Troubleshooting discovery
When you run a discovery, there are multiple product components that handle the discovery task. To identify the source of a discovery problem, it is important to understand the components that process a discovery task. Use the information on the Process section to learn about the main steps that occur during discovery. Use the remaining sections to find out how to troubleshoot discovery errors that occur during specific parts of the process. v Process v 1. Task status on page 240 v 2. Publish status on page 242 v 3. Job status on page 242 v 4. Target status on page 243 v 5. Results on page 244
Process
To demonstrate how components interact, the following steps outline the component interactions during an Inventory discovery that uses software signatures on target computers in an environment that uses the scalable distribution infrastructure. 1. The task is submitted and activity plan engine starts task execution. 2. The deployment engine runs the workflow to perform the discovery. 3. The software signature file is published to the depot. 4. The job is submitted to device manager. 5. The target computer polls device manager for the job and runs the following items: a. The software signature file is downloaded from depot.
239
b. The Inventory discovery scan runs on the computer. c. The scan result is uploaded to the provisioning server queue. 6. The discovery engine worker processes the results, picking up the results from the queue. If an error occurs during discovery: 1. Verify that all requirements for discovery are met as described in Requirements on page 152. 2. Use the subsections of this topic to learn more about how to troubleshoot specific parts of a discovery task. The troubleshooting steps for discovery in this topic are based on the process for an Inventory discovery using the scalable distribution infrastructure, but many of the steps apply to other types of discoveries. Note: If there is an error message in the interface or the log files with a message ID, you can check the Messages section under Reference for a description of the error message.
1. Task status
Check the status of the discovery task. For information about task status, see Tracking a provisioning task on page 1165. 1. Check for error messages that might explain the source of the problem. 2. On the provisioning server, check the log files for the activity plan engine and the deployment engine. By default, the log level for console.log is info and the log level for trace.log is error. Change the log level to debug to obtain more troubleshooting information. For information about setting the log level, see Configuring log4j dynamically
Table 46. Log files Log file console.log Location
Windows
%TIO_LOGS%
Linux
UNIX
$TIO_LOGS
trace.log
Windows
%TIO_LOGS%
Linux
UNIX
$TIO_LOGS
The following excerpts from console.log show key messages for a successful discovery task: This line indicates that the task has started.
DEBUG [Activity Plan Engine] ( TpmTask.java:55) manager.TpmTask: Task execution started: Discovery.OnDevice
The following line shows that permissions were successfully verified on the target computer.
DEBUG [Discovery.OnDevice(77401) from com.ibm.tivoli.tpm.activityplan.manager.AggregateTaskDispatcher] (WorkflowAccessManager.java:106) accesscontrol.WorkflowAccessManager: checking permission (target:1411)Discovery.OnDevice Discovery.OnDevice on 22305 succeeded
If you encounter discovery errors with permissions, check the following information: v Lack of information from Initial Discovery on page 245 v Deployment engine exception when running discovery on page 254 The following lines show that the provisioning workflow was started.
INFO [Discovery.OnDevice(77401) from com.ibm.tivoli.tpm.infrastructure.soa.OSGiSdiTaskDispatcher] (MessageTranslatorProxy.java:303) messagetranslator.MessageTranslatorProxy: createDeploymentRequest(workflowName=Cit_SDI_OnDevice) DEBUG [Cit_SDI_OnDevice(11200)] (WorkflowExecutionMonitor.java:67) komodor.WorkflowExecutionMonitor: Starting workflow: Cit_SDI_OnDevice.java
3. If the provisioning workflow fails, a message appears in the log.
240
COPINF029E The system failed to run the workflow Cit_SDI_OnDevice in order to process execution through the infrastructure.
Check the logs for the Cit_SDI_OnDevice provisioning workflow in the web interface to determine where the error occurred. The error messages in the log can help you to identify which component is the source of the problem. 4. Open the Workflow Execution Logs view if it is not displayed. a. From the Eclipse menu, click Window > Show View > Other. b. Expand Automation Package and click Workflow Execution Logs. c. Click OK. The Workflow Execution Logs page displays the provisioning workflow run history. There is a limit of 4000 characters for provisioning workflow output. If this limit is exceeded, the output is truncated. You can check the workflowlogexport.xml file to try to identify where any errors occurred as a workflow is executing. Check the workflowlogexport.xml file for the following: 1. The line tagged with the deployment request contains a lot of information. In particular, this line contains: v The unique deployment request number of the workflow operation, for example, 11309. v The error details string. This is a complete error stack that you or IBM Support can use to trace the stack exception. v There might be clues to the problem is in the string error message. This is also a good starting point for troubleshooting. v The error code provides a Tivoli Provisioning Manager specific error, normally of the form ABCDEF###E. For example, COPDEX040E or COPCOM123E. v The status code at the end of the line is useful and can indicate failed or success or in-progress. If you are calling IBM Support, provide Support with this status code. The following sample extract from a workflowlogexport.xml shows the relevant content marked in bold font:
<deployment-request id="11309" error-details=" Device$CopyFile(line:24) Apache_Install___Red_Hat ... at com.ibm.tivoli.ldo.runtime.WorkflowExecutionThread. run(WorkflowExecutionThread.java:84)" error-message= "SourceDeviceID is a required parameter" workflw-name="SoftwareModule.Install" create-username=">MAXADMIN" error-code= "COPDEX123EworkflowThrownException" status="failed"
2. Search the workflowlogexport.xml file to try to identify the line where the error occurred. When a workflow executes successfully, it involves a series of steps, each of which executes in turn. When an error occurs, a message is written to the workflowlogexport.xml and workflow code stops execution. As the workflow steps the execution of the code, additional content is written to the XML file. Therefore, the information about the actual error is not normally contained at the end of the XML file. To try to identify the information about the error, search for Failed workflow in the file and copy that entire line. This information is very useful for you to analyze yourself or to submit to IBM Support. To help IBM Support understand the context of the error, also provide the lines of output preceding and following the error in the workflowlogexport.xml file. If you need to call IBM Support, collect all of the information described here to help the Support staff address your issue quickly.
241
2. Publish status
For an inventory scan with software signatures, verify that the software signature was published to the depot. 1. On the provisioning server, check console.log for the following message:
DEBUG [Cit_SDI_OnDevice(11200)] (FileManager.java:317) cds.FileManager: Published file C:/Program Files/IBM/tivoli/tpm/tmp/cit_subagent/4546-SoftwareSignatureForSOA-1270567409156 with taskId 77401 to CDS depots: depot.example.com
2. Verify in the dynamic content delivery console that the file is on the depot server. In a supported Web browser, type the following URL:
https://host_name:9045/admin
3. Log on with the Tivoli Provisioning Manager administrator user name and password that you specified during core components installation. The default user is maxadmin. 4. If more information is required for the depot, check the following log files on the provisioning server, .
Table 47. Log files Log file trace_cdsmgr.log Message and trace information for download plans as well as general message and trace information trace_cdssec.log Message and trace information for Web services authentication and authorization trace_distribution.log Message and trace information for the distribution agent Location
Windows
%TIO_LOGS%\ctgde\logs
Linux
UNIX Windows
$TIO_LOGS/ctgde/logs
Linux
UNIX Windows
Linux
UNIX
3. Job status
Verify the status of the discovery job. 1. On the provisioning server, check console.log for a message to indicate that the job was submitted:
INFO [Cit_SDI_OnDevice(11200)] (JobManagementServiceClient.java:534) client.JobManagementServiceClient: Submitted job to the job management server. Job id is: [127056745464054137] INFO [Cit_SDI_OnDevice(11200)] (ExecutionLogger.java:333) runtime.ExecutionLogger:
2. If more information is required for device manager, check the following log files on the provisioning server.
Table 48. Log files Log file TraceDMSnumber.log Location
Windows
Linux
UNIX
DMSMsgn.log
Windows
Linux
UNIX
In TraceDMSnumber.log, search for the string jdml. The default DMS polling interval is 60 minutes, so the timestamp in the log might be as much as 60 minutes after the job was submitted. The following example shows an exerpt from the log.
242
INSERT INTO JOB_PARM (PARM_VALUE, LAST_MODIFIED, PARM_KEY, JOB_ID) VALUES (http://www.ibm.com/xmlns/prod/tivoli/tpm/jdml/2.0" failurePolicy="stop-on-error" priority="1" name="CitScan" applicationData="Discovery"
The Job Description Markup Language (JDML) also helps you to link the ID for the task with the ID for the job. For example:
<jdml:Variable name="jobId" literal="true">6125</jdml:Variable> <jdml:Variable name="taskId" literal="true">77401</jdml:Variable>
4. Target status
Check the progress of the discovery job on the target computer for the discovery task. 1. On the target computer, verify that the discovery job was received for processing. Look in CA_HOME/logs/trace-log-number.xml CA_HOME The agent installation directory v v v
Windows HP UX AIX
C:\Program Files\tivoli\ep
Linux Solaris
/opt/tivoli/ep
/usr/tivoli/ep
number A number such as 1. The following message shows that the discovery job was received.
JES023I Processing job: name = [CitScan], requestId = [6e58be70988b11dfbef4000c291214c0]
If the job was not received, check the following items: a. Verify communication with the target computer. Run the TCA_PingAgent provisioning workflow. b. If the discovery task is taking a very long time to complete, one possible cause is that the target computer is not polling for jobs, so the job is never received. To fix this problem, see Jobs not reaching target computer 2. Verify that the discovery job ran in trace-log-number.log. For an Inventory discovery, the following line indicates that the results of the discovery were generated on the target computer.
CIT034I Combined CIT output file as an XML import format C:\Program Files x86)\tivoli\ep\conf\org.eclipse.osgi\bundles\167\data\cit_tpmlabw2k82010.08.04.11.26.20.xml
The following line indicates that the discovery results were uploaded to the provisioning server.
JES037I Done executing work item: Job [CitScan], Work Item [ScanFileUpload] ]
3. On the target computer, check the following log files for additional information.
Table 49. Log files Log file error-log-number.log For error messages generated during agent run time. Location v v v
Windows HP UX AIX
Linux Solaris
/opt/tivoli/ep
/usr/tivoli/ep
243
Table 49. Log files (continued) Log file traceCIT.log Location v

Windows
%ProgramFiles%\IBM\tivoli\common\ /usr/ibm/tivoli/common/CIT/logs
For Inventory discovery discovery only Note: You can also set a higher trace level modifying the v file: $CA_HOME/../../../cit/config/ CitTrace.propertiesThe default value for variable CA_HOME is: v v
Windows UNIX
CIT\logs
UNIX
%ProgramFiles%\Tivoli\ep\runtime\agent /usr/tivoli/ep/runtime/agent
5. Results
Verify that the discovery results were processed. On the provisioning server, check console.log for the following information: These lines show the selection of the discovery scan results, and then processing of the results.
DEBUG [Discovery engine worker 0] ( Queue.java:177) engine.Queue: Selected message 77403 DEBUG [Discovery engine worker 0] (DcmDeviceIntegrator.java:258) util.DcmDeviceIntegrator: Found 0 subnets associated with discovery technology 4546 DEBUG [Discovery engine worker 0] (DiscoveryWorker.java:81) engine.DiscoveryWorker: Processed message: id 77403
Related links Support information about discovery Log files for troubleshooting discovery Discovery problems and limitations on page 245
Log files for troubleshooting discovery

The following are common troubleshooting problems that you might encounter when running discovery. v For any discovery v For the Tivoli Provisioning Manager Inventory Discovery v For any Inventory Discovery if the Tivoli Common Agent is not installed on page 245
For any discovery

1. Check the log files and/or the workflow logs to determine the problem. On the Tivoli Provisioning Manager server: v
Windows
UNIX Linux $TIO_LOGS/console.log v v Workflow logs available from the web interface 2. If the Inventory Discovery is involved, perform the checks described for the Inventory Discovery. 3. Resolve the cause and then try again.
For the Tivoli Provisioning Manager Inventory Discovery

1. Check the log files and/or the workflow logs to determine the problem. 2. If Common Inventory Technology (CIT) is run under the Tivoli common agent (TCA), check also the TCA logs. On the Tivoli Provisioning Manager server:
244
Windows
UNIX Linux $TIO_LOGS/console.log v v Workflow logs available from the web interface On the target computer:
Windows
%ProgramFiles%\IBM\tivoli\common\CIT\logs\ traceCIT.log
UNIX Linux /usr/ibm/tivoli/common/CIT/logs/ traceCIT.log v For the TCA-based Inventory Discovery, on the target computer: v CA_HOME/logs/error-log-n.xml v CA_HOME/logs/trace-log-n.xml
and n = 0,1,2,... Note: You can also set a higher trace level modifying the following file:
$CA_HOME/../../../cit/ config/CitTrace.properties
where the default value for the CA_HOME variable is: v

Windows
%ProgramFiles%\Tivoli\ep\runtime\agent
UNIX Linux /usr/tivoli/ep/runtime/agent v 3. Resolve the cause and then try again.
For any Inventory Discovery if the Tivoli Common Agent is not installed
1. Check the log files and/or the workflow logs to determine the problem. On the Tivoli Provisioning Manager server: v TIO_LOGS\console.log v $TIO_HOME/tmp/cit_subagent/platform/target_id_timestamp Note: By default this directory is deleted. You should set a property to keep it. On the computer: v /tmp/cit_discoveryId 2. If the Inventory Discovery is involved, perform the checks described for the Inventory Discovery. 3. Resolve the cause and then try again.
Discovery problems and limitations

Lack of information from Initial Discovery

User credentials are needed to access full information about the discovered computers. Otherwise, very little information is provided.
Symptoms
When running Initial Discovery, very limited information about the discovered computers is returned if no user credentials are provided.
Causes
User credentials are needed to access full information about the discovered computers.

245
To retrieve detailed information about the discovered computers, it is recommended that you provide user credentials. If you do not provide them, only limited information about the computer (such as the host name and operating system) is returned, and the discovered computers are added into the Unknown Resources page.
Incorrect value for cpu.type in data model

The discovery populates a 32-bit value in the data model by default. If the target computer has a 64-bit processor, manually change the value of cpu.type to 64-bit.
Symptoms
After running a Rembo Hardware Discovery against a target computer, the value for cpu.type is not correctly inserted into the data model.
Causes
The discovery cannot always determine whether the target computer has a 32-bit or 64-bit processor. The discovery populates a 32-bit value in the data model by default, but with this value it is not possible to install a 64-bit operating system image on the target computer.

Manually change the cpu.type value from 32-bit to 64-bit.
Microsoft Active Directory discovery only displays short names

Microsoft Active Directory discovery only displays the short names of the discovered computers because it only detects the information which was defined in the Microsoft Active Directory registry.
Symptoms
Microsoft Active Directory discovery only displays the short names of the discovered computers, and not their fully qualified host names.
Causes
Microsoft Active Directory discovery only detects the information which was defined in the Microsoft Active Directory registry.

Set a fully qualified host name as the computer name on the target computer before running a Microsoft Active Directory discovery.
No hardware report information from Microsoft Active Directory discovery

A Microsoft Active Directory discovery only detects the information which was defined in the Microsoft Active Directory registry.
Symptoms
No hardware information is returned after running a Microsoft Active Directory discovery against a computer.
Causes
A Microsoft Active Directory discovery only detects the information which was defined in the Microsoft Active Directory registry.
246

Go to the Variable tab of the discovered computer to display more attributes found by the Microsoft Active Directory discovery.
Inventory scan fails if Tivoli Common Agent is not installed

The inventory scan fails because the service access point is not defined for this computer.
Symptoms
An inventory scan on a computer discovered by Microsoft Active Directory discovery fails if the computer does not have Tivoli Common Agent installed.
Causes
The operation fails because the service access point is not defined for this computer.

Perform a network discovery on that computer to define the RXA Service Access Point, or install Tivoli Common Agent on the target computer.
Discovery of Linux on zSeries is overwriting the record for another Linux on the same host platform in the data model
For Linux on zSeries, all the virtual computers on the same host platform share the same MAC address. The discovery uses the MAC address to identify the discovered computers. If two or more computers share the same MAC address, they are considered as one computer. You can update the MAC for the layer 2 mode device so that the Linux virtual machine is assigned a unique MAC address. The virtual machine MAC address must be unique within the same host platform.
Symptoms
The discovery of a first machine is completed successfully. The discovery of a second machine on the same host platform is completed with a message stating that the machine exists in the data model. All data from the previous discovery is overwritten by the second one.
Causes
The operation fails because the virtual computers on the same host platform have the same MAC address.

To change the MAC address on SuSE on zSeries systems, perform the following steps: 1. Create a hardware device configuration file in /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.#: 2. Set the value for parameter QETH_LAYER2_SUPPORT to 1. 3. Set the value for parameter QETH_OPTIONS to 1. The following example shows a hardware device configuration file:
STARTMODE="auto" MODULE="qeth" MODULE_OPTIONS="" MODULE_UNLOAD="yes" SCRIPTUP="hwup-ccw" SCRIPTUP_ccw="hwup-ccw" SCRIPTUP_ccwgroup="hwup-qeth" SCRIPTDOWN="hwdown-ccw" CCW_CHAN_IDS="0.0.7868 0.0.7869 0.0.786a"
247
CCW_CHAN_NUM="3" CCW_CHAN_MODE="GBEOSA" QETH_LAYER2_SUPPORT="1" QETH_OPTIONS="fake_ll=1"
4. Create an interface configuration file in /ect/sysconfig/network/ifcfg-qeth-bus-ccw-0.0.#: 5. Set the value for parameter LLADDR to the MAC address you want, for example 00:01:02:03:04:05. The following example shows an interface device configuration file:
BOOTPROTO="static" UNIQUE="" STARTMODE="onboot" IPADDR="9.26.177.36" NETMASK="255.255.255.0" NETWORK="9.26.177.0" BROADCAST="9.26.177.255" _nm_name=qeth-bus-ccw-0.0.7858 LLADDR="00:01:02:03:04:05"
6. Test the configuration files:

#> hwup qeth-bus-ccw-0.0.#
The following result is displayed:

hwup: module qeth already present in kernel
7. Restart the system. 8. Use the following commands to change the MAC address to the value you want. a. Stop the network interface:
ifconfig eth0 down
b. Run the command for changing the MAC address:

ifconfig eth0 hw ether 00:01:02:03:04:05
c. Start the network interface:

ifconfig eth0 up
To change the MAC address on Red Hat on zSeries Systems, perform the following steps: 1. Create the configuration file in /etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE=eth0 BOOTPROTO=static IPADDR=9.26.177.39 NETMASK=255.255.255.0 NETTYPE=qeth ONBOOT=yes PORTNAME=GBEOSA SUBCHANNELS=0.0.7874,0.0.7875,0.0.7876 MACADDR=00:01:02:03:DC:08 OPTIONS="layer2=1"
2. Add or verify the alias in /etc/modprobe.conf:

alias eth0 qeth
3. Restart the system. 4. Use the following commands to change the system MAC address to the value you want. a. Stop the network interface:
ifconfig eth0 down
b. Run the command for changing the MAC address:

ifconfig eth0 hw ether 00:01:02:03:04:05
c. Start the network interface:

ifconfig eth0 up
248
Common agent cannot be installed using Microsoft Active Directory

Before trying to install the Tivoli Common Agent, perform a network discovery on the target computer.
Symptoms
Tivoli Common Agent cannot be installed on a computer using Microsoft Active Directory.
Causes
This operation fails because the service access point is not defined for the target computer.

Before trying to install the Tivoli Common Agent, perform a network discovery on the target computer to define the service access point.
Cannot run Microsoft Updates discovery on UNIX

A workaround is available if a Microsoft Updates discovery fails.
Symptoms
When running a Microsoft Updates discovery on UNIX target computers using Tivoli Provisioning Manager, the operation fails.

As a workaround, perform these steps for UNIX target computers, except AIX-based computers: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Variables tab. 3. Create a variable using cabextractcommand as its key. 4. Set the value for this key to:
cabextract _CAB_FILE_NAME_ -d _WORKING_DIRECTORY_
5. Install the cabextract utility on the UNIX target computers you want to discover using the Microsoft Updates discovery: a. Download cabextract-1.2.tar.gz from the http://www.cabextract.org.uk/ Web site. b. Perform the following actions to install the cabextract utility: 1) Navigate to the directory where you downloaded the rpm cabextract utility. 2) Run the following command to install the cabextract rpm package:
rpm -ivh RPM_NAME
Perform these steps for AIX-based computers: 1. Download the following packages: v #rpm -ivh gcc-4.2.0-3.aix5.3.ppc.rpm v #rpm -ivh libgcc-4.2.0-3.aix5.3.ppc.rpm v #rpm -ivh libstdcplusplus-4.2.0-3.aix5.3.ppc.rpm v #rpm -ivh libstdcplusplus-devel-4.2.0-3.aix5.3.ppc.rpm v #rpm -ivh gcc-cplusplus-4.2.0-3.aix5.3.ppc.rpm v #/usr/sbin/updtvpkg 2. Click Go To > Administration > Provisioning > Provisioning Global Settings. 3. Click the Variables tab. 4. Create a variable using cabextractcommand as its key.
249
5. Set the value for this key to:

cabextract _CAB_FILE_NAME_ -q -d _WORKING_DIRECTORY_
6. Install the cabextract utility on the AIX target computers you want to discover using the Microsoft Updates discovery: a. Download cabextract-1.2.tar.gz from the http://www.cabextract.org.uk/ Web site. b. Run the following commands to install the cabextract utility: v $ gzip -cd < cabextract-1.2.tar.gz | tar xf v $ cd cabextract-1.2 v $ ./configure v $ make v $ make install
Wrong locale discovered on Linux computers

The computer locale is not discovered correctly because the computer locale variables are not set.
Symptoms
The inventory discovery does not detect the correct locale of Linux computers if Tivoli Common Agent is not installed on them.
Causes
The computer locale is not discovered correctly because the computer locale variables in the etc/environment file are not set.

Ensure that you have set the appropriate LC_* and LANG variables according to your computer locale in Linux ~/.ssh/environment file depending on your computer the Windows /etc/environment or configuration.
Deadlock problems during a discovery

Deadlock problems might arise during a discovery if some variables are not configured correctly.
Symptoms
When running a discovery, some deadlock issues arise.
Causes
The problem might be caused by the following variables:
Table 50. Deadlock issues Global variable AM.Discovery.Thread.Count Description The variable specifies how many threads to use when processing discovery data that is returned from the agent manager during an agent manager discovery run. Default value If no value is specified, then the default value is used, which is 8. The best value to use for this variable is 4.
250
Table 50. Deadlock issues (continued) Global variable DiscoveryConcurrencyLevel Description The variable handles the processing of discovery objects in the data model. Default value If no value is specified, then the default value is used, which is 2. The best value to use for this variable is 4. Note: It is not recommended to set a value bigger than 4.

As a workaround for deadlock situations during a discovery run, the values of the AM.Discovery.Thread.Count and DiscoveryConcurrencyLevel variables can be set to 4 as follows: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click Variables. 3. Click Edit > Add Variable. 4. Name the variable in the Key field, with a component of Deployment engine, and specify a value (4) for the variable in the Value field. 5. Click Save. 6. Issue the tio.sh stop -t command. 7. Issue the tio.sh start -t command.
Dual computer information after agent installation on provisioning computers

If the host names specified for the target computer in the DNS and on the operating system do not match, then the network discovery creates two separate data model records for the same target computer.
Symptoms
After discovering a computer with network discovery and then installing the common agent on it, another data model record is created for that computer but it displays a different computer name.
Causes
If the host names specified for the target computer in the DNS and on the operating system do not match, then the network discovery creates two separate data model records are created for the same target computer.

Ensure that the computer host name configured for DNS and the host name configured in the operating system are the same.
Windows Vista computers cannot be discovered by the network discovery using their IPv6 addresses
A workaround is available if Windows Vista computers cannot be discovered.
Symptoms
Windows Vista target computers cannot be discovered using the discovery wizard provided to perform a network RXA-based discovery.

251
As a workaround for this discovery issue, set up theWindows Vista target computers of your environment as follows: 1. If you are a member of a local administrators group and you use a local user account, complete the following three steps to be able to perform administrative tasks on the target computers: a. Enable the built-in Administrator account and use it to connect. To enable the built-in Administrator account, open the Windows Control Panel and click Administrative Tools > Local Security Policy > Security Settings > Local Policies > Security Options . Then double-click Accounts: Administrator account status and select Enabled. b. Disable the user account control if a different administrator user account is to be used to connect to the Windows Vista computer. To disable the user account control, open the Windows Control Panel and click Administrative Tools > Local Security Policy > Security Settings > Local Policies > Security Options . Then double-click User Account Control: Run all administrators in Admin Approval Mode and select Disabled. Changing this setting requires a reboot of the computer. c. Disable the user account control if you administer a workstation with a local user account (Security Account Manager user account). Otherwise, you will not connect as a full administrator and will not be able to perform administrative tasks. To disable the user account control perform the following steps: 1) Click Start > Run. 2) Type regedit, and press Enter. 3) Locate and click the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 4) Right-click LocalAccountTokenFilterPolicy, and click Modify. If the LocalAccountTokenFilterPolicy registry entry does not exist, follow these steps: a) From the Edit menu, click New, and then click DWORD Value. b) Type LocalAccountTokenFilterPolicy, and then press Enter. 5) In Value enter 1 , and click OK. 6) Restart the computer. 2. The target computers must have the Remote Registry service started, which represents the default configuration, in order for Remote Execution and Access (RXA) to connect to the target computer. Verify the service status clicking Administrative Tools > Services and start the Remote Registry service if needed.
Windows 2003 and Windows XP 64-bit computers cannot be discovered using their IPv6 addresses
Windows 2003 and Windows XP 64-bit computers are not discovered if the discovery configuration specifies their IPv6 addresses.
Symptoms
After running the network RXA-based discovery, the discovery might fail and the workflow log might display an error message similar to the following:
CTGRI0001E The application could not establish a connection to 2002:091A:0519:11F5:020D:60FF:FED4:F416.
Causes
If the IPv6 addresses of the computers have been used in the discovery configuration, the Windows 2003 Server Enterprise SP2 and Windows XP 64-bit target computers cannot be reached when doing a network RXA-based discovery.
252
As a workaround for this discovery issue, complete the following steps for each Windows 2003 Server Enterprise SP2 and Windows XP 64-bit target computer in your environment. 1. (Optional) Create the CNAME record for the file server on the appropriate DNS server, if the CNAME record does not exist. 2. Apply the following registry change to the file server: a. Start the Registry Editor (Regedt32.exe). b. Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Smb\Parameters
c. On the Edit menu, click Add Value, and then add the following registry value: DWORD key IPv6Protection Add with hex value 00000014 (0x00000014). DWORD key IPv6EnableOutboundGlobal Add with hex value 1 (0x1). d. Locate and click the following key in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
e. On the Edit menu, click Add Value, and then add the following registry value:
Value name: DisableStrictNameChecking Data type: REG_DWORD Radix: Decimal Value: 1
f. Quit the Registry Editor. 3. Restart your Windows target computer. After completing these steps on the target computers, run the network RXA-based discovery again.
Cannot discover Windows XP 32-bit computers with IPv6 only enabled

IPv6 addresses on Windows XP 32-bit computers cannot be discovered using RXA-based network discovery.
Symptoms
After running the RXA-based network discovery against a Windows XP 32-bit computer with only the IPv6 protocol enabled, the computer cannot be discovered.
Causes
The RXA-based discovery uses the Microsoft SMB protocol to communicate with a managed computer. On Windows XP 32-bit computers, SMB only supports IPv4 communication and IPv6 addresses are not supported. This is a known Microsoft limitation.

v If you need to use the Windows XP 32-bit operating system on the computer, you must communicate with the computer using IPv4. Ensure that an IPv4 address is configured on the computer. v If you want to use an IPv6 address to communicate with the computer, use a Windows operating system version with SMB protocol support for IPv6 addresses. Versions with support include Windows XP 64-bit, Windows 2003, Windows Vista and Windows 2008.
Wrong version displayed for Web logic 10.X computer discovered from TADDM
Symptoms
When discovering from TADDM a computer with Web logic version 10.0 installed, on the Software tab of the discovered computer the Web logic version displayed is 10.3, even if the actual version is 10.0.
253

TADDM discovers the correct version, even if the wrong version is displayed by the Tivoli Provisioning Manager Web interface.
Deployment engine exception when running discovery

Symptoms
When running a workflow or performing a discovery, the following exception might be displayed:
COPDEX040E An unexpected deployment engine exception occurred: psdi.util.MXApplicationException: BMXAA4017E - Object TPSERVER Id= server_id is not qualified according to the data restriction of this user.
Causes
This error is due to the discovered computer which might be created. During the creation of the computer, a security check is performed to verify if the user has access to the new computer. If the user has no access, the exception is thrown.

There are two different solutions to workaround this issue: v The first solution consists of performing the following steps: Identify a provisioning group containing the objects to which you have write access. This information can be found on the Provisioning Permissions tab of the Security Groups application. When you define the discovery configuration, select this provisioning group as a value for the Add Computers to Group option. Run the discovery logged on as the user with the write access. v The second solution consists of performing the following steps: Create a dynamic group using a query to identify the computer to be created. For example, if the new computer to be discovered has the host name winServer.tpmserver.example.com, you can create a query based on the domain name tpmserver.example.com, so that you have access to all computers with that specific domain name. For details about how to create a dynamic group, see Creating groups on page 39. Add the dynamic group that you created to the security group of the user with write permissions using the Provisioning Permissions tab of the Security Groups application. For details about how to assign write permissions to a security group, see Lesson 1: Assigning read/write type of permissions to security groups on page 83. After it is added, the user will have write access to the computer to be created. Run the discovery logged on as the user with the write access.
Note: Error message BMXAA4017E can also occur in the following situation, which is not related to the cause described above: 1. You create a static provisioning group and enable the data model object finder security for a security group. 2. You log out as the MAXADMIN user and log in as a user from the particular security group. 3. You Click Go To > Deployment > Provisioning Computers. 4. You click the New button to create a new computer. 5. You enter a name for the computer and click Save. The error message is displayed. It is displayed for any user who has read/write data model object finder security enabled for a static group of computers. Contact your administrator if you receive the error message in this circumstance.
254
The network discovery fails

The network discovery fails because networking information is missing or not configured for an AIX WPAR.
Symptoms
Running a network discovery fails with errors indicating that there are problems with the networking configuration on an AIX WPAR target computer.
Causes
An AIX WPAR virtual server might be missing networking information, or the networking information is not configured correctly.

Fix the networking configuration of the AIX WPAR and then run the network discovery again.
COPCOM618E error for Windows computers configured with Federal Desktop Core Configuration
If the target computers that you manage have Microsoft Windows XP or Microsoft Windows Vista installed and are configured with Federal Desktop Core Configuration (FDCC), these computer cannot communicate with the provisioning server.
Symptoms
The following message might be displayed in Status of my recent provisioning workflows in the Start Center:
COPCOM618E The network discovery could not find any of the specified resources.

Microsoft Windows XP: 1. Run the following command:
gpedit.msc
2. Expand Local Computer Policy > Computer Configuration > Administrative Templates > Network Connections > Windows Firewall > Standard Profile. 3. Ensure that Windows Firewall: Do not allow exceptions is Not Configured. 4. Ensure that Windows Firewall: Allow file and printer sharing exception and Windows Firewall: Allow local port exceptions are Enabled. 5. Expand Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. 6. Ensure that Network security: LAN Manager authentication level is set to Send NTLMv2 response only. 7. Open Windows Firewall in the Control Panel. 8. Add the following port numbers. ClickExceptions > Add port.
9045 9046 9510 9511 9512 9513 9514 9515
255
Microsoft Windows Vista: 1. Run the following command:

gpedit.msc
2. Expand Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. 3. Ensure that Network security: LAN Manager authentication level is set to Send NTLMv2 response only. 4. Ensure that User Account Control Admin Approval Mode for the Build-in Administrator account is set to Disabled. 5. Expand Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall with Advanced Security - Local Group Policy Object > Inbound Rules. 6. Create a new inbound File and Print Sharing rule, which will allow SMB inbound traffic. 7. Create a new inbound Protocol and Ports rule for following TCP ports:
9045 9046 9510 9511 9512 9513 9514 9515
TADDM discovery failure

Symptoms
When running the TADDM discovery, the operation fails with the following error:
COPDEX040E An unexpected deployment engine exception occurred: class com.ibm.tivoli.tpm.discovery.taddm.exception.TaddmDiscoveryException: COPTDM214E Cannot connect to the TADDM server server_name because the client and server do not match in the Java RMI.
Causes
The TADDM server is on a version different from the version enabled by default in Tivoli Provisioning Manager. By default, Tivoli Provisioning Manager 7.2 supports TADDM version 7.2.

As a workaround for this discovery issue, perform the following steps to enable TADDM version 7.1.2.6. Select the option Run as administrator for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide.
Windows 2008
1. Log on to Tivoli Provisioning Manager as tioadmin. 2. Stop the Tivoli Provisioning Manager deployment engine by running the following commands: UNIX $TIO_HOME/tio.sh stop tpm Windows %TIO_HOME%\tio.cmd stop tpm 3. Move to the TIO_HOME/lwi/runtime/tpm/eclipse/plugins/TADDMDiscovery directory. 4. Create a directory named lib_7.2. 5. Back up the following files by copying them from the lib directory to the lib_7.2 directory: v platform-model.jar
256
v taddm-api-client.jar 6. Copy the following files from the lib_7.1.2.x directory to the lib directory: v platform-model.jar v taddm-api-client.jar Choose to overwrite the existing files. 7. Start the Tivoli Provisioning Manager deployment engine by running the following commands: UNIX $TIO_HOME/tools/tio.sh start tpm Windows %TIO_HOME%\tools\tio.cmd start tpm Note: To switch back to TADDM version 7.2, the files backed up in the lib_7.2 folder can be copied to the lib folder again.
IP address and host name are not displayed on the Web interface
IP address and host name are not updated on the Web interface after changing the IP address or the host name of a target computer.
Symptoms
When you change the IP address or the host name of a target computer, the new information is not reflected on the Web interface.

As a workaround for this issue, perform the following actions: v If you changed the IP address of a target computer, restart the Tivoli Common Agent on this computer. v If you changed the host name of a target computer, run a Provisioning Inventory discovery on this computer.
257
258
Chapter 4. Deploying operating systems

Operating system deployment provides the ability to discover, manage, and deploy images. You can also automate software installations and configure remote computers. Setting up and deploying images manually is time-consuming and error-prone. Many organizations manage deployments to hundreds of computers on different operating systems across multiple sites, and need a consistent method with which to manage these deployments. Instead of trying to manage deployments using different processes or tools, you can centralize deployment with a single tool and easily set up and deploy images in a consistent way. Flexible options are available for managing and installing operating system software. You can manage common requests related to a workstation life cycle without an on-site visit, thus reducing the total cost of ownership of each managed system. Using image management, target computers or workstations connect to the boot server during the boot phase and begin the installation of the operating system across the network. The operating system is installed using images created from the boot server. An image is a representation of a computer program and its related data such as the kernel, file systems, libraries, and programs of the managed system at a given time. Common operating systems deployment tasks include: v Creating an image from operating system media. v Capturing an image from a source system. v Deploying an image to one or more target systems.
When to use operating system management

Technologies for operating system management are designed to facilitate management of standard images for new installations of operating systems or standard installations of operating systems and software in a new state. The following examples describe some situations where you might use operating system management: Computer additions When you add a new computer to your enterprise, you can install a standard image on that computer. Computer management and restoration You can use image management to improve processes for deploying images on large groups of computers or when new components need to be deployed to many computers. If a set of computers is affected by a hardware component repair or a virus, the initial state can be restored by copying an existing image onto the affected computers. Patch management Patch management is an integral part of protecting customer services, corporate and customer data, and day-to-day operations. However, keeping computers up-to-date and compliant with corporate security requirements is complex and time-consuming. The challenges outlined later in this section, however, can be effectively managed by capturing an image from a computer that has the patch installed and copying it onto the target machines automatically: v Frequent updates are released by the vendors. v Tracking and evaluating security risks and the appropriate software updates is time-consuming and requires in-depth knowledge of installed software, hardware and software dependencies, and corporate requirements. v Deployment of patches is required to reduce downtime or service interruptions.
259
v Effective auditing and reporting is required to monitor deployment, verify compliance, and troubleshoot errors. v Operating system images must be kept up-to-date.
Operating system management with Tivoli Provisioning Manager for OS Deployment

The primary technology for operating system management is Tivoli Provisioning Manager for OS Deployment. Tivoli Provisioning Manager for OS Deployment provides powerful operating system management capabilities and supports a wide range of targets. It also provides additional capabilities that are not supported for deployment with other technologies, including: v Ability to set up child OS deployment servers that automatically synchronize with the parent deployment server to distribute workload and manage deployments in multiple VLANs. v Ability to create device drivers and other software as software modules. You can then create binding rules for those software modules to have them deployed in certain scenarios. For example: A user creates a device driver (which is a software module) for a network adapter on Windows 2003. When they are creating the software module, they can assign certain binding rules by default. For example, the software module can automatically be bound if the specific PCI card for that network adapter is found on the target system being deployed. On the same device driver as listed previously, the user might want a different set up, for example, they might have a software module they always want installed with all their Windows installation. In this case, they can create a binding rule for that software module, so that every time they do a deployment of a Windows image, it deploys the specific software module. The Tivoli Provisioning Manager for OS Deployment parent server must be installed during Tivoli Provisioning Manager installation; otherwise you must rerun the Tivoli Provisioning Manager installer to install it. After you have a parent server installed, you can install child servers: Creating child OS deployment servers on page 284 Automation packages for other technologies are included with Tivoli Provisioning Manager, but you must ensure that the appropriate automation package is installed and you must configure the boot server information manually before using them. Important: Tivoli Provisioning Manager for OS Deployment does not run any backup software. Backup software is designed to store a copy of data at a specific point in time so that it can be recovered if the original data source is lost or damaged. A backup can contain data that is very specific to the configuration of the source computer and at a time when the computer is not in a clean state. Use of operating system management software to perform backup and restore operations is not recommended, particularly if you are capturing a computer where complex applications are installed. Depending on the application and the configuration of the computer at the time of capture, these applications might not work correctly when you deploy the captured backup to the same computer.
Tivoli Provisioning Manager for OS Deployment and Federal Information Processing Standard (FIPS) 140-2
Integration with Tivoli Provisioning Manager for OS Deployment is not supported when FIPS compliance is enabled in Tivoli Provisioning Manager. Tivoli Provisioning Manager for OS Deployment is not compliant with FIPS 140-2. The Tivoli Provisioning Manager for OS Deployment interface is not accessible when FIPS compliance is enabled.
260
Operating system management basics

Find out more about operating system management, the processes for creating, managing, and installing images for managed computers. Review the troubleshooting information and the log files names and location for this feature and also additional resources that help you with your operating system management. Find out more about what operating system management is about, who the primary users are, and what are the key examples and terms that you need to know about this feature. v Process on page 262 v v v v v v User roles on page 263 Requirements on page 263 Key terms on page 264 Troubleshooting on page 264 Log files on page 264 Resources on page 264
261
Process
Set up infrastructure Create the image Configure image properties
Install the image
No
Install other software?
Yes
Define software modules
Bind software modules to an image or a target
Legend
Provisioning Administrator Provisioning Configuration Librarian Deployment Specialist
Operating systems management includes the processes that are detailed later in this section. Roles for each step in the process are noted in brackets. 1. Set up the infrastructure (Provisioning Administrator) v A boot server manages your images and their deployment. The parent boot server is typically installed during Tivoli Provisioning Manager installation. v After the parent boot server is installed, you can select to install additional child servers to distribute the workload. v Ensure that target computers meet requirements for image deployment. 2. Create the image (Deployment Specialist) You can define an unattended setup image with the installation files for the operating system, or you can capture an image of the operating system on a reference computer. 3. Configure image properties (Provisioning Configuration Librarian) These properties are configuration settings that you want to apply to all deployments of the image. For example, you can configure the operating system to use a dynamic IP address or define a site license key for a Windows image deployment. 4. Create software modules that you want to install with the image (Provisioning Configuration Librarian). A software module is software such as an application or a device driver. 5. Bind, or associate, the appropriate software modules with an image or a specific target computer (Provisioning Administrator) 6. Deploy the created image (Deployment Specialist).
262
User roles
You must be assigned to the appropriate user role to perform image management operations.
Table 51. User roles Role Deployment Specialist Description v Deploys images Skills v Server management experience v Familiarity with OS management life cycle Provisioning Configuration Librarian v Manages overall product configuration. v Responsible for setting up the environment to support boot server technologies. Provisioning Administrator v Knowledge of provisioning server configuration and boot server technologies.
v Performs higher level management v Knowledge of boot server of the environment such as technologies. installing or deleting boot servers. v The individual who uses a target computer, typically a notebook, desktop or server. v Basic knowledge of the operating system on the target computer.
End User
Requirements
User roles and requirements on page 279 Target computer requirements: Requirements for Windows target computers on page 556 Requirements for Red Hat Linux target computers on page 560 Requirements for SUSE Linux Enterprise Server (SLES) target computers on page 561 Requirements for AIX target computers on page 562 Requirements for Solaris Operating Environment target computers on page 563 Requirements for HP-UX target computers on page 565 v Hardware requirements on page 281 v Operating system requirements on page 282 v File system requirements on page 283 Server system requirements on page 280
263
Key terms
bare metal computer A computer on which there is nothing reliable but the hardware. It can be coming straight from factory without any data on its hard disk (out of the box) or it can contain a possibly damaged operating system. boot server A system that is required to start other servers. Boot servers are defined to provision workstations or other systems without any installed software. Compare with terminal server. image A representation of a computer program and its related data such as the kernel, file systems, libraries, and programs of the managed system at a given point in time.
target computer The system that is the final destination of a management operation.
Troubleshooting
v os/tcom_troubleshooting.dita v Log files v COPOSD messages v Support information about OS deployment v Contacting Support
Log files
Review the log files in the following topics to recover from problems that you might encounter when deploying operating systems: v Tivoli Provisioning Manager for OS Deployment server log files v Copying log files to the software repository v Recovering from Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images problems
Resources
To learn more about managing operating systems, refer to one of the following resources: v Tutorial: Managing operating systems on page 301 v Chapter 4, Deploying operating systems, on page 259 v Setting up additional child OS deployment servers on page 283 v Security problems with TPM for OS Deployment
Related links Chapter 4, Deploying operating systems, on page 259 Requirements on page 279 os/tcom_troubleshooting.dita Tutorial: Managing operating systems on page 301
Tivoli Provisioning Manager for OS Deployment overview

Tivoli Provisioning Manager for OS Deployment is a database-driven, PXE-based deployment solution.
264
You can use Tivoli Provisioning Manager for OS Deployment to perform the following tasks using source servers: v Windows cloning (capturing a golden master image) and unattended setup v AIX unattended setup v Linux cloning (not supported on Linux PPC), and unattended setup v Solaris unattended setup v VMWare ESX unattended setup Using industry standards such as Wake-On-LAN, PXE, ODBC/JDBC, DMI and PCI detection, Microsoft system preparation tool (Sysprep), Kickstart, and Autoyast, Tivoli Provisioning Manager for OS Deployment offers easy to use installation of operating systems and selected software on tens, or even hundreds, of computers simultaneously. The deployment source can be on the network, on a CD-ROM or DVD-ROM, or on a disk partition.
Upgrade to Tivoli Provisioning Manager for Images

New with Tivoli Provisioning Manager version 7.2, you can opt to upgrade your Tivoli Provisioning Manager for OS Deployment to Tivoli Provisioning Manager for Images, to gain access to an important set of virtualization features that are not available in Tivoli Provisioning Manager for OS Deployment. Tivoli Provisioning Manager for Images provides: v Easy management and maintenance of virtual images and physical server images, including content customization and ability to modify images offline. v More efficient management of image distribution, discovery, capture, replication, storage, and deployment. v Hardware-independent snapshots of server images, to improve agility, flexibility, and recovery of servers. v Server consolidation through image conversions, and quick deployment to various environments. v Management of multiple hypervisor environments by converting images to various formats. v Simplified storage of thousands of images. For more information, see Chapter 5, Managing virtual images, on page 387.
Components for managing virtual images

The product consists of server-side components, console-side components, and target-side applications. Server-side components The following server-side components are installed using a typical setup program. The OS deployment server This component, which runs in the background as a service, provides the PXE remote-boot capability and multicast file access to the remote-boot targets. A deployment database The deployment database is accessed through the standard ODBC/JDBC interface, and through the TCP-to-ODBC/JDBC Gateway service. This database stores Bill of Material (BOM) files for every target, including information about what software modules must be installed. Console-side components The web interface This is a Web-based application that is used to prepare and supervise deployments. Using the web interface, you can configure the OS deployment server, manage objects used during a deployment, and create recovery CDs and DVDs. You can also visualize targets
265
into their different groups. The parameters and status of each target can be controlled (for example, when a target requests a remote-boot through PXE). Target-side applications The following target-side applications are installed automatically by the target through the network. The deployment engine The deployment engine is a stand-alone mini-operating system used for all the management tasks that are performed outside of the real operating system, such as the operating system installation. The deployment engine must not be installed manually on target systems, because it is downloaded automatically when the target systems are instructed to boot on the OS deployment server in their DHCP configuration. After the deployment engine is started, it loads a ramdisk that can perform various operations on the targets, such as: v Disk partitions and formatting v Installation of complete operating systems such as Windows or UNIX v Disk wipes The web interface extension The web interface extension is a small program that can run on most operating systems (Windows, AIX, Linux, Solaris), either in the background as a service or as a command-line tool. It provides cross-operating system connectivity to the management platform for targets with an installed operating system. It can be used to collect information from targets, to remotely initiate tasks on a target from the OS deployment server, or to trigger commands on the OS deployment server from a target. The web interface extension can access all files on the hard disk and other drives through the operating system. When running under Microsoft Windows, it can also access the system registry, and all system information published by drivers using the Windows Management Interface (WMI). Also, for all Intel-based operating systems, the web interface extension can install a hook on the boot process to initiate a PXE boot or to start the deployment engine in offline mode, to trigger pre-operating system management tasks such as migration or recovery. The deployment engine and the web interface extension are stand-alone management platforms and do not require an operating system. The web interface side application, typically installed on the server, is the web interface extension, running in background as a service. Optionally, a web interface extension can be installed on targets, so that you can take control of them remotely. The web interface extension is useful, for example, to restart the computer when a deployment starts, or to perform an operating system inventory. Several features of the web interface are not available when the web interface extension is not installed on the server. The web interface extension is a piece of software designed to run as an operating system application (a Windows application or a UNIX application). When you install the product, you install the OS deployment server. The target side is embedded into the server, and sent to computers through a network connection such as a network boot or PXE boot, or through media such as a CD-ROM, a diskette, or a hard disk partition. Note: It is also possible to boot targets over the network without using PXE. See Booting targets without using PXE on page 274 for more information.
266
Figure 2. Tivoli Provisioning Manager for OS Deployment components
1. A CD-ROM that contains both the deployment engine and the web interface extension can be created. 2. Computers boot, loading the deployment engine either from the PXE server (OS deployment server) or from the CD-ROM.
267
3. The deployment engine loads a ramdisk, embedded Linux for Linux targets or WinPE2 for Windows targets. 4. The ramdisk can perform various tasks, including the operating system installation. 5. The targets boot into the operating system (Windows, Linux, Solaris), with the web interface extension optionally running.
Operating system management process

Operating system management includes several main steps.
Set up infrastructure
Create the image
Configure image properties
Install the image
No
Install other software?
Yes
Define software modules
Bind software modules to an image or a target
Legend
Provisioning Administrator Provisioning Configuration Librarian Deployment Specialist
Operating systems management includes the processes that are detailed later in this section. Roles for each step in the process are noted in brackets. 1. Set up the infrastructure (Provisioning Administrator) v A boot server manages your images and their deployment. The parent boot server is typically installed during Tivoli Provisioning Manager installation. v After the parent boot server is installed, you can select to install additional child servers to distribute the workload. v Ensure that target computers meet requirements for image deployment. 2. Create the image (Deployment Specialist) You can define an unattended setup image with the installation files for the operating system, or you can capture an image of the operating system on a reference computer. 3. Configure image properties (Provisioning Configuration Librarian) These properties are configuration settings that you want to apply to all deployments of the image. For example, you can configure the operating system to use a dynamic IP address or define a site license key for a Windows image deployment.
268
4. Create software modules that you want to install with the image (Provisioning Configuration Librarian). A software module is software such as an application or a device driver. 5. Bind, or associate, the appropriate software modules with an image or a specific target computer (Provisioning Administrator) 6. Deploy the created image (Deployment Specialist).
Image deployment process

When you deploy an image, the deployment is made up of several steps that are automatically run in sequence without user interaction: 1. Invoke the Image Deployment application. Click Go To > Deployment > OS Management > Image Deployment. 2. Select the target machine and image you want to install. The image deployment workflow will be run. If Tivoli Provisioning Manager can manage the target computer (it has credentials and can execute commands) and the target computer is running, then Tivoli Provisioning Manager will restart the target computer. Since the target computer must be set to boot from the network first (see Network boot on page 273), it will then PXE boot off the Tivoli Provisioning Manager for OS Deployment deployment server. If Tivoli Provisioning Manager cannot manage the target computer, then you must restart the computer yourself. 3. The target determines that it is starting a new deployment and queries the provisioning server for the relevant deployment OS configuration. 4. The target performs hardware discovery through DMI and PCI system calls. 5. The target queries the ODBC/JDBC database for all relevant information regarding the operating system and the software modules to be installed, and dynamically generates a deployment script. 6. If specific hardware configuration software needs to be run early (such as RAID controller configuration), you will have to deploy the hardware configuration image with an image deployment. If you want to install a hardware configuration and then an OS image afterwards, you can create a software stack containing entries for the hardware configuration stack and the OS image (for example, a golden master or unattended setup) stack. After a subsequent reboot, the target resumes the process. 7. The target partitions its hard disk according to the information retrieved from the database. A small bootstrap is also written to the hard disk, so as to be able to take over any subsequent reboot on the hard disk. 8. The target initiates a batch multicast transfer for all files needed during the deployment. The files are downloaded in the order which optimizes the efficiency of the multicast download and stored in a temporary storage location on the hard-disk. 9. When everything is done, the deployment process terminates by starting up the target computer into the operating system. Tivoli Provisioning Manager will also attempt to connect to the machine after the deployment and run an inventory scan.
Hardware and operating systems images - overview

You can configure a target with a fresh installation of the operating system and then capture a golden master image of the computer. You can also capture a point-in-time snapshot (on Windows only). Other kinds of images you can create are hardware configuration images or unattended setup images. Golden master image A golden master image is a depersonalized boot device image that can be used for deployment on multiple computers. You have more options available for configuration when a machine is deployed using a golden master, such as modifying disk settings and users. Point-in-time snapshot image A Point-in-time snapshot is the partition layout and list of files to deploy an operating system, created by cloning without using Sysprep. With a snapshot, an OS restore is performed, but there is less customization available than there is with a golden master image.
269
Hardware configuration image Hardware configurations are performed at deployment time through a vendor-dependent environment which is loaded onto the target before operating system installation. Unattended setup image You can use unattended setup to create a deployment system without actively being involved in the process. Note: You cannot capture any kind of image if your target machine (that is, the machine you are capturing from) has Tivoli Common Agent installed. For Tivoli Provisioning Manager for Images, a new image type called TPM for Images Virtual Image has been specifically added for virtual image management support. Tivoli Provisioning Manager (TPM) for Images Virtual Image A virtual representation of a computer program and its related data such as the kernel, file systems, libraries, and programs of the managed system at a particular time.
Operating system images requirements

An image is a representation of a computer program and its related data such as the kernel, file systems, libraries, and programs of the computer at a given point in time. You can perform the following tasks with operating systems images: v Deploy an image to one or more target computers v Restore a snapshot image to recover a target computer There are several ways to create an image: v Capture the image from a computer in your enterprise. v Create an unattended setup image (from a CD). v Create an unattended setup image from a file. Boot servers deploy images to computers so that they have the same base software. The image can be installed on a new computer that has no software, or it can replace existing software on a computer that you want to reuse. There are several types of images: Golden master A depersonalized operating system image that is used for deployment on multiple computers. Operating system installations include many unique elements that need to be generalized before capturing an image. For example, on Windows computers, the computer name and security identifier are unique to each computer. A golden master image is generic so that it can be installed on a different computer from the computer where the image was captured from. Unattended setup An installation of the operating system without user interaction - it is equivalent to installing the operating system directly from the operating system media. Point-in-time snapshot An image of the computer that is captured without using a system preparation tool to make the image generic. This type of image can be used to back up a specific computer. Note: This option is not recommended for use in situations other than for backing up data files on a system. Some software applications have a complex configuration and might not work properly after being restored. Point-in-time snapshots are only supported on Windows.
270
TPM for Images Virtual Image A new image type that was specifically added for virtual image support. For more information about virtual images, see Chapter 5, Managing virtual images, on page 387. Requirements for capturing an image: Information pertaining to source computers Ensure that you have the following information. This is required to perform the task. v The name of the computer that contains the operating system that you want to capture. v The time that you want to capture the image. You can start the capture immediately, or schedule it for a later time. Ensure the source computer has an operating system associated with it The source computer must have an operating system defined on it. This is used to display a list of boot servers that are capable of capturing an image for that operating system and hardware architecture. Managed by Tivoli Provisioning Manager The source computer must be managed by Tivoli Provisioning Manager. The source computer must have at least one of the following defined: v UUID. This is a property of the server object called: computer.uuid v Serial number. This is a property of the server object computer called: computer.serialNumber v A NIC set as netboot enabled with the MAC address of the network interface the source computer starts from. Requirements for installing an image: Information required for installing an image Ensure that you know the time that you want to install the image. You can start the installation immediately, or schedule it for a later time. Target computer capabilities when deploying with Tivoli Provisioning Manager for OS Deployment The target computer must be managed by Tivoli Provisioning Manager and must have at least one of the following defined: v UUID. This is a property of the server object called: computer.uuid v Serial number. This is a property of the server object computer called: computer.serialNumber v A NIC set as netboot enabled with the MAC address of the network interface the target computer starts from. Also, it must meet the minimum hardware requirements to install the operating system.
Unattended setup image deployment

An unattended setup image is an installation of the operating system without user interaction - it is equivalent to installing the operating system directly from the operating system media. An unattended setup image enables you to deploy an operating system to a target system. Deploying an operating systems to target system using an unattended setup image typically involves the following steps: v Creating an unattended setup image by providing the installation CD-ROMs and choosing installation options. The application can be accessed in Tivoli Provisioning Manager by selecting Go to > Deployment > OS management > Unattended Setup Image. This will run a wizard you can use to create an unattended setup image. v Creating software modules for most commonly used business applications and other software, using the web interface v Optionally, designing automatic binding rules and fixed configuration parameters for fully unattended deployment on unknown targets
271
Determining which kind of operating system image to create

This topic provides reference information to help you determine which kind of operating system image you must choose given a specific situation.
There are three different types of operating systems images you can create. You must consider certain prerequisites (such as which operating systems are supported) as well as your goal when creating an image.
When to use an unattended setup image

Supported Operating Systems Windows, AIX, Linux (Intel and PPC), Solaris, VMWare Description An unattended setup image is an installation of the operating system without user interaction - it is equivalent to installing the operating system directly from the operating system media. An unattended setup image enables you to deploy an operating system to a target system. . This can save you a lot of time if you have numerous machines you need to deploy an image to. Sample uses Using automation to install a fresh operating system from the operating system CD, instead of doing it manually. Creating a reference machine with a basic installation (for an operating system, for example). Creating an image you want to reuse exactly as is. For example, for setting up computers in a test or classroom environment, where all user data and configurations can be the same.
When to use a golden master image

Supported Operating Systems Windows and Linux on Intel Description A golden master image is a depersonalized boot device image that is be used for deployment on multiple computers using some configuration files that would personalize the image for the target computers. Sample uses For situations in which you need to able configure options, such as modifying disk settings and users when you deploy an image. For example, you are setting up computers for your team, and they all need the same software, but different user IDs. Limitations Not supported on all operating systems. On Windows, you must use sysprep before you create the image.
When to use a point in time snapshot

Supported Operating Systems Windows Description A Point-In-Time snapshot is an image that is captured without making the image generic. Because the image is not depersonalized, you cannot deploy it to other computers. Sample uses Simple backup of an individual computer.
272
Restoring a computer from a software-related problem, such as malware intrusions or operating system failure. Limitations Only supported on Windows Limited in the amount of data they can handle and might fail for machines with large amounts of data Does not scale well. It must not be used as a general backup solution for a set of computers or your entire enterprise.
Network boot
Tivoli Provisioning Manager for OS Deployment (or Tivoli Provisioning Manager for Images) implements a PXE network boot application. There are several ways computers can boot over a network, but the one mandated by PC99 is called PXE. PXE is a type of DHCP extension. Tivoli Provisioning Manager requires that any target computer you want to use for OS or virtual image management (for example, capturing images from or deploying images to) must have its boot order set to boot from the network first. This is a requirement to be able to perform operating system or virtual image management operations in a Tivoli Provisioning Manager environment. Note: Your target computer must be set to boot from the network, and also from the Tivoli Provisioning Manager for OS Deployment boot server. You might need to configure your DHCP server in order to do this: DHCP server requirements and configuration on page 296. A network boot application is different from any other program for a number of reasons: v It is invoked by the BIOS during the initial bootstrap of the computer, before any operating system or disk boot manager. v It depends on the presence of a special chip on the network card, the PXE boot ROM. v It is capable of communicating with a server over the network thanks to a programming interface provided by the bootrom. PXE is the informal standard for this kind of programming interface. v It is downloaded from a special OS deployment server, and does not depend on any local storage device. It can work on computers without hard disk, CD-ROM or diskette devices. If a local storage device is present on the computer, it is accessible to the network boot application. However, a network boot application does not fail if the storage device is corrupted or broken. v It gets its parameters (IP address and other boot parameters) from a central DHCP server. A typical network-boot sequence goes through the following phases: 1. Starting up: A user or a wake-up event starts up the remote-boot computer. 2. Network boot: The BIOS configuration (boot order), a hot key (for example, F12), or the wake-up event instructs the computer to boot on the network. 3. IP address discovery: The remote-boot target computer broadcasts a DHCP request for an IP address. Any DHCP server which knows the target (that is, recognizes its hardware address) or which has a pool of freely distributable dynamic addresses sends an IP address. The target takes the first answer and confirms it to the server. In addition to the IP address, the server gives some other network parameters to the target and information about the boot procedure to follow. 4. OS deployment server discovery: In the case of PXE remote-boot, the target computer then proceeds to the discovery of the OS deployment server. The OS deployment server is responsible for delivering a network boot program to the target. It is not necessarily the same computer as the DHCP server. The target responds to the first OS deployment server which replies and downloads a small program using a simple multicast protocol (MTFTP). 5. Server connection: If the network boot program is the deployment engine, it establishes a secure (encrypted) connection to the provisioning server and receives instructions from the server to determine the name of the program to run.
273
6. Pre-OS configuration: The deployment engine then downloads from the file server everything required by the OS configuration specified by the system administrator. These file transfers are done using a secure, robust and efficient unicast or multicast protocol. Many actions can be performed at this stage: installing an operating system from scratch, repairing a corrupted operating system, or performing an inventory. 7. OS booting: When instructed by the OS configuration, the deployment engine removes itself from memory and allows the computer to start the operating system, as if the computer is booting normally from the hard disk. This ensures full compatibility with the operating system and avoids all problems of the traditional diskless remote boot. Note: Tivoli Provisioning Manager for OS Deployment features a fault-tolerant server architecture, with the OS deployment server always available to the target. However, in case of severe network failure, targets can be configured to work in offline mode, without network access. In this scenario, the deployment engine is stored on a permanent storage medium, such a hard disk partition or a CD-ROM, and started from that medium instead of being loaded from the network.
Booting targets without using PXE

If you do not want to use PXE on your network, you can use Tivoli Provisioning Manager for OS Deployment to create a network boot CD, DVD, or USB drive. With network boot media, your target can boot and connect to the Tivoli Provisioning Manager for OS Deployment server in a PXE-less environment. Use this kind of deployment when it is not possible to use PXE to boot the target. Some typical situations are network card without PXE support, firewalls preventing PXE traffic, non-allowed PXE boot, or an unavailable DHCP server. To create the network boot media, you can either use the web interface wizard or run command lines from a computer with the web interface extension installed. Whether you have Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installed, the creation of the network boot media is the same. For procedural details, see the following links. Note: v Network boot media must be updated every time the OS deployment server is updated or upgraded to ensure compatibility with the OS deployment server. v If your network boot media is optimized for Windows operating systems, you must create the media from an OS deployment server or a web interface extension installed on a computer with the same byte order (little endian or big endian) as the one on which you want to use the network boot media. Creating network boot USB drive with the wizard: Tivoli Provisioning Manager for OS Deployment can automatically generate bootable USB drives that connect the target to an OS deployment server, without using DHCP or PXE, to perform deployments. Before you begin Install the rbagent, also known as web interface extension, on a Windows target. The USB drive must be formatted as FAT32 or NTFS. USB keys already filled with a bootable operating system might not work. Note: SuSE Linux Enterprise Desktop cloning is not supported on USB drive deployments These bootable USB drives can also be used to deploy computers without a PXE compliant network adapter. To create OS bootable USB drives:
274
Procedure 1. Click Go To > Deployment > OS Management > Software Modules. 2. Click Create deployment media. 3. Select Create a network boot USB key to start the USB key wizard. Click Next. 4. Specify the operating system on which to boot the target. Select Optimized for Linux to load an embedded Linux environment or Optimized for Windows to load a WinPE deployment engine. Note: Before clicking Optimized for Windows, ensure that you created the WinPE deployment engine. To determine what WinPE version is required, see the Tivoli Provisioning Manager for OS Deployment documentation. If you have the WinPE deployment engine on the OS deployment server, the WinPE deployment engine starts by default. Otherwise the default is to start embedded Linux. Only when embedded Linux or WinPE is running, does the target connect to the network and try to contact an OS deployment server. 5. If you want to obtain the target IP address through DHCP, select Dynamic IP address with DHCP, and click Next. If you want to use a fixed IP address for your target instead of having it go to the DHCP server, select Static IP address, and click Next. a. Enter the target IP address, gateway, and network mask. b. (Optional) Select Allow IP address override at runtime to be able to modify the target IP address when starting up the target. c. Click Next. 6. Enter the IP address of the OS deployment server. 7. (Optional) Select Allow server IP address override at runtime to be able to modify the IP address of the OS deployment server when starting up the target. 8. Plug your USB key into a machine running the web interface extension, and specify its address. 9. Choose the drive matching your USB key. 10. Click Finish to close the wizard. What to do next Use the USB drive to boot the target. Creating a network boot CD or DVD with the wizard: Procedure 1. Click Go To > Deployment > OS Management > Software Modules. 2. Click Generate media at the bottom of the page. 3. Select Create a network boot CD/DVD and click Next. 4. If you want to obtain the target IP address through DHCP, select Dynamic IP address with DHCP, and click Next. If you want to use a fixed IP address for your target instead of having it go to the DHCP server, select Static IP address, and click Next. a. Enter the target IP address, gateway, and network mask. b. (Optional) Select Allow IP address override at runtime to be able to modify the target IP address when starting up the target. c. Click Next. 5. Specify the operating system on which to boot the target. Select Optimized for Linux to load an embedded Linux environment or Optimized for Windows to load a WinPE deployment engine.
275
Note: Before clicking Optimized for Windows, ensure you created the WinPE deployment engine. To determine what WinPE version is required, see the Tivoli Provisioning Manager for OS Deployment documentation. If you have the WinPE deployment engine on the OS deployment server, the WinPE deployment engine starts by default. Otherwise the default is to start embedded Linux. Only when embedded Linux or WinPE is running, does the target connect to the network and try to contact an OS deployment server. 6. Enter the IP address of the OS deployment server. 7. (Optional) Select Allow server IP address override at runtime to be able to modify the IP address of the OS deployment server when starting up the target. Note: When you create the network boot CD or DVD in a multiserver infrastructure, ensure that the OS deployment servers share the same password and port number. The network boot CD or DVD works only if you specify the IP address of a OS deployment server having the same password and port number of the OS deployment server that generated the ISO file. 8. Click here on the screen to download the ISO file. 9. Click Finish to close the wizard. What to do next The generated ISO file can be burned to create the network boot CD. To start a target computer over the network using your OS deployment server without booting through PXE, start the target on the network boot CD and the target automatically connects to the OS deployment server. Creating a network boot USB drive with command lines: You can create a network boot USB drive, which Tivoli Provisioning Manager for OS Deployment can use when a target cannot boot from the network. Before you begin Install the rbagent, also known as web interface extension, on a Windows target. The USB drive must be formatted as FAT32 or NTFS. Existing files on the USB drive are not deleted. USB keys already filled with a bootable operating system might not work. The command line must be used only when the web interface is either inappropriate or unavailable. Procedure v If you want to obtain the target IP address through DHCP, use this command line:
Windows
On Windows operating systems
rbagent.exe -s <OSD_server_ip_address>:<OSD_server_password> rad-mkbootusb <drive> <USB_OSD_server_ip_address> <USB_OSD_server_password> [allowsrvipoverload] [nowpe|preferwpe] [bootopt nnn] [clearcmos]
where: OSD_server_ip_address Is the IP address of the OS deployment server. OSD_server_password Is the password for the administrative user (typically admin) on your OS deployment server. drive Is a drive letter of the Windows target where you run the rbagent command. The
276
rad-mkbootusb command adds the requested files to the FAT32 or NTFS partition and makes it bootable. The drive must be already formatted. Existing files on the partition are not deleted. USB_OSD_server_ip_address Is the IP address of the OS deployment server that the target must contact, when it boots from the USB drive. USB_OSD_server_password Is the password of the OS deployment server that the target must contact, when it boots from the USB drive. allowsrvipoverload Allows you to choose an OS deployment server later, from the target. nowpe|preferwpe Defines if an embedded Linux environment or WinPE2 environment is loaded from the USB drive, when a target boots from this USB drive, without accessing the network. Only when embedded Linux or WinPE2 is running, does the target connect to the network and try to contact an OS deployment server. If you deploy only Linux, specify prefermcp to skip the WinPE2 deployment engine. You can specify preferwpe only if there is a WinPE2 deployment engine on the OS deployment server. bootopt nnn Allows you to specify additional flags before the boot. clearcmos Resets the CMOS alarm fields if they are in an invalid state. For example:
> C:\TPMfOSd Files\global\http\agents\rbagent.exe -s 10.10.10.10:abcd rad-mkbootusb C: 10.10.10.10 abcd
v If you want to use a fixed IP address for your target instead of having it go to the DHCP server, use this command line: On Windows operating systems:
rbagent.exe -s <OSD_server_ip_address>:<OSD_server_password> rad-mkbootusb <drive> <USB_OSD_server_ip_address> <USB_OSD_server_password> fixed [fixed_ip_address] [fixed_netmask] [fixed_gateway_ip_address] [allowsrvipoverload] [nowpe|preferwpe] [allowipoverload] [bootopt nnn] [clearcmos]
where: OSD_server_ip_address is the IP address of the OS deployment server. OSD_server_password is the password for the administrative user (typically admin) on your OS deployment server. drive is a drive letter of the Windows target where you run the rbagent command. The rad-mkbootusb command adds the requested files to the FAT32 or NTFS partition and makes it bootable. The drive must be already formatted. Existing files on the partition are not deleted.
USB_OSD_server_ip_address Is the IP address of the OS deployment server that the target must contact, when it boots from the USB drive. USB_OSD_server_password Is the password of the OS deployment server that the target must contact, when it boots from the USB drive. fixed_ip_address Is the static IP address of the target you boot using the USB drive.
277
fixed_netmask Is the netmask of the target you boot using the USB drive. fixed_gateway_ip_address Is the IP address of the gateway that the target uses. nowpe|preferwpe Defines if an embedded Linux environment or WinPE2 is loaded from the USB drive, when a target boots from this USB drive, without accessing the network. Only when embedded Linux or WinPE2 is running, does the target connect to the network and try to contact an OS deployment server. If you deploy only Linux, specify nowpe to skip the WinPE2 software module. You can specify preferwpe only if there is a WinPE2 software module on the OS deployment server. allowipoverload Allows you to define IP settings manually on the target. bootopt nnn Allows you to specify additional flags before the boot. clearcmos Resets the CMOS alarm fields if they are in an invalid state. What to do next You can now boot the target using the network boot USB drive instead of the network card. To use the PXE emulation USB key, insert the USB key into the drive and restart the target. If your machine does not boot from the USB key, check the BIOS boot list to see if your USB drive is included in the boot sequence and is listed before the hard disk. Most machines also allow you to select the temporary boot device without changing the boot sequence in BIOS. Creating a network boot CD or DVD with command lines: This mode must be used only when the web interface is either inappropriate or unavailable. Note: When you create the network boot CD or DVD in a multiserver infrastructure, ensure that the OS deployment servers share the same password and port number. The network boot CD or DVD works only if you specify the IP address of a OS deployment server having the same password and port number of the OS deployment server that generated the ISO file. Procedure v If you want to obtain the target IP address through DHCP, use these command lines:
UNIX Linux
#./rbagent -s <target_ip_address>:<target_password> rad-mkbootcd <full_path_to_boot_iso> <target_ip_address> <target_password>
Windows
rbagent.exe -s <target_ip_address>:<target_password> rad-mkbootcd <full_path_to_boot_iso> <target_ip_address> <target_password>
where: target_ip_address Is the IP address of the OS deployment server. target_password Is the password for the administrative user (typically admin) on your OS deployment server.
278
full_path_to_boot_iso Is the full path to the .iso file you want to create on the target where you run the rbagent command. For example:
> C:\TPMfOSd Files\global\http\agents\rbagent.exe -s 10.10.10.10:abcd rad-mkbootcd C:\boot.iso 10.10.10.10 abcd
This creates a file called boot.iso in c:\ which can be burned onto a CD. v If you want to use a fixed IP address for your target instead of having it go to the DHCP server, use these command lines:
UNIX Linux
#./rbagent -s <target_ip_address>:<target_password> rad-mkbootcd <full_path_to_boot_iso> <target_ip_address> <target_password> [fixed_ip_address] [fixed_netmask] [fixed_gateway_ip_address]
Windows
> rbagent.exe -s <target_ip_address>:<target_password> rad-mkbootcd <full_path_to_boot_iso> <target_ip_address> <target_password> [fixed_ip_address] [fixed_netmask] [fixed_gateway_ip_address]
where: fixed_ip_address Is the static IP address of the target you boot using the CD. fixed_netmask Is the netmask of the target you boot using the CD. fixed_gateway_ip_address Is the IP address of the gateway the target uses. What to do next The generated ISO file can be burned to create the network boot CD. To start a target computer over the network using your OS deployment server without booting through PXE, start the target on the network boot CD and the target automatically connects to the OS deployment server.
Requirements
Before you start working with managing operating systems, ensure that you meet all requirements.

To perform operating system management tasks, ensure that you have the required knowledge and access rights to perform your role.
Table 52. User roles Role Deployment Specialist Description v Deploys images Skills v Server management experience v Familiarity with OS management life cycle
279
Table 52. User roles (continued) Role Provisioning Configuration Librarian Description v Manages overall product configuration. v Responsible for setting up the environment to support boot server technologies. Provisioning Administrator Skills v Knowledge of provisioning server configuration and boot server technologies.
v Performs higher level management v Knowledge of boot server of the environment such as technologies. installing or deleting boot servers. v The individual who uses a target computer, typically a notebook, desktop or server. v Basic knowledge of the operating system on the target computer.
End User
Server system requirements

Before you install OS deployment servers, ensure that you meet the system requirements.
Hardware requirements
The minimum recommended configurations for the OS deployment server includes:
Table 53. Hardware requirements for the OS deployment server Processor type Minimum Recommended Dual-Xeon Quad-core or two dual-core Processor speed 2 GHz 2 GHz RAM 1 GB RAM 2 GB RAM Free disk space 10 GB 100 GB
Store Tivoli Provisioning Manager for OS Deployment files on a large hard disk if you plan to create many hard-disk images, and you might want to use a fast processor to minimize the time spent creating these images. The OS deployment server is multithreaded and benefits from computers with multiple processors.
Operating system requirements

Tivoli Provisioning Manager for OS Deployment must be installed during Tivoli Provisioning Manager installation, so that the parent OS deployment server is installed on the provisioning server. If you decide to add a child OS deployment server after the Tivoli Provisioning Manager installation, you can install the OS deployment server on any of the supported platforms for the provisioning server. For more information, see Supported operating systems and platforms for target computers. Compatible operating system and architecture for Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images are listed in the following table:
Table 54. Server operating systems Operating system Windows XP Professional Server Windows 2003 Server Windows 2008 Server SUSE Linux Enterprise Server (SLES) 10 Architecture x86-32 and x86-64 x86-32 and x86-64 x86-32 and x86-64 x86-32 and x86-64
280
Table 54. Server operating systems (continued) Operating system SUSE Linux Enterprise Server (SLES) 10 SUSE Linux Enterprise Server (SLES) 10 SUSE Linux Enterprise Server (SLES) 11 SUSE Linux Enterprise Server (SLES) 11 SUSE Linux Enterprise Server (SLES) 11 Red-Hat Enterprise Linux Server 5 Red-Hat Enterprise Linux Server 5 IBM AIX 6.1 Solaris 10 Update 6 Architecture IBM PowerPC 64 (iSeries and pSeries) IBM System z x86-32 and x86-64 IBM PowerPC 64 (iSeries and pSeries) IBM System z x86-32 and x86-64 IBM PowerPC 64 (iSeries and pSeries) IBM PowerPC 64 (iSeries and pSeries) SPARC 64-bit
Also, Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images can work with almost any RFC-compliant DHCP server, including Windows 2003 DHCP server, Windows 2000 DHCP server, ISC DHCP server, Solaris DHCP server and the Netware 5 DHCP server.
Target system requirements

For operating system management, the following target system requirements must be met.
The following are the requirements for x86 and x8664 targets: v Minimal processor: Pentium type level. v Minimal RAM memory: 512 MB. Note: Windows 1 GB might be necessary on some targets to run WinPE2. 1 GB RAM is also necessary on the reference target to capture a golden master or a virtual image. v VESA-compliant (release 2.0 or later) Video BIOS to get "high" resolution (VGA fallback is always possible in case of incompatibility) and to have a user interface on the target. Note: Tivoli Provisioning Manager for OS Deployment can also work on headless computers, in which case all operations have to be performed from the web interface. v Either a legacy ATA drive (with Ultra DMA support if speed is required) or a BIOS-supported hard drive. v DMI support for collecting hardware information, such as model and serial number. Note: Disks with a size equal to or larger than 1 TB are not supported on targets running Linux and on virtual images. To make full use of the Tivoli Provisioning Manager for OS Deployment features, remote-boot x86 and x8664 targets must be equipped with a PXE-compliant bootrom, either version 2.00 or later. Most recent computers with on-board network adapters have built-in PXE support. The network cards that have been shown to work best with Tivoli Provisioning Manager for OS Deployment are Intel adapters. For computers without built-in PXE support, you might consider using a PXE emulation floppy available from various third party sources, creating network boot media, or working offline with deployment media. SUN SPARC targets need a firmware that supports the SUN wanboot method for network booting. Wanboot is the only supported network boot method for SUN SPARC.
281
Tivoli Provisioning Manager for OS Deployment can also deploy operating systems to VMWare virtual machines. Use of the Intel e1000 adapter on VMWare virtual machines requires VMWare ESX 3.0.2 with February 2008 patches, VMWare ESX 3.5 or later, VMWare Workstation 6.0.3 or later, VMWare Server 2.0 or later. Microsoft Virtual PC and Microsoft Virtual Server are not supported.

Compatible operating system, version, and architecture for OS deployments on Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images targets are listed in Table 1:
Table 55. Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images target operating systems Operating system Windows Server 2008 Version GA, R2, R2-SP1 (See note) Architecture x86-32 and x86-64 Disk and memory requirements For image deployment v 10 GB free disk space (32-bit) v 20 GB free disk space (64-bit) v 1 GB RAM For image capture v 1 GB RAM
Windows 7
GA and SP1 (See note)
x86-32 and x86-64
For image deployment v 10 GB free disk space (32-bit) v 20 GB free disk space (64-bit) v 1 GB RAM
Windows Vista
GA and SP2
x86-32 and x86-64
Windows 2003 Server Windows XP Professional SUSE Linux Enterprise Server (SLES) SUSE Linux Enterprise Server (SLES) SUSE Linux Enterprise Server (SLES) SUSE Linux Enterprise Desktop (SLED)
SP2/R2 SP3 11 11 10 SP3 10 SP3
x86-32 and x86-64 x86-32 and x86-64 x86-32 and x86-64 IBM PowerPC 64 (pSeries) x86-32 and x86-64 x86-32 and x86-64
282
Table 55. Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images target operating systems (continued) Operating system SUSE Linux Enterprise Server (SLES) Red-Hat Enterprise Linux (RHEL) Server Red-Hat Enterprise Linux (RHEL) Server Red-Hat Desktop Red-Hat Enterprise Linux (RHEL) Server Red-Hat Enterprise Linux (RHEL) Server Red-Hat Desktop Solaris Solaris Solaris IBM AIX 5L IBM AIX 6L VMWare ESX Server VMWare ESX Server VMWare ESX Server
Version 10 SP3 6 (See note) 5, Update 3 5, Update 3 5, Update 3 4, Update 8 4, GA version only 10 Update 6 10 9 (cloning only) 5.3 (setup only) 6.1 (setup only) 4.0 3.5 Update 4 3.0.2
Architecture IBM PowerPC 64 (pSeries) x86-32 and x86-64
Disk and memory requirements
x86-32 and x86-64 x86-32 and x86-64 IBM PowerPC 64 ( pSeries) x86-32 and x86-64 x86-32 and x86-64 SPARC 64-bit SPARC 64-bit SPARC 64-bit IBM PowerPC 64 (pSeries) IBM PowerPC 64 (pSeries) x86-32 x86-32 x86-32
Note: Windows 2008 R2 SP1, Windows 7 SP1, and Red-Hat Enterprise Linux 6 are currently supported with Tivoli Provisioning Manager for OS Deployment version 7.1.1.5.
File system requirements

Support for Windows Vista/2008/7 is restricted to NTFS partitions. FAT 32 partitions are not supported. Supported file systems include: v The Second Extended File system (Ext2) and Third Extended File system (Ext3). Tivoli Provisioning Manager for OS Deployment can natively write files on Ext2 and Ext3. This means that the product can create and format Ext2 and Ext3 partitions, and can add, delete, and modify files on these partitions. v Partitions UUID and labels v LVM file system Note: Tivoli Provisioning Manager for OS Deployment cannot capture an image, or perform direct replication from a target with unformatted partitions, or partitions formatted using an unsupported proprietary file system. Such partitions should be either deleted or formatted using a supported file system before capturing or replicating an image to another computer.
Setting up additional child OS deployment servers

If you installed Tivoli Provisioning Manager for OS Deployment during the Tivoli Provisioning Manager installation, a primary boot server is installed on the provisioning server. This is the parent server. If you want, you can then add child servers to distribute the OS deployment workload.
283
Remember: For Tivoli Provisioning Manager for Images, the procedure to install additional child servers is identical with this one, for Tivoli Provisioning Manager for OS Deployment. If you did not install Tivoli Provisioning Manager for OS Deployment during Tivoli Provisioning Manager installation, you must run the Tivoli Provisioning Manager installation again to install the parent boot server on the provisioning server.
Provisioning server Remote server 1
Parent boot server
Child boot server
OS deployment database
Remote server 2
Child boot server
If you install child servers, you can optionally promote a child server to be the parent boot server.
Child boot server
Parent boot server
Remote server 2
Child boot server
Tivoli Provisioning Manager for OS Deployment can support environments with a large number of target computers by spreading the workload between multiple boot servers. Replication is the means to keep files and information up-to-date between parent and child servers. All images are automatically replicated to the parent server, and from the parent server to all the child servers. The Tivoli Provisioning Manager for OS Deployment database is stored on the provisioning server. Child servers do not have their own databases, but point to the parent database.
Creating child OS deployment servers

You can install Tivoli Provisioning Manager for OS Deployment child servers to distribute the OS deployment workload.
Before you begin

The computer where you want to install a new OS deployment server must be an existing Tivoli Provisioning Manager managed computer. Ensure that the computer meets basic requirements for target computers: Server system requirements on page 280.
284
To successfully deploy a child server, ensure that your target system exposes the Windows cpu.type ( Linux cpu.family) property under hardware resources, otherwise Tivoli Provisioning Manager cannot for Intel, AMD, zSeries, and resolve to the correct ( Windows 32bit or 64bit) installable file ( Linux PowerPC systems). To perform this task: 1. Discover a target computer. See Discovering your target computers on page 568. 2. Discover hardware resources on the target computer. See Discovering hardware using provisioning Inventory discovery on page 164. If a Tivoli Provisioning Manager for OS Deployment boot server was not installed during Tivoli Provisioning Manager installation, you must rerun the Tivoli Provisioning Manager again to install it. For instructions, see the Tivoli Provisioning Manager Installation Guide. To create a child OS deployment server:
Procedure
1. Click Go To > Deployment > OS Management > Boot Server Installation. 2. Select the computer that you want to use as your OS deployment server. 3. Select TPMfOSd for the Boot Server Type. Click OK. 4. Review the information, then click Submit.
Results
You have now installed a child OS deployment server. Uninstalling child OS deployment servers: You can uninstall the child OS deployment servers that you no longer require. To uninstall your OS deployment server: Procedure 1. Click Go To > Deployment > Provisioning Computers. 2. Select the computer that has the OS deployment server installed. 3. Click Select Action > Uninstall > Software Installation and uninstall the OS deployment server installation. Results You have now uninstalled your child OS deployment server.
Promoting a child OS deployment server

You can promote a child OS deployment server so that it becomes the parent OS deployment server. You might want to promote a child OS deployment server to a parent OS deployment server to cut down on the workload on the provisioning server. Important: Promoting a child server is a major operation that modifies all Tivoli Provisioning Manager for OS Deployment boot servers in their infrastructure. All OS deployment servers must be running in a good state, with no Tivoli Provisioning Manager for OS Deployment activities running before performing this operation. To promote a child OS deployment server:
285
Procedure
1. Click Go To > Deployment > OS Management > Boot Servers. 2. From the Select Action menu, click Promote a child boot server to parent. 3. When prompted, click Yes.
Results
The child server is now a parent server, and the parent server is now a child server.
Windows Preinstallation Environment (WinPE)

Windows Preinstallation Environment is more and more widely used in all the tasks pertaining to the deployment of Windows operating systems. Tivoli Provisioning Manager for OS Deployment uses three different kinds of WinPE2 software modules, depending on the tasks at hand.
WinPE3: If you have upgraded to Tivoli Provisioning Manager for OS Deployment version 7.1.1.4, the supported WinPE deployment engine is 3.0. Other versions are not compatible. WinPE 3.0 must be created from a Windows Automated Installation Kit (AIK) for Windows 7 in English. To learn more about using WinPE3, see Managing multiple WinPE 3.0 deployment engines on page 289.
Types of WinPE2
WinPE2 consists of a group of files that can be loaded as a ramdisk, which enable you to perform operations on a target. WinPE2 deployment engine This WinPE2 is a prerequisite to create Windows images and deploy them. You must store only one WinPE2 deployment engine on your OS deployment server, as it is independent of the architecture or the version of the Windows operating system you work with. However, depending on your hardware, you might have to inject specific drivers in your WinPE2 deployment engine. To create a WinPE2 deployment engine you need a computer running Windows 32-bit, with Windows Automated Installation Kit (WAIK) 1.1 32-bit in English installed, and running the web interface extension. WinPE2 ramdisk This WinPE2 contains the installation files for any Windows Vista/2008/7 operating system. It can be found on the original installation CD/DVD. In the case of a Windows Vista/2008/7 unattended setup creation, the WinPE2 ramdisk software module is automatically created and bound to the image, which ensures your WinPE2 to be of the correct version. For golden master images, you also need a WinPE2 ramdisk if you need to inject drivers into your image. In this case, you might need to create your WinPE2 ramdisk using the Software wizard. To create a WinPE2 ramdisk, you need a computer running Windows 32-bit, with WAIK 1.1 32-bit in English installed, and running the web interface extension. You also need the original Windows Vista/2008/7 installation CD/DVD. Note: A 64-bit WinPE2 ramdisk is required to be able to reuse Windows Vista and Windows 2008 64-bit images created with an earlier version of Tivoli Provisioning Manager for OS Deployment, for example, version 7.1.1. WinPE2 hardware environment This type of WinPE2 is used for hardware configurations.
286
To create a WinPE2 hardware environment, you must start the vendor commands on a computer running Windows 32-bit, with WAIK 1.1 32-bit in English installed, and the web interface extension installed. You must start the vendor commands before you start the web interface extension.
Windows Automated Installation Kit (WAIK)

Note: Windows Automated Installation Kit for Windows 7 and Windows Server 2008 R2 is not supported. Use Windows Automated Installation Kit 32-bit for Windows Vista and Windows Server 2008 in English. You must restart your computer after having installed WAIK.
Good practice
If you deploy Windows operating systems, you need to create one WinPE2 deployment engine, and potentially several WinPE2 ramdisks and WinPE2 hardware configurations. For each of these creations, you need a computer running under Windows, with WAIK and the web interface extension installed. The same configuration is also needed to update Windows Vista/2008/7 images, and to inject drivers into the WinPE2 deployment engine. WAIK can be obtained free of charge from Microsoft, but it is rather heavy and cumbersome to install. Therefore, it is good practice to install WAIK and the web interface extension on a target running a Windows operating system and to perform all operations requiring this configuration on this dedicated target.
Creating a WinPE2 deployment engine

To create or deploy Windows images, you must create a WinPE2 deployment engine.
Before you begin

Ensure that the computer from which you create the WinPE2 deployment engine: v Runs a 32-bit version of Windows. v Has Windows Automated Installation Kit (WAIK) installed. v Runs the web interface extension. This computer can be: v A local OS deployment server installed on a Windows 2000/2003/2008/XP/Vista/7 operating system v Any computer with a Windows 2000/2003/2008/XP/Vista/7 operating system. Note: To work with a Windows target, you must install Windows Automated Installation Kit (WAIK) 1.1 32-bit for Windows Vista and Windows 2008 in English. Windows Automated Installation Kit for Windows 7 and Windows Server 2008 R2 is not supported. Note: If you upgraded your Tivoli Provisioning Manager for OS Deployment to 7.1.1.4 or higher, create WinPE deployment engines using the application at Click Go To > Deployment > OS Management > OS Deployment Engines. . For more information about the OS Deployment Engines application, see Managing multiple WinPE 3.0 deployment engines on page 289. You must create a WinPE2 deployment engine only once, unless you deleted it. To start the WinPE2 software module creation:
287
Procedure
1. Navigate to the Software Modules page. Click Go To > Deployment > OS Management > Software Modules. 2. From the contextual menu, click Add a new software. The Software wizard is displayed. 3. Select one of the Windows operating systems as the type of software module to create, and click Next. 4. Select WinPE 2 engine for OS deployment server ramdisk image, and click Next. 5. Specify the address of the computer on which you installed WAIK and the web interface extension, and click Next. 6. Click Finish.
Results
The resulting WinPE2 deployment engine appears as a software module in the WinPE2 Deployment engine specific folder.
What to do next
The created WinPE2 deployment engine might not contain all the necessary drivers depending on the hardware on which you want to use it. If this is the case: Create software modules with the missing drivers. Double-click the WinPE2 deployment engine to view the software details. Click Update drivers. Specify the address of the computer on which you installed WAIK and the web interface extension, and click Next. 5. Select the software modules containing the drivers you need to inject in your WinPE2 deployment engine and click Next. 1. 2. 3. 4. After you created the WinPE2 deployment engine, you can create and deploy Windows images. Note: During the deployment, do not edit the WinPE2 deployment engine that you are using.
Creating a WinPE2 ramdisk

WinPE2 ramdisks are automatically created and bound to your image when you create an unattended setup for Windows Vista/2008/7. However, you need to create one manually if you need to inject divers into a Windows Vista/2008/7 golden master image or Tivoli Provisioning Manager for Images virtual image.
Before you begin

To create a WinPE2 ramdisk, you need a computer running Windows 32-bit, with WAIK 1.1 32-bit in English installed, and running the web interface extension. You also need the original Windows Vista/2008/7 installation CD/DVD. To create a WinPE2 ramdisk software module:
Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. 3. 4. 5. 6. From the contextual menu, click Add a new software. The Software wizard is displayed. Select A Windows Vista / 2008 / 7 software module, and click Next. Select A custom action on the target computer, and click Next. Select A WinPE 2.0 Ramdisk image for Vista/2008/7, and click Next. Specify the IP address of the computer on which you installed WAIK and the web interface extension.
288
7. Specify the location of the Windows Vista/2008/7 installation files (CD-ROM/DVD), and click Next. 8. Click Finish.
What to do next
The WinPE2 ramdisk software module is created. Now, you can bind it to the corresponding Windows Vista/2008/7 golden master or virtual images. Note: For Tivoli Provisioning Manager for Images virtual images, you do not need to create binding rules to bind the WinPE2 ramdisk software module to the Windows Vista/2008/7 virtual images. As long as you have the WinPE2 ramdisk image, Tivoli Provisioning Manager for Images can automatically find it and bind it for you.
Managing multiple WinPE 3.0 deployment engines

Create and manage multiple WinPE3 deployment engines for deploying Windows images.
Before you begin

This feature is only available if you upgrade to Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images, version 7.1.1.4 or higher. To upgrade, see the document called Upgrading Tivoli Provisioning Manager for OS Deployment to a later version on page 352. Important: After you upgrade to version 7.1.1.4 or higher, you must restart the provisioning server and WebSphere Application Server to refresh the provisioning web interface. Use the tio command to restart both of the servers. Starting in version 7.1.1.4, Provisioning Manager for OS Deployment and Provisioning Manager for Images provide support for having several WinPE 3.0 deployment engines on any OS deployment server. You can manage the WinPE 3.0 deployment engines in these products without leaving the provisioning web interface. To access the deployment engines using Tivoli Provisioning Manager, follow these steps:
Procedure
1. Log into the provisioning web interface. 2. Click Go To > Deployment > OS Management > OS Deployment Engines. Binding drivers: Before you begin Your WinPE deployment engine contains built-in drivers. Use them first. If you encounter problems with the built-in drivers, if some drivers are not bound, or if some drivers are missing, bind other drivers to your WinPE deployment engine. In this offline driver injection process, you can only bind drivers, to your WinPE deployment engine, that are driversoftware modules in your OS deployment server. You must therefore create driver software modules from the drivers that you want to bind to your WinPE deployment engine. The product helps you select appropriate drivers for particular target models. It helps you to predict potential problems and to solve them. It does not guarantee that a specific WinPE deployment engine, with bound drivers, works with a given target.
289
The information used by the OS deployment server to predict the compatibility of a driver with a target model is taken from the content provided by the vendor in its driver. The OS deployment server cannot verify the accuracy of this information. Procedure 1. Check the compatibility of your WinPE deployment engine. To view the details of the deployment engine, you have two options: v Double-click a deployment engine. v Select a deployment engine, and then select View engine details in the contextual menu. 2. Go to the section Network and mass storage drivers. A check is performed while the page is loading. This can take a few minutes. If drivers are missing, or are not bound, or if several drivers are bound for the same device, the following information is provided. Indicates a missing critical driver, or a critical driver of the wrong architecture. Indicates that a missing non-critical driver, or a non-critical driver of the wrong architecture. Indicates that a required driver is present on the OS deployment server, but that it is not bound. Indicates that there are several drivers bound for the same device, or that there is a binding with a driver that is not known as compatible. You can expand the line to get more information. v For drivers missing on the OS deployment server, you find a suggestion of where to look for it, including, if available, a download link and the exact directory within the downloaded archive where the driver can be found. v When drivers are present on the OS deployment server, you find suggestions of which driver to bind, in order of preference. If multiple drivers are known to possibly work for a device, the best choice is listed first. The choice is explained in the advice text, which first recommends the use of device-specific drivers, that is, drivers that have been specifically designed for the given hardware device. Then compatible device drivers, that match the device family, are recommended, even if they are not an exact rebranded variant (for example, as second choice, an Adaptec driver of the same family as an IBM ServerRaid adapter, if it is based on the same chipset). Finally, as third choice, generic drivers, for example, Microsoft generic AHCI driver for any AHCI controller, are recommended. If no error is found, you do not need to modify the bindings. 3. Modify the driver bindings of the WinPE deployment engine. Click Edit engine's driver bindings. There are two ways to perform this. v Use a wizard. a. Click Fix Drivers. b. Follow the instructions in the wizard. After having selected a target model, you must select one of these options: Automatically fix issues that can be fixed for this model. Fixes all issues that can be automatically fixed. Such issues include, for example, a missing binding to an existing driver, multiple bindings for a device, or removing a driver tagged for another operating system. Manually fix issues for this model. Presents you with each issue in turn. Ways to solve the issue, when available, are proposed. Automatically bind drivers for this model. Erases every existing binding. New bindings are then automatically added. Copy driver bindings for this model from a similar engine. Copies all the bindings from a selected source engine to the current engine.
290
Reset all drivers bindings for this model. Erases all the driver bindings, and does not create any new binding. v Edit the bindings manually, using the driver binding grid. Columns represent target models known to the OS deployment server and matching the patterns provided for the WinPE deployment engine. They can be expanded to view their network and mass storage devices, if a PCI inventory has been performed. The first line represents the WinPE deployment engine. Other lines represent software module folders in the OS deployment server. They can be expanded to view individual drivers. If a driver can be used only for 32-bit or 64-bit machines, a superscript x86 or x86-64 mark is written next to the driver name. If you do not find the drivers that you need in the list provided, create software modules for your drivers. a. (Optional) To obtain a summary of the errors and warnings, click the link provided above the grid. This helps you locate the problematic areas in the driver grid. b. Expand the columns of problematic target models to view the individual network and mass storage devices. c. Expand software module folders containing drivers to view the individual drivers.
Figure 3. Driver binding grid
A cell with a green background indicates that driver information corresponds to the device. The quality of the drivers that can be selected is illustrated by the intensity of the green background: the best drivers are in intense green, the family drivers are in standard green, and the generic drivers are in pale green. A cell with an orange background indicates either that the driver is not a PCI driver, or that there is no compatibility information available for the driver. indicates that the driver is bound to the WinPE deployment A cell with a green check mark engine for use with the specific target model and device. d. Click a green or orange background cell to add or remove bindings. It is not possible to bind or unbind drivers from the WinPE deployment engine itself, because they are built-in drivers.
291
You should have one, and only one, check mark per column, indicating that you have one and only one driver for each device. e. When you have finished modifying the bindings, click Save. f. To return to the Image details page, click Back. Potential problems with the image are recomputed, allowing you to check if your modifications have solved the detected problems. Results Existing WinPE deployment engines will be displayed. You can view engine details, create new deployment engines, and manage all engines in this application.
Setting up for Solaris deployments

Tivoli Provisioning Manager for OS Deployment does not require a full Solaris install environment (with JumpStart) to be able to provision Solaris. The only requirement is to have the corresponding operating system image files available via an NFS share to perform Solaris unattended setup and flash imaging. The Solaris install server can be configured on any standard Solaris computer using the steps below, but can also be installed on another UNIX computer with an NFS server compatible with Solaris targets. Although it is common to use the OS deployment server as Solaris install server, you can use multiple Solaris install servers closer to the Solaris computers to deploy than the OS deployment server if required.
Preparing the Solaris installation server

You must configure a network share and load the installation content of Solaris operating systems:
Procedure
1. Create a root directory on a volume with enough disk space. For instance: mkdir /export/install. 2. For each version of Solaris to be deployed by the OS deployment server, create a subdirectory of the root directory. For instance: mkdir /export/install/sol10. 3. Insert the appropriate installation CD-ROM or DVD-ROM. 4. Go to the CD-ROM/DVD-ROM directory, which is normally /cdrom/xxxxx where xxxxx is either cdrom0 (a symbolic link to the actual media directory) or media title such as sol_10_606_sparc. Note: A directory listing must show entries of the form s0, s1, s2, and so on. If the installation files are on multiple CD-ROMs, there is only one directory, s0. 5. Copy the content of the CD-ROMs/DVD-ROM into the Solaris installation server directory. a. Go to /cdrom/cdrom0/Solaris_10/Tools. b. Make sure you have at least 5 GB available, for instance under /export/install on your Solaris install server. c. Run ./setup_install_server -w /export/install/sol10-miniroot /export/install/sol10. This operation can take 15 to 30 minutes. d. (Optional) You can delete the sol10-miniroot directory and, if you already have your NFS install server elsewhere, the sol10 directory. Note: The paths given in the substeps are for a Solaris computer which hosts both the Solaris install server and the OS deployment server. These substeps must be performed at least once on an Solaris computer to create the miniroot file. This file can then be copied to any NFS shares. 6. Verify that NFS is started by making sure that nfsd is running. If needed, start /etc/init.d/rpc and start /etc/init.d/nfs.server (for Solaris).
292
7. Export and share the installation root directory as read-only for everyone, with root equivalence. On the Solaris install server, edit /etc/dfs/dfstab and add: share -F nfs -o ro,anon=0 /export/install. 8. Refresh shares with the command shareall. 9. Check that the export succeeded with the command showmount -e.
Results
You have now created the Solaris installation server directory, copied the appropriate content into it, and exported and shared the installation root directory as read-only.
What to do next
For the system profiles you intend to create from the files stored on the Solaris install server to be fully usable, you must: v Copy the files from the actual operating system version you want to create a profile for. If you want to deploy Solaris 10, then you must have the full content of the Solaris 10 CD-ROMs on you Solaris install server. Reusing files from another version might prevent proper OS deployment. v Use the latest available versions of the operating systems to ensure you have the most up to date fixes.
Preparing the Solaris install server for Flash Archives

It is recommended to create a separate directory on the Solaris install server for Solaris Flash archives because this directory needs to provide write permission during the creation of the flash archives.
Procedure
1. Create an export directory for Flash Archives: mkdir /export/flars. 2. Share this new directory with read and write permissions: share F nfs o rw,anon=0 /export/flars.
Results
You have now created and shared a Solaris Flash archive directory.
Configuring Solaris network boot

You can boot a SUN computer with Tivoli Provisioning Manager for OS Deployment either when the computer is booting, or when the Solaris operating system is running. Note: A network boot for Solaris is accepted only when a deployment task is scheduled on that computer. For architectures other than sun4u, change the path listed in the steps below. Use the uname -m command to check the architecture.
Procedure
1. From the OpenBOOT monitor (Stop-A), type boot net:dhcp. To make this change permanent, type setenv boot-device net:dhcp. Then a simple boot command or restarting the system are enough to boot onto the provisioning server 2. To force a network boot from the operating system, use this command:
/usr/platform/sun4u/sbin/eeprom boot-device=net:dhcp /usr/sbin/reboot
3. Alternatively, you can force a single network boot by using the following special string, that is recognized by the bootstrap code of the provisioning server
/usr/platform/sun4u/sbin/eeprom boot-device="net:dhcp was: disk" /usr/sbin/reboot
293
Results
You have now configured a Solaris machines so you can have a network boot on it.
Specifics for PowerPC targets on AIX and Linux

PowerPc targets have certain particularities associated with them.
DHCP
For detailed information on Dynamic Host Configuration Protocol (DHCP) see DHCP server requirements and configuration on page 296. Note: Microsoft DHCP server does not work well with some PowerPC firmware. Use the IBM recommended DHCP servers.
Booting
For detailed information about bootingIBM System p and booting CellBlades, see Booting IBM System p and Booting CellBlades on page 295.
Booting IBM System p

IBM System p machines can be booted on the OS deployment server.
Before you begin

Before you can boot a IBM System p target on the OS deployment server, you must: v Start an image installation on the target. Without a task bound to it, the target cannot boot on the OS deployment server. The way you can boot a IBM System p target on the OS deployment server depends on the operating system you want to install.
Procedure
v
AIX SUSE
To install AIX and SuSE 10:
1. Boot the target. 2. Type 1 to select SMS Menu. 3. Type 5 for Select Boot options. 4. Type 1 for Select Install/Boot Device. 5. Type 6 for Network. 6. Under Select device, select the network interface that you have registered in the OS deployment server. 7. Type 2 for Normal Mode Boot. 8. Type 1 (Yes) to confirm the above. v To install RedHat: 1. Boot the target. 2. Press 8 when booting to reach the Open Firmware prompt. 3. From an Open Firmware prompt, run boot net ks=http://<serverip>:<serverport>/linux/ks.cfg ksdevice=eth0 where <serverip> is the IP address of the OS deployment server, and <serverport> its port. Serverport is typically 8080.
Red Hat
294
Booting CellBlades
CellBlades can be booted on the OS deployment server. To boot on the OS deployment server:
Procedure
1. Boot the target. 2. Press 8 when booting to reach the Open Firmware prompt. 3. From an Open Firmware prompt, run boot net ks=http://<serverip>:<serverport>/linux/ks.cfg ksdevice=eth0 where <serverip> is the IP address of the OS deployment server, and <serverport> its port. Serverport is typically 8080.
Example
If the server IP is 192.168.1.25, and the server HTTP port is 8080, type the following line on the Open Firmware prompt:
boot net ks=http://192.168.1.25:8080/linux/ks.cfg ksdevice=eth0
Prerequisites for VMware targets

To be able to successfully deploy images on VMware, it is important to follow a number of prerequisites when setting up the VMware target. Guest operating system Always set the guest operating system that you intend to deploy, otherwise the deployment might fail. Network adapter v The Intel e1000 network adapter works properly on all Windows editions. v On Windows 64-bit, the AMD Lance network adapter is not supported. Using it results in a failed deployment with either a shutdown of the virtual machine or a blue screen. v The AMD Lance network adapter is supported for all Linux distributions, but it is very slow. v The Intel e1000 network adapter is supported on all Linux distributions, apart from Red Hat Enterprise Linux 5 (REHL5). With REHL5, the Intel e1000 card is in a dirty state when rebooting the operating system after performing Linprep. The target cannot connect to the network anymore. Therefore, the deployment stops and fails. To workaround this issue, install two network cards on your VMware target: The Intel e1000 as the primary boot device. An AMD Lance as the second boot device to use as a fallback. With the two cards, when Linux reboots and the Intel e1000 does not answer, the AMD Lance takes over, letting the virtual machine boot and the deployment continue. SCSI controller v For Windows XP, Windows XP SP1, Windows 2003, and Windows 2003 SP1, only BusLogic is supported. v On all other operating systems, LSI Logic is supported.
Discovering an OS deployment server

If you install a parent OS deployment server by rerunning the Tivoli Provisioning Manager installation, you must run a discovery configuration to discover your parent server or new unattended image.
295
To discover an OS deployment server: Attention: This discovery only discovers Tivoli Provisioning Manager for OS Deployment servers that were installed by Tivoli Provisioning Manager. It does not discover stand-alone Tivoli Provisioning Manager for OS Deployment servers.
Procedure
1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. Create a discovery configuration by clicking . 3. Specify a Name for your discovery configuration, select Software Discovery as the category, and TPMfOSD Installation Discovery as the Method, then click OK. 4. Your discovery configuration opens. In the Discovery Parameters section, specify the following information: Password The Java API password used for the Tivoli Provisioning Manager for OS Deployment installation. HTTP Server Port The HTTP server port that you specified for Tivoli Provisioning Manager for OS Deployment during installation. On Windows, the default value is 8080, and on UNIX, it is 8088. . 5. Click Save 6. Click Run Discovery. v If you need to discover your OS deployment server, select your Tivoli Provisioning Manager computer as your Target and click Submit. v If you need to discover images, select the computer where your OS deployment server is installed as your Target and click Submit.
Results
If you were searching for your OS deployment server, an object for it will now exist in the data model. If you need to discover images, the new images imported from the parent OS deployment server are in the Images page (Click Go To > Deployment > OS Management > Images. )
DHCP server requirements and configuration

Ensure that your DHCP server is correctly configured for operating system and virtual image management.
Requirements
There are no special product requirements for the DHCP server. If the DHCP server and the OS deployment server are running on the same target, the DHCP server must support the definition of the Class identifier DHCP option (option 60). Tivoli Provisioning Manager for OS Deployment can work with almost any RFC-compliant DHCP server, including Windows 2003 DHCP server, Windows 2000 DHCP server, ISC DHCP server, Solaris DHCP server, and the Netware 5 DHCP server. Note: 1. Because of the nature of PXE, you cannot run two PXE servers on the same computer. If you have installed another PXE boot tool such as Microsoft ADS, you must disable it before installing Tivoli Provisioning Manager for OS Deployment. 2. Microsoft DHCP server does not work well with some PowerPC firmware. If you have PowerPC targets in your environment, use an IBM recommended DHCP server.
296
Configuration
The DHCP server is used by the PXE bootrom to get its IP address and other basic networking information (including subnet mask, and default gateway). Using Tivoli Provisioning Manager for OS Deployment can require changes to your DHCP configuration. Typically, these changes can be performed automatically during the Tivoli Provisioning Manager for OS Deployment installation. However, in some cases, you might want to verify the changes, or perform them manually. You can configure your DHCP server for one of the following situations: v The DHCP server and the OS deployment server are not running on the same host. v The DHCP server and the OS deployment server are running on the same host. v You already have a PXE 2.0 infrastructure with PXE Boot Server discovery installed, and you want to add Tivoli Provisioning Manager for OS Deployment to the list of servers to discover. Note: v If you have previously configured your DHCP server for another PXE bootstrap, do not reuse your existing DHCP configuration. Remove DHCP options 43 and 60 for the hosts on which you want to run Tivoli Provisioning Manager for OS Deployment, and follow configuration instructions in this section. If you are running Tivoli Provisioning Manager for OS Deployment on the same computer as the DHCP server, you need to set option 60 again. v There are also cases where you must set both DHCP options 43 and 60, for example, when you have two different OS deployment servers.
Configuring the DHCP server

You can configure your DHCP server in several different ways. The following options are available: v The DHCP server and the OS deployment server are not running on the same host. v The DHCP server and the OS deployment server are running on the same host. v You already have a PXE 2.0 infrastructure with PXE Boot Server discovery installed and you want to add Tivoli Provisioning Manager for OS Deployment to the list of servers to discover.
Note: v If you have previously configured your DHCP server for another PXE bootstrap, do not reuse your existing DHCP configuration. Remove DHCP options 43 and 60 for the hosts on which you want to run Tivoli Provisioning Manager for OS Deployment, and follow the instructions given in this section. If you are running Tivoli Provisioning Manager for OS Deployment on the same host as the DHCP server, you need to set option 60 again. v There are also cases where you must set both DHCP options 43 and 60, for example, when you have two different OS deployment servers. Review the following information, select the case that suits your needs, and then perform the configuration steps. DHCP server and OS deployment server on different targets, with no information about the PXE server location Perform the following: v If DHCP options 43 and 60 are set, remove them. v If the DHCP server is not running on the same target as the OS deployment server, the DHCP configuration does not change. The OS deployment server detects DHCP packets sent over the network by PXE bootroms, and offers PXE parameters without disturbing the standard DHCP negotiation process. This behavior is called DHCPProxy.
297
DHCP server and OS deployment server on different targets, with information about the PXE server location Perform the following: v Set option 60 (Class identifier) to "PXEClient" to inform the target that the location of the PXE server is known. v Set option 43 to indicate that the PXE server does not reside on the same computer as the DHCP server, and to specify the location of the PXE server. DHCP server and OS deployment server on the same target Perform the following: v If DHCP option 43 is set, remove it. v Set option 60 (Class identifier) to "PXEClient" to inform the target that the location of the PXE server is known.
If you plan to run the DHCP server and the OS deployment server on the same target, you must instruct your DHCP server to send DHCP option 60 (Class identifier) to the targets. When option 60 is set to PXEClient, the DHCP server knows the location of the PXE server. If option 43 is not set, the PXE server has the same IP address as the DHCP server.
Configuring the DHCP option 60

Adding DHCP option 60 to Windows 2003 DHCP server: By default, option 60 is not set on Windows 2003. If the OS deployment server runs on the same host as the DHCP server, you must add this option and set its value to PXEClient in order to tell PXE clients where to find the OS deployment server. Procedure Open a command window. Enter netsh. Enter dhcp. Enter server \\hostname or server ip_address. A command prompt that says: dhcp server> is displayed. 5. Enter add optiondef 60 PXEClient STRING 0 comment=option added for PXE support. 6. Enter set optionvalue 60 STRING PXEClient. 7. To confirm that everything has been set correctly, enter show optionvalue all. 1. 2. 3. 4. Adding DHCP option 60 to a host with ISC DHCP server: If you use the ISC DHCP server 2.0, you can add the DHCP option 60 to a group of targets or to a single target by adding the statement option dhcp-class-identifier PXEClient ; to a section of the configuration file. If you use option 43 (vendor-encapsulated-options) for another PXE application, remove it for the Tivoli Provisioning Manager for OS Deployment targets. The changes to be made on a ISC DHCP server 3.0 are similar to those for a 2.0 server, but use different names: v Add vendor-class-identifier "PXEClient"; for the targets running Tivoli Provisioning Manager for OS Deployment. v Remove any occurrences of option space PXE; if you were running another PXE application. Note:
298
v The OS deployment server responds to all requests, including requests originating from unknown targets. v If the flag Completely ignore unknown targets is set for the server, it only responds to discovery requests originating from known targets. You can specify either the IP address or the Ethernet address in the target list. At this stage, the IP address of the remote-boot target is known.

Option 43 is a binary buffer that contains a list of suboptions, which are packed in the binary buffer in no specific order. Most suboptions are optional. An exhaustive list of suboptions can be found in the PXE specifications. Described below are only the suboptions that require the specification of the PXE server IP address. PXE option 6: PXE_DISCOVERY_CONTROL This option specifies how the PXE client contacts PXE servers, using either unicast, multicast, or broadcast. The format of this option is one byte. PXE option 8: PXE_BOOT_SERVERS A list of IP addresses, each address corresponding to one PXE server (when discovery_control is unicast). A PXE server is identified by a number (the standard value for Tivoli Provisioning Manager for OS Deployment is 15) and its IP address. The format of this option is two bytes for the server type (15 for Tivoli Provisioning Manager for OS Deployment), one byte for the number of servers to list (1 in our example), and four bytes per server address. PXE option 9: PXE_BOOT_MENU This option contains a list of choices to prompt on the screen at boot time. You need to have a PXE boot menu even if it is not used. The format of this option is two bytes for the server type, one byte for the length of the string to display, and the string to display on screen. The total length of this option is 5 bytes. PXE option 10 (0A): PXE_BOOT_TIMEOUT This option is required to specify how long (in seconds) the boot menu is displayed, and the text of a prompt that is displayed during waiting time. The format of this option is one byte for the timeout value, followed by the prompt text. PXE option 255 (FF): PXE_END To be valid, the binary buffer of DHCP option 43 must end in FF. Setting DHCP option 43: If your DHCP server runs on Windows NT, you can enter the suboption values one at a time in option 43, by selecting the hexadecimal input. If your DHCP server is ISC DHCP (version 2.x), you can enter the suboption values as provided in the examples (bytes separated with colons) for parameter vendor-encapsulated-options (the exact name depends on the version you are using). If your DHCP server is ISC DHCP (version 3.x), you can use an explicit syntax to describe the PXE options, as follows:
# In the global section: option space PXE; option PXE.discovery-control code 6 = unsigned integer 8; option PXE.boot-server code 8 = { unsigned integer 16, unsigned integer 8, ip-address }; option PXE.boot-menu code 9 = { unsigned integer 16, unsigned integer 8, text}; option PXE.menu-prompt code 10 = { unsigned integer 8, text };
299
# In the scope/host section: option dhcp-parameter-request-list 60,43; option vendor-class-identifier "PXEClient"; vendor-option-space PXE; option PXE.discovery-control 7; option PXE.boot-menu 15 5 "Rembo"; option PXE.menu-prompt 0 "Rembo";
Example: option 43 for PXE servers on different subnets: In this example, you have targets A and B boot on server 192.10.10.10, and targets C and D boot on server 192.10.11.10, which is on a different subnet (a valid gateway must be set up for C and D in order to locate the PXE server on a different subnet). Note: Server type 15 is translated into 00:0F in hexadecimal. IP address 192.10.10.10 is translated into C0:0A:0A:0A, and 192.10.11.10 is translated into C0:0A:0B:0A. Letters R and B are translated into 52 and 42. The following are the options that must be inserted in the binary buffer and their values: PXE option 6, length 1, value=07 Value 07 means use PXE_BOOT_SERVERS list, disable multicast and broadcast discovery. PXE option 8, length 7, value = 00:0F:01:C0:0A:0A:0A (targets A and B) Only one IP address is used, the address of the PXE server for the target which receives these DHCP options. PXE option 8, length 7, value = 00:0F:01:C0:0A:0B:0A (targets C and D) Only one IP address is used, the address of the PXE server for the target which receives these DHCP options. PXE option 9, length 5, value = 00:0F:02:52:42 There is only one line, displaying RB, and which goes to server type 15 (Tivoli Provisioning Manager for OS Deployment). PXE option A, length 2, value=00:52 The timeout is set to 0 seconds, meaning that one wants to boot using the first line of the boot menu, and the prompt is set to R. Because the timeout is 0, the prompt text is not displayed, but it must be at least one character long. PXE option FF This closes the buffer. The format of the binary buffer is similar to what is used for the DHCP packet itself. The buffer is a list of options, each option starting with its option number (one byte), followed by its length (one byte), and its value (a list of bytes). Here is the transcription of the above example, for targets A and B:
Option 43 = 06:01:07:08:07:00:0F:01:C0:0A:0A:0A:09:05:00:0F:02:52:42:0A:02:00:52:FF
And for targets C and D:

Option 43 = 06:01:07:08:07:00:0F:01:C0:0A:0B:0A:09:05:00:0F:02:52:42:0A:02:00:52:FF
Example: option 43 to create a PXE boot menu: The administrator wants to display two lines in the PXE boot menu, pointing to two separate OS deployment servers. The two servers must use different PXE server type numbers or they will be seen as one server only by the PXE network card.
300
In addition to the standard PXE server type 15, OS deployment servers accept any number between 33008 (80F0 in hexadecimal) and 33280 (8200 in hexadecimal). These new PXE server type numbers are used to differentiate multiple OS deployment servers in the BOOT_SERVERS sub-option of DHCP option 43. In this example, the first server has the address 192.168.1.4 (C0:A8:01:04 in hexadecimal), and the second server 192.168.1.5 (C0:A8:01:05 in hexadecimal). Procedure 1. Assign an OS deployment server type to each of the servers. OS deployment servers accept server type 15, and server types from 33008 to 33280. For this example, 33008 (80F0) is used for the first server, and 33009 (80F1) for the second server. 2. The suboptions of DHCP option 43 must then be configured as follows: PXE option 6, length 1, value=07 Value 07 means use PXE_BOOT_SERVERS list, disable multicast and broadcast discovery PXE option 8, length 14 (0E), value = 80:F0:01:C0:A8:01:04:80:F1:01:C0:A8:01:05 Option 8 defines the two PXE servers. The first server is defined by the first 7 bytes, starting with the OS deployment server type (80:F0, 33008), followed by one IP address: C0:A8:01:04 (192.168.1.4). The second server is defined as follows, using OS deployment server type 80:F1 (33009). PXE option 9, length 22 (16), value = 80:F0:08:53:65:72:76:65:82:20:41:80:F1:08:53:65:72:76:65:82:20:42 Option 9 defines the boot menu that is displayed at boot time. The first 11 bytes correspond to the first line, for the first server. It shows the string Server A, associated with type 80:F0 (first server). The second line shows the string Server B, associated with type 80:F1 (second server). PXE option 9, length 5, value = 00:0F:02:52:42 (targets C and D) Only one IP address is used, the address of the PXE server for the target which receives these DHCP options. PXE option A, length 6, value =0F:53:65:6C:65:63:74 Option 10 (0A) specifies a 15 second timeout and shows the string Select as the boot menu prompt. PXE option FF This closes the buffer The full option 43 reads as follows:
06:01:07:08:0E:80:F0:01:C0:A8:01:04:80:F1:01:C0:A8:01:05: 09:16:80:F0:08:53:65:72:76:65:82:20:41:80:F1:08:53:65:72:76:65:82:20:42: 0A:06:0F:53:65:6C:65:63:74:FF
Tutorial: Managing operating systems

Flexible options are available to manage operating systems, install operating system software, and capture and restore disk images. This tutorial provides an introduction to image management on Windows and Linux on Intel and focusses on Tivoli Provisioning Manager for OS Deployment integration with Tivoli Provisioning Manager. There are several situations in which you might need to deploy an image to a system, such as adding a new system to your enterprise, or restoring computers that have been affected by a hardware component repair or a virus.
301
When you use the image management, target computers are connected to the boot server during the start phase and begins installing the operating system through the network. The operating system is installed by using images created from the boot server. This tutorial uses Windows computers to describe image management but the same overall process applies to deployment on Linux on Intel computers.
Learning objectives
The learning objectives for the scenario are: v Learn how to capture an image and configure image properties. v Learn how to create a software module and binding it to an image. v Learn how to install an image.
Considerations
The Tivoli Provisioning Manager for OS Deployment Intel boot server sends PXE responses when there is DHCP traffic between the client computer and the DHCP server. A computer restarted for the first time since the Tivoli Provisioning Manager for OS Deployment boot server is installed is registered to Tivoli Provisioning Manager for OS Deployment with PXE boot option to start on hard-disk if idle. This option is set so that when a computer starts the Tivoli Provisioning Manager for OS Deployment boot server, if there are no pending activities, it starts from the hard disk drive. An isolated network is recommended for testing the Tivoli Provisioning Manager for OS Deployment boot server. An isolated network means that only the computers you are using for this test receives PXE responses from the Tivoli Provisioning Manager for OS Deployment. Consider the following before installing the Tivoli Provisioning Manager for OS Deployment boot server in your production network: v Are there other Intel boot servers deployed on the network? Is it necessary to check with the IT support group first? Both the Tivoli Provisioning Manager for OS Deployment and the other Intel boot server send PXE responses and might cause a conflict if the other Intel boot server has an imaging operation and the Tivoli Provisioning Manager for OS Deployment PXE response is received first to start from hard-disk. v Are there production or important Intel servers on the network that you do not want to interfere with the start by making sure that you have the correct Tivoli Provisioning Manager for OS Deployment configuration?
Prerequisites
Before you start, you need the following: v The Tivoli Provisioning Manager for OS Deployment automation package must be installed. It is installed by default during Tivoli Provisioning Manager installation. If you need to install it manually, see the Tivoli Provisioning Manager Installation Guide. v A DHCP server and a DNS server. For details about these requirements, see the Tivoli Provisioning Manager Installation Guide. The DHCP server is configured to reserve an IP address for the MAC address of the computers for capture and install image. Also, the Tivoli Provisioning Manager for OS Deployment computer, DHCP server, and Tivoli Provisioning Manager for OS Deployment server requires a static IP address assigned to them.
302
The network interface of the Tivoli Provisioning Manager computer does not have the attribute Dynamic IP address set and the IP address matches the DHCP reserved IP address. v A client computer to install the image on, and a computer for installing Tivoli Provisioning Manager for OS Deployment. For more information about the requirements for these computers, see Server system requirements on page 280 and Target system requirements on page 281. v Available ports. By default, the Tivoli Provisioning Manager for OS Deployment boot server uses the following ports for communication: DHCP: port 67 UDP PXE BINL: port 4011 UDP TFTP: port 69 UDP MTFTP: port 4015 UDP NBP: port 4012 UDP FILE: port 4013 UDP and TCP MCAST: port 10000-10500 UDP Address: 239.2.0.1 - 239.2.1.1 On the clients, the default ports are the following: DHCP: port 68 UDP MTFTP: port 8500-8510 UDP Address: 232.1.0.1 MCAST: port 9999 UDP Remote control (Web Interface Extension): port 4014 UDP These ports can all be modified, with one notable exception which is port 69 for TFTP. Port 69 is part of the PXE specifications, independently of the Tivoli Provisioning Manager for OS Deployment product and thus cannot be modified. Any product using PXE boot needs to have this port open to permit PXE boot. Note that this port needs to be open only on the Tivoli Provisioning Manager for OS Deployment boot server, not on the client machines. v Microsoft System Preparation tool (Sysprep). The Microsoft System Preparation file is a tool that helps you to automatically deploy images on multiple computers. Before you actually capture the image from the client computer, the capture image provisioning workflow copies and runs the Sysprep files to prepare the computer for cloning. The install image provisioning workflow uses Sysprep to personalize the target computer by setting Windows attributes. For all Windows platforms, before you proceed with the image capture, you can select the Sysprep check box to enable Tivoli Provisioning Manager to run Sysprep automatically, or you can clear the check box to run Sysprep yourself, manually. See the following options and the Preparing the reference computer on page 311 section for more information about preparing the reference computer:
Windows
Running Sysprep automatically By default, Tivoli Provisioning Manager can run Sysprep automatically on all Windows 2008, Windows 2008R2, Windows 7, and Windows Vista platforms. Running Sysprep manually For Windows platforms that are not supported by Tivoli Provisioning Manager, or if you would like to specify more parameters for running Sysprep, clear the Sysprep check box and then run Sysprep yourself.
Part 1: Creating an image

In this part, you will learn how to create several types of images. The main purpose of Tivoli Provisioning Manager for OS Deployment is to deploy an operating system on targets by replicating a reference system. However, unattended installation of operating systems is also possible. The latter case does not replicate a reference system, but merely provides the correct parameters to Windows or UNIX setup for a fully unattended installation.
303
There are a number of differences between an unattended installation and disk cloning. Creating an unattended installation typically involves creating the image from reference media such as an installation CD. All of the necessary tasks are performed on the server, using the Web interface. In contrast, a captured image requires you to configure a target, prepare it for capture. In this part, you will learn how to: v Synchronize images v Create an unattended setup image v Add an existing Windows WIM or Solaris Flash archive image to the database so that you can manage and deploy it. v Capture a Windows or Linux image v Create a Point-In-Time snapshot The BIOS startup sequence of the computer you capture the image from must first have network and then hard disk for this install task to complete successfully.
Synchronizing images
The Provisioning Configuration Librarian runs an image synchronization periodically, to update the Tivoli Provisioning Manager data model with the latest Tivoli Provisioning Manager for OS Deployment images (golden master, point-in-time snapshot, hardware configuration, unattended setup) or Tivoli Provisioning Manager for Images virtual images. The image synchronization discovers Tivoli Provisioning Manager for OS Deployment images or snapshots of Tivoli Provisioning Manager for Images virtual images and creates image objects for them in the Tivoli Provisioning Manager data model. Once discovered, these images can then be deployed to virtual or physical machines. To synchronize images:
Procedure
1. Click Go To > Deployment > OS Management > Images. 2. Click Select Action > Tivoli Provisioning Manager for OS Deployment > Synchronize images with the boot server. The Provisioning Task Tracking application displays the current status of the task. When the provisioning task has started, you can monitor its progress on this page. From the Select Action menu, click Refresh to update the page.
Results
All the images are now discovered in Tivoli Provisioning Manager, and image objects are added to the data model for them. Note: Before deployment, all imported or discovered virtual images must have SAP and credential information added, so that they can be used on the target computers. For more information, see Adding credentials to virtual images on page 430
Creating an unattended setup

In this lesson, you will learn how to install operating systems using standard installation processes in unattended mode. Creating an unattended setup for Windows: You can install operating systems using standard installation processes in unattended mode.
304
Vista
2008
v To create an unattended Windows Vista or Windows 2008 image, you must be using a source computer (that is, the computer that contains the OS media you are going to create an image from) with a 32-bit architecture running the web interface extension under one of the following operating systems: Windows Windows Windows Windows 2003 XP Vista 2008
Creating this type of image is not possible on a Windows 2000 operating system. You can, however, use any kind of machine (for example, a Linux operating system machine) to actually create the unattended setup image as long as Tivoli Provisioning Manager for OS Deployment is installed on it. The source computer only needs the web interface extension on it. For instructions on how to manually install the web interface extension see: Installing and uninstalling the web interface extension on page 384 v The web interface extension must be started with local administrator privileges. When you create a hardware environment, the web interface extension must be running from the command line instead of as a Windows service. If you are running the web interface extension as a Windows service, perform the following steps to run it from the command line: 1. At the command line, run the following command to stop the service:
net stop remboagent
2. Change to the Tivoli Provisioning Manager for OS Deployment directory for the web interface extension. The default location is C:\Program Files\Common Files\IBM Tivoli 3. Run the following command to run the web interface extension from the command line:
rbagent -d
v Creating an unattended Windows Vista or Windows 2008 installation image is possible only for users that have separately obtained the MicrosoftWindows Automated Imaging Kit (WAIK) 32-bit and installed it on the computer running the Web interface extension. Reboot your computer after installing the WAIK. The WAIK is licensed to you by the code's owner and not by IBM. v Creating an unattended Windows Vista or Windows 2008 installation image with multiple CD-ROMs is not supported. You are required to use a single DVD-ROM. v You can prepare your image to be ready for Microsoft BitLocker Drive Encryption (BitLocker). You must have at least two partitions: A partition of at least 1.5 GB is necessary to hold BitLocker and to server as a boot partition A second partition holds the operating system Depending on the number of partitions already created, the Profile Wizard offers to reserve one of the existing partitions for BitLocker, or to create a new one.
2003 The Windows 2003 R2 operating system is distributed on two CD-ROMs. To create a fully deployable unattended image of Windows 2003 R2, you must: 1. Create an image using the first CD-ROM only, following the steps in the wizard; 2. Create a software module with the content of the second CD-ROM (see Creating a software module for unattended deployment of Windows 2003 R2 on page 343). 3. Bind this software module (with an automatic binding rule) to the image you just created (see Automatic binding rules on page 347).
To create an unattended setup image: 1. Click Go To > Deployment > OS Management > Unattended Setup Image. 2. Select Unattended setup in the first pane of the wizard and click Next. 3. Select your operating system from the list and click Next.
305
4. Follow the instructions of the wizard. Note: Do not close the browser when the image is being uploaded. If you do, the upload might be cancelled. 5. You will have to choose the computer where the material to create your unattended setup image can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension. You have now created an unattended setup image for Windows. When the wizard closes, the Tasks view will open, and a workflow that discovers the newly created image is run. Note: If the wizard does not exit properly (for example, the browser times out instead of you clicking Finish), the image is still created, but the workflow that discovers the image is not run. In order to discover your images, you must create and run a discovery configuration against your parent OS deployment server: Discovering an OS deployment server on page 295. When your first unattended installation image is created, you can use it to deploy targets. Note: If you want to modify the browser timeout value, follow these steps: Changing the automatic logoff setting. Creating an unattended setup for AIX: An unattended setup allows you to install operating systems using standard installation processes in unattended mode. To create an AIX unattended setup, you must work on an AIX operating system of the same version as the image you want to create. 1. Copy the AIX installation CD-ROM or DVD-ROM on the hard disk. 2. Export the path of the folder in which you have copied the installation files by NFS. This folder must have write permissions. a. Verify that NFS is already running by typing the command lssrc -g nfs. The output must indicate that the nfsd and the rpc.mountd daemons are active. If they are not, you must start the NFS daemons. b. At a command line, enter smit mknfsexp. c. Specify appropriate values in the fields: Pathname of directory to export Mode to export directory, and Export directory now, system restart or both. d. Specify any other optional characteristics you want, or accept the default values by leaving the remaining fields as they are. e. When you have finished making your changes, SMIT updates the /etc/exports file. If the /etc/exports file does not exist, it is created. 3. 4. 5. 6. f. Repeat steps a through e for each directory you want to export. Click Go To > Deployment > OS Management > Unattended Setup Image. Select Unattended setup in the first pane of the wizard and click Next. Select your operating system from the list and click Next. Follow the instructions of the wizard.
306
Note: Do not close the browser when the image is being uploaded. If you do, the upload might be cancelled. You have now created an unattended setup image for AIX. When the wizard closes, the Tasks view will open, and a workflow that discovers the newly created image is run. Note: If the wizard does not exit properly (for example, the browser times out instead of you clicking Finish), the image is still created, but the workflow that discovers the image is not run. In order to discover your images, you must create and run a discovery configuration against your parent OS deployment server: Discovering an OS deployment server on page 295. When your first unattended installation image is created, you can use it to deploy targets. Note: If you want to modify the browser timeout value, follow these steps: Changing the automatic logoff setting. Although the all the files on the installation media were necessary for the image creation, only some are needed at deployment time. If you want to delete superfluous files, make sure NFS_install points to Install/PPC. You can then delete the content of other installation directories. Creating an unattended setup for Linux on Intel: To create an unattended setup image: 1. Click Go To > Deployment > OS Management > Unattended Setup Image. 2. Select Unattended setup in the first pane of the wizard and click Next. 3. Select your operating system from the list and click Next. 4. Follow the instructions of the wizard. Note: Do not close the browser when the image is being uploaded. If you do, the upload might be cancelled. 5. You will have to choose the computer where the material to create your unattended setup image can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension. You have now created an unattended setup image for Linux on Intel. When the wizard closes, the Tasks view will open, and a workflow that discovers the newly created image is run. Note: If the wizard does not exit properly (for example, the browser times out instead of you clicking Finish), the image is still created, but the workflow that discovers the image is not run. In order to discover your images, you must create and run a discovery configuration against your parent OS deployment server: Discovering an OS deployment server on page 295. When your first unattended installation image is created, you can use it to deploy targets. Note: If you want to modify the browser timeout value, follow these steps: Changing the automatic logoff setting.
307
Creating an unattended setup image for Linux on PowerPC: To create an unattended setup image: 1. 2. 3. 4. Click Go To > Deployment > OS Management > Unattended Setup Image. Select Unattended setup in the first pane of the wizard and click Next. Select your operating system from the list and click Next. Follow the instructions of the wizard.
Note: Do not close the browser when the image is being uploaded. If you do, the upload might be cancelled. 5. You will have to choose the computer where the material to create your unattended setup image can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension. You have now created an unattended setup image for Linux on PowerPC. When the wizard closes, the Tasks view will open, and a workflow that discovers the newly created image is run. Note: If the wizard does not exit properly (for example, the browser times out instead of you clicking Finish), the image is still created, but the workflow that discovers the image is not run. In order to discover your images, you must create and run a discovery configuration against your parent OS deployment server: Discovering an OS deployment server on page 295. When your first unattended installation image is created, you can use it to deploy targets. Note: If you want to modify the browser timeout value, follow these steps: Changing the automatic logoff setting. Creating an unattended setup image for Solaris: For Solaris 9, unattended setup is only supported if you are creating your unattended setup image from a Solaris flash archive. For instructions on how to do this, see: Creating an unattended setup image from a Solaris Flash archive on page 310. To create an unattended setup image: 1. Click Go To > Deployment > OS Management > Unattended Setup Image. 2. Select Unattended setup in the first pane of the wizard and click Next. 3. Select your operating system from the list and click Next. 4. Follow the instructions of the wizard. Note: Do not close the browser when the image is being uploaded. If you do, the upload might be cancelled. 5. You will have to choose the computer where the material to create your unattended setup image can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension.
308
You have now created an unattended setup image for Solaris. When the wizard closes, the Tasks view will open, and a workflow that discovers the newly created image is run. Note: If the wizard does not exit properly (for example, the browser times out instead of you clicking Finish), the image is still created, but the workflow that discovers the image is not run. In order to discover your images, you must create and run a discovery configuration against your parent OS deployment server: Discovering an OS deployment server on page 295. When the wizard for a Solaris unattended installation completes, it automatically makes changes to the boot system under /export/install/solxx/Solaris_xx/Tools/Boot (where xx depends on your version of Solaris) to use autoconfiguration. However, the boot system remains fully compatible with the standard Solaris installation process. Any installation not started with rembo.fcode as the boot file name behaves in the traditional Solaris way. When your first unattended installation image is created, you can use it to deploy targets. Note: If you want to modify the browser timeout value, follow these steps: Changing the automatic logoff setting. Creating an unattended setup for VMWare ESX 3.5: To create a unattended setup image for VMWare ESX 3.5, you must download the binary entitled ESX Server 3.5 Update 2 CD image (596 MB). Creating the image from ESX Server 3i U2 Installable (238 MB) will result in a failed deployment. To create an unattended setup image: 1. Click Go To > Deployment > OS Management > Unattended Setup Image. 2. Select Unattended setup in the first pane of the wizard and click Next. 3. Select your operating system from the list and click Next. 4. Follow the instructions of the wizard. Note: Do not close the browser when the image is being uploaded. If you do, the upload might be cancelled. 5. You will have to choose the computer where the material to create your unattended setup image can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension. You have now created an unattended setup image for VMWare ESX 3.5. When the wizard closes, the Tasks view will open, and a workflow that discovers the newly created image is run. Note: If the wizard does not exit properly (for example, the browser times out instead of you clicking Finish), the image is still created, but the workflow that discovers the image is not run. In order to discover your images, you must create and run a discovery configuration against your parent OS deployment server: Discovering an OS deployment server on page 295. When your first unattended installation image is created, you can use it to deploy targets.
309
Note: If you want to modify the browser timeout value, follow these steps: Changing the automatic logoff setting. Creating an unattended setup image from a Windows Imaging Format (WIM) image: Windows Imaging Format (WIM) is a file-based disk image format. It can be used to deploy Windows operating systems. You can use the Create Unattended Setup Image wizard to create a WIM image using Tivoli Provisioning Manager for OS Deployment. v To add a Windows WIM image, you must be using a computer with a 32-bit architecture running the web interface extension under Windows XP, Windows 2003, Windows Vista or Windows 2008. The web interface extension must be started with local administrator privileges. Creating this type of image is not possible on Windows 2000. v To deploy a Windows WIM image, a WinPE 32-bit software module, with the same build number as the Windows WIM image, is mandatory. You must bind the software module to your Windows Vista or Windows 2008 profile. If you do not have an WinPE software module on your provisioning server, the profiles wizard guides you to create one now. See Creating a software module for custom actions on Windows on page 341 to create the required software module at a later time. v Creating a Windows WIM image is possible only for users that have separately obtained the Microsoft Windows Automated Imaging Kit (WAIK) 32-bit and installed it on the computer running the web interface extension. The WAIK is licensed to you by the code's owner and not by IBM. v Creating an unattended setup image from a Windows WIM image stored on multiple CD-ROMs is not supported. You are required to use a single DVD-ROM. v You can prepare your profile to be ready for Microsoft BitLocker Drive Encryption (BitLocker). You must have at least two partitions: A partition of at least 1.5 GB is necessary to hold BitLocker and to serve as a boot partition A second partition holds the operating system Depending on the number of partitions already created, the unattended setup wizard offers to reserve one of the existing partitions for BitLocker, or to create a new one. To create an image: 1. Click Go To > Deployment > OS Management > Unattended Setup Image. 2. Select Cloning from a reference image file and click Next. 3. Select Windows Vista/2008 WIM image and click Next. 4. Follow the instruction of the wizard. 5. You will have to choose the computer where the material to create your unattended setup image can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension. You have now created an unattended setup image from a WIM image. When the wizard closes, the Tasks view will open, and a workflow that discovers the newly created image is run. Note: If the wizard does not exit properly (for example, the browser times out instead of you clicking Finish), the image is still created, but the workflow that discovers the image is not run. In order to discover your images, you must create and run a discovery configuration against your parent OS deployment server: Discovering an OS deployment server on page 295. Creating an unattended setup image from a Solaris Flash archive:
310
You can create an image from a Solaris Flash archive (a file with a .flar extension). To be able to create your image, you need a Solaris Flash archive on your NFS server and the complete installation files for a Solaris operating system. When you create an image, you will be prompted for the directory in which the operating system installation files are located. The wizard checks for the .cdtoc hidden file before asking you for the exact location of the Flash Archive you want to use for your image. Note: There might be installation specific issues with Flash archives. In particular, some symbolic links might prevent flash archives to be restored properly. As a workaround, remove the symbolic links and copy the actual files in the appropriate directory. Although Tivoli Provisioning Manager for OS Deployment is not involved in the creation of Flash archives, the process is described for convenience. For more information, refer to SUN Solaris documentation. 1. Mount the flash archive directory on the install server. a. Create a local mount point, a directory that you can reference locally.
mkdir /export/flash
b. Mount the remote flash archive directory

mount certdev-sun2:/export/flars /export/flash
2. Run the flash archive creation command

flarcreate -n flarname.flar -x /export/flash -c /export/flash/flarname.flar
3. Restart the computer to make sure that all unnecessary file handles are closed. 4. Check that the new flash archive is created and sent to the Flash directory of the Solaris install server. To create an image: 1. Click Go To > Deployment > OS Management > Unattended Setup Image. 2. Select Cloning from a reference image file and click Next. 3. Select Solaris Flash Archive and click Next. 4. Follow the instruction of the wizard. You have now created an unattended setup image from a Solaris Flash archive. When the wizard closes, the Tasks view will open, and a workflow that discovers the newly created image is run. Note: If the wizard does not exit properly (for example, the browser times out instead of you clicking Finish), the image is still created, but the workflow that discovers the image is not run. In order to discover your images, you must create and run a discovery configuration against your parent OS deployment server: Discovering an OS deployment server on page 295.
Creating a golden master image

In this lesson, you will set up a reference computer and then capture a golden master image. A golden master image is a depersonalized boot device image that is be used for deployment on multiple computers using some configuration files that would personalize the image for the target computers. An image entry is added to the Tivoli Provisioning Manager image list for every operating system configuration in Tivoli Provisioning Manager for OS Deployment. As more than one operating system configuration can be defined for one system profile, more Tivoli Provisioning Manager images can be displayed for it. Preparing the reference computer: Before you capture an image, prepare the source computer so that the image is as clean as possible.
311
You must perform this task directly on the source computer that you are using to capture the image. v Delete the temporary Internet cache. v Delete temporary directories and files. v Disconnect network drives and remote printers. v Empty the recycle bin. v If necessary, partition the hard disk or format partitions. When partitioning your hard disk, ensure that there is enough space to store its temporary image files when it is deploying an image. If you ensure that the last partition of your hard disk is at least 1 GB in size, or if you leave a similar amount of free (unpartitioned) space at the end of your hard disk, you must have enough space. Tivoli Provisioning Manager for OS Deployment can store temporary files in both the unpartitioned space at the end of the hard disk and the free space at the end of the last partition. The sum of these areas must be large enough for storing all partition images that will be deployed at the same time on the target computer and must typically be about half of the size of the data on the hard disk (for example, 1 GB if your OS partition contains about 2 GB of data). Additional Windows requirements Sysprep must be run (automatically or manually) for all Windows platforms before an image capture. For more information about this task, see Windows Microsoft System Preparation tool (Sysprep) in Running Sysprep automatically. Linux considerations When preparing a Linux image, there are two main issues: the space for the temporary cache partition and the bootloader. You must ensure that the partitioning scheme provides enough space for the temporary cache partition during deployment. The sum of the space in the last partition and the unpartitioned space must be large enough to hold all partition images. This is the case most of the time, except with a few distributions that put the Linux swap partition at the end of the disk by default. Ensure that your swap partition is not at the end of the disk when preparing a Linux image. The Linux bootloader is also important. Tivoli Provisioning Manager for OS Deployment supports only Grand Unified Bootloader (GNU GRUB). You can install GRUB on the bootsector of the Linux /boot partition or on the root partition. If you plan to use redeployment, it is mandatory to install GRUB in the boot sector of the Linux /boot partition. To start your system correctly with GRUB, ensure that you have a standard MBR on the disk, with the boot partition flagged as bootable. For creating a golden master image, Tivoli Provisioning Manager for OS Deployment automatically installs and runs its own system preparation tool, LinPrep. Running Sysprep automatically: For all Windows platforms, before you proceed with the image capture, you can select the Sysprep check box to enable Tivoli Provisioning Manager to run Sysprep automatically, or you can clear the check box to run Sysprep yourself, manually. By default, Tivoli Provisioning Manager can run Sysprep automatically on all Windows 2008, Windows 2008R2, Windows 7, and Windows Vista platforms. To enable Tivoli Provisioning Manager to run Sysprep automatically on all Windows platforms other than Windows 2008, Windows 2008R2, Windows 7, and Windows Vista, you must first manually copy over the Microsoft Sysprep files to the Tivoli Provisioning Manager repository. The Sysprep tool is located on your Windows version CD-ROM in the Support\Tools\deploy.cab file. A version can also be downloaded for free from the Microsoft Web site. Use the latest service pack level of the operating system release you use. For example, if you have Windows Server 2003 SP1 and SP2
312
computers, then use Sysprep for Windows Server 2003 SP2, if available from Microsoft. After you have found the tool, extract the cab file and place the files sysprep.exe, and setupcl.exe into the %TIO_HOME%/repository/windows-operating-system/Windows_subdirectory. The Windows_subdirectory file name includes the operating system that you are using and the appropriate bit size (32-bit or 64-bit): v win2k/32-bit: Windows 2000 32-bit v win2k/64-bit: Windows 2000 64-bit v win2k3/32-bit: Windows 2003 32-bit v win2k3/64-bit: Windows 2003 64-bit v winxp/32-bit: Windows XP 32-bit v winxp/64-bit: Windows XP 64-bit Note: Check the sizes of files sysprep.exe and setupcl.exe in the Tivoli Provisioning Manager repository subdirectories of win2k, win2k3, and winxp against the source location where you copied these files from. If the incorrect Windows operating system release of these files are copied into a subdirectory, then Sysprep fails to run during capture image with no restarting of the computer for Tivoli Provisioning Manager for OS Deployment to start capturing the image. Running Sysprep on Windows Vista and Windows 2008: Before capturing your image, run Sysprep to prepare the reference computer. Tivoli Provisioning Manager for OS Deployment works with Sysprep to automate the post-cloning reconfiguration. Sysprep cannot be used on targets that are part of a domain. The system profile image must be made on a target that does not belong to a domain. Even if your operating system was part of the domain before you launched Sysprep, Sysprep removes it from the domain. Later, you can automatically join a domain during the deployment process. Before running Sysprep, you must configure your target to use DHCP. If your target uses a static IP address, you have a high risk IP conflicts when the target boots for the first time and it has not yet applied all Sysprep settings. With Windows Vista and Windows 2008, you can run Microsoft System Preparation Tool (Sysprep) on the operating system only three times. After that, the Sysprep tool refuses to start, therefore always start from your original reference image. To work around this issue, you can also use a virtual machine. Sysprep is available on every installed Windows Vista and Windows 2008 operating system. The Sysprep executable file is archived in c:\windows\system32\sysprep\sysprep.exe. To start the Sysprep process, follow these instructions: Important: Tivoli Provisioning Manager for OS Deployment provides a fully automated solution to capture Windows Vista and Windows 2008 images from a reference computer. However, due to various problems in the Sysprep tool, the Tivoli Provisioning Manager for OS Deployment automation package cannot provide a reliable solution to restore an OS configuration to its original state on a reference computer. Since a minimal set of configuration parameters are used inside a sysprep response file, the OS configuration might change on a reference computer. If the OS configuration changes system administrators must manually restore various settings such as: v Network configuration v Domain membership v Windows Firewall configuration v Microsoft Update v Microsoft AntiSpyware tools v User profiles
313
Configuration of virtual network adapters, virtual drives, and network shares might also be affected by the sysprep tool. Creating a backup of these configurations is highly recommended. 1. Log on as a user with administrator privileges. 2. Close any open applications and type the run command in the Windows Vista or Windows 2008 Start Search command prompt. 3. When the run command prompt opens, browse to the Sysprep executable file and click OK. A System Preparation Tool page opens. 4. 5. 6. 7. From the System Cleanup action menu, select Enter System Out-of-Box Experience (OOBE). Select the Generalize check box. From the Shutdown Options menu, select Shutdown. Click OK. After a few seconds, your system shuts down automatically. Alternatively, you can specify these options when launching Sysprep from the command line prompt by running the command: c:\windows\system32\sysprep\sysprep.exe /oobe /generalize /shutdown. Note: v Sysprep can also be used in audit mode. In audit mode, when the user first boots the deployed machine, the boot process does an Out-Of-Box Experience (OOBE) stage which finalizes the OS configuration taking connected peripherals into account. This OOBE stage takes about 10 minutes. If Sysprep is used in OOBE mode, this stage is performed during deployment without significantly increasing the deployment time. v It is possible to have a partition dedicated to Microsoft BitLocker Drive Encryption (BitLocker). If the reference computer you are cloning is BitLocker ready, running Sysprep prevents it to boot anymore.Tivoli Provisioning Manager for OS Deployment can correct this error and allow the computer to boot again by assigning the operating system partition as boot partition. However, if you want to use BitLocker on the reference target afterward, you need to manually change the boot partition back to the BitLocker partition. Tivoli Provisioning Manager for OS deployment properly configures boot and root partitions on deployed computers. Thus, computers deployed with an image cloned from a BitLocker ready computer are perfectly bootable and BitLocker ready. If the reference computer is not BitLocker ready, running Sysprep does not raise any difficulty. With the Profile Wizard, you can make the cloned image BitLocker ready by assigning or creating a BitLocker partition of at least 1.5 GB. Running Sysprep on Windows XP and Windows 2003: Before capturing your image, run Sysprep to prepare the reference computer. Tivoli Provisioning Manager for OS Deployment works with Sysprep to automate the post-cloning reconfiguration. Sysprep cannot be used on targets that are part of a domain. The system profile image must be made on a target that does not belong to a domain. Even if your operating system was part of the domain before you launched Sysprep, Sysprep removes it from the domain. Later, you can automatically join a domain during the deployment process. Before running Sysprep, you must configure your target to use DHCP. If your target uses a static IP address, you have a high risk IP conflicts when the target boots for the first time and it has not yet applied all Sysprep settings. Depending on how Windows was installed, you might never have logged on as an administrator. If this is the case, log out and log in again as an administrator to ensure that the administrator profile is correctly created. Otherwise, you might not be able to create system snapshots affecting the administrator settings.
314
Sysprep for Windows XP is included on the Windows XP Professional CD-ROM, and archived in the file \Support\Tools\Deploy.cab. To 1. 2. 3. run Sysprep: Copy the Sysprep executable files into a folder named c:\sysprep. Close all your applications. Run the command c:\sysprep\sysprep.exe -mini -forceshutdown -reseal from the Start > Run menu. Alternatively, you can start Sysprep with a graphical user interface by double-clicking on its icon a. Make sure that Mini Setup is checked b. Click Reseal. Your system shuts down automatically after a few seconds. Running Sysprep on Windows 2000: Before capturing your image, run Sysprep to prepare the reference computer. Tivoli Provisioning Manager for OS Deployment works with Sysprep to automate the post-cloning reconfiguration. Sysprep cannot be used on targets that are part of a domain. The system profile image must be made on a target that does not belong to a domain. Even if your operating system was part of the domain before you launched Sysprep, Sysprep removes it from the domain. Later, you can automatically join a domain during the deployment process. Before running Sysprep, you must configure your target to use DHCP. If your target uses a static IP address, you have a high risk IP conflicts when the target boots for the first time and it has not yet applied all Sysprep settings. Sysprep for Windows 2000 is included in Windows 2000 Resource Kit, and is also available for free on the Microsoft Web site. 1. Copy the Sysprep executable files into a folder named c:\sysprep. 2. Close all your applications. 3. Run the command sysprep.exe from the Start > Run menu. Your system shuts down automatically after a few seconds (if it does not, wait a minute or so and then turn it off). Capturing a golden master image: After you have prepared the reference computer, you can capture the image. If the computer that you are capturing the image from does not have the following settings, the capture image provisioning task will fail: v Ensure that the network interface with Dynamic IP Address set has the computer name in DNS, so that the Tivoli Provisioning Manager computer will find the IP address from the DNS server. v The BIOS startup sequence must first have network and then hard disk for this computer. v Ensure that Tivoli Provisioning Manager can manage the target computer (it has credentials and can execute commands) and that the target computer is running. Tivoli Provisioning Manager will restart the target computer. The target computer must be set to boot from the network and it will PXE boot off the Tivoli Provisioning Manager for OS Deployment server. For details, see Network resource discovery on page 154 and Tivoli Provisioning Manager for OS Deployment overview on page 264. Note: v Image capture is not supported on VMWare ESX, AIX, or Linux PPC.
315
v Image capture is also not supported for Solaris computers. Instead, you must create a Flash archive and then create an unattended setup installation using the Flash archive. Creating an unattended setup image from a Solaris Flash archive on page 310 v To prevent errors during the common agent installation on the target machine, ensure that the common agent is not installed and the Tivoli GUID is removed from the computer that you are capturing the image from. For details, see Uninstalling the common agent on page 669. Sysprep must be run (automatically or manually) for all Windows platforms before an image capture. For more information about this task, see Windows Microsoft System Preparation tool (Sysprep) in Tutorial: Managing operating systems on page 301. 1. Click Go To > Deployment > OS Management > Image Capture. 2. In the Task field, specify a description for the provisioning task for the capture. 3. In the Source Computer field, specify your source computer to capture the image from. 4. If required, adjust the timeout period for connecting with a target computer. 5. In the Boot Server Type field, specify TPMfOSd as the boot server technology that you are using to capture the image. Additional fields are displayed. 6. In the Image Details, section specify the following information: a. In the Image field, specify a name for the image. b. Type a description for the image next to the Image field. c. In the Image Type field, select Golden Master. Note: If Tivoli Provisioning Manager for OS Deployment has been upgraded to Tivoli Provisioning Manager for Images, a new type of virtual image, TPM for Images Virtual Image, is available. 7. By default, the image capture process will be started as soon as you submit the provisioning task. If you want to schedule the capture for a specific date or time, click Schedule and specify the date and time. 8. Click Submit to confirm your settings. The Provisioning Task Tracking application displays the current status of the task. When the provisioning task has started, you can monitor its progress on this page. From the Select Action menu, click Refresh to update the page. The image has now been captured. You can now prepare the computer that you will install this image on and then install the captured image. If you want to view the image that you have just captured: Click Go To > Deployment > OS Management > Images. Search for the image name.
Capturing a Point-In-Time snapshot

In this lesson, you will capture a Point-In-Time snapshot. A Point-In-Time snapshot is an image that is captured without making the image generic. Because the image is not depersonalized, you cannot deploy it to other computers. Point-In-Time snapshots can be used to perform a simple backup of an individual computer, but they do not replace the role of backup or archival applications that are designed for storage and recovery of critical data in your organization. They are only supported on Windows. If the computer that you are capturing the image from does not have the following settings, the capture image provisioning task will fail: v Ensure that the network interface with Dynamic IP Address set has the computer name in DNS, so that the Tivoli Provisioning Manager computer will find the IP address from the DNS server. v The BIOS startup sequence must first have network and then hard disk for this computer. Note:
316
v Point-In-Time snapshots are only supported on Windows. v The Point-In-Time snapshot does not run or use Sysprep. v Point-In-Time snapshots are limited in the amount of data they can handle. They might fail for machines with large amounts of data (for example, database servers). v Point-In-Time snapshots do not scale well. We do not recommend you use them to back up several computers or a data center. To capture a system snapshot: 1. Click Go To > Deployment > OS Management > Image Capture. 2. In the Task field, specify a description for the provisioning task for the capture. 3. In the Source Computer field, specify your source computer to capture the image from. 4. If required, adjust the timeout period for connecting with a target computer. 5. In the Boot Server Type field, specify TPMfOSd as the boot server technology that you are using to capture the image. Additional fields are displayed. 6. In the Image Details, section specify the following information: a. In the Image field, specify a name for the image. b. Type a description for the image next to the Image field. c. In the Image Type field, select Point-In-Time Snapshot. 7. By default, the image capture process will be started as soon as you submit the provisioning task. If you want to schedule the capture for a specific date or time, click Schedule and specify the date and time. 8. Click Submit to confirm your settings. The Provisioning Task Tracking application displays the current status of the task. When the provisioning task has started, you can monitor its progress on this page. From the Select Action menu, click Refresh to update the page. The Point-In-Time snapshot has now been captured. If you need to restore the image, you can deploy it to the same computer that you captured it from. If you want to view the image that you have just captured: Click Go To > Deployment > OS Management > Images. Search for the image name.
Working with hardware configurations

In this lesson, you will learn more about hardware configurations and supported environments, and will create an environment and a hardware configuration. Hardware configuration images: Hardware configurations are performed at deployment time through an vendor-dependent environment which is loaded on the target before operating system installation. Hardware configurations do not impact the consecutive operating system deployment because Tivoli Provisioning Manager for OS Deployment configures the hardware through actions run in a ramdisk before the deployment of the operating system. The execution flow is similar, regardless of the environment to run: 1. The environment is loaded in memory, as a ramdisk 2. Any additional binary or configuration files are added to the ramdisk, based on the selection made in the web interface 3. The computer boots the ramdisk 4. The hardware configuration task is executed
317
5. The ramdisk reboots 6. Tivoli Provisioning Manager for OS Deployment resumes the deployment sequence if any was selected, but hardware configuration can also be run as a separate task There are four types of hardware configuration available: RAID configuration A generic configuration wizard allows you to create the RAID configuration regardless of the vendor, Tivoli Provisioning Manager for OS Deployment builds the specific file. BIOS update Allows you to update the BIOS firmware on the target. BIOS settings Allows you to update the BIOS or BMC (baseboard management controller) settings through an initialization file. Hardware custom configuration Allows you to perform your own configuration, based on tools and a command to be applied to them. Environment overview: To launch hardware configurations, you need to set up a vendor-specific environment containing the related scripting toolkit tools and the necessary drivers to run correctly (for example, network connectivity) on the target. Three environments are supported: v Scripts and tools running in DOS v Scripts and tools running in WinPE 1.x v Scripts and tools running in WinPE 2.x Every environment is very specific to its vendor, and must be prepared with the suitable drivers and scripting toolkit tools. An environment is installed on a target, or possibly run as a ramdisk. However, an environment by itself is not able to perform hardware configurations (RAID configuration, BIOS settings, and so on). It needs to contain drivers and tools for the required configuration changes. When creating a complete environment with OS deployment server, you associate the environment files for one of the three types of environments, with the tools and drivers enabling it to perform hardware configurations on a specific set of target models. Once the hardware configuration is performed, any environment file on the target is written over during the operating system deployment phase, leaving no trace of the environment on the target. Creating a hardware environment: Hardware environments allow you to perform hardware configurations on targets. Before you can create your environment with the wizard, you must prepare the files on the OS deployment server. The provided instructions explain how to prepare files using scripting toolkits for either IBM, Dell, or HP products. It is recommended that you download the latest WinPE2.x compatible scripting tool environments and use the instructions below for that version. However, the instructions for WinPE1.x and DOS are also provided.
318
A hardware environment uses the Windows Imaging Format (WIM). The following limitations of WIM apply: v You must be using a computer with a 32-bit architecture running the web interface extension under Windows XP, Windows 2003, Windows Vista or Windows 2008. Windows 2000 is not supported. v The web interface extension must be started with local administrator privileges. When you create a hardware environment, the web interface extension must be running from the command line instead of as a Windows service. If you are running the web interface extension as a Windows service, perform the following steps to run it from the command line: 1. At the command line, run the following command to stop the service:
net stop remboagent
2. Change to the Tivoli Provisioning Manager for OS Deployment directory for the web interface extension. The default location is C:\Program Files\Common Files\IBM Tivoli. 3. Run the following command to run the web interface extension from the command line:
rbagent -d
v Creating a Windows WIM image is possible only for users that have separately obtained the Microsoft Windows Automated Installation Kit (WAIK) 32-bit and installed it on the computer running the web interface extension. The WAIK is licensed to you by the code's owner and not by IBM. IBM ServerGuide Scripting Toolkit DOS-based 1. Download the latest ServerGuide scripting toolkit from the IBM site. 2. Extract the toolkit into c:\IBM-SGSTK-DOS, for example. Note: DOS tools will be deprecated. They are actually used only to support some older hardware. IBM ServerGuide Scripting Toolkit WinPE 1.x-based 1. Download the latest ServerGuide scripting toolkit from the IBM site. 2. Extract the toolkit into c:\IBM-SGSTK-WinPE1.x, for example. 3. According to the user guide found under c:\IBM-SGSTK-WinPE1.x\sgdeploy\SGTKWinPE\Docs\ UserGuide.pdf, you must then: a. Provide WinPE 2005. b. Run SGTKWinPE.cmd to create a WinPE image with the requested drivers for IBM servers. IBM ServerGuide Scripting Toolkit WinPE 2.x-based 1. Download the latest ServerGuide scripting toolkit from the IBM site 2. Extract it for example into c:\IBM-SGSTK-WinPE2.x 3. According to the user guide found under: c:\IBM-SGSTK-WinPE2.x/sgdeploy/SGTKWinPE/Docs/ UserGuide.pdf you must then a. Download the Windows Automated Installation Kit (AIK) 1.1 for Windows Vista SP1 and Windows Server 2008. Note: Windows Automated Installation Kit for Windows 7 and Windows Server 2008 R2 is not supported. b. Install the Windows AIK. c. Restart your computer. d. According to the user guide found under c:\IBM-SGSTK-WinPE2.x/sgdeploy/SGTKWinPE/ Docs/UserGuide.pdf, you must then: 1) Download the Windows Automated Installation Kit (AIK) 1.0 for Windows Vista SP1 and Windows Server 2008. 2) Install the Windows AIK. 3) Restart your computer.
319
4) Run SGTKWinPE.cmd to create a WinPE image with the requested drivers for IBM servers. Use the option /Image to exclude ISO, and provide the following properties files to include all RAID and Fibre tools and exclude all network tools. The command finds by itself the location of the WAIK.For 32-bit WinPE:
SGTKWinPE.cmd /Image ScenarioINIs\Local\Raid_Config_Only_x86.ini
For 64-bit WinPE:

SGTKWinPE.cmd /Image ScenarioINIs\Local\Raid_Config_Only_x64.ini
A directory that contains the environment tools is created, for example, .\sgdeploy\WinPE_ScenarioOutput\Local_Raid_Config_Only_x86\ISO. Note: From ServerGuide Scripting Toolkit version 2.20 onwards, there are two update zip files in the .\sgdeploy\updates\uxsp directory of the main zip file, which contain the IBM Server Guide Scripting Toolkit (ibm_utl_sep_1.00_winpe_i386.zip and ibm_utl_sep_1.00_winpe_x86-64.zip). These zip files must be manually extracted in the directory where the main IBM ServerGuide Scripting Toolkit was extracted, for example, C:\IBM-SGSTD-WinPE2.x. DELL Scripting Toolkit WinPE 1.x-based Note: Windows PE 2005 must be built from a Windows 2003 server for the Dell tools to work. To set up the Windows PE environment for your Dell servers: 1. You must first obtain a Windows PE 2005 file structure. 2. Copy it to a temporary folder, for example, c:\winpe-dell. 3. The Windows PE 2005 directory structure must contain a directory named I386 or MININT. If it contains a directory named MININT, rename it toI386. 4. Download the Deployment Toolkit from Dell. 5. Run the executable package to extract the toolkit to the disk of the OS deployment server. In the examples, it is assumed that you have extracted the toolkit into c:\DELL-DTK, which implies that you have a folder named C:\DELL-DTK\Dell\Toolkit. 6. To install the appropriate drivers for Dell servers in your WinPE image, follow the instructions of the DTK User Guide (Running Deployment Scripts Using DTK and Windows PE). In a. b. c. particular, you must: Install the drivers with the driverinst.bat script. Modify winpeoem.sif and winbom.ini. Add the RPC DLLs to the Windows PE directory.
Note: Add the RPC DLLs in i386\system32 instead of those in the Tools folder. 7. To verify that the drivers have been installed, check for the existence of the file named c:\temp\winpedell\i386\system32\racsvc.exe. Dell DTK Scripting Toolkit WinPE 2.x based 1. Download the Windows Automated Installation Kit (WAIK) 1.1 32-bit for Windows Vista SP1 and Windows Server 2008. The Windows Automated Installation Kit (WAIK) 1.1 is distributed by Microsoft and is available at Windows Automated Installation Kit (AIK). 2. Install the Windows AIK. 3. Download the latest DTK scripting toolkit from the Dell Web site. The name of the downloaded file should be similar to DTK2.6-WINPE-56.exe. 4. Extract the download file. For example, extract the file to the location c:\ Dell-DTK-2.6 5. 5. According to the Dell user guide, found under C:\Dell-DTK-2.6\Dell\Toolkit\Docs\ DTK25UG.pdf, you must then complete the following tasks:
320
a. Open a command prompt in the directory containing the driver installation batch for WinPE2.x: VPE_driverinst.bat. For example, the directory, C:\ Dell-DTK-2.6\Dell\ Drivers\winpe2.x. b. Launch the file called VPE_driverinst.bat <WINPEPATH> <DTKPATH>, where <WINPEPATH> is the destination path to create the directory structure for Windows PE 2.0, and <DTKPATH> is the path to the Dell drivers in the extracted DTK toolkit. For example, the file might be called VPE_driverinst.bat C:\Dell-DTK-2.6\WinPE2.x_Out C:\Dell-DTK-2.6\Dell\drivers. Launching this file preinstalls the Dell drivers into winpe.wim. 6. Copy and rename the customized C:\Dell-DTK-2.6\WinPE2.x_out\winpe.wim to C:\Dell-DTK-2.6\WinPE2.x_Out\ISO\sources\boot.wim. HP SmartStart Scripting Toolkit WinPE 1.x-based The initial setup for the HP SmartStart Scripting Toolkit is very similar to the setup of the Dell Hardware Toolkit, since both toolkits require Windows PE. Some details are therefore skipped, as you can read the Dell section to complete the information found here. 1. Download the Win32 HP SmartStart Scripting Toolkit version of the toolkit on the HP site. 2. Extract it to the disk of the OS deployment server (for example, to c:\HP-TK). 3. Create a Windows PE 2005 folder for the HP tools: a. Copy a Windows PE file structure to a temporary folder, for example, c:\winpe_hp. b. Install the HP drivers in the Windows PE directory, as explained in the User Guide for the HP Hardware Toolkit. 1) Run the executable under hpDrivers. 2) Give the location of the i386 folder of your Windows PE folder. HP SmartStart Scripting Toolkit WinPE 2.x-based Note: Only versions of the HP SmartStart Scripting Toolkit up to 2.1 c (file SP44695.exe) are currently supported. 1. Download the Windows Automated Installation Kit (WAIK) 1.1 32-bit for Windows Vista SP1 and Windows Server 2008. It is distributed by Microsoft and is available on the Microsoft Web site at Windows Automated Installation Kit (AIK). Note: Windows Automated Installation Kit for Windows 7 and Windows Server 2008 R2 is not supported. 2. Install the Windows AIK. 3. Restart the computer. 4. Download the latest SmartStart Scripting Toolkit from the HP Web site: http:// h18013.www1.hp.com/products/servers/management/toolkit/. The name of the downloaded file should be similar to SP38836.EXE. 5. Extract the file to a directory, for example, C:\HP-TK. 6. According to the HP SmartStart Scripting Toolkit Windows Edition User Guide.pdf found under C:\HP-TK\SWSetup\SP38836\ and the Windows Preinstallation Environment User's Guide (WinPE.chm) contained in the Windows Automated Installation Kit, you must then mount the WinPE2.x base image for specific customization. For example, activate extra packages, add drivers, and so on. a. From the Windows AIK tools folder, run the command to create the Windows PE customization directory. For example: C:\Program Files\Windows AIK\Tools\ PETools>copype.cmd x86 C:\HP-TK\SWSetup\SP38836\WinPE2.x_HP. b. Mount the base image launching imagex from the WinPE2.x_HP folder. For example: imagex /mountrw WinPE.wim 1 .\mount. c. Install the WMI packages in the image: peimg /image=.\mount /install=*WMI*
321
d. Add the required drivers (.inf files) to the base image using the peimg /inf command.
peimg /inf=<driverpath> .\mount
where <driverpath> is the location of the .inf files found in the extracted drivers within the hpDrivers folder. For example, peimg /inf=c:\HP-TK\SWSetup\SP38836\hpDrivers\ExtrDrivers\nic\b06nd .\mount. e. Repeat step d. for each additional device driver. f. Copy the hpsstkio.sys Toolkit I/O driver (required for the conrep and rbsureset utilities) from the HP driver directory to the Windows driver directory. For example:
copy C:\HP-TK\SWSetup\SP38836\hpDrivers\system\hpsstkio\hpsstkio.sys C:\HP-TK\SWSetup\SP38836\WinPE2.x_HP\mount\Windows\System32\drivers
g. When you finish customizing the image, prepare the environment image by using the peimg /prep command:
peimg /image=.\mount /prep
h. Unmount the customized image to build the customized WinPE.wim:

imagex /unmount /commit .\mount
7. Copy and rename the customized C:\HP-TK\SWSetup\SP38836\WinPE2.x_HP\WinPE.wim file into C:\HP-TK\SWSetup\SP38836\WinPE2.x_HP\ISO\sources\boot.wim. To create your environment with the wizard: 1. Click Go To > Deployment > OS Management > Hardware Configuration Image. 2. Select any option in the first page of the wizard and click Next. 3. On the second page of the wizard, select to create a pre-boot environment. This launches the Hardware Environment Wizard. 4. Follow the steps in the wizard. You must: a. Ensure that the Web interface extension is running on the computer where WAIK and the environment tools have been prepared. b. Provide the path of the folder in which the environment tools are located, that is where you have installed the scripting toolkit, for example, C:\IBM-SGSTK-WinPE-2.x\sgdeploy\ WinPE_ScenarioOutput\Local_Raid_Config_Only\ISO. c. Provide the path of the folder in which the environment material is located, that is the WinPE files, for example, C:\IBM-SGSTK-WinPE-2.x\sgdeploy\WinPE_ScenarioOutput\ Local_Raid_Config_Only\ISO. Click Go To > Deployment > OS Management > Software Modules. Here you can view the created environment under a specific environment folder. Now, you can create hardware configurations using this environment. Creating a hardware configuration: A wizard allows you to effortlessly create hardware configurations. Before you can create a hardware configuration, you must have created the needed environments to be able to later apply the hardware configurations. 1. Click Go To > Deployment > OS Management > Hardware Configuration Image. 2. Select the kind of hardware configuration you want to create. 3. Provide at least one target model and environment pair on which the hardware configuration can apply. 4. For BIOS update, BIOS settings or Hardware custom configuration the specific files or set of files can be downloaded from the specific vendor sites.
322
5. Follow the wizard instructions. Note: Do not close the browser when the image is being uploaded. If you do, the upload might be cancelled. To view or edit a hardware configuration, you need to find the Hardware configuration image information in the Images application. Click Go To > Deployment > OS Management > Images. Then click the Properties tab.
Part 2: Configuring image properties

Each image has associated parameters for configuration of the operating system. You can configure image properties directly in the web interface or create a customized image properties file. An image properties file enables you to configure parameters which do not appear in the web interface. You must only use an image properties file if you are familiar with the syntax and format of the file. If you want to create a customized image properties file, there are two ways that you can use the file: v Create a single image properties file for all deployments of the image and associate it directly with the image. v Create multiple image properties files for use with specific deployments of the image. You can write a provisioning workflow that configures the software configuration template for the image with the appropriate image properties file at deployment time. Note: You must have experience in correctly configuring image properties directly in a file. Tivoli Provisioning Manager for OS Deployment does not provide any syntax checking of the file. See the operating system documentation for details about the file format and syntax.
Editing image properties in the web interface

You can edit the properties of an image so that they are applied to every deployment of the image.
Procedure
1. 2. 3. 4. Click Go To > Deployment > OS Management > Images. In the list of images, click the image that you want to edit. Click the Properties tab. To edit parameters, click Edit on the banner of the corresponding section and enter the values. In the Fixed target properties section, specify parameters that are common to all targets of this image. The web interface displays a number of OS configuration parameters divided into panes sections. You can set the TCP/IP mode of the target being deployed. If the end-user's network supports the DHCP mode, you can set TCP/IP settings to use DHCP. If the TCP/IP mode has been already defined in the Target Details page, the deployment uses the values defined in this page. If you do not set any TCP/IP mode, the Dynamic, use DHCP value is used. Any value entered in Fixed target properties overrides the corresponding value for targets deployed using this OS configuration. In the Fixed user properties section, you can enter the organization name.
Windows In the Windows-specific info section, you can enter a Windows product key if you have an Open License or a similar site license that uses the same product key for all targets. Configuration-related information also includes operating system information (under the section OS deployment), including an operating system version, its architecture, its language, the root of the system installation and boot parameters. In the OS deployment section, you can also specify (for a multi-partition image) partitions that must be excluded from deployment. In the text fields, enter the number of the partitions you want to
323
exclude, keeping in mind that partitions with numbers 1 to 4 are primary partitions, while those with number 5 or above are logical partitions. If you want to exclude more than one partition, separate the partition numbers with commas. For example, 2,5 excludes the second primary partition and the first logical partition. Note: a. This option is valid only for the first physical disk. b. This option is valid only for partitions defined in the image. The partition scheme defined in the image is always written on the disk of the deployed target. Therefore, if your target has two partitions but your image has only one, the deployment always creates the one partition of the image and deletes the second partition of your target. c. Partitions can be preserved only when the target has the same partition scheme as the one defined in the image. The way partition sizes are defined in a image makes it unlikely for a target not previously deployed with this system profile to have the same partition scheme. Some pre-settings can also be specified concerning the local user in the Fixed target properties section. Values in Fixed target properties can contain special keywords that are replaced by dynamic information. For example, [IP] is replaced by the full IP address of the target being deployed, while [MAC] is replaced by the hardware address, also known as Media Access Control (MAC) address. To set target names based on the MAC address, you can enter the following value in the target name field: pc[MAC]. The computer with the MAC address 00:01:02:03:04:05 is named pc000102030405. The following keywords are supported: v [IP]: full IP address (received by DHCP) v [MAC]: hardware address v [SN]: serial number as found in DMI (SMBIOS) v v v v [BOMID]: unique target identifier in the provisioning server database [AT]: DMI asset tag [GRP]: deepest administrative group name to which the target belongs [DHCPNAME]: target name as known to the DHCP server
Every keyword supports a range extension if you want to include only part of the dynamic information. The range starts at value 0. [IP3] corresponds to the last byte of the IP address (in IP addresses, bytes are separated by dots. pc-[IP3] becomes pc-12 if IP address is 192.168.0.12). [IP1-3] corresponds to bytes 1 to 3. [MAC3-5] is replaced by the last three bytes of the MAC address (MAC addresses are typically represented in hexadecimal, with colons to separate the bytes). For AT, GRP, and DHCPNAME, the range corresponds to a substring.
Binding drivers to Windows images

When an image does not contain the drivers needed for deployment, you must bind these drivers to the image to be able to deploy it and obtain a working operating system.
Before you begin

You can only bind drivers to images that are software modules in your OS deployment server. You must therefore create driver software modules from the drivers that you want to bind to your system profile. The following methods are available for binding images types to Windows device drivers: 1. Standard binding rule method where you can indicate profiles to bind to a software module. 2. Driver specific binding rule method (available only if you have upgraded to IBM Tivoli Provisioning Manager for OS Deployment version 7.1.1.4 or higher) where you bind drivers per system profile and target model/device pair.
324
Note: You can switch from one method to the other. In the driver specific binding rule method, driver bindings from the standard binding rule method are ignored, and vice-versa. The method described here is the driver specific binding rule method. From version 7.1.1.4 of the product onwards, it is recommended to use the driver specific binding rule method, which is the method by default on all new Windows images. A system profile is a shared object where image data is stored. If you use the driver specific binding rule method, the binding might be shared with other images. Any changes to an image will also apply to images that share the binding grid. For the driver specific binding rule method, the following image types are supported: 1. Golden master images 2. Snapshot images 3. Unattended images The OS deployment server helps you select appropriate drivers for particular target models. It helps you to predict potential problems and to solve them. It does not guarantee that a specific image, with bound drivers, works with a given target. The information used by the OS deployment server to predict the compatibility of a driver with a target model is taken from the content provided by the vendor in its driver. The OS deployment server cannot verify the accuracy of this information.
Procedure
1. Check the compatibility of your image. a. Go to Click Go To > Deployment > OS Management > Images. b. Find the image in the list and click on it to select it. c. On the Driver Binding tab, select the Use Driver Specific Binding Mode to enable to the new mode. d. A check is performed while the page is loading. This may take a few minutes. If drivers are missing, or are not bound, or if several drivers are bound for the same device, the following information is provided. Indicates a missing critical driver, or a critical driver of the wrong architecture. Indicates that a missing non-critical driver, or a non-critical driver of the wrong architecture. Indicates that a required driver is present on the OS deployment server, but that it is not bound. Indicates that there are several drivers bound for the same device, or that there is a binding with a driver that is not known as compatible. You can expand the line to get more information. v For drivers missing on the OS deployment server, you find a suggestion of where to look for it, including, if available, a download link and the exact directory within the downloaded archive where the driver can be found. v When drivers are present on the OS deployment server, you find suggestions of which driver to bind, in order of preference. If multiple drivers are known to possibly work for a device, the best choice is listed first. The choice is explained in the advice text, which first recommends the use of device-specific drivers, that is, drivers that have been specifically designed for the given hardware device. Then compatible device drivers, that match the device family, are recommended, even if they are not an exact rebranded variant (for example, as second choice, an Adaptec
325
driver of the same family as an IBM ServerRaid adapter, if it is based on the same chipset). Finally, as third choice, generic drivers, for example, Microsoft generic AHCI driver for any AHCI controller, are recommended. If no error is found, you do not need to modify the bindings. 2. Modify the driver bindings of the system profile. There are two ways to perform this. v Use a wizard. a. At the bottom of the page, click Fix Drivers. b. Follow the instructions of the wizard. After having selected a target model, you have to select one of these options: Automatically fix issues which can be fixed for this model. Fixes all issues which can be automatically fixed. Such issues include a missing binding to an existing driver, or multiple bindings for a device, for example. Manually fix issues for this model. Presents you with each issue in turn. Ways to solve the issue, when available, are proposed. Automatically bind drivers for this model. Erases every existing binding. New bindings are then automatically added. Copy driver bindings for this model from a similar profile. Copies all the bindings from a selected source system profile to the current one. Reset all drivers bindings for this model. Erases all the driver bindings, and does not create any new binding. v Edit the bindings manually. Columns represent target models known to the OS deployment server. They can be expanded to view their devices, provided an inventory has been performed. The first line represents the system profile. Other lines represent software module folders in the OS deployment server. They can be expanded to view individual drivers. If a driver can be used only for 32-bit or 64-bit machines, a superscript x86 or x86-64 mark is written next to the driver name. If you do not find the drivers that you need in the list provided, you should first create software modules for your drivers. a. (Optional) To obtain a summary of the errors and warnings, click the link provided above the grid. This helps you locate the problematic areas in the driver grid. b. Expand the columns of problematic target models to view individual devices. c. Expand software module folders containing drivers to view the individual drivers.
326
A cell with a green background indicates that driver information corresponds to the device. The quality of the drivers that can be selected is illustrated by the intensity of the green background: the best drivers are in intense green, the family drivers are in standard green, and the generic drivers are in pale green. A cell with an orange background indicates either that the driver is not a PCI driver, or that there is no compatibility information available for the driver. indicates that the driver is bound to the system profile for A cell with a green check mark use with the specific target model and device. d. Click on a green background cell to add or remove bindings. It is not possible to bind or unbind drivers from the system profile itself, because they are built-in drivers. You should have one, and only one, check mark per column, indicating that you have one and only one driver for each device. e. When you are done modifying the bindings, click Save. f. To return to the Profile details page, click Back. Potential problems with the image are recomputed, allowing you to check if your modifications have solved the detected problems.
What to do next
When you have solved all the driver binding issues, you can deploy targets with your system profile.
Creating a customized image properties file

You can create an image properties file that define parameters for to all future deployments of an image. An image properties file includes settings that are not available in the web interface. There are two ways that to use an image properties file: v Create a single image properties file for all deployments of the image and associate it directly with the image. v Create multiple image properties files for use with specific deployments of the image. A software stack is associated with each image and deployment settings are stored in a software configuration template. When you deploy the image, a copy (or clone) of the software stack is created for the deployment. This design enables you use provisioning workflows to assign an image properties file to the cloned software configuration template at deployment time.
327
Tivoli Provisioning Manager for OS Deployment merges the information in an the image properties file with the information provided on the web interface. If a value is specified for a parameter in the web interface, the corresponding value in the image properties file is ignored. The following examples show the impact of this behavior: v If the parameter FullName is defined in both the web interface file and in the custom file, the value in the web interface file is used for the deployment. v If a value for the license key is not configured in the web interface file but is configured in the custom file, the value in the custom file is used for the deployment. Creating a single file for all deployments: Before you begin You must have experience in correctly configuring image properties directly in a file. Tivoli Provisioning Manager for OS Deployment does not provide any syntax checking of the file. See the operating system documentation for details about the file format and syntax. Procedure 1. On the Properties tab of the image, open the appropriate file. v v v v
Vista XP Red Hat SUSE 2008 2003
Click Edit custom 'unattend.xml' to edit the file. Click Edit custom 'sysprep.inf' to edit the file.
Click Edit custom 'ks.cfg' to edit the file. Click Edit custom 'autoinst.xml' to edit the file.
Solaris Click Edit custom 'solaris.profile' to edit the file. v v VMWare ESX: Click Edit custom 'ks.cfg' to edit the file to modify the size of the VMFS and VMKcore partitions if needed and to define a custom partitioning scheme when installing VMWare with scripted installation. 2. Type in the parameters and their values in the syntax required by the operating system, or copy and paste it from another editor. 3. Click OK.
Example
Red Hat Here is an example of a custom file which defines a custom partitioning scheme when installing RedHat with scripted installation.
part part part part part
/usr --fstype ext3 --size 4000 /home --fstype ext3 --size 4000 /opt --fstype ext3 --size 20000 /var --fstype ext3 --size 2000 /tmp --fstype ext3 --size 2000
SUSE Here is an example of a config.xml file which adds a new user during setup and defines a custom partitioning scheme when installing SuSE with scripted installation.
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns"> <users config:type="list"> <user> <username>jdoe</username> <user_password>tOpsEcreT</user_password> <encrypted config:type="boolean">false</encrypted> <forename>John</forename> <surname>Doe</surname> </user> </users>
328
<partitioning config:type="list"> <drive> <device>/dev/sda</device> <partitions config:type="list"> <partition> <create config:type="boolean">true</create> <filesystem config:type="symbol">ext3</filesystem> <format config:type="boolean">true</format> <mount>/usr</mount> <size>2G</size> <partition> <partition> <create config:type="boolean">true</create> <filesystem config:type="symbol">ext3</filesystem> <format config:type="boolean">true</format> <mount>/home</mount> <size>1024M</size> </partition> </partitions> <use>free</use> </drive> </partitioning> </profile>
Do not omit the xmlns and xmlns:config attributes of the profile tag.
Solaris
Here is an example of a disk layout described in a solaris.profile file:

explicit rootdisk.s0 rootdisk.s1 SUNWCpm SUNWCpmx SUNWCdial SUNWCdialx SUNWCadm SUNWCcpc free 2048 delete delete delete delete / swap
partitioning filesys filesys cluster cluster cluster cluster cluster cluster
By default the deployment provides its own preinstall and postinstall scripts for generating profiles dynamically and installing software modules specified in the database. If you want to add your own code in the preinstall and postinstall scripts, you can do so by adding sections in the custom profile configuration file solaris.profile.
SI_BEGIN: echo This is the preinstall script ... SI_PROFILE: echo This is the profile configuration partitioning explicit filesys rootdisk.s0 free / filesys rootdisk.s1 2048 swap cluster SUNWCpm delete cluster SUNWCpmx delete cluster SUNWCdial delete cluster SUNWCdialx delete cluster SUNWCadm cluster SUNWCcpc SI_FINISH: echo This is the postinstall script ...
VMWare ESX: In the following example, the following partitions are created: v A ext3 partition of 900 KB on the sda disk.
329
v A vmfs3 partition of 50 MB is created on the sda disk. v A vmkcore partition of 94 KB on the sda disk.
part /var --fstype ext3 --size=900 --ondisk sda part None --fstype vmfs3 --size=50000 --grow --ondisk sda part None --fstype vmkcore --size=94 --ondisk sda
Associating image properties with the software stack: If you want to use specific image properties for individual image deployments instead of applying the same image properties to all deployments, you can use provisioning workflows to assign a customized image properties file at deployment time. Before you begin To perform this task, you must have the following skills: v Experience in correctly configuring image properties directly in a file. Tivoli Provisioning Manager for OS Deployment does not provide any syntax checking of the file. Refer to the operating system documentation for details about the file format and syntax. v If you want to use multiple image properties files for specific deployments of the same image, you must have experience writing provisioning workflows and be familiar with software configuration templates. This task does not explain how to write provisioning workflows to customize settings in asoftware configuration template. A software stack for an image includes a software configuration template with parameters for the image deployment. The parameter CustomConfigFile defines the image properties file name. Note: You must have experience in correctly configuring image properties directly in a file. Tivoli Provisioning Manager for OS Deployment does not provide any syntax checking of the file. See the operating system documentation for details about the file format and syntax. Procedure 1. On the provisioning server, create your custom image properties files in a text editor with the parameters and values that you want to set for specific deployments. For more information about the parameters to configure in the image properties file, refer to the related links at the end of this topic and your operating system documentation. Consider centralizing your custom image properties files in a single directory so that they are easy to reference from a provisioning workflow. 2. The following steps show you where to configure the name of the image properties file in the software catalog. Setting a value on the original software stack has the same effect as creating image properties file from the Properties tab of the image itself. To assign a specific value at deployment time, you must create your own provisioning workflows that change the value of the CustomConfigFile parameter on a clone of the image at deployment time. . a. On the Image tab of the image, locate the software stack for the image. Click b. Under Configuration Templates, locate the Template Parameters section and expand CustomConfigFile. c. In the Parameter Value field, specify the full path and file name for the custom image properties file. For example, c:\imgprop\unattend.xml or /var/imgprop/ks.cfg. d. Save your changes.
330
What to do next To automatically set values in the custom file, you must create provisioning workflows for deploying the image that will set the value of CustomConfigFile at deployment time. Troubleshooting: If the image properties in the deployed operating system are not what you expected, you must examine the parameter files carefully. The image properties are the result of the parameters configured in the web interface, and the parameters in the image properties file that you created.
Vista 2008 To troubleshoot OS configuration parameters after a successful deployment, view the two files Windows/panther/setup.xml and Windows/panther/unattend.xml which are the result of the merge between the default and custom parameter files. To troubleshoot OS configuration parameters after a failed deployment, you must look for the following files in the partition containing the operating system: v user_unattend.xml, which is the file you edited v setup.xml, which results from the merge v unattend.xml, which results from the merge as well
To troubleshoot OS configuration parameters after a failed deployment, follow these steps: v Without rebooting the target:
Red Hat
1. Type Alt+F2 on the target. This opens a shell. 2. In the opened shell, view the file /tmp/anaconda.log. To troubleshoot OS configuration parameters after a failed deployment, follow these steps: v Without rebooting the target: 1. Type Alt+F2 on the target. This opens a shell.
SUSE
2. In the opened shell, view the file/var/log/YaST2/y2log .
Browsing partition files

You can browse partition images stored on your server. To do so, on the image Properties page (Go to > Deployment > OS Management > Images and click Properties), in the Partition layout section, click the partition that you want to view. From this page you can also expand a partition image on your local disk. To do so, click Browse image of primary partition to go to the Partition image explorer. Right-click and select Expand on local disk. Follow the prompts of the Image wizard to expand the partition. Note: You must expand the partition to an empty directory. Selecting a folder that already contains something causes the extraction to fail. You can add new directories to the partition and upload files from the local computer that the web interface is running on. Uploads must be performed one file at a time and the upload file size limit is of 1 MB.
Changing the partition layout

Partition layout can be updated to resize partitions, assign mount points, and change the file system. Partition layout can be edited on Disks tab of the OS configuration details page. Editing the partition layout enables you to:
331
v Add or delete partitions. Note: Adding or deleting partitions can lead to OS configuration problems, so this feature must only be used very carefully. To provide a better description to your profile, the Comment field allows you to write all necessary details. v Resize a partition by dragging sliders, or by assigning it an absolute or relative size. v Change the file system of a partition. v Assign a mount point to the partition. To change the partition layout:
Procedure
1. 2. 3. 4. Click Go To > Deployment > OS Management > Images. Select your image, then click the Properties tab. Click the Disks tab, then scroll down and click Edit partition layout. To add a partition, click Add a regular partition or Add an extended partition.
5. To resize partitions with the sliders, grab the slider to the right of the partition and drag it. 6. To update all other parameters, select a partition by clicking it, then click Edit, and update the parameters. 7. Click OK.
Results
You have now changed the partition layout.
Part 3: Creating software modules

A software module is a piece of software other than the operating system that can be created to address various needs. Tivoli Provisioning Manager for OS Deployment is based on imaging technology. As administrator, you create images of components that you want to see on every target, and the automated deployment merges and restores these images on each target, automatically, when needed. Tivoli Provisioning Manager for OS Deployment can handle most scenarios for software deployment and postinstallation configuration. There are many types of software modules. Depending on the type of package and installation files, the wizard guides you through the different steps to achieve your software module with minimal effort. Only some of them are available for each operating system. Information about software modules is stored in the Tivoli Provisioning Manager for OS Deployment database and is not stored in the Tivoli Provisioning Manager database. This means that you cannot view or manage software modules in the Tivoli Provisioning Manager software catalog. To view software modules in Tivoli Provisioning Manager:Click Go To > Deployment > OS Management > Software Modules. The following types of software modules can be added. v v v
Windows Windows Windows
AVista language pack A Windows Hotfix
A Windows Installer (MSI). Packages that comply with the Designed for Windows logo program typically use this type of installer. It guarantees that there is an easy way to perform an
332
unattended installation of the software. An MSI package typically contains a file with an .msi extension. If you only have a single .exe file, it is likely to be an archive that you must extract first. For more information, refer to the section. v v
Windows Windows
A Windows driver to include in a deployment
A Windows HAL to include in a clone deployment. This option must be used only to inject HAL into a Windows cloning profile. For HAL injection in unattended setup profiles, you must create a driver package.
v A custom action on the targets. This includes OS configuration changes such as registry patches, command to be run, and copying sets of files on the target. The process for creating a software module of the common agent is used as an example. v v A Linux application installation, using RPM. A Solaris application installation, using pkgadd
Linux
Creating a language pack software module

Before you begin
Windows language pack software modules must be created using a source computer with a Windows operating system, and the source computer must be running the web interface extension. You can, however, use any kind of machine (for example, a Linux operating system machine) to actually create the software module as long as Tivoli Provisioning Manager for OS Deployment is installed on it. For instructions on how to manually install the web interface extension on a source computer, see Installing and uninstalling the web interface extension on page 384. The directory containing language pack files must contain a file with a .cab extension.
Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. Select the Windows Vista / 2008 and click Next. 4. Select Language pack and click Next. 5. Follow the instructions of the wizard to create your software module. 6. You will have to choose the computer where the material to create your software module can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension.
Results
Parameters of the software module are pre-filled for you but they can be modified in the appropriate step of the software wizard. These parameters include: v A description that identifies the package in the software module tree. v A comment with additional information about the software module. v The stage of the deployment when your software module must be installed: when the OS is installed, or after one or more additional reboot. Most of the time, you must install the package at the same time as the operating system. However, you can decide to install them in a specified order to avoid software-specific conflicts. v A file name to store your image on the provisioning server. Packages typically have a .pkg extension.
333
v The path to where the installation files are restored on the target computer. This path is relative to the system root partition. v An additional command line that might be necessary to install your software module. When possible, the wizard suggests automatically the appropriate command line to run the installation unattended. However, you might need to add some additional parameters to the command.
Creating a HotFix software module

Before you begin
Windows HotFixes can be created only from a computer with a Windows operating system, and the source computer must be running the web interface extension. You can, however, use any kind of machine (for example, a Linux operating system machine) to actually create the software module as long as Tivoli Provisioning Manager for OS Deployment is installed on it. For instructions on how to manually install the web interface extension on a source computer, see Installing and uninstalling the web interface extension on page 384. The directory containing the HotFix files must contain a file with a .msu extension.
Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. Select Windows Vista / 2008 and click Next. 4. Select HotFix (MSU) and click Next. 5. Follow the instructions of the wizard to create your software module. 6. You will have to choose the computer where the material to create your software module can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension.
Results
Parameters of the software module are pre-filled for you but they can be modified in the appropriate step of the software wizard. These parameters include: v A description that identifies the package in the software module tree. v A comment with additional information about the software module. v The stage of the deployment when your software module must be installed: when the OS is installed, or after one or more additional reboot. Most of the time, you must install the package at the same time as the operating system. However, you can decide to install them in a specified order to avoid software-specific conflicts. v A file name to store your image on the provisioning server. Packages typically have a .pkg extension. v The path to where the installation files are restored on the target computer. This path is relative to the system root partition. v An additional command line that might be necessary to install your software module. When possible, the wizard suggests automatically the appropriate command line to run the installation unattended. However, you might need to add some additional parameters to the command.
334
Creating Microsoft Software Installer (MSI) software modules

Before you begin
MSI software modules can be created only: v Locally with a provisioning server installed on a Windows 2000/2003/2008 operating system. v From a computer with a Windows 2000/2003/2008/XP/Vista operating system and running the web interface extension. Note: You can actually use any kind of machine (for example, a Linux operating system machine) to create the software module as long as Tivoli Provisioning Manager for OS Deployment is installed on it. The source computer must be a Windows machine with the web interface extension installed. For instructions on how to manually install the web interface extension, see Installing and uninstalling the web interface extension on page 384. The directory containing MSI files must contain a file with a .msi extension. If the MSI file is located on the provisioning server, you must have placed it in a subdirectory of the import directory. Note: If the folder you are looking for is not on the local computer, the provisioning server, or on another computer running the web interface extension, you might still be able to access the wanted resource using the following procedure:
Windows
Windows 1. Create a .lnk.yourfilename file (where yourfilename is the name of your choice) that contains the path to the wanted folder (for example, \\fileserver\export\softs\). 2. In the wizard, enter .lnk.yourfilename preceded by the appropriate path. UNIX Use symlinks.
UNIX
To create your software module
Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. 4. 5. 6. Select Windows Vista / 2008 and click Next. Select A Windows application installation, using Microsoft Installer (MSI) and click Next. Follow the instructions of the wizard to create your software module. You will have to choose the computer where the material to create your software module can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension.
Results
Parameters of the software module are pre-filled for you but they can be modified in the appropriate step of the software wizard. These parameters include: v A description that identifies the package in the software module tree. v A comment with additional information about the software module.
335
v The stage of the deployment when your software module must be installed: when the OS is installed, or after one or more additional reboot. Most of the time, you must install the package at the same time as the operating system. However, you can decide to install them in a specified order to avoid software-specific conflicts. v A file name to store your image on the provisioning server. Packages typically have a .pkg extension. v The path to where the installation files are restored on the target computer. This path is relative to the system root partition. v An additional command line that might be necessary to install your software module. When possible, the wizard suggests automatically the appropriate command line to run the installation unattended. However, you might need to add some additional parameters to the command.
Creating Linux software modules with RPM

Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. Select Linux and click Next. 4. Select A Linux application installation, using RPM and click Next. 5. Follow the instructions of the wizard to create your software module.
Results
Creating Solaris software modules with pkgadd

Procedure
1. 2. 3. 4. 5. Go to Click Go To > Deployment > OS Management > Software Modules. Click New software to run the software wizard. Select Solaris and click Next. Select A Solaris package installation, using pkgadd and click Next. Follow the instructions in the wizard to create your software module.
Results
Parameters of the software module are pre-filled for you but they can be modified in the appropriate step of the software wizard. These parameters include: v A description that identifies the package in the software module tree. v A comment with additional information about the software module.
336
v The stage of the deployment when your software module must be installed: when the OS is installed, or after one or more additional reboot. Most of the time, you must install the package at the same time as the operating system. However, you can decide to install them in a specified order to avoid software-specific conflicts. v A file name to store your image on the provisioning server. Packages typically have a .pkg extension. v The path to where the installation files are restored on the target computer. This path is relative to the system root partition. v An additional command line that might be necessary to install your software module. When possible, the wizard suggests automatically the appropriate command line to run the installation unattended. However, you might need to add some additional parameters to the command.
Creating a software module with drivers

A driver package is used to provide the appropriate driver files to Sysprep or Windows unattended installation, to install devices that are not activated by Windows because the driver is not present in the system profile.
Before you begin

The directory containing driver files must contain a file with a .inf extension. Driver packages are best used with unattended setup images, because standard Windows installation files do not always contain the drivers for recent hardware, and the goal of unattended setup is to have the target fully installed at the end of the process.
Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. Select Windows Vista/2008/7 or Windows 2000/2003/XP and click Next. 4. Select A Windows driver to include in a deployment and click Next. 5. Follow the wizard instructions to create your software module.
Results
When you indicate the directory in which the driver files are located, if several subdirectories contain drivers, the wizard lists all these directories. You must then select one or several directories. Selecting multiple directories allows you to create several driver packages at the same time with common binding rules. In case of multiple driver package creation, you can enter a folder name in which you want to store the new software modules. If the folder does not exist, the wizard creates it. If only one driver package is being created, the wizard presents the characteristics of the driver. This panel is skipped in the wizard in multiple driver package creation, but you can view the information in the software module details once the package has been created. The wizard allows you to create binding rules based on the PCI hardware ID, the baseboard ID, the computer model name, operating system architecture and targeted operating systems. Depending on your selections, the wizard provides steps with easy-to-follow instructions to create the binding rules. PCI hardware ID v If you select Use this driver for the exact same device only, the PCI vendor ID, device ID, and sub-device ID must match. v If you select Use this driver for similar devices, only the PCI vendor ID and the device ID need to match.
337
Baseboard ID You can either type in a substring of the baseboard name or select baseboard names extracted from the targets known to the provisioning server. Computer model name You can either type in a substring of the computer model name or select model names extracted from the targets known to the provisioning server. OS architecture Select Auto to use the information contained in the driver to define the binding rule. Select 32 bit, 64 bit, or Both if you know the architecture the driver has been designed for. OS targeted Select for which family of Windows operating systems the driver has been written for. The number of rules created vary depending on the selections you made, but very quickly reaches over one hundred if your rules are based on similar PCI device IDs. Parameters of the software module are pre-filled for you but they can be modified in the appropriate step of the software wizard for single driver creation. For multiple driver creation, the parameters do not appear in the wizard. They can be edited in the software details page of each driver package. These parameters include: v A description that identifies the package in the software module tree. v A comment with additional information about the software module. v The stage of the deployment when your software module must be installed: when the OS is installed, or after one or more additional reboots. Most of the time, you must install the package at the same time as the operating system. However, you can choose to install them in a specified order to avoid software-specific conflicts. v A file name to store your image on the provisioning server. Typically, packages have a .pkg extension. v The path where the installation files are restored on the target. This path must start with \drivers, because Windows unattended installation and Sysprep look in C:\drivers when installing new devices. Creating driver packages for Windows target computers: To deploy Windows target computers most efficiently, you need up-to-date drivers which are often not included with operating system installation files. These drivers can be obtained from the vendor of the server. Before you begin Before you can create your driver packages, you need to obtain the proper driver files. IBM drivers For IBM drivers, download the ServerGuide. To locate the ServerGuide, search for ServerGuide download in a search engine. Copy the ServerGuide directory. Note: ServerGuide is different from the ServerGuide Toolkit. HP drivers For HP drivers, download the SmartStart. To locate the SmartStart, search for SmartStart download. Dell Drivers To locate Dell drivers, search for Dell drivers download. The following example assumes that the drivers have been copied into the Files/import directory on your OS deployment server.
338
To create a driver package: Procedure Click Go To > Deployment > OS Management > Software Modules. Click New Software to run the software wizard. Select the relevant operating system and click Next. Select A Windows driver to include in a deployment and click Next. Select On the OS server itself (in the 'import' directory) and click Next. Select the relevant directory. For IBM drivers for a Windows 2003 operating system, this is sguide/w2003drv/$oem$/$1/drv. 7. Select all relevant drivers in the list provided and click Next. Sometimes, several versions of the same driver are available. In this case, follow these guidelines: v Select drivers without alternative, even if the name is misleading. v Select the appropriate Windows version when there are alternatives, for instance select win2003 rather than win2k or winnt for a Windows 2003 driver. 1. 2. 3. 4. 5. 6. v Select server when the alternative is between server and pro. v Avoid selecting drivers with powerpc in their name. v Avoid selecting drivers containing hardware abstraction layer (HAL). v Avoid selecting drivers with another architecture. Note: It is better to have a few extra drivers included in the package than to miss one. 8. Give a meaningful folder name to store your drivers, for instance IBM ServerGuide 2003 32bit, and click Next. 9. Select Yes, create binding rules based on: and PCI hardware ID. Then click Next. 10. Select Use this driver for the exact same device only and click Next. 11. Select the appropriate architecture and the targeted operating system and click Next. 12. Click Finish. Results You have now finished the driver package creation process. What to do next You might have to go through the driver package creation process several times, to create different driver package directories specific for operating systems and their architecture.
Creating a software module for HAL injection on a cloning image

2000 2003 XP
Hardware abstraction layer (HAL) might change from one computer to another depending on whether it has a single or multiple processors, whether it uses Advanced Programmable Interrupt Controller (APIC) and Advanced Configuration and Power Interface (ACPI). HAL also depends on the operating system. To create universal images, you might be required to have other HAL versions on your image than the original. To create a HAL software module to be injected on a golden master image during deployment, you must create a HAL software module and bind it to the corresponding images.
339
Procedure
1. 2. 3. 4. Click Go To > Deployment > OS Management > Software Modules. Click New Software to run the software wizard. Select Windows 2000 / 2003/ XP. Select A Windows HAL to include in a clone deployment.
5. Follow the wizard instructions. Different HALs are available on Windows installation CD-ROMs. The wizard offers you to create binding rules for this HAL and pre-fils some of the data to facilitate the rule creation process.
Results
You have now created a HAL software module to be injected on a cloning image during deployment.
What to do next
If you have not used the wizard to create binding rules, it is recommended that you bind your HAL package now to deploy it in appropriate contexts. Creating a software module for HAL injection on an unattended setup: Before you begin HAL injection on an unattended setup image is typically only necessary on some very specific server systems. The server vendor must then provide you with the appropriate HAL. IBM provides HALs for its servers in the ServerGuide CD-ROM To create a HAL software module to be injected on an unattended setup image during deployment, you must create a HAL software module and bind it to the corresponding images. Procedure 1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. Select Windows 2000 / 2003/ XP. 4. Select A Windows driver to include in a deployment. 5. Follow the wizard instructions. When asked for the driver file location, provide the path to the HAL. Results You have now created HAL injection on an unattended setup image. What to do next If you have not used the wizard to create binding rules, it is recommended that you bind your HAL package now to deploy it in appropriate contexts.
Creating a software module for custom actions

Software modules can also contain custom actions to be performed on the target. They are divided into: v An OS configuration change to perform on the target. v A set of files to copy on the target. Note: This task contains a set of general instructions for creating software modules on any platform. For more details about creating software modules on Windows, see Creating a software module for custom actions on Windows on page 341.
340
Configuration changes are further subdivided. Depending on the operating system, you can: v Copy a single text file. v Execute a single command file. v Boot a floppy disk. The following example shows how to create a software module of the common agent.
Procedure
1. 2. 3. 4. 5. Click Go To > Deployment > OS Management > Software Modules. Click Create to run the software wizard. Select the operating system and click Next. Select A custom action on the target computer and click Next. Follow the instructions of the wizard to create your software module.
Results
Parameters of the software module are pre-filled for you but they can be modified in the appropriate step of the software wizard. These parameters include: v A description that identifies the package in the software module tree. v A comment with additional information about the software module. v The stage of the deployment when your software module must be installed: when the OS is installed, or after one or more additional reboot. Most of the time, you must install the package at the same time as the operating system. However, you can decide to install them in a specified order to avoid software-specific conflicts. v A file name to store your image on the provisioning server. Packages typically have a .pkg extension. v The path to where the installation files are restored on the target computer. This path is relative to the system root partition. v An additional command line that might be necessary to install your software module. When possible, the wizard suggests automatically the appropriate command line to run the installation unattended. However, you might need to add some additional parameters to the command. Repeating custom actions: Some commands must be run every time the target boots during a deployment. This is typically the case if you want to repeatedly mount a network share. This connection is destroyed when rebooting. You can therefore create a single software module to mount the network share and set this software module to run once after each reboot, starting at a specific reboot. This option is available for executing a single command. Procedure 1. Create your software module. 2. Double-click the software module name in the Software components page to display the Software details page 3. Click Edit in the title of the Package information section. 4. Select the installation stage at which the software module must be applied first. 5. Select Run at each software pass until end of deployment and click OK. Creating a software module for custom actions on Windows: Software modules can also contain custom actions to be performed on the target. They are divided into:
341
Vista
2008
A WinPE 2.0 image (option present only for Windows Vista and Windows 2008
software modules ). Note: To create a WinPE 2.0 image, the Web interface extension must be started with administrator privileges. A WinPE 1.0 Ramdisk image (option present only for Windows 2000/2003/XP software modules). v An OS configuration change to perform on the target. v A set of files to copy on the target. v
XP 2003
Configuration changes are further subdivided into: v v v v v v Copy and execute a single file. Apply a Windows registry change. Apply a Windows .ini file change. Copy a single text file. Execute a single command file. Boot a virtual floppy disk. Note: Virtual floppy disk software modules can only be created from a Windows operating system running the web interface extension. Procedure 1. 2. 3. 4. 5. Click Go To > Deployment > OS Management > Software Modules. Click New Software to run the software wizard. Select the operating system and click Next. Select A custom action on the target and click Next. Follow the instructions of the wizard to create your software module.
6. You will have to choose the computer where the material to create your software module can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension. Results Parameters of the software module are pre-filled for you but they can be modified in the appropriate step of the software wizard. These parameters include: v A description that identifies the package in the software module tree. v A comment with additional information about the software module. v The stage of the deployment when your software module must be installed: when the OS is installed, or after one or more additional reboot. Most of the time, you must install the package at the same time as the operating system. However, you can decide to install them in a specified order to avoid software-specific conflicts. v A file name to store your image on the provisioning server. Packages typically have a .pkg extension. v The path to where the installation files are restored on the target computer. This path is relative to the system root partition.
342
v An additional command line that might be necessary to install your software module. When possible, the wizard suggests automatically the appropriate command line to run the installation unattended. However, you might need to add some additional parameters to the command. Example As examples are described the complete step-by-step process of creating a software module with the content of the second CD-ROM of a Windows 2003 R2 distribution (see Creating a software module for unattended deployment of Windows 2003 R2), and of creating a ramdisk from a bootable diskette (see Creating a ramdisk software module from a bootable diskette on page 344). Repeating custom actions: Some commands must be run every time the target boots during a deployment. This is typically the case if you want to repeatedly connect to a network share. This connection is destroyed when rebooting. You can therefore create a single software module with a netuse command to set the network share and set this software module to run once after each reboot, starting at a specific reboot. This option is available for v Windows registry changes. v Copying and executing a single file. v Executing a single command. Procedure 1. Create your software module. 2. Double-click the software module name in the Software components page to display the Software details page 3. Click Edit in the title of the Package information section. 4. Select the installation stage at which the software module must be applied first. 5. Select Run at each software pass until end of deployment and click OK. Creating a software module for unattended deployment of Windows 2003 R2: To prepare an unattended deployment of Windows 2003 R2, you must include some of the content of the second CD-ROM of the distribution in a software module and bind this software module to the image created with the first CD-ROM. Procedure 1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. Select Windows 2000 / 2003 / XP. 4. Select A custom action on the target. 5. Select A set of files to copy on the target (with an optional command to execute). 6. 7. 8. 9. Indicate on which computer the files of the second CD-ROM are located. Indicate the complete path to find the files in /CMPNENTS/R2, for example D:/CMPNENTS/R2. Verify the proposed description and if necessary, modify it. Optionally, enter a comment. Enter the necessary parameters for this specific software module: v Apply the software module After one additional reboot. v Enter a meaningful package file name, with a .pkg extension. v Use \install\R2 as destination path. v Do not forget the command-line to be run on the target:
343
cmd /c \install\R2\setup2.exe /q /a /p:xxxx-xxxx-xxxx-xxxx-xxxx /cs
where xxxx-xxxx-xxxx-xxxx-xxxx is the product key. 10. Wait during the package generation process and click Finish. What to do next Bind your software module to your Windows 2003 R2 unattended setup image (see Automatic binding rules on page 347). Creating a ramdisk software module from a bootable diskette: Creating a ramdisk software module from a bootable diskette is considered by the software module wizard to be a Configuration change, which itself is included in the Custom action. Procedure 1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. Select Windows 2000 / 2003 / XP. 4. Select A custom action on the target. 5. Select a Configuration change. 6. Select Boot a virtual floppy disk. 7. Specify which computer the bootable diskette must be read from. This can be either on the local computer or on another computer running the web interface extension. The option On the server itself must not be used. If the diskette drive is added after the web interface extension is started (on the local or remote computer depending on your choice), it might be necessary to stop and restart the web interface extension to enable it to detect the diskette drive. Moreover, the diskette must not be opened by another application (such as Windows Explorer), as this might cause interference. Note: The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension. 8. Insert the bootable diskette that you want to image and run as a ramdisk in the disk drive and click Next. 9. Enter a software module description and click Next. 10. Specify parameters for the package creation and click Next. Results The software module is created. Creating a software module of the common agent: This example shows the steps for creating a software module of the Tivoli Common Agent. v The Agent Manager must be installed on the same server as Tivoli Provisioning Manager. The Agent Manager is installed during Tivoli Provisioning Manager installation. v The following Tivoli common agent installable packages have to be present in the local file repository root path: common_agent_1.4.1.0_200810230654_aix.tar common_agent_1.4.1.0_200810230654_linux_ppc.tar
344
common_agent_1.4.1.0_200810230654_linux.tar common_agent_1.4.1.0_200810230654_solaris.tar common_agent_1.4.1.0_200810230654_windows.exe The local file repository path is: TIO_HOME\repository. v A number of configuration scripts must exist inside the TIO_HOME/tools/prepare_tca_image folder. These scripts are: caInstall.rsp checkDiskSpace.vbs ihscript.vbs install.bat install.sh All of the scripts listed above will be used during an offline installation of the Tivoli Common Agent that will be performed on a target system once an OS image has been successfully deployed. v A script, prepareTCAImage, used for preparation of the Tivoli Common Agent and Tivoli Provisioning Manager subagent installation images must exist inside the tools folder. Either %TIO_HOME%\tools\ prepareTCAImage.cmd or $TIO_HOME/tools/prepareTCAImage.sh. This script will be executed by a workflow code and it will generate a number of Tivoli Common Agent offline, platform specific, installation packages. It also extracts the common agent installation parameters, such as the agent manager registration password, and writes them to a response file, caInstall.rsp. To 1. 2. 3. create a software module: Click Go To > Deployment > OS Management > Boot Servers. In the Select Action menu, select Create Tivoli Common Agent Software Modules. Click Yes when prompted to go to the Provisioning Task Tracking application.
The Provisioning Task Tracking application opens and you can monitor the progress of your software module creation.
Keeping command lines confidential

When you use command lines in your software modules, their call and their output are stored in deployment logs. In some circumstances, for instance when the command line includes a password or a product key, it might be necessary to keep the information contained in the command line confidential. Three levels of confidentiality are available. No confidentiality The command line is visible in the web interface and on the target during the installation, its call is logged, and its output is also logged. The command line call is not logged The command line is visible in the web interface, and its output is logged, but the command line call, containing the whole command line string with all parameters, is visible in the logs neither on the web interface nor on the target. To apply this level of confidentiality, you must prefix the command line by one exclamation mark (!). The command line call and output are not logged The command line is visible in the web interface, but its call and output are visible in the logs neither on the web interface nor on the target. To apply this level of confidentiality, you must prefix the command line by two exclamation marks (!!).
345
The command lines and their optional confidentiality markers can be entered either in the Software wizard or when you edit the Package information (Click Go To > Deployment > OS Management > Software Modules. ) Once on the Software Modules page, select the software module that you want to edit.
Scheduling the application of software modules

When several software modules are associated with an image, you can schedule when they are applied. Note: 1. Windows language packs, Windows HotFixes, and Windows drivers are always deployed right after the operating system. Their ordering cannot be modified. Therefore, they do not appear in the Software application order window. 2. Solaris software modules are always applied right after operating system installation. Reboots are not handled under Solaris. To schedule the application of software modules, click Reorder software at the bottom of the software modules page. This opens a dialog window that allows you to order the different software modules stored on your provisioning server. The dialog shows the different steps of a deployment with disk partitioning (in green), OS installation (in purple) and reboots (in red). Software components can be installed in between all of these steps, where they are placed inside the expandable installation stages (in yellow). You can add, move, and delete reboot sequences by using the buttons at the bottom of the dialog window. You can also rename software installation stages. You can expand the software installation stages to view their content by clicking on the + icon. You can then move individual software modules from one stage to another by drag-and-drop. The destination stage does not need to be expanded. Note: Drag-and-drop is limited to the Software Application Order window. The software modules are not ordered within an installation stage. If you want a software module to be installed before another between two specific reboots, create two distinct installation stages between the reboots. For example, if your first software module copies files on the target and the second one runs a command on these files, you must place the first software module in an installation stage which occurs before the one in which you run the command software module. Typical application locations for software modules include: v For virtual floppy-disk used as ramdisk: before disk partitioning and OS installation, in order to allow for the configuration of low-level hardware devices controlling the hard disk, such as RAID controllers. v For virtual floppy-disk images: in between disk partitioning and OS installation, in order to flash devices early. v Sysprep and unattended setup processes are automatically run during the OS installation phase, if required. v For system snapshots: right after OS installation, to deploy the software nearly at the same time as the operating system image (the most efficient). Before OS installation is forbidden, as a system snapshot needs an installed OS. v For other software: when the OS is installed or after additional reboots, depending on the software module needs.
346
Part 4: Binding rules

In this section of the tutorial, you will learn how to associate or bind a software module to targets. Software bindings correspond to the list of software modules currently assigned to the target.
Binding software modules to targets

Binding software modules to target computers enables automatic deployment. When binding to target computers, you explicitly provide the list of software modules to bind to your target computers. To explicitly bind a software module to target computers follow these steps:
Procedure
1. 2. 3. 4. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. In the list of computers, click the name of the appropriate computer. Click the Deployment Properties tab. Click the Bindings tab, then click Software bindings.
5. Click Edit to modify the bindings. 6. Select the software module to associate with deployment to this computer. 7. Click OK.
Results
You have now bound a software module to a target computer.
What to do next
You can also deselect items to remove their explicit bindings. To remove a binding by rule, you must modify the rule.
Automatic binding rules

Automatic binding rules are used to create bindings between software modules and target deployments, without having to specifically bind a software module on each target deployment. Rules are created in software modules to determine which deployment on atarget will automatically be bound to the software module. Rules are made of criteria and values. If a target has a matching value for all criteria in the rule, the software module is bound to that target. For example, if the criteria is the model name, and the value is Optiplex, targets with a model name starting with Optiplex will be bound to the object where the rule has been defined. To create a binding rule:
Procedure
1. 2. 3. 4. 5. Click Go To > Deployment > OS Management > Software Modules. Select the software module that you want to use for the new binding rule. Click the software module that you want to bind. Details about the software module are displayed. Click New rule. When adding a binding rule to a software module, you can set values for the following criteria: v A deployment scheme v An image v A current OS configuration
347
v One of the system-definable and user-definable fields of the database (only used if you have customized the database) v An operating system type, such as Windows 2000 v An operating system version, such as SP2 v An operating system language v An operating system architecture, such as x86-32 v A computer model name v A BIOS version v A PCI device v A base board v A free-text condition in Rembo-C; syntax For example, to create a binding based on the operating system type between a software module and targets, you must create a rule, click OS type, and select the operating system version that you want to limit this software module to. 6. When adding a binding rule to an OS configuration, you can set a condition on the deployment scheme, and on the computer model name. The next four fields are only used if you have customized your database and want to match specific user categories. 7. Finally, you can enter a free-text condition following the Rembo-C; syntax. Free-text conditions follow a Rembo-C; syntax. They must only be used by advanced users. The conditions determine the applicability of the rule and evaluate to true or false. A condition must be formed using the variables also used for keyword substitutions in software modules, combined with Java-like logical operators, listed by order of priority in the table below:
Table 56. Logical operators for free-text conditions Operator < <= => > == != && || Meaning smaller than smaller than or equal to greater than or equal to greater than equal to not equal to AND operator OR operator
For example, a typical condition can be:

Disk[0].DiskSize > 10*1024*1024
Note: If a condition cannot be evaluated, it is considered to have the value false.
Results
You have now created an automatic binding rule.
Binding drivers in version 7.1.1.4 and higher

If you have upgraded to Tivoli Provisioning Manager for OS Deployment version 7.1.1.4 or higher, there is an option for Windows device drivers to use a driver specific binding rule method. To learn more about using this option, see the detailed information in the following documents: Managing multiple WinPE 3.0 deployment engines on page 289
348
Binding drivers to Windows images on page 324
Part 5: Installing an image

In this part, you will learn how to install images.
Installing an image
You can now deploy the image to the target computer. The BIOS startup sequence of this computer must first have network and then hard disk for this installation task to complete successfully. If you are deploying the Tivoli Common Agent with a Linux golden master or unattended setup image, we recommend you have a minimum of 2 GB of swap space for the image. To specify this: Click Go To > Deployment > OS Management > Images. Select your image, then click the Properties tab, then the Disks tab. In this task, you will deploy the image to the target computer. To install the image on the computer: 1. Click Go To > Deployment > OS Management > Image Deployment. 2. Specify a name for the image deployment task or accept the default name. 3. Select the image that you want to install. 4. Select the target computer for the image installation. Note: During an unattended deployment of an ESXi server, you must set the boot setting of the target setting to Kernel free mode. The Kernel free mode only works with the PXE deployment. a. To set boot mode to Kernel free mode, go to Target Details > Edit Boot Mode > Use Kernel free mode. b. Save changes. 5. Choose to schedule the task or run it immediately. 6. Click Submit. The task will be run. Monitor its progress until the task has completed. Click Refresh to see the updated status. a. To view the task progress in detail, click the task name to open the task details page. In the Deployment Request Details column, click Request ID to view the provisioning workflow execution log. b. If the target computer is already managed by Tivoli Provisioning Manager, Tivoli Provisioning Manager will attempt to reboot the machine so that the deployment activity can run. If Tivoli Provisioning Manager cannot restart the machine, then Tivoli Provisioning Manager will schedule the OS deployment activity, and you must boot the machine manually. When the machine boots off the network (and gets picked up by the OS deployment server), it will then run the OS deployment activity. You have now deployed an image to your target computer. After you install an image of Windows 2000 using Tivoli Provisioning Manager for OS Deployment, you must log on to the Windows 2000 computer locally, with the Administrator credentials, for all disk partitions to be created correctly. If you log into the computer remotely for the first time after installing Windows 2000, some disk partitions might not appear in the Windows registry.
2000
Microsoft Sysprep, with Windows 2000 setup, will not configure a static IP network configuration. When you log on to Windows 2000, a network script is executed to configure the network. On the Windows 2000 computer, navigate to Start > Settings > Network and Dial-up Connections. From the menu, select View and then click Refresh to view the network connections configuration changes.
2000
349
The software inventory on the target computer might not be up to date after installing a Tivoli Provisioning Manager for OS Deployment image. We recommend you perform the following discoveries to update the software inventory on the target computer: 1. Install Tivoli Common Agent 2. Tivoli Provisioning Manager inventory discovery You can perform this task by running the Computer Discovery, Common Agent Installation and Inventory Discovery out-of-the-box scenario: Discovering your environment using the ready-to-use network discoveries on page 231.
Security
This section provides the user with information regarding security issues with Tivoli Provisioning Manager for OS Deployment.
Avoiding new vulnerability issues

After you have installed the provisioning server on your network while taking into account network security constraints, you still need to ensure that using Tivoli Provisioning Manager for OS Deployment does not create new vulnerability issues. You should: v Protect your network against rogue PXE servers that can have access to your network. Otherwise, target computers can boot on the rogue server instead of the legitimate PXE server. v Prevent unwanted target computers from booting on your PXE server, unless you want to risk transferring sensitive information to unsecure computers.
Backup server files

Tivoli Provisioning Manager for OS Deployment operating system images and other files are stored in a folder, and are accessible using file browsing tools. All of these files are stored in the data directory (typically C:\TPMfOS Files for Windows). This directory contains regular files and control files, with .md5, .dir and .inodes extensions. These special files contain information about the file system structure, including the internal file number used by the provisioning server to identify a file. When backing up files, it is important that you include both regular files and the provisioning server special files. When restoring files (or adding individual files), the provisioning server automatically detects new files and creates associated control files. Adding a file does not necessarily mean that the file will be usable by the provisioning server. A database entry is typically needed to describe what the file is used for. If you only want to back up a specific deployment scheme, image, or software module, it is easier to use RAD files.
Rogue PXE servers

A rogue PXE server is a server on a network which is not under the administrative control of the network staff. By default, the PXE protocol is not protected against rogue PXE servers when it is working in boot discovery mode. There are ways to prevent this type of breach.
350
The target sends broadcast packets to the network requesting a PXE answer. The first PXE server to respond to the request takes control of the target computer. A rogue PXE server answering the request faster than the legitimate Tivoli Provisioning Manager for OS Deployment PXE server can take control of computers booting onto the network. Using PXE in boot discovery mode is a well known security breach, independent from Tivoli Provisioning Manager for OS Deployment. While DHCP discovery must broadcast requests (the target computer does not yet possess any network information), there are ways to prevent the PXE security breach and allow only authorized PXE servers to answer requests from target computers.
Using DHCP options to close the breach

Deactivate boot discovery mode for PXE targets. After this is done, computers trying to contact a PXE server must know the specific address and can no longer send broadcast packets. Information is transferred at the DHCP stage, by using options 60 and 43. Using these options, the DHCP server returns the target its IP address and the IP address of the authorized PXE server. If necessary, option 43 can contain several IP addresses for backup servers.
Network security constraints

In many enterprise environments, an administrator must consider network security constraints. For example, some ports can be unavailable to secure network traffic in and out of the enterprise. By default, Tivoli Provisioning Manager for OS Deployment uses the following ports on the provisioning server for communication: v DHCP : port 67 UDP v PXE BINL : port 4011 UDP v TFTP : port 69 UDP v MTFTP : port 4015 UDP v v v v v v NBP : port 4012 UDP FILE : port 4013 UDP & TCP MCAST : port 10000-10500 UDP Address: 239.2.0.1-239.2.1.1 HTTP (Web Interface) : port 8080 TCP HTTPS : 443 TCP Java gateway : port 2020 TCP
On targets, the default ports are the following: v DHCP : port 68 UDP v MTFTP : port 8500-8510 Address: 232.1.0.1 UDP v MCAST : port 9999 UDP v Remote control (web interface extension) : port 4014 UDP All of these ports can be modified, with the exception of port 69 for TFTP. Port 69 is part of the PXE specification, independent from Tivoli Provisioning Manager for OS Deployment, and cannot be modified. Any product using PXE boot needs to have this port open to permit PXE boot. This port needs to be open only on the provisioning server, not on the target computers.
Reference
351
Upgrading Tivoli Provisioning Manager for OS Deployment to a later version

Tivoli Provisioning Manager for OS Deployment is installed as part of the Tivoli Provisioning Manager 7.2 installation. If necessary, when a newer Tivoli Provisioning Manager for OS Deployment build becomes available, you can download it and then upgrade your Tivoli Provisioning Manager for OS Deployment to this later version. You can upgrade to a Tivoli Provisioning Manager for OS Deployment version later than or equal to the version released with Tivoli Provisioning Manager version 7.2.
Obtaining the latest Tivoli Provisioning Manager for OS Deployment build

Build packages and fixes for Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images are published on IBM Fix Central. The packages can be found by accessing the Fix Central section of the Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images Support Web site, at http://www.ibm.com/support/fixcentral. The license for Tivoli Provisioning Manager for Images provides you with an entitled IBM ID, which is required for the downloads. If you do not have an entitled IBM ID, you will see the fixes, but you will not be able to download them. To download the packages for Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images:
Procedure
1. Select Tivoli for the Product Group. 2. Select the Tivoli Provisioning Manager for OS Deployment or the Tivoli Provisioning Manager for Images product. 3. For the Installed Version, select the build number that matches the number of the Tivoli Provisioning Manager for OS Deployment build that was shipped with Tivoli Provisioning Manager 7.2. 4. Select the platform, and then click Browse to find the required packages and fixes. 5. Click Continue.
Upgrading to the latest Tivoli Provisioning Manager for OS Deployment build

To upgrade your Tivoli Provisioning Manager for OS Deployment to a later version:
Procedure
1. Obtain the new Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images full build for the platforms used in your environment. If you are unsure, download all platforms. See Obtaining Tivoli Provisioning Manager for Images on page 396. 2. Extract all .exe files (self-extracting Windows 32-bit and 64-bit installables) to obtain the required .msi files. If you want, you can delete the .exe files. 3. Place all the Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables (tar.gz and .msi files) into the $TIO_HOME/repository/tpmfosd folder (for Windows, %TIO_HOME%\repository\tpmfosd). Note: Ensure that permissions for the files placed in the repository are set so that they are owned by tioadmin. 4. Discover the new Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables: a. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations.
352
b. In the Discovery Configuration list, click TPMfOSD Version Discovery, and then click Run. This will discover the Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables that you have placed in the repository, and will also create Tivoli Provisioning Manager software products that represent the new versions of Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images. 5. Stop Tivoli Provisioning Manager for OS Deployment on all of your servers, except the one running on the local Tivoli Provisioning Manager server. 6. Perform the following: a. In Tivoli Provisioning Manager, run a software product upgrade for Tivoli Provisioning Manager for OS Deployment on the local server: 1) Click Go To > Deployment > Software Management > Software Product Upgrade. 2) On the Software Product Upgrade page, select Tivoli Provisioning Manager for OS Deployment as the software to upgrade.
Windows
Note: For details about the OSD_HOME installation directory, see ../ com.ibm.tivoli.tpm.ins.doc/install/rpath_variables.dita. 3) Select the target computer, which is the local Tivoli Provisioning Manager server, then select Upgrade to a new version as the upgrade method. 4) Click Submit. This will upgrade the local Tivoli Provisioning Manager for OS Deployment server to the new version that you have selected. b.
UNIX Linux For non-Windows Tivoli Provisioning Manager servers, the upgrade of the local Tivoli Provisioning Manager for OS Deployment server must be done manually, as Tivoli Provisioning Manager does not have root access to the local system:
Note: Due to a known limitation, step 6 b is required only for the local Tivoli Provisioning Manager server. For all the other Tivoli Provisioning Manager for OS Deployment servers, only step 6 a is required, regardless of their operating system. 1) Stop Tivoli Provisioning Manager for OS Deployment (stop the rembo, rbagent, and dbgw processes). 2) Untar or gzip the new Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installable to the Tivoli Provisioning Manager for OS Deployment installation directory. This will overwrite the old installation file with the new one. 3) Start Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images. 4) Run the TPMfOSd Version Discovery (Click Go To > Discovery > Provisioning Discovery > Discovery Configurations.) to ensure that Tivoli Provisioning Manager is up-to-date with the new version that you upgraded manually. 7. If you have more than one Tivoli Provisioning Manager for OS Deployment servers in your environment, you must now upgrade your other servers, too. Repeat step 6 a and run the software product upgrade for all the other Tivoli Provisioning Manager for OS Deployment servers in your environment. This can be done for all server types. Note: If the local Tivoli Provisioning Manager server is not the parent server, the parent server must be upgraded before any child servers. Upgrade the Tivoli Provisioning Manager for OS Deployment servers one at a time.
Results
You have finished upgrading your Tivoli Provisioning Manager for OS Deployment to a later version.
353
Tivoli Provisioning Manager for OS Deployment boot server configuration

Tivoli Provisioning Manager for OS Deployment boot server can be accomplished by modifying the main server side OS configuration parameters. They can be modified either in the web interface or directly by editing the rembo.conf file. The parameters are divided into seven categories that mirror the sections found in the web interface. They are: v v v v v v v Debug level information Base parameters Web interface parameters Boot module parameters Network boot module parameters File access module parameters HTTP Console Security parameters
Most parameters can be modified in the web interface: Click Go To > Deployment > OS Management > Boot Servers. For more details, see: Modifying OS configuration parameters on page 360.
Base parameters
Debug level information GlobalDebugLevel number specifies the level of details that must be placed in the log file. IP address of the backup server Backup ip-addr defines the IP address of a backup server that can be used by the target if the primary server fails. The backup server must have the same Net Password as this server. For the backup recovery system to work, the backup server must also contain an exact copy of the files stored on primary server. Maximum size of the server log files MaxLogSize number limits the size of the log file generated by the provisioning server. The maximum log size is specified in bytes, and applies to all log files created by the provisioning server. If you do not specify this parameter is not set, or set to 0, then log files are not limited in size. If a limit is set, and the server reaches this limit, the current log file is backed up and a new file is created. CountersInterval minutes specifies the interval, in minutes, for the server statistics measures. Network interfaces used by the server Interfaces ip-addr specifies the list of network interfaces that the provisioning server uses when sending and receiving packets to and from targets. If you leave this option unspecified, the server uses the network interface corresponding to the official hostname of the server. The format is a list of IP addresses, separated by spaces.
web interface parameters

You can modify these parameters with caution, and only if you are familiar with them. v Disable the HTTP module DisableHTTP disables the web interface. If you set this parameter, run the -c command-line option to change server parameters. Note: You must not disable the HTTP module as the Tivoli Provisioning Manager functionality integrated with will cease to be available. v Disable HTTP SSL encryption DisableSSL disables encryption in the Web interface and enables unencrypted HTTP connections.
354
v TCP port for HTTP requests, TCP port for encrypted HTTP requests (SSL) HTTPServerPort port specifies the TCP port used by the Web interface when listening for unencrypted HTTP requests. You can set this parameter to 80 if you want the Web interface to be accessible by typing the server host name in your Web browser. To make the Web interface accessible by typing https followed by the server host name, set this parameter to 443. v Inactivity timeout before a session expires HTTPSessionTimeout minutes specifies the timeout (in minutes) before Web interface users are automatically logged out. A typical value is 5 minutes. Disable HTML contextual menus DisableContextualMenu disables the contextual menu. When you use a right-click in the web interface, you will see the regular contextual menu of your browser. Disable HTML drag-and-drop DisableDragAndDrop disables web interface drag-and-drop operations on selected icons. Drag-and-drop works on most common browsers, but it can be disabled in case of incompatibility. Disable javascript drop-down lists DisableJSDropDown disables enhanced drop-down menus in favor of standard drop-down menus. Standard drop-down menus do not recognize DHTML layers under Internet Explorer, so this parameter can cause problems. Disable the use of cookies DisableCookies disables the use of cookies in the web interface. Disabling cookies does not prevent you from using any essential function of the console. Disable HTTP transfer optimization DisableHTTPOptim disables the optimization of HTTP transfer in the web interface. Set this parameter if you do not want the web interface to group JavaScript, stylesheets, and images into large files to reduce HTTP traffic and enhance the cache process. You must disable this optimization if you are creating console pages.
Boot module parameters

v Disable DHCP/BINL module DisableBOOT disables the PXE component of the provisioning server. v Disable the DHCP proxy functionality DisableDHCPProxy disables the DHCPProxy service on the provisioning server. The server does not send extended DHCP replies (PXE replies) to DHCP discovery packets sent on the network by remote-boot target. When the DHCP proxy is disabled, the DHCP server must be configured to provide a complete PXE answer to PXE targets, including option 60 and option 43. DHCP proxy mode must be disabled if you have more than one provisioning server operating on the same subnet. v Disable the multicast BINL functionality BootNoMulticastDiscovery disables PXE multicast discovery support on the provisioning server. When PXE multicast discovery is disabled, target computers with multicast discovery configured in DHCP option 43 are not able to find the provisioning server. v UDP port for TFTP requests TFTPPort is the port used on the provisioning server to receive TFTP request packets from PXE targets. The default value is 69. Note that unless your network equipment is automatically routing TFTP packets to a non-standard part, you must not change this setting because PXE always sends TFTP requests to port 69, without any possibility to change port. v Max. TFTP Segment Size MaxTFTPSegSize bytes is the maximum size in bytes for TFTP segments. The default value is 512 but a smaller one can be given if the network configuration requires it. v Seconds to wait before starting a MTFTP stream
355
MTFTPStartDelay secs specifies the time, in seconds, to wait before starting a MTFTP transfer. This period is used by target computers to replicate together. The higher the value is, the more replicated the deployment engine is. However, latency is introduced when booting target computers individually. The PXE standard default value is 2. v IP address used by targets for MTFTP MTFTPClients port [:target-port ] specifies the multicast IP address and port used by the provisioning server when sending MTFTP data to target computers. v UDP port for MTFTP requests MTFTPPort port specifies the UDP port used by the provisioning server to receive MTFTP request packets from target computers. The default value is 4015. v Seconds to wait before sending DHCP/BINL answers BootReplyDelay secs specifies the number of seconds to wait before answering DHCP/BINL request packets sent by target computers. If you have more than one provisioning server on the same subnet, target computers use the server with the lowest shortest reply delay. The default value is 0 (no delay). v Max. number of requests per minute (load balancing) BootReplyLimit number specifies the maximum number of DHCP/BINL requests to a provisioning server in one minute. The server discards boot requests coming from target computers when the specified limit is reached. A number of 0 indicates unlimited requests. This parameter can be used to implement load balancing over multiple servers. v UDP port for DHCP/BINL requests BootDiscoveryPort port specifies the UDP port that the provisioning server uses when listening for BINL boot requests. The default port used for a standard target computer is 4011. v Multicast IP address used for BINL requests BootDiscoveryAddress ip-addr specifies the multicast IP address that the provisioning server listens to when waiting for BINL multicast requests coming from target computers. This value must match the value set in the DHCP option 43 sent to targets. v No-boot schedule NoBootSchedule specifies the frequency at which the provisioning server stops providing a PXE boot service. It is used in conjunction with NoBootDuration. Modify this parameter using the web interface only. v No-boot duration in minutes NoBootDuration specifies the duration in minutes during which the provisioning server stops providing a PXE boot service if a no-boot schedule is specified. It is used in conjunction with the parameter NoBootSchedule. Modify this parameter using the web interface only.
Network boot parameters

v Disable the NBP module DisableNBP disables the NBP component of the provisioning server. Because NBP is used by target computers when booting, target computers are not able to boot if NBP is disabled. v UDP port for NBP requests NBPServerPort port specifies the UDP port used by the provisioning server to receive NBP requests from target computers. The default value is 4012. Only change this value if the default port is already used by another application on your computer.
File access module parameters

v Disable the FILE module DisableFILE disables the FILE (NetFS, MCAST) component of the provisioning server. If you disable the FILE server module, target computers are not able to boot on this server. v Base directory for server files
356
BaseDir string specifies the base directory for the provisioning server. All paths included in the OS configuration are relative to this base directory. This is a mandatory parameter, and has no default value (if you are using file-based configuration mode, you must set it before starting the provisioning server for the first time). Relative directory for the shared repository SharedDir path specifies the path relative to the server file directory for storing the shared repository internal files. By default, this parameter is set to shared. First multicast IP address used for MCAST transfers FileMCASTAddress ip-addr:port specifies the multicast IP address used when sending packets to target computers. The provisioning server can generate different multicast IP addresses using this parameter as the base for the first address in a range. Number of multicast addressed to use for MCAST transfers FileMCASTAddrCount number specifies the number of multicast addresses that the provisioning server can use when sending multicast data to target computers. This parameter sets the size of the range of multicast addresses that the server can use. This range begins with the address set by the parameter FileMCASTAddress. Maximum number of PCAST connections FileMaxPCASTSessions indicates the maximum number of PCAST sessions that the provisioning server accepts simultaneously. This parameter is relevant if the server is running in UNICAST mode and deploying a group with the UNICAST setting. Port for FILE requests FileServerPort port specifies the UDP port used by the provisioning server to receive transfer protocol control requests. The default value is 4013, but you can change this parameter if port 4013 is already used by an application on your computer. Disable the TCP module DisableTCP disables the TCP component of the provisioning server. Target computers might not be able to boot on this server if you disable the TCP server module.
v Directory for internal files DataDir path specifies the path relative to the provisioning server base directory for storing files accessible to the target computer. By default, this parameter is set to files.
Network share module

v Network UNC path NetworkShare path specifies the path of the shared partition directory of the provisioning server. This parameter can be used to increase the deployment speed of some operating systems. You need to have set the partition as read-only for the user entitled to access the network share. v User entitled NetworkUser "string" is the name of the user entitled to access the network share. If the user is part of a domain, use the syntax Domain/User. v Password of the user NetworkPasswd "string" is the password used to access the network share. The password is stored in an encrypted format in the rembo.conf file. Note: If the Network UNC path, the User entitled, or the Password of the user are not correct, you get an error when trying to deploy using the network share. If the Network UNC path is empty, the deployment does not try to use a network share.
OS deployment server replication

Replication keeps databases, files, and information up-to-date between parent and child OS deployment servers. It can be performed through several mechanisms.
357
Replicated objects
The following objects are replicated between parent and a child OS deployment servers: v Deployment schemes v Hardware configurations v Software modules v Images, including virtual images With a good network connection between your servers and your database, you can choose one of the following replication mechanisms: v Automated, whenever it is needed, using a config.csv file. v Automated, at scheduled times. v Manual, using the web interface or a command line (web interface extension). See the related links for more information about replicating with a schedule or manually, using the web interface or the web interface extension.
Replicating OS deployment servers with a schedule

To replicate your OS deployment servers regularly, you can set up a replication schedule, indicating the frequency of the replication
Before you begin

If you have a hierarchy of more than two levels of parent and child servers, the scheduling must match the hierarchy. Top servers must be replicated first, and child servers after. Important: The replication schedule for each server is determined by the config.csv file at the Tivoli Provisioning Manager for OS Deployment start time. If you change the replication schedule in the web interface (on the Replication tab), it will not be saved after restarting; the values from the config.csv file will be used instead. For a persistent change to the replication schedule, you must edit the config.csv file.
Procedure
v For a persistent change, edit the config.csv file to include the new replication schedule. v Otherwise, use the web interface to set up a replication schedule. For each child server in the hierarchy: 1. Click Go To > Deployment > OS Management > Boot Servers. 2. Click the boot server to work with, then click its Replication tab. 3. Click Set up a replication schedule. 4. Enter the start date and time, and the frequency of the replications. As child servers must be replicated after their parents, you must use the same or a lower frequency than the replication schedule on the parent server. 5. Click OK.
Replicating an OS deployment server once manually

Replicating OS deployment servers can be done manually with the web interface or with the web interface extension.
Procedure
v With the web interface: 1. Click Go To > Deployment > OS Management > Boot Servers. 2. Click the boot server to work with, then click its Replication tab.
358
3. Select the OS deployment server you want to replicate. 4. Click on the link to replicate the server. The exact wording of the link depends on whether the server needs to replicate, and on the position of the server in the hierarchy. v With a command line and the web interface extension: 1. On the child server, open a command line shell. 2. Go to the directory where rbagent is located. 3. Run rbagent rad-srvsync.
What to do next
Now, you can replicate the children of this OS deployment server. You can also set up a replication schedule.
Server replication status

You can see the server replication status on the server's Replication tab, in the web interface. Click Go To > Deployment > OS Management > Boot Servers. Click the server to work with, and then click its Replication tab. The icons on this page are visual indicators for the replication status of your servers.
Status
v On the lower left hand-side of a server icon, the up/down indicator is displayed. The status indicator can take two different values:
A blue circle with a light center, indicating that the OS deployment server is up and running.
A black dot, indicating that the OS deployment server is down. v On the lower right side of a child server icon, the replication status indicator is displayed. The status indicator can take three different values:
A cross in a red dot indicates that the selected child server is not up-to-date with its parent. Files are missing on the child server; the child server must be replicated with its parent before any action is performed.
A yellow triangle with an exclamation point indicates a warning. A discrepancy was discovered between the child and the server files. Some files can have been updated or added on the parent server. Click Object version to view which deployment objects are not up-to-date. If you plan to use any of these objects, you must replicate your server first. This page contains yellow triangles if SSL is not disabled or if the servers are temporarily unresponsive.
A green dot with a white check mark indicates that the child server is up-to-date with its parent. Note: When a server is down, it keeps the replication status indicator it had when it was last running. Replicating while a server is down is not possible.
359
Modifying OS configuration parameters

The following list provides detailed explanations of the parameters used in the rembo.conf file and the web interface. Backup Name Backup IP address of backup server. Synopsis Backup ip-addr Location v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab, and select Base Parameters. v rembo.conf: Beginning of the file. Description This parameter defines the IP address of a backup server for this provisioning server. The backup server IP address is sent to all target computers connected to this server. If this server fails, the targets detect that the primary server has failed, and automatically switch to the backup server. Here are some considerations regarding the provisioning server running at the IP address specified by this parameter (the backup): v The backup must be configured to use the same UDP ports as this server for the NBP, FILE, MCAST and PCAST services (that is for all specific services); v Its file system must be strictly identical to the file system of this server, so that boot agents can switch from one server to the other in the middle of a file transfer; v Ideally, the backup must be configured to answer DHCP discovers and PXE discovers for the same targets as this server, but with a higher delay (see BootReplyDelay). This ensures that the remote-target boots on the backup server on the next boot. BaseDir Name BaseDir Directory for all provisioning server files. Synopsis BaseDir " directory" Location v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the File Access Module section. v rembo.conf: Beginning of the file. Description By default under Windows, DataDir points to c:\Program Files\Common Files\IBM Tivoli. You must set this parameter to the directory where you have installed the provisioning server executable. If you are using the Windows version the BaseDir parameter is automatically configured during the setup process. BaseDir contains a subdirectory named packages which holds the .pak server extensions. Note: Always use forward slashes (/) in all path names you enter in the text-based configuration file.
360
Examples
BaseDir "c:\Program Files\Common Files\IBM Tivoli" BaseDir "/usr/local/tpmfos"
BootDiscoveryAddress Name BootDiscoveryAddress Multicast address used for PXE discovery requests Synopsis BootDiscoveryAddress ip-addr Location v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description If PXE multicast boot discovery is enabled on the provisioning server (see (BootNoMulticastDiscovery)), this option must be set to the multicast IP address used by the remote-boot targets when performing PXE discovery. If this option is not set, Tivoli Provisioning Manager for OS Deployment uses the IP address 232.2.0.1.If the provisioning server is in the same subnet as the DHCP server, PXE discovery is not required because the remote-boot targets know that the PXE server is on the same computer as the DHCP server (option 60 set to PXEClient). If the provisioning server and the DHCP server run on different computers, but are on the same IP subnet, PXE discovery is still not required because the provisioning server intercepts DHCP requests and provides PXE information at the DHCP stage. You only require PXE discovery if the remote-boot targets are not on the same subnet as the provisioning server, or if your existing PXE infrastructure is already setup for PXE discovery. Example
BootDiscoveryAddress 232.5.6.7
BootDiscoveryPort Name BootDiscoveryPort IP port used when listening to PXE discovery requests Synopsis BootDiscoveryPort port Location in the OS configuration v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description This parameter must be set to the port used by remote-targets when sending PXE boot requests (multicast boot discovery, or BINL discovery). The default value works with PXE bootroms which have not been modified, so there is no reason to change this value unless you know what you are doing. If this option is not set, Tivoli Provisioning Manager for OS Deployment uses the IP port 4011. Example
BootDiscoveryPort 5011
361
BootNoMulticastDiscovery Name BootNoMulticastDiscovery Disables PXE multicast discovery support. Synopsis BootNoMulticastDiscovery yes/no Location v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description If the parameter BootNoMulticastDiscovery (without argument) is present in the configuration file (rembo.conf config), then PXE multicast discovery is disabled on the server. The provisioning server does not answer PXE multicast packets received from remote-boot targets. PXE multicast discovery is used by remote-boot targets if your existing PXE infrastructure is configured to use PXE discovery. Multicast discovery is not needed if the remote-boot targets and the provisioning server are on the same subnet, because the targets use other mechanisms to find the provisioning server (DHCP proxy, or DHCP option 60). If you know that you do not need PXE multicast discovery, you can disable it by setting this parameter to true. This is suggested if you are in a large company or institution where other PXE targets can be configured to use multicast discovery on other subnets, but you do not want your server to reply to these targets. Example
BootNoMulticastDiscovery
BootReplyDelay Name BootReplyDelay Sets the delay before answering discovery requests. Synopsis BootReplyDelay secs Location v web interface: Not available. v rembo.conf: Beginning of the file. Description This parameter sets the number of seconds to wait before answering a PXE discovery request (PXE discovery enabled), or a DHCP request (ProxyDHCP enabled). The default value is 0 (no delay). The only reason to delay a PXE reply is when two or more OS deployment servers are configured to run on the same subnet, with the same list of targets. The parent server can be configured with a delay of 0 seconds (answer immediately), and other servers with a delay of 2 seconds. If the parent server fails, backup servers handle remote-boot target requests. Example
BootReplyDelay 2
DataDir Name DataDir Directory for internal files.
362
Synopsis DataDir " path" Location v web interface: Not available v rembo.conf: Beginning of the file. Description The server uses the directory specified by DataDir to store its internal files, in particular all the files stored on its file system. You can use this parameter to specify a new directory for the internal files of the server, for example if you want to store the server files on a new storage device with more space, but you want to keep the executable and configuration files on the original location. All the files stored in the directory specified by DataDir must not be modified, or the provisioning server might not work correctly. If the specified directory does not exists, the server tries to create it. Examples
DataDir "/mnt/morespace/rembo" DataDir "C:/TPMfOS"
DefaultAuthDomain Name DefaultAuthDomain Default authentication domain. Synopsis DefaultAuthDomain " domain" Location in the OS configuration v web interface :Not available v rembo.conf: Beginning of the file. Description This is the name of the default authentication domain to use when a target sends an authentication request to the server to identify a user. This name must match the name of an existing authentication domain as defined in Authentication domains. Example
DefaultAuthDomain "HTTP"
DefaultFileServer Name DefaultFileServer Defines a new server for FILE services. Synopsis DefaultFileServer ip-addr Location in the OS configuration v web interface :Not available v rembo.conf: Beginning of the file. Description This parameter can be used to specify the default IP address of the target serving the NETfs and MCAST protocols. If the you want to use the same provisioning server for all services, you do not have to specify this parameter. The target defined by this parameter must be configured to use the same network password (NetPassword) as the server containing this parameter.
363
This parameter is applied to all the targets contained in the group. Example
DefaultFileServer 172.16.8.9
DefaultGroup Name DefaultGroup Default group for unknown targets. Synopsis DefaultGroup " name" Location in the OS configuration rembo.conf: Beginning of the file. Description This parameter defines the default administrative group for unknown targets. The "name " argument must be an existing administrative group. Example
DefaultGroup "MyNewHosts"
DefaultLockOut Name DefaultLockOut Locks peripherals on unknown targets. Synopsis DefaultLockOut [ none ] [ , mouse ] [ , keys ] [ , screen ] [ , all ] Location in the OS configuration rembo.conf: Beginning of the file. Description Use this parameter to lock peripherals on the remote-boot targetsduring the time Tivoli Provisioning Manager for OS Deployment is active on the unknown target. You can for example lock the mouse or/and the keyboard so that the user cannot interrupt an automatic image restoration process. Peripherals are automatically unlocked when Tivoli Provisioning Manager for OS Deployment gives the control to the operating system (with a HDBoot, LXBoot, RDBoot or DeviceBoot). Example
DefaultLockOut keys, mouse
DefaultOptions Name DefaultOptions Startup options for the remote target computer. Synopsis DefaultOptions [ admin ] [ , autoboot ] [ , nousb ] [ , novesa ] [ , noapm ] [ , unicast ] [ , noigmp2 ] [ , noudma ] [ , noprotpart ] [ , realmodedisk ] [ , realmodepxe ] [, routepxeirq] Location in the OS configuration rembo.conf: Beginning of the file. Description Twelve different options can be set for targets. These options are used when unknown targets run under Tivoli Provisioning Manager for OS Deployment:
364
v Admin: forces the target to run in administrative mode. Administrative mode adds options in the start menu on the target: Interact, to run the interactive evaluator, and Purge cache to purge the local disk cache. Additionally, functions defined in the admin.rbx plugins are available (File Manager, TextEdit,...). v Autoboot: tells the target to automatically reboot on unrecoverable errors. Unrecoverable errors are low-level errors which cannot be intercepted with the exception mechanisms. By default unrecoverable errors are displayed on the screen and the computer is halted. You can define the autoboot option if you want to reboot on unrecoverable errors. v NoUSB: disables USB devices on the remote-boot target. v NoVESA: disables all the graphical interface on the remote-boot target. v NoAPM: disables advanced power management on the remote-boot target. v Unicast: uses unicast instead of multicast when downloading files from the provisioning server. v NoIGMP2: disables IGMP version 2 to force using IGMP version 1 on the remote-boot target. v NoUDMA: disables UltraDMA support for all IDE hard-disks on the remote-boot target. This can solve problems on poorly designed hardware or buggy chipsets, but at a high cost in terms of performance. v NoProtPart: disables ATA-5 features. v RealModeDisk: disables enhanced disk access. v RealModePXE: disables enhanced PXE access. v RoutePXEIRQ: reroutes network IRQ separately from the disk controller IRQ. Example
DefaultOptions admin
DefaultPXEBootMode Name DefaultPXEBootMode Selects default PXE boot behavior. Synopsis DefaultPXEBootMode { normal | hdboot | ignore } Location in the OS configuration rembo.conf: Beginning of the file. Description This option defines how the provisioning server answers PXE boot requests coming from unknown targets. When mode is normal, the provisioning server processes the boot request. When mode is hdboot, the provisioning server tells the unknown target to immediately boot on the hard disk. When mode is ignore, the provisioning server does not answer the boot request, thus giving the opportunity for another PXE server to answer. Example
DefaultPXEBootMode normal
DefaultResolution Name DefaultResolution Default screen resolution for new targets. Synopsis DefaultResolution " path " Location in the OS configuration v web interface : Not available v rembo.conf: Beginning of the file.
365
Description This parameter defines the default screen resolution for target on a new target. Example
DefaultResolution "800x600"
DisableBOOT Name DisableBOOT Disables PXE services Synopsis DisableBOOT Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description Use this option to disable the PXE component of the provisioning server. Targets are not able to boot on PXE anymore if this option is included in the configuration file. Use this option if you want to use the provisioning server for remote file access only (for example when setting up the server). Not included in the default configuration. Example
DisableBOOT
DisableContextualMenu Name DisableContextualMenu Disables the specific contextual menus in the web interface. Synopsis DisableContextualMenu Location in the OS configuration v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable the specific contextual menus in the web interface. This can be useful if you want access to the regular contextual menu of your Web browser, in order, for example, to view the source page. Not included in the default configuration. Example
DisableContextualMenu
DisableCookies Name DisableCookies Disables the use of cookies in the web interface. Synopsis DisableCookies Location in the OS configuration
366
v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you do not want the web interface to memorize your local preferences such as window positions using local cookies. Disabling cookies does not prevent you to use any essential function of the web interface. Not included in the default configuration. Example
DisableCookies
DisableDHCPProxy Name DisableDHCPProxy Disables answers to DHCP discovers (DHCPProxy). Synopsis DisableDHCPProxy yes/no Note: In rembo.conf configuration, the keyword DisableDHCPProxy is used without argument. If the keyword is present, it is assumed to be set to the value yes automatically. Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description If this parameter is set to yes, the provisioning server does not send PXE replies to DHCPDISCOVER packets sent by remote-boot targets. You can set this parameter to yes if you do not need this feature because either the DHCP server and the provisioning server are on the same target, or you are using PXE multicast discovery. The default value is false (that is DHCP Proxy is enabled by default). Example
DisableDHCPProxy
DisableDragAndDrop Name DisableDragAndDrop Disables the drag-and.drop feature of the web interface. Synopsis DisableDragAndDrop Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable the drag-and-drop feature of the web interface. This can be useful in case of severe incompatibility with unsupported browsers. Note that the feature in known to work on most common browsers.
367
Not included in the default configuration. Example

DisableDragAndDrop
DisableFILE Name DisableFILE Disables FILE components of the provisioning server. Synopsis DisableFILE Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the File access module section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable the FILE component of the provisioning server. This can be useful if you are accessing the server from TCP targets. Note: Do not set this option if targets are booting on this provisioning server. If you set DisableFile, you must also set DisableTCP. Not included in the default configuration. Example
DisableFILE
DisableHTTP Name DisableHTTP Disables the console. Synopsis DisableHTTP Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable the HTTP component of the provisioning server, that is the web interface. Disabling HTTP is not recommended as it forces you to run the server in command-line only. If you set DisableHTTP, you must run the -c command line option to change server parameters. Note: A full Tivoli Provisioning Manager for OS Deployment server restart is necessary when this parameter is modified. Not included in the default configuration. Example
DisableHTTP
DisableHTTPOptim Name DisableHTTPOptim Disables the web interface.
368
Synopsis DisableHTTPOptim Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to prevent the web interface to group JavaScript, stylesheet, and image files into large files to reduce HTTP traffic. Note: If you are creating console pages, you must disable set this parameter to disable optimization. Not included in the default configuration. Example
DisableHTTPOptim
DisableJSDropDown Name DisableJSDropDown Disables JavaScript menus in the web interface. Synopsis DisableJSDropDown Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable enhanced drop-down menus in the web interface, and use standard drop-down selectors instead. Note that standard drop-down selectors do not respect DHMTL layers under Internet Explorer, resulting in strange effects. Not included in the default configuration. Example
DisableJSDropDown
DisableNBP Name DisableNBP Disables NBP services. Synopsis DisableNBP Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Network Boot Module section. v rembo.conf: Beginning of the file.
369
Description Including this option in the configuration file causes the NBP component of the provisioning server to stop answering requests coming on the NBP port. Do not set this option if your server is used by targets. Not included in the default configuration. Example
DisableNBP
DisableSSL DisableSSL Disables SSL encryption. Synopsis DisableSSL Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable the SSL encryption and use unencrypted HTTP connections. This can be useful if you want a faster download time, but it is not as safe. Note: A full Tivoli Provisioning Manager for OS Deployment server restart is necessary when this parameter is modified. Not included in the default configuration. Example
DisableSSL
DisableTCP Name DisableTCP Disables TCP services. Synopsis DisableTCP Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the File access module section. v rembo.conf: Beginning of the file. Description This option disables the TCP component of the provisioning server. You can include this option with caution if you are not using server replication Note: Do not set this option if targets are booting on this server. If you set DisableTCP, you must also set DisableFile. Not included in the default configuration. Example
DisableTCP
FileMCASTAddress
370
Name FileMCASTAddress Multicast address used for the MCAST protocol. Synopsis FileMCASTAddress ip-addr:port FileMCASTAddrCount number Location in the OS configuration. v web interface: Not available. v rembo.conf: Beginning of the file. Description FileMCASTAddress defines the destination multicast address and destination port used by the provisioning server when sending multicast UDP datagram to targets requesting a file with the MCAST protocol. The default value is 239.2.0.1:10000. FileMCASTAddrCount defines the upper limit of the multicast address range used by the server (that is the number of different multicast addresses used). When combined with FileMCASTAddress, this parameter can control the lower and upper limits of the range of multicast addresses used by the server. The default value is 256 (that is use no more than 256 multicast addresses). The MCAST protocol is used by targets to download large files from the server. This protocol is a proprietary protocol made using multicast UDP. Example To force the provisioning server to use 1000 multicast addresses starting at 232.1.1.1, use:
FileMCASTAddress 232.1.1.1 FileMCASTAddrCount 1000
FileMCASTEncrypt Name FileMCASTEncrypt Encrypts MCAST datagrams. Synopsis FileMCASTEncrypt Location in the OS configuration. v web interface: Not available. v rembo.conf: Beginning of the file. Description If this parameter is present in a rembo.conf configuration file, or set to yes in the web interface, MCAST datagrams exchanged between the provisioning server and the remote-boot targets are encrypted. The MCAST protocol is used by targets to download large files from the server. This protocol is a proprietary protocol made using multicast UDP. MCAST datagrams are not encrypted by default. Example
FileMCASTEncrypt
FileServerPort Name FileServerPort Port used on the server for NETfs and MCAST requests. Synopsis FileServerPort port
371
Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the File access module section. v rembo.conf: Beginning of the file. Description This value is used by the provisioning server as the port for all file-related requests sent by targets. File-related requests include NETfs requests and MCAST requests. The default value is 4013. The value of this parameter is sent to targets during the NBP phase of the boot process. If you change this parameter, targets automatically use the new value on next boot. Example
FileServerPort 5013
HTTPAdminName Name HTTPAdminName Username of the main administrator of the provisioning server. Synopsis HTTPAdminName " username " Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of file. Description This is the superuser name intended to be used only by the main provisioning server administrator, in order to get access to the all configuration parameters of the server. There is only one superuser login. Example
HTTPAdminName "Admin"
HTTPRole Name HTTPRole Security roles with access to the web interface console. Synopsis HTTPRole "RoleName"{ Members "membername" [,...] Allowpages "pagename" [,...] Allowgroups "groupname" [,...] Policies "policyname" [,...] } Location in the OS configuration. v web interface: Not available. v rembo.conf: After global parameters. Description An HTTP role allows specific members to access predefined pages on the web interface, as well as preselected administrative groups. One can also define security policies. Parameters are a single string or a list of strings separated by commas. The star * means all, without restriction. Role members can be either individuals or groups defines by the authentication authority. An individual, who does not belong to any role, trying to log on to the web interface is denied access to the console. An individual, belonging to several roles, cumulates the page access
372
rights and administrative group access rights of all the roles s/he belongs to. Security policies are also cumulative, resulting in a more restrictive policy when an individual belongs to several roles. The security policies include: v CONF_RO to deny changes to the server configuration. v HOST_RO to deny addition and removal of targets. To use HTTPRole, you must first have set a local authentication domain named HTTP with ( )AuthLocalDomain. Example
HTTPRole "RestrictedAccess" { Members "rembo" Allowpages "*" AllowGroups "local1", "local2" Policies "HOST_RO" }
HTTPServerPort Name HTTPServerPort TCP port for HTTP requests. Synopsis HTTPServerPort port Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description This is the TCP port used by the web interface when listening for unencrypted HTTP requests. You can set this parameter to 8080 if you want the web interface to be accessible by typing the server hostname in your Web browser. The provisioning server always listens on this port even if connections are encrypted, in order to redirect unencrypted connections to the encrypted TCP port. Note: A full Tivoli Provisioning Manager for OS Deployment server restart is necessary when this parameter is modified. Example
HTTPServerPort 8080
HTTPSServerPort Name HTTPSServerPort TCP port for encrypted HTTP requests (SSL). Synopsis HTTPSServerPort port Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description This is the TCP port used by the web interface when listening for encrypted HTTP requests.
373
You can set this parameter to 443 if you want the web interface to be accessible by typing the server hostname in your Web browser, prefixed with the https URL syntax. Note: A full Tivoli Provisioning Manager for OS Deployment server restart is necessary when this parameter is modified. Example
HTTPSServerPort 443
HTTPSessionTimeout Name HTTPSessionTimeout Time in minutes before a web interface session expires. Synopsis HTTPSessionTimeout minutes Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description This is the inactivity timeout (in minutes) before web interface users are automatically logged out. A typical safe value is 5 minutes, but you might want to make it longer if you receive the message Session timed out too often and are sure that you will not forget to log out when you leave your computer. Example
HTTPSessionTimeout 30
Interfaces Name Interfaces List of network interfaces used by the provisioning server. Synopsis Interfaces ip-addr1 [ ip-addr2 ] [ ip-addr3... ] Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Base Parameters section. v rembo.conf: Beginning of the file. Description You will find this option very useful if you are running on a multihomed computer (that is a target with more than one network card, or with a network card and a dial-up adapter). This option lets you specify the list of network interfaces used by the provisioning server when receiving and sending packets to targets. If you leave this option unset, the server uses the network interface corresponding to the official hostname of the server. You must specify a list of IP addresses to use. Each IP address must correspond to the IP address to one of the network interfaces of the provisioning server. The list must contain at least one address. Note: You are strongly encouraged to set this option if your computer is multihomed. Otherwise the server might not receive the network packets not originating from its official interface.
374
Examples
Interfaces 192.168.1.1 Interfaces 192.168.1.1 192.168.10.1 10.1.1.1
MaxLogSize Name MaxLogSize Maximum size of log files created by the provisioning server. Synopsis MaxLogSize size_in_bytes Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Base parameters section. v rembo.conf: Beginning of the file. Description This parameter can be used to limit the size of the log file generated by the provisioning server. The maximal log size must be specified in bytes, and apply to all the log files created by the server (file, nbp, http, tcp, VM, and boot). If you do not specify this parameter, or set the limit to 0, then log files are not limited in size. Example To limit the size of logs to 10MB:
MaxLogSize 10000000
To disable log size limit:

MaxLogSize 0
MaxPCASTSessions Name MaxPCASTSessions Maximum number of simultaneous PCAST sessions. Synopsis MaxPCASTSessions number Location in the OS configuration. v web interface > : Not available v rembo.conf: Beginning of the file. Description This is the maximum number of PCAST sessions that the provisioning server accepts simultaneously. This parameter is mostly relevant if the server is running in UNICAST mode and deploying a group with UNICAST setting. The default value is 8. Because each session uses around 16MB of server memory, higher values must be avoided on servers with no more than 256Mb. Example
MaxPCASTSessions 8
MaxTFTPSegSize Name MaxTFTPSegSize Maximum size of a TFTP segment. Synopsis MaxTFTPSegSize number
375
Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description This is the maximum size of TFTP segment in bytes. This parameter can be used to reduce the size of packets sent by the provisioning server if required by the underlying network. This can be useful for instance when network traffic is encrypted by routers. The default value is 512. Example
MaxTFTPSegSize 256
MTFTPClients Name MTFTPClients The destination address and port used by the MTFTP server. Synopsis MTFTPClients ip-addr [: port ] Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description This is the destination IP address and port used by the server when sending multicast MTFTP datagrams to boot agents. The IP address must be a valid multicast address and must match the address sent to the target during the DHCP phase. If the deployment engine has received its PXE parameters from the provisioning server during the DHCP phase, this address is automatically included so that the deployment engine always uses the same address/port as the server. The default value is 232.1.0.1:8500. Example
MTFTPClients 232.8.7.6
MTFTPPort Name MTFTPPort The port used by the MTFTP server. Synopsis MTFTPPort port Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description This is the port used by the server when listening to MTFTP requests. If the remote-boot targets are using the provisioning server to get their PXE parameters, this value is sent in the DHCP/PXE reply so that the remote-boot target always uses the correct port.
376
The default value is 4015. Example

MTFTPPort 5015
MTFTPStartDelay Name MTFTPStartDelay The initial delay on target computers before sending first MTFTP request. Synopsis MTFTPStartDelay secs Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description This is the delay used by remote-boot targets before sending the first MTFTP request to the provisioning server. This delay is used by the target to listen to an existing MTFTP transfer. If the MTFTP file they are about to request is already being sent by the server on the multicast address, then the target does not request the file and listens to the packets. The longer this delay is, the more probability you have that many targets reuse the same MTFTP channel instead of requesting the file. But if you want to have a fast boot process, you must set this value to 1 (the minimum value). The default value is 2 (seconds). Example
MTFTPStartDelay 1
NBPServerPort Name NBPServerPort Port used on the provisioning server for NBP requests. Synopsis NBPServerPort port Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Network Boot module section. v rembo.conf: Beginning of the file. Description This value is used by the provisioning server as the port for all NBP requests sent by remote-boot targets. NBP is a protocol used by target computers to get their startup parameters (startup page, groupname,...) and to send authentication requests to the server. The default value is 4012. The value of this parameter is sent to targets as part of the last MTFTP packet when the server sends the initial part to the PXE bootrom. If you change this parameter, targets automatically use the new value on next boot. Example
NBPServerPort 5012
NetPassword
377
Name NetPassword Network password for remote file access. Synopsis NetPassword " password " Location in the OS configuration. v web interface: Not available. v rembo.conf: Beginning of the file. Description This is the password used by the provisioning server to accept or deny network requests coming from a target, the web interface or NetClnt. You must change this option when you install a new provisioning server and select a password to protect your files against unpermitted access. If you are using the Windows version of the server, you are asked to enter the password during the setup. If you are using the web interface, or NetClnt to access the files stored in your provisioning server, the password you enter in NetClnt (or the web interface) must match the word set in NetPassword. Note: This password is an important piece of your security. If you require optimal security, you are strongly encouraged to protect the configuration of the server. By default, this file is created by the installer and the password is stored encrypted in it. Example
NetPassword "mypassword"
NetworkShare Name NetworkShare UNC path of the shared partition directory of the provisioning server. Synopsis NetworkShare "path " Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Network Share Module section. v rembo.conf: Beginning of the file. Description This is the path of the shared partition directory of the provisioning server. This parameter can be used to increase the deployment speed of some operating systems. The target computer access the network share directly to retrieve the necessary installation files. You need to have set the partition as read-only for the user entitled to access the network share. Example
NetworkShare "provisioningServer/partition"
NetworkUser Name NetworkUser name of a user entitled to access the network share. Synopsis NetworkUser "name " Location in the OS configuration.
378
v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Network Share Module section. v rembo.conf: Beginning of the file. Description The name of the user entitled to access the network share, which is given in NetworkShare. If the user is part of a domains, you must use the syntax Domain/User. This user name is used by the targetcomputer to access the network share on the provisioning server. Example
NetworkUser "ClientComputer"
NetworkPasswd Name NetworkPasswd Network password used by the target computer to access the network share. Synopsis NetworkPasswd "password " Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Network Share Module section. v rembo.conf: Beginning of the file. Description This is the password used by the target computer to access the network share located on the server, using the NetworkUser user name. The password is stored in the rembo.conf file. Example
NetworkPasswd "clientPassword"
TCPServerPort Name TCPServerPort Defines the TCP port used. Synopsis TCPServerPort port Location in the OS configuration. v web interface: Not available. v rembo.conf: Beginning of the file. Description This option defines the TCP port used by the TCP component of the provisioning server when listening to requests coming from other servers. The default value is 4013. Example
TCPServerPort 2048
Hardware compatibility list

The list of certified compatible hardware for Tivoli Provisioning Manager for OS Deployment is provided as a Tivoli technote on the IBM web site.
379
The hardware listed in Table 57 to Table 65 on page 383 are known to work with Tivoli Provisioning Manager for OS Deployment.
Table 57. IBM servers Machine Type 7971 7972 7981 7996 8853 8832 8843 8839 8850 8886 8835 8848 8486 8480 8482 8485 8647 8649 8648 8671 8841 8685 8865 8673 8836/8849 8849 8676 8837 8670 8840 8863 8870 8872 4347 4362 4363 4364 4365 Model IBM BladeCenter LS21 BladeCenter LS41 BladeCenter HS20 BladeCenter HC10 BladeCenter HS21 BladeCenter HS20 BladeCenter HS20 BladeCenter HS40 BladeCenter LS20 BladeCenter S eServer 325 eServer 326 IBM xSeries 100 xSeries 205 xSeries 206 xSeries 206m xSeries 225 xSeries 225 xSeries 226 xSeries 235 xSeries 236 xSeries 255 xSeries 260 xSeries 305 xSeries 306 xSeries 306m xSeries 335 xSeries 336 xSeries 345 xSeries 346 xSeries 366 xSeries 445 xSeries 460 System x3105 System x3200 System x3200 System x3250 System x3250

Tested BIOS level BAJT22A BAJT22A FEE110A DOJT16A BCJT16A BSJT26A BWJT27A SBJT62A BKJT23F BCJT16A M1JT36A M2JT28A IJJT28C JPJT53A KEJT40A PAJT24A OPJT50A OQJT14A PMJT66C GRJT57A NRJT34A AVJT26A ZUJT65A PLJT68A KEJT40A PAJT42A T2JT39A APJT37A GEJT63A KPJT41A ZUJT65A REJT49A ZUJT65A A2JT19A G8JT29A G8JT29A G9JT26A G9JT26A
380
Table 57. IBM servers (continued) Machine Type 7973 7984 7977 7978 7979 7985 8877 8866 8864 8878 Model System x3400 System x3455 System x3500 System x3550 System x3650 System x3655 System x3755 System x3800 System x3850 System x3950* Tested BIOS level SPJT52A C0JT35A SPJT52A GFE29B GGE29B C2JT28A ZYJT29A ZTJT10A ZSJT10A ZTJT13A
Table 58. IBM workstations Machine Type 6225 9229
Model IBM IntelliStation M Pro IntelliStation M Pro FIJT41A GVJT26A
Tested BIOS level
Table 59. Lenovo mobile and desktop computers Machine Type ThinkCentre ASI ThinkCentre SSO ThinkPad R52 ThinkPad T30 ThinkPad T41 ThinkPad T42 ThinkPad T60 ThinkPad T60p ThinkPad X31 ThinkPad X60 Table 60. IBM Point of Sale computers Machine Type 4851-514 4810-33H 4838-137 4840544 4800-722 4800-782 4836-132 4846-565 4800-743 IBM SurePOS 500 SurePOS 300 Anyplace Kiosk SurePOS 500 SurePOS 700 SurePOS 700 Anyplace Kiosk SurePOS 500 SurePOS 700

Model 8105, 8107, 8109, 8117, 8119, 8121 8086 1859-B7U 2366-N6G 2373-3JG 2373-FWG 1951-A47 2007-83U 2672-C8G 1706-AA7
Model
Tested BIOS level HHKT130 8BKT120 8AKT111 X7KT100 82KT130 83KT130 8AKT111 X6KT142 85KT027
381
Table 60. IBM Point of Sale computers (continued) Machine Type 4800-723 4838-520 4838-720 Table 61. IBM storage servers Name IBM TotalStorage DS4100 (formerly FAStT100) IBM TotalStorage DS4300 (formerly FAStT600) IBM TotalStorage DS4400 (formerly FAStT700) IBM TotalStorage DS4500 (formerly FAStT900) FAStT EXP500 Storage Expansion Unit Table 62. Ethernet adapters Part number 06P3601 06P3801 08K3124 08L2565, 08L2567 09N3609 09N9774 09N9901 22P4501 22P4701 26P8039 31P6301 31P6401 34L0201 34L1101, 34L1110 34L1201, 34L1210 34L4401 (3DES US) 34L4410 34L4501 (DES non-US) 34L4510 85H9921, 85H9930 85H9921, 85H9930 FRU number 06P3609 06P3809 08K3125 08L2566 09N3609 00N8117 09N9901 22P4509 22P4709 26P8069 31P6309 31P6409 30L5929 34L1109 34L1209 34L4409 not available Name IBM 10/100 Ethernet Server Adapter Intel PRO/100 SP Mobile Combo adapter IBM 10/100 EtherJet Mini PCI adapter with 56K modem (Intel current card) IBM 10/100 EtherJet PCI Adapter with Wake on LAN1 10/100 EtherLink PCI Management Adapter by 3Com IBM 10/100 EtherJet miniPCI adapter with 56K modem by 3Com 10/100 EtherLink Server Adapter by 3Com Intel PRO/100S Desktop Adapter Intel PRO/100S Low Profile Desktop Adapter Ethernet Daughter Card IBM NetXtreme 1000 T Ethernet Adapter IBM NetXtreme 1000 T Dual Port Ethernet Adapter IBM 10/100 EtherJet PCI Adapter with Wake on LAN1 IBM 10/100 EtherJet PCI Adapter with IBM Alert on LAN 2 IBM 10/100 EtherJet PCI Management Adapter IBM 10/100 EtherJet Secure Management Adapter IBM 10/100 EtherJet Secure Management Adapter
Model SurePOS 700 AnyPlace Kiosk AnyPlace Kiosk
Tested BIOS level 85KT027 8DKT100 8DKT100
Model number 1724-100 1722-1RU 1742-1RU 1742-90U 3560-1RU
WoL Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes Yes Yes
85H9928 85H9928
IBM 10/100 EtherJet PCI Adapter with Wake on LAN1 IBM 10/100 EtherJet PCI Adapter with Wake on LAN1
Yes Yes
382
Table 62. Ethernet adapters (continued) Part number Ships with system Ships with system Ships with system Ships with system FRU number not available not available 26P8100 not available Name Intel Gigabit Copper (82543) PRO 1000 XT Intel Gigabit Copper (82544) PRO 1000 XT IEEE 1394/LAN Combo Card On board Ethernet Adapter for ThinkPad R30 WoL Yes Yes Yes Yes
Table 63. IBM ServeRAID controllers Name ServeRAID-8i controller ServeRAID-8s controller Winterhaven, MegaRAID 8480 SAS controller ServeRAID-4Mx Ultra160 SCSI controller ServeRAID-4Lx Ultra160 SCSI controller ServeRAID-5i Ultra320 SCSI controller ServeRAID-6M Ultra320 SCSI controller ServeRAID-4H Ultra160 SCSI controller ServeRAID-6i Ultra320 SCSI controller ServeRAID-7k Ultra320 SCSI controller ServeRAID-7t SATA controller ServeRAID-7e (Adaptec HostRAID) controller ServeRAID-8e controller ServeRAID-8k SAS controller LSI MegaRAID SAS 8408E controller LSI 1068 controller Table 64. LSI RAID controllers Name LSI-SAS RAID controller (Sanford) Single Channel LSI Ultra320 SCSI controller Dual Channel LSI Ultra320 SCSI controller LSI MegaRAID IDEal RAID controller Table 65. BladeCenter-related products Name SAS Expander Switch Module SAS 2-port CFFv daughter card Qlogic 4Gb SFF Qlogic 4Gb Std Part number 39Y9192 39Y9187 26R0890 26R0884 FRU number 39Y9193 39Y9188 26R0893 26R0889 25R8060 LSI53C1020 LSI53C1030 LSI MegaRAID IDEal RAID Part number Part number 13N2227 39R8765 39R8850 06P5736 06P5740 25P3492 32P0033 37L6889 71P8595 71P8642 71P8648 n/a n/a 25R8064 39R8850 25R8060 FRU number 13N2233 39R8785 39R8852 06P5737 06P5741 32P0016 02R0985 37L6892 71P8627 71P8644 71P8650 n/a n/a 25R8064 n/a n/a
383
Table 65. BladeCenter-related products (continued) Name Emulex 4Gb SFF Fibre Channel Expansion Card IBM BladeCenter Optical Pass-Thru Module Cisco Gigabit Ethernet Switch module Cisco Fiber Switch Module IBM BladeCenter Advanced Management Module (AMM) IBM BladeCenter PCI Expansion Unit (PEU) IBM BladeCenter HS20 Fibre Channel Expansion Card - Short Form Factor IBM BladeCenter 6-pt Fibre Channel Switch Module Qlogic iSCSI Expansion Card for IBM BladeCenter Nortel Copper L2/L3 Switch Module Nortel Fibre L2/L3 Switch Module QLogic 4 Gb Fibre Channel Switch Module Brocade 20 Port FC switch module IBM BladeCenter HS20 Fibre Channel Expansion Card IBM BladeCenter 2-Port Fibre Channel Switch Module Myrinet Cluster Expansion Card for IBM BladeCenter IBM BladeCenter Copper Pass-Thru Module IBM BladeCenter Gigabit Ethernet Expansion Card Part number 39Y9186 02R9080 13N2281 13N2285 25R5778 25K8373 26K4841 26K6477 26K6487 26K6530 26K6531 26R0883 32R1812 48P7061 48P7062 73P6000 73P6100 73P9030 FRU number n/a 02R9082 13N2285 13N2286 25R5777 32R0753 26K4859 26K6481 26K6490 26K6526 26K6529 26R0888 32R1820 59P6624 59P6621 73P6001 73P6098 13N2306 (replaces 73P9031) 73P9004 90P3776 n/a
Nortel Network Layer 2-7 GbE Switch Module for IBM BladeCenter Intel Copper Switch Module IBM BladeCenter PCI Expansion unit (PEU)
73P9057 90P3686 90P3721
Installing and uninstalling the web interface extension

If the source computer does not have Tivoli Provisioning Manager for OS Deployment installed on it, you must install the web interface extension on it manually. The source computer is the computer that contains the OS media you want to create an image from. To manually install the web interface extension:
Procedure
1. On the source computer, find the files for the web interface extension, which are located in the OSD_DATADIR\global\http\agents directory, where OSD_DATADIR is the Tivoli Provisioning Manager for OS Deployment data directory you specified, for example: v
Windows
UNIX Linux /opt/tpmfosd_files v 2. Perform the following:
v v v
Windows Run the rbagent.msi file. Follow the instructions in the wizard to install the web interface extension. AIX Linux
Run the rbagent.aix file. Run the rbagent.linux file.
384
Solaris
Run the rbagent.solaris file.
For all UNIX files, you must transform the downloaded file into an executable (for example, chmod +x rbagent.linux) and then run it. For example, ./rbagent.linux -s <IP>:<password> where IP is the IP address of the OS deployment server to which you want to connect, and password is the password that was specified at the Tivoli Provisioning Manager for OS Deployment installation.
Uninstalling the web interface extension

To uninstall the web interface extension: On Windows operating systems 1. Open the Control Panel. 2. Open Add or Remove Programs. 3. Select IBM Tivoli web interface extension. 4. Click Remove. 5. Follow the instructions of the installer. Note: The rbagent.conf file is not removed from the Program Files/Common Files/IBM Tivoli directory. This enables you to keep the same configuration in case of upgrade. If you want to remove the web interface extension completely, you must delete the rbagent.conf file manually. On UNIX operating systems Simply delete the executable file.
385
386

As more and more physical servers and storage resources are virtualized and consolidated, it can be difficult to discover and inventory assets in the virtual environment, and also monitor the growth of virtual machines and the underlying IT infrastructure. Optional with Tivoli Provisioning Manager version 7.2, the integration with Tivoli Provisioning Manager for Images adds an important set of virtualization features and leverages the operating system deployment and image management functions. Tivoli Provisioning Manager for Images provides a superset of the Tivoli Provisioning Manager for OS Deployment functions. In addition to the operating system deployment and image management capabilities, Tivoli Provisioning Manager for Images provides virtualization features that are not available in Tivoli Provisioning Manager for OS Deployment. The virtualization function ensures an easy management of the virtualization infrastructure and accelerates provisioning to target computers by building Tivoli Provisioning Manager for Images virtual images once and deploying them multiple times, whenever they are needed. Tivoli Provisioning Manager for Images helps you to: v Manage different types of hypervisors v Manage different types of virtual images v Back up and restore images Common Tivoli Provisioning Manager for Images virtual image management tasks include: v Capturing a Tivoli Provisioning Manager for Images virtual image from a physical or virtual source system. v Installing a Tivoli Provisioning Manager for Images virtual image one or more physical or virtual target systems. v Replicating Tivoli Provisioning Manager for Images virtual images between repositories. v Discovering Tivoli Provisioning Manager for Images virtual images. v Importing and exporting Tivoli Provisioning Manager for Images virtual images. See the related links for more information about obtaining and upgrading to Tivoli Provisioning Manager for Images.
Virtual image management basics

Tivoli Provisioning Manager for Images virtual image management includes processes for discovering, capturing, installing, replicating, importing, and exporting Tivoli Provisioning Manager for Images virtual images. Find out more about what Tivoli Provisioning Manager for Images virtual image management is about, who the primary users are, and what are the key examples and terms that you need to know about this feature. v Process on page 388 v User roles on page 388 v Requirements on page 389 v Key terms on page 390 v Troubleshooting on page 390 v Log files on page 391
387
Process
When you deploy an image, the deployment is made up of several steps that are automatically run in sequence without user interaction: 1. Invoke the Image Deployment application. Click Go To > Deployment > OS Management > Image Deployment. 2. Select the target machine and image you want to install. The image deployment workflow will be run. If Tivoli Provisioning Manager can manage the target computer (it has credentials and can execute commands) and the target computer is running, then Tivoli Provisioning Manager will restart the target computer. Since the target computer must be set to boot from the network first (see Network boot on page 273), it will then PXE boot off the Tivoli Provisioning Manager for OS Deployment deployment server. If Tivoli Provisioning Manager cannot manage the target computer, then you must restart the computer yourself. 3. The target determines that it is starting a new deployment and queries the provisioning server for the relevant deployment OS configuration. 4. The target performs hardware discovery through DMI and PCI system calls. 5. The target queries the ODBC/JDBC database for all relevant information regarding the operating system and the software modules to be installed, and dynamically generates a deployment script. 6. If specific hardware configuration software needs to be run early (such as RAID controller configuration), you will have to deploy the hardware configuration image with an image deployment. If you want to install a hardware configuration and then an OS image afterwards, you can create a software stack containing entries for the hardware configuration stack and the OS image (for example, a golden master or unattended setup) stack. After a subsequent reboot, the target resumes the process. 7. The target partitions its hard disk according to the information retrieved from the database. A small bootstrap is also written to the hard disk, so as to be able to take over any subsequent reboot on the hard disk. 8. The target initiates a batch multicast transfer for all files needed during the deployment. The files are downloaded in the order which optimizes the efficiency of the multicast download and stored in a temporary storage location on the hard-disk. 9. When everything is done, the deployment process terminates by starting up the target computer into the operating system. Tivoli Provisioning Manager will also attempt to connect to the machine after the deployment and run an inventory scan.
User roles
You must be assigned to the appropriate user role to perform virtual image management operations.
388
Table 66. User roles Role Provisioning Administrator Description v Upgrades Tivoli Provisioning Manager for OS Deployment to Tivoli Provisioning Manager for Images, to enable the virtual images management. v Installs the web interface extension on hypervisors. v Performs higher level management of the environment such as installing or deleting boot servers. Provisioning Configuration Librarian v Knowledge of provisioning server v Manages overall product configuration, boot server, and configuration. Responsible for virtualization technologies. setting up the environment to support boot server and hypervisor technologies. v Performs virtual image discovery, replication, capture, import, export, and deployment activities. Deployment Specialist v Deploys captured virtual images to v Server and image management target computers. experience. v Knowledge of hypervisor technologies. v Familiarity with OS management life cycle. End User v The individual who uses a target computer, typically a notebook, desktop or server. v Basic knowledge of the operating system on the target computer. Skills v Knowledge of boot server and virtualization technologies.
Requirements
User roles and requirements on page 406 Requirements on page 406 Target computer requirements: Requirements for Windows target computers on page 556 Requirements for Red Hat Linux target computers on page 560 Requirements for SUSE Linux Enterprise Server (SLES) target computers on page 561 Requirements for AIX target computers on page 562 Requirements for Solaris Operating Environment target computers on page 563 Requirements for HP-UX target computers on page 565 v Hypervisor requirements on page 407 v Server system requirements on page 280 v Setting up additional child OS deployment servers on page 283 v Windows Preinstallation Environment (WinPE) on page 286 v Prerequisites for VMware targets on page 295 v DHCP server requirements and configuration on page 296
389
Key terms
bare metal computer A computer on which there is nothing reliable but the hardware. It can be coming straight from factory without any data on its hard disk (out of the box) or it can contain a possibly damaged operating system. boot server A system that is required to start other servers. Boot servers are defined to provision workstations or other systems without any installed software. Compare with terminal server. child server An OS deployment server that is a subordinate of another OS deployment server in a replication tree structure. Only the top-level parent OS deployment server is not a child. hypervisor A program or a portion of Licensed Internal Code that allows multiple instances of operating systems to run simultaneously on the same hardware. Typically, it represents the server that hosts the virtual servers. For ESX, for example, the hypervisor is the actual VMWare ESX server that hosts the virtual servers. image A representation of a computer program and its related data such as the kernel, file systems, libraries, and programs of the managed system at a particular time.
parent server An OS deployment server in a replication tree structure that has at least one dependent OS deployment server. See also child. Preboot Execution Environment (PXE) PXE is an industry standard target/server interface that allows networked computers that are not yet loaded with an operating system to be configured and booted remotely. PXE is based on Dynamic Host Configuration Protocol (DHCP). Using the PXE protocol, targets can request configuration parameter values and startable images from the server. The PXE process consists of the system initiating the protocol by broadcasting a DHCPREQUEST containing an extension that identifies the request as coming from a target that uses PXE. The server sends the target a list of OS deployment servers that contain the operating systems available. The target then selects and discovers an OS deployment server and receives the name of the executable file on the chosen OS deployment server. The target downloads the file using Trivial File Transfer Protocol (TFTP) and runs it, which loads the operating system. target computer The system that is the final destination of a management operation. unattended setup Operating system installation on a target, using original installation files and parameters contained in a script defined on the OS deployment server. Contrast with clone. virtual image A virtual representation of a computer program and its related data such as the kernel, file systems, libraries, and programs of the managed system at a particular time.
Troubleshooting
v Log files v Operating system and virtual image management problems and limitations v Messages v Search the IBM Support Portal v Contacting Support
390
Log files
Review the log files in the following topics to recover from problems that you might encounter when managing virtual images: v Tivoli Provisioning Manager for OS Deployment server log files v Copying log files to the software repository v Recovering from Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images problems
Resources
To learn more about virtual image management, refer to one of the following resources: v Tutorial: Managing virtual images on page 437 v Components for managing virtual images on page 265 v Installing the web interface extension on page 428 v Virtual image tasks on page 430 v For a description of a field in the interface, click Alt+F1.
Related links Chapter 5, Managing virtual images, on page 387 Requirements on page 406 Troubleshooting virtual images management Tutorial: Managing virtual images on page 437
Tivoli Provisioning Manager for Images overview

Tivoli Provisioning Manager for Images provides a superset of Tivoli Provisioning Manager for OS Deployment functionality. Designed to replace Tivoli Provisioning Manager for OS Deployment, Tivoli Provisioning Manager for Images provides all the Tivoli Provisioning Manager for OS Deployment functionality plus a set of important virtualization features. The additional virtualization functionality enables you to capture virtual images from virtual or physical machines and discover virtual machines and images from various hypervisors. Tivoli Provisioning Manager for Images provides: v Easy management and maintenance of virtual images and physical server images, including content customization and ability to modify images offline. v More efficient management of image distribution, discovery, capture, replication, storage, and deployment. v Hardware-independent snapshots of server images, to improve agility, flexibility, and recovery of servers. v Server consolidation through image conversions, and quick deployment to various environments. v Management of multiple hypervisor environments by converting images to various formats. v Simplified storage of thousands of images. Tivoli Provisioning Manager for Images delivers hardware independence, virtual and physical image independence, and image conversion capabilities. It helps you to optimize physical and virtual infrastructure resources, and reduce enterprise data center costs and administration complexity. It provides both hardware-independent and virtualization-independent imaging to move images seamlessly between physical or virtual machines.
391
Managing different hypervisors

When you manage different hypervisors you work with tools of specific hypervisor vendors. Because most of these tools are expensive, it might not be convenient to use different hypervisors. To minimize costs, Tivoli Provisioning Manager for Images provides you with a hypervisor-independent baseline for image management. You can switch from one technology provider to another one and get a homogeneous view of their virtualization environment, even when their environment is a mixture of technologies.
Managing different virtual images

While virtualization improves the data center efficiency and server usage, it also causes problems to keep track of thousands of images and their contents. If you have deployed tens of VMWare ESX servers on a VMWare-based virtualization infrastructure, you must find a way to keep track and catalog the thousand images that are produced in a consolidated view: hypervisors, VM instances, and snapshot images. Tivoli Provisioning Manager for Images provides the following benefits: v Discovery of VM instances and snapshot images on different virtualization infrastructures (VMWare ESX, KVM). v Support of multiple image formats (VMDK and raw). v Consolidated view of heterogeneous physical and virtual images.
Backing up and restoring images

Tivoli Provisioning Manager for Images helps you to optimize the backup and restore of thousands of images. In a VMWare-based virtualization infrastructure with tens of hypervisors, to virtualize and consolidate your environment, you must back up and restore images. Tivoli Provisioning Manager for Images provides a scalable image repository that stores and replicates the huge numbers of images by using a sector-by-sector disk image backup and not a file-by-file backup. The unit being stored is a block of 2 MB. This technique optimizes the disk space usage because if two blocks are identical only one is saved. Each block is compressed, stored in a directory, and decompressed during the image deployment. The new way of storing images is very efficient because using this sector algorithm eliminates the storage of duplicates of any sector and less image data is replicated between servers in large environments. Note: This kind of storage is not available on images stored with previous versions of Tivoli Provisioning Manager for OS Deployment, RAD export images, cloning, and unattended setup profiles.
Components for managing virtual images

The product consists of server-side components, console-side components, and target-side applications. Server-side components The following server-side components are installed using a typical setup program. The OS deployment server This component, which runs in the background as a service, provides the PXE remote-boot capability and multicast file access to the remote-boot targets. A deployment database The deployment database is accessed through the standard ODBC/JDBC interface, and
392
through the TCP-to-ODBC/JDBC Gateway service. This database stores Bill of Material (BOM) files for every target, including information about what software modules must be installed. Console-side components The web interface This is a Web-based application that is used to prepare and supervise deployments. Using the web interface, you can configure the OS deployment server, manage objects used during a deployment, and create recovery CDs and DVDs. You can also visualize targets into their different groups. The parameters and status of each target can be controlled (for example, when a target requests a remote-boot through PXE). Target-side applications The following target-side applications are installed automatically by the target through the network. The deployment engine The deployment engine is a stand-alone mini-operating system used for all the management tasks that are performed outside of the real operating system, such as the operating system installation. The deployment engine must not be installed manually on target systems, because it is downloaded automatically when the target systems are instructed to boot on the OS deployment server in their DHCP configuration. After the deployment engine is started, it loads a ramdisk that can perform various operations on the targets, such as: v Disk partitions and formatting v Installation of complete operating systems such as Windows or UNIX v Disk wipes The web interface extension The web interface extension is a small program that can run on most operating systems (Windows, AIX, Linux, Solaris), either in the background as a service or as a command-line tool. It provides cross-operating system connectivity to the management platform for targets with an installed operating system. It can be used to collect information from targets, to remotely initiate tasks on a target from the OS deployment server, or to trigger commands on the OS deployment server from a target. The web interface extension can access all files on the hard disk and other drives through the operating system. When running under Microsoft Windows, it can also access the system registry, and all system information published by drivers using the Windows Management Interface (WMI). Also, for all Intel-based operating systems, the web interface extension can install a hook on the boot process to initiate a PXE boot or to start the deployment engine in offline mode, to trigger pre-operating system management tasks such as migration or recovery. The deployment engine and the web interface extension are stand-alone management platforms and do not require an operating system. The web interface side application, typically installed on the server, is the web interface extension, running in background as a service. Optionally, a web interface extension can be installed on targets, so that you can take control of them remotely. The web interface extension is useful, for example, to restart the computer when a deployment starts, or to perform an operating system inventory. Several features of the web interface are not available when the web interface extension is not installed on the server. The web interface extension is a piece of software designed to run as an operating system application (a Windows application or a UNIX application). When you install the product, you install the OS deployment server. The target side is embedded into the server, and sent to computers through a network connection such as a network boot or PXE boot, or through media such as a CD-ROM, a diskette, or a hard disk partition.
393
Note: It is also possible to boot targets over the network without using PXE. See Booting targets without using PXE on page 274 for more information.
394
Figure 5. Tivoli Provisioning Manager for OS Deployment components
1. A CD-ROM that contains both the deployment engine and the web interface extension can be created. 2. Computers boot, loading the deployment engine either from the PXE server (OS deployment server) or from the CD-ROM.
395
3. The deployment engine loads a ramdisk, embedded Linux for Linux targets or WinPE2 for Windows targets. 4. The ramdisk can perform various tasks, including the operating system installation. 5. The targets boot into the operating system (Windows, Linux, Solaris), with the web interface extension optionally running.
Obtaining Tivoli Provisioning Manager for Images

Tivoli Provisioning Manager for Images replaces Tivoli Provisioning Manager for OS Deployment provided with Tivoli Provisioning Manager version 7.2, therefore it is not installed with Tivoli Provisioning Manager for OS Deployment. If you have Tivoli Provisioning Manager installed, review the following upgrade scenarios, and obtain the build packages required for the upgrade: v If you have Tivoli Provisioning Manager version 7.2 installed and would like to use the additional functionality provided by Tivoli Provisioning Manager for Images, you must purchase a license for Tivoli Provisioning Manager for Images, and then upgrade your Tivoli Provisioning Manager for OS Deployment to Tivoli Provisioning Manager for Images. v If you have an earlier version of Tivoli Provisioning Manager (for example, 7.1.1), you must first upgrade to Tivoli Provisioning Manager 7.2, which will also upgrade your Tivoli Provisioning Manager for OS Deployment to the latest version deployed with Tivoli Provisioning Manager 7.2. Build packages and fixes for Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images are published on IBM Fix Central. The packages can be found by accessing the Fix Central section of the Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images Support Web site, at http://www.ibm.com/support/fixcentral. The license for Tivoli Provisioning Manager for Images provides you with an entitled IBM ID, which is required for the downloads. If you do not have an entitled IBM ID, you will see the fixes, but you will not be able to download them. To download the packages for Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images:
Procedure
1. Select Tivoli for the Product Group. 2. Select the Tivoli Provisioning Manager for OS Deployment or the Tivoli Provisioning Manager for Images product. 3. For the Installed Version, select the build number that matches the number of the Tivoli Provisioning Manager for OS Deployment build that was shipped with Tivoli Provisioning Manager 7.2. 4. Select the platform, and then click Browse to find the required packages and fixes. 5. Click Continue.
What to do next
Upgrading Tivoli Provisioning Manager for OS Deployment to Tivoli Provisioning Manager for Images on page 397
396
Upgrading Tivoli Provisioning Manager for OS Deployment to Tivoli Provisioning Manager for Images
To gain access to the virtualization features provided by Tivoli Provisioning Manager for Images, you must upgrade Tivoli Provisioning Manager for OS Deployment (the build provided with Tivoli Provisioning Manager version 7.2) to Tivoli Provisioning Manager for Images.
Before you begin

Ensure that all requirements for your operating system are met. See the related links for more information. Note: When newer Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images builds become available, if an upgrade is required, you can use the same procedure to upgrade your existing Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images version to a later version. You can upgrade: v Tivoli Provisioning Manager for OS Deployment to a version later than or equal to the version released with Tivoli Provisioning Manager version 7.2. v Upgrade Tivoli Provisioning Manager for Images to a version later than or equal to the version supported with Tivoli Provisioning Manager version 7.2. To upgrade to Tivoli Provisioning Manager for Images or to a later version:
Procedure
1. Obtain the new Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images full build for the platforms used in your environment. If you are unsure, download all platforms. See Obtaining Tivoli Provisioning Manager for Images on page 396. 2. Extract all .exe files (self-extracting Windows 32-bit and 64-bit installables) to obtain the required .msi files. If you want, you can delete the .exe files. 3. Place all the Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables (tar.gz and .msi files) into the $TIO_HOME/repository/tpmfosd folder (for Windows, %TIO_HOME%\repository\tpmfosd). Note: Ensure that permissions for the files placed in the repository are set so that they are owned by tioadmin. 4. Discover the new Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables: a. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. b. In the Discovery Configuration list, click TPMfOSD Version Discovery, and then click Run. This will discover the Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables that you have placed in the repository, and will also create Tivoli Provisioning Manager software products that represent the new versions of Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images. 5. Stop Tivoli Provisioning Manager for OS Deployment on all of your servers, except the one running on the local Tivoli Provisioning Manager server. 6. Perform the following: a. In Tivoli Provisioning Manager, run a software product upgrade for Tivoli Provisioning Manager for OS Deployment on the local server: 1) Click Go To > Deployment > Software Management > Software Product Upgrade. 2) On the Software Product Upgrade page, select Tivoli Provisioning Manager for OS Deployment as the software to upgrade.
Windows
397
Results
Your systems are now upgraded to Tivoli Provisioning Manager for Images or to the newer version of Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images.
Image deployment process

When you deploy an image, the deployment is made up of several steps that are automatically run in sequence without user interaction: 1. Invoke the Image Deployment application. Click Go To > Deployment > OS Management > Image Deployment. 2. Select the target machine and image you want to install. The image deployment workflow will be run. If Tivoli Provisioning Manager can manage the target computer (it has credentials and can execute commands) and the target computer is running, then Tivoli Provisioning Manager will restart the target computer. Since the target computer must be set to boot from the network first (see Network boot on page 273), it will then PXE boot off the Tivoli Provisioning Manager for OS Deployment deployment server. If Tivoli Provisioning Manager cannot manage the target computer, then you must restart the computer yourself.
398
3. The target determines that it is starting a new deployment and queries the provisioning server for the relevant deployment OS configuration. 4. The target performs hardware discovery through DMI and PCI system calls. 5. The target queries the ODBC/JDBC database for all relevant information regarding the operating system and the software modules to be installed, and dynamically generates a deployment script. 6. If specific hardware configuration software needs to be run early (such as RAID controller configuration), you will have to deploy the hardware configuration image with an image deployment. If you want to install a hardware configuration and then an OS image afterwards, you can create a software stack containing entries for the hardware configuration stack and the OS image (for example, a golden master or unattended setup) stack. After a subsequent reboot, the target resumes the process. 7. The target partitions its hard disk according to the information retrieved from the database. A small bootstrap is also written to the hard disk, so as to be able to take over any subsequent reboot on the hard disk. 8. The target initiates a batch multicast transfer for all files needed during the deployment. The files are downloaded in the order which optimizes the efficiency of the multicast download and stored in a temporary storage location on the hard-disk. 9. When everything is done, the deployment process terminates by starting up the target computer into the operating system. Tivoli Provisioning Manager will also attempt to connect to the machine after the deployment and run an inventory scan.
Managed image types

Tivoli Provisioning Manager for Images can manage all types of images that can be managed by Tivoli Provisioning Manager for OS Deployment, plus a new image type called TPM for Images Virtual Image, which was specifically added for virtual image management support. Tivoli Provisioning Manager (TPM) for Images Virtual Image A virtual representation of a computer program and its related data such as the kernel, file systems, libraries, and programs of the managed system at a particular time. Golden master image A golden master image is a depersonalized boot device image that can be used for deployment on multiple computers. You have more options available for configuration when a machine is deployed using a golden master, such as modifying disk settings and users. Point-in-time snapshot image A Point-in-time snapshot is the partition layout and list of files to deploy an operating system, created by cloning without using Sysprep. With a snapshot, an OS restore is performed, but there is less customization available than there is with a golden master image. Hardware configuration image Hardware configurations are performed at deployment time through a vendor-dependent environment which is loaded onto the target before operating system installation. Unattended setup image You can use unattended setup to create a deployment system without actively being involved in the process. Note: You cannot capture any kind of image if your target machine (that is, the machine you are capturing from) has Tivoli Common Agent installed.
Network boot
Tivoli Provisioning Manager for OS Deployment (or Tivoli Provisioning Manager for Images) implements a PXE network boot application. There are several ways computers can boot over a network, but the one mandated by PC99 is called PXE. PXE is a type of DHCP extension. Tivoli Provisioning Manager requires that any target computer you want to use for OS or virtual image management (for example, capturing
399
images from or deploying images to) must have its boot order set to boot from the network first. This is a requirement to be able to perform operating system or virtual image management operations in a Tivoli Provisioning Manager environment. Note: Your target computer must be set to boot from the network, and also from the Tivoli Provisioning Manager for OS Deployment boot server. You might need to configure your DHCP server in order to do this: DHCP server requirements and configuration on page 296. A network boot application is different from any other program for a number of reasons: v It is invoked by the BIOS during the initial bootstrap of the computer, before any operating system or disk boot manager. v It depends on the presence of a special chip on the network card, the PXE boot ROM. v It is capable of communicating with a server over the network thanks to a programming interface provided by the bootrom. PXE is the informal standard for this kind of programming interface. v It is downloaded from a special OS deployment server, and does not depend on any local storage device. It can work on computers without hard disk, CD-ROM or diskette devices. If a local storage device is present on the computer, it is accessible to the network boot application. However, a network boot application does not fail if the storage device is corrupted or broken. v It gets its parameters (IP address and other boot parameters) from a central DHCP server. A typical network-boot sequence goes through the following phases: 1. Starting up: A user or a wake-up event starts up the remote-boot computer. 2. Network boot: The BIOS configuration (boot order), a hot key (for example, F12), or the wake-up event instructs the computer to boot on the network. 3. IP address discovery: The remote-boot target computer broadcasts a DHCP request for an IP address. Any DHCP server which knows the target (that is, recognizes its hardware address) or which has a pool of freely distributable dynamic addresses sends an IP address. The target takes the first answer and confirms it to the server. In addition to the IP address, the server gives some other network parameters to the target and information about the boot procedure to follow. 4. OS deployment server discovery: In the case of PXE remote-boot, the target computer then proceeds to the discovery of the OS deployment server. The OS deployment server is responsible for delivering a network boot program to the target. It is not necessarily the same computer as the DHCP server. The target responds to the first OS deployment server which replies and downloads a small program using a simple multicast protocol (MTFTP). 5. Server connection: If the network boot program is the deployment engine, it establishes a secure (encrypted) connection to the provisioning server and receives instructions from the server to determine the name of the program to run. 6. Pre-OS configuration: The deployment engine then downloads from the file server everything required by the OS configuration specified by the system administrator. These file transfers are done using a secure, robust and efficient unicast or multicast protocol. Many actions can be performed at this stage: installing an operating system from scratch, repairing a corrupted operating system, or performing an inventory. 7. OS booting: When instructed by the OS configuration, the deployment engine removes itself from memory and allows the computer to start the operating system, as if the computer is booting normally from the hard disk. This ensures full compatibility with the operating system and avoids all problems of the traditional diskless remote boot. Note: Tivoli Provisioning Manager for OS Deployment features a fault-tolerant server architecture, with the OS deployment server always available to the target. However, in case of severe network failure, targets can be configured to work in offline mode, without network access. In this scenario, the deployment engine is stored on a permanent storage medium, such a hard disk partition or a CD-ROM, and started from that medium instead of being loaded from the network.
400
Booting targets without using PXE

If you do not want to use PXE on your network, you can use Tivoli Provisioning Manager for OS Deployment to create a network boot CD, DVD, or USB drive. With network boot media, your target can boot and connect to the Tivoli Provisioning Manager for OS Deployment server in a PXE-less environment. Use this kind of deployment when it is not possible to use PXE to boot the target. Some typical situations are network card without PXE support, firewalls preventing PXE traffic, non-allowed PXE boot, or an unavailable DHCP server. To create the network boot media, you can either use the web interface wizard or run command lines from a computer with the web interface extension installed. Whether you have Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installed, the creation of the network boot media is the same. For procedural details, see the following links. Note: v Network boot media must be updated every time the OS deployment server is updated or upgraded to ensure compatibility with the OS deployment server. v If your network boot media is optimized for Windows operating systems, you must create the media from an OS deployment server or a web interface extension installed on a computer with the same byte order (little endian or big endian) as the one on which you want to use the network boot media.
Creating network boot USB drive with the wizard

Tivoli Provisioning Manager for OS Deployment can automatically generate bootable USB drives that connect the target to an OS deployment server, without using DHCP or PXE, to perform deployments.
Before you begin

Install the rbagent, also known as web interface extension, on a Windows target. The USB drive must be formatted as FAT32 or NTFS. USB keys already filled with a bootable operating system might not work. Note: SuSE Linux Enterprise Desktop cloning is not supported on USB drive deployments These bootable USB drives can also be used to deploy computers without a PXE compliant network adapter. To create OS bootable USB drives:
Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. Click Create deployment media. 3. Select Create a network boot USB key to start the USB key wizard. Click Next. 4. Specify the operating system on which to boot the target. Select Optimized for Linux to load an embedded Linux environment or Optimized for Windows to load a WinPE deployment engine. Note: Before clicking Optimized for Windows, ensure that you created the WinPE deployment engine. To determine what WinPE version is required, see the Tivoli Provisioning Manager for OS Deployment documentation. If you have the WinPE deployment engine on the OS deployment server, the WinPE deployment engine starts by default. Otherwise the default is to start embedded Linux. Only when embedded Linux or WinPE is running, does the target connect to the network and try to contact an OS deployment server.
401
5. If you want to obtain the target IP address through DHCP, select Dynamic IP address with DHCP, and click Next. If you want to use a fixed IP address for your target instead of having it go to the DHCP server, select Static IP address, and click Next. a. Enter the target IP address, gateway, and network mask. b. (Optional) Select Allow IP address override at runtime to be able to modify the target IP address when starting up the target. c. Click Next. 6. Enter the IP address of the OS deployment server. 7. (Optional) Select Allow server IP address override at runtime to be able to modify the IP address of the OS deployment server when starting up the target. 8. Plug your USB key into a machine running the web interface extension, and specify its address. 9. Choose the drive matching your USB key. 10. Click Finish to close the wizard.
What to do next
Use the USB drive to boot the target.
Creating a network boot CD or DVD with the wizard

Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. Click Generate media at the bottom of the page. 3. Select Create a network boot CD/DVD and click Next. 4. If you want to obtain the target IP address through DHCP, select Dynamic IP address with DHCP, and click Next. If you want to use a fixed IP address for your target instead of having it go to the DHCP server, select Static IP address, and click Next. a. Enter the target IP address, gateway, and network mask. b. (Optional) Select Allow IP address override at runtime to be able to modify the target IP address when starting up the target. c. Click Next. 5. Specify the operating system on which to boot the target. Select Optimized for Linux to load an embedded Linux environment or Optimized for Windows to load a WinPE deployment engine. Note: Before clicking Optimized for Windows, ensure you created the WinPE deployment engine. To determine what WinPE version is required, see the Tivoli Provisioning Manager for OS Deployment documentation. If you have the WinPE deployment engine on the OS deployment server, the WinPE deployment engine starts by default. Otherwise the default is to start embedded Linux. Only when embedded Linux or WinPE is running, does the target connect to the network and try to contact an OS deployment server. 6. Enter the IP address of the OS deployment server. 7. (Optional) Select Allow server IP address override at runtime to be able to modify the IP address of the OS deployment server when starting up the target. Note: When you create the network boot CD or DVD in a multiserver infrastructure, ensure that the OS deployment servers share the same password and port number. The network boot CD or DVD works only if you specify the IP address of a OS deployment server having the same password and port number of the OS deployment server that generated the ISO file.
402
8. Click here on the screen to download the ISO file. 9. Click Finish to close the wizard.
What to do next
The generated ISO file can be burned to create the network boot CD. To start a target computer over the network using your OS deployment server without booting through PXE, start the target on the network boot CD and the target automatically connects to the OS deployment server.
Creating a network boot USB drive with command lines

You can create a network boot USB drive, which Tivoli Provisioning Manager for OS Deployment can use when a target cannot boot from the network.
Before you begin

Install the rbagent, also known as web interface extension, on a Windows target. The USB drive must be formatted as FAT32 or NTFS. Existing files on the USB drive are not deleted. USB keys already filled with a bootable operating system might not work. The command line must be used only when the web interface is either inappropriate or unavailable.
Procedure
v If you want to obtain the target IP address through DHCP, use this command line:
Windows
On Windows operating systems
rbagent.exe -s <OSD_server_ip_address>:<OSD_server_password> rad-mkbootusb <drive> <USB_OSD_server_ip_address> <USB_OSD_server_password> [allowsrvipoverload] [nowpe|preferwpe] [bootopt nnn] [clearcmos]
where: OSD_server_ip_address Is the IP address of the OS deployment server. OSD_server_password Is the password for the administrative user (typically admin) on your OS deployment server. drive Is a drive letter of the Windows target where you run the rbagent command. The rad-mkbootusb command adds the requested files to the FAT32 or NTFS partition and makes it bootable. The drive must be already formatted. Existing files on the partition are not deleted.
USB_OSD_server_ip_address Is the IP address of the OS deployment server that the target must contact, when it boots from the USB drive. USB_OSD_server_password Is the password of the OS deployment server that the target must contact, when it boots from the USB drive. allowsrvipoverload Allows you to choose an OS deployment server later, from the target. nowpe|preferwpe Defines if an embedded Linux environment or WinPE2 environment is loaded from the USB drive, when a target boots from this USB drive, without accessing the network. Only when embedded Linux or WinPE2 is running, does the target connect to the network and try to
403
contact an OS deployment server. If you deploy only Linux, specify prefermcp to skip the WinPE2 deployment engine. You can specify preferwpe only if there is a WinPE2 deployment engine on the OS deployment server. bootopt nnn Allows you to specify additional flags before the boot. clearcmos Resets the CMOS alarm fields if they are in an invalid state. For example:
> C:\TPMfOSd Files\global\http\agents\rbagent.exe -s 10.10.10.10:abcd rad-mkbootusb C: 10.10.10.10 abcd
v If you want to use a fixed IP address for your target instead of having it go to the DHCP server, use this command line: On Windows operating systems:
rbagent.exe -s <OSD_server_ip_address>:<OSD_server_password> rad-mkbootusb <drive> <USB_OSD_server_ip_address> <USB_OSD_server_password> fixed [fixed_ip_address] [fixed_netmask] [fixed_gateway_ip_address] [allowsrvipoverload] [nowpe|preferwpe] [allowipoverload] [bootopt nnn] [clearcmos]
where: OSD_server_ip_address is the IP address of the OS deployment server. OSD_server_password is the password for the administrative user (typically admin) on your OS deployment server. drive is a drive letter of the Windows target where you run the rbagent command. The rad-mkbootusb command adds the requested files to the FAT32 or NTFS partition and makes it bootable. The drive must be already formatted. Existing files on the partition are not deleted.
USB_OSD_server_ip_address Is the IP address of the OS deployment server that the target must contact, when it boots from the USB drive. USB_OSD_server_password Is the password of the OS deployment server that the target must contact, when it boots from the USB drive. fixed_ip_address Is the static IP address of the target you boot using the USB drive. fixed_netmask Is the netmask of the target you boot using the USB drive. fixed_gateway_ip_address Is the IP address of the gateway that the target uses. nowpe|preferwpe Defines if an embedded Linux environment or WinPE2 is loaded from the USB drive, when a target boots from this USB drive, without accessing the network. Only when embedded Linux or WinPE2 is running, does the target connect to the network and try to contact an OS deployment server. If you deploy only Linux, specify nowpe to skip the WinPE2 software module. You can specify preferwpe only if there is a WinPE2 software module on the OS deployment server. allowipoverload Allows you to define IP settings manually on the target.
404
bootopt nnn Allows you to specify additional flags before the boot. clearcmos Resets the CMOS alarm fields if they are in an invalid state.
What to do next
You can now boot the target using the network boot USB drive instead of the network card. To use the PXE emulation USB key, insert the USB key into the drive and restart the target. If your machine does not boot from the USB key, check the BIOS boot list to see if your USB drive is included in the boot sequence and is listed before the hard disk. Most machines also allow you to select the temporary boot device without changing the boot sequence in BIOS.
Creating a network boot CD or DVD with command lines

This mode must be used only when the web interface is either inappropriate or unavailable. Note: When you create the network boot CD or DVD in a multiserver infrastructure, ensure that the OS deployment servers share the same password and port number. The network boot CD or DVD works only if you specify the IP address of a OS deployment server having the same password and port number of the OS deployment server that generated the ISO file.
Procedure
v If you want to obtain the target IP address through DHCP, use these command lines:
UNIX Linux
#./rbagent -s <target_ip_address>:<target_password> rad-mkbootcd <full_path_to_boot_iso> <target_ip_address> <target_password>
Windows
rbagent.exe -s <target_ip_address>:<target_password> rad-mkbootcd <full_path_to_boot_iso> <target_ip_address> <target_password>
where: target_ip_address Is the IP address of the OS deployment server. target_password Is the password for the administrative user (typically admin) on your OS deployment server. full_path_to_boot_iso Is the full path to the .iso file you want to create on the target where you run the rbagent command. For example:
> C:\TPMfOSd Files\global\http\agents\rbagent.exe -s 10.10.10.10:abcd rad-mkbootcd C:\boot.iso 10.10.10.10 abcd
This creates a file called boot.iso in c:\ which can be burned onto a CD. v If you want to use a fixed IP address for your target instead of having it go to the DHCP server, use these command lines:
UNIX Linux
405
#./rbagent -s <target_ip_address>:<target_password> rad-mkbootcd <full_path_to_boot_iso> <target_ip_address> <target_password> [fixed_ip_address] [fixed_netmask] [fixed_gateway_ip_address]
Windows
> rbagent.exe -s <target_ip_address>:<target_password> rad-mkbootcd <full_path_to_boot_iso> <target_ip_address> <target_password> [fixed_ip_address] [fixed_netmask] [fixed_gateway_ip_address]
where: fixed_ip_address Is the static IP address of the target you boot using the CD. fixed_netmask Is the netmask of the target you boot using the CD. fixed_gateway_ip_address Is the IP address of the gateway the target uses.
What to do next
The generated ISO file can be burned to create the network boot CD. To start a target computer over the network using your OS deployment server without booting through PXE, start the target on the network boot CD and the target automatically connects to the OS deployment server.
Requirements
Before you proceed with the virtual images management, ensure that all hardware and software requirements are met.

To perform virtual image management tasks, ensure that you have the required knowledge and access rights to perform your role.
Table 67. User roles Role Provisioning Administrator Description v Upgrades Tivoli Provisioning Manager for OS Deployment to Tivoli Provisioning Manager for Images, to enable the virtual images management. v Installs the web interface extension on hypervisors. v Performs higher level management of the environment such as installing or deleting boot servers. Skills v Knowledge of boot server and virtualization technologies.
406
Table 67. User roles (continued) Role Provisioning Configuration Librarian Description Skills
v Knowledge of provisioning server v Manages overall product configuration, boot server, and configuration. Responsible for virtualization technologies. setting up the environment to support boot server and hypervisor technologies. v Performs virtual image discovery, replication, capture, import, export, and deployment activities.
Deployment Specialist
v Deploys captured virtual images to v Server and image management target computers. experience. v Knowledge of hypervisor technologies. v Familiarity with OS management life cycle.
End User
v The individual who uses a target computer, typically a notebook, desktop or server.
v Basic knowledge of the operating system on the target computer.
Web interface prerequisites

Web interface prerequisites for managing operating systems The name resolution is not always properly set on Linux computers. When trying an HTTP connection to a running OS deployment server on a Linux computer, whether locally or remotely, the web interface could not appear. The OS deployment server redirects an HTTP connection made using an IP address to the name of the running OS deployment server. If the server name cannot be found on the local computer, the connection fails. For instance HTTP://127.0.0.1 is usually redirected to HTTP://localhost. To solve the problem, you must edit, on the computer running the Web browser, the file containing name resolution information and add the IP address and the name of the OS deployment server you want to connect to. The location of the name resolution file depends on the operating system: v v v
UNIX Windows Windows Linux XP 2000
/etc/hosts
2003 Vista 2008 Windows 7
C:\WINDOWS\system32\drivers\etc\hosts
Server: C:\WINNT\system32\drivers\etc\hosts
For more information, go to the IBM Tivoli Provisioning Manager for Images information center.
Hypervisor requirements
To take advantage of the interaction with the hypervisor for virtual image management, the following requirements must be met. The hypervisor requirements ensure that Tivoli Provisioning Manager for Images can communicate with the web interface extension (rbagent) installed on your hypervisor. Note: If the requirements are not met, Tivoli Provisioning Manager for Images will treat a virtual machine the same as a physical machine. You will still be able to capture and deploy virtual images, but without taking full advantage of the interaction with the hypervisor.
VMWare ESX 3.5 hypervisor requirements

To successfully discover, capture, or deploy a virtual image on VMWare ESX 3.5 hypervisor, you must install the Virtual Disk Development Kit (VDDK) Version 1.1 library on the hypervisor.
407
To configure the VMWare ESX 3.5 hypervisor: 1. Disable the active firewall, by running, for example, the following command: etc/init.d/firewall stop. 2. Download the FUSE 2.5.3 library from SourceForge.net and compile it on the VMWare ESX hypervisor. For details, see the INSTALL instruction file in the decompressed library folder. This library is a prerequisite of VDDK. 3. Download VDDK version 1.1 from VMWare Cloud Computing with Virtualization and install it on a VMWare ESX hypervisor. 4. Define the VDDK path in the library path of the user running the rbagent by adding the following line to the /root/.bashrc file and reload it:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/vmware-vix-disklib/lib32/
5. Install libxml2 version 2.6.16 or copy the libxml2.so.2.6.16 file and create the following symbolic link:
ln -s /usr/lib/libxml2.so.2.6.16 /usr/lib/libxml2.so.2
6. After the VDDK installation, reboot the hypervisor. 7. Ensure that the VMWare ESX hypervisor supports the following command:
vmware-cmd -l
8. Before running the full inventory, capture, or deployment of a virtual server, ensure that the virtual server is powered off. 9. Ensure that the web interface extension is running on the VMWare ESX hypervisor with the rad-refreshhypervisor option. To do this on Linux, copy rbagent.linux from the <TPMfOSD_DATA_DIR>\global\http\agents directory of the OS deployment server to the VMWare ESX hypervisor, set the execution permission: chmod +x rbagent.linux, and launch the web interface extension with the following syntax:
./rbagent.linux -d -s <server ip>:<Web_user_interface_administrator_password> rad-refreshhypervisor
Ensure that only one instance of web interface extension is running. Note: Tivoli Provisioning Manager for Images does not support the capture or deployment when the file systems are ReiserFs, LVM. 10. Ensure that the vmware.conf file is located in the same directory where the web interface extension is installed and has the following content:
ESX_HOST=127.0.0.1 ESX_USER=root ESX_PWD=password ESX_PORT=902
The following is an example of a running VMWare ESX hypervisor configuration: v VMWare ESX 3.5 U4 v fuse-2.5.3.tar.gz (compiled by running the configure, make, and make install commands) v VDDK library: VMware-vix-disklib-1.1.0-163495.i386.tar.gz v /usr/lib/vmware-vix-disklib/lib32 defined in the library path v libxml2 version 2.6.16 (with libxml2-2.6.16-1.1.el3.rf.i386.rpm and libxml2-python-2.6.161.1.el3.rf.i386.rpm) or a link between /usr/lib/libxml2.so.2 and /usr/lib/libxml2.so.2.6.16 (ln -s /usr/lib/libxml2.so.2.6.16 /usr/lib/libxml2.so.2)
VMWare ESX 4.0 hypervisor requirements

To successfully discover, capture, or deploy a virtual image on VMWare ESX 4.0 hypervisor, you must install the Virtual Disk Development Kit (VDDK) Version 1.1 library on the hypervisor. To configure the VMWare ESX 4.0 hypervisor:
408
1. Ensure that VMWare ESX 4.0 is installed by running cat /etc/vmware-release. 2. Disable the active firewall, by running, for example, the following command: etc/init.d/firewall stop. 3. Download the FUSE 2.7.4-1 library from SourceForge.net and compile it on the VMWare ESX hypervisor or download an already compiled libfuse.so.2 rpm package such as libfuse-2.7.41.el5.pp.i386.rpm from http://rpm.pbone.net/index.php3/stat/4/idpl/9551006/com/libfuse2.7.4-1.el5.pp.i386.rpm.html. Install FUSE on the hypervisor, for example, by entering the following command:
rpm -ivh libfuse-2.7.4-1.el5.pp.i386.rpm
4. Download VDDK version 1.1.1 (VMware-vix-disklib.*.tar.gz 32bit version) from VMWare Cloud Computing with Virtualization and install it on a VMWare ESX hypervisor. Extract the contents: tar -zxvf VMware-vix-disklib.*.tar.gz and run ./vmware-install.pl to install VDDK 1.1.1. A warning message about a missing libfuse.so.2 library might be displayed even if the library is installed. Proceed with the next configuration steps. 5. After the VDDK installation, reboot the hypervisor. 6. Do not install libxml2 because a supported version is already installed in VMWare ESX 4.0. Check that libxml2-2.6.26 is already present. 7. Define the VDDK path in the library path of the user running the rbagent by adding the following line to the /root/.bashrc file and reload it:
export LD_LIBRARY_PATH=:/usr/lib/vmware-vix-disklib/lib32
8. Ensure that the VMWare ESX hypervisor supports the following command:
vmware-cmd -l
9. Create vmware.conf in the same directory where the web interface extension is installed and ensure that it has the following content:
10. Ensure that the web interface extension is running on the VMWare ESX hypervisor with the rad-refreshhypervisor option. To do this on Linux, copy rbagent.linux from the <TPMfOSD_DATA_DIR>\global\http\agents directory of the OS deployment server to the VMWare ESX hypervisor, set the execution permission: chmod +x rbagent.linux, and launch the web interface extension with the following syntax:
Ensure that only one instance of web interface extension is running. Note: Tivoli Provisioning Manager for Images does not support the capture or deployment when the file systems are ReiserFs, LVM. The following is an example of a running VMWare ESX hypervisor configuration: v VMWare ESX 4.0 v libfuse-2.7.4-1.el5.pp.i386.rpm (compiled by running the configure, make, and make install commands) v VDDK library: VMware-vix-disklib.*.tar.gz v /usr/lib/vmware-vix-disklib/lib32 defined in the library path v libxml2 version 2.6.26
KVM hypervisor requirements

To successfully discover, export, import, or deploy a virtual image on a KVM hypervisor, you must ensure that the libvirt library is installed and configured on the hypervisor.
409
Note: The image deployment is supported on the KVM hypervisor, only if you boot from a network boot CD or DVD. Before starting a hypervisor discovery, the web interface extension checks if the libvirt library is installed otherwise the discovery mechanism uses the virsh commands on each hypervisor. To ensure that the libvirt library is correctly installed, check that the libvirt.so file, used by the web interface extension to detect libvirt installation, is defined in the hypervisor library path. If the libvirt.so file does not exist, you must create it as a symbolic link pointing to the libvirt library file. For example, you can enter the following command:
ln -s /usr/lib/libvirt.so.0 /usr/lib/libvirt.so
In this way libvirt.so points to the libvirt.so.0 libvirt library. KVM native commands: If you want to use the virsh commands, ensure that the following command:
capabilities
runs correctly from a virsh shell. KVM discovery works with objects defined in libvrt: The web interface extension runs the KVM discovery only on objects that are defined in the libvirt library. Additional requirements: Before running the full inventory, capture, or deployment of a virtual machine, ensure that the virtual machine is powered off. KVM hypervisor machine must be 64 bit. KVM hypervisor must have CPU with virtualization extension (check for vmx, svm flags under /proc/cpuinfo as follows: egrep (vmx|svm) /proc/cpuinfo) This command looking for either vmx or svm and outputs where it finds them. KVM guests must run under a KVM engine, not under QEMU (check this by running the following command: virsh dumpxml <kvm_guest_name>, the output must contain the following information <domain type=kvm id=xx>) Ensure that the web interface extension is running on the KVM hypervisor with the radrefreshhypervisor option. To do this on Linux, copy rbagent.linux from the <TPMfOSD_DATA_DIR>\ global\http\agents directory of the OS deployment server to the KVM hypervisor, set the execution permission: chmod +x rbagent.linux, and launch the web interface extension with the following syntax:
Ensure that only one instance of web interface extension is running. The raw disk is the only virtual disk format supported. Note: Tivoli Provisioning Manager for Images does not support the capture or deployment when the filesystems are ReiserFs, LVM.
Server system requirements

Before you install OS deployment servers, ensure that you meet the system requirements.
410
The minimum recommended configurations for the OS deployment server includes:
Table 68. Hardware requirements for the OS deployment server Processor type Minimum Recommended Dual-Xeon Quad-core or two dual-core Processor speed 2 GHz 2 GHz RAM 1 GB RAM 2 GB RAM Free disk space 10 GB 100 GB
Store Tivoli Provisioning Manager for OS Deployment files on a large hard disk if you plan to create many hard-disk images, and you might want to use a fast processor to minimize the time spent creating these images. The OS deployment server is multithreaded and benefits from computers with multiple processors.

Tivoli Provisioning Manager for OS Deployment must be installed during Tivoli Provisioning Manager installation, so that the parent OS deployment server is installed on the provisioning server. If you decide to add a child OS deployment server after the Tivoli Provisioning Manager installation, you can install the OS deployment server on any of the supported platforms for the provisioning server. For more information, see Supported operating systems and platforms for target computers. Compatible operating system and architecture for Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images are listed in the following table:
Table 69. Server operating systems Operating system Windows XP Professional Server Windows 2003 Server Windows 2008 Server SUSE Linux Enterprise Server (SLES) 10 SUSE Linux Enterprise Server (SLES) 10 SUSE Linux Enterprise Server (SLES) 10 SUSE Linux Enterprise Server (SLES) 11 SUSE Linux Enterprise Server (SLES) 11 SUSE Linux Enterprise Server (SLES) 11 Red-Hat Enterprise Linux Server 5 Red-Hat Enterprise Linux Server 5 IBM AIX 6.1 Solaris 10 Update 6 Architecture x86-32 and x86-64 x86-32 and x86-64 x86-32 and x86-64 x86-32 and x86-64 IBM PowerPC 64 (iSeries and pSeries) IBM System z x86-32 and x86-64 IBM PowerPC 64 (iSeries and pSeries) IBM System z x86-32 and x86-64 IBM PowerPC 64 (iSeries and pSeries) IBM PowerPC 64 (iSeries and pSeries) SPARC 64-bit
Also, Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images can work with almost any RFC-compliant DHCP server, including Windows 2003 DHCP server, Windows 2000 DHCP server, ISC DHCP server, Solaris DHCP server and the Netware 5 DHCP server.
Target system requirements

For virtual image management, the following target system requirements must be met.
411
The following are the requirements for x86 and x8664 targets: v Minimal processor: Pentium type level. v Minimal RAM memory: 512 MB. Note: Windows 1 GB might be necessary on some targets to run WinPE2. 1 GB RAM is also necessary on the reference target to capture a golden master or a virtual image. v VESA-compliant (release 2.0 or later) Video BIOS to get "high" resolution (VGA fallback is always possible in case of incompatibility) and to have a user interface on the target. Note: Tivoli Provisioning Manager for OS Deployment can also work on headless computers, in which case all operations have to be performed from the web interface. v Either a legacy ATA drive (with Ultra DMA support if speed is required) or a BIOS-supported hard drive. v DMI support for collecting hardware information, such as model and serial number. Note: Disks with a size equal to or larger than 1 TB are not supported on targets running Linux and on virtual images. To make full use of the Tivoli Provisioning Manager for OS Deployment features, remote-boot x86 and x8664 targets must be equipped with a PXE-compliant bootrom, either version 2.00 or later. Most recent computers with on-board network adapters have built-in PXE support. The network cards that have been shown to work best with Tivoli Provisioning Manager for OS Deployment are Intel adapters. For computers without built-in PXE support, you might consider using a PXE emulation floppy available from various third party sources, creating network boot media, or working offline with deployment media. SUN SPARC targets need a firmware that supports the SUN wanboot method for network booting. Wanboot is the only supported network boot method for SUN SPARC. Tivoli Provisioning Manager for OS Deployment can also deploy operating systems to VMWare virtual machines. Use of the Intel e1000 adapter on VMWare virtual machines requires VMWare ESX 3.0.2 with February 2008 patches, VMWare ESX 3.5 or later, VMWare Workstation 6.0.3 or later, VMWare Server 2.0 or later. Microsoft Virtual PC and Microsoft Virtual Server are not supported.

Compatible operating system, version, and architecture for OS deployments on Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images targets are listed in Table 1:
412
Table 70. Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images target operating systems Operating system Windows Server 2008 Version GA, R2, R2-SP1 (See note) Architecture x86-32 and x86-64 Disk and memory requirements For image deployment v 10 GB free disk space (32-bit) v 20 GB free disk space (64-bit) v 1 GB RAM For image capture v 1 GB RAM
Windows 7
GA and SP1 (See note)
x86-32 and x86-64
Windows Vista
GA and SP2
x86-32 and x86-64
Windows 2003 Server Windows XP Professional SUSE Linux Enterprise Server (SLES) SUSE Linux Enterprise Server (SLES) SUSE Linux Enterprise Server (SLES) SUSE Linux Enterprise Desktop (SLED) SUSE Linux Enterprise Server (SLES) Red-Hat Enterprise Linux (RHEL) Server Red-Hat Enterprise Linux (RHEL) Server Red-Hat Desktop Red-Hat Enterprise Linux (RHEL) Server
SP2/R2 SP3 11 11 10 SP3 10 SP3 10 SP3 6 (See note) 5, Update 3 5, Update 3 5, Update 3
x86-32 and x86-64 x86-32 and x86-64 x86-32 and x86-64 IBM PowerPC 64 (pSeries) x86-32 and x86-64 x86-32 and x86-64 IBM PowerPC 64 (pSeries) x86-32 and x86-64
x86-32 and x86-64 x86-32 and x86-64 IBM PowerPC 64 ( pSeries)
413
Table 70. Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images target operating systems (continued) Operating system Red-Hat Enterprise Linux (RHEL) Server Red-Hat Desktop Solaris Solaris Solaris IBM AIX 5L IBM AIX 6L VMWare ESX Server VMWare ESX Server VMWare ESX Server Version 4, Update 8 4, GA version only 10 Update 6 10 9 (cloning only) 5.3 (setup only) 6.1 (setup only) 4.0 3.5 Update 4 3.0.2 Architecture x86-32 and x86-64 x86-32 and x86-64 SPARC 64-bit SPARC 64-bit SPARC 64-bit IBM PowerPC 64 (pSeries) IBM PowerPC 64 (pSeries) x86-32 x86-32 x86-32 Disk and memory requirements
Note: Windows 2008 R2 SP1, Windows 7 SP1, and Red-Hat Enterprise Linux 6 are currently supported with Tivoli Provisioning Manager for OS Deployment version 7.1.1.5.
File system requirements

Support for Windows Vista/2008/7 is restricted to NTFS partitions. FAT 32 partitions are not supported. Supported file systems include: v The Second Extended File system (Ext2) and Third Extended File system (Ext3). Tivoli Provisioning Manager for OS Deployment can natively write files on Ext2 and Ext3. This means that the product can create and format Ext2 and Ext3 partitions, and can add, delete, and modify files on these partitions. v Partitions UUID and labels v LVM file system Note: Tivoli Provisioning Manager for OS Deployment cannot capture an image, or perform direct replication from a target with unformatted partitions, or partitions formatted using an unsupported proprietary file system. Such partitions should be either deleted or formatted using a supported file system before capturing or replicating an image to another computer.
Setting up additional child OS deployment servers

If you installed Tivoli Provisioning Manager for OS Deployment during the Tivoli Provisioning Manager installation, a primary boot server is installed on the provisioning server. This is the parent server. If you want, you can then add child servers to distribute the OS deployment workload. Remember: For Tivoli Provisioning Manager for Images, the procedure to install additional child servers is identical with this one, for Tivoli Provisioning Manager for OS Deployment. If you did not install Tivoli Provisioning Manager for OS Deployment during Tivoli Provisioning Manager installation, you must run the Tivoli Provisioning Manager installation again to install the parent boot server on the provisioning server.
414
Provisioning server
Remote server 1
Parent boot server
Child boot server
Remote server 2
Child boot server
If you install child servers, you can optionally promote a child server to be the parent boot server.
Child boot server
Parent boot server
Remote server 2
Child boot server
Tivoli Provisioning Manager for OS Deployment can support environments with a large number of target computers by spreading the workload between multiple boot servers. Replication is the means to keep files and information up-to-date between parent and child servers. All images are automatically replicated to the parent server, and from the parent server to all the child servers. The Tivoli Provisioning Manager for OS Deployment database is stored on the provisioning server. Child servers do not have their own databases, but point to the parent database.
Creating child OS deployment servers

You can install Tivoli Provisioning Manager for OS Deployment child servers to distribute the OS deployment workload.
Before you begin

The computer where you want to install a new OS deployment server must be an existing Tivoli Provisioning Manager managed computer. Ensure that the computer meets basic requirements for target computers: Server system requirements on page 280. To successfully deploy a child server, ensure that your target system exposes the Windows cpu.type ( Linux cpu.family) property under hardware resources, otherwise Tivoli Provisioning Manager cannot resolve to the correct ( Windows 32bit or 64bit) installable file ( Linux for Intel, AMD, zSeries, and PowerPC systems). To perform this task: 1. Discover a target computer. See Discovering your target computers on page 568.
415
2. Discover hardware resources on the target computer. See Discovering hardware using provisioning Inventory discovery on page 164. If a Tivoli Provisioning Manager for OS Deployment boot server was not installed during Tivoli Provisioning Manager installation, you must rerun the Tivoli Provisioning Manager again to install it. For instructions, see the Tivoli Provisioning Manager Installation Guide. To create a child OS deployment server:
Procedure
1. 2. 3. 4. Click Go To > Deployment > OS Management > Boot Server Installation. Select the computer that you want to use as your OS deployment server. Select TPMfOSd for the Boot Server Type. Click OK. Review the information, then click Submit.
Results
You have now installed a child OS deployment server. Uninstalling child OS deployment servers: You can uninstall the child OS deployment servers that you no longer require. To uninstall your OS deployment server: Procedure 1. Click Go To > Deployment > Provisioning Computers. 2. Select the computer that has the OS deployment server installed. 3. Click Select Action > Uninstall > Software Installation and uninstall the OS deployment server installation. Results You have now uninstalled your child OS deployment server.
Promoting a child OS deployment server

You can promote a child OS deployment server so that it becomes the parent OS deployment server. You might want to promote a child OS deployment server to a parent OS deployment server to cut down on the workload on the provisioning server. Important: Promoting a child server is a major operation that modifies all Tivoli Provisioning Manager for OS Deployment boot servers in their infrastructure. All OS deployment servers must be running in a good state, with no Tivoli Provisioning Manager for OS Deployment activities running before performing this operation. To promote a child OS deployment server:
Procedure
1. Click Go To > Deployment > OS Management > Boot Servers. 2. From the Select Action menu, click Promote a child boot server to parent. 3. When prompted, click Yes.
416
Results
The child server is now a parent server, and the parent server is now a child server.
Windows Preinstallation Environment (WinPE)

Windows Preinstallation Environment is more and more widely used in all the tasks pertaining to the deployment of Windows operating systems. Tivoli Provisioning Manager for OS Deployment uses three different kinds of WinPE2 software modules, depending on the tasks at hand.
WinPE3: If you have upgraded to Tivoli Provisioning Manager for OS Deployment version 7.1.1.4, the supported WinPE deployment engine is 3.0. Other versions are not compatible. WinPE 3.0 must be created from a Windows Automated Installation Kit (AIK) for Windows 7 in English. To learn more about using WinPE3, see Managing multiple WinPE 3.0 deployment engines on page 289.
Types of WinPE2
WinPE2 consists of a group of files that can be loaded as a ramdisk, which enable you to perform operations on a target. WinPE2 deployment engine This WinPE2 is a prerequisite to create Windows images and deploy them. You must store only one WinPE2 deployment engine on your OS deployment server, as it is independent of the architecture or the version of the Windows operating system you work with. However, depending on your hardware, you might have to inject specific drivers in your WinPE2 deployment engine. To create a WinPE2 deployment engine you need a computer running Windows 32-bit, with Windows Automated Installation Kit (WAIK) 1.1 32-bit in English installed, and running the web interface extension. WinPE2 ramdisk This WinPE2 contains the installation files for any Windows Vista/2008/7 operating system. It can be found on the original installation CD/DVD. In the case of a Windows Vista/2008/7 unattended setup creation, the WinPE2 ramdisk software module is automatically created and bound to the image, which ensures your WinPE2 to be of the correct version. For golden master images, you also need a WinPE2 ramdisk if you need to inject drivers into your image. In this case, you might need to create your WinPE2 ramdisk using the Software wizard. To create a WinPE2 ramdisk, you need a computer running Windows 32-bit, with WAIK 1.1 32-bit in English installed, and running the web interface extension. You also need the original Windows Vista/2008/7 installation CD/DVD. Note: A 64-bit WinPE2 ramdisk is required to be able to reuse Windows Vista and Windows 2008 64-bit images created with an earlier version of Tivoli Provisioning Manager for OS Deployment, for example, version 7.1.1. WinPE2 hardware environment This type of WinPE2 is used for hardware configurations. To create a WinPE2 hardware environment, you must start the vendor commands on a computer running Windows 32-bit, with WAIK 1.1 32-bit in English installed, and the web interface extension installed. You must start the vendor commands before you start the web interface extension.
417
Windows Automated Installation Kit (WAIK)

Note: Windows Automated Installation Kit for Windows 7 and Windows Server 2008 R2 is not supported. Use Windows Automated Installation Kit 32-bit for Windows Vista and Windows Server 2008 in English. You must restart your computer after having installed WAIK.
Good practice
If you deploy Windows operating systems, you need to create one WinPE2 deployment engine, and potentially several WinPE2 ramdisks and WinPE2 hardware configurations. For each of these creations, you need a computer running under Windows, with WAIK and the web interface extension installed. The same configuration is also needed to update Windows Vista/2008/7 images, and to inject drivers into the WinPE2 deployment engine. WAIK can be obtained free of charge from Microsoft, but it is rather heavy and cumbersome to install. Therefore, it is good practice to install WAIK and the web interface extension on a target running a Windows operating system and to perform all operations requiring this configuration on this dedicated target.
Creating a WinPE2 deployment engine

To create or deploy Windows images, you must create a WinPE2 deployment engine.
Before you begin

Ensure that the computer from which you create the WinPE2 deployment engine: v Runs a 32-bit version of Windows. v Has Windows Automated Installation Kit (WAIK) installed. v Runs the web interface extension. This computer can be: v A local OS deployment server installed on a Windows 2000/2003/2008/XP/Vista/7 operating system v Any computer with a Windows 2000/2003/2008/XP/Vista/7 operating system. Note: To work with a Windows target, you must install Windows Automated Installation Kit (WAIK) 1.1 32-bit for Windows Vista and Windows 2008 in English. Windows Automated Installation Kit for Windows 7 and Windows Server 2008 R2 is not supported. Note: If you upgraded your Tivoli Provisioning Manager for OS Deployment to 7.1.1.4 or higher, create WinPE deployment engines using the application at Click Go To > Deployment > OS Management > OS Deployment Engines. . For more information about the OS Deployment Engines application, see Managing multiple WinPE 3.0 deployment engines on page 289. You must create a WinPE2 deployment engine only once, unless you deleted it. To start the WinPE2 software module creation:
Procedure
1. Navigate to the Software Modules page. Click Go To > Deployment > OS Management > Software Modules. 2. From the contextual menu, click Add a new software. The Software wizard is displayed. 3. Select one of the Windows operating systems as the type of software module to create, and click Next.
418
4. Select WinPE 2 engine for OS deployment server ramdisk image, and click Next. 5. Specify the address of the computer on which you installed WAIK and the web interface extension, and click Next. 6. Click Finish.
Results
The resulting WinPE2 deployment engine appears as a software module in the WinPE2 Deployment engine specific folder.
What to do next
The created WinPE2 deployment engine might not contain all the necessary drivers depending on the hardware on which you want to use it. If this is the case: 1. Create software modules with the missing drivers. 2. Double-click the WinPE2 deployment engine to view the software details. 3. Click Update drivers. 4. Specify the address of the computer on which you installed WAIK and the web interface extension, and click Next. 5. Select the software modules containing the drivers you need to inject in your WinPE2 deployment engine and click Next. After you created the WinPE2 deployment engine, you can create and deploy Windows images. Note: During the deployment, do not edit the WinPE2 deployment engine that you are using.
Creating a WinPE2 ramdisk

WinPE2 ramdisks are automatically created and bound to your image when you create an unattended setup for Windows Vista/2008/7. However, you need to create one manually if you need to inject divers into a Windows Vista/2008/7 golden master image or Tivoli Provisioning Manager for Images virtual image.
Before you begin

To create a WinPE2 ramdisk, you need a computer running Windows 32-bit, with WAIK 1.1 32-bit in English installed, and running the web interface extension. You also need the original Windows Vista/2008/7 installation CD/DVD. To create a WinPE2 ramdisk software module:
Procedure
1. 2. 3. 4. Click Go To > Deployment > OS Management > Software Modules. From the contextual menu, click Add a new software. The Software wizard is displayed. Select A Windows Vista / 2008 / 7 software module, and click Next. Select A custom action on the target computer, and click Next.
5. Select A WinPE 2.0 Ramdisk image for Vista/2008/7, and click Next. 6. Specify the IP address of the computer on which you installed WAIK and the web interface extension. 7. Specify the location of the Windows Vista/2008/7 installation files (CD-ROM/DVD), and click Next. 8. Click Finish.
419
What to do next
The WinPE2 ramdisk software module is created. Now, you can bind it to the corresponding Windows Vista/2008/7 golden master or virtual images. Note: For Tivoli Provisioning Manager for Images virtual images, you do not need to create binding rules to bind the WinPE2 ramdisk software module to the Windows Vista/2008/7 virtual images. As long as you have the WinPE2 ramdisk image, Tivoli Provisioning Manager for Images can automatically find it and bind it for you.
Managing multiple WinPE 3.0 deployment engines

Create and manage multiple WinPE3 deployment engines for deploying Windows images.
Before you begin

This feature is only available if you upgrade to Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images, version 7.1.1.4 or higher. To upgrade, see the document called Upgrading Tivoli Provisioning Manager for OS Deployment to a later version on page 352. Important: After you upgrade to version 7.1.1.4 or higher, you must restart the provisioning server and WebSphere Application Server to refresh the provisioning web interface. Use the tio command to restart both of the servers. Starting in version 7.1.1.4, Provisioning Manager for OS Deployment and Provisioning Manager for Images provide support for having several WinPE 3.0 deployment engines on any OS deployment server. You can manage the WinPE 3.0 deployment engines in these products without leaving the provisioning web interface. To access the deployment engines using Tivoli Provisioning Manager, follow these steps:
Procedure
1. Log into the provisioning web interface. 2. Click Go To > Deployment > OS Management > OS Deployment Engines. Binding drivers: Before you begin Your WinPE deployment engine contains built-in drivers. Use them first. If you encounter problems with the built-in drivers, if some drivers are not bound, or if some drivers are missing, bind other drivers to your WinPE deployment engine. In this offline driver injection process, you can only bind drivers, to your WinPE deployment engine, that are driversoftware modules in your OS deployment server. You must therefore create driver software modules from the drivers that you want to bind to your WinPE deployment engine. The product helps you select appropriate drivers for particular target models. It helps you to predict potential problems and to solve them. It does not guarantee that a specific WinPE deployment engine, with bound drivers, works with a given target. The information used by the OS deployment server to predict the compatibility of a driver with a target model is taken from the content provided by the vendor in its driver. The OS deployment server cannot verify the accuracy of this information.
420
Procedure 1. Check the compatibility of your WinPE deployment engine. To view the details of the deployment engine, you have two options: v Double-click a deployment engine. v Select a deployment engine, and then select View engine details in the contextual menu. 2. Go to the section Network and mass storage drivers. A check is performed while the page is loading. This can take a few minutes. If drivers are missing, or are not bound, or if several drivers are bound for the same device, the following information is provided. Indicates a missing critical driver, or a critical driver of the wrong architecture. Indicates that a missing non-critical driver, or a non-critical driver of the wrong architecture. Indicates that a required driver is present on the OS deployment server, but that it is not bound. Indicates that there are several drivers bound for the same device, or that there is a binding with a driver that is not known as compatible. You can expand the line to get more information. v For drivers missing on the OS deployment server, you find a suggestion of where to look for it, including, if available, a download link and the exact directory within the downloaded archive where the driver can be found. v When drivers are present on the OS deployment server, you find suggestions of which driver to bind, in order of preference. If multiple drivers are known to possibly work for a device, the best choice is listed first. The choice is explained in the advice text, which first recommends the use of device-specific drivers, that is, drivers that have been specifically designed for the given hardware device. Then compatible device drivers, that match the device family, are recommended, even if they are not an exact rebranded variant (for example, as second choice, an Adaptec driver of the same family as an IBM ServerRaid adapter, if it is based on the same chipset). Finally, as third choice, generic drivers, for example, Microsoft generic AHCI driver for any AHCI controller, are recommended. If no error is found, you do not need to modify the bindings. 3. Modify the driver bindings of the WinPE deployment engine. Click Edit engine's driver bindings. There are two ways to perform this. v Use a wizard. a. Click Fix Drivers. b. Follow the instructions in the wizard. After having selected a target model, you must select one of these options: Automatically fix issues that can be fixed for this model. Fixes all issues that can be automatically fixed. Such issues include, for example, a missing binding to an existing driver, multiple bindings for a device, or removing a driver tagged for another operating system. Manually fix issues for this model. Presents you with each issue in turn. Ways to solve the issue, when available, are proposed. Automatically bind drivers for this model. Erases every existing binding. New bindings are then automatically added. Copy driver bindings for this model from a similar engine. Copies all the bindings from a selected source engine to the current engine. Reset all drivers bindings for this model. Erases all the driver bindings, and does not create any new binding. v Edit the bindings manually, using the driver binding grid.
421
Columns represent target models known to the OS deployment server and matching the patterns provided for the WinPE deployment engine. They can be expanded to view their network and mass storage devices, if a PCI inventory has been performed. The first line represents the WinPE deployment engine. Other lines represent software module folders in the OS deployment server. They can be expanded to view individual drivers. If a driver can be used only for 32-bit or 64-bit machines, a superscript x86 or x86-64 mark is written next to the driver name. If you do not find the drivers that you need in the list provided, create software modules for your drivers. a. (Optional) To obtain a summary of the errors and warnings, click the link provided above the grid. This helps you locate the problematic areas in the driver grid. b. Expand the columns of problematic target models to view the individual network and mass storage devices. c. Expand software module folders containing drivers to view the individual drivers.
A cell with a green background indicates that driver information corresponds to the device. The quality of the drivers that can be selected is illustrated by the intensity of the green background: the best drivers are in intense green, the family drivers are in standard green, and the generic drivers are in pale green. A cell with an orange background indicates either that the driver is not a PCI driver, or that there is no compatibility information available for the driver. indicates that the driver is bound to the WinPE deployment A cell with a green check mark engine for use with the specific target model and device. d. Click a green or orange background cell to add or remove bindings. It is not possible to bind or unbind drivers from the WinPE deployment engine itself, because they are built-in drivers. You should have one, and only one, check mark per column, indicating that you have one and only one driver for each device. e. When you have finished modifying the bindings, click Save.
422
f. To return to the Image details page, click Back. Potential problems with the image are recomputed, allowing you to check if your modifications have solved the detected problems. Results Existing WinPE deployment engines will be displayed. You can view engine details, create new deployment engines, and manage all engines in this application.
Prerequisites for VMware targets

To be able to successfully deploy images on VMware, it is important to follow a number of prerequisites when setting up the VMware target. Guest operating system Always set the guest operating system that you intend to deploy, otherwise the deployment might fail. Network adapter v The Intel e1000 network adapter works properly on all Windows editions. v On Windows 64-bit, the AMD Lance network adapter is not supported. Using it results in a failed deployment with either a shutdown of the virtual machine or a blue screen. v The AMD Lance network adapter is supported for all Linux distributions, but it is very slow. v The Intel e1000 network adapter is supported on all Linux distributions, apart from Red Hat Enterprise Linux 5 (REHL5). With REHL5, the Intel e1000 card is in a dirty state when rebooting the operating system after performing Linprep. The target cannot connect to the network anymore. Therefore, the deployment stops and fails. To workaround this issue, install two network cards on your VMware target: The Intel e1000 as the primary boot device. An AMD Lance as the second boot device to use as a fallback. With the two cards, when Linux reboots and the Intel e1000 does not answer, the AMD Lance takes over, letting the virtual machine boot and the deployment continue. SCSI controller v For Windows XP, Windows XP SP1, Windows 2003, and Windows 2003 SP1, only BusLogic is supported. v On all other operating systems, LSI Logic is supported.
DHCP server requirements and configuration

Ensure that your DHCP server is correctly configured for operating system and virtual image management.
Requirements
There are no special product requirements for the DHCP server. If the DHCP server and the OS deployment server are running on the same target, the DHCP server must support the definition of the Class identifier DHCP option (option 60). Tivoli Provisioning Manager for OS Deployment can work with almost any RFC-compliant DHCP server, including Windows 2003 DHCP server, Windows 2000 DHCP server, ISC DHCP server, Solaris DHCP server, and the Netware 5 DHCP server. Note:
423
1. Because of the nature of PXE, you cannot run two PXE servers on the same computer. If you have installed another PXE boot tool such as Microsoft ADS, you must disable it before installing Tivoli Provisioning Manager for OS Deployment. 2. Microsoft DHCP server does not work well with some PowerPC firmware. If you have PowerPC targets in your environment, use an IBM recommended DHCP server.
Configuration
The DHCP server is used by the PXE bootrom to get its IP address and other basic networking information (including subnet mask, and default gateway). Using Tivoli Provisioning Manager for OS Deployment can require changes to your DHCP configuration. Typically, these changes can be performed automatically during the Tivoli Provisioning Manager for OS Deployment installation. However, in some cases, you might want to verify the changes, or perform them manually. You can configure your DHCP server for one of the following situations: v The DHCP server and the OS deployment server are not running on the same host. v The DHCP server and the OS deployment server are running on the same host. v You already have a PXE 2.0 infrastructure with PXE Boot Server discovery installed, and you want to add Tivoli Provisioning Manager for OS Deployment to the list of servers to discover. Note: v If you have previously configured your DHCP server for another PXE bootstrap, do not reuse your existing DHCP configuration. Remove DHCP options 43 and 60 for the hosts on which you want to run Tivoli Provisioning Manager for OS Deployment, and follow configuration instructions in this section. If you are running Tivoli Provisioning Manager for OS Deployment on the same computer as the DHCP server, you need to set option 60 again. v There are also cases where you must set both DHCP options 43 and 60, for example, when you have two different OS deployment servers.
Configuring the DHCP server

You can configure your DHCP server in several different ways. The following options are available: v The DHCP server and the OS deployment server are not running on the same host. v The DHCP server and the OS deployment server are running on the same host. v You already have a PXE 2.0 infrastructure with PXE Boot Server discovery installed and you want to add Tivoli Provisioning Manager for OS Deployment to the list of servers to discover.
Note: v If you have previously configured your DHCP server for another PXE bootstrap, do not reuse your existing DHCP configuration. Remove DHCP options 43 and 60 for the hosts on which you want to run Tivoli Provisioning Manager for OS Deployment, and follow the instructions given in this section. If you are running Tivoli Provisioning Manager for OS Deployment on the same host as the DHCP server, you need to set option 60 again. v There are also cases where you must set both DHCP options 43 and 60, for example, when you have two different OS deployment servers. Review the following information, select the case that suits your needs, and then perform the configuration steps. DHCP server and OS deployment server on different targets, with no information about the PXE server location Perform the following: v If DHCP options 43 and 60 are set, remove them.
424
v If the DHCP server is not running on the same target as the OS deployment server, the DHCP configuration does not change. The OS deployment server detects DHCP packets sent over the network by PXE bootroms, and offers PXE parameters without disturbing the standard DHCP negotiation process. This behavior is called DHCPProxy. DHCP server and OS deployment server on different targets, with information about the PXE server location Perform the following: v Set option 60 (Class identifier) to "PXEClient" to inform the target that the location of the PXE server is known. v Set option 43 to indicate that the PXE server does not reside on the same computer as the DHCP server, and to specify the location of the PXE server. DHCP server and OS deployment server on the same target Perform the following: v If DHCP option 43 is set, remove it. v Set option 60 (Class identifier) to "PXEClient" to inform the target that the location of the PXE server is known. If you plan to run the DHCP server and the OS deployment server on the same target, you must instruct your DHCP server to send DHCP option 60 (Class identifier) to the targets. When option 60 is set to PXEClient, the DHCP server knows the location of the PXE server. If option 43 is not set, the PXE server has the same IP address as the DHCP server.

Adding DHCP option 60 to Windows 2003 DHCP server: By default, option 60 is not set on Windows 2003. If the OS deployment server runs on the same host as the DHCP server, you must add this option and set its value to PXEClient in order to tell PXE clients where to find the OS deployment server. Procedure 1. Open a command window. 2. Enter netsh. 3. Enter dhcp. 4. Enter server \\hostname or server ip_address. A command prompt that says: dhcp server> is displayed. 5. Enter add optiondef 60 PXEClient STRING 0 comment=option added for PXE support. 6. Enter set optionvalue 60 STRING PXEClient. 7. To confirm that everything has been set correctly, enter show optionvalue all. Adding DHCP option 60 to a host with ISC DHCP server: If you use the ISC DHCP server 2.0, you can add the DHCP option 60 to a group of targets or to a single target by adding the statement option dhcp-class-identifier PXEClient ; to a section of the configuration file. If you use option 43 (vendor-encapsulated-options) for another PXE application, remove it for the Tivoli Provisioning Manager for OS Deployment targets. The changes to be made on a ISC DHCP server 3.0 are similar to those for a 2.0 server, but use different names: v Add vendor-class-identifier "PXEClient"; for the targets running Tivoli Provisioning Manager for OS Deployment.
425
v Remove any occurrences of option space PXE; if you were running another PXE application. Note: v The OS deployment server responds to all requests, including requests originating from unknown targets. v If the flag Completely ignore unknown targets is set for the server, it only responds to discovery requests originating from known targets. You can specify either the IP address or the Ethernet address in the target list. At this stage, the IP address of the remote-boot target is known.

Option 43 is a binary buffer that contains a list of suboptions, which are packed in the binary buffer in no specific order. Most suboptions are optional. An exhaustive list of suboptions can be found in the PXE specifications. Described below are only the suboptions that require the specification of the PXE server IP address. PXE option 6: PXE_DISCOVERY_CONTROL This option specifies how the PXE client contacts PXE servers, using either unicast, multicast, or broadcast. The format of this option is one byte. PXE option 8: PXE_BOOT_SERVERS A list of IP addresses, each address corresponding to one PXE server (when discovery_control is unicast). A PXE server is identified by a number (the standard value for Tivoli Provisioning Manager for OS Deployment is 15) and its IP address. The format of this option is two bytes for the server type (15 for Tivoli Provisioning Manager for OS Deployment), one byte for the number of servers to list (1 in our example), and four bytes per server address. PXE option 9: PXE_BOOT_MENU This option contains a list of choices to prompt on the screen at boot time. You need to have a PXE boot menu even if it is not used. The format of this option is two bytes for the server type, one byte for the length of the string to display, and the string to display on screen. The total length of this option is 5 bytes. PXE option 10 (0A): PXE_BOOT_TIMEOUT This option is required to specify how long (in seconds) the boot menu is displayed, and the text of a prompt that is displayed during waiting time. The format of this option is one byte for the timeout value, followed by the prompt text. PXE option 255 (FF): PXE_END To be valid, the binary buffer of DHCP option 43 must end in FF. Setting DHCP option 43: If your DHCP server runs on Windows NT, you can enter the suboption values one at a time in option 43, by selecting the hexadecimal input. If your DHCP server is ISC DHCP (version 2.x), you can enter the suboption values as provided in the examples (bytes separated with colons) for parameter vendor-encapsulated-options (the exact name depends on the version you are using). If your DHCP server is ISC DHCP (version 3.x), you can use an explicit syntax to describe the PXE options, as follows:
# In the global section: option space PXE; option PXE.discovery-control code 6 = unsigned integer 8; option PXE.boot-server code 8 = { unsigned integer 16, unsigned integer 8, ip-address };
426
option PXE.boot-menu code 9 = { unsigned integer 16, unsigned integer 8, text}; option PXE.menu-prompt code 10 = { unsigned integer 8, text }; # In the scope/host section: option dhcp-parameter-request-list 60,43; option vendor-class-identifier "PXEClient"; vendor-option-space PXE; option PXE.discovery-control 7; option PXE.boot-menu 15 5 "Rembo"; option PXE.menu-prompt 0 "Rembo";
Example: option 43 for PXE servers on different subnets: In this example, you have targets A and B boot on server 192.10.10.10, and targets C and D boot on server 192.10.11.10, which is on a different subnet (a valid gateway must be set up for C and D in order to locate the PXE server on a different subnet). Note: Server type 15 is translated into 00:0F in hexadecimal. IP address 192.10.10.10 is translated into C0:0A:0A:0A, and 192.10.11.10 is translated into C0:0A:0B:0A. Letters R and B are translated into 52 and 42. The following are the options that must be inserted in the binary buffer and their values: PXE option 6, length 1, value=07 Value 07 means use PXE_BOOT_SERVERS list, disable multicast and broadcast discovery. PXE option 8, length 7, value = 00:0F:01:C0:0A:0A:0A (targets A and B) Only one IP address is used, the address of the PXE server for the target which receives these DHCP options. PXE option 8, length 7, value = 00:0F:01:C0:0A:0B:0A (targets C and D) Only one IP address is used, the address of the PXE server for the target which receives these DHCP options. PXE option 9, length 5, value = 00:0F:02:52:42 There is only one line, displaying RB, and which goes to server type 15 (Tivoli Provisioning Manager for OS Deployment). PXE option A, length 2, value=00:52 The timeout is set to 0 seconds, meaning that one wants to boot using the first line of the boot menu, and the prompt is set to R. Because the timeout is 0, the prompt text is not displayed, but it must be at least one character long. PXE option FF This closes the buffer. The format of the binary buffer is similar to what is used for the DHCP packet itself. The buffer is a list of options, each option starting with its option number (one byte), followed by its length (one byte), and its value (a list of bytes). Here is the transcription of the above example, for targets A and B:
Option 43 = 06:01:07:08:07:00:0F:01:C0:0A:0A:0A:09:05:00:0F:02:52:42:0A:02:00:52:FF
And for targets C and D:

Option 43 = 06:01:07:08:07:00:0F:01:C0:0A:0B:0A:09:05:00:0F:02:52:42:0A:02:00:52:FF
Example: option 43 to create a PXE boot menu:

427
The administrator wants to display two lines in the PXE boot menu, pointing to two separate OS deployment servers. The two servers must use different PXE server type numbers or they will be seen as one server only by the PXE network card. In addition to the standard PXE server type 15, OS deployment servers accept any number between 33008 (80F0 in hexadecimal) and 33280 (8200 in hexadecimal). These new PXE server type numbers are used to differentiate multiple OS deployment servers in the BOOT_SERVERS sub-option of DHCP option 43. In this example, the first server has the address 192.168.1.4 (C0:A8:01:04 in hexadecimal), and the second server 192.168.1.5 (C0:A8:01:05 in hexadecimal). Procedure 1. Assign an OS deployment server type to each of the servers. OS deployment servers accept server type 15, and server types from 33008 to 33280. For this example, 33008 (80F0) is used for the first server, and 33009 (80F1) for the second server. 2. The suboptions of DHCP option 43 must then be configured as follows: PXE option 6, length 1, value=07 Value 07 means use PXE_BOOT_SERVERS list, disable multicast and broadcast discovery PXE option 8, length 14 (0E), value = 80:F0:01:C0:A8:01:04:80:F1:01:C0:A8:01:05 Option 8 defines the two PXE servers. The first server is defined by the first 7 bytes, starting with the OS deployment server type (80:F0, 33008), followed by one IP address: C0:A8:01:04 (192.168.1.4). The second server is defined as follows, using OS deployment server type 80:F1 (33009). PXE option 9, length 22 (16), value = 80:F0:08:53:65:72:76:65:82:20:41:80:F1:08:53:65:72:76:65:82:20:42 Option 9 defines the boot menu that is displayed at boot time. The first 11 bytes correspond to the first line, for the first server. It shows the string Server A, associated with type 80:F0 (first server). The second line shows the string Server B, associated with type 80:F1 (second server). PXE option 9, length 5, value = 00:0F:02:52:42 (targets C and D) Only one IP address is used, the address of the PXE server for the target which receives these DHCP options. PXE option A, length 6, value =0F:53:65:6C:65:63:74 Option 10 (0A) specifies a 15 second timeout and shows the string Select as the boot menu prompt. PXE option FF This closes the buffer The full option 43 reads as follows:
06:01:07:08:0E:80:F0:01:C0:A8:01:04:80:F1:01:C0:A8:01:05: 09:16:80:F0:08:53:65:72:76:65:82:20:41:80:F1:08:53:65:72:76:65:82:20:42: 0A:06:0F:53:65:6C:65:63:74:FF
Installing the web interface extension

For Tivoli Provisioning Manager for Images to know about virtual images and virtual servers, the web interface extension (rbagent) must be installed and running on the hypervisor, otherwise Tivoli Provisioning Manager for Images will manage the virtual machines as physical machines. The web interface extension is installed automatically when Tivoli Provisioning Manager for OS Deployment is installed on a computer. However, if the computer that you intend to use as a source
428
computer for your virtual image does not have Tivoli Provisioning Manager for OS Deployment installed, you can also install the web interface extension manually on it. When the web interface extension is running on a target, it can be used by the OS deployment server to perform actions on and gather information from the target. When browsing the web interface from a computer which is not the OS deployment server, the web interface extension allows the computer on which the web interface is running to exchange information with the OS deployment server. In the absence of the web interface extension, several features of the web interface will also be disabled.
Installing and uninstalling the web interface extension

If the source computer does not have Tivoli Provisioning Manager for OS Deployment installed on it, you must install the web interface extension on it manually. The source computer is the computer that contains the OS media you want to create an image from. To manually install the web interface extension:
Procedure
1. On the source computer, find the files for the web interface extension, which are located in the OSD_DATADIR\global\http\agents directory, where OSD_DATADIR is the Tivoli Provisioning Manager for OS Deployment data directory you specified, for example: v
Windows
UNIX Linux /opt/tpmfosd_files v 2. Perform the following:
v v v v
Windows Run the rbagent.msi file. Follow the instructions in the wizard to install the web interface extension. AIX Linux Solaris
Run the rbagent.aix file. Run the rbagent.linux file. Run the rbagent.solaris file.
For all UNIX files, you must transform the downloaded file into an executable (for example, chmod +x rbagent.linux) and then run it. For example, ./rbagent.linux -s <IP>:<password> where IP is the IP address of the OS deployment server to which you want to connect, and password is the password that was specified at the Tivoli Provisioning Manager for OS Deployment installation.
Uninstalling the web interface extension

To uninstall the web interface extension: On Windows operating systems 1. Open the Control Panel. 2. Open Add or Remove Programs. 3. Select IBM Tivoli web interface extension. 4. Click Remove. 5. Follow the instructions of the installer. Note: The rbagent.conf file is not removed from the Program Files/Common Files/IBM Tivoli directory. This enables you to keep the same configuration in case of upgrade. If you want to remove the web interface extension completely, you must delete the rbagent.conf file manually. On UNIX operating systems Simply delete the executable file.
429
Virtual image tasks

You can use Tivoli Provisioning Manager for Images to perform the following tasks.
The Provisioning Configuration Librarian runs an image synchronization periodically, to update the Tivoli Provisioning Manager data model with the latest Tivoli Provisioning Manager for OS Deployment images (golden master, point-in-time snapshot, hardware configuration, unattended setup) or Tivoli Provisioning Manager for Images virtual images. The image synchronization discovers Tivoli Provisioning Manager for OS Deployment images or snapshots of Tivoli Provisioning Manager for Images virtual images and creates image objects for them in the Tivoli Provisioning Manager data model. Once discovered, these images can then be deployed to virtual or physical machines. To synchronize images:
Procedure
1. Click Go To > Deployment > OS Management > Images. 2. Click Select Action > Tivoli Provisioning Manager for OS Deployment > Synchronize images with the boot server. The Provisioning Task Tracking application displays the current status of the task. When the provisioning task has started, you can monitor its progress on this page. From the Select Action menu, click Refresh to update the page.
Results
All the images are now discovered in Tivoli Provisioning Manager, and image objects are added to the data model for them. Note: Before deployment, all imported or discovered virtual images must have SAP and credential information added, so that they can be used on the target computers. For more information, see Adding credentials to virtual images
Adding credentials to virtual images

Before deploying a discovered or imported virtual image to a target computer, you must define a Service Access Point (SAP) and password credentials for it, so that the virtual image can be used on the target computer after deployment. Note: This procedure is not required for captured virtual images. Captured virtual images already have SAP information which is replicated automatically to the target computer after the image is successfully installed on it. Matching credential keys are automatically added to the image object used in Tivoli Provisioning Manager. To add SAP and credential information to an already discovered or imported virtual image:
Procedure
1. 2. 3. 4. Click Go To > Deployment > OS Management > Images. Click the virtual image you want to work with, then click its Credentials tab. Click Add Credentials, then select SSH and SCP for a Linux image, or RXA for a Windows image. On the Add Credential Pair dialog, ensure that the Create Password Credential box is selected.
5. Enter the following password credential information: a. For Search Key, enter master.
430
b. Enter the login User Name and Password for the image. c. Confirm the password. 6. Click OK. 7. Assign the corresponding SSH_HOST or RXA_HOST to the Use feedback loop to check system status field. 8. Click Save.
Results
You have finished adding the required SAP and password credentials to the selected virtual image. You can now deploy the virtual image to the target computer.
Capturing virtual images

Tivoli Provisioning Manager for Images virtual images can be captured from virtual machines that are running on computers that Tivoli Provisioning Manager for Images manages through the web interface extension (rbagent) on the hypervisor, as well as virtual machines that are not managed through the hypervisor. It can even capture virtual images from real physical machines.
Before you begin

v If you capture the image of a Linux virtual machine, ensure that you injected the required disk and network drivers in the software module. Before capturing a 64-bit Red Hat Linux machine, perform the following steps: 1. Back up the existing initrd file located in the /boot directory. 2. Modify the /etc/modprobe.conf file, by adding the following lines (if additional scsi_hostadapter entries are already in the file, increment only the counter):
alias alias alias alias scsi_hostadapter1 mptbase scsi_hostadapter2 mptspi scsi_hostadapter3 ata_piix scsi_hostadapter<N> <module>
3. Enter the following command: mkinitrd /boot/initrd-<kernelversion>.img <kernelversion> v You cannot clone, capture an image, or perform direct image replication from a target with unformatted partitions or partitions formatted using an unsupported proprietary file system. Such partitions should be either deleted, or formatted using a supported file system before cloning, capturing, or replicating an image to another computer. Restriction: A captured image that has four primary partitions cannot be deployed. The fourth partition must be a logical partition. Also, you cannot deploy an image in which the OS partition follows the data partition. You can capture an image of a physical or virtual computer and store it on the Tivoli Provisioning Manager for Images server. For capturing an image online, a process is run on the source machine that selectively reads all the relevant data from the hard disks and saves it optimally to a virtual image, de-fragmenting all files. Note: Unlike the capture of Tivoli Provisioning Manager for OS Deployment golden master images, the capture of Tivoli Provisioning Manager for Images virtual images does not require sysprep for Windows targets. To capture a virtual image:
Procedure
1. Click Go To > Deployment > OS Management > Image Capture.
431
2. Select the source computer from which you want to capture the image. It can be either a physical or a virtual machine. Note: Ensure that the source computer: v Is powered on. v Can be managed by Tivoli Provisioning Manager (has credentials and can execute commands). Tivoli Provisioning Manager will restart the computer. The computer must be set to boot off first from the network, so it can PXE boot off the Tivoli Provisioning Manager for Images server. 3. Click TPMfOSd for the Boot Server Type. 4. Enter the image name and, optionally, an image description. 5. Select TPM for Images Virtual Image for the Image Type. Other image types available are: v Golden Master - standard profile v Point-in-Time Snapshot 6. Click Submit. Tivoli Provisioning Manager will log into the computer and will attempt to reboot it (if it is a known virtual machine, Tivoli Provisioning Manager will restart it). Then, the computer will boot off the Tivoli Provisioning Manager for Images server. For doing this, you must have the computer set to either boot first off the network and PXE boot off the Tivoli Provisioning Manager for Images server, or possibly boot off a network boot CD-ROM which will also boot it off the Tivoli Provisioning Manager for Images server.
Results
The image of the computer, hypervisor, or virtual machine that you selected has been captured. The capture process creates an OVF file and some disk files in the OS deployment server format. The creation of the virtual image might be slower than the standard profile creation.
What to do next
You can now see the details of the captured image. Click Go To > Deployment > OS Management > Images. Select the captured image and then click the Properties tab.
Deploying virtual images

You can deploy virtual images to target computers using Tivoli Provisioning Manager for Images.
Before you begin

v The BIOS startup sequence of the target computer must first have network and then hard disk for the installation task to complete successfully. v If you deploy the Tivoli Common Agent with a Linux golden master or unattended setup image, we recommend you have a minimum of 2 GB of swap space for the image. To specify this: Click Go To > Deployment > OS Management > Images. Select your image, then click the Properties tab, then the Disks tab. v (Optional) Ensure that the web interface extension (rbagent) is installed and running on the hypervisor. Without the rbagent on the hypervisor,Tivoli Provisioning Manager for Images will manage the virtual machine as a physical machine. The target computer can be a physical machine, a virtual machine, or a virtual machine that is on a hypervisor that Tivoli Provisioning Manager for Images already knows about. The image can be deployed even to a hypervisor technology that is different from the one used for the capture. For example if the machine was captured from a VMWare ESX virtual machine, it can be deployed to a KVM virtual machine.
432
To install the virtual image on the target computer:
Procedure
1. 2. 3. 4. 5. Click Go To > Deployment > OS Management > Image Deployment. Specify a name for the image deployment task or accept the default name. Select the virtual image that you want to install. Select the target computer to install the image on. Choose to schedule the task or run it immediately.
6. Click Submit. The Provisioning Task Tracking application displays the current status of the task. When the provisioning task has started, you can monitor its progress on this page. From the Select Action menu, click Refresh to update the page. a. To view the task progress in detail, click the task name to open the task details page. In the Deployment Request Details column, click Request ID to view the provisioning workflow execution log. b. If the target computer is already managed by Tivoli Provisioning Manager, Tivoli Provisioning Manager will attempt to reboot the machine so that the deployment activity can run. If Tivoli Provisioning Manager cannot restart the machine, then Tivoli Provisioning Manager will schedule the OS deployment activity, and you must boot the machine manually. When the machine boots off the network (and gets picked up by the Tivoli Provisioning Manager for OS Deployment server), it will then run the OS deployment activity.
Results
The virtual image has been installed on the specified target computer.
What to do next
2000 After you install a Windows 2000 image using Tivoli Provisioning Manager for OS Deployment, you must log on to the Windows 2000 computer locally, with Administrator credentials, for all disk partitions to be created correctly. If you log into the computer remotely for the first time after installing Windows 2000, some disk partitions might not appear in the Windows registry.
Microsoft Sysprep, with Windows 2000 setup, will not configure a static IP network configuration. When you log on to Windows 2000, a network script is executed to configure the network. On the Windows 2000 computer, navigate to Start > Settings > Network and Dial-up Connections. From the menu, select View and then click Refresh to view the network connections configuration changes.
2000
The software inventory on the target computer might not be up to date after installing a Tivoli Provisioning Manager for OS Deployment image. We recommend you perform the following discovery activities to update the software inventory on the target computer: 1. Install Tivoli Common Agent 2. Tivoli Provisioning Manager inventory discovery You can do this task by running the Computer Discovery, Common Agent Installation and Inventory Discovery out-of-the-box scenario: Discovering your environment using the ready-to-use network discoveries on page 231.
Replicating virtual images

With Tivoli Provisioning Manager for Images, you can replicate virtual images between parent and child OS deployment servers, or snapshots of virtual images between hypervisors and parent or child servers.
433
Before you begin

v Ensure that enough disk space is available for the replicated image on the OS deployment server. v Turn on the OS deployment server target before starting the replication. v (Optional) Ensure that the web interface extension (rbagent) is installed and running on the hypervisor. Without the rbagent on the hypervisor,Tivoli Provisioning Manager for Images will manage the virtual machine as a physical machine. For virtual image replication, all the images listed on the Images page (Go To > Deployment > OS Management > Images) are located on the OS deployment server or have been discovered in a hypervisor. For example, you might want to replicate a virtual image from the hypervisor to the Tivoli Provisioning Manager for Images servers, if you know that the image will be deployed often from these servers. Also, you can replicate images that are defined in the OS deployment server database to any OS deployment server. Restriction: A captured image that has four primary partitions cannot be deployed. The fourth partition must be a logical partition. Also, you cannot deploy an image in which the OS partition follows the data partition. To replicate a virtual image:
Procedure
1. Click Go To > Deployment > OS Management > Images. 2. Select the virtual image that you want to replicate. Tip: To verify the location of the image that you are about to replicate, click its Properties tab, and review the information in the Image locations section. 3. Click Select Action > Tivoli Provisioning Manager for OS Deployment > Replicate Virtual Image. The Image Replication Wizard is displayed. 4. Specify the IP address of the OS deployment server where you want to replicate the virtual image, then click OK. 5. Click Next to start the replication process. The replication wizard is launched. 6. When the image replication is complete, click Finish.
Results
The selected virtual image has been successfully replicated.
What to do next
You can now see the new location of the virtual image. Click Go To > Deployment > OS Management > Images. Select the image that you have just replicated, click the Properties tab, then go to Image locations.
Exporting virtual images

Using Tivoli Provisioning Manager for Images, you can export existing virtual images to an OVF file.
Before you begin

v Ensure that enough disk space is available on the machine to which you want to export the image. Note: To export a virtual image to OVF format on Windows systems, ensure that the image is less than:
434
2 GB, on a FAT16 filesystem 4 GB, on a FAT32 filesystem On an NTFS filesystem, the only image size limit is the available hard disk space. v (Optional) Ensure that the web interface extension (rbagent) is installed and running on the hypervisor. Without the rbagent on the hypervisor,Tivoli Provisioning Manager for Images will manage the virtual machine as a physical machine. If you want to export to a VMDK format, install the web interface extension in its 32-bit version, to be compatible with VDDK. To export a virtual image to the OVF format:
Procedure
1. Click Go To > Deployment > OS Management > Images. 2. Select the virtual image to export. 3. Click Select Action > Tivoli Provisioning Manager for OS Deployment > Export Virtual Image. The OVF Export Wizard is displayed. Click Next. 4. Select the target where you want to export the OVF image. You can select the local computer if it has the web interface extension installed, the OS deployment server, or any computer with the web interface extension installed. Click Next. 5. In the Folder box, specify the OVF file. Important: It is recommended that you use a unique directory for each OVF export, to make it easier to keep track of all of your files. If you select the OS deployment server, the default path is OSD_DATADIR\vimages, where OSD_DATADIR is the default directory for the Tivoli Provisioning Manager for OS Deployment data files: v v
Windows UNIX
Linux
/opt/tpmfosd_files
A virtual image in OVF format consists of a file with the .ovf extension, and a set of virtual disk image files. Click OK, then click Next. 6. Specify the format for the virtual disk image files, depending on the format supported by the tool used to reimport the image later. The available options are: v VHD format (Microsoft Hyper-V) v VMDK format (VMWare ESX) v Raw sparse format (not recommended) Note: If the selected virtual disk image format is VMDK, before exporting the image ensure that: v You installed the VDDK library on the machine where the VMDK file will be located. A reboot is required after the VDDK installation. v You defined the VDDK path in the library path of the machine root user. v You run the web interface extension application (rbagent.exe) in its 32-bit version to be compatible with VDDK 1.1, which is a 32-bit application. Before using the VMDK file on a VMWare ESX Server, you must run the following command on the hypervisor:
vmkfstools -i <source_bytpmfosd> <output_for_esx>
where: <source_bytpmfosd> Specifies the name of the VMDK file created by using Tivoli Provisioning Manager for Images.
435
<output_for_esx> Specifies the name of the destination VMDK file to run on the VMWare ESX Server. For example:
vmkfstools -i ./OVFSLES10_OM.vmdk ./SLES10_CONVERTED/OVFSLES10_OM_CONVERTED.vmdk
Using the generated <output_for_esx> file you can run the new virtual machine on the VMWare ESX Server. 7. Click Next to start the export process. The export wizard is launched. 8. When the image export is complete, click Finish.
Results
The virtual image has been successfully exported to the specified target in the OVF format.
What to do next
You can now use the new image on the targets. Note: If the virtual images are exported to OVF in a format different from the format of the source hypervisor, they might be unusable on the target hypervisor. This is due to the different hardware emulation. To avoid this problem, use the standard process of capturing and deploying images to virtual machines, as this process rebuilds the system according to different hardware.
Importing virtual images

Using Tivoli Provisioning Manager for Images you can import an existing virtual image into your image repository stored on the server. You must provide the virtual image in OVF format, along with all virtual disk images referenced by the OVF file.
Before you begin

v Ensure that enough disk space is available on the OS deployment server <TPMfOSD_DATA_DIR>\vimages directory, where the image is imported. v Ensure that the web interface extension (rbagent) is installed on the machine where the virtual image is located. The web interface extension is necessary to import files remotely from any computer. If you do not want to install the web interface extension, make your files available in the OS deployment server <TPMfOSD_DATA_DIR>\import directory, so that the OS deployment server can access them directly. v If the virtual disk images referenced by the OVF file have a VMDK format, before importing the image ensure that: You installed the VDDK library on the machine where the VMDK file is located. A reboot is required after VDDK installation. You defined the VDDK path in the library path of the machine root user. To import a virtual image from the OVF format:
Procedure
1. Click Go To > Deployment > OS Management > Images. 2. Click Select Action > Tivoli Provisioning Manager for OS Deployment > Import Virtual Image. The OVF Import Wizard is displayed. Click Next. 3. Select the computer where the OVF image is located. You can select the local computer if it has the web interface extension installed, the OS deployment server (in the OSD_DATADIR\import directory), or any computer with the web interface extension installed. Click Next. 4. In the OVF File box, specify the OVF file, then click Next. The import wizard is launched.
436
5. When the image import is complete, click Finish. Tivoli Provisioning Manager will then run a discovery to discover the imported image.
Results
The virtual image has been imported in the OVF format from the specified computer.
What to do next
You can now deploy the imported image to targets. Note: Before deployment, all imported or discovered virtual images must have SAP and credential information added, so that they can be used on the target computers. For more information, see Adding credentials to virtual images on page 430
Tutorial: Managing virtual images

The virtualization features provided with Tivoli Provisioning Manager for Images help you to manage the virtualization infrastructure and to accelerate provisioning by deploying virtual images that have been built and are already available to target computers, whenever needed. This tutorial provides an introduction to virtual image management and focusses on Tivoli Provisioning Manager for Images integration with Tivoli Provisioning Manager. A quick and reliable deployment of virtual images to physical or virtual systems provides: v Efficient management of image distribution, discovery, capture, replication, storage, and deployment v Hardware-independent snapshots of server and virtual images, which improve agility and flexibility of server provisioning and recovery v Minimum storage for thousands of images This tutorial uses Windows computers to describe virtual image management but the same overall process applies to deployment on Linux on Intel computers.
Learning objectives
The learning objectives for the tutorial are: v Learn how to set up the environment for virtual image management. v Learn how to create and manage virtual images. v Learn how to create software modules and binding them to images. v Learn how to install virtual images on virtual or physical machines.
Considerations
The Tivoli Provisioning Manager for OS Deployment Intel boot server sends PXE responses when there is DHCP traffic between the client computer and the DHCP server. A computer restarted for the first time since the Tivoli Provisioning Manager for OS Deployment boot server is installed is registered to Tivoli Provisioning Manager for OS Deployment with PXE boot option to start on hard-disk if idle. This option is set so that when a computer starts the Tivoli Provisioning Manager for OS Deployment boot server, if there are no pending activities, it starts from the hard disk drive.
437
An isolated network is recommended for testing the Tivoli Provisioning Manager for OS Deployment boot server. An isolated network means that only the computers you are using for this test receives PXE responses from the Tivoli Provisioning Manager for OS Deployment. Consider the following before installing the Tivoli Provisioning Manager for OS Deployment boot server in your production network: v Are there other Intel boot servers deployed on the network? Is it necessary to check with the IT support group first? Both the Tivoli Provisioning Manager for OS Deployment and the other Intel boot server send PXE responses and might cause a conflict if the other Intel boot server has an imaging operation and the Tivoli Provisioning Manager for OS Deployment PXE response is received first to start from hard-disk. v Are there production or important Intel servers on the network that you do not want to interfere with the start by making sure that you have the correct Tivoli Provisioning Manager for OS Deployment configuration?
Prerequisites
Before you start, you need the following: v The Tivoli Provisioning Manager for OS Deployment version provided with Tivoli Provisioning Manager version 7.2 already installed. v The license for Tivoli Provisioning Manager for Images purchased. v A DHCP server and a DNS server. For details about these requirements, see the Tivoli Provisioning Manager Installation Guide. The DHCP server is configured to reserve an IP address for the MAC address of the computers for capture and install image. Also, the Tivoli Provisioning Manager for OS Deployment computer, DHCP server, and Tivoli Provisioning Manager for OS Deployment server requires a static IP address assigned to them. The network interface of the Tivoli Provisioning Manager computer does not have the attribute Dynamic IP address set and the IP address matches the DHCP reserved IP address. v Available ports. By default, the Tivoli Provisioning Manager for OS Deployment boot server uses the following ports for communication: DHCP: port 67 UDP PXE BINL: port 4011 UDP TFTP: port 69 UDP MTFTP: port 4015 UDP NBP: port 4012 UDP FILE: port 4013 UDP and TCP MCAST: port 10000-10500 UDP Address: 239.2.0.1 - 239.2.1.1 On the clients, the default ports are the following: DHCP: port 68 UDP MTFTP: port 8500-8510 UDP Address: 232.1.0.1 MCAST: port 9999 UDP Remote control (Web Interface Extension): port 4014 UDP These ports can all be modified, with one notable exception which is port 69 for TFTP. Port 69 is part of the PXE specifications, independently of the Tivoli Provisioning Manager for OS Deployment product and thus cannot be modified. Any product using PXE boot needs to have this port open to permit PXE boot. Note that this port needs to be open only on the Tivoli Provisioning Manager for OS Deployment boot server, not on the client machines.
438
Part 1: Setting up for virtual image management

To set up for virtual image management, you must first obtain the required build packages and upgrade to Tivoli Provisioning Manager for Images. Then you might want to install the web interface extension on the hypervisor, to make it work with Tivoli Provisioning Manager. In the absence of the rbagent, Tivoli Provisioning Manager for Images will manage the virtual machines as physical machines. Before installing the web interface extension, it is recommended that you run first a host platform discovery, to discover the host platforms and all the virtual machines. The host platform discovery scan also provides additional information about the virtual machines, which makes them manageable through the hypervisor technology. The installation of the web interface extension on the hypervisor then triggers an automated hardware discovery that discovers all the new virtual machines known to Tivoli Provisioning Manager for Images in Tivoli Provisioning Manager, and creates data model objects for them.
Learning objectives
In this part, you will learn to: v Obtain the required build packages and upgrade to Tivoli Provisioning Manager for Images. v Discover the host platform and virtual machines, using a host platform discovery configuration. v Install the web interface extension on the hypervisor. v Discover the virtual machines in Tivoli Provisioning Manager.
Upgrading to Tivoli Provisioning Manager for Images

Upgrading Tivoli Provisioning Manager for OS Deployment to Tivoli Provisioning Manager for Images offers you access to a set of additional virtualization features that are not available in Tivoli Provisioning Manager for OS Deployment. Obtaining the build packages: If you have Tivoli Provisioning Manager installed, review the following upgrade scenarios, and obtain the build packages required for the upgrade: v If you have Tivoli Provisioning Manager version 7.2 installed and would like to use the additional functionality provided by Tivoli Provisioning Manager for Images, you must purchase a license for Tivoli Provisioning Manager for Images, and then upgrade your Tivoli Provisioning Manager for OS Deployment to Tivoli Provisioning Manager for Images. v If you have an earlier version of Tivoli Provisioning Manager (for example, 7.1.1), you must first upgrade to Tivoli Provisioning Manager 7.2, which will also upgrade your Tivoli Provisioning Manager for OS Deployment to the latest version deployed with Tivoli Provisioning Manager 7.2. Build packages and fixes for Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images are published on IBM Fix Central. The packages can be found by accessing the Fix Central section of the Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images Support Web site, at http://www.ibm.com/support/fixcentral. The license for Tivoli Provisioning Manager for Images provides you with an entitled IBM ID, which is required for the downloads. If you do not have an entitled IBM ID, you will see the fixes, but you will not be able to download them. To obtain the required build packages: 1. Select Tivoli for the Product Group. 2. Select the Tivoli Provisioning Manager for OS Deployment or the Tivoli Provisioning Manager for Images product.
439
3. For the Installed Version, select the build number that matches the number of the Tivoli Provisioning Manager for OS Deployment build that was shipped with Tivoli Provisioning Manager 7.2. 4. Select the platform, and then click Browse to find the required packages and fixes. 5. Click Continue. Upgrading to Tivoli Provisioning Manager for Images: Ensure that all requirements for your operating system are met. To upgrade to Tivoli Provisioning Manager for Images: 1. Obtain the new Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images full build for the platforms used in your environment. If you are unsure, download all platforms. See Obtaining Tivoli Provisioning Manager for Images on page 396. 2. Extract all .exe files (self-extracting Windows 32-bit and 64-bit installables) to obtain the required .msi files. If you want, you can delete the .exe files. 3. Place all the Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables (tar.gz and .msi files) into the $TIO_HOME/repository/tpmfosd folder (for Windows, %TIO_HOME%\repository\tpmfosd). Note: Ensure that permissions for the files placed in the repository are set so that they are owned by tioadmin. 4. Discover the new Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables: a. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. b. In the Discovery Configuration list, click TPMfOSD Version Discovery, and then click Run. This will discover the Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables that you have placed in the repository, and will also create Tivoli Provisioning Manager software products that represent the new versions of Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images. 5. Stop Tivoli Provisioning Manager for OS Deployment on all of your servers, except the one running on the local Tivoli Provisioning Manager server. 6. Perform the following: a.
Windows In Tivoli Provisioning Manager, run a software product upgrade for Tivoli Provisioning Manager for OS Deployment on the local server: 1) Click Go To > Deployment > Software Management > Software Product Upgrade. 2) On the Software Product Upgrade page, select Tivoli Provisioning Manager for OS Deployment as the software to upgrade.
440
Discovering the hypervisor and virtual servers

Before installing the web interface extension, you can run a host platform discovery to discover the hypervisor and all the virtual machines. The host platform discovery scan provides additional information about the virtual machines that makes them manageable through the hypervisor technology. The host platform discovery scan discovers the hypervisor (VMWare or KVM) and creates a host platform for it in Tivoli Provisioning Manager. The discovery then runs an inventory discovery and a virtual hosts discovery on the hypervisor. To run the host platform discovery scan: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. On the Discovery Configurations page, select the host platform discovery configuration for the scan. For example, VMWare Virtual Center Discovery for VMWare. (For KVM, Libvirt Virtual HostPlatform Discovery). 3. Click Run Discovery. The Run Discovery wizard is displayed. 4. Select the target computers for the host platform discovery scan, and then click OK. 5. (Optional) Click Schedule to specify scheduling options for the discovery scan, if you do not intend to run it immediately. 6. Click Submit. The Provisioning Task Tracking application displays the current status of the task. When the provisioning task has started, you can monitor its progress on this page. From the Select Action menu, click Refresh to update the page. The host platform and its virtual machines are now discovered and displayed on the Virtualization Management page (Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management.).
Installing the web interface extension on the hypervisor

For Tivoli Provisioning Manager for Images to know about virtual images and virtual servers, the web interface extension (rbagent) must be installed and running on the hypervisor.
441
Note: In the absence of the rbagent on the hypervisor, Tivoli Provisioning Manager for Images will manage virtual machines as physical machines. To install the web interface extension on your hypervisor: Note: For the purpose of this tutorial, the VMWare ESX 4.0 hypervisor technology is used as an example. For details about a different hypervisor technology, see Hypervisor requirements on page 407. 1. Ensure that VMWare ESX 4.0 is installed by running cat /etc/vmware-release. 2. Disable the active firewall, by running, for example, the following command: etc/init.d/firewall stop. 3. Download the FUSE 2.7.4-1 library from SourceForge.net and compile it on the VMWare ESX hypervisor or download an already compiled libfuse.so.2 rpm package such as libfuse-2.7.41.el5.pp.i386.rpm from http://rpm.pbone.net/index.php3/stat/4/idpl/9551006/com/libfuse2.7.4-1.el5.pp.i386.rpm.html. Install FUSE on the hypervisor, for example, by entering the following command:
rpm -ivh libfuse-2.7.4-1.el5.pp.i386.rpm
4. Download VDDK version 1.1.1 (VMware-vix-disklib.*.tar.gz 32bit version) from VMWare Cloud Computing with Virtualization and install it on a VMWare ESX hypervisor. Extract the contents: tar -zxvf VMware-vix-disklib.*.tar.gz and run ./vmware-install.pl to install VDDK 1.1.1. A warning message about a missing libfuse.so.2 library might be displayed even if the library is installed. Proceed with the next configuration steps. 5. After the VDDK installation, reboot the hypervisor. 6. Do not install libxml2 because a supported version is already installed in VMWare ESX 4.0. Check that libxml2-2.6.26 is already present. 7. Define the VDDK path in the library path of the user running the rbagent by adding the following line to the /root/.bashrc file and reload it:
export LD_LIBRARY_PATH=:/usr/lib/vmware-vix-disklib/lib32
8. Ensure that the VMWare ESX hypervisor supports the following command:
vmware-cmd -l
9. Create vmware.conf in the same directory where the web interface extension is installed and ensure that it has the following content:
10. Ensure that the web interface extension is running on the VMWare ESX hypervisor with the rad-refreshhypervisor option. To do this on Linux, copy rbagent.linux from the <OSD_DATADIR>\global\http\agents directory of the OS deployment server to the VMWare ESX hypervisor, set the execution permission: chmod +x rbagent.linux, and run the web interface extension with the following syntax:
11. Ensure that only one instance of web interface extension is running. Note: Tivoli Provisioning Manager for Images does not support the capture or deployment when the file systems are ReiserFs, LVM. The web interface extension is now installed on your hypervisor.
Discovering the virtual servers in Tivoli Provisioning Manager

The web interface extension installed on the hypervisor triggers an automated Tivoli Provisioning Manager hardware discovery, which discovers the new virtual servers that are known to Tivoli Provisioning Manager for Images.
442
The Tivoli Provisioning Manager TPMfOSD_Hardware_Discovery discovers information about the new virtual servers and creates new data model objects for these computers. You can now run an image synchronization, to ensure that all the snapshot images in Tivoli Provisioning Manager for Images are discovered and added to the Tivoli Provisioning Manager data model.
Part 2: Creating and managing virtual images

You can create virtual images by capturing them from virtual or physical machines using Tivoli Provisioning Manager for Images, by importing them from an OVF format or, if there are Tivoli Provisioning Manager for Images images that Tivoli Provisioning Manager does not know about, by running an image synchronization, which discovers image snapshots and adds them to the Tivoli Provisioning Manager data model. Once the virtual images are managed by Tivoli Provisioning Manager, you can configure their properties, replicate them, or perform other tasks with them.
Learning objectives
In this part, you will learn to: v Run an image synchronization, to make any Tivoli Provisioning Manager for Images images known to Tivoli Provisioning Manager. This requires the web interface extension be installed and running on the hypervisor. v Capture a virtual image. v Import a virtual image. v Replicate a virtual image. v Export a virtual image.
You run an image synchronization to update the Tivoli Provisioning Manager image library with the latest Tivoli Provisioning Manager for Images virtual images. The image synchronization discovers snapshot virtual images that are known to Tivoli Provisioning Manager for Images and creates image objects in the Tivoli Provisioning Manager data model for them. To synchronize images: 1. Click Go To > Deployment > OS Management > Images. 2. Click Select Action > Tivoli Provisioning Manager for OS Deployment > Synchronize images with the boot server. The Provisioning Task Tracking application displays the current status of the task. When the provisioning task has started, you can monitor its progress on this page. From the Select Action menu, click Refresh to update the page. After the new images are discovered, they can be deployed to other virtual machines or physical machines. Note: Before deployment, all imported or discovered virtual images must have SAP and credential information added, so that they can be used on the target computers. For more information, see Adding credentials to virtual images on page 430
Capturing a virtual image

Tivoli Provisioning Manager for Images virtual images can be captured from virtual machines that are running on computers that Tivoli Provisioning Manager for Images manages through the web interface extension (rbagent) on the hypervisor, as well as virtual machines that are not managed through the hypervisor. It can even capture virtual images from real physical machines.
443
Note: v Unlike the capture of Tivoli Provisioning Manager for OS Deployment golden master images, the capture of Tivoli Provisioning Manager for Images virtual images does not require sysprep for Windows targets. v To prevent errors during the common agent installation on the target machine, ensure that the common agent is not installed and the Tivoli GUID is removed from the computer that you are capturing the image from. For details, see Uninstalling the common agent on page 669. To capture a virtual image: 1. Click Go To > Deployment > OS Management > Image Capture. 2. Select the source machine from which you want to capture the image. It can be either a physical or a virtual machine. Note: Ensure that the source machine: v Can be managed by Tivoli Provisioning Manager (has credentials and can execute commands). Tivoli Provisioning Manager will restart the computer. The computer must be set to boot off first from the network, so it can PXE boot off the Tivoli Provisioning Manager for Images server. 3. Click TPMfOSd for the Boot Server Type. 4. Enter the image name and, optionally, an image description. 5. Select TPM for Images Virtual Image for the Image Type. 6. Click Submit. Tivoli Provisioning Manager will log into the computer and will attempt to reboot it (if it is a known virtual machine, Tivoli Provisioning Manager will restart it). Then, the computer will boot off the Tivoli Provisioning Manager for Images server. For doing this, you must have the computer set to either boot first off the network and PXE boot off the Tivoli Provisioning Manager for Images server, or possibly boot off a network boot CD-ROM which will also boot off the Tivoli Provisioning Manager for Images server. You have finished capturing the virtual image. In Tivoli Provisioning Manager, you can configure the image properties, replicate it, or perform other tasks with it.
Importing a virtual image

You can import a virtual image from an OVF format using Tivoli Provisioning Manager for Images. You must provide the virtual image in OVF format, along with all virtual disk images referenced by the OVF file. v Ensure that the web interface extension (rbagent) is installed on the machine where the virtual image is located. The web interface extension is necessary to import files remotely from any computer. If you do not want to install the web interface extension, make your files available in the OS deployment server <TPMfOSD_DATA_DIR>\import directory, so that the OS deployment server can access them directly. v Ensure that enough disk space is available on the OS deployment server <TPMfOSD_DATA_DIR>\vimages directory, where the image is imported. v If the virtual disk images referenced by the OVF file have a VMDK format, before importing the image ensure that: You installed the VDDK library on the machine where the VMDK file is located. A reboot is required after VDDK installation. You defined the VDDK path in the library path of the machine root user. To import the virtual image from the OVF format: 1. Click Go To > Deployment > OS Management > Images. 2. Click Select Action > Tivoli Provisioning Manager for OS Deployment > Import Virtual Image. The OVF Import Wizard is displayed. Click Next.
444
3. Select the computer where the OVF image is located. You can select the local computer if it has the web interface extension installed, the OS deployment server (in the OSD_DATADIR\import directory), or any computer with the web interface extension installed. Click Next. 4. In the OVF File box, specify the OVF file, then click Next. The import wizard is launched. 5. When the image import is complete, click Finish. Tivoli Provisioning Manager will then run a discovery to discover the imported image. The virtual image is now successfully imported in OVF format. Note: Before deployment, all imported or discovered virtual images must have SAP and credential information added, so that they can be used on the target computers. For more information, see Adding credentials to virtual images on page 430
Replicating a virtual image

You can replicate a virtual image between a parent OS deployment server and a child OS deployment server, or a snapshot of the virtual image between the hypervisor and the parent or child OS deployment server. The replication requires that the web interface extension be installed and running on the hypervisor. You must also ensure that enough disk space is available for the replicated image on the OS deployment server. Turn on the OS deployment server target before starting the replication. All the images listed on the Images page (Go To > Deployment > OS Management > Images) are located on the OS deployment server or have been discovered in a hypervisor. For example, you might want to replicate a virtual image from the hypervisor to the Tivoli Provisioning Manager for Images servers, if you know that the image will be deployed often from these servers. Also, you can replicate images that are defined in the OS deployment server database to any OS deployment server. Restriction: A captured image that has four primary partitions cannot be deployed. The fourth partition must be a logical partition. Also, you cannot deploy an image in which the OS partition follows the data partition. To replicate a virtual image: 1. Click Go To > Deployment > OS Management > Images. 2. Select the virtual image that you want to replicate. Tip: To verify the location of the image that you are about to replicate, click its Properties tab, and review the information in the Image locations section. 3. Click Select Action > Tivoli Provisioning Manager for OS Deployment > Replicate Virtual Image. The Image Replication Wizard is displayed. 4. Specify the IP address of the OS deployment server where you want to replicate the virtual image, then click OK. 5. Click Next to start the replication process. The replication wizard is launched. 6. When the image replication is complete, click Finish. The selected virtual image has been successfully replicated. You can now see the new location of the virtual image. Click Go To > Deployment > OS Management > Images. Select the image that you have just replicated, click the Properties tab, then go to Image locations.
445
Exporting a virtual image

You can export an existing virtual image to an OVF file. v The export requires that the web interface extension be installed and running on the hypervisor. If you want to export to an VMDK format, you must install the web interface extension in its 32-bit version, to be compatible with VDDK. v Ensure that enough disk space is available on the machine to which you want to export the image. Note: To export a virtual image to OVF format on Windows systems, ensure that the image is less than: 2 GB, on a FAT16 filesystem 4 GB, on a FAT32 filesystem On an NTFS filesystem, the only image size limit is the available hard disk space. export a virtual image to the OVF format: Click Go To > Deployment > OS Management > Images. Select the virtual image to export. Click Select Action > Tivoli Provisioning Manager for OS Deployment > Export Virtual Image. The OVF Export Wizard is displayed. Click Next. 4. Select the target where you want to export the OVF image. You can select the local computer if it has the web interface extension installed, the OS deployment server, or any computer with the web interface extension installed. Click Next. 5. In the Folder box, specify the OVF file. Important: It is recommended that you use a unique directory for each OVF export, to make it easier to keep track of all of your files. If you select the OS deployment server, the default path is OSD_DATADIR\vimages, where OSD_DATADIR is the default directory for the Tivoli Provisioning Manager for OS Deployment data files: v v
Windows UNIX
To 1. 2. 3.
Linux
/opt/tpmfosd_files
A virtual image in OVF format consists of a file with the .ovf extension, and a set of virtual disk image files. Click OK, then click Next. 6. Specify the format for the virtual disk image files, depending on the format supported by the tool used to reimport the image later. The available options are: v VHD format (Microsoft Hyper-V) v VMDK format (VMWare ESX) v Raw sparse format (not recommended) Note: If the selected virtual disk image format is VMDK, before exporting the image ensure that: v You installed the VDDK library on the machine where the VMDK file will be located. A reboot is required after the VDDK installation. v You defined the VDDK path in the library path of the machine root user. v You run the web interface extension application (rbagent.exe) in its 32-bit version to be compatible with VDDK 1.1, which is a 32-bit application. Before using the VMDK file on a VMWare ESX Server, you must run the following command on the hypervisor:
vmkfstools -i <source_bytpmfosd> <output_for_esx>
where:
446
<source_bytpmfosd> Specifies the name of the VMDK file created by using Tivoli Provisioning Manager for Images. <output_for_esx> Specifies the name of the destination VMDK file to run on the VMWare ESX Server. For example:
vmkfstools -i ./OVFSLES10_OM.vmdk ./SLES10_CONVERTED/OVFSLES10_OM_CONVERTED.vmdk
Using the generated <output_for_esx> file you can run the new virtual machine on the VMWare ESX Server. 7. Click Next to start the export process. The export wizard is launched. 8. When the image export is complete, click Finish. The virtual image has been successfully exported to the specified target in the OVF format.
Part 3: Creating software modules

A software module is a piece of software other than the operating system that can be created to address various needs. Tivoli Provisioning Manager for OS Deployment is based on imaging technology. As administrator, you create images of components that you want to see on every target, and the deployment automatically merges and restores these images on each target, when needed. Tivoli Provisioning Manager for OS Deployment can handle most scenarios for software deployment and postinstallation configuration. There are many types of software modules. Depending on the type of package and installation files, the wizard guides you through the different steps to achieve your software module with minimal effort. Only some of them are available for each operating system. Information about software modules is stored in the Tivoli Provisioning Manager for OS Deployment database and is not stored in the Tivoli Provisioning Manager database. This means that you cannot view or manage software modules in the Tivoli Provisioning Manager software catalog.Click Go To > Deployment > OS Management > Software Modules. to view software modules in Tivoli Provisioning Manager. The following types of software modules can be added: v v v
Windows Windows
AVista language pack A Windows Hotfix
Windows A Windows Installer (MSI). Packages that comply with the Designed for Windows logo program typically use this type of installer. It guarantees that there is an easy way to perform an unattended installation of the software. An MSI package typically contains a file with an .msi extension. If you only have a single .exe file, it is likely to be an archive that you must extract first. For more information, refer to the section. Windows
v v
A Windows driver to include in a deployment
Windows A Windows HAL to include in a clone deployment. This option must be used only to inject HAL into a Windows cloning profile. For HAL injection in unattended setup profiles, you must create a driver package.
447
v A custom action on the targets. This includes OS configuration changes such as registry patches, command to be run, and copying sets of files on the target. The process for creating a software module of the common agent is used as an example. v
Linux
A Linux application installation, using RPM.
Creating a language pack software module

Before you begin
Windows language pack software modules must be created using a source computer with a Windows operating system, and the source computer must be running the web interface extension. You can, however, use any kind of machine (for example, a Linux operating system machine) to actually create the software module as long as Tivoli Provisioning Manager for OS Deployment is installed on it. For instructions on how to manually install the web interface extension on a source computer, see Installing and uninstalling the web interface extension on page 384. The directory containing language pack files must contain a file with a .cab extension.
Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. 4. 5. 6. Select the Windows Vista / 2008 and click Next. Select Language pack and click Next. Follow the instructions of the wizard to create your software module. You will have to choose the computer where the material to create your software module can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension.
Results
Creating a HotFix software module

Before you begin
Windows HotFixes can be created only from a computer with a Windows operating system, and the source computer must be running the web interface extension. You can, however, use any kind of
448
machine (for example, a Linux operating system machine) to actually create the software module as long as Tivoli Provisioning Manager for OS Deployment is installed on it. For instructions on how to manually install the web interface extension on a source computer, see Installing and uninstalling the web interface extension on page 384. The directory containing the HotFix files must contain a file with a .msu extension.
Procedure
1. 2. 3. 4. Click Go To > Deployment > OS Management > Software Modules. Click New Software to run the software wizard. Select Windows Vista / 2008 and click Next. Select HotFix (MSU) and click Next.
5. Follow the instructions of the wizard to create your software module. 6. You will have to choose the computer where the material to create your software module can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension.
Results
Creating Microsoft Software Installer (MSI) software modules

Before you begin
MSI software modules can be created only: v Locally with a provisioning server installed on a Windows 2000/2003/2008 operating system. v From a computer with a Windows 2000/2003/2008/XP/Vista operating system and running the web interface extension. Note: You can actually use any kind of machine (for example, a Linux operating system machine) to create the software module as long as Tivoli Provisioning Manager for OS Deployment is installed on it. The source computer must be a Windows machine with the web interface extension installed. For instructions on how to manually install the web interface extension, see Installing and uninstalling the web interface extension on page 384.
449
The directory containing MSI files must contain a file with a .msi extension. If the MSI file is located on the provisioning server, you must have placed it in a subdirectory of the import directory. Note: If the folder you are looking for is not on the local computer, the provisioning server, or on another computer running the web interface extension, you might still be able to access the wanted resource using the following procedure:
Windows
Windows 1. Create a .lnk.yourfilename file (where yourfilename is the name of your choice) that contains the path to the wanted folder (for example, \\fileserver\export\softs\). 2. In the wizard, enter .lnk.yourfilename preceded by the appropriate path. UNIX Use symlinks.
UNIX
To create your software module
Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. Select Windows Vista / 2008 and click Next. 4. Select A Windows application installation, using Microsoft Installer (MSI) and click Next. 5. Follow the instructions of the wizard to create your software module. 6. You will have to choose the computer where the material to create your software module can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension.
Results
Creating Linux software modules with RPM

Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard.
450
3. Select Linux and click Next. 4. Select A Linux application installation, using RPM and click Next. 5. Follow the instructions of the wizard to create your software module.
Results
Creating driver packages for Windows target computers

To deploy Windows target computers most efficiently, you need up-to-date drivers which are often not included with operating system installation files. These drivers can be obtained from the vendor of the server.
Before you begin

Before you can create your driver packages, you need to obtain the proper driver files. IBM drivers For IBM drivers, download the ServerGuide. To locate the ServerGuide, search for ServerGuide download in a search engine. Copy the ServerGuide directory. Note: ServerGuide is different from the ServerGuide Toolkit. HP drivers For HP drivers, download the SmartStart. To locate the SmartStart, search for SmartStart download. Dell Drivers To locate Dell drivers, search for Dell drivers download. The following example assumes that the drivers have been copied into the Files/import directory on your OS deployment server. To create a driver package:
Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. 3. 4. 5. Click New Software to run the software wizard. Select the relevant operating system and click Next. Select A Windows driver to include in a deployment and click Next. Select On the OS server itself (in the 'import' directory) and click Next.
451
6. Select the relevant directory. For IBM drivers for a Windows 2003 operating system, this is sguide/w2003drv/$oem$/$1/drv. 7. Select all relevant drivers in the list provided and click Next. Sometimes, several versions of the same driver are available. In this case, follow these guidelines: v Select drivers without alternative, even if the name is misleading. v Select the appropriate Windows version when there are alternatives, for instance select win2003 rather than win2k or winnt for a Windows 2003 driver. v v v v Select server when the alternative is between server and pro. Avoid selecting drivers with powerpc in their name. Avoid selecting drivers containing hardware abstraction layer (HAL). Avoid selecting drivers with another architecture.
Note: It is better to have a few extra drivers included in the package than to miss one. 8. Give a meaningful folder name to store your drivers, for instance IBM ServerGuide 2003 32bit, and click Next. 9. Select Yes, create binding rules based on: and PCI hardware ID. Then click Next. 10. Select Use this driver for the exact same device only and click Next. 11. Select the appropriate architecture and the targeted operating system and click Next. 12. Click Finish.
Results
You have now finished the driver package creation process.
What to do next
You might have to go through the driver package creation process several times, to create different driver package directories specific for operating systems and their architecture.
Creating a software module for HAL injection on a cloning image

2000 2003 XP
Hardware abstraction layer (HAL) might change from one computer to another depending on whether it has a single or multiple processors, whether it uses Advanced Programmable Interrupt Controller (APIC) and Advanced Configuration and Power Interface (ACPI). HAL also depends on the operating system. To create universal images, you might be required to have other HAL versions on your image than the original. To create a HAL software module to be injected on a golden master image during deployment, you must create a HAL software module and bind it to the corresponding images.
Procedure
1. 2. 3. 4. 5. Click Go To > Deployment > OS Management > Software Modules. Click New Software to run the software wizard. Select Windows 2000 / 2003/ XP. Select A Windows HAL to include in a clone deployment. Follow the wizard instructions. Different HALs are available on Windows installation CD-ROMs. The wizard offers you to create binding rules for this HAL and pre-fils some of the data to facilitate the rule creation process.
452
Results
You have now created a HAL software module to be injected on a cloning image during deployment.
What to do next
If you have not used the wizard to create binding rules, it is recommended that you bind your HAL package now to deploy it in appropriate contexts. Creating a software module for HAL injection on an unattended setup: Before you begin HAL injection on an unattended setup image is typically only necessary on some very specific server systems. The server vendor must then provide you with the appropriate HAL. IBM provides HALs for its servers in the ServerGuide CD-ROM To create a HAL software module to be injected on an unattended setup image during deployment, you must create a HAL software module and bind it to the corresponding images. Procedure 1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. Select Windows 2000 / 2003/ XP. 4. Select A Windows driver to include in a deployment. 5. Follow the wizard instructions. When asked for the driver file location, provide the path to the HAL. Results You have now created HAL injection on an unattended setup image. What to do next If you have not used the wizard to create binding rules, it is recommended that you bind your HAL package now to deploy it in appropriate contexts.
Creating a software module for custom actions

Software modules can also contain custom actions to be performed on the target. They are divided into: v An OS configuration change to perform on the target. v A set of files to copy on the target. Note: This task contains a set of general instructions for creating software modules on any platform. For more details about creating software modules on Windows, see Creating a software module for custom actions on Windows on page 341. Configuration changes are further subdivided. Depending on the operating system, you can: v Copy a single text file. v Execute a single command file. v Boot a floppy disk. The following example shows how to create a software module of the common agent.
453
Procedure
1. 2. 3. 4. Click Go To > Deployment > OS Management > Software Modules. Click Create to run the software wizard. Select the operating system and click Next. Select A custom action on the target computer and click Next.
5. Follow the instructions of the wizard to create your software module.
Results
Parameters of the software module are pre-filled for you but they can be modified in the appropriate step of the software wizard. These parameters include: v A description that identifies the package in the software module tree. v A comment with additional information about the software module. v The stage of the deployment when your software module must be installed: when the OS is installed, or after one or more additional reboot. Most of the time, you must install the package at the same time as the operating system. However, you can decide to install them in a specified order to avoid software-specific conflicts. v A file name to store your image on the provisioning server. Packages typically have a .pkg extension. v The path to where the installation files are restored on the target computer. This path is relative to the system root partition. v An additional command line that might be necessary to install your software module. When possible, the wizard suggests automatically the appropriate command line to run the installation unattended. However, you might need to add some additional parameters to the command. Repeating custom actions: Some commands must be run every time the target boots during a deployment. This is typically the case if you want to repeatedly mount a network share. This connection is destroyed when rebooting. You can therefore create a single software module to mount the network share and set this software module to run once after each reboot, starting at a specific reboot. This option is available for executing a single command. Procedure 1. Create your software module. 2. Double-click the software module name in the Software components page to display the Software details page 3. Click Edit in the title of the Package information section. 4. Select the installation stage at which the software module must be applied first. 5. Select Run at each software pass until end of deployment and click OK. Creating a software module for custom actions on Windows: Software modules can also contain custom actions to be performed on the target. They are divided into: v
Vista 2008
A WinPE 2.0 image (option present only for Windows Vista and Windows 2008
software modules ). Note: To create a WinPE 2.0 image, the Web interface extension must be started with administrator privileges. v
XP 2003
A WinPE 1.0 Ramdisk image (option present only for Windows 2000/2003/XP
software modules).
454
v An OS configuration change to perform on the target. v A set of files to copy on the target. Configuration changes are further subdivided into: v Copy and execute a single file. v Apply a Windows registry change. v Apply a Windows .ini file change. v Copy a single text file. v Execute a single command file. v Boot a virtual floppy disk. Note: Virtual floppy disk software modules can only be created from a Windows operating system running the web interface extension. Procedure 1. Click Go To > Deployment > OS Management > Software Modules. 2. Click New Software to run the software wizard. 3. Select the operating system and click Next. 4. Select A custom action on the target and click Next. 5. Follow the instructions of the wizard to create your software module. 6. You will have to choose the computer where the material to create your software module can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension. Results Parameters of the software module are pre-filled for you but they can be modified in the appropriate step of the software wizard. These parameters include: v A description that identifies the package in the software module tree. v A comment with additional information about the software module. v The stage of the deployment when your software module must be installed: when the OS is installed, or after one or more additional reboot. Most of the time, you must install the package at the same time as the operating system. However, you can decide to install them in a specified order to avoid software-specific conflicts. v A file name to store your image on the provisioning server. Packages typically have a .pkg extension. v The path to where the installation files are restored on the target computer. This path is relative to the system root partition. v An additional command line that might be necessary to install your software module. When possible, the wizard suggests automatically the appropriate command line to run the installation unattended. However, you might need to add some additional parameters to the command. Example As examples are described the complete step-by-step process of creating a software module with the content of the second CD-ROM of a Windows 2003 R2 distribution (see Creating a software module for unattended deployment of Windows 2003 R2 on page 343), and of creating a ramdisk from a bootable diskette (see Creating a ramdisk software module from a bootable diskette on page 344).
455
Repeating custom actions: Some commands must be run every time the target boots during a deployment. This is typically the case if you want to repeatedly connect to a network share. This connection is destroyed when rebooting. You can therefore create a single software module with a netuse command to set the network share and set this software module to run once after each reboot, starting at a specific reboot. This option is available for v Windows registry changes. v Copying and executing a single file. v Executing a single command. Procedure 1. Create your software module. 2. Double-click the software module name in the Software components page to display the Software details page 3. Click Edit in the title of the Package information section. 4. Select the installation stage at which the software module must be applied first. 5. Select Run at each software pass until end of deployment and click OK. Creating a software module for unattended deployment of Windows 2003 R2: To prepare an unattended deployment of Windows 2003 R2, you must include some of the content of the second CD-ROM of the distribution in a software module and bind this software module to the image created with the first CD-ROM. Procedure 1. 2. 3. 4. 5. 6. 7. 8. 9. Click Go To > Deployment > OS Management > Software Modules. Click New Software to run the software wizard. Select Windows 2000 / 2003 / XP. Select A custom action on the target. Select A set of files to copy on the target (with an optional command to execute). Indicate on which computer the files of the second CD-ROM are located. Indicate the complete path to find the files in /CMPNENTS/R2, for example D:/CMPNENTS/R2. Verify the proposed description and if necessary, modify it. Optionally, enter a comment. Enter the necessary parameters for this specific software module: v Apply the software module After one additional reboot. v Enter a meaningful package file name, with a .pkg extension. v Use \install\R2 as destination path. v Do not forget the command-line to be run on the target:
cmd /c \install\R2\setup2.exe /q /a /p:xxxx-xxxx-xxxx-xxxx-xxxx /cs
where xxxx-xxxx-xxxx-xxxx-xxxx is the product key. 10. Wait during the package generation process and click Finish. What to do next Bind your software module to your Windows 2003 R2 unattended setup image (see Automatic binding rules on page 347).
456
Creating a ramdisk software module from a bootable diskette: Creating a ramdisk software module from a bootable diskette is considered by the software module wizard to be a Configuration change, which itself is included in the Custom action. Procedure 1. 2. 3. 4. 5. 6. 7. Click Go To > Deployment > OS Management > Software Modules. Click New Software to run the software wizard. Select Windows 2000 / 2003 / XP. Select A custom action on the target. Select a Configuration change. Select Boot a virtual floppy disk. Specify which computer the bootable diskette must be read from. This can be either on the local computer or on another computer running the web interface extension. The option On the server itself must not be used. If the diskette drive is added after the web interface extension is started (on the local or remote computer depending on your choice), it might be necessary to stop and restart the web interface extension to enable it to detect the diskette drive. Moreover, the diskette must not be opened by another application (such as Windows Explorer), as this might cause interference.
Note: The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension. 8. Insert the bootable diskette that you want to image and run as a ramdisk in the disk drive and click Next. 9. Enter a software module description and click Next. 10. Specify parameters for the package creation and click Next. Results The software module is created. Creating a software module of the common agent: This example shows the steps for creating a software module of the Tivoli Common Agent. v The Agent Manager must be installed on the same server as Tivoli Provisioning Manager. The Agent Manager is installed during Tivoli Provisioning Manager installation. v The following Tivoli common agent installable packages have to be present in the local file repository root path: common_agent_1.4.1.0_200810230654_aix.tar common_agent_1.4.1.0_200810230654_linux_ppc.tar common_agent_1.4.1.0_200810230654_linux.tar common_agent_1.4.1.0_200810230654_solaris.tar common_agent_1.4.1.0_200810230654_windows.exe The local file repository path is: TIO_HOME\repository. v A number of configuration scripts must exist inside the TIO_HOME/tools/prepare_tca_image folder. These scripts are: caInstall.rsp checkDiskSpace.vbs
457
ihscript.vbs install.bat install.sh All of the scripts listed above will be used during an offline installation of the Tivoli Common Agent that will be performed on a target system once an OS image has been successfully deployed. v A script, prepareTCAImage, used for preparation of the Tivoli Common Agent and Tivoli Provisioning Manager subagent installation images must exist inside the tools folder. Either %TIO_HOME%\tools\ prepareTCAImage.cmd or $TIO_HOME/tools/prepareTCAImage.sh. This script will be executed by a workflow code and it will generate a number of Tivoli Common Agent offline, platform specific, installation packages. It also extracts the common agent installation parameters, such as the agent manager registration password, and writes them to a response file, caInstall.rsp. To create a software module: 1. Click Go To > Deployment > OS Management > Boot Servers. 2. In the Select Action menu, select Create Tivoli Common Agent Software Modules. 3. Click Yes when prompted to go to the Provisioning Task Tracking application. The Provisioning Task Tracking application opens and you can monitor the progress of your software module creation.
Keeping command lines confidential

When you use command lines in your software modules, their call and their output are stored in deployment logs. In some circumstances, for instance when the command line includes a password or a product key, it might be necessary to keep the information contained in the command line confidential. Three levels of confidentiality are available. No confidentiality The command line is visible in the web interface and on the target during the installation, its call is logged, and its output is also logged. The command line call is not logged The command line is visible in the web interface, and its output is logged, but the command line call, containing the whole command line string with all parameters, is visible in the logs neither on the web interface nor on the target. To apply this level of confidentiality, you must prefix the command line by one exclamation mark (!). The command line call and output are not logged The command line is visible in the web interface, but its call and output are visible in the logs neither on the web interface nor on the target. To apply this level of confidentiality, you must prefix the command line by two exclamation marks (!!). The command lines and their optional confidentiality markers can be entered either in the Software wizard or when you edit the Package information (Click Go To > Deployment > OS Management > Software Modules. ) Once on the Software Modules page, select the software module that you want to edit.
Scheduling the application of software modules

When several software modules are associated with an image, you can schedule when they are applied. Note:
458
1. Windows language packs, Windows HotFixes, and Windows drivers are always deployed right after the operating system. Their ordering cannot be modified. Therefore, they do not appear in the Software application order window. 2. Solaris software modules are always applied right after operating system installation. Reboots are not handled under Solaris. To schedule the application of software modules, click Reorder software at the bottom of the software modules page. This opens a dialog window that allows you to order the different software modules stored on your provisioning server. The dialog shows the different steps of a deployment with disk partitioning (in green), OS installation (in purple) and reboots (in red). Software components can be installed in between all of these steps, where they are placed inside the expandable installation stages (in yellow). You can add, move, and delete reboot sequences by using the buttons at the bottom of the dialog window. You can also rename software installation stages. You can expand the software installation stages to view their content by clicking on the + icon. You can then move individual software modules from one stage to another by drag-and-drop. The destination stage does not need to be expanded. Note: Drag-and-drop is limited to the Software Application Order window. The software modules are not ordered within an installation stage. If you want a software module to be installed before another between two specific reboots, create two distinct installation stages between the reboots. For example, if your first software module copies files on the target and the second one runs a command on these files, you must place the first software module in an installation stage which occurs before the one in which you run the command software module. Typical application locations for software modules include: v For virtual floppy-disk used as ramdisk: before disk partitioning and OS installation, in order to allow for the configuration of low-level hardware devices controlling the hard disk, such as RAID controllers. v For virtual floppy-disk images: in between disk partitioning and OS installation, in order to flash devices early. v Sysprep and unattended setup processes are automatically run during the OS installation phase, if required. v For system snapshots: right after OS installation, to deploy the software nearly at the same time as the operating system image (the most efficient). Before OS installation is forbidden, as a system snapshot needs an installed OS. v For other software: when the OS is installed or after additional reboots, depending on the software module needs.
Part 4: Binding rules

In this section of the tutorial, you will learn how to associate or bind a software module to targets. Software bindings correspond to the list of software modules currently assigned to the target.
Binding software modules to targets

Binding software modules to target computers enables automatic deployment. When binding to target computers, you explicitly provide the list of software modules to bind to your target computers. To explicitly bind a software module to target computers follow these steps:
459
Procedure
1. 2. 3. 4. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. In the list of computers, click the name of the appropriate computer. Click the Deployment Properties tab. Click the Bindings tab, then click Software bindings.
5. Click Edit to modify the bindings. 6. Select the software module to associate with deployment to this computer. 7. Click OK.
Results
You have now bound a software module to a target computer.
What to do next
You can also deselect items to remove their explicit bindings. To remove a binding by rule, you must modify the rule.
Automatic binding rules

Automatic binding rules are used to create bindings between software modules and target deployments, without having to specifically bind a software module on each target deployment. Rules are created in software modules to determine which deployment on atarget will automatically be bound to the software module. Rules are made of criteria and values. If a target has a matching value for all criteria in the rule, the software module is bound to that target. For example, if the criteria is the model name, and the value is Optiplex, targets with a model name starting with Optiplex will be bound to the object where the rule has been defined. To create a binding rule:
Procedure
1. Click Go To > Deployment > OS Management > Software Modules. 2. Select the software module that you want to use for the new binding rule. 3. Click the software module that you want to bind. Details about the software module are displayed. 4. Click New rule. 5. When adding a binding rule to a software module, you can set values for the following criteria: v A deployment scheme v An image v A current OS configuration v One of the system-definable and user-definable fields of the database (only used if you have customized the database) v An operating system type, such as Windows 2000 v An operating system version, such as SP2 v An operating system language v v v v v An operating system architecture, such as x86-32 A computer model name A BIOS version A PCI device A base board
460
v A free-text condition in Rembo-C; syntax For example, to create a binding based on the operating system type between a software module and targets, you must create a rule, click OS type, and select the operating system version that you want to limit this software module to. 6. When adding a binding rule to an OS configuration, you can set a condition on the deployment scheme, and on the computer model name. The next four fields are only used if you have customized your database and want to match specific user categories. 7. Finally, you can enter a free-text condition following the Rembo-C; syntax. Free-text conditions follow a Rembo-C; syntax. They must only be used by advanced users. The conditions determine the applicability of the rule and evaluate to true or false. A condition must be formed using the variables also used for keyword substitutions in software modules, combined with Java-like logical operators, listed by order of priority in the table below:
Table 71. Logical operators for free-text conditions Operator < <= => > == != && || Meaning smaller than smaller than or equal to greater than or equal to greater than equal to not equal to AND operator OR operator
For example, a typical condition can be:

Disk[0].DiskSize > 10*1024*1024
Note: If a condition cannot be evaluated, it is considered to have the value false.
Results
You have now created an automatic binding rule.
Part 5: Installing a virtual image

In this part, you will learn how to install a virtual image.
Installing a virtual image

You can install virtual images on physical computers, on virtual machines, or on virtual machines on hypervisors that are known to Tivoli Provisioning Manager for Images. v The BIOS startup sequence of the target computer must first have network and then hard disk for the installation task to complete successfully. v If you deploy the Tivoli Common Agent with a Linux golden master or unattended setup image, we recommend you have a minimum of 2 GB of swap space for the image. To specify this: Click Go To > Deployment > OS Management > Images. Select your image, then click the Properties tab, then the Disks tab. v Ensure that the web interface extension is installed and running on the hypervisor. You can deploy a virtual image on more than one target computers at a time. The image can be deployed even to a hypervisor technology that is different from the one used for the capture. For example, if the image was captured from a VMWare ESX virtual machine, it can be deployed to a KVM virtual machine.
461
Note: Before deployment, all imported or discovered virtual images must have SAP and credential information added, so that they can be used on the target computers. For more information, see Adding credentials to virtual images on page 430. To 1. 2. 3. 4. 5. install the virtual image on the target computer: Click Go To > Deployment > OS Management > Image Deployment. Specify a name for the image deployment task or accept the default name. Select the virtual image that you want to install. Select the target computer to install the image on. Choose to schedule the task or run it immediately.
6. Click Submit. The task will be executed. Monitor its progress until the task has completed. Click Refresh to see the updated status. a. To view the task progress in detail, click the task name to open the task details page. In the Deployment Request Details column, click Request ID to view the provisioning workflow execution log. b. If the target computer is already managed by Tivoli Provisioning Manager, Tivoli Provisioning Manager will attempt to reboot the machine so that the deployment activity can run. If Tivoli Provisioning Manager cannot restart the machine, then Tivoli Provisioning Manager will schedule the OS deployment activity, and you must boot the machine manually. When the machine boots off the network (and gets picked up by the Tivoli Provisioning Manager for OS Deployment server), it will then run the OS deployment activity. You have finished deploying the virtual image to the specified target computer.
Reference
Upgrading Tivoli Provisioning Manager for Images to a later version

If necessary, when a newer Tivoli Provisioning Manager for Images build becomes available, you can download it and then upgrade your existing Tivoli Provisioning Manager for Images to this later version. You can upgrade to a Tivoli Provisioning Manager for Images version later than or equal to the version supported with Tivoli Provisioning Manager version 7.2.
Obtaining the latest Tivoli Provisioning Manager for Images build

Build packages and fixes for Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images are published on IBM Fix Central. The packages can be found by accessing the Fix Central section of the Tivoli Provisioning Manager for OS Deployment and Tivoli Provisioning Manager for Images Support Web site, at http://www.ibm.com/support/fixcentral. The license for Tivoli Provisioning Manager for Images provides you with an entitled IBM ID, which is required for the downloads. If you do not have an entitled IBM ID, you will see the fixes, but you will not be able to download them. To download the packages for Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images:
Procedure
1. Select Tivoli for the Product Group. 2. Select the Tivoli Provisioning Manager for OS Deployment or the Tivoli Provisioning Manager for Images product.
462
3. For the Installed Version, select the build number that matches the number of the Tivoli Provisioning Manager for OS Deployment build that was shipped with Tivoli Provisioning Manager 7.2. 4. Select the platform, and then click Browse to find the required packages and fixes. 5. Click Continue.
Upgrading to the latest Tivoli Provisioning Manager for Images build

To upgrade your Tivoli Provisioning Manager for Images to a later version:
Procedure
1. Obtain the new Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images full build for the platforms used in your environment. If you are unsure, download all platforms. See Obtaining Tivoli Provisioning Manager for Images on page 396. 2. Extract all .exe files (self-extracting Windows 32-bit and 64-bit installables) to obtain the required .msi files. If you want, you can delete the .exe files. 3. Place all the Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables (tar.gz and .msi files) into the $TIO_HOME/repository/tpmfosd folder (for Windows, %TIO_HOME%\repository\tpmfosd). Note: Ensure that permissions for the files placed in the repository are set so that they are owned by tioadmin. 4. Discover the new Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables: a. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. b. In the Discovery Configuration list, click TPMfOSD Version Discovery, and then click Run. This will discover the Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images installables that you have placed in the repository, and will also create Tivoli Provisioning Manager software products that represent the new versions of Tivoli Provisioning Manager for OS Deployment or Tivoli Provisioning Manager for Images. 5. Stop Tivoli Provisioning Manager for OS Deployment on all of your servers, except the one running on the local Tivoli Provisioning Manager server. 6. Perform the following: a. In Tivoli Provisioning Manager, run a software product upgrade for Tivoli Provisioning Manager for OS Deployment on the local server: 1) Click Go To > Deployment > Software Management > Software Product Upgrade.
Windows
2) On the Software Product Upgrade page, select Tivoli Provisioning Manager for OS Deployment as the software to upgrade. Note: For details about the OSD_HOME installation directory, see ../ com.ibm.tivoli.tpm.ins.doc/install/rpath_variables.dita. 3) Select the target computer, which is the local Tivoli Provisioning Manager server, then select Upgrade to a new version as the upgrade method. 4) Click Submit. This will upgrade the local Tivoli Provisioning Manager for OS Deployment server to the new version that you have selected. b. For non-Windows Tivoli Provisioning Manager servers, the upgrade of the local Tivoli Provisioning Manager for OS Deployment server must be done manually, as Tivoli Provisioning Manager does not have root access to the local system:
UNIX Linux
463
Results
You have finished upgrading your Tivoli Provisioning Manager for Images to a later version.
Tivoli Provisioning Manager for OS Deployment boot server configuration

Tivoli Provisioning Manager for OS Deployment boot server can be accomplished by modifying the main server side OS configuration parameters. They can be modified either in the web interface or directly by editing the rembo.conf file. The parameters are divided into seven categories that mirror the sections found in the web interface. They are: v Debug level information v Base parameters v Web interface parameters v Boot module parameters v Network boot module parameters v File access module parameters v HTTP Console Security parameters Most parameters can be modified in the web interface: Click Go To > Deployment > OS Management > Boot Servers. For more details, see: Modifying OS configuration parameters on page 360.
Base parameters
Debug level information GlobalDebugLevel number specifies the level of details that must be placed in the log file. IP address of the backup server Backup ip-addr defines the IP address of a backup server that can be used by the target if the
464
primary server fails. The backup server must have the same Net Password as this server. For the backup recovery system to work, the backup server must also contain an exact copy of the files stored on primary server. Maximum size of the server log files MaxLogSize number limits the size of the log file generated by the provisioning server. The maximum log size is specified in bytes, and applies to all log files created by the provisioning server. If you do not specify this parameter is not set, or set to 0, then log files are not limited in size. If a limit is set, and the server reaches this limit, the current log file is backed up and a new file is created. CountersInterval minutes specifies the interval, in minutes, for the server statistics measures. Network interfaces used by the server Interfaces ip-addr specifies the list of network interfaces that the provisioning server uses when sending and receiving packets to and from targets. If you leave this option unspecified, the server uses the network interface corresponding to the official hostname of the server. The format is a list of IP addresses, separated by spaces.
web interface parameters

You can modify these parameters with caution, and only if you are familiar with them. v Disable the HTTP module DisableHTTP disables the web interface. If you set this parameter, run the -c command-line option to change server parameters. Note: You must not disable the HTTP module as the Tivoli Provisioning Manager functionality integrated with will cease to be available. v Disable HTTP SSL encryption DisableSSL disables encryption in the Web interface and enables unencrypted HTTP connections. v TCP port for HTTP requests, TCP port for encrypted HTTP requests (SSL) HTTPServerPort port specifies the TCP port used by the Web interface when listening for unencrypted HTTP requests. You can set this parameter to 80 if you want the Web interface to be accessible by typing the server host name in your Web browser. To make the Web interface accessible by typing https followed by the server host name, set this parameter to 443. v Inactivity timeout before a session expires HTTPSessionTimeout minutes specifies the timeout (in minutes) before Web interface users are automatically logged out. A typical value is 5 minutes. v Disable HTML contextual menus DisableContextualMenu disables the contextual menu. When you use a right-click in the web interface, you will see the regular contextual menu of your browser. v Disable HTML drag-and-drop DisableDragAndDrop disables web interface drag-and-drop operations on selected icons. Drag-and-drop works on most common browsers, but it can be disabled in case of incompatibility. v Disable javascript drop-down lists DisableJSDropDown disables enhanced drop-down menus in favor of standard drop-down menus. Standard drop-down menus do not recognize DHTML layers under Internet Explorer, so this parameter can cause problems. v Disable the use of cookies DisableCookies disables the use of cookies in the web interface. Disabling cookies does not prevent you from using any essential function of the console. v Disable HTTP transfer optimization
465
DisableHTTPOptim disables the optimization of HTTP transfer in the web interface. Set this parameter if you do not want the web interface to group JavaScript, stylesheets, and images into large files to reduce HTTP traffic and enhance the cache process. You must disable this optimization if you are creating console pages.
Boot module parameters

v Disable DHCP/BINL module DisableBOOT disables the PXE component of the provisioning server. v Disable the DHCP proxy functionality DisableDHCPProxy disables the DHCPProxy service on the provisioning server. The server does not send extended DHCP replies (PXE replies) to DHCP discovery packets sent on the network by remote-boot target. When the DHCP proxy is disabled, the DHCP server must be configured to provide a complete PXE answer to PXE targets, including option 60 and option 43. DHCP proxy mode must be disabled if you have more than one provisioning server operating on the same subnet. v Disable the multicast BINL functionality BootNoMulticastDiscovery disables PXE multicast discovery support on the provisioning server. When PXE multicast discovery is disabled, target computers with multicast discovery configured in DHCP option 43 are not able to find the provisioning server. v UDP port for TFTP requests TFTPPort is the port used on the provisioning server to receive TFTP request packets from PXE targets. The default value is 69. Note that unless your network equipment is automatically routing TFTP packets to a non-standard part, you must not change this setting because PXE always sends TFTP requests to port 69, without any possibility to change port. v Max. TFTP Segment Size MaxTFTPSegSize bytes is the maximum size in bytes for TFTP segments. The default value is 512 but a smaller one can be given if the network configuration requires it. v Seconds to wait before starting a MTFTP stream MTFTPStartDelay secs specifies the time, in seconds, to wait before starting a MTFTP transfer. This period is used by target computers to replicate together. The higher the value is, the more replicated the deployment engine is. However, latency is introduced when booting target computers individually. The PXE standard default value is 2. v IP address used by targets for MTFTP MTFTPClients port [:target-port ] specifies the multicast IP address and port used by the provisioning server when sending MTFTP data to target computers. v UDP port for MTFTP requests MTFTPPort port specifies the UDP port used by the provisioning server to receive MTFTP request packets from target computers. The default value is 4015. v Seconds to wait before sending DHCP/BINL answers BootReplyDelay secs specifies the number of seconds to wait before answering DHCP/BINL request packets sent by target computers. If you have more than one provisioning server on the same subnet, target computers use the server with the lowest shortest reply delay. The default value is 0 (no delay). v Max. number of requests per minute (load balancing) BootReplyLimit number specifies the maximum number of DHCP/BINL requests to a provisioning server in one minute. The server discards boot requests coming from target computers when the specified limit is reached. A number of 0 indicates unlimited requests. This parameter can be used to implement load balancing over multiple servers. v UDP port for DHCP/BINL requests BootDiscoveryPort port specifies the UDP port that the provisioning server uses when listening for BINL boot requests. The default port used for a standard target computer is 4011. v Multicast IP address used for BINL requests
466
BootDiscoveryAddress ip-addr specifies the multicast IP address that the provisioning server listens to when waiting for BINL multicast requests coming from target computers. This value must match the value set in the DHCP option 43 sent to targets. v No-boot schedule NoBootSchedule specifies the frequency at which the provisioning server stops providing a PXE boot service. It is used in conjunction with NoBootDuration. Modify this parameter using the web interface only. v No-boot duration in minutes NoBootDuration specifies the duration in minutes during which the provisioning server stops providing a PXE boot service if a no-boot schedule is specified. It is used in conjunction with the parameter NoBootSchedule. Modify this parameter using the web interface only.
Network boot parameters

v Disable the NBP module DisableNBP disables the NBP component of the provisioning server. Because NBP is used by target computers when booting, target computers are not able to boot if NBP is disabled. v UDP port for NBP requests NBPServerPort port specifies the UDP port used by the provisioning server to receive NBP requests from target computers. The default value is 4012. Only change this value if the default port is already used by another application on your computer.
File access module parameters

v Disable the FILE module DisableFILE disables the FILE (NetFS, MCAST) component of the provisioning server. If you disable the FILE server module, target computers are not able to boot on this server. v Base directory for server files BaseDir string specifies the base directory for the provisioning server. All paths included in the OS configuration are relative to this base directory. This is a mandatory parameter, and has no default value (if you are using file-based configuration mode, you must set it before starting the provisioning server for the first time). v Relative directory for the shared repository SharedDir path specifies the path relative to the server file directory for storing the shared repository internal files. By default, this parameter is set to shared. v First multicast IP address used for MCAST transfers FileMCASTAddress ip-addr:port specifies the multicast IP address used when sending packets to target computers. The provisioning server can generate different multicast IP addresses using this parameter as the base for the first address in a range. v Number of multicast addressed to use for MCAST transfers FileMCASTAddrCount number specifies the number of multicast addresses that the provisioning server can use when sending multicast data to target computers. This parameter sets the size of the range of multicast addresses that the server can use. This range begins with the address set by the parameter FileMCASTAddress. v Maximum number of PCAST connections FileMaxPCASTSessions indicates the maximum number of PCAST sessions that the provisioning server accepts simultaneously. This parameter is relevant if the server is running in UNICAST mode and deploying a group with the UNICAST setting. v Port for FILE requests FileServerPort port specifies the UDP port used by the provisioning server to receive transfer protocol control requests. The default value is 4013, but you can change this parameter if port 4013 is already used by an application on your computer. v Disable the TCP module
467
DisableTCP disables the TCP component of the provisioning server. Target computers might not be able to boot on this server if you disable the TCP server module. v Directory for internal files DataDir path specifies the path relative to the provisioning server base directory for storing files accessible to the target computer. By default, this parameter is set to files.
Network share module

v Network UNC path NetworkShare path specifies the path of the shared partition directory of the provisioning server. This parameter can be used to increase the deployment speed of some operating systems. You need to have set the partition as read-only for the user entitled to access the network share. v User entitled NetworkUser "string" is the name of the user entitled to access the network share. If the user is part of a domain, use the syntax Domain/User. v Password of the user NetworkPasswd "string" is the password used to access the network share. The password is stored in an encrypted format in the rembo.conf file. Note: If the Network UNC path, the User entitled, or the Password of the user are not correct, you get an error when trying to deploy using the network share. If the Network UNC path is empty, the deployment does not try to use a network share.
OS deployment server replication

Replication keeps databases, files, and information up-to-date between parent and child OS deployment servers. It can be performed through several mechanisms.
Replicated objects
The following objects are replicated between parent and a child OS deployment servers: v Deployment schemes v Hardware configurations v Software modules v Images, including virtual images With a good network connection between your servers and your database, you can choose one of the following replication mechanisms: v Automated, whenever it is needed, using a config.csv file. v Automated, at scheduled times. v Manual, using the web interface or a command line (web interface extension). See the related links for more information about replicating with a schedule or manually, using the web interface or the web interface extension.
Replicating OS deployment servers with a schedule

To replicate your OS deployment servers regularly, you can set up a replication schedule, indicating the frequency of the replication
Before you begin

If you have a hierarchy of more than two levels of parent and child servers, the scheduling must match the hierarchy. Top servers must be replicated first, and child servers after.
468
Important: The replication schedule for each server is determined by the config.csv file at the Tivoli Provisioning Manager for OS Deployment start time. If you change the replication schedule in the web interface (on the Replication tab), it will not be saved after restarting; the values from the config.csv file will be used instead. For a persistent change to the replication schedule, you must edit the config.csv file.
Procedure
v For a persistent change, edit the config.csv file to include the new replication schedule. v Otherwise, use the web interface to set up a replication schedule. For each child server in the hierarchy: 1. Click Go To > Deployment > OS Management > Boot Servers. 2. Click the boot server to work with, then click its Replication tab. 3. Click Set up a replication schedule. 4. Enter the start date and time, and the frequency of the replications. As child servers must be replicated after their parents, you must use the same or a lower frequency than the replication schedule on the parent server. 5. Click OK.
Replicating an OS deployment server once manually

Replicating OS deployment servers can be done manually with the web interface or with the web interface extension.
Procedure
v With the web interface: 1. Click Go To > Deployment > OS Management > Boot Servers. 2. Click the boot server to work with, then click its Replication tab. 3. Select the OS deployment server you want to replicate. 4. Click on the link to replicate the server. The exact wording of the link depends on whether the server needs to replicate, and on the position of the server in the hierarchy. v With a command line and the web interface extension: 1. On the child server, open a command line shell. 2. Go to the directory where rbagent is located. 3. Run rbagent rad-srvsync.
What to do next
Now, you can replicate the children of this OS deployment server. You can also set up a replication schedule.
Server replication status

You can see the server replication status on the server's Replication tab, in the web interface. Click Go To > Deployment > OS Management > Boot Servers. Click the server to work with, and then click its Replication tab. The icons on this page are visual indicators for the replication status of your servers.
Status
v On the lower left hand-side of a server icon, the up/down indicator is displayed. The status indicator can take two different values:
A blue circle with a light center, indicating that the OS deployment server is up and running.
469
A black dot, indicating that the OS deployment server is down. v On the lower right side of a child server icon, the replication status indicator is displayed. The status indicator can take three different values:
A cross in a red dot indicates that the selected child server is not up-to-date with its parent. Files are missing on the child server; the child server must be replicated with its parent before any action is performed.
A yellow triangle with an exclamation point indicates a warning. A discrepancy was discovered between the child and the server files. Some files can have been updated or added on the parent server. Click Object version to view which deployment objects are not up-to-date. If you plan to use any of these objects, you must replicate your server first. This page contains yellow triangles if SSL is not disabled or if the servers are temporarily unresponsive.
A green dot with a white check mark indicates that the child server is up-to-date with its parent. Note: When a server is down, it keeps the replication status indicator it had when it was last running. Replicating while a server is down is not possible.
Modifying OS configuration parameters

The following list provides detailed explanations of the parameters used in the rembo.conf file and the web interface. Backup Name Backup IP address of backup server. Synopsis Backup ip-addr Location v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab, and select Base Parameters. v rembo.conf: Beginning of the file. Description This parameter defines the IP address of a backup server for this provisioning server. The backup server IP address is sent to all target computers connected to this server. If this server fails, the targets detect that the primary server has failed, and automatically switch to the backup server. Here are some considerations regarding the provisioning server running at the IP address specified by this parameter (the backup):
470
v The backup must be configured to use the same UDP ports as this server for the NBP, FILE, MCAST and PCAST services (that is for all specific services); v Its file system must be strictly identical to the file system of this server, so that boot agents can switch from one server to the other in the middle of a file transfer; v Ideally, the backup must be configured to answer DHCP discovers and PXE discovers for the same targets as this server, but with a higher delay (see BootReplyDelay). This ensures that the remote-target boots on the backup server on the next boot. BaseDir Name BaseDir Directory for all provisioning server files. Synopsis BaseDir " directory" Location v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the File Access Module section. v rembo.conf: Beginning of the file. Description By default under Windows, DataDir points to c:\Program Files\Common Files\IBM Tivoli. You must set this parameter to the directory where you have installed the provisioning server executable. If you are using the Windows version the BaseDir parameter is automatically configured during the setup process. BaseDir contains a subdirectory named packages which holds the .pak server extensions. Note: Always use forward slashes (/) in all path names you enter in the text-based configuration file. Examples
BaseDir "c:\Program Files\Common Files\IBM Tivoli" BaseDir "/usr/local/tpmfos"
BootDiscoveryAddress Name BootDiscoveryAddress Multicast address used for PXE discovery requests Synopsis BootDiscoveryAddress ip-addr Location v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description If PXE multicast boot discovery is enabled on the provisioning server (see (BootNoMulticastDiscovery)), this option must be set to the multicast IP address used by the remote-boot targets when performing PXE discovery. If this option is not set, Tivoli Provisioning Manager for OS Deployment uses the IP address 232.2.0.1.If the provisioning server is in the same subnet as the DHCP server, PXE discovery is not required because the remote-boot targets know that the PXE server is on the same computer as the DHCP server (option 60 set to PXEClient). If the provisioning server and the
471
DHCP server run on different computers, but are on the same IP subnet, PXE discovery is still not required because the provisioning server intercepts DHCP requests and provides PXE information at the DHCP stage. You only require PXE discovery if the remote-boot targets are not on the same subnet as the provisioning server, or if your existing PXE infrastructure is already setup for PXE discovery. Example
BootDiscoveryAddress 232.5.6.7
BootDiscoveryPort Name BootDiscoveryPort IP port used when listening to PXE discovery requests Synopsis BootDiscoveryPort port Location in the OS configuration v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description This parameter must be set to the port used by remote-targets when sending PXE boot requests (multicast boot discovery, or BINL discovery). The default value works with PXE bootroms which have not been modified, so there is no reason to change this value unless you know what you are doing. If this option is not set, Tivoli Provisioning Manager for OS Deployment uses the IP port 4011. Example
BootDiscoveryPort 5011
BootNoMulticastDiscovery Name BootNoMulticastDiscovery Disables PXE multicast discovery support. Synopsis BootNoMulticastDiscovery yes/no Location v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description If the parameter BootNoMulticastDiscovery (without argument) is present in the configuration file (rembo.conf config), then PXE multicast discovery is disabled on the server. The provisioning server does not answer PXE multicast packets received from remote-boot targets. PXE multicast discovery is used by remote-boot targets if your existing PXE infrastructure is configured to use PXE discovery. Multicast discovery is not needed if the remote-boot targets and the provisioning server are on the same subnet, because the targets use other mechanisms to find the provisioning server (DHCP proxy, or DHCP option 60).
472
If you know that you do not need PXE multicast discovery, you can disable it by setting this parameter to true. This is suggested if you are in a large company or institution where other PXE targets can be configured to use multicast discovery on other subnets, but you do not want your server to reply to these targets. Example
BootNoMulticastDiscovery
BootReplyDelay Name BootReplyDelay Sets the delay before answering discovery requests. Synopsis BootReplyDelay secs Location v web interface: Not available. v rembo.conf: Beginning of the file. Description This parameter sets the number of seconds to wait before answering a PXE discovery request (PXE discovery enabled), or a DHCP request (ProxyDHCP enabled). The default value is 0 (no delay). The only reason to delay a PXE reply is when two or more OS deployment servers are configured to run on the same subnet, with the same list of targets. The parent server can be configured with a delay of 0 seconds (answer immediately), and other servers with a delay of 2 seconds. If the parent server fails, backup servers handle remote-boot target requests. Example
BootReplyDelay 2
DataDir Name DataDir Directory for internal files. Synopsis DataDir " path" Location v web interface: Not available v rembo.conf: Beginning of the file. Description The server uses the directory specified by DataDir to store its internal files, in particular all the files stored on its file system. You can use this parameter to specify a new directory for the internal files of the server, for example if you want to store the server files on a new storage device with more space, but you want to keep the executable and configuration files on the original location. All the files stored in the directory specified by DataDir must not be modified, or the provisioning server might not work correctly. If the specified directory does not exists, the server tries to create it. Examples
DataDir "/mnt/morespace/rembo" DataDir "C:/TPMfOS"
DefaultAuthDomain
473
Name DefaultAuthDomain Default authentication domain. Synopsis DefaultAuthDomain " domain" Location in the OS configuration v web interface :Not available v rembo.conf: Beginning of the file. Description This is the name of the default authentication domain to use when a target sends an authentication request to the server to identify a user. This name must match the name of an existing authentication domain as defined in Authentication domains. Example
DefaultAuthDomain "HTTP"
DefaultFileServer Name DefaultFileServer Defines a new server for FILE services. Synopsis DefaultFileServer ip-addr Location in the OS configuration v web interface :Not available v rembo.conf: Beginning of the file. Description This parameter can be used to specify the default IP address of the target serving the NETfs and MCAST protocols. If the you want to use the same provisioning server for all services, you do not have to specify this parameter. The target defined by this parameter must be configured to use the same network password (NetPassword) as the server containing this parameter. This parameter is applied to all the targets contained in the group. Example
DefaultFileServer 172.16.8.9
DefaultGroup Name DefaultGroup Default group for unknown targets. Synopsis DefaultGroup " name" Location in the OS configuration rembo.conf: Beginning of the file. Description This parameter defines the default administrative group for unknown targets. The "name " argument must be an existing administrative group. Example
DefaultGroup "MyNewHosts"
DefaultLockOut
474
Name DefaultLockOut Locks peripherals on unknown targets. Synopsis DefaultLockOut [ none ] [ , mouse ] [ , keys ] [ , screen ] [ , all ] Location in the OS configuration rembo.conf: Beginning of the file. Description Use this parameter to lock peripherals on the remote-boot targetsduring the time Tivoli Provisioning Manager for OS Deployment is active on the unknown target. You can for example lock the mouse or/and the keyboard so that the user cannot interrupt an automatic image restoration process. Peripherals are automatically unlocked when Tivoli Provisioning Manager for OS Deployment gives the control to the operating system (with a HDBoot, LXBoot, RDBoot or DeviceBoot). Example
DefaultLockOut keys, mouse
DefaultOptions Name DefaultOptions Startup options for the remote target computer. Synopsis DefaultOptions [ admin ] [ , autoboot ] [ , nousb ] [ , novesa ] [ , noapm ] [ , unicast ] [ , noigmp2 ] [ , noudma ] [ , noprotpart ] [ , realmodedisk ] [ , realmodepxe ] [, routepxeirq] Location in the OS configuration rembo.conf: Beginning of the file. Description Twelve different options can be set for targets. These options are used when unknown targets run under Tivoli Provisioning Manager for OS Deployment: v Admin: forces the target to run in administrative mode. Administrative mode adds options in the start menu on the target: Interact, to run the interactive evaluator, and Purge cache to purge the local disk cache. Additionally, functions defined in the admin.rbx plugins are available (File Manager, TextEdit,...). v Autoboot: tells the target to automatically reboot on unrecoverable errors. Unrecoverable errors are low-level errors which cannot be intercepted with the exception mechanisms. By default unrecoverable errors are displayed on the screen and the computer is halted. You can define the autoboot option if you want to reboot on unrecoverable errors. v NoUSB: disables USB devices on the remote-boot target. v NoVESA: disables all the graphical interface on the remote-boot target. v NoAPM: disables advanced power management on the remote-boot target. v Unicast: uses unicast instead of multicast when downloading files from the provisioning server. v NoIGMP2: disables IGMP version 2 to force using IGMP version 1 on the remote-boot target. v NoUDMA: disables UltraDMA support for all IDE hard-disks on the remote-boot target. This can solve problems on poorly designed hardware or buggy chipsets, but at a high cost in terms of performance. v NoProtPart: disables ATA-5 features. v RealModeDisk: disables enhanced disk access. v RealModePXE: disables enhanced PXE access. v RoutePXEIRQ: reroutes network IRQ separately from the disk controller IRQ.
475
Example
DefaultOptions admin
DefaultPXEBootMode Name DefaultPXEBootMode Selects default PXE boot behavior. Synopsis DefaultPXEBootMode { normal | hdboot | ignore } Location in the OS configuration rembo.conf: Beginning of the file. Description This option defines how the provisioning server answers PXE boot requests coming from unknown targets. When mode is normal, the provisioning server processes the boot request. When mode is hdboot, the provisioning server tells the unknown target to immediately boot on the hard disk. When mode is ignore, the provisioning server does not answer the boot request, thus giving the opportunity for another PXE server to answer. Example
DefaultPXEBootMode normal
DefaultResolution Name DefaultResolution Default screen resolution for new targets. Synopsis DefaultResolution " path " Location in the OS configuration v web interface : Not available v rembo.conf: Beginning of the file. Description This parameter defines the default screen resolution for target on a new target. Example
DefaultResolution "800x600"
DisableBOOT Name DisableBOOT Disables PXE services Synopsis DisableBOOT Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description Use this option to disable the PXE component of the provisioning server. Targets are not able to boot on PXE anymore if this option is included in the configuration file. Use this option if you want to use the provisioning server for remote file access only (for example when setting up the server). Not included in the default configuration.
476
Example
DisableBOOT
DisableContextualMenu Name DisableContextualMenu Disables the specific contextual menus in the web interface. Synopsis DisableContextualMenu Location in the OS configuration v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable the specific contextual menus in the web interface. This can be useful if you want access to the regular contextual menu of your Web browser, in order, for example, to view the source page. Not included in the default configuration. Example
DisableContextualMenu
DisableCookies Name DisableCookies Disables the use of cookies in the web interface. Synopsis DisableCookies Location in the OS configuration v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you do not want the web interface to memorize your local preferences such as window positions using local cookies. Disabling cookies does not prevent you to use any essential function of the web interface. Not included in the default configuration. Example
DisableCookies
DisableDHCPProxy Name DisableDHCPProxy Disables answers to DHCP discovers (DHCPProxy). Synopsis DisableDHCPProxy yes/no Note: In rembo.conf configuration, the keyword DisableDHCPProxy is used without argument. If the keyword is present, it is assumed to be set to the value yes automatically. Location in the OS configuration.
477
v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description If this parameter is set to yes, the provisioning server does not send PXE replies to DHCPDISCOVER packets sent by remote-boot targets. You can set this parameter to yes if you do not need this feature because either the DHCP server and the provisioning server are on the same target, or you are using PXE multicast discovery. The default value is false (that is DHCP Proxy is enabled by default). Example
DisableDHCPProxy
DisableDragAndDrop Name DisableDragAndDrop Disables the drag-and.drop feature of the web interface. Synopsis DisableDragAndDrop Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable the drag-and-drop feature of the web interface. This can be useful in case of severe incompatibility with unsupported browsers. Note that the feature in known to work on most common browsers. Not included in the default configuration. Example
DisableDragAndDrop
DisableFILE Name DisableFILE Disables FILE components of the provisioning server. Synopsis DisableFILE Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the File access module section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable the FILE component of the provisioning server. This can be useful if you are accessing the server from TCP targets. Note: Do not set this option if targets are booting on this provisioning server. If you set DisableFile, you must also set DisableTCP. Not included in the default configuration.
478
Example
DisableFILE
DisableHTTP Name DisableHTTP Disables the console. Synopsis DisableHTTP Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable the HTTP component of the provisioning server, that is the web interface. Disabling HTTP is not recommended as it forces you to run the server in command-line only. If you set DisableHTTP, you must run the -c command line option to change server parameters. Note: A full Tivoli Provisioning Manager for OS Deployment server restart is necessary when this parameter is modified. Not included in the default configuration. Example
DisableHTTP
DisableHTTPOptim Name DisableHTTPOptim Disables the web interface. Synopsis DisableHTTPOptim Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to prevent the web interface to group JavaScript, stylesheet, and image files into large files to reduce HTTP traffic. Note: If you are creating console pages, you must disable set this parameter to disable optimization. Not included in the default configuration. Example
DisableHTTPOptim
DisableJSDropDown Name DisableJSDropDown Disables JavaScript menus in the web interface.
479
Synopsis DisableJSDropDown Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable enhanced drop-down menus in the web interface, and use standard drop-down selectors instead. Note that standard drop-down selectors do not respect DHMTL layers under Internet Explorer, resulting in strange effects. Not included in the default configuration. Example
DisableJSDropDown
DisableNBP Name DisableNBP Disables NBP services. Synopsis DisableNBP Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Network Boot Module section. v rembo.conf: Beginning of the file. Description Including this option in the configuration file causes the NBP component of the provisioning server to stop answering requests coming on the NBP port. Do not set this option if your server is used by targets. Not included in the default configuration. Example
DisableNBP
DisableSSL DisableSSL Disables SSL encryption. Synopsis DisableSSL Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description Add this option to the configuration file if you want to disable the SSL encryption and use unencrypted HTTP connections. This can be useful if you want a faster download time, but it is not as safe.
480
Note: A full Tivoli Provisioning Manager for OS Deployment server restart is necessary when this parameter is modified. Not included in the default configuration. Example
DisableSSL
DisableTCP Name DisableTCP Disables TCP services. Synopsis DisableTCP Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the File access module section. v rembo.conf: Beginning of the file. Description This option disables the TCP component of the provisioning server. You can include this option with caution if you are not using server replication Note: Do not set this option if targets are booting on this server. If you set DisableTCP, you must also set DisableFile. Not included in the default configuration. Example
DisableTCP
FileMCASTAddress Name FileMCASTAddress Multicast address used for the MCAST protocol. Synopsis FileMCASTAddress ip-addr:port FileMCASTAddrCount number Location in the OS configuration. v web interface: Not available. v rembo.conf: Beginning of the file. Description FileMCASTAddress defines the destination multicast address and destination port used by the provisioning server when sending multicast UDP datagram to targets requesting a file with the MCAST protocol. The default value is 239.2.0.1:10000. FileMCASTAddrCount defines the upper limit of the multicast address range used by the server (that is the number of different multicast addresses used). When combined with FileMCASTAddress, this parameter can control the lower and upper limits of the range of multicast addresses used by the server. The default value is 256 (that is use no more than 256 multicast addresses). The MCAST protocol is used by targets to download large files from the server. This protocol is a proprietary protocol made using multicast UDP. Example To force the provisioning server to use 1000 multicast addresses starting at 232.1.1.1, use:
481
FileMCASTAddress 232.1.1.1 FileMCASTAddrCount 1000
FileMCASTEncrypt Name FileMCASTEncrypt Encrypts MCAST datagrams. Synopsis FileMCASTEncrypt Location in the OS configuration. v web interface: Not available. v rembo.conf: Beginning of the file. Description If this parameter is present in a rembo.conf configuration file, or set to yes in the web interface, MCAST datagrams exchanged between the provisioning server and the remote-boot targets are encrypted. The MCAST protocol is used by targets to download large files from the server. This protocol is a proprietary protocol made using multicast UDP. MCAST datagrams are not encrypted by default. Example
FileMCASTEncrypt
FileServerPort Name FileServerPort Port used on the server for NETfs and MCAST requests. Synopsis FileServerPort port Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the File access module section. v rembo.conf: Beginning of the file. Description This value is used by the provisioning server as the port for all file-related requests sent by targets. File-related requests include NETfs requests and MCAST requests. The default value is 4013. The value of this parameter is sent to targets during the NBP phase of the boot process. If you change this parameter, targets automatically use the new value on next boot. Example
FileServerPort 5013
HTTPAdminName Name HTTPAdminName Username of the main administrator of the provisioning server. Synopsis HTTPAdminName " username " Location in the OS configuration.
482
v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of file. Description This is the superuser name intended to be used only by the main provisioning server administrator, in order to get access to the all configuration parameters of the server. There is only one superuser login. Example
HTTPAdminName "Admin"
HTTPRole Name HTTPRole Security roles with access to the web interface console. Synopsis HTTPRole "RoleName"{ Members "membername" [,...] Allowpages "pagename" [,...] Allowgroups "groupname" [,...] Policies "policyname" [,...] } Location in the OS configuration. v web interface: Not available. v rembo.conf: After global parameters. Description An HTTP role allows specific members to access predefined pages on the web interface, as well as preselected administrative groups. One can also define security policies. Parameters are a single string or a list of strings separated by commas. The star * means all, without restriction. Role members can be either individuals or groups defines by the authentication authority. An individual, who does not belong to any role, trying to log on to the web interface is denied access to the console. An individual, belonging to several roles, cumulates the page access rights and administrative group access rights of all the roles s/he belongs to. Security policies are also cumulative, resulting in a more restrictive policy when an individual belongs to several roles. The security policies include: v CONF_RO to deny changes to the server configuration. v HOST_RO to deny addition and removal of targets. To use HTTPRole, you must first have set a local authentication domain named HTTP with ( )AuthLocalDomain. Example
HTTPRole "RestrictedAccess" { Members "rembo" Allowpages "*" AllowGroups "local1", "local2" Policies "HOST_RO" }
HTTPServerPort Name HTTPServerPort TCP port for HTTP requests. Synopsis HTTPServerPort port Location in the OS configuration.
483
v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description This is the TCP port used by the web interface when listening for unencrypted HTTP requests. You can set this parameter to 8080 if you want the web interface to be accessible by typing the server hostname in your Web browser. The provisioning server always listens on this port even if connections are encrypted, in order to redirect unencrypted connections to the encrypted TCP port. Note: A full Tivoli Provisioning Manager for OS Deployment server restart is necessary when this parameter is modified. Example
HTTPServerPort 8080
HTTPSServerPort Name HTTPSServerPort TCP port for encrypted HTTP requests (SSL). Synopsis HTTPSServerPort port Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description This is the TCP port used by the web interface when listening for encrypted HTTP requests. You can set this parameter to 443 if you want the web interface to be accessible by typing the server hostname in your Web browser, prefixed with the https URL syntax. Note: A full Tivoli Provisioning Manager for OS Deployment server restart is necessary when this parameter is modified. Example
HTTPSServerPort 443
HTTPSessionTimeout Name HTTPSessionTimeout Time in minutes before a web interface session expires. Synopsis HTTPSessionTimeout minutes Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the web interface section. v rembo.conf: Beginning of the file. Description This is the inactivity timeout (in minutes) before web interface users are automatically logged
484
out. A typical safe value is 5 minutes, but you might want to make it longer if you receive the message Session timed out too often and are sure that you will not forget to log out when you leave your computer. Example
HTTPSessionTimeout 30
Interfaces Name Interfaces List of network interfaces used by the provisioning server. Synopsis Interfaces ip-addr1 [ ip-addr2 ] [ ip-addr3... ] Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Base Parameters section. v rembo.conf: Beginning of the file. Description You will find this option very useful if you are running on a multihomed computer (that is a target with more than one network card, or with a network card and a dial-up adapter). This option lets you specify the list of network interfaces used by the provisioning server when receiving and sending packets to targets. If you leave this option unset, the server uses the network interface corresponding to the official hostname of the server. You must specify a list of IP addresses to use. Each IP address must correspond to the IP address to one of the network interfaces of the provisioning server. The list must contain at least one address. Note: You are strongly encouraged to set this option if your computer is multihomed. Otherwise the server might not receive the network packets not originating from its official interface. Examples
Interfaces 192.168.1.1 Interfaces 192.168.1.1 192.168.10.1 10.1.1.1
MaxLogSize Name MaxLogSize Maximum size of log files created by the provisioning server. Synopsis MaxLogSize size_in_bytes Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Base parameters section. v rembo.conf: Beginning of the file. Description This parameter can be used to limit the size of the log file generated by the provisioning server. The maximal log size must be specified in bytes, and apply to all the log files created by the server (file, nbp, http, tcp, VM, and boot). If you do not specify this parameter, or set the limit to 0, then log files are not limited in size. Example
485
To limit the size of logs to 10MB:

MaxLogSize 10000000
To disable log size limit:

MaxLogSize 0
MaxPCASTSessions Name MaxPCASTSessions Maximum number of simultaneous PCAST sessions. Synopsis MaxPCASTSessions number Location in the OS configuration. v web interface > : Not available v rembo.conf: Beginning of the file. Description This is the maximum number of PCAST sessions that the provisioning server accepts simultaneously. This parameter is mostly relevant if the server is running in UNICAST mode and deploying a group with UNICAST setting. The default value is 8. Because each session uses around 16MB of server memory, higher values must be avoided on servers with no more than 256Mb. Example
MaxPCASTSessions 8
MaxTFTPSegSize Name MaxTFTPSegSize Maximum size of a TFTP segment. Synopsis MaxTFTPSegSize number Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description This is the maximum size of TFTP segment in bytes. This parameter can be used to reduce the size of packets sent by the provisioning server if required by the underlying network. This can be useful for instance when network traffic is encrypted by routers. The default value is 512. Example
MaxTFTPSegSize 256
MTFTPClients Name MTFTPClients The destination address and port used by the MTFTP server. Synopsis MTFTPClients ip-addr [: port ] Location in the OS configuration.
486
v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description This is the destination IP address and port used by the server when sending multicast MTFTP datagrams to boot agents. The IP address must be a valid multicast address and must match the address sent to the target during the DHCP phase. If the deployment engine has received its PXE parameters from the provisioning server during the DHCP phase, this address is automatically included so that the deployment engine always uses the same address/port as the server. The default value is 232.1.0.1:8500. Example
MTFTPClients 232.8.7.6
MTFTPPort Name MTFTPPort The port used by the MTFTP server. Synopsis MTFTPPort port Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description This is the port used by the server when listening to MTFTP requests. If the remote-boot targets are using the provisioning server to get their PXE parameters, this value is sent in the DHCP/PXE reply so that the remote-boot target always uses the correct port. The default value is 4015. Example
MTFTPPort 5015
MTFTPStartDelay Name MTFTPStartDelay The initial delay on target computers before sending first MTFTP request. Synopsis MTFTPStartDelay secs Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Boot module section. v rembo.conf: Beginning of the file. Description This is the delay used by remote-boot targets before sending the first MTFTP request to the provisioning server. This delay is used by the target to listen to an existing MTFTP transfer. If the MTFTP file they are about to request is already being sent by the server on the multicast address, then the target does not request the file and listens to the packets. The longer this
487
delay is, the more probability you have that many targets reuse the same MTFTP channel instead of requesting the file. But if you want to have a fast boot process, you must set this value to 1 (the minimum value). The default value is 2 (seconds). Example
MTFTPStartDelay 1
NBPServerPort Name NBPServerPort Port used on the provisioning server for NBP requests. Synopsis NBPServerPort port Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Network Boot module section. v rembo.conf: Beginning of the file. Description This value is used by the provisioning server as the port for all NBP requests sent by remote-boot targets. NBP is a protocol used by target computers to get their startup parameters (startup page, groupname,...) and to send authentication requests to the server. The default value is 4012. The value of this parameter is sent to targets as part of the last MTFTP packet when the server sends the initial part to the PXE bootrom. If you change this parameter, targets automatically use the new value on next boot. Example
NBPServerPort 5012
NetPassword Name NetPassword Network password for remote file access. Synopsis NetPassword " password " Location in the OS configuration. v web interface: Not available. v rembo.conf: Beginning of the file. Description This is the password used by the provisioning server to accept or deny network requests coming from a target, the web interface or NetClnt. You must change this option when you install a new provisioning server and select a password to protect your files against unpermitted access. If you are using the Windows version of the server, you are asked to enter the password during the setup. If you are using the web interface, or NetClnt to access the files stored in your provisioning server, the password you enter in NetClnt (or the web interface) must match the word set in NetPassword. Note: This password is an important piece of your security. If you require optimal security, you are strongly encouraged to protect the configuration of the server. By default, this file is created by the installer and the password is stored encrypted in it.
488
Example
NetPassword "mypassword"
NetworkShare Name NetworkShare UNC path of the shared partition directory of the provisioning server. Synopsis NetworkShare "path " Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Network Share Module section. v rembo.conf: Beginning of the file. Description This is the path of the shared partition directory of the provisioning server. This parameter can be used to increase the deployment speed of some operating systems. The target computer access the network share directly to retrieve the necessary installation files. You need to have set the partition as read-only for the user entitled to access the network share. Example
NetworkShare "provisioningServer/partition"
NetworkUser Name NetworkUser name of a user entitled to access the network share. Synopsis NetworkUser "name " Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Network Share Module section. v rembo.conf: Beginning of the file. Description The name of the user entitled to access the network share, which is given in NetworkShare. If the user is part of a domains, you must use the syntax Domain/User. This user name is used by the targetcomputer to access the network share on the provisioning server. Example
NetworkUser "ClientComputer"
NetworkPasswd Name NetworkPasswd Network password used by the target computer to access the network share. Synopsis NetworkPasswd "password " Location in the OS configuration. v web interface: Click Go To > Deployment > OS Management > Boot Servers.. Then click the Tivoli Provisioning Manager for OS Deployment boot server you want to work with, click the Configuration tab and click Edit in the Network Share Module section. v rembo.conf: Beginning of the file.
489
Description This is the password used by the target computer to access the network share located on the server, using the NetworkUser user name. The password is stored in the rembo.conf file. Example
NetworkPasswd "clientPassword"
TCPServerPort Name TCPServerPort Defines the TCP port used. Synopsis TCPServerPort port Location in the OS configuration. v web interface: Not available. v rembo.conf: Beginning of the file. Description This option defines the TCP port used by the TCP component of the provisioning server when listening to requests coming from other servers. The default value is 4013. Example
TCPServerPort 2048
Hardware compatibility list

The list of certified compatible hardware for Tivoli Provisioning Manager for OS Deployment is provided as a Tivoli technote on the IBM web site. The hardware listed in Table 57 on page 380 to Table 65 on page 383 are known to work with Tivoli Provisioning Manager for OS Deployment.
Table 72. IBM servers Machine Type 7971 7972 7981 7996 8853 8832 8843 8839 8850 8886 8835 8848 8486 8480 8482 8485 Model IBM BladeCenter LS21 BladeCenter LS41 BladeCenter HS20 BladeCenter HC10 BladeCenter HS21 BladeCenter HS20 BladeCenter HS20 BladeCenter HS40 BladeCenter LS20 BladeCenter S eServer 325 eServer 326 IBM xSeries 100 xSeries 205 xSeries 206 xSeries 206m
Tested BIOS level BAJT22A BAJT22A FEE110A DOJT16A BCJT16A BSJT26A BWJT27A SBJT62A BKJT23F BCJT16A M1JT36A M2JT28A IJJT28C JPJT53A KEJT40A PAJT24A
490
Table 72. IBM servers (continued) Machine Type 8647 8649 8648 8671 8841 8685 8865 8673 8836/8849 8849 8676 8837 8670 8840 8863 8870 8872 4347 4362 4363 4364 4365 7973 7984 7977 7978 7979 7985 8877 8866 8864 8878 Model xSeries 225 xSeries 225 xSeries 226 xSeries 235 xSeries 236 xSeries 255 xSeries 260 xSeries 305 xSeries 306 xSeries 306m xSeries 335 xSeries 336 xSeries 345 xSeries 346 xSeries 366 xSeries 445 xSeries 460 System x3105 System x3200 System x3200 System x3250 System x3250 System x3400 System x3455 System x3500 System x3550 System x3650 System x3655 System x3755 System x3800 System x3850 System x3950* Tested BIOS level OPJT50A OQJT14A PMJT66C GRJT57A NRJT34A AVJT26A ZUJT65A PLJT68A KEJT40A PAJT42A T2JT39A APJT37A GEJT63A KPJT41A ZUJT65A REJT49A ZUJT65A A2JT19A G8JT29A G8JT29A G9JT26A G9JT26A SPJT52A C0JT35A SPJT52A GFE29B GGE29B C2JT28A ZYJT29A ZTJT10A ZSJT10A ZTJT13A
Table 73. IBM workstations Machine Type 6225 9229 Model IBM IntelliStation M Pro IntelliStation M Pro FIJT41A GVJT26A Tested BIOS level
491
Table 74. Lenovo mobile and desktop computers Machine Type ThinkCentre ASI ThinkCentre SSO ThinkPad R52 ThinkPad T30 ThinkPad T41 ThinkPad T42 ThinkPad T60 ThinkPad T60p ThinkPad X31 ThinkPad X60 Table 75. IBM Point of Sale computers Machine Type 4851-514 4810-33H 4838-137 4840544 4800-722 4800-782 4836-132 4846-565 4800-743 4800-723 4838-520 4838-720 Table 76. IBM storage servers Name IBM TotalStorage DS4100 (formerly FAStT100) IBM TotalStorage DS4300 (formerly FAStT600) IBM TotalStorage DS4400 (formerly FAStT700) IBM TotalStorage DS4500 (formerly FAStT900) FAStT EXP500 Storage Expansion Unit Table 77. Ethernet adapters Part number 06P3601 06P3801 08K3124 FRU number 06P3609 06P3809 08K3125 Name IBM 10/100 Ethernet Server Adapter Intel PRO/100 SP Mobile Combo adapter IBM 10/100 EtherJet Mini PCI adapter with 56K modem (Intel current card) WoL Yes Yes Yes 1724-100 1722-1RU 1742-1RU 1742-90U 3560-1RU Model number IBM SurePOS 500 SurePOS 300 Anyplace Kiosk SurePOS 500 SurePOS 700 SurePOS 700 Anyplace Kiosk SurePOS 500 SurePOS 700 SurePOS 700 AnyPlace Kiosk AnyPlace Kiosk Model Tested BIOS level HHKT130 8BKT120 8AKT111 X7KT100 82KT130 83KT130 8AKT111 X6KT142 85KT027 85KT027 8DKT100 8DKT100 Model 8105, 8107, 8109, 8117, 8119, 8121 8086 1859-B7U 2366-N6G 2373-3JG 2373-FWG 1951-A47 2007-83U 2672-C8G 1706-AA7
492
Table 77. Ethernet adapters (continued) Part number 08L2565, 08L2567 09N3609 09N9774 09N9901 22P4501 22P4701 26P8039 31P6301 31P6401 34L0201 34L1101, 34L1110 34L1201, 34L1210 34L4401 (3DES US) 34L4410 34L4501 (DES non-US) 34L4510 85H9921, 85H9930 85H9921, 85H9930 Ships with system Ships with system Ships with system Ships with system FRU number 08L2566 09N3609 00N8117 09N9901 22P4509 22P4709 26P8069 31P6309 31P6409 30L5929 34L1109 34L1209 34L4409 not available Name IBM 10/100 EtherJet PCI Adapter with Wake on LAN1 10/100 EtherLink PCI Management Adapter by 3Com IBM 10/100 EtherJet miniPCI adapter with 56K modem by 3Com 10/100 EtherLink Server Adapter by 3Com Intel PRO/100S Desktop Adapter Intel PRO/100S Low Profile Desktop Adapter Ethernet Daughter Card IBM NetXtreme 1000 T Ethernet Adapter IBM NetXtreme 1000 T Dual Port Ethernet Adapter IBM 10/100 EtherJet PCI Adapter with Wake on LAN1 IBM 10/100 EtherJet PCI Adapter with IBM Alert on LAN 2 IBM 10/100 EtherJet PCI Management Adapter IBM 10/100 EtherJet Secure Management Adapter IBM 10/100 EtherJet Secure Management Adapter WoL Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes Yes Yes
85H9928 85H9928 not available not available 26P8100 not available
IBM 10/100 EtherJet PCI Adapter with Wake on LAN1 IBM 10/100 EtherJet PCI Adapter with Wake on LAN1 Intel Gigabit Copper (82543) PRO 1000 XT Intel Gigabit Copper (82544) PRO 1000 XT IEEE 1394/LAN Combo Card On board Ethernet Adapter for ThinkPad R30
Yes Yes Yes Yes Yes Yes
Table 78. IBM ServeRAID controllers Name ServeRAID-8i controller ServeRAID-8s controller Winterhaven, MegaRAID 8480 SAS controller ServeRAID-4Mx Ultra160 SCSI controller ServeRAID-4Lx Ultra160 SCSI controller ServeRAID-5i Ultra320 SCSI controller ServeRAID-6M Ultra320 SCSI controller ServeRAID-4H Ultra160 SCSI controller ServeRAID-6i Ultra320 SCSI controller Part number 13N2227 39R8765 39R8850 06P5736 06P5740 25P3492 32P0033 37L6889 71P8595 FRU number 13N2233 39R8785 39R8852 06P5737 06P5741 32P0016 02R0985 37L6892 71P8627
493
Table 78. IBM ServeRAID controllers (continued) Name ServeRAID-7k Ultra320 SCSI controller ServeRAID-7t SATA controller ServeRAID-7e (Adaptec HostRAID) controller ServeRAID-8e controller ServeRAID-8k SAS controller LSI MegaRAID SAS 8408E controller LSI 1068 controller Table 79. LSI RAID controllers Name LSI-SAS RAID controller (Sanford) Single Channel LSI Ultra320 SCSI controller Dual Channel LSI Ultra320 SCSI controller LSI MegaRAID IDEal RAID controller Table 80. BladeCenter-related products Name SAS Expander Switch Module SAS 2-port CFFv daughter card Qlogic 4Gb SFF Qlogic 4Gb Std Emulex 4Gb SFF Fibre Channel Expansion Card IBM BladeCenter Optical Pass-Thru Module Cisco Gigabit Ethernet Switch module Cisco Fiber Switch Module IBM BladeCenter Advanced Management Module (AMM) IBM BladeCenter PCI Expansion Unit (PEU) IBM BladeCenter HS20 Fibre Channel Expansion Card - Short Form Factor IBM BladeCenter 6-pt Fibre Channel Switch Module Qlogic iSCSI Expansion Card for IBM BladeCenter Nortel Copper L2/L3 Switch Module Nortel Fibre L2/L3 Switch Module QLogic 4 Gb Fibre Channel Switch Module Brocade 20 Port FC switch module IBM BladeCenter HS20 Fibre Channel Expansion Card IBM BladeCenter 2-Port Fibre Channel Switch Module Myrinet Cluster Expansion Card for IBM BladeCenter IBM BladeCenter Copper Pass-Thru Module IBM BladeCenter Gigabit Ethernet Expansion Card Part number 39Y9192 39Y9187 26R0890 26R0884 39Y9186 02R9080 13N2281 13N2285 25R5778 25K8373 26K4841 26K6477 26K6487 26K6530 26K6531 26R0883 32R1812 48P7061 48P7062 73P6000 73P6100 73P9030 FRU number 39Y9193 39Y9188 26R0893 26R0889 n/a 02R9082 13N2285 13N2286 25R5777 32R0753 26K4859 26K6481 26K6490 26K6526 26K6529 26R0888 32R1820 59P6624 59P6621 73P6001 73P6098 13N2306 (replaces 73P9031) 25R8060 LSI53C1020 LSI53C1030 LSI MegaRAID IDEal RAID Part number Part number 71P8642 71P8648 n/a n/a 25R8064 39R8850 25R8060 FRU number 71P8644 71P8650 n/a n/a 25R8064 n/a n/a
494
Table 80. BladeCenter-related products (continued) Name Nortel Network Layer 2-7 GbE Switch Module for IBM BladeCenter Intel Copper Switch Module IBM BladeCenter PCI Expansion unit (PEU) Part number 73P9057 90P3686 90P3721 FRU number 73P9004 90P3776 n/a
495
496
Chapter 6. Managing images in the image library

The image library is a catalog of all the images in your provisioning environment. The image library features three applications: 1. Master Images Master images are used to provision computers and virtual servers. The images contain hardware and software resources. You can create many versions of a master image and deploy the images on multiple computers. Each time you deploy an image, an instance image is created. The instance image represents the computer that has been created and its relationship with the master image that was used to create it. Master images can be simple or composite. A composite image contains several member master images. When you deploy a composite master image, one virtual server is created for each member master image contained in the composite. 2. Saved Images Saved images are used to preserve a particular state of a virtual server. You can create many saved images of a virtual server and these images are grouped and associated only with that virtual server. Use the saved images to restore a deleted virtual server, or to return an existing virtual server to a previously saved state. 3. Image Repositories This application contains details about the repositories where images are kept, and also provides a view of the contents of these repositories. An image repository can contain master images, saved images, instance images, or any combination of these three types. The following types of image repositories are supported: VMware, KVM, PowerVM, and VMControl repositories. There are distinct differences between master images and saved images.
Table 81. Comparison of master images and saved images Master images Supported systems v Physical computers v Virtual servers Type of image Depersonalized v Master images are templates of existing computers. They can contain hardware resources and software resources that can be customized before the master image is deployed. Deployment Personalized v Think of a saved image as a backup of the virtual server. When you restore a saved image to a virtual server, you replace the entire system. v The resources of the saved image cannot be changed. v Completely replaces, or creates, the virtual server. A saved image is only associated to the virtual server that it was created from. Saved images remain in the provisioning database when the virtual server is deleted and can therefore be used to re-create the virtual server at a later time. Saved images v Virtual servers
v Create a computer. The master image must contain hardware resources and software resources. v Deploy on an existing computer. The master image contains only software resources.
497
Image library basics

Find out more about what image library basics are all about, who the primary users are, and what are the key examples and terms that you need to know about this feature. Review the troubleshooting information and the log files names and location for this feature and also additional resources that help you complete your image library tasks. Learn more about the image library, who the primary users of the library are, and what are the key examples and terms that you must know about this feature. v Process v v v v v v User roles Requirements on page 499 Key terms on page 500 Troubleshooting on page 501 Log files on page 501 Resources on page 501
Process
Master images contain the hardware configuration and software resources required to fully provision a computer, while saved images are backups of various states of your virtual server. To learn about the differences between master images and saved images, see the comparison table in Chapter 6, Managing images in the image library, on page 497. For more information about the Master images and Saved images process, see v Master images on page 504 v Saved Images on page 517
User roles
You must be assigned to the appropriate user role to use the image library.
Table 82. User roles Role Provisioning Administrator Description v Publishes and unpublishes master images and saved images. Skills v Knowledge of boot server technologies. v Knowledge of virtualization technologies. For example, VMware, KVM, PowerVM, and VMControl. Deployment Specialist v Deploys master images. v Restores saved images to re-create deleted virtual servers. v Restores saved images to return an existing virtual server to a previous state. v Deploys OVF images. v Server management experience v Familiarity with operating system management life cycle
498
Table 82. User roles (continued) Role Provisioning Configuration Librarian Description v Registers master images to the image library by capturing the images, importing the images, or running discovery. v Synchronizes the image library with the image repositories. v Creates and deletes saved images. v Deletes virtual servers. v Edits the configuration of master images. Skills Knowledge of provisioning server configuration and boot server technologies.
Requirements
v User roles and requirements on page 501 v Configuring an image repository on page 502 v Software prerequisites for composite images on page 511
Chapter 6. Managing the image library
499
Key terms
composite image An image that contains multiple member images. host platform server A physical server that has hosting capabilities for virtual servers. image A representation of a computer program and its related data, such as the kernel, file systems, libraries, and programs of the managed system at a particular time.
image repository The managed system where the image is physically located. Each repository has a synchronization operation which updates the entries in the image library. image revisions Identifies versions of the same master image. When you change an instance image, or capture a master image from that instance, a revision of the original master image that was used to create that instance image is created. You can use the revision to update the existing instances to the new version. instance image A deployment of a master image or a saved image. Hardware and software properties are customized during the deployment process. The instance image references the customized values. There is a direct association between an instance image and a provisioning computer in the database. The instance image reflects any changes made to the initial virtual server configuration. master image A depersonalized image that acts as a template containing both hardware and software configurations. Use a master image to deploy multiple virtual servers. Master images can be simple or composite. A simple image is an individual image. A composite image is an image that contains multiple member images. member image An image that is included in a composite image. mount point The association between a repository and a host platform server. This relationship is used to filter out the repositories that are unavailable for a specific host platform server OVF (Open Virtualization Format) A platform independent open standard for packaging and distributing virtual appliances. saved image Saved images are backups of a state of a virtual server at a given point in time. Use saved images to restore the actual content of the virtual server, as it was defined at the time when the saved image was created. You can have multiple saved images for a virtual server. Saved images are saved in groups. If a virtual server is deleted, use a saved image to restore it to the desired state. software stack A list of software products, organized in the required installation order. A software stack can contain individual pieces of software and other software stacks. virtual server A server that shares its resources with other servers to support applications. virtual server template A template on which a virtual server is based. The virtual server is allocated using the hardware requirements of the template.
500
Troubleshooting
v Log files on page 522 v Troubleshooting image library management on page 522 v Messages v Search the IBM Support Portal v Contacting support
Log files
Follow the steps below and review the indicated log files to recover from problems that you might encounter when managing entries in the image library: v Problems with saved images v Image repository problems on page 523 v Master image problems on page 523
Resources
To learn more about managing image entries in the image library, refer to one of the following resources: v Master images on page 504 v Composite images on page 510 v Saved Images on page 517 v Publishing an image on page 520 v For a description of a field in the interface, click Alt+F1.
Related links Chapter 6, Managing images in the image library, on page 497 Requirements Troubleshooting image library management on page 522
Requirements
Before you begin using the image library, ensure that the image repositories are configured and synchronized.

To perform image management tasks in the image library, ensure that you have the required knowledge and access rights to perform your role.
Table 83. User roles Role Provisioning Administrator Description v Publishes and unpublishes master images and saved images. Skills v Knowledge of boot server technologies. v Knowledge of virtualization technologies. For example, VMware, KVM, PowerVM, and VMControl.
501
Table 83. User roles (continued) Role Deployment Specialist Description v Deploys master images. v Restores saved images to re-create deleted virtual servers. v Restores saved images to return an existing virtual server to a previous state. v Deploys OVF images. Provisioning Configuration Librarian v Registers master images to the image library by capturing the images, importing the images, or running discovery. v Synchronizes the image library with the image repositories. v Creates and deletes saved images. v Deletes virtual servers. v Edits the configuration of master images. Knowledge of provisioning server configuration and boot server technologies. Skills v Server management experience v Familiarity with operating system management life cycle
Configuring an image repository

Set up an image repository so that it points to the path on a managed system. The image repository location represents the physical location on the managed system where the images are stored. The location must be configured before you create saved images or instance images. The following types of image repositories are supported: 1. VMFS 2. KVM 3. PowerVM 4. VMControl For each image repository, the following types of images are supported: v Master images v Saved images v Instance images You can enable all the types of images on each image repository, or if you want to organize your repositories by image type, you can enable only one type of image on each repository. For example, if you want to have an image repository that contains saved images only, enable saved images for that repository but do not enable master images or instance images. When you create saved images, that repository can be selected, but when you create a master image or an instance image, that repository is not available as a repository option.
Creating an image repository

Create image repositories so that you can create master images, instance images, and saved images. Manually creating an image repository is only required for PowerVM and KVM.
502
For VMware, the image repository is created when you run the VMware Virtual Center Discovery. The information discovered from the datastores in the VirtualCenter populates the image repository. Similarly for VMControl, the image repository is created during the discovery process. For a KVM file-based boot server, the image repository is automatically created when you install the boot server. This image repository is only master images enabled by default. If you need to create an image repository which is saved images enabled or instance images enabled, you must create it manually. To manually create a PowerVM or KVM image repository, complete these steps:
Procedure
1. Click Go To > IT Infrastructure > Image Library > Image Repositories. 2. From the Select Action menu, select PowerVM or KVM as the type of image repository that you want to create. 3. Type a name for the Repository. You can also add a Description. 4. Optional Type a value for the Available Space and Total Space. These values represent the deallocated space and total space on the image repository. 5. Select which type of image you want to save in this repository. If you want to save all types of images, select all of the check boxes: v Master Images Enabled v Saved Images Enabled v Instance Images Enabled If you do not select all of the image types, only the image type that you enable can be added to the image repository. When you create an image, the repository options are filtered by the type of images that you have enabled. 6. Click Submit to save your changes and create the image repository. 7. From the List tab, select the repository that you created. 8. On the Repository tab, click New Repository Location. and select the computer, or (only for PowerVM repository) the managed system ID of the 9. Click NIM boot server, where the images will be physically located. Click OK. 10. For KVM, VMFS, and VMControl image repositories, a section called Mount Points is present. PowerVM does not use mount points. The mount point is the association between the repository and the host platform server. The location can be on any accessible remote managed system that can store the virtual files. The mount points for VMFS are automatically configured by the VMware Virtual Center Discovery. The mount point for VMControl is also automatically configured by its discovery process. For file-based KVM boot server, the mount point is automatically associated to the image repository with the file-based boot server. For KVM-OVF and the KVM image repository that is manually created, the mount point must be manually configured. Click New Mount Point. 11. In the Mount Point field, type the path to the mount point. The path value is the path to the managed system from your local computer. Note: Ensure that you specify a different directory from where your KVM virtual servers are created. Sharing a directory structure for virtual servers and master images is not supported.
Results
The image repository is now created and configured.
What to do next
The next step is to synchronize the image repository.
503
Master images
Master images contain the hardware configuration and software resources required to fully provision a computer. Master images can be thought of as templates. They can be created in the following ways: 1. Captured from existing computers in the provisioning database (non-native images). 2. Discovered from the virtualization technology (native images). For example, VMware templates are created in the VirtualCenter and are discovered by the provisioning server and added to the image library as master images. 3. With Tivoli Provisioning Manager for OS Deployment, creating an unattended image using installation media such as CDs or DVDs. 4. Importing an OVF package. An important feature of master images is the ability to create versions. Whenever you capture a master image, a version is assigned to the image. Each new image that you capture can be associated to the original master image in a parent-child relationship, or you can start a new version sequence. This diagram illustrates the functionality of the version feature.
Server 1
Capture 1
Capture 2
Create revision?
Yes
No
Master image 1.1
Master image 1.2
New master image 1.1
Master image 1.1.2.1
Deploy
Capture 3
Server 2
504
1. Capture 1. A master image is captured from Server 1. It is the first master image of Server 1, so version 1.1 is assigned to the master image. 2. Capture 2. A second master image is captured from Server 1. A decision is required on whether you want to create a revision of master image 1. v Create revision: If you create a revision of master image 1, version 1.2 is assigned to the new image and a parent-child relationship is created between the two images. v Do not create revision: If you choose not to create a revision, a new master image version 1.1 is created. The new master image does not replace the original master image 1.1 from Capture 1. 3. Deploy. Master image 1.1 is deployed to create Server 2. This is a new physical or virtual server. 4. Capture 3. A master image is captured from Server 2. Each time you create a master image, decide if you want to create a revision of the original master image. In this example, the user has decided to create a revision and has chosen master image 1.1 as the ancestor. Version 1.1.2.1 is assigned to the new master image. This is because a revision was already created of master image 1.1. If master image 1.2 did not exist, the revised master image of Capture 3 would have been called version 1.2. The version number 1.1.2.1 might seem strange at first, but the additional digits do have a meaning. The first three digits, 1.1.2, represent a new branch in the revision history of the image with version 1.1. The fourth digit represents the first version on that branch. So the version "1.1.2.1" can be read as first version of the branch 1.1.2 of the image with version 1.1."
Synchronizing the image library

The image library and the images in the repository of the virtualization technology must be synchronized so that the images can be used in the provisioning server.
Before you begin

1. Create an image repository in the Image Repositories application. The repository must be created so that the images have a direct link to the physical location on the computer. For detailed steps, see the topic called Creating an image repository on page 502. 2. For KVM and VMware, an SSH SAP must be defined on the computer where the repository is located. Manually add the SAP to the computer, or run the Initial Discovery on the computer to automatically define the SAP. To run Initial Discovery, click Go To > Discovery > Provisioning Discovery > Discovery Configurations. Select Initial Discovery from the list and follow the tabbed wizard to specify the required information and run the discovery. Important: On the Credentials tab, in the Password Credentials section, click New Row. Enter a user and choose SSH mechanism name and password. Beside the Protocol field, click Select Value selection. Using this mechanism will define the SSH SAP on the computer during the discovery. The configuration librarian typically synchronizes the image library. The image repository is the managed system where master images are physically located. For example, VMware VirtualCenter datastore is an image repository that contains VMware master images. The synchronization updates the image library with any new master images in the image repository. Master images can only be used if they are entries in the image library, so synchronizing periodically is a best practice to follow. Only master images are synchronized against the existing content of the image library. Saved images and instance images are created using the provisioning server, so they are added to the image repository when they are created. During synchronization, the following actions occur:
505
1. Add: Master images that are in the repository but are not in the image library are added to the library. 2. Remove: Master images that are in the image library but are not in the repository are removed from the library. The following types of repositories are supported: v VMFS v KVM v PowerVM v VMControl Follow these steps to synchronize the image repositories:
Procedure
1. Click Go To > IT Infrastructure > Image Library > Image Repositories. 2. Click an image repository . 3. On the Repository tab, click Synchronize Repository.
Results
All of the master images in the provisioning database that are identified as that repository type, are synchronized and added to the Image Repositories application.
What to do next
After you synchronize to add master images as entries in the image library, you can review the image information about the Master Image tab for each image. If master images are discovered, a virtual server template might not be associated to the image. This is the case for pSeries master images that are discovered by the IBM AIX NIM Discovery that runs when you click Synchronize Repository. Add a virtual server template to the master image if it does not have one.
Adding virtual server templates

To add a virtual server template to a master image, follow these steps:
Procedure
1. From the Master Images application, select the master image. > Select Value. 2. On the Master Image tab, beside Virtual Server Template, click 3. Select the virtual server template that you want to add to the master image. Important: Virtual server templates that are manually associated to a master image that is discovered are deleted if the master image record is deleted. Create a duplicate of the virtual server template before you associate the template to the master image. To duplicate the virtual server template, click Go To > IT Infrastructure > Provisioning Inventory > Virtual Server Templates. Select the virtual server template from the list. From the Select Action menu, click Duplicate Virtual Server Template. When the template has been duplicated, return to the Master Images application and associate the virtual server template to the master image.
506
Capturing master images

Capture an image of an existing computer to create a master image.
Before you begin

To capture KVM master images, the virtual servers must have a Windows or Linux operating system, and the operating system must be in the provisioning database. Run an inventory discovery on the KVM virtual server to add the operating system to the provisioning database. For detailed instructions on running an inventory discovery, see the topic called Discovering software using the provisioning Inventory discovery. Note: To prevent errors during the common agent installation on the target machine, ensure that the common agent is not installed and the Tivoli GUID is removed from the computer that you are capturing the image from. For details, see Uninstalling the common agent on page 669. Image captures can be done using a boot server or using a native host platform method. To create a master image from an existing computer, follow these steps:
Procedure
1. Click Go To > IT Infrastructure > Image Library > Master Images. 2. From the Select Action menu, click Capture Image. 3. In the Capture New Image window, type a name for the Provisioning Task or accept the default name. 4. Select the Source Computer from which to capture the image by clicking 5. In the Image field, type a name for the new master image. .
. There are three types of boot servers: NIM (LPAR), 6. Select the Boot Server Type by clicking File-Based (KVM), and IBM Tivoli Provisioning Manager for OS Deployment. The provisioning server matches the boot server type to the operating system of the source computer. The Tivoli Provisioning Manager for OS Deployment type is available for all computers, and is the only option available if the source computer does not have an operating system. 7. 8. 9. 10. . There are three types of images: Select the Image Type by clicking Accept the default Timeout value or type a new value. Click Select Boot Server and click the boot server that you want to use to capture the image. To schedule the new master image to be created, click Schedule. Accept the default value, Run Now, to create the master image immediately, or select Scheduled Start and then click the calendar button to specify the date and time that you want the virtual server to be created. Click OK. The provisioning task is launched. At the prompt, you can jump to the Provisioning Task Tracking application to monitor the task.
11.
Results
The image is captured and listed as a master image. The instance image of the source computer is updated to reflect its relationship with this new master image. Now you can use the image to deploy new provisioning computers or virtual servers, or deploy it to an existing system.
Deploying a master image to create a new virtual server

Master images contain the hardware configuration and software required to fully provision new computers. In this topic, learn how to deploy a master image to create a new virtual server.
507
Master images can be deployed on physical or virtual servers. Every master image can be deployed in two ways: 1. As a new computer, which creates a new virtual server on an existing host platform server. 2. As a software image deployed on an existing computer. Using a native host platform operation, for example, creating a virtual server using a VMware template. Follow these steps to provision a new computer:
Procedure
1. 2. 3. 4. Click Go To > IT Infrastructure > Image Library > Master Images. Select the master image that you want to deploy. From the Select Action menu, click Deploy Master Image. Select Create Server.
5. In the Virtual Server field, type a name for the new virtual server. and select a host platform server from the list. The list of 6. In the Host Platform field, click available host platform servers is determined by the existence of a software image on the master image. a. If there is a software image, the available host platforms are listed based on the guest operating system type. b. If there is no software image, the Hypervisor type is used to retrieve the list of available host platform servers. to select the Repository where the virtual server will be created. 7. Optional Click 8. Optional Type the Repository Relative Path. Important: VMware: Use the following format for the repository path:
/<Datacenter_name>/vm/<Folder_name>
If you do not include the vm reference between the Datacenter_name and Folder_name, an error occurs. 9. For OVF only, click the Map Networks tab. To specify the Host Platform Network, beside Bridge, and select the Host Platform Network. click 10. Click Edit Virtual Hardware. The minimum required hardware configurations are shown. Update the recommended values for deployment as needed. The changes to these values cannot go below the minimum value or exceed the available resources. If the resources values are changed, they are saved as a clone of the recommended virtual server template. Note: For OVF, the network interface card (NIC) cannot be changed in the Edit Virtual Hardware tab. Change are made on the Edit Software tab. See the next step for details. The Edit Virtual Hardware and Edit Software tabs do not apply to VMware master images. The hardware and software of a VMware template cannot be changed. 11. Click Edit Software. The software stack associated with the master image is cloned and displayed. If you want to change the software that is included on the master image, click software that you want to add to the image. Click OK. Tip: For OVF, to change the NIC, click ConfigNet. To change the root password, click ConfigPWD_ROOT . and select the
508
12. Click Scheduling and click Schedule to select when the master image will be deployed. Click OK.
Results
The master image is deployed to the new computer. To change the computer resources, select the computer and go to the Provisioning Computers application. To view the computers that have been provisioned using this master image, click the Instances tab. Each deployed computer is an instance of this master image. Instance images help you to understand how images are being used; you can view all the instances of a particular master image. It also helps you to see and track the master image versioning. By viewing the instance images, you can see what computer was deployed with which version of the master image. If you are recapturing that computer, you know that you can give it a new version. Instance images also help with impact analysis. If an image has a problem, you can see what instances in your provisioning database have that image.
What to do next
After the image is deployed and the computer or virtual server is used in your business environment, there will typically be some changes made to the computer, for example, additional software or patches and upgrades will be installed on the computer. After you change the computer, you can recapture an image of the changes. The new version of the image will contain these changes and can be used to deploy to more new or existing computers with the latest changes.
Creating a version of an existing image

Master image versions help to capture the activity in the life cycle of your image management process. The image versions are used to provision computers at various states. Versioning links different revisions of the same master image so that the images are related to each other. To create a version of an existing master image, follow these steps:
Procedure
1. Click Go To > IT Infrastructure > Image Library > Master Images. 2. From the Select Action menu, click Capture Image. 3. In the Capture New Image window, type a name for the Provisioning Task or accept the default name. 4. Select the Source Computer from which to capture the image by clicking 5. In the Image field, type a name for the new master image. 6. Select the Boot Server Type by clicking . .
. 7. Select the Image Type by clicking 8. Select Create Revision to verify that this image is a version of an earlier image. to select the image that you are creating a version of. The 9. Beside Ancestor Master Image, click image that you select will be the parents of this new revised child image. The version number is automatically assigned to the new image. 10. Accept the default Timeout value or type a new value. 11. Click Select Boot Server and click the boot server that you want to use to capture the image.
509
12. To schedule the new master image to be created, click Schedule. Accept the default value, Run Now, to create the master image immediately, or select Scheduled Start and then click the calendar button to choose the date and time that you want the virtual server to be created. Click OK. 13. The provisioning task is launched. At the prompt, you can jump to the Provisioning Task Tracking application to monitor the task.
Results
When the provisioning task finishes, a new version of the image is created. The instance image of the source computer is updated to reflect its relationship with this new master image. Also, the revision number of the newly captured image will be set to reflect whether it is the beginning of a new line of images (for example, version 1.1), or it is a revision of another master image (for example, version 1.2 or higher). To see the relationship between the image versions, select the parent image and click the Version tab. All of the child versions of the parent image will be listed.
What to do next
The next step is installing a new version on an existing provisioning computer or virtual server.
Deploying a master image on an existing virtual server

When you deploy a master image to an existing virtual server, it replaces only the software resources; the hardware resources of the virtual server are not replaced. Only master images that have a software image associated through the software stack can be deployed on existing computers. VMware master images cannot be deployed on an existing computer because the VMware template contains both hardware configuration and software resources. Also, composite master images cannot be deployed on existing virtual servers. To deploy a master image on an existing computer, complete the following steps:
Procedure
1. Click Go To > IT Infrastructure > Image Library > Master Images. 2. Select the master image that you want to deploy. 3. From the Select Action menu, click Deploy Master Image. 4. Clear Create Server. and select a computer from the list. 5. Beside Target Computer, click 6. In the Instance field, type the name of the new image instance. and select 7. Click Edit Software. To change the software that is included on the master image, click the software that you want to add to the image. Click OK. 8. Click Scheduling and click the Schedule button to select when the master image will be deployed. Click OK.
Results
The software resources of the computer are replaced by the master image.
Composite images
Capture and deploy composite images to create several virtual servers in a single operation.
510
A composite image is a set of images captured from two or more computers, in cases where you would like to deal with the set as a logical single entity. Typically, the set of computers would collectively provide an application service: for example, a WebSphere Application Server with a deployed J2EE application on one computer, that uses a DB2 database installed on a second computer. Composite images are treated as a single entity for the following image management operations: 1. 2. 3. 4. Capturing master images Deploying an instance of a master image Capturing a version of a deployed master image instance Publishing master images
Software prerequisites for composite images

Review the supported operating systems, virtualization technologies and prerequisites for capturing and deploying composite images.
Supported operating systems

v RedHat Enterprise Linux: Versions 5, 5.3, and 5.4 v SUSE Linux Enterprise Server (SLES): Versions 10 and 11 Only single network interfaces are supported for each virtual server.
Supported middleware versions

v WebSphere Application Server (stand-alone) and WebSphere ND: Versions 6.0, 6.1, 7.0 v DB2 (non-partitioned): Versions 8.2, 9.1, 9.5 v Oracle Database: Versions 10g and 11g Note: 1. These software products are treated in a special way in composite image capture and deploy operations. During a capture, the configurations of these software products are captured and saved with the OVF metadata of the image. At deployment time, you can modify the existing configurations. Other software products are still captured and deployed as part of the image, but their configurations are not treated specially. 2. In specific environments, you may have deadlock problems during the deployment of WebSphere ND 7.0 images. To solve the problem, install WebSphere ND 7.0 fix pack 13 or later.
Prerequisites for the target virtual servers

Target virtual servers must have the following packages installed: v Python: Version 2.4 or later v Perl: Version 5.8 or later v Prerequisites for RedHat Enterprise Linux: PyXML pyOpenSSL v Prerequisites for SUSE Linux Enterprise Server (SLES): python-xml python-openssl For capture on SUSE Linux Enterprise Server (SLES) targets, configure the following files: SLES In the /etc/sysconfig/network/config file, configure the setting:
FORCE_PERSISTENT_NAMES=no
511
In the /etc/sysconfig/boot file, configure the setting:

RUN_PARALLEL="no"
SLES 10 In the /etc/sysconfig/hardware/config file, configure the setting:

DRIVER=skip
Creating composite images

Create a composite image to save several member master images in the image library. You can create composite images in the following ways: 1. Capture composite images. 2. Discover composite images. 3. Import OVF files that contain composite images.
Capturing composite master images

Capture images of existing computers to create a new composite master image.
Before you begin

Before you can capture an image, target virtual servers must have the following prerequisites: v The required packages must be installed. For detailed information, see Software prerequisites for composite images on page 511 v Targets are associated with a host platform so that they are defined as virtual servers. v SSH-Server SAP is defined on the target virtual servers. You can either manually add this SAP or discover the virtual servers using RXA discovery. If the SAP is not defined on the targets, the virtual servers will not be displayed in the list of source computers to select from. v Target virtual servers must have a network interface called eth0. To verify that the network interface of the target has that name, click Go To > Provisioning Computers and find the target virtual server in the list. Click the virtual server and then click the Hardware tab. On the Network Interface tab, ensure that the network interface is called eth0. If the network interface has a different name, rename it to eth0. v To prevent errors during the common agent installation on the target computer, ensure that the common agent is not installed and the Tivoli GUID is removed from the computer that you are capturing the image from. For details, see Uninstalling the common agent on page 669 . To create a composite master image, follow these steps:
Procedure
1. Click Go To > IT Infrastructure > Image Library > Master Images. 2. From the Select Action menu, click Capture Composite Image. 3. In the Capture Composite Image window, type a name for the Provisioning Task or accept the default name. 4. To select the virtual servers to capture the images from, click Select, and select the virtual servers that you want to include in the composite image. Click OK. 5. Select the Repository where the image will be located. 6. Type the Relative Path of the repository location. This is the relative path to the root location of that repository where the captured image will be saved. 7. In the Composite Image field, type a name for the new master image, or accept the default name.
512
8. To schedule the new composite master image to be created, click Schedule. Accept the default value, Run Now, to create the master image immediately, or select Scheduled Start and then click the calendar button to specify the date and time that you want the virtual server to be created. Click OK. 9. The provisioning task is launched. At the prompt, you can jump to the Provisioning Task Tracking application to monitor the task.
Results
The composite image is captured and listed as a master image. to To view all of the images that are included in the composite master image, click View Details expand the composite image. In the Member Images table, you can see all of the images. To view specific details about each image, click on the name of the member image. The instance image of the source computer is updated to reflect its relationship with this new composite master image. Now you can use the image to deploy new virtual servers.
Importing master images

Import an OVF package to add new master images to the image library.
Before you begin

Before a master image can be imported to the provisioning database, the following considerations must be met: 1. An OVF package must be created. For detailed information on creating the OVF, see the document called Best Practises for Building a Virtual Appliance with OVF Metadata for use by TPM 7.2: http://www.ibm.com/developerworks/wikis/display/tivoliprovisioningmanager/ Best+Practices+for+Building+a+Virtual+Appliance+with+OVF+Metadata+for+use+by+TPM+7.2. 2. The OVF package must be located on a computer in the provisioning data center. 3. An SSH Client SAP must be located on either the source computer or the destination computer. Open Virtualization Format (OVF) is an open, secure, and portable format for packaging and distributing software as one virtual server image, or a set of virtual server images. Image information is contained in the OVF package. The package information is imported to the image library and creates master image entries with metadata to specify that it is an OVF image type. OVF file support is available for the following scenarios:
Table 84. Supported OVF environments Virtualization platforms KVM VMware (versions 3.5 and 4.0) Guest operating systems SUSE Linux Enterprise Server (SLES) Red Hat Enterprise Linux Server (RHEL)
Procedure
1. Click Go To > IT Infrastructure > Image Library > Master Images. 2. 3. 4. 5. From the Select Action menu, click Import Master Image. Type a name for the Provisioning Task, or accept the default name. Select the Source Computer, the computer where the OVF package is located. Type the Source Path, the name of the directory containing your OVF file.
513
6. Select the Destination Repository where the OVF file will be imported. Click Select Value and select the KVM or VMware repository. Master images must be enabled on the repository to be able to import the OVF package to that repository. 7. Type the Repository Relative Path for the location in the repository where the master image will reside. 8. Type an Image Name for the master image. 9. Specify a Timeout or accept the default value. 10. Select Import revision of existing master image if the master image will be a new version of an existing image library entry. and select the 11. If the master image is a revision, beside Ancestor Image Name, click Select Value appropriate master image from the list. 12. Click Schedule to schedule the provisioning task to import the master image. 13. Click Submit. 14. If you scheduled the master image to be imported immediately, the provisioning task will begin.
Results
When the master image is imported, it will display in the Master Images application. Click on the image to view the image details.
What to do next
The images can be deployed as new virtual servers.
Deploying a composite image to create new virtual servers

Composite master images contain the hardware configuration and software required to fully provision new virtual servers. In this topic, learn how to deploy a composite master image to create new virtual servers.
Before you begin

For deploying VMware images to create new virtual servers, the destination host platform server must have the mkisofs package. This is an RPM package is typically found on the operating system product CD. Composite images can only be deployed to create new virtual servers. All of the member images in the composite must be deployed together; members cannot be deployed individually. The composite image and each master image entry in the composite must be configured before you can deploy the images to create new virtual servers. Follow these steps to provision new virtual servers by deploying a composite image:
Procedure
1. 2. 3. 4. Click Go To > IT Infrastructure > Image Library > Master Images. Select the composite image that you want to deploy. From the Select Action menu, click Deploy Master Image. If licence agreements for the software on the image is required, a Licence Agreements tab will be shown. Click on each licence listed and read the agreement. Click Agree if you agree to the licence conditions. 5. When all of the licences have been agreed to, click Configure Composite Instance. On this tab, type a Composite Instance Name. You can also type a description for the new composite image in the opposite field.
514
6. Click Configure Member Instances. 7. Each member of the composite master image must be configured before the image can be deployed. Click on the first member in the composite. 8. On the Configure Member Instance tab, enter the required information: a. Type a name for the New Virtual Server that will be created by deploying this image. You can also type a description for the new virtual server in the opposite field. b. Beside Host Platform, click Select Value virtual server will be created on. and select the host platform server that the new
and select the repository for the new instance image. c. Beside Repository, click Select Value Instance images are created when master images are deployed. Only repositories associated with the selected host platform server will be displayed. When you select the host platform, the repository fields will be shown. Also, only repositories that are enabled for instance images can be selected. The instance enabled flag is an attribute of the repository and can be set for the repository in the Image Repositories application. d. Type the Repository Relative Path. This is the relative path to the repository location where the new instance image will reside. The repository location is the root path on an image repository and can be configured in the Image Repositories application. For example, if /deploy is the repository location, the Repository Relative Path for deploying the image will be relative to /deploy. If the images will be located in my_vm_path, the absolute path where the image files will be found is going to be /deploy/my_vm_path. To avoid potential problems, ensure that you do not use any special characters. Deploying a composite master image on VMware might fail if there are special characters in the Repository Relative Path because using non-ASCII characters can cause problems with VMware software. For more information about this issue, see the VMware Knowledge Base article number KB 1003866. 9. On the Map Networks tab, all of the networks on the host platform server are displayed. Click Select Value connected to. and choose the network on the host platform server that the virtual server will be
10. Optional. On the Edit Virtual Hardware tab, the CPU and Memory resources can be updated. Only the Virtual Quantity column applies to these resources. Edit the values in the Variables table, if required. 11. On the Edit Software tab, enter the required information for each of the following software resource templates. a. Select the ConfigSystem software resource template. Click the hostname parameter. In the Value field type the host name of the new virtual server. Verify that all other parameters are configured correctly, and make changes as required. b. Select the ConfigNetworkPort software resource template. Ensure that the value for the usedhcp parameter is the same value that is displayed in the ConfigSystem template. Review the values of the other listed parameters. Make changes as required. Tip: The domain name should not include the leading apostrophe character ('). c. Select the ConfigPWD_ROOT software resource template. If the user name of the virtual server can be changed, the username parameter will be displayed. Expand the parameter and make any required changes. To set the password, expand the password parameter and type the new password in the Parameter Value field. Type the password again in the Confirm Value field Other configuration templates might be listed, depending on the software on the captured image. Review the parameters and values and make changes if required.The member master image is now configured. The Configured check box will be selected. If the check box is not checked and you are unsure of what remains to be configured, click another member in the table. A validation message will be prompted that will indicate the what field requires input and on what tab.
515
12. Complete steps 8 to 12 for each master image in the composite image. All of the master images must be configured before you can deploy the composite image. 13. Click Scheduling and click Schedule to select when the composite images will be deployed. Click OK. 14. When all of the master images have been configured, the OK button will be enabled. Click OK. 15. If the deployment was scheduled to start immediately, the provisioning task begins.
Results
The composite image is deployed to the selected host platform servers and the virtual servers are created. To view the virtual servers that have been provisioned using this composite image, click the Instances tab. Each composite instance represents a collections of virtual servers that have been deployed from this composite image. The member instances give information about the individual virtual servers. Instance images help you to understand how images are being used; you can view all the instances of a particular master image. It also helps you to see and track the master image versioning. By viewing the instance images, you can see what virtual server was deployed with which version of the master image. If you are recapturing that virtual server, you can give it a new version number. Instance images also help with impact analysis. If an image has a problem, you can see what instances in your provisioning database have that image. To make changes to the virtual server resources, click the new virtual server and go to the Provisioning Computers application.
What to do next
After the image is deployed and the virtual servers are used in your business environment, there will typically be some changes made to the virtual servers, for example, additional software or patches and upgrades will be installed on the computer. After you change the virtual server, you can recapture an image of the changes. The new version of the image will contain these changes and can be used to deploy to more virtual servers with the latest changes.
Capturing a version of a composite master image

Composite master image versions help to capture the activity in the life cycle of your image management process. To create a version of an existing composite master image, follow these steps:
Procedure
1. Click Go To > IT Infrastructure > Image Library > Master Images. 2. Select the composite master image that you want to capture. 3. From the Select Action menu, click Capture Master Image Revision. 4. In the Capture Master Image Revision window, type a name for the Provisioning Task or accept the default name. 5. Click Select Server Collection to select the server collection that represents the instance of the composite master image that you want to capture. Click OK. 6. Select the Repository where the image will be located. 7. Type the Relative Path of the repository location. This is the relative path to the root location of that repository where the captured image will be saved. 8. In the Composite Image field, type a name for the new master image, or accept the default name.
516
9. To schedule the new version of the composite master image to be created, click Schedule. Accept the default value, Run Now, to create the master image immediately, or select Scheduled Start and then click the calendar button to specify the date and time that you want the new version of the master image to be created. Click OK. 10. The provisioning task is launched. At the prompt, you can jump to the Provisioning Task Tracking application to monitor the task.
Results
When the provisioning task finishes, a new version of the composite master image is created. The revision number of the newly captured image will be set to reflect whether it is the beginning of a new line of images (for example, version 1.1), or it is a revision of another master image (for example, version 1.2 or higher). To see the relationship between the image versions, select the parent image and click the Version tab. All of the child versions of the parent image will be listed.
Saved Images
Saved images are backups of various states of your virtual server. Use saved images to replace an existing virtual server, or to restore a deleted virtual server. The Saved Images application is only applicable for virtual server. Note: VMControl virtual servers are not supported by the Saved Images application. Each image that you save, of a single virtual server, becomes a member of a provisioning group associated with the virtual server. The provisioning group does not require any maintenance; it is maintained automatically by the actions in the Saved Images application. For example, Saving and Removing images adds and removes the saved images from the provisioning group. The images in the group are associated with the virtual server that the saved image was created from. The saved images remain in the image library, even if the original virtual server is deleted. Saved images are different from master images. To learn about the differences between master images and saved images, see the comparison table in Chapter 6, Managing images in the image library, on page 497. This diagram illustrates the typical flow of saving images.
517
Create saved Image
Update virtual server
Create saved Image
Delete virtual server
Restore virtual server
Does virtual server still exist?
Yes
No
Replace existing virtual server
Create new virtual server on existing host platform
Create saved image Save an image of an existing virtual server. Update virtual server This step in the process represents the typical actions for a virtual server in your environment. Updating can mean installing patches, or adding software to the virtual server. Create saved image Any time a change is made to the virtual server, you might want to create a saved image of the changed state of the virtual server. You can have multiple saved images for the various states of your virtual server. Delete virtual server If a virtual server is deleted from your provisioning environment, the saved images of the virtual server remain. You can restore the virtual server using any of the saved images of that virtual server. Restore virtual server You can restore a virtual server using a saved image. Restoring the virtual server completely replaces the existing virtual server. Or, if the virtual server has been deleted from your provisioning environment, it will be recreated on an existing host platform server.
518
To learn more about creating and restoring saved images, see the documentation in this section.
Saving images
Saved images are used to restore or replace a virtual server. You can create multiple images of a virtual server so that you can have images for different states.
Before you begin

Create an image repository in the Image Repositories application. The repository must be created, and enabled for saved images, so that the images have a direct link to the physical location on the managed system. The configuration librarian typically saves images of virtual servers. To create saved images, follow these steps:
Procedure
1. Click Go To > IT Infrastructure > Image Library > Saved Images. 2. From the Select Action menu, click Save Computer. 3. Type a name for the Provisioning Task or accept the default name. , and select the virtual server that you want to save an image of. 4. Beside Source Computer click Multiple virtual servers can be selected. Click OK. 5. The Saved Image name and description are created. Accept the name or type a new name. and select the repository where this image will be saved. If multiple 6. Beside Repository, click virtual servers are selected, expand each Source Computer to specify the required information in the Details section. Specify the required information for each type of image that you are saving: v KVM: Repository and Relative Path. v VMware: Repository only. v PowerVM: Repository only. If you specify a relative path for the saved image, it must be a unique path so that the saved images are not overwritten on the repository. 7. The task is defaulted to run immediately. Accept the default, or to schedule the task to run later, click Schedule > Scheduled Start and then click the calendar button to specify the date and time that you want the saved image to be created. Click OK. 8. Click Submit. 9. The provisioning task is launched. At the prompt, you can jump to the Provisioning Task Tracking application to monitor the provisioning task.
Results
The saved image is created and is now an object in the provisioning database. You can create multiple images of the same virtual server. Any time that you change the state of the virtual server, save an image of the state so that you can roll back to that state, if required. The following actions also occur for the saved images: v The saved image is added to a provisioning group associated to the virtual server. To view the saved images in the provisioning group, navigate to the Provisioning groups application. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. All of the saved images for the virtual server are contained in the same provisioning group. v The saved image is added to the image repository that is associated to the host platform server.
519
Creating or replacing virtual servers from saved images

Use a saved image to restore a virtual server that has been deleted or to replace an existing virtual server. A deployment specialist or a configuration librarian typically restores images. Saved images can also be thought of as image backups. When you restore a saved image, it re-creates a virtual server. Create the virtual server on the host platform server that hosted the original virtual server, or choose a different host platform server.
Procedure
1. 2. 3. 4. Click Go To > IT Infrastructure > Image Library > Saved Images. From the Select Action menu, click Restore Computer. A default name for the Provisioning Task is created. Accept the default name or type a new name. Decide where the virtual server will be restored. If you want to specify a different host platform server, clear Restore to Original Host Platform?. and select a host
5. If you are specifying a new host platform server, beside Host Platform click platform server. 6. Beside Repository, click located.
and select the repository where the new virtual server will be physically
7. The task is defaulted to run immediately. Accept the default, or to schedule the task to run later, click Schedule > Scheduled Start and then click the calendar button to specify the date and time that you want the virtual server to be created. Click OK. 8. Click Submit. 9. The provisioning task is launched. At the prompt, you can jump to the Provisioning Task Tracking application to monitor the task.
Results
When the provisioning task completes, the virtual server is created and added to the provisioning database. To view the virtual server details, navigate to the Provisioning Computers application and search for the virtual server name.
Publishing an image
By default, master images and saved images are available for all users to view. To secure these images, you can publish images to a specific provisioning group. All users can see all images in the Image Library. There might be situations where users do not require access to use, or even to view images. You can restrict access to images by publishing images to specific provisioning groups and then setting the group permissions to allow the access only to specific users. A common configuration is to define a group for each team of users that will share their own images among the team. The administrator, TPADMIN, is the only user that can publish images. To publish images, follow these steps:
Procedure
1. Click Go To > IT Infrastructure > Image Library > Master Images. Or, to publish a saved image, navigate to the Saved Images application. Click Go To > IT Infrastructure > Image Library > Saved Images. The remaining steps will use master images as an example. The same steps can be duplicated in the Saved Images application to publish saved images.
520
2. From the Select Action menu, click Publish Master Image. 3. Choose the images that you want to publish. Click Select Master Images. Select all of the images that will be published to the provisioning group. If composite images are selected, all of the members of the composite will be published. Publishing composite members individually is not supported. Note: If you clicked Select Action > Publish Master Image from one of the detail pages of a specific master image, then there is no need to select the master image again. 4. To publish the image to a provisioning group, choose whether you want to publish to an existing provisioning group or if you want to create a new provisioning group. Existing provisioning groups for master images are listed in the Selected Provisioning Groups section. v If you select Use an existing provisioning group, click Select Provisioning Groups. From the list, select the provisioning group, or groups, that you would like the image to be added to and click OK. v If you select Create a new provisioning group, type a name for the new provisioning group and click OK. 5. Click OK.
Results
The master image is published to the specified provisioning groups. Only users that belong to the security group that is associated to the provisioning group, will have access to that master image now. To verify that the master image has been published, view the image details on the Master Image tab. After an image is published to a provisioning group, on the image details page, the Unpublish Image option will be available from the Select Action menu.
What to do next
If the provisioning group is not associated to a security group, create the association so that the appropriate users can access the published master image.
Associating a security group with a provisioning group

Associating a security group to a provisioning group restricts the access of the images in the group. Depending on the type of access users require, you can either give read-only or read/write permissions to the images. Follow these steps to associate the provisioning group to a security group:
Procedure
1. Click Go To > Security > Security Group. 2. Search the security group that you want to associate to the provisioning group that you published the images to. Click on the name of the security group to select it. 3. On the Provisioning Permissions tab, click Add Read-only Permissions or Add Read/Write Permissions. 4. Select the provisioning group of images Click OK. 5. Click OK.
Results
The provisioning group is now associated to the security group with the type of provisioning permissions that you chose, either read-only or read/write.
521
You can associate a provisioning group to multiple security groups, if different types of users require access to the same images.
Unpublishing images
If images no longer need to be secured, you can unpublish them to remove them from the groups that they have been published to with a single operation.
Procedure
1. Click Go To > IT Infrastructure > Image Library > Saved Images. Or, to unpublish a master image, navigate to the Master Images application. Click Go To > IT Infrastructure > Image Library > Master Images. 2. Select the image that you want to remove from the provisioning group. 3. From the Select Action menu, click Unpublish Saved Image. Or, from the master images application, click Select Action > Unpublish Master Image.
Results
The image is removed from all the provisioning groups to which it was published. Note: Images are only unpublished from provisioning groups that they are specifically published to. If a user has manually added an image to a provisioning group, the image will remain in that group. If you want to unpublish a master image only from a specific group, click the Master Image tab to to delete the row related to the group in the Published to display the image details and click Provisioning Groups table.
Troubleshooting image library management

To help you to troubleshoot problems with the image library, gather as much information as possible about the error. Review the following list to assess the problem.
Procedure
1. Check the interface and log files for error messages. See the Log files topic for details. 2. If there is an error message with a message ID, search the Tivoli Provisioning Manager Information Center for a description of the error message. 3. Check the Tivoli Provisioning Manager release notes or the latest available fix pack readme file for information about known issues or updates to the documentation.
Log files
Log files help in diagnosing problems and recording commands. v Problems with saved images v Image repository problems on page 523 v Master image problems on page 523 Note: The log files mentioned in the following tables are located in the TEMP directory: v v
Windows UNIX
%TEMP%. For the full address, see the Environment variables document.
Linux
/tmp/
Problems with saved images

522
Step where the problem occurs: Removing saved images
Check errors in: v Provisioning workflow log v web interface error messages
Log files v HostPlatform.DeleteSavedImage v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages. v Hostplatform.SaveImage v No log file - for more information about the error message, see Messages. v Hostplatform.RestoreImage v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages.
Creating saved images Deleting saved images
v web interface error messages v web interface error messages
Restoring saved images v Provisioning workflow log v web interface error messages Saving saved images v Provisioning workflow log v web interface error messages Publishing saved images Unpublishing saved images v web interface error messages v web interface error messages
Image repository problems

Step where the problem occurs Synchronizing repositories Check errors in: v Provisioning workflow log v web interface error messages Creating KVM repositories Creating VMFS repositories Creating PowerVM repositories Deleting repositories v UI error messages v web interface error messages v web interface error messages v web interface error messages Log files v Repository.Synchronize v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages.
Master image problems

Step where the problem occurs Check errors in: Log files v No log file - for more information about the error message, see Messages.
Creating master images v web interface error messages
523
Step where the problem occurs
Check errors in:
Log files v No log file - for more information about the error message, see Messages. v VApp_DeployVirtualAppliance: creating a virtual server and the image is OVF v HostPlatform.CreateVirtualServerAndSoftwareStack: creating a virtual server and the image is NOT OVF v SoftwareModule.Install: deploying on existing server v No log file - for more information about the error message, see Messages.
Deleting master images v web interface error messages Deploying master images v Provisioning workflow log v web interface error messages
Removing master images
v Provisioning workflow log v web interface error messages
v BootServer.DeleteImage v No log file - for more information about the error message, see Messages. v BootServer.CaptureImage if golden master, BootServer.CaptureScriptedImage if scripted image, BootServer.CaptureBackupImage if snapshot v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages. v No log file - for more information about the error message, see Messages.
Capturing master images
v Provisioning workflow log v web interface error messages
Publishing master images Unpublishing master images Creating a revision Deleting instance images
v web interface error messages v web interface error messages v web interface error messages v web interface error messages
Image library problems and limitations

Cannot remove VMware master images

A VMware master image cannot be removed from the image library.
Symptoms
The following error occurs when you try to remove a VMware master image:
COPSWD087E - This action is not supported
Causes
The error message is expected. Only image library entries that have software resources associated can be removed.
524
If the VMware master image is no longer required, delete the image from the VMwareVirtualCenter. After the image is deleted, run the VMware Virtual Center Discovery from the provisioning server. The discovery synchronizes the image library with the VirtualCenter and removes the master image from the image library.
Synchronizing does not update changes to existing OVF master images

Changes that are made to existing OVF master images are not updated in the image library after a synchronization.
Symptoms
After you synchronize to add OVF master images to the image library, any updates made to the data on the images will not be updated the next time you synchronize the repository.
Causes
This behavior is expected. Support for OVF is only for new master images. Any new master images or data that is added to the existing OVF image is not synchronized.

Instead of changing existing OVF images, create new versions of the original master image.
Cannot create a VMware virtual server from a SLES 10 master image

An error occurs when you use a SLES 10 master image to create a VMware virtual server.
Symptoms
The following error occurs when you select a SLES 10 master image and try to deploy a new VMware virtual server:
COPDEX123E A ConnectionInfoTimeout exception occurred. The exception was caused by the following problem: IBM Tivoli Provisioning Manager was NOT able to determine the IP of the VM for connectivity. Make sure the VMware Template has VMware tools installed and is set to DHCP.
Causes
This is a known VMware issue. The error can happen for a number of reasons. For example, if a virtual server has been cloned and VMware tools have not been installed into a VMware virtual server.

See the VMware documentation http://www.novell.com/support/search.do?cmd=displayKC &docType=kc&externalId=3048119&sliceId=SAL_Public for more details about the affected environments and the situation.
Provisioning task fails with a refused connection error

Synchronizing a KVM repository fails with an SSH error.
Symptoms
The following error occurs when you are running a provisioning task, for example, synchronizing a KVM repository:
java.net.ConnectException: Connection refused: connect
525
Causes
The error occurs because the SSH daemon is not configured and started on the provisioning server.
Environment
This error can also occur if you have manually installed Cygwin instead of installing it with Tivoli Provisioning Manager installer.

Complete these steps to configure the SSH daemon: 1. Log in to the provisioning server as the administrative user. 2. Run the following command to configure the SSH daemon:
ssh-host-config -y
3. Run the following command the start the SSH daemon:

cygrunsrv -S sshd
4. Run your provisioning task again.
A KVM virtual server entry cannot be deleted from the agent manager
To use a KVM virtual server with the Tivoli Common Agent, the virtual server must have a full host name as the Computer name.
Symptoms
Running the provisioning workflow, TCA_DeleteServerFromAM, to remove the virtual server entry from the agent manager fails.
Causes
The Computer name of the KVM virtual server is not a full host name.

Change the Computer name of the virtual server so that it is the full host name of the virtual server. To delete the agent manager entry, see Removing expired agents. Note: If you used a saved image to create the virtual server, do not use this saved image to restore this virtual server again. Create a new saved image with the Computer name with the full host name that is supported to work with the Tivoli Common Agent.
TCA_pingAgent fails after virtual server is restored

The Tivoli Common Agent is not running on the virtual server after it is restored because the original virtual server was not deleted from the agent manager.
Symptoms
After successfully restoring a virtual server that has been deleted with a saved image that includes the Tivoli Common Agent, the provisioning workflow TCA_pingAgent fails. A management IP address is required, but the virtual server does not have one. The agent is not running on the restored virtual server.
Causes
The original virtual server was deleted from the provisioning database and then the saved image was used to restore the virtual server. However, the original virtual server was not deleted from the agent
526
manager. It must be removed because it has the old information of the virtual server. When a saved image is used to restore a virtual server, new information is given to the virtual server.

Complete the following steps to resolve the issue: 1. To delete the virtual server from the agent manager, run the provisioning workflow called TCA_DeleteServerFromAM. 2. To download the new certificates from the agent manager to the virtual server and to register the restored virtual server with the agent manager again, follow these steps: a. Stop the Tivoli Common Agent. b. Remove all of the files from the directory <TCA_HOME>/runtime/agent/cert. c. Edit the <TCA_HOME>/runtime/agent/config/endpoint.properties file. Set the property called agent.ssl.truststore.download to true. d. Start the Tivoli Common Agent. The original virtual server has been removed from the agent manager and the restored virtual server has been registered.
Capture fails with session is down error

Capturing a KVM computer fails with the error that the session is down.
Symptoms
Trying to capture an image of a KVM computer fails with the following error:
com.jcraft.jsch.JSchException: session is down
Causes
The target computer is low on memory.

Increase the memory on the target computer and try to capture the image again.
527
528
Chapter 7. Deploying software

Tivoli Provisioning Manager uses the scalable distribution infrastructure for software and patch distribution and installation, discovery, and compliance management. Unlike the deployment engine infrastructure, which is typically used for automating operations on smaller sets of managed targets, the scalable distribution infrastructure ensures a fast and reliable software distribution to large numbers of target computers (tens of thousands) in a variety of topologies.
Software deployment basics

Find out more about the software deployment process, the key terms, who are the users that deploy software, and what are the requirements that you need to verify before deploying software. Review the troubleshooting information and the log files names and locations and also additional resources that help you complete your software deployment tasks. v Process on page 530 v User roles on page 531 v Requirements on page 531 v Key terms on page 532 v Troubleshooting on page 533 v Log files on page 533 v Resources on page 533 v
529
Process
The following diagram illustrates the high-level architecture of the scalable distribution infrastructure:
Provisioning Server
Web Service Clients
Operator/Administrator Console
Tivoli Provisioning Manager
Dynamic Content Delivery Management Center
Agent Manager
Region A
Branch Office 1
Dynamic Content Delivery Depot
Target
Branch Office 2
Target
Region B
Branch Office 3
Target
Software deployment using the scalable distribution infrastructure includes the following processes: v v v v Setting up scalable distribution infrastructure on page 538 Publishing software to depot servers on page 543 Distributing and installing software on page 582 Installing software products on page 607
530
User roles
You must be assigned to the appropriate user role to perform software deployment.
Table 85. User roles for software distribution through the scalable distribution infrastructure Role Provisioning Administrator Description of Role Responsible for: v The management of the provisioning server itself. v Setting up the scalable distribution infrastructure. v Configuring the deployed core components to work with the provisioning server environment. Deployment Specialist Responsible for managing entities in v Intermediate knowledge of the a data center. Uses Tivoli Tivoli Provisioning Manager Provisioning Manager to manage system. these entities and has all the required v Intermediate knowledge of the access permissions to the software distribution process corresponding devices. through the scalable distribution infrastructure. Skills v Advanced knowledge of the Tivoli Provisioning Manager system. v Advanced knowledge of the architecture and functions of the scalable distribution infrastructure.
Requirements
User roles and requirements on page 546 Target computer requirements: Requirements for Windows target computers on page 556 Requirements for Red Hat Linux target computers on page 560 Requirements for SUSE Linux Enterprise Server (SLES) target computers on page 561 Requirements for AIX target computers on page 562 Requirements for Solaris Operating Environment target computers on page 563 Requirements for HP-UX target computers on page 565 v Requirements for common agent installation on page 547 v Installation media for software distribution on page 566
531
Key terms
depot server The component that stores files for distribution. Files are uploaded to a depot server using a client and stored in a directory that is specified when the depot server is installed. Depot servers can replicate files to other depot servers. Target computers can download files from depot servers or peers. distribute To disperse software packages, software patches, and software stacks to be installed over one or more targets. distribution infrastructure A framework for software distribution supporting software management tasks including configuration, distribution, installation, and asset inventory management. job A separately executable unit of work.
logical management operation A generic function supported by a set of devices. For example, configuring an IP address on a network interface is a logical management operation supported by all operating systems. Although this is logically the same function, the steps for performing this function on each operating system are different. These steps are supported by provisioning workflows for that operating system. provisioning group A group of computers, software definitions, file repositories, and so on. An administrator can create provisioning groups to organize systems into meaningful categories, and to facilitate deployment of software to multiple computers. provisioning task An action that runs a deployment job on one or more target computers. A deployment job can include one or more job items that correspond to provisioning workflows. provisioning workflow A program that is used to manage an environment. The program consists of a sequential series of steps that are performed to accomplish a particular provisioning task. publish To enable faster download and software distribution to target computers, you can publish software products, software patches, or files in a specified repository to selected depot servers, in advance of when they are needed on the computers. The files published on depot servers can then be downloaded by the target computers. scalable distribution infrastructure A solution that ensures fast and reliable software distribution to large numbers of target computers in a variety of topologies. It enables central management of software distribution, and relies on core services such as Tivoli Common Agent services, the dynamic content delivery, and device manager service to perform the actual software distribution and federated job management operations. software package block (SPB) A file or set of files that can be included in a particular software deployment. Examples include an installation package, installation files for a patch downloaded from the vendor website, or a software image. software resource template (SRT) A set of parameters that define configuration options and software resources to create on a managed system during software installation. software signature The set of unique information that identifies a software application, such as the name, version, and file size of an application.
532
Troubleshooting
v Troubleshooting software distribution on page 751 v Log files on page 761 v Software deployment problems and limitations on page 763 v Messages v Support information about the scalable distribution infrastructure v Contacting Support
Log files
The following are common troubleshooting problems with scalable distribution infrastructure. Check the log files and the workflow logs to determine the problem: v Recovering from software resource problems v Recovering from software product problems v Recovering from software stack problems v Recovering from file problems v Recovering from agent installation problems v Recovering from patch problems
Resources
To learn more about software deployment using the scalable distribution infrastructure, refer to one of the following resources: v Tutorial: Software deployment on page 567 v Distributing and installing software on page 582 v Simple software product distribution on page 618 v Uninstalling software on page 626 v Installing Tivoli Common Agent Services on page 628 v Administering installed software on page 689 v For a description of a field in the web interface, press Alt+F1.
Related links Chapter 7, Deploying software, on page 529 Requirements on page 546 Tutorial: Software deployment on page 567
Software distribution process overview

The scalable distribution infrastructure ensures central management of software distribution from Tivoli Provisioning Manager, and relies on core services such as Tivoli common agent services, the dynamic content delivery, and device manager service to perform the actual software distribution and federated job management operations. It allows you to use most capabilities in Tivoli Provisioning Manager, including the security compliance capability, which is not supported on other infrastructures. It also allows you to reduce your infrastructure costs, because it requires less hardware than other infrastructures. The following diagram illustrates the high-level architecture of the scalable distribution infrastructure:
533
Provisioning Server
Web Service Clients
Agent Manager
Region A
Branch Office 1
Target
Branch Office 2
Target
Region B
Branch Office 3
Target
Software deployment using the scalable distribution infrastructure includes the following processes: v Setting up scalable distribution infrastructure on page 538 v Publishing software to depot servers on page 543 v Distributing and installing software on page 582 v Installing software products on page 607
Components
The scalable distribution infrastructure includes the following management elements and distribution elements. Each management element maintains a record data set for its type of data (jobs or bulk data). The distribution elements (job managers, depot managers) maintain a working data set which is a cache of the management data set. To enhance performance, the management elements implement a cache pre-fill strategy in which data is distributed to the branch elements in advance of when it is needed.
534
Provisioning server The provisioning server is the server on which Tivoli Provisioning Manager is installed. The following components of the scalable distribution infrastructure are installed on the provisioning server: The dynamic content delivery management center The dynamic content delivery management center provides centralized control of the upload, replication, and download of files. It also monitors the state of depot servers and stores file data and download statistics. The dynamic content delivery management center implements a distribution policy that sends bulk data to some or all the distributed depot servers in advance of when it is needed. A device manager federator The federator is installed on the provisioning server and is configured to act as a federated server. The federator implements a job distribution policy that pushes incoming jobs to all the regional agents. Agent Manager Tivoli Provisioning Manager uses the Tivoli Common Agent Services for software distribution and compliance. Tivoli Common Agent Services provides an infrastructure for managing the computer systems in your environment. Agent Manager is the server component of the Tivoli Common Agent Services that provides functions that clients can use to get information about agents and resource managers. It enables secure connections between the target computers, maintains the database information about the targets and plug-ins installed on the agent, and processes queries against that database from resource managers. It also includes a registration service, which handles security certificates, registration, tracking of common agents and resource managers, and status collection and forwarding. Distribution servers The provisioning server connects to distribution servers, or directly to target computers. The distribution servers contain the following components: A device manager federated agent Agents are installed on distribution servers and are configured to communicate with the federator to get command jobs and to distribute them to the set of clients installed on the target computers. The agents on the distribution server periodically communicate with the federator and detect when there is network connectivity. A dynamic content delivery depot Depots communicate with the management server, particularly the dynamic content delivery management center, to provide status information and during download requests from the agents.
535
Depot Server
OSGi
Common Agent
Tivoli Common Agent target computers Target computers connect to the distribution servers. The targets contain the following components: A device manager subagent Clients are installed as device manager subagents on all the targets and are used for receiving jobs from the Device Management Service and sending results from the agents to the Device Management Service. A dynamic content delivery subagent Subagents are installed on all the managed systems or targets to download files from depot servers or from other clients. Tivoli Common Agent client The Tivoli Common Agent client is installed on the target computers and acts as a common container for all the subagents. The deployed agent software collects data from and performs operations on managed resources on behalf of a Tivoli management application. It provides shared system resources and secure connectivity.
536
Target Computer
OSGi
Device Manager Subagent
Dynamic Content Delivery Subagent
Common Agent
The following diagram illustrates the interaction between the components of the scalable distribution infrastructure:
537
Provisioning Server
Web Service Clients
Agent Manager
Region A
Branch Office 1
Target
Branch Office 2
Target
Region B
Branch Office 3
Target
The management elements of the infrastructure are installed on the provisioning server. The branch elements ensure a two-way communication between the management elements and the clients installed on the target computers in the branch offices. The branch elements communicate with the management elements to get data requested by the targets at the branch. When the targets receive the requested data, results are returned to the regional elements, which in turn, communicate them back to the management elements.
Setting up scalable distribution infrastructure

After the provisioning server is successfully installed, a number of postinstallation configurations tasks must be performed to set up the scalable distribution infrastructure. The Tivoli Provisioning Manager installer silently installs the following management elements of the scalable distribution infrastructure on the provisioning server: v The Tivoli agent manager v The device manager federator
538
v The dynamic content delivery management center The following diagram illustrates all of the elements that constitute the scalable distribution infrastructure:
Provisioning server
Agent Manager

...
2 1

Service Subagent
- Common Agent
The following postinstallation configuration tasks must be performed to properly set up the distribution elements of the infrastructure to interact and communicate with the management elements so that all supported operations can be successfully performed: Install the depot servers The installation of the dynamic content delivery depot servers can be done using the web
539
interface. Regions, depots, and zones can also be created, updated, or deleted using the DcdAdmin automation package. If you need to create several zones, use the DcdAdmin automation package CLI or workflows to create them. For more information, see the Automation package for management of large numbers of regions, zones, and depot servers on page 821 and Adding depot servers on page 819 topics. Install the common agent on target computers The common agent installation can be performed either using the provisioning server or outside of it. For more information, see the Installing the common agent on page 541 topic.
Depot server installation

To be able to publish the software files that you want to distribute and install on target computers, you need to define the regions, zones, and depot servers that will be used in the software distribution process.
Before you begin

v New depot servers can only be added after a region has been defined. For more information, see the Adding and removing regions on page 818 topic. v Also, the server that will be configured as a depot server needs to be discovered first. Discovery adds the depot server to the data model. For more information see Regions, zones, and depot servers on page 817. v If you have enabled IPv6 addressing support for the scalable distribution infrastructure, the operating system on depots must be able to communicate appropriately with other computers in your environment. For example, if you have both IPv4 and IPv6 target computers, the depot can be configured to support both IPv4 and IPv6 addressing, or you can set up separate IPv6 and IPv4 depots to support communication with each type of IP addressing. If all communication with the depot will use IPv6 addressing, the depot can be configured to support IPv6 only. v Note that regardless of your language settings, Server Traffic statistics are displayed in the following format: 0.0. The new depot server with the specified properties is added and registered with the management center. It is also listed on the Depots Management page, and its displayed status is Active. For information about how to add a depot server, see Creating the infrastructure for scalable software distribution on page 572. You can perform the following actions with the depot server: v View more details for a depot server. v Modify depot server properties, designate the depot server as a preferred upload server, or install the depot agent services on the depot server. Preferred upload servers are selected before other depot servers to receive uploaded files. If no preferred upload server is available, another depot server is selected to receive the uploaded file. Preferred upload servers must be globally accessible, not blocked by a firewall from clients. If a preferred upload server is not included in the initial publishing of a file, a temporary preferred upload server is chosen by the Dynamic Content Delivery management center for the initial publishing. After all the replications are completed to the chosen depots, the file will be removed from this temporary preferred upload server. The criteria for a preferred upload server must include the following: High availability: Monitor the depot using the check status of a depot on the provisioning server. These depots must always be in an active status. Alternatively, you can use the Event Console in the Dynamic Content Delivery Admin Console. Proximity to the provisioning server or the management center. High network bandwidth availability. Large available disk space.
540
You cannot have a preferred upload server in a zone with "Minimize traffic in and out of zone" set to enabled or incoming-blocked. A publish to this preferred upload server will fail. v Define the number of concurrent activities included in each activity plan when publishing software and patches. When you publish software products or patches to a depot, Provisioning Manager generates an activity plan. By default the activity plan contains five concurrent activities. If you want to change the number of concurrent activities, perform the following steps: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click Variables. 3. Click New Row and add the following settings: Variable Type Publish software activity concurrency level Component Entire System Value Type the value of the property with the required number of concurrent activities. The default value is five. Tip: To view information about depot server status from the Start Center, expand the Depot status portlet. Running the dynamic content delivery depot as LOCAL_SYSTEM: To run the dynamic content delivery depot as LOCAL_SYSTEM, set the value of the Windows_Run_Service_As_SYSTEM parameter to true in the TCA default.<dcmId> configuration template for the CDS_Depot_Stack. The default value is false. To run the dynamic content delivery depot as LOCAL_SYSTEM: Procedure 1. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. 2. Click CDS_Depot_Stack. 3. Expand Configuration Templates to locate Default Template and click the TCA default..<dcmId> configuration template. 4. In the Template Parameters list, the Windows_Run_Service_As_SYSTEM parameter is sorted onto the next page. Advance the parameter list page by clicking the right arrow in the Template Parameters header bar. 5. Set the value of the Windows_Run_Service_As_SYSTEM parameter to true. The default value is false. Results Setting the value of the Windows_Run_Service_As_SYSTEM parameter to true enables the credentials specified for the local system account to be used instead of the local user credentials.
Installing the common agent

When you install the common agent from the provisioning server, the common agent is installed on the managed system with the related TCA-Feature Tivoli Provisioning Manager Base.
Preinstallation information
Before installing the common agent using the following methods, review the following information: v Requirements for common agent installation on page 547
541
v Installing the common agent on the provisioning server, where the agent manager is also installed, is not supported. If you want to revert to the previous version of a common agent for compatibility with other products that require the older product level, you must remove the agent and then reinstall it using the installation package included with the other product. Installing the common agent does not affect any other agents that are already installed. v Version 1.4.2.1 of the common agent is installed with the current version of the provisioning server. Note: The common agent installation does not support RSA credentials for Windows target computers. When the network discovery is performed using the RSA credentials, a set of password credentials for SMB must also be used to discover the Windows target computers.
Installation methods
There are two main ways to install the common agent: Using Tivoli Provisioning Manager You can use the Common Agent Installation page to install the common agent on an existing managed system. This option installs the common agent with default options. The following service access points (SAP) are created on the target computer during the common agent installation: v Agent-Server (IPv4 / CommonAgent) v SDI-SAP (IPv4/Scalable Distribution Infrastructure) v RXA-Server (IPv4/RXA) Note: The RXA SAP is created only if you provide credentials and there is no default SAP assigned to the device. The TCA.Create.EO.SAP configuration parameter determines if the SDI SAP is created as part of the agent installation. This parameter is set to true by default. To modify this parameter, go to Provisioning Global Settings->Variables. For more information, see Installing the common agent on managed systems on page 640. Outside of Tivoli Provisioning Manager The common agent can also be installed using an installation image, which provides all the required common agent installers, and their configuration. Restriction: The standalone installation does not support the installation of the dynamic content delivery depot subagent. For more information, see Installing the common agent and subagents using a stand-alone installation on page 641. The default common agent installation path is: v Windows: C:\Program Files\Tivoli\ep v Solaris or Linux: /opt/tivoli/ep v AIX or HP-UX: /usr/tivoli/ep
Changing the default polling interval

Before installing the common agent and the depot server, you might need to change the default polling interval from target computers and depot servers. To reduce network traffic, the default polling interval is set to one hour. You can change the default polling interval to something more appropriate to your needs. Based on the total number of managed systems, you must determine the most appropriate polling interval for your needs. For small numbers of managed systems, reducing the target polling interval can be acceptable. For large numbers of managed systems, short polling intervals might be detrimental to the overall system performance.
542
Important: You can specify values for the polling interval in two places, in the software definition, and in the software stack. If you are using the prepareTCAImage script to complete a stand-alone common agent installation, the properties for the polling interval from the software definition are used by default. You can change this behavior by setting the TCA.Standalone.Stack.Name variable and specifying a software stack to use. The prepareTCAImage command searches for a global variable called TCA.Standalone.Stack.Name. If the variable exists and points to an existing stack, it uses the properties from the stack specified in the variable. If the variable does not exist or points to a nonexistent stack, the properties from the software definition are used for the default polling interval. You can change the polling interval in the TCA-Subagent JES configuration template, available in both the Tivoli Common Agent Stack and CDS_Depot_Stack configuration templates. Each stack contains its own unique copy of the PollingInterval template parameter. If a change is required in both places, the procedure must be performed in both stacks. The following procedure describes how to change the polling interval where the properties from the software stack are used to define the polling interval. If you are using the prepareTCAImage script for common agent installations, the following procedure does not change the default polling interval unless you have set the TCA.Standalone.Stack.Name variable and specified the software stack to use for the polling interval. If you are using the properties from the software stack, complete the following steps to change the polling interval:
Procedure
1. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. 2. Find the software stack called Tivoli Common Agent Stack or CDS_Depot_Stack and click it. 3. Under Configuration Templates, expand the TCA-TPM-Base Feature default template. 4. Select TCA-JES Default. 5. Click the icon for the PollingInterval parameter and type the new interval in the Value field. For example, if you want to set it to 10 minutes, enter 00:10.
Results
You are now ready to install the common agent and the depot server. The default polling interval is reset to the specified value.
What to do next
After the polling interval is reset to the specified value, you can install the common agent and the depot server.
Publishing software to depot servers

To allow faster download and software distribution to target computers, you can publish software products, software patches, or files in a specified repository to selected depot servers at the branch office, in advance of when they are needed on the computers. The files published on depot servers can then be downloaded by the target computers.
Before you begin

Distribution files are published to a depot server using the dynamic content delivery agent. The agent must be installed on the depot server before you can publish any files. The depot feature needs to be installed on a depot before a file can be published to it. Verify that the depot is in active state before publishing a file to it. Always include a preferred upload server when a file is published for the first time. You can also define the number of concurrent activities included in each activity plan when publishing software and patches. The default value is five. Increasing the number of activities in each plan reduces the risk of creating too many threads.
543
Before you publish a file, determine which users will download the file and their location on the network. This affects the target lists or regions to which you replicate the file. To minimize network traffic and download time, publish the file to depot servers that are near the users who need the file. Files uploaded to a depot server are stored in a directory that is specified when the depot server is installed. Depot servers can replicate the uploaded files to other depot servers to optimize the efficiency of network traffic. The computers download the published files for installation.
Publishing software products

To publish software products to depot servers:
Procedure
1. 2. 3. 4. Click Go To > Deployment > Software Management > Software Product Publishing. Select the Encrypt File check box if you want to enable encryption of the software installable. Click Select Software and select the software modules to be published, then click OK. Click Select Depots and select one or more depot servers for the provisioning task, then click OK. Tip: The default path for publishing can be customized. v The default path is C:\Program Files\Tivoli\ep\runtime\agent\subagents\cds\depot\. v The relative path variable is \data. v The system creates subdirectories \files\1 under C:\Program Files\Tivoli\ep\runtime\agent\ subagents\cds\depot\data\. To publish to a specific subdirectory, for example, abcd, change the relative path. The files will be published at C:\Program Files\Tivoli\ep\runtime\agent\subagents\cds\depot\ abcd\files\1\. 5. Click Schedule to run the task now or to specify the date and time on which the provisioning task is scheduled to start. 6. Under Notification, specify notification settings for the task. 7. Click Submit.
Results
The publishing task is either run immediately or saved and run at the specified time. You can track the provisioning task status on the Provisioning Task Tracking page.
Publishing patches
To publish software patches to depot servers:
Procedure
1. Click Go To > Deployment > Patch Management > Patch Publishing. 2. Click Select Patches to select the patches that you want to publish, then click OK.
Windows To search for a particular patch, enter the patch name in the Patch field, for example KB921823. If multiple software definitions are available for that patch number, for example, Security Update for Windows Server 2003 and Security Update for Windows XP, select all the software definitions that match the patch number, and the provisioning server will publish them to the depots. 3. Click Select Depots and select one or more depot servers for the provisioning task, then click OK.
Tip: The default path for publishing can be customized.
544
v The default path is C:\Program Files\Tivoli\ep\runtime\agent\subagents\cds\depot\. v The relative path variable is \data. v The system creates subdirectories \files\1 under C:\Program Files\Tivoli\ep\runtime\agent\ subagents\cds\depot\data\. To publish to a specific subdirectory, for example, abcd, change the relative path. The files will be published at C:\Program Files\Tivoli\ep\runtime\agent\subagents\cds\depot\ abcd\files\1\. 4. Click Schedule to run the task now or to specify the date and time on which the provisioning task is scheduled to start. 5. Click Submit.
Results
Unpublishing files from depot servers

Distribution files can be unpublished from depot servers when they are no longer needed. You can unpublish software products, software patches, and files in a specified file repository from depot servers. Unpublished files are removed from all depot servers they have initially been published to.
Unpublishing software products

To unpublish software products from depot servers:
Procedure
1. Click Go To > Deployment > Software Management > Software Product Unpublishing. 2. Type a relevant name for the provisioning task. You can use this name to view the provisioning task status on the Provisioning Task Tracking page. 3. Under Select Installables, specify the software modules for the provisioning task: a. From Views, select a software view to filter the list of software products. b. The Software Products type is selected by default. The Available Software table lists all available software modules that have at least one installation file. c. Select the software installation files for the provisioning task. The Selected Installables table lists the selected files. 4. Click Schedule to run the task now or to specify the date and time on which the provisioning task is scheduled to start. 5. Click Submit.
Results
Unpublishing patches
To unpublish software patches from depot servers, follow these steps:
Procedure
1. Click Go To > Deployment > Patch Management > Patch Unpublishing.
545
2. Type a relevant name for the provisioning task. You can use this name to view the provisioning task status on the Provisioning Task Tracking page. 3. Under Select Installables, specify the software patch-installation file pairs for the provisioning task: a. From Views, select a software view to filter the list of software patches. b. The Software Patches type is selected by default. The Available Software table lists all available software patches that have at least one installation file. c. Select the software installation files for the provisioning task. The Selected Installables table lists the installation files selected for the provisioning task. 4. Click Schedule to run the task now or to specify the date and time on which the provisioning task is scheduled to start. 5. Click Submit.
Results
Unpublishing files
Files in a specified file repository, which are not associated with any installables, can also be unpublished from depot servers. To unpublish files from depot servers, follow these steps:
Procedure
1. Click Go To > Deployment > Software Management > File Unpublishing. 2. Click Unpublish > Files. 3. Type a relevant name for the provisioning task. You can use this name to view the provisioning task status on the Provisioning Task Tracking page. 4. Under Select Files, specify the files for the provisioning task: a. Select the file repository for the files to be unpublished. b. Search for and select the files for the provisioning task. The Selected Files table lists the files selected for the provisioning task. 5. Click Schedule to run the task now or to specify the date and time on which the provisioning task is scheduled to start. 6. Click Submit.
Results
Requirements
Before you proceed with the software deployment using the scalable distribution infrastructure, ensure that all software, hardware, and access rights requirements are met.

To perform the software distribution tasks, ensure that you have the required knowledge and access rights to perform your role.
546
Table 86. User roles for software distribution through the scalable distribution infrastructure Role Provisioning Administrator Description of Role Responsible for: v The management of the provisioning server itself. v Setting up the scalable distribution infrastructure. v Configuring the deployed core components to work with the provisioning server environment. Deployment Specialist Responsible for managing entities in v Intermediate knowledge of the a data center. Uses Tivoli Tivoli Provisioning Manager Provisioning Manager to manage system. these entities and has all the required v Intermediate knowledge of the access permissions to the software distribution process corresponding devices. through the scalable distribution infrastructure. Skills v Advanced knowledge of the Tivoli Provisioning Manager system. v Advanced knowledge of the architecture and functions of the scalable distribution infrastructure.
Hardware and software prerequisites

The computers that the provisioning server manages require some hardware and software prerequisites before you can perform software distribution and management.
Requirements for common agent installation

Before installing the common agent, verify the prerequisites.
General requirements
Target computers must already be configured with the software required for administration with the provisioning server. In addition to the requirements in this topic, verify the requirements: v Windows requirements for common agent installation on page 550 v UNIX requirements for common agent installation on page 552 v Linux requirements for common agent installation on page 554
547
Table 87. Footprint requirements on Windows targets Requirement Footprint on Windows targets Details
Windows The amount of disk and memory space required by the common agent and subagents to work correctly on Windows targets is estimated as follows: XP
Windows XP v Disk: 180 MB v Memory: 50 MB
2003
Windows 2003 Enterprise Edition and Windows 2003 Data Center Edition v Disk: 190 MB v Memory: 50 MB
Vista
Vista v Disk: 270 MB v Memory: 50 MB
2008
Windows Server 2008 Standard Edition and Windows Server 2008 Enterprise v Disk: 270 MB v Memory: 50 MB
Edition
Windows 7
Windows 7 v Disk: 270 MB v Memory: 50 MB
548
Table 88. Footprint requirements on UNIX targets Requirement Footprint on UNIX targets Details
UNIX On UNIX platforms, the disk and memory footprint for the common agent and subagents is estimated as follows: Linux
Linux v Disk: 140 MB v Memory: 60 MB
Red Hat
RedHat v Disk: 200 MB v Memory: 60 MB
SUSE
SuSe v Disk: 211 MB v Memory: 60 MB
AIX
AIX v Disk: 145 MB v Memory: 60 MB
Solaris
Solaris x86 v Disk: 160 MB v Memory: 60 MB SPARC v Disk: 170 MB v Memory: 60 MB
HP UX
HP-UX PA-RISC v Disk: 200 MB v Memory: 60 MB ia64 v Disk: 280 MB v Memory: 60 MB
Table 89. General footprint requirements Requirement General footprint requirements Details Added to the base footprint specified previously, the following factors can increase the size of the common agent footprint on the target computer: v The signature files and output XML files for Common Inventory Technology (CIT): 20 MB v The log files for the common agent: default 2 MB, configurable. v The cache used for peering (turned on by default): up to 2 GB, configurable. For more information about how to configure the default peering cache, see Configuring the default peering cache on page 655.
549
Table 90. Other general requirements Requirement Credentials Details You can optionally define service access points (SAP) for the Device.ExecuteCommand and Device.CopyFile commands. v If no default service access points (RXA or SSH) are defined, an RXA service access point is created for the target computer when you install the common agent from the Install Common Agent page and specify a user name and a password. v If default service access points are already defined for the Device.ExecuteCommand and Device.CopyFile commands on targets, they are used to install the common agent. If you want to use predefined default SAPs to install the common agent, the operating system of the targets must also be configured. You can run the TCA_Set_Platform_Capabilities provisioning workflow on the targets to add the operating system information. You can create a provisioning workflow task to run the specified provisioning workflow on selected targets. Firewall access rule Host name resolution An access rule must be created on the Access Control List (ACL) for the firewall during or before the installation of the common agent. If host names are used, DNS or hosts files must be configured so that the common agent can resolve the fully qualified domain name of the agent manager server, and the provisioning server can resolve the host names of target computers. The default configuration is communication using host names. You can verify the current configuration by looking at the value of the global variable SDI.Use.Hostname. A value of true means that communication with host names is configured. A value false means that IP address communication is configured. If you want to use host names to resolve to a configured IPv6 address on a target computer, enable IPv6 support for the scalable distribution infrastructure. JRE version Access control Date and time requirements IBM JRE 1.5 is bundled as a private JRE with the agent, and does not interfere with other JREs installed on the same system. To install the common agent, the provisioning administrator role must be assigned to your user account. When the common agent starts for the first time, it connects to the agent manager to register itself. The date and time on the managed system must be set within 24 hours of the date and time on the agent manager server for successful registration. The values are compared in coordinated universal time (UTC), so the systems can be in different time zones.
Windows requirements for common agent installation: Before installing the common agent on Windows, verify the following prerequisites. Windows requirements The following additional requirements apply to Windows target computers. You can use either a local administrator account or a domain administrator account for the agent installation on Windows. Windows Installer Windows Installer Version 2.0 or higher is required to install the common agent. It is included with Windows 2003 Server. If you are installing the agent on a target with a previous version of Windows Installer, you can obtain Version 2.0 from the Microsoft Web site. Internet Connection Firewall (ICF)
550
Windows XP includes a built-in firewall called the Internet Connection Firewall (ICF). By default, ICF is not available on Windows XP systems. Windows XP Service Pack 2 (SP2) comes with the Windows Firewall enabled by default. If either firewall is enabled on a Windows XP target system, it blocks attempted accesses by RXA. On Windows XP SP2, you can select the File and Printer Sharing box in the Exceptions page of the Windows Firewall configuration to enable the access. IBM Tivoli Remote Execution and Access (RXA) prerequisites If RXA is used to communicate with the target computers, the following RXA prerequisites must be met: v Ensure that the service Remote Registry Service is enabled and running, so that the RXA service access point can run commands and scripts. v The default hidden administrative disk shares (such as C$ and D$) are required. v On Windows XP Professional, Simple File Sharing must be disabled for RXA. Simple Networking forces all logins to authenticate as guest. A guest login does not have the authorizations necessary for RXA to work. To disable Simple File Sharing: 1. In a Windows Explorer window, click Tools > Folder Options, and then click the View tab. 2. In the Advanced settings list, clear the Simple File Sharing check box. 3. Click Apply and OK. v On Windows Vista and Windows Server 2008, share must be shared for the Guest or Everyone accounts, and password protected sharing must be disabled. To disable password protected sharing: 1. Click Control Panel > Networking and Internet > Sharing and Discovery. 2. Click the down arrow next to Password protected sharing. 3. Click Turn off password protected sharing. 4. Click Apply, and exit the Control Panel. v On Windows 2003 and XP, both ports 135 (RPC) and 445 (TCP) must be enabled on the target computers, to ensure successful communication using RXA. RXA first tries port 445 and, if 445 is disabled, it uses port 139 (NetBIOS over TCP/IP). v Additionally, on Windows Vista and Windows Server 2008, you might need to modify the registry entry to disable User Account Control when you administer a workstation with a local user account (Security Account Manager user account). Otherwise, you will not connect as a full administrator and will not be able to perform administrative tasks. To disable User Account Control, perform the following steps: 1. Click Start. 2. Click Run and type regedit. Press Enter. 3. In the left pane, browse to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ Policies\system\ folder. 4. Right-click a blank area in the right pane. 5. Click New. 6. 7. 8. 9. 10. 11. Click DWORD Value. Type LocalAccountTokenFilterPolicy. Double-click the item that you created. Type 1 in the box. Click OK. Restart your computer.
551
Alternatively, you can modify the registry entry manually by typing the following command line: cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\ system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f v Review the local security policies on the computer. Check for any policies that are blocking required ports and modify them so that traffic is allowed on those ports. 1. Open the Windows Control Panel and double-click Administrative Tools. 2. Double-click Local Security Policy. 3. Click IP Security Policies on Local Computer. If Microsoft Active Directory is installed, click IP Security Policies on Active Directory. 4. Click Actions > Manage IP filter lists and filter actions. 5. Check each filter for the required ports. 6. If required ports are defined with a filter, review each of the defined IP security policies and ensure that none of the policies are configured to block traffic on the required ports. RXA uses an internal run timeout value for internal commands during connection attempts and most remote communications. v For UNIX targets, the default value is set to five seconds. v For Windows targets, the default value is set to zero, which is an infinite timeout. In most cases, the default settings must not be changed. However, if the default timeout for your UNIX targets needs to be increased or set to zero, you can set it at system level, by completing the following steps: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. 3. 4. 5. Click the Variables tab. Click New Row. Add a variable named rxa.internalruntimeout and set the required value in milliseconds. Create the same variable for the target computer's RXA SAP.
The RXA SSH service access point (SAP) is used during the RXA SSH discovery. UNIX requirements for common agent installation: Before installing the common agent on UNIX, verify the following prerequisites. The following additional requirements apply to UNIX target computers. The Java XMLEncoder/Decoder classes depend on libawt. Your operating system environment might not have the particular package that includes all of the libraries needed by libawt. Install the missing required packages, if any.
552
Table 91. UNIX requirements Requirement

UNIX
Details v On many UNIX systems, the response to the su (switch user) command includes a standard message of the day. Because the provisioning server cannot distinguish the message of the day from the command prompt, the message of the day can cause an error when you install the common agent from the Install Common Agent page. To address this problem, create a $HOME/.hushlogin file with a length of 0 bytes in the directory for the user associated with the Common Agent service access point. You can create this file by running the command touch .hushlogin in the appropriate user directory. On HP-UX, adding the .hushlogin file does not prevent the message of the day from interfering with the common agent upgrade. Instead, perform the following operations: 1. Remove /etc/motd if it exists, or comment out the motd line in the global profile /etc/profile 2. Comment out the copyright line in the global profile/etc/profile 3. Edit the .profile file for root. Remove all lines but leave any lines with path information. For example, PATH=/usr/sbin:$PATH:/sbin:/home/root. v You can install the common agent on UNIX target computers using a non-root user. Perform the following steps: 1. Manually create a non-root user account on the target computer with system administrator privileges. 2. Discover the target computer using SSH using the account information of the non-root user, or manually add it to the data model. If the computer is manually added, use the TCA_Manage_Platform_Capabilities.wkf provisioning workflow to populate the discovery information. Use the following parameters in the provisioning workflow: DeviceID Target computer ID osFamily One of the following values: Linux, AIX, HP, Windows architecture One of the following values: s390, powerpc, intel 3. Follow the instructions in Installing the common agent on page 570 for -su and -sudo installations. 4. You can now install the common agent using a non-root user. No further credentials are required when you run the common agent installation. Note: A root password is required to install and run the agent. Non-root installation is not supported and is not recommended. If required you can use the workflows to provide a non-root account with which to log into the target for audit/tracking purposes.
AIX
v On AIX 5.2 target computers, the runtime code, which is a prerequisite of GSKit7, is required. The xlC.rte 6.0 runtime code can be downloaded as a fix from the AIX Web site at http://www-933.ibm.com/support/fixcentral/. v The minimum AIX version to run Java5 is AIX 5.2 ML7 or above (IBM System p 64-bit) 32-bit emulation and AIX 5.3 with ML3. v On AIX target computers, install the X11 file sets. Specifically, install X11.base.rte to obtain file libgair4.a. This file is a prerequisite for the Java XML Encoder/Decoder classes.
553
Table 91. UNIX requirements (continued) Requirement

Solaris
Details v The OS Patch-ID# 112438-03 patch is required. v You might get the following error message if the patch is not installed. COPCOM123E A shell command error occurred: Exit code=137, Error stream=" ld.so.1: tar: fatal: libc.so.1: version `SUNW_1.22 not found (required by file tar) Killed ", Output stream="".
HP UX
v The PHCO_34275 HP-UX cumulative patch is required. Obtain the patch from the HP Support Web site, at http://www2.itrc.hp.com/service/home/home.do. v For HP-UX Itanium, the image file required for the common agent installation is provided separately, on Disk 6 (TPM_TIO_V71_Disk3_unix.tar.gz). Before attempting to install the common agent on this platform, manually copy the common_agent_1.4.1.0_hpux_IA64_full_200711070832.tar file from Disk 6 to the $TIO_HOME/repository folder. v Ensure that the kernel parameter max_thread_proc is set to at least 128. The default value is 64.
Linux requirements for common agent installation: Before installing the common agent on Linux, verify the following prerequisites. The following additional requirements apply to Linux target computers. The Java XMLEncoder/Decoder classes depend on libawt. Your operating system environment might not have the particular package that includes all of the libraries needed by libawt. Install the missing required packages, if any.
554
Table 92. Linux requirements Requirement

Linux
Details v On RHEL target computers, the 32-bit versions of all the required compatibility packages must be installed, in the specified order. All Red Hat Enterprise Linux 4.0 operating systems compat-libstdc++-33-3.2.3-47.3.i386.rpm xorg-x11-deprecated-libs-6.8.1-23.EL.i386.rpm Red Hat Enterprise Linux 4.0 64-bit operating systems On Red Hat Enterprise Linux 4.0 64-bit operating systems, the following 32-bit compatibility packages are required: libgcc-3.4.3-9 compat-libstdc++-33 v On RHEL and SUSE Linux Enterprise Server target computers, verify that you can run the ping localhost command successfully. If you receive an error, there might be a problem with the format of your hosts file. The file must include: The IP address, fully qualified domain name, and host name of the computer where you are running the installer as the first entry The IP address 127.0.0.1, the fully qualified domain name localhost.localdomain, and the host name localhost The following example shows settings for a computer with the host name river: #IP address 10.0.0.12 127.0.0.1 Fully Qualified Domain Name river.example.com localhost.localdomain Short Name river localhost
Note: Linux installations differentiate between the IP address for the localhost host name and the actual host name of the computer. Ensure that your /etc/hosts file includes the static IP address for both localhost and the actual host name of the computer. v On RHEL, version 6 and 5 target computers, the following compatibility packs are required: libgcc compat-libstdc++-33 libXtst-1.0.1-3.1.i386.rpm libXt-1.0.2-3.1.fc6.i386.rpm libXp-1.0.0-8.1.el5.i386.rpm libXmu-1.0.2-5.i386.rpm libXext-1.0.1-2.1.i386.rpm libSM-1.0.1-3.1.i386.rpm libICE-1.0.1-2.1.i386.rpm v On RHEL, (x86 32 and 64-bit) version 6 and 5 target computers, ensure that enhanced security is disabled and there is no firewall. To install the common agent: 1. Run the getenforce command to determine if a firewall is enabled. 2. Run the setenforce 0 command to disable it. 3. Install the common agent. 4. Run he setenforce 1 command to re-enable it. 5. Ensure no other firewall is enabled.
555
Table 92. Linux requirements (continued) Requirement Details You can install the common agent on Linux target computers using a non-root user. Perform the following steps: 1. Manually create a non-root user account on the target computer with system administrator privileges. 2. Discover the target computer using SSH using the account information of the non-root user, or manually add it to the data model. If the computer is manually added, use the TCA_Manage_Platform_Capabilities.wkf provisioning workflow to populate the discovery information. Use the following parameters in the provisioning workflow: DeviceID Target computer ID osFamily One of the following values: Linux, AIX, HP, Windows architecture One of the following values: s390, powerpc, intel 3. Follow the instructions in Installing the common agent on page 570 for -su and -sudo installations. 4. You can now install the common agent using a non-root user. No further credentials are required when you run the common agent installation. Note: A root password is required to install and run the agent. Non-root installation is not supported and is not recommended. If required you can use the workflows to provide a non-root account with which to log into the target for audit/tracking purposes.
Requirements for Windows target computers

Ensure that the following prerequisites are met on all the target computers running Windows. Components such as the common agent can optionally use the IBM Tivoli Remote Execution and Access (RXA) protocol to perform system operations. If RXA is used to communicate with the targets, ensure that they meet the RXA prerequisites. The following sections describe the requirements for Windows target computers: v All Windows target computers v v v v v v Windows XP target computers on page 557 Windows Server 2008 target computers on page 557 Windows 7 target computers on page 558 Disabling User Account Control on page 558 Internet Connection Firewall (ICF) on page 559 RXA internal timeout value on page 559
v Protocols on page 559 v Common agent requirements on page 559
All Windows target computers

For all Windows target computers, ensure that you meet the following requirements: v The target computers must have remote registry administration enabled. v The default hidden administrative disk shares (such as C$ and D$) are required. v On Windows 2003 and XP, both ports 135 (RPC) and 445 (TCP) must be enabled on the target computers, to ensure successful communication using RXA. RXA first tries port 445 and, if 445 is disabled, it uses port 139 (NetBIOS over TCP/IP).
556
v Additionally, on Windows Vista and Windows Server 2008, you might need to modify the registry entry: 1. Click Start. 2. Type regedit, and press Enter. 3. In the left pane, browse to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ Policies\system\ folder. 4. Right-click a blank area in the right pane. 5. Click New. 6. Click DWORD Value. 7. Type LocalAccountTokenFilterPolicy. 8. Double-click the item that you created. 9. Type 1 in the box. 10. Click OK. 11. Restart your computer. v If Windows Scripting Host (WSH) or the WMI service is disabled on the target, or if VBScript is otherwise disabled, some Windows Protocol methods do not work. For all Windows target computers, after you meet all requirements, ensure that the Remote Registry Service is enabled and started. The default startup type for the Remote Registry service is manual. The Remote Registry service must be running to enable RXA. To check if the Remote Registry service is enabled and started, perform the following steps: 1. In the Start search box, enter services.msc and press ENTER. 2. In the console pane of the Microsoft Management Console, ensure that the service status is started. If not, right-click Remote Registryand click Start. To avoid problems with the manual startup, set the Remote Registry service startup type to automatic. If you want to automatically start the service after the server boot, perform the following steps: 1. Right-click Remote Registry and select Properties. 2. In the Startup type option, choose Automatic. 3. Click Apply and OK. When the system starts, Remote Registry starts automatically.
Windows XP target computers

For Windows XP target computers, ensure that you meet the following requirements: v Windows XP systems must have Simple File Sharing disabled for Remote Execution and Access to work. Simple Networking forces all logins to authenticate as guest. A guest login does not have the authorizations necessary for Remote Execution and Access to function. v To disable Simple File Sharing, start Windows Explorer and click Tools Folder Options. Select the View tab and scroll through the list of settings to Use Simple File Sharing. Deselect Use Simple File Sharing. Click Apply and OK. v Windows XP includes a built-in firewall called the Internet Connection Firewall (ICF). By default, ICF is disabled on Windows XP systems. Windows XP Service Pack 2 comes with the Windows Firewall on by default. If either firewall is enabled on a Windows XP or Vista target, it blocks attempted accesses by Remote Execution and Access. To allow access on XP Service Pack 2, select the File and Printer Sharing box in the Exceptions tab of the Windows Firewall configuration.
Windows Server 2008 target computers

For Windows Server 2008 target computers, ensure that you meet the following requirements:
557
v You can use either a local administrator account or a domain administrator account for the agent installation on Windows. On Windows Server 2008 you might need to disable User Account Control. See the section on Windows Vista to learn how to disable User Account Control. v On Windows Server 2008 disk shares must be shared for the Guest or Everyone accounts, and password protected sharing must be disabled. To disable password protected sharing on Windows Server 2008, perform the following steps: 1. Click Control Panel and select Network and Sharing Center. 2. Click Advanced Sharing Settings. 3. Click Turn off password protected sharing. 4. Click Save Changes.
Windows Vista target computers

For Windows Vista target computers, ensure that you meet the following requirements: v On Windows Vista systems disk shares must be shared for the Guest or Everyone accounts, and password protected sharing must be disabled. To disable password protected sharing on Windows Vista systems, perform the following steps: 1. Click Control Panel->Networking and Internet ->Sharing and Discovery. 2. Click the down arrow that is next to Password protected sharing. 3. Click Turn off password protected sharing. 4. Click Apply and exit the control panel. The new User Account Control feature in Windows Vista requires users to perform several steps before RXA applications can communicate with Vista target computers. If you have a domain user account, ensure that the local and the target computer are both members of a Windows domain. If you are a member of a local administrators group and you use a local user account, complete the following three steps to perform administrative tasks on the target computer: 1. Enable the built-in Administrator account and use it to connect. To enable the built-in Administrator account, open the Windows Control Panel and click Administrative Tools ->Local Security Policy ->Security Settings ->Local Policies ->Security Options. Then double-click on Accounts: Administrator account status and select Enable. 2. Disable User Account Control if a different Administrator user account is to be used to connect to the Vista target. To disable User Account Control, open the Windows Control Panel and click Administrative Tools ->Local Security Policy ->Security Settings ->Local Policies ->Security Options. Then double-click User Account Control: Run all administrators in Admin Approval Mode and select Disable. Changing this setting requires a system reboot. 3. Disable User Account Control when you administer a workstation with a local user account (Security Account Manager user account). Otherwise, you cannot connect as a full administrator and cannot perform administrative tasks.
Windows 7 target computers

For Windows 7 target computers, ensure that you meet the following requirements: v Enable the built-in Administrator account and use it to connect. To enable the built-in Administrator account, open the Windows Control Panel and click Administrative Tools ->Local Security Policy ->Security Settings ->Local Policies ->Security Options. Double-click Accounts: Administrator account status and select Enable.
Disabling User Account Control

To disable User Account Control, perform the following steps: 1. Click Start ->Run.
558
2. Type regedit, 3. Press ENTER. 4. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ CurrentVersion\Policies\System
5. If the LocalAccountTokenFilterPolicy registry entry does not exist, follow these steps: a. On the Edit menu, click New ->DWORD Value. b. Type LocalAccountTokenFilterPolicy, and then press ENTER. c. Right-click LocalAccountTokenFilterPolicy, and then click Modify. d. In the Value data box, type 1, and click OK. e. Restart your computer. 6. Alternatively, you can modify the registry entry manually by using the following command line:
cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows \CurrentVersion\Policies\ system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Internet Connection Firewall (ICF)

Windows XP, Windows Vista, and Windows Server 2008 include a built-in firewall called the Internet Connection Firewall (ICF). By default, ICF is disabled on these systems. Windows XP Service Pack 2 (SP2) comes with the Windows Firewall enabled by default. If either firewall is enabled on a Windows XP, Windows Vista, and Windows Server 2008 target, it blocks attempted accesses by RXA. On Windows XP SP2, select the File and Printer Sharing box in the Exceptions tab of the Windows Firewall configuration to enable access.
RXA internal timeout value

RXA uses an internal run timeout value for internal commands during connection attempts and most remote communications. v For UNIX targets, the default value is set to five seconds. v For Windows targets, the default value is set to zero, which is an infinite timeout. In most cases, the default settings must not be changed. However, if the default timeout for your UNIX targets needs to be increased or set to zero, you can set it at system level, by completing the following steps: 1. 2. 3. 4. 5. Click Go To > Administration > Provisioning > Provisioning Global Settings. Click the Variables tab. Click New Row. Add a variable named rxa.internalruntimeout and set the required value in milliseconds. Create the same variable for the target computer's RXA SAP.
The RXA SSH service access point (SAP) is used during the RXA SSH discovery.
Protocols
IPv4 is the protocol supported by the provisioning server.
Common agent requirements

The common agent is required to take advantage of all patch management features.
559
If you do not plan to install the common agent on the target computers, consider configuring OpenSSH and OpenSSL to secure communication between the provisioning server and the targets. Note: If you are using OpenSSH: v Use version 4.4 or higher. Version 4.3 has a known issue that can cause Expect scripts that the provisioning server runs on target computers to fail. v Ensure that you use password authentication to secure communication between the provisioning server and the targets. For more information, see Requirements for common agent installation on page 547.
Requirements for Red Hat Linux target computers

Ensure that the following prerequisites are met on all target computers running Red Hat Linux. For additional prerequisites for the common agent installation, see Requirements for common agent installation on page 547.
Table 93. Requirements for Red Hat Linux Requirement Command prompt Details When running scriptlets, Tivoli Provisioning Manager requires that the command prompt ends in $, #, or >. The PS1 environment variable governs the appearance of the prompt. If you change this variable on your target computer (managed-to) or provisioning server (managed-from), you might encounter problems when running provisioning workflows. The following examples show the command prompts that you can use: command$ $ command# # command> > RPM packages v up2date agent v OpenSSH v ftp v perl v wget v yum v PyXML v expect Note: The Expect installation is only required to be installed on a target computer if a certain provisioning automation package workflow runs expect code on the target computer itself. This installation is optional depending on the requirements.
560
Table 93. Requirements for Red Hat Linux (continued) Requirement Compatibility packages Details On all supported Red Hat Enterprise Linux 4.0 operating systems, the 32-bit versions of all the required compatibility packages must be installed in the specified order: All Red Hat Enterprise Linux 4.0 operating systems compat-libstdc++-33-3.2.3-47.3.i386.rpm xorg-x11-deprecated-libs-6.8.1-23.EL.i386.rpm Red Hat Enterprise Linux 4.0 64-bit operating systems libgcc-3.4.3-9 compat-libstdc++-33 Compatibility packages are required on Red Hat Enterprise Linux 6 and 5 for installing the common agent. For more information, see Requirements for common agent installation on page 547. Package locations The location of the shells or script interpreters is also important because scripts that are run must include this information about the first line of the script. Ensure that the packages are installed in the following locations: v Bash locations: /bin/bash v Expect Locations: /usr/bin/expect v Perl : /usr/bin/perl v Python: /usr/bin/python Note: The Expect installation is only required to be installed on a target computer if a certain provisioning automation package workflow runs expect code on the target computer itself. This installation is optional depending on the requirements. TCP port Ensure that TCP port 9510 is open on the target computers.
Requirements for SUSE Linux Enterprise Server (SLES) target computers

Ensure that the following prerequisites are met on all target computers running SUSE Linux Enterprise Server (SLES). For additional prerequisites for the common agent installation, see Requirements for common agent installation on page 547.
Table 94. Requirements for SUSE Linux Enterprise Server (SLES) Requirement Command prompt Details When running scriptlets, Tivoli Provisioning Manager expects that the command prompt ends in $ , # or >. The PS1 environment variable governs the appearance of the prompt. If you change this variable on your target computer (managed-to) or provisioning server (managed-from), you might run into problems running provisioning workflows. The following examples show command prompts you can use: command$ $ command# # command> >
561
Table 94. Requirements for SUSE Linux Enterprise Server (SLES) (continued) Requirement Packages and locations Details v perl 5.8 v expect 5.34 v bash 2.05 The location of the shells or script interpreters is also important because scripts that are run must include this information about the first line of the script. Ensure that the packages are installed in the following locations: v Bash locations: /bin/bash v Expect Locations: /usr/bin/expect v Perl : /usr/bin/perl Note: The Expect installation is only required to be installed on a target computer if a certain provisioning automation package workflow runs expect code on the target computer itself. This installation is optional depending on the requirements. TCP port Ensure that TCP port 9510 is open on the target computers.
Requirements for AIX target computers

Ensure that the following prerequisites are met on all the target computers running AIX. For additional prerequisites for the common agent installation, see Requirements for common agent installation on page 547.
Table 95. Requirements for AIX Requirement Command prompt Details When running scriptlets, the provisioning server expects that the command prompt ends in $, # or >. The PS1 environment variable governs the appearance of the prompt. If you change this variable on your target computer (managed-to) or provisioning server (managed-from), you might run into problems running provisioning workflows. The following examples show command prompts you can use: command$ $ command# # command> > There has to be a blank character at the end of the prompt on AIX target computer in order to run on it a workflow containing a scriptlet (bash / perl). If a blank character is not present at the end of the prompt then the scriplets (both perl and bash) called inside a workflow stop and do not return to executing workflow. Required packages v openSSH 4.4 or later v bash v Expect 5.4 or later (required for compliance patch management) Tip: OpenSSH for AIX 5 can be obtained from https://sourceforge.net/projects/ openssh-aix.
562
Table 95. Requirements for AIX (continued) Requirement Package locations Details The location of the shells or script interpreters is important because scripts that are run must include this information about the first line of the script. Ensure that the packages are installed in the following locations. v Bash location: /usr/bin/bash v Expect location: /usr/bin/expect v Perl location: /usr/bin/perl Note: Expect is only required to be installed on a target computer if a certain automation package runs expect code on the target computer itself. This installation is optional depending on the requirements. The runtime code, which is a The xlC.rte 6.0 runtime code can be downloaded as a fix from the AIX Support site prerequisite of GSKit7 on at: https://techsupport.services.ibm.com/server/aix.fdc. AIX 5.2.
Requirements for Solaris Operating Environment target computers

Ensure that the following prerequisites are met on all target computers running Solaris. Note: Software distribution is supported on Solaris 9 and 10 (Sun SPARC or x64) computers. Patch management is supported only on the following Solaris computers: v v v v v Solaris Solaris Solaris Solaris Solaris 10 (AMD 64-bit) 10 (x86 64-bit) 10 (Sun SPARC) 9 (Sun SPARC) 8 (Sun SPARC)
For additional prerequisites for the common agent installation, see Requirements for common agent installation on page 547.
Table 96. Requirements for Solaris Requirement Command prompt Details When running scriptlets, the provisioning server expects that the command prompt ends in $, #, or >. The PS1 environment variable governs the appearance of the prompt. If you change this variable on your target computer (managed-to) or provisioning server (managed-from), you might run into problems running provisioning workflows. The following examples show command prompts you can use: command$ $ command# # command> >
563
Table 96. Requirements for Solaris (continued) Requirement Required packages Details Solaris 8 v SUNWlibc v SUNWxcu4 Solaris 9 v bash-2.05 v perl-5.8.4 v OpenSSL v openssh 4.4 or higher v zlib v wget-1.9.1 v libgcc-3.3 v expect-5.40 v gzip-1.3[1] v tcl-8.4.6-sol9 v tk-8.4.6-sol9 v SUNWxcu4 Solaris 10 v bash-3.2 (default shell) v openssl v opensshopenssh 4.4 or higher v wget-1.10.2 v expect-5.43.0 v gzip-1.3.5.10 v tcl-8.4.9 v tk-8.4.9 v SUNWmfrun v SUNWbrg v SUNWbrgr v SUNWzoner v SUNWzoneu v SUNWxcu4 v SUNWxwdv v SUNWxwice v SUNWxwfnt v SUNWxwrtl v SUNWxwplr v SUNWxwplt v SUNWctpls v SUNWj5rt v SUNWpool v SUNWpoolr
564
Table 96. Requirements for Solaris (continued) Requirement SUNWxcu4 package Details Note: To install the Solaris SUNWxcu4 package needed for Tivoli Common Agent: 1. Copy the "SUNWxcu4" package from Solaris install media and put it under /tmp 2. cd /tmp 3. pkgadd -d <package> 4. edit /etc/profile with the following lines PATH=/usr/xpg4/bin:/usr/ local/bin:/usr/sbin:/usr/binexport PATH Package locations The location of the shells or script interpreters is also important because scripts that are run must include this information about the first line of the script. Ensure that the packages are installed in the following locations: v Bash locations: /bin/bash v Expect Locations: /usr/bin/expect Note: The Expect install is only required to be installed on a target computer if a certain provisioning automation package workflow executes expect code on the target computer itself. This install is optional depending on the requirements. Patch required for common agent installation On Solaris target computers, the OS Patch-ID# 112438-03 patch is required for the successful installation of the common agent.
Requirements for HP-UX target computers

Ensure that the following prerequisites are met on all target computers running HP-UX 11i. For additional prerequisites for the common agent installation, see Requirements for common agent installation on page 547.
Table 97. Requirements for HP-UX Requirement Command prompt Details When running scriptlets, Tivoli Provisioning Manager requires that the command prompt ends in $, #, or >. The PS1 environment variable governs the appearance of the prompt. If you change this variable on your target computer (managed-to) or provisioning server (managed-from), you might have problems when running workflows. The following examples show command prompts you can use: command$ $ command# # command> >
565
Table 97. Requirements for HP-UX (continued) Requirement Required packages Details HP-UX 11i v bash-3.2 bash requires the following packages: libiconv termcap gettext v expect-5.43.0 v openssl v openssh 4.4 or higher v zlib v libgcc-3.3 v gzip-1.3.5.10 v perl-5.8.7 v wget-1.10.2 Package locations The location of the shells or script interpreters is also important because scripts that are run must include this information about the first line of the script. Ensure that the packages are installed in the following locations: v Bash: /bin/bash v Expect: /usr/bin/expect v Perl: /usr/bin/perl v Sh: /usr/bin/sh Note: The Expect installation is only required to be installed on a target computer if a certain provisioning automation package workflow runs expect code on the target computer itself. This installation is optional depending on the requirements. Patch required for the common agent installation On HP-UX target computers, the PHCO_34275 HP-UX cumulative patch is required for the successful installation of the common agent. You can obtain the patch from the HP Support Web site, at http://www2.itrc.hp.com/ service/home/home.do.
Installation media for software distribution

Ensure that you have the installation files for the software that you want to distribute. Software that you install with provisioning workflows. Commands, installation settings, product configuration, and installation requirements for a software product can vary with each version of the software product. It is therefore important to check the version of installation files that you want to deploy and verify that you are using provisioning workflows that support the same version of the software. For example, The list of predefined software definitions provided in the Software Product application includes IBM Htttp Server for version 2.0.47.1 of the product. To deploy IBM HTTP Server with this software definition, you must use the installation media for this specific version level, IBM HTTP Server 2.0.47.1. If you try to deploy a different version of HTTP server using the settings in this software definition, the installation might fail.
566
Tutorial: Software deployment

This tutorial demonstrates software deployment on a large group of target computers using the infrastructure solution for a scalable software distribution provided with Tivoli Provisioning Manager. This solution offers support for a number of software distribution services and enables the management of large numbers of target computers in a variety of topologies. The scalable distribution infrastructure provides a fast and reliable way to distribute and install software on target computers or groups of computers. In this tutorial, you will first discover all of the computers to work with, then create a provisioning group of computers. You will define the scalable distribution infrastructure that consists of a region, zone, and depot server. You will install the common agent and subagents and configure the computers to be used with this infrastructure. You will scan the computers for hardware and software and run common agent health status reports. You will open an existing software package block in the Software Package Editor and then save it to the local file repository, which will add it to the Tivoli Provisioning Manager software catalog. You will then create a correlation between the software signature and the software module associated with the software package block. To speed up the download and software distribution process, you will first publish the software package block to the depot server, and then will distribute and install the software package block on all of the target computers in your group. Finally, you will run inventory and deployment reports to verify the successful software deployment on all of the target computers in your group.
Learning objectives
In this tutorial you will: v Learn how to discover computers. v Learn how to create a provisioning group. v Learn how to install the common agent on the target computers in the provisioning group, and how to configure them. v v v v v v Learn Learn Learn Learn Learn Learn how how how how how how to to to to to to define regions, zones, and depot servers for the scalable software distribution. set up and run a Tivoli Provisioning Manager inventory scan. run the common agent discovery and health status report. save software package blocks to the Tivoli Provisioning Manager local file repository. create and correlate a software signature with a software module. publish, distribute, and install a software package block on a group of computers.
v Learn how to validate the software installation. v Learn how to run software inventory reports to verify the successful software installation. Allow 90 minutes to discover your target computers, set up the infrastructure, configure the targets, and publish, distribute, and install the software on them.
Prerequisites
Ensure that you meet all requirements described in Requirements on page 546. The following additional requirements apply to this scenario: Before you start, you need the following: v A provisioning server. v One Windows depot server. v One or more Windows target computers to install software on.
567
Restriction: The depot server and the target computer must not be the same.
Part 1: Discovery
Discovery provides a way to find out or discover new devices. The discovered devices are added to the Tivoli Provisioning Manager data model. The data model is a centralized repository, which contains all the physical and logical assets that Tivoli Provisioning Manager can manage.
Discovering your target computers

To discover your target computers, create a discovery configuration. This operation searches for devices that are unknown to Tivoli Provisioning Manager, and adds them to the data model. For existing resources, the discovery updates the data model with any new or changed information. Your target computers must meet the requirements in the Requirements for Windows target computers on page 556 topic. To discover your computers: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. Tip: To perform this task from the Start Center, click Discovery Configurations under Provisioning administration applications or Discovery and task applications. Search for the discovery configuration called Initial Discovery and click its name on the displayed list. Click the IP Address Ranges tab. Click New Row. In the Start and End fields, type the IP addresses of your target computers. After each set of IP addresses, click New Row.
2. 3. 4. 5.
Tip: You can also specify subnetworks that you want to discover. If, for example, all the target computers that you want to discover are in a LAN, click the Subnetworks tab and specify the IP address and mask for the LAN. After specifying each subnetwork, click New Row. 6. Click the Credentials tab. 7. Click New Row. 8. Type the user ID and password. After each set of credentials, click New Row. If you specify more than one set of credentials, they will be attempted on each target computer in the order that they are listed. If the logon attempt on a target computer is successful, the computer is added to the data model. Notes: v The system will attempt to connect to each IP address using each user name and password provided until it finds a user name and password that can be used to connect successfully. This might cause user accounts to be locked out, depending on the security policy enforced on the target computers. v You might need to increase the default timeout value if you are on a slower network or you are attempting to discover slower computers. 9. 10. 11. 12. . Click Save Click Run Discovery. Type a name for the discovery task and click Submit. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed.
568
You have created a discovery configuration and run it to discover your targets. These target computers are now part of the data model.
Generating a discovery report

After you have run a discovery and populated the data model, you can quickly run a discovery report. Discovery reports show the last discovery scan results by computers and discovery configuration. You can generate a discovery report to view a list of computers discovered along with discovery configuration information. To 1. 2. 3. 4. generate a discovery report: Click Go To > Administration > Reporting > Report Administration. Find the report with the file name tp_objectsDiscovered.rptdesign and click the report name. Click Generate Request Page. After the report is generated, click Close. The report lists the computers discovered, the discovery configuration that was used to discover them, and the discovery method used. Tip: If no computers are listed in the report, your SMB setup might be incorrect. For more information about what is required to configure the target computers for discovery, see Requirements for Windows target computers on page 556. 5. Click Preview and in the window that is displayed click Submit. You can now group these computers together so you can work with multiple computers at the same time.
Creating a provisioning group

Defining provisioning groups is a way of organizing managed computers to facilitate software distribution, compliance, patch management, and other tasks. Create a provisioning group populated with all the target computers that you want to work with. Important: Do not add the computer that you want to use as a depot server to this group because you are not managing software for the depot server together with the target computers in the provisioning group. To create a provisioning group: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. 2. 3. 4. 5. . Click New Type a name and a description for the new group, for example, Test group. Click the icon for the Member Type field and click Computer. Click Add Members and select the target computers that you want to add to your provisioning group, then click OK. .
6. Click Save
The provisioning group is created and listed on the Provisioning Groups page. You are ready to define the global configuration settings for the common agent installation.
Defining the global agent configuration

After you have discovered your computers and created a provisioning group for them, you can define the global settings for the common agent installation.
569
Configuring the common agent installation options is required only once, and is done at the software configuration template level. Installation options such as such as the JES polling interval, the dynamic content delivery peering, or the maximum dynamic content delivery cache size can be configured. Defining the global agent configuration can include: v Changing the common agent default port number on page 651 v Overriding the default common agent installation path on page 653 v Changing the default polling interval on page 542 v Configuring the default peering cache on page 655

The common agent is a software product that provides infrastructure for management applications. The common agent installed on the target computers provides remote deployment capability, shared resources, secure connectivity, and a single entry point.
UNIX . If you plan to install the common agent as a non-root user, the common agent installation task must start either the su or sudo command to obtain root permissions during the installation. Depending on which command you will use, follow these steps before you install the common agent:
Enabling su to obtain root permissions for the installation 1. Manually create a non-root user account on the target computer with system administrator privileges. 2. Manually set the umask value to 002 for the root user on the target computer. To do so, make the following changes:
Table 98. Umask updates required Shell used by root Korn Bash AIX Required setting In the home folder for root, add umask 002 to the .profile file. In the home folder for root, add umask 002 to the .bash_profile and .bashrc files. In the file /etc/security/user, change the umask setting for root to 002.
If a umask setting already exists, change the value to 002. You can return the setting to its original value after installation. 3. Run the TCA_Manage_No_root_SSH_SAP workflow to populate the root password in the credentials of the target SAP. Use the following parameters in the TCA_Manage_No_root_SSH_SAP workflow:
Table 99. Parameters Parameter DeviceID userName userPassword rootPassword Description The target computer ID. The non-root username you created in step 1. The non-root user password you created in step 1. The root account password. If the su - command does not require a password, enter unspecified for the rootPassword parameter. If no SAP is present, one is created with the non-root user and password that you provide.
Enabling sudo to obtain root permissions for installation 1. Manually create a non-root user account on the target computer with system administrator privileges.
570
2. Configure the /etc/sudoers file on the target computers to allow the non-root user to run the following commands as root:
df test -d * rm -rf /tmp/tcatemp rm -rf ep* /tmp/tcatemp/tcainstall.sh /tmp/tcatemp/setup.* [UNIX/Linux] /opt/tivoli/ep/_uninst/uninstall [AIX] /usr/tivoli/ep/_uninst/uninstall
Note: The commands or scripts in the list above must be configured in the /etc/sudoers file with full path information. Only those provided by Tivoli Provisioning Manager include the full path information. The full path to the remaining entries is not included because it varies from one UNIX distribution to the next. Provide this information for your particular system when you configure them in your /etc/sudoers file. For Linux operating systems, comment out or delete the line containing Defaults requiretty:
#Defaults requiretty
3. Sudo must be configured to either prompt for the password of the current user, or not require a password. If it prompts for a password using a non-default password prompt, see Enabling custom password prompts using sudo. 4. You can change the Install_Using_Sudo parameter in the TCA default configuration template, available in both the Tivoli Common Agent Stack and the CDS_Depot_Stack configuration templates. Each stack contains its own unique copy of the Install_Using_Sudo template parameter. If a change is required in both places, perform the procedure in both stacks. Use the following parameters in the TCA_Manage_No_root_SSH_SAP workflowTo use sudo for the current task only, perform step 5 on page 572 in the following procedure. Otherwise, to use sudo for all common agent installation tasks, perform the following procedure: a. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. b. Click Tivoli Common Agent Stack or CDS_Depot_Stack. c. Under Configuration Templates, click TCA default. <number>. d. Under Template Parameters, click the Install_Using_Sudo parameter icon. e. Set the Parameter Value to true. f. Click Save. The following is a sample of the /etc/sudoers file, where the non-root user is peter and the hostname of the target computer where the TCA is to be installed is nc117093:
# sudoers file. # # This file MUST be edited with the visudo command as root. # Failure to use visudo may result in syntax or file permission errors # that prevent sudo from running. # # See the sudoers man page for the details on how to write a sudoers file. # # Host alias specification Cmnd_Alias INSTALL_TPM_AGENT=/usr/bin/df,/usr/ bin/test -d *,/bin/rm -rf /tmp/tcatemp,/bin/rm -rf ep*,/tmp/tcatemp/tcainstall. sh,/tmp/tcatemp/setup.*,/usr/tivoli/ep/_ uninst/uninstall,/usr/bin/s cp # User alias specification # Cmnd alias specification # Defaults specification # Runas alias specification # User privilege specification root ALL=(ALL) ALL peter nc117093=(root) NOPASSWD: INSTALL_TPM_AGENT # Uncomment to allow people in group wheel to run all commands # %wheel ALL=(ALL) ALL # Same thing without a password
571
# # # #
%wheel ALL=(ALL) NOPASSWD: ALL Samples %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom %users localhost=/sbin/shutdown -h now
The common agent can be installed one time on each target computer. After the common agent is installed on a target computer, subsequent subagents can be deployed on the existing common agent. To install the common agent on all the target computers in your provisioning group: 1. Click Go To > Deployment > Software Management > Common Agent Installation. 2. Under Common Agent Stacks, select the common agent software stack to install on the target computers. The default software stack is Tivoli Common Agent Stack. 3. Click Select > Groups and select the provisioning group that you want to work with, for example, Test group, then click OK. 4. Clear the Create Credentials check box. No credentials are required, as they were added to your target computers during discovery. 5. If you are using sudo to install the common agent with a non-root user: a. Click the Advanced tab. b. Under Configuration Templates, click TCA default. <number>.
UNIX
c. Under Template Parameters, click the Install_Using_Sudo parameter icon. d. Set the Parameter Value to true. 6. Click Schedule to specify the date and time when you want the task to start. 7. Click Submit. When you submit the task, the Provisioning Task Tracking page is displayed. You can click the task name to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status. You have installed the common agent on all the computers in your provisioning group. Tip: To view the status of agent installations from the Start Center, expand the Agents status portlet. You are ready to configure the target computers for software distribution using the scalable distribution infrastructure.
Part 2: Configuration
The configuration tasks ensure that the infrastructure for a scalable distribution infrastructure exists and all of the target computers are properly configured to use this infrastructure. Inventory and common agent discovery scans determine what hardware and software is installed on the target computers, and provide agent status information that enables you to evaluate the health status of the common agent on the target computers.
Creating the infrastructure for scalable software distribution

Creating the infrastructure for a scalable software distribution means creating a region, a zone, and a depot server that will be used to deploy the software to the target computers. Creating a region: Regions are used to group depot servers that are located near one another to optimize upload, replication, and download times. When you create a depot server, you must associate it with a region. You can assign a depot server to only one region. To create a region:
572
1. 2. 3. 4.
Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. Click the Regions tab. Click New Row. Type a name and a description for the new region. .
5. Click Save
The newly created region is now listed on the Regions page. After you have defined the region, you can add the depot server that will be used for software distribution. Adding a depot server: A depot server is a system that stores files for distribution. Distribution files are uploaded to a depot server using a client. Depot servers can replicate uploaded files to other depot servers to optimize the efficiency of network traffic. The target computers download the files from the depot server. To add a new depot server: 1. Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. 2. Click the Depots tab. 3. Click New Row. 4. Type a name for the depot server. 5. In the Region field, select the region that you have just created. This is region the new depot server will be assigned to. 6. In the Computer field, search for and select the name of the target computer that you want to configure as a depot server. The depot server must not be included in your group. 7. In the IP Address field, specify the IP address of the depot server. 8. In the Fully qualified host name field, type the fully qualified domain name of the depot server that has already been discovered using the SMB discovery. 9. Select the Install the depot agent services check box and specify the credentials to install the depot agent services. If you do not select this option, the depot is only added to the data model. 10. Select the Preferred upload server check box. If using multiple depot server, at least one depot must be selected as a preferred upload server. 11. Leave all of the other default options unchanged. 12. Click Save .
The depot is added. If you selected the Install the depot agent services check box, a task for adding the new depot server is created. You can click the task name to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status. The newly added depot server with the specified properties is now listed on the Depots tab. Creating a zone: Use a zone to logically group systems within regions by defining an IP range or domain name. A region is generic if no zones are defined for it, or specific if zones are used to define domain names within it. To create a zone: 1. Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. 2. Click the Zones tab.
573
3. 4. 5. 6.
Click New Row. Type a name and a description for the new zone. In the Regions field, select the region that you have just created for the zone. Select Domain Name, and then specify the domain that your depot server and target computers are in. 7. Leave all of the other default options unchanged. 8. Click Save .
The newly created zone is now listed on the Zones tab. You are now ready to run a Tivoli Provisioning Manager inventory scan on the target computers to find out what hardware and software is already installed on them.
Running the Tivoli Provisioning Manager inventory scan

To find out what hardware and software is already installed on the target computers that you will be working with, set up and run a Tivoli Provisioning Manager inventory scan. The scan examines all target computers in your group and the depot server that you have just defined for installed hardware and software. Before you start the scan, ensure that Microsoft Active Directory is running, if present. To run a Tivoli Provisioning Manager inventory scan on your target computers: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. In the list, find the Tivoli Provisioning Manager Inventory Discovery configuration and click its name. 3. Select the Hardware and Software check boxes. 4. Select Use software signature. 5. Click Run Discovery. 6. Click Select > Groups and select the name of your group, then click OK. 7. Click Select > Computers and select the name of the depot server, then click OK. 8. Click Schedule to run the discovery task immediately, or schedule it to run at a specified date and time. 9. Under Notification, specify the appropriate notification options. 10. Click Submit. When you submit the task, the Provisioning Task Tracking page is displayed. Click the task name to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status. After the scan has completed successfully, you can see a list of all the software that has been discovered on a specified target computer: 1. Click Go To > Deployment > Provisioning Computers. 2. In the list, find the name of one of your target computers and click its name. 3. Click the Software tab. Under Software Installations, all the software products that the Tivoli Provisioning Manager inventory scan has discovered on that target computer are listed. You can run a common agent discovery scan and generate a health status report, to assess the current health status of the common agent installed on the target computers.
574
Running the common agent discovery and health status report

You can now run a common agent discovery scan on the agent manager database to discover information about the common agent health on the target computers. You can produce a report about the common agent status information. Running the common agent discovery scan: To 1. 2. 3. run the common agent discovery scan: Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. In the list, find the IBM Tivoli Common Agent Discovery configuration and click its name. Click Run Discovery.
4. Click Submit. 5. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The discovery task is displayed with a status of Success on the Provisioning Task Tracking page. Running the common agent health status report: You can run a health status report, to display the common agent status information generated during the common agent discovery scan. Tip: To view agent status information from the Start Center, expand the Agents status portlet. To generate a common agent health status report: 1. Click Go To > Administration > Reporting > Report Administration. 2. Find the report with the file name tp_endpoints.rptdesign and click its name. 3. Click Generate Request Page. 4. After the report is generated, click Close. The report lists agent status parameters such as the status, last contact time, last boot time, agent start time, last attempt time, last error message for each of the target computers, which allows you to assess the current health status of the common agent installed on the target computers. Note: Currently, only the following columns in the report are populated with data: Computer ID, Computer Name, Agent Name, Description, and Agent Check-In Time. 5. Click Preview and in the window that is displayed click Submit. The following Agent states and explanations are shown in the report: 1. Running: The Agent is running. 2. Stopped: The Agent has been stopped. 3. Uninstalled: The agent was installed on the system and it has been uninstalled outside of Tivoli Provisioning Manager. 4. Offline: The Agent is offline. Next, you will open an existing software package block (SPB) in Software Package Editor, and then save it to the Tivoli Provisioning Manager local file repository. This will create the software module that is required for the software distribution. You will also create a software signature for the software module, so that the software module can be discovered using a Tivoli Provisioning Manager inventory scan.
Part 3: Software publication, distribution, and installation

You can publish, distribute, and install software products that are defined in the Tivoli Provisioning Manager software catalog. First, open the software package block (SPB) to be deployed in Software
575
Package Editor, and then save it to the Tivoli Provisioning Manager local file repository. Before opening the software package block for the first time, ensure you configured the Software Package Editor. Then, you can create a software signature for the software module associated with the software package block. To speed up the download and software distribution, you can publish the software to a depot server before distributing and installing it on the target computers. You can perform the software publication, distribution, and installation using any one of the following methods: v For flexibility, you can perform separate tasks for software publication, distribution, and installation: 1. Create and run a software publication task first, which uploads the software to a depot server. 2. Create and run a software distribution task, which distributes the software to the target computers in your group. 3. Create and run a software installation task, which installs the already distributed software on the target computers. v If you have not published and distributed the software yet, you can directly start with the installation task that will perform all of these operations seamlessly. If the software has not been published and distributed, the installation task will perform a software publication to the depot server first, followed by a software distribution to selected target computers, and then a software installation on the target computers.
Configuring Software Package Editor properties

Before opening the software package block for the first time, ensure you configured the Software Package Editor properties. To set the Software Package Editor properties: 1. In the Software Package Editor window, click Settings > Preferences. 2. On the Preferences page, specify the following settings: v In the Web Server hostname field, type the fully qualified host name of the Tivoli Provisioning Manager server. v In the Web Server port field, ensure that it contains the default port number of the Web server, 9443. v Type SPE in the Web Server root path field. Check Use SSL if the Tivoli Provisioning Manager server uses HTTPS over SSL. In the Username field, type the Tivoli Provisioning Manager user ID. In the Password field, type the password defined at installation for this user ID. Type the Default file path used by the Software Package Editor each time you click Browse (...) on a panel, or when you open or save software packages. v Type a path to a temporary folder to where the Software Package Editor saves temporary files. 3. Click OK. v v v v The Software Package Editor is now configured to communicate with the Tivoli Provisioning Manager server. Using the Software Package Editor, you can now open a software package (SPB) that will be published, distributed, and installed on the target computers.
Saving the software package block to the local file repository

To have the software package block (SPB) added to the Tivoli Provisioning Manager software catalog, you must first open it in Software Package Editor, and then save it to the local file repository. The software package block file, TPM51_OS_Management_Viewlet.spb, can be obtained from the Tivoli Provisioning Manager version 5.1 Beta download website.
576
To be able to publish the software package block to the depot server and then distribute it to the target computers, you must ensure that a software module exists for the software package block. A correlation between a software signature and this software module can be created, and will be used to discover the software module with a Tivoli Provisioning Manager inventory scan using software signatures. To test a software package block deployment on a Windows target computer, you can use the sample software package block, testwinspb.spb, available in TIO_HOME\repository\SWDiscCli. If the deployment is successful, a file test.txt will be created in a test directory on the target computer under $(temp_dir). To save the software package block to the local file repository: 1. Click Go To > IT Infrastructure > Software Catalog > Software Products. 2. 3. 4. 5. From the Select Action menu, click Start SPE. On the Software Package Editor window, click File > Open > Open from local file system. Browse to the TPM51_OS_Management_Viewlet.spb file on your local system, and then click Open. Click File > Save > Save to repository, and then select Local File Repository. Note: A warning message is displayed saying that the software package block is not editable. If you want to edit the software package block, save it as a software package definition (.spd) file, open the .spd file and edit it as required, and then save it as a software package block (.spb) file to the local file repository. When the software package block is saved to the Tivoli Provisioning Manager local file repository, a software module and installable file for it are automatically created. The software package block can be saved to any custom file repository as well. Next, you will create the software signature to be associated with the software module.
Creating a software signature

A software signature can be created and associated with the software module for the software package block. The Tivoli Provisioning Manager inventory scan is run on the target computer, it detects the software signature and, using the signature, it discovers the associated software module. The inventory scan uses the software signature-software module correlation to find which software module the discovered software installation belongs to. The discovered software installation is associated with the software module using the software signature correlation. To add a software signature: 1. Click Go To > IT Infrastructure > Software Catalog > Software Signatures. 2. 3. 4. 5. 6. . Click New Type a name for the new software signature, the software version and name. In the Operating System field, select Windows. Under File Size, click New Row. Type the file name,TPM51Beta2_OSMgmtTutorial.swf and the file size, 9316159. and click the software module
7. In the Associated Software Definition field, click Detail Menu that you have imported previously. 8. Click Save .
The software signature that you have created is now associated with the software module. You can now manage the software package block, because its signature is associated with the software module.
577
You are now ready to publish the software package block to the depot server and then distribute it and install it on the target computers. Note: If you import software package blocks containing an inventory signature or a software signature stanza with the user interface, add the signature files manually. To add the signature files automatically, the software package block must be saved to the repository with the Software Package Editor.
Publishing the new software package blocks to the depot server

To enable a faster software distribution, you can publish the new software package blocks to the depot server before distributing them to the target computers. The depot server stores the uploaded files in a predefined directory. The target computers in your group download the software package blocks from the depot server. To publish the software package blocks to the depot server: 1. Click Go To > Deployment > Software Management > Software Product Publishing. 2. Click Select Software and select the software module for the software package block that you have created, IBM Desktop Link. Click OK. 3. Click Select Depots and select the depot server that you created previously. 4. Click Schedule and specify if you want to run the task immediately, or schedule it to run at a specified date and time. 5. Under Notification, select the appropriate notification options. 6. Click Submit. When you submit the task, the Provisioning Task Tracking page is displayed. You can click the task name to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status. The software package blocks are now published to the specified depot server. To 1. 2. 3. 4. verify that the software package blocks have been published to the depot server: Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. Click the Depots tab. Click the name of your depot server. Find the software package block files under Files on Depot server.
Note: If you encounter an error message COPDEX040E when publishing a software package, go to http://www.ibm.com/developerworks/forums/thread.jspa?threadID=191892&tstart=30 to find information to help you troubleshoot the problem. Next, you will distribute the published software package blocks to the target computers in your group.
Distributing the software package block to target computers

After the software package block has been published, the target computers can download it from the depot server without installing it. You will create a software distribution task, which you can run immediately or schedule for a specified date and time. To 1. 2. 3. distribute the software package block to the target computers in your group: Click Go To > Deployment > Software Management > Software Product Distribution. Click Select Software and select the software module that you have created earlier, then click OK. Click Select > Groups and select your group, then click OK.
578
4. Click Schedule and specify if you want to run the software distribution task immediately, or schedule it to run at a specified date and time. 5. Under Notification, select the appropriate notification options. 6. Click Submit. When you submit the task, the Provisioning Task Tracking page is displayed. You can click the task name to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status. The software package block is now distributed to the target computers. You can install it on all of the target computers in your group.
Installing the software package block on target computers

You will now install the already distributed software package block on all of the target computers in your group. To install the software package block on the target computers in your group: 1. Click Go To > Deployment > Software Management > Software Product Installation. 2. Click Select Software and select the software module that you have created earlier, then click OK. 3. Click Select > Groups and select the name of your group, then click OK. 4. Click Schedule and click Run Now to run the software installation task immediately, or schedule it to run at a specified date and time. Note: While running a software installation task, there are workflow parameters which list the priority of the task only when user changes it before running the task. When priority is not listed in the workflow parameters, the task runs with the priority that is defined in the global variable. 5. Under Notification, select the appropriate notification options. 6. Click Submit.. When you submit the task, the Provisioning Task Tracking page is displayed. You can click the task name to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status. The SPB is now installed on all of the target computers in your group. To verify that the SPB is installed, click Go To > Deployment > Provisioning Computers. Find one of the target computers in your group and click the computer name. Click the Software tab. The software module that you have created is listed as installed software. Upgrading the software package block on target computers: You can upgrade the already distributed software package block on all of the target computers in your group. You can upgrade an existing software package block on the target computers in your group by performing the following steps: 1. Click Go To > Deployment > Software Management > Software Product Installation. 2. Click Select Software and select the software module that you have created earlier, then click OK. 3. Click Select > Groups and select the name of your group, then click OK. 4. Click Schedule and click Run Now to run the software installation task immediately, or schedule it to run at a specified date and time.
579
Note: While running a software installation or upgrade task, there are workflow parameters which list the priority of the task only when user changes it before running the task. When priority is not listed in the workflow parameters, the task runs with the priority that is defined in the global variable. 5. Under Notification, select the appropriate notification options. 6. Click Submit.. When you submit the task, the Provisioning Task Tracking page is displayed. You can click the task name to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status. The software package block is now installed on all of the target computers in your group. To verify that the software package block is upgraded, click Go To > Deployment > Provisioning Computers. Find one of the target computers in your group and click the computer name. Click the Software tab. The software module that you have created is listed as installed software.
Setting a time out value for installing software package blocks in a DE infrastructure
You can set a specific time out value for installing software package block (SPB) files on target computers using the Deployment Engine (DE) infrastructure, because the default time out value might not be sufficient for transferring SPB files larger than 4 GB. Specify an appropriate time out value for installing software package block (SPB) files on target computers by setting a parameter in the Software Definition page of the SPB file you want to install using the Deployment Engine (DE) infrastructure. The default value of the time out parameter is 600 seconds. If you do not set a specific time out value, the default value is used during the software package block installation workflow. To set a specific time out value, perform these steps:
Procedure
1. Click Go To > IT Infrastructure > Software Catalog > Software Products. 2. Select the software product you want to install from the list. 3. In the Software Definition page, in the Template Parameters section of the page, identify the SPB_DE_COPY_TIMEOUT_SEC parameter. 4. Specify a value for this parameter depending on the size of your SPB files. The value must be specified in seconds. 5. Click Save .
Results
When you install this software product on the target computers using a DE infrastructure, the installation workflow will use the time out value you specified for the SPB_DE_COPY_TIMEOUT_SEC parameter.
Validating the software installation

To validate the software installation on any target computer in your group, you can delete the software installation for the software package block, and then run a Tivoli Provisioning Manager inventory scan to confirm that the software package block is still installed on the target computer. You can also create a custom application, which do not have a signature in the standard signature file, therefore you need a custom signature associated with it to be able to recognize it correctly. To validate the software installation: 1. Click Go To > Deployment > Provisioning Computers.
580
2. Find one of the target computers in your group and click its name. 3. Click the Software tab. 4. Under Software Installations, find the software that you have just installed and, in that row, click Mark Row for Delete . 5. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 6. Find the Tivoli Provisioning Manager Inventory Discovery configuration and click its name. 7. Click Run Discovery. 8. Click Select > Computers, and select the name of the target computer from which you have just deleted the software installation, then click OK. 9. Click Schedule and select Run Now to run the discovery task immediately, or schedule it to run at a specified date and time. 10. Under Notification, select the appropriate notification options. 11. Click Submit. 12. On the Provisioning Task Tracking page, click Refresh to monitor the discovery task until it is completed. 13. Go to the Software tab of the target computer for which you have deleted the software installation. The Tivoli Provisioning Manager inventory scan detected that the SPB is still installed on the target computer, and put the software installation back on the Software Installations list. The name of the restored software installation is the name of the software signature that you have previously created for the SPB. You have validated the software installation on the selected target computer. Next, you can run an inventory report to display the software installed on each of the target computers.
Generating inventory and deployment reports

Now that you have installed the software package block on all of the target computers in your group and validated the software package block installation, you can quickly run an inventory report and a deployment report to show that the software has been successfully installed. To 1. 2. 3. 4. generate the reports: Click Go To > Administration > Reporting > Report Administration. Find the report with the file name tp_software.rptdesign and click its name. Click Generate Request Pages. After the report is generated, click Close.
5. Click Preview and in the window that is displayed click Submit. The report lists all the computers and all the software installed on each computer. The software package block is displayed in the installed software list for each target computer. Currently, all the target computers in your group have the software package block installed.
Unpublishing the software and uninstalling the common agent

Before you uninstall the product, unpublish the software package block from the depot server and uninstall the common agent to clean up all of your target computers.
Unpublishing the software

To unpublish the software package block from the depot server: 1. Click Go To > Deployment > Software Management > Software Product Unpublishing. 2. Under Selected Software Products table, select the software module that you want to remove from the depot server.
581
3. Under Selected Depots table, select the depot that you want to remove from the depot server. 4. Under Schedule, click Run Now to run the task immediately, or schedule it to run at a specified date and time. Select the appropriate notification options. 5. Click Submit. When you submit the task, the Provisioning Task Tracking page is displayed. You can click the task name to see details about its status and monitor its progress until the task has completed. Click Refresh to see an update on its status. The software package block is now unpublished from the depot server. Next, you will uninstall the common agent from all of the target computers.
Uninstalling the common agent

To uninstall the common agent from one or more target computers: 1. Click Go To > Deployment > Provisioning Computers. 2. Click Select Records and select the target computers from which to uninstall the common agent. 3. From the Select Action menu, click Uninstall > Common Agent. Note: If you click Uninstall > Common Agent without any selection, a list of all computers with common agent installed is displayed as targets. The list of computers on which common agent is not installed is ignored. If you perform the same action with the list of selected computers, a target table is populated with the list of computers where common agent is installed. A message is displayed if there is no common agent installed. A task is created for the common agent removal. Click it to see details about it, then monitor it until the task is completed. The common agent is now removed from all of the selected target computers.
Distributing and installing software

A number of methods to distribute and install software on one or more managed target computers are provided. Assign the provisioning administrator and deployment specialist security roles to your user account to be able to distribute and install software. You can choose to install software products, patches, or software stacks on managed computers using any one of the following methods: v Performing separate provisioning tasks for software distribution and installation: 1. Create and schedule a software distribution provisioning task first, which distributes the software to a number of selected target computers without installing it. 2. Create and schedule a software installation provisioning task, which installs the already distributed software on the selected targets. This option is only present for the software package blocks. v Performing the software distribution and installation at the same time. If the software has not been distributed yet to target computers, you can create and schedule an installation provisioning task that will perform a software distribution to selected targets first, followed by a software installation.
582
Restriction: Distribution of software packages performed as a separate provisioning task is not recommended. Unlike software package blocks, install and distribute software packages in one step. If you want to distribute and install software in two separate provisioning tasks, use software package blocks rather than software packages. You can perform distribution and installation provisioning tasks immediately or schedule them for a specific date and time. if a configuration template is associated with the software, you can also select and customize it so that the software is configured correctly for the target environment. The default time frame for a successful file distribution to target computers is set to two hours. A file distribution that has not successfully completed within two hours can be considered failed. If required, you can customize this interval to accommodate the file distribution of larger files to larger numbers of targets. For more information, see the Overriding the default distribution time interval on page 605 topic. When a provisioning task is canceled, by default, its job is canceled on the provisioning server only. Agents that have already started processing the job continue processing it. For an optional configuration parameter that allows the cancellation of distributions, see Canceled task does not cancel jobs in progress on page 793
Distributing software products

During distribution, selected target computers download the software products that have already been published to depot servers. If distribution is performed at a different time than installation, the target computers download the files without installing them. If the software has not been distributed yet, one installation provisioning task performs both distribution and installation on targets.
Before you begin

Make sure that your user role is Deployment Specialist or equivalent. Note: To save time before deploying common agents to your managed resources, you can optionally run a prerequisite check. See Checking prerequisites locally on page 637. To distribute software products:
Procedure
1. Click Go To > Deployment > Software Management > Software Product Distribution. 2. Click Select Software and select the software products that you want to distribute, then click OK. 3. Click Select > Computers and select the target computers where you want to copy the software, then click OK. Important: Note the following points when selecting software and computers on the Software Product Distribution page: v If no software product is selected in the Selected Software section, the list of target computers under Selected Targets displays only the computers that have either a scalable distribution infrastructure-SAP defined. v If one or more software products that do not have the SoftwareInstallable.Distribute logical management operation implemented are selected, then only the computers that have a scalable distribution infrastructure-SAP defined are listed. v If one or more software products that all have the SoftwareInstallable.Distribute logical management operation implemented are selected, then all the target computers are listed, regardless of whether they are enabled for the scalable distribution infrastructure or not. 4. Click Schedule to specify when you want to distribute the software.
583
5. Under Notification, specify when you want to be notified about the status of the distribution. 6. Click Submit.
Results
If you chose to install the software immediately, the provisioning server starts the installation. If you scheduled the installation, the installation occurs at the specified date and time. You can view installation progress and status on the Provisioning Task Tracking page.
Software distribution in branch office environments

Large organizations and enterprises have complex branch office environments that are either centralized or distributed, based on specific trends, business needs, and strategies. Each organization has its own priorities and business goals that typically translate into specific sets of requirements that have an impact on the design of an effective branch office infrastructure solution for that organization. Challenges in large and complex branch office environments are typically linked to the following factors: v A large number of branches. v Low-bandwidth or intermittent connectivity between branches and the management center. v A vast number of resources in heterogeneous configurations. v A wide variety of managed devices available at branch and retail sites, from in-store servers running applications that use various prerequisites, to workstations, point-of-sale terminals, handheld scanners, radio frequency identification readers, and so on. v A lack of the appropriate IT skill sets that are needed to manage services at branch sites. v The mission-critical nature of most of the operations at the branch sites. An efficient solution for large and complex branch office environments must meet most of the technical and business requirements of branch office environments. The goals of an efficient branch office solution must meet all of the preceding constraints and can include: v Centralized control and management of data. v Fast and reliable software deployment to branch offices, with minimal impact to the network performance. v Efficient utilization of existing bandwidth. v Priority given to mission-critical applications over other types of traffic used in the branch office. v Remote manageability and serviceability specially for branch offices that are heavily dependent on the availability of certain services. v Secure business transactions. To address the requirements of large branch office environments, a number of provisioning services are used to provide an efficient branch office infrastructure solution. Branch office overview: The software distribution is centrally managed from the provisioning server. Existing core services such as the dynamic content delivery and device manager service perform the actual software distribution and federated job management operations. The branch office infrastructure solution offered with Tivoli Provisioning Manager offers a scalable infrastructure to support a number of provisioning services. This enables the management of various target computers in a variety of topologies. The scalable distribution infrastructure includes management elements and distribution elements. Each management element maintains a record data set for its type of data (jobs or bulk data). The distribution elements (job managers, depot managers) maintain a working data set which is a cache of the
584
management data set. To enhance performance, the management elements implement a cache pre-fill strategy in which data is distributed to the branch elements in advance of when it is needed. The scalable distribution infrastructure includes the following main components: Provisioning server The provisioning server is the server on which Tivoli Provisioning Manager is installed. The following components of the scalable distribution infrastructure are installed on the provisioning server: Agent Manager Tivoli Provisioning Manager uses theTivoli Common Agent Services for software distribution and compliance. Tivoli Common Agent Services provides an infrastructure for managing the computer systems in your environment. Agent Manager is the server component of the Tivoli Common Agent Services that provides functions that clients can use to get information about agents and resource managers. It enables secure connections between managed target computers running the common agent, maintains the database information about the target computers and the software running on them, and processes queries against that database from resource managers. It also includes a registration service, which handles security certificates, registration, tracking of common agents and resource managers, and status collection and forwarding. The device manager federator The 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 delivers incoming jobs to all of the regional federated agents that are configured to communicate with it. Currently, a two-tiered federated environment is supported. The dynamic content delivery management center Provides centralized control of the upload, replication, and download of files, and implements a distribution policy that sends bulk data to some or all of the distributed depot servers, in advance of when it is needed. It also monitors the state of depot servers and stores file data and download statistics. Distribution servers The provisioning server connects to distribution servers, or directly to target computers. The distribution servers contain the following components: A device manager federated agent The federated agent can be installed on distribution servers and can be configured to communicate with the device manager federator to get command jobs which are distributed to the clients installed on the targets in the branch. The federated agent on the distribution server periodically communicates with the federator and detects when there is network connectivity. A dynamic content delivery depot Regional dynamic content delivery depot servers ensure the communication between the management server and the clients or subagents installed on the target computers. The regional depot servers communicate with the management server to get data that will be distributed to targets upon request.
585
Depot Server
OSGi
Common Agent
Tivoli Common Agent target computers Distribution servers connect to the target computers. The targets contain the following components: A device manager subagent Clients are installed as device manager subagents on the target computers at the branch and are used for receiving tasks from and returning results to the federated agents. A dynamic content delivery client subagent Clients installed as dynamic content delivery subagents on all the managed systems or targets at the regional branch office, to download files from depot servers or from other clients.
Target Computer
OSGi
Device Manager Subagent
Dynamic Content Delivery Subagent
Common Agent
Tivoli Common Agent The common agent is installed on the target computers and acts as a common container for all the subagents. The common agent collects data from subagents and uses them to
586
perform operations on managed resources on behalf of a Tivoli management application. It provides shared system resources and secure connectivity. The following diagram illustrates the interactions between the components of the scalable distribution infrastructure:
587
Provisioning Server
Web Service Clients
Agent Manager
Region A
Branch Office 1
Target
Branch Office 2
Target
Region B
Branch Office 3
Target
As you can see, the management elements of the infrastructure are installed on the provisioning server. The branch elements ensure a two-way communication between the management elements and the clients installed on the target computers in the branch offices. The branch elements communicate with the
588
management elements to get data requested by the targets at the branch. When the targets receive the requested data, results are returned to the regional elements, which in turn, communicate them back to the management elements. Setting up scalable distribution infrastructure: After the provisioning server is successfully installed, a number of postinstallation configurations tasks must be performed to set up the scalable distribution infrastructure. The Tivoli Provisioning Manager installer silently installs the following management elements of the scalable distribution infrastructure on the provisioning server: v The Tivoli agent manager v The device manager federator v The dynamic content delivery management center The following diagram illustrates all of the elements that constitute the scalable distribution infrastructure:
589

Provisioning server
Agent Manager

...
2 1

Service Subagent
- Common Agent
The following postinstallation configuration tasks must be performed to properly set up the distribution elements of the infrastructure to interact and communicate with the management elements so that all supported operations can be successfully performed: Install the depot servers The installation of the dynamic content delivery depot servers can be done using the web interface. Regions, depots, and zones can also be created, updated, or deleted using the DcdAdmin automation package. If you need to create several zones, use the DcdAdmin automation package CLI or workflows to create them. For more information, see the Automation package for management of large numbers of regions, zones, and depot servers on page 821 and Adding depot servers on page 819 topics.
590
Install the common agent on target computers The common agent installation can be performed either using the provisioning server or outside of it. For more information, see the Installing the common agent on page 541 topic. Manual setup of the device manager federated agents: A number of manual configuration tasks can be performed to enable the communication between the device manager federated agents, the device manager federator installed on the provisioning server, and the device manager subagents installed on the target computers at the branch office. The federated agent needs to be configured to communicate with the federator, and the subagents on the targets can be configured to communicate with the federated agent. Tip: An automation package, eDMS_LWI.tcdriver, is also provided so that most of the following tasks can be performed automatically. The following manual configuration tasks are required: v Installing IBM JRE, version 1.5 manually v Installing the lightweight device manager federated agent v Configuring the device manager federated agent on page 593 v Configuring the device manager subagents on page 596 Installing IBM JRE, version 1.5 manually: You must extract the required files for IBM JRE from the common agent package provided with Tivoli Provisioning Manager. To manually install IBM JRE: Procedure 1. On the provisioning server, locate the following files: Windows common_agent_<version_number>_<build_date>_<OS_name>.exe, in the %TIO_HOME%\repository directory. UNIX common_agent_<version_number>_<build_date>__<OS_name>.tar, in the $TIO_HOME/repository directory. where <OS_name> is the operating system running on the target computer. 2. Extract the files to a specified location on the target computer. You must use the <tca_installer> -is:extract option to extract the installer files, then create a self extracting archive of JRE ibm-java2-jre-50sr6-win-i386.exe which can be extracted with the -d option. On UNIX, use the GNU tar utility to extract the files in the .tar archives, instead of using Windows-specific utilities such as Winzip. 3. Add a java directory to the location where the lightweight device manager federated agent is to be installed on the target computer. For example, <eDMS_install_dir>\java (Windows) or <eDMS_install_dir>/java (UNIX). 4. After extracting the files in step 2, copy the jre subfolder to the java directory created in step 3. No files or subfolders other than jre are required after extracting the files in step 2, so that you can delete them all. Installing the lightweight device manager federated agent:
591
Before you begin Ensure that JRE, version 1.5 is already installed, as described in the Installing IBM JRE, version 1.5 manually on page 591 procedure. To manually install the lightweight device manager federated agent: Procedure 1. On the provisioning server, locate the following files: On Windows The following files can be found in the %TIO_HOME%\repository\edms_lwi directory: v 0628A_53lwi700.zip v com.tivoli.eDMS_1.8.0.20060720D2.zip v com.tivoli.eDMS_TPM_Mediator_1.8.0.20060720D2.zip On UNIX The following files can be found in the $TIO_HOME/repository/edms_lwi directory: v 0628A_53lwi700.tar.gz v com.tivoli.eDMS_1.8.0.20060720D2.tar.gz v com.tivoli.eDMS_TPM_Mediator_1.8.0.20060720D2.tar.gz 2. Extract the files to the <eDMS_install_dir> directory. The archive names are as follows: On Windows 0628A_53lwi700.zip On UNIX 0628A_53lwi700.tar.gz 3. Extract the files as follows: On Windows Extract the files in the com.tivoli.eDMS_1.8.0.20060720D2.zip archive to <eDMS_install_dir>\apps\eclipse\plugins On UNIX Extract the files in the com.tivoli.eDMS_1.8.0.20060720D2.tar.gz archive to <eDMS_install_dir>/apps/eclipse/plugins 4. Extract the files as follows: On Windows Extract the files in the com.tivoli.eDMS_TPM_Mediator_1.8.0.20060720D2.zip archive to <eDMS_install_dir>\apps\eclipse\plugins On UNIX Extract the files in the com.tivoli.eDMS_TPM_Mediator_1.8.0.20060720D2.tar.gz archive to <eDMS_install_dir>/apps/eclipse/plugins Results The lightweight device manager federated agent is now installed on the target computer. Installing the lightweight device manager federated agent from the GUI: To manually install the lightweight device manager federated agent from the GUI:
592
Procedure 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Select the computer on which you want to install the lightweight device manager federated agent. 3. From the Select Action menu, select Install > Software Product. The Install Software dialog is displayed. 4. Click Select Software and specify eDMS_lwi. 5. Click Select Computer and specify the computer on which you want to install the lightweight device manager federated agent. 6. Click OK > Submit. Results The lightweight device manager federated agent is now installed on the target computer. Configuring the device manager federated agent: To manually configure the device manager federated agent to communicate with the device manager federator on the provisioning server: Procedure 1. Edit the config.ini file, located in the <eDMS_install_dir>\conf directory (Windows) or <eDMS_install_dir>/conf (UNIX), as follows. Add the following lines just before the end of the file marker:
# eDMS configuration stuff... # The next 2 parms set eDMS to be a Federated Server(Enterprise) and a Branch Server # For the enterprise server, set WAS_DMS_ENABLE_FEDERATED_SERVER=true # For a Branch Office server (which is NOT also the enterprise server), set WAS_DMS_ENABLE_FEDERATED_SERVER=false # The sample below is for an enterprise server which is federating itself. For a # branch office server # WAS_DMS_FEDERATED_AGENT_SERVER_ADDRESS=http://<hostnameOrIPAddrOfEnterpriseServer> :<EnterpriseServerPort> WAS_DMS_ENABLE_FEDERATED_SERVER=true WAS_DMS_FEDERATED_AGENT_SERVER_ADDRESS= https://<fully qualified hostname of TPM Manifest server>:9045 # Note: In default TPM, two way secure port (client/server auth) defaults to 9046, so the URL in that environment would be: # WAS_DMS_FEDERATED_AGENT_SERVER_ADDRESS=https://localhost:9046 # # # # *******IMPORTANT NOTE FOR DEMOS********* Post 2/10/2009 builds support the new (optional) configuration parameter WAS_DMS_FEDERATED_AGENT_POLL_INTERVAL_IN_MINUTES The default is set to 10 minutes. For improved response time for demos, set it to 1
WAS_DMS_FEDERATED_AGENT_POLL_INTERVAL_IN_MINUTES = 10 # # Set WAS_DMS_USE_DETECTED_DMS_SERVER_IF_AVAILABLE and # WAS_DMS_USE_CONFIGURED_DMS_SERVER_IF_DETECTED_SERVER_UNAVAILABLE # as described below depending on the desired behaviour. # # To use the proxy and fall back on the configured URL if the service (or the gateway or associated gateway software # itself) is unavailable # WAS_DMS_USE_DETECTED_DMS_SERVER_IF_AVAILABLE=true # WAS_DMS_USE_CONFIGURED_DMS_SERVER_IF_DETECTED_SERVER_UNAVAILABLE=true # # To disable the proxy and just use the configured server (i.e., the way it worked before this - this is the DEFAULT)
593
# # # # # # # # #
WAS_DMS_USE_DETECTED_DMS_SERVER_IF_AVAILABLE=false WAS_DMS_USE_CONFIGURED_DMS_SERVER_IF_DETECTED_SERVER_UNAVAILABLE=true To use the service and only the configured service WAS_DMS_USE_DETECTED_DMS_SERVER_IF_AVAILABLE=true WAS_DMS_USE_CONFIGURED_DMS_SERVER_IF_DETECTED_SERVER_UNAVAILABLE=false To disable JMS initialization (JMS is not supported for eDMS) WAS_DMS_ENABLE_JMS_COMMUNICATION=false
# # Hostname and port of CAS Agent Manager Server. Leve blank for now until CAS # integration work is complete # WAS_DMS_AGENT_MANAGER_SERVER_ADDRESS= #
2. Edit the lwistart.bat (lwistart.sh for UNIX), lwistop.bat (lwistop.sh for UNIX), and lwistatus.bat (lwistatus.sh for UNIX) files as follows. The files are located in the following directories: v On Windows: <eDMS_install_dir>\bin\lwistart.bat <eDMS_install_dir>\bin\lwistop.bat <eDMS_install_dir>\bin\lwistatus.bat where <eDMS_install_dir> is the installation directory of the lightweight device manager federated agent. The default installation directory is C:\<Program_Files_Dir>\ibm\edms_lwi where <Program_Files_Dir> represents the value of the Windows registry entry. v On UNIX: <eDMS_install_dir>/bin/lwistart.sh <eDMS_install_dir>/bin/lwistop.sh <eDMS_install_dir>/bin/lwistatus.sh where <eDMS_install_dir> is the installation directory of the lightweight device manager federated agent. The default installation directory is /opt/ibm/edms_lwi/bin. On Windows add the following lines at the beginning of the lwistart.bat, lwistop.bat, and lwistatus.bat files:
set JAVA_HOME=<eDMS_install_dir>\java\jre set PATH=<eDMS_install_dir>\java\jre\bin;%PATH%
assuming that JRE is installed on <eDMS_install_dir>\java on your Windows computer. On UNIX add the following lines at the beginning of the lwistart.sh, lwistop.sh, and lwistatus.sh files:
JAVA_HOME=<eDMS_install_dir>/java/jre PATH=<eDMS_install_dir>/java/jre/bin:$PATH
assuming that JRE is installed on <eDMS_install_dir>/java on your UNIX computer. 3. Add the following lines to the lwistart.bat (lwistart.sh for UNIX) file: On Windows add -Xmx512000000 to the lines starting with "%JAVA_PROGRAM%". For example,
"%JAVA_PROGRAM%" -Xmx512000000 -cp "%CONF_DIR%\configLWI.jar" com.ibm.lwi.config.CreateBatchScript
594
On UNIX add the following line:

"$JAVA_HOME/bin/java" \ $JAVAOPTS \ $DEBUG_ARGS \ "-Xbootclasspath/a:rcp/loggerboot.jar:rcp/\ properties$UTIL_JARS" \ -Xverify:none \ -Xmx512000000 \ -cp "eclipse/launch.jar:eclipse/startup.jar" \ com.ibm.lwi.LaunchLWI "$@"
4. Copy the agentKeys.jks and agentTrust.jks files from the provisioning server, under %TIO_HOME%\cert, to your device manager federated agent server, at <eDMS_install_dir>\security\ keystore (Windows) or <eDMS_install_dir>/security/keystore (UNIX). 5. Rename agentKeys.jks to KeyStore.jks, and agentTrust.jks to TrustStore.jks. 6. On the target computer, edit the following lines in the <eDMS_install_dir>\conf\config.properties file (<eDMS_install_dir>/conf/config.properties on UNIX), as follows:
com.ibm.pvc.webcontainer.port.secure=9045 com.ibm.osg.webcontainer.port.secure=9045 com.ibm.lwi.profile=profile.Extended
7. (Optional:) The Agent Manager Host Name and Registration Password are provided by the prepareTCAImage.cmd or prepareTCAImage.sh script files. If you want to obtain the decrypted agent manager registration password: a. Log on as tioadmin to the provisioning server. b. At a command prompt, change directory to %TIO_HOME%\tools (Windows) or $TIO_HOME/tools (UNIX or Linux). c. Run the following command: On Windows getAMRegistrationPassword.cmd On UNIX or Linux getAMRegistrationPassword.sh 8. On the target computer, create an sslconfig file under <eDMS_install_dir>\conf (Windows) or <eDMS_install_dir>/conf (UNIX) with the following contents:
sslEnabled=true com.ibm.ssl.keyStore.9045=../../security/keystore/KeyStore.jks com.ibm.ssl.keyStorePassword.9045=<PASSWORD> com.ibm.ssl.trustStore.9045=../../security/keystore/TrustStore.jks com.ibm.ssl.trustStorePassword.9045=<PASSWORD> com.ibm.ssl.clientAuthentication.9045=false com.ibm.ssl.keyStore.9046=../../security/keystore/KeyStore.jks com.ibm.ssl.keyStorePassword.9046=<PASSWORD> com.ibm.ssl.trustStore.9046=../../security/keystore/TrustStore.jks com.ibm.ssl.trustStorePassword.9046=<PASSWORD> com.ibm.ssl.clientAuthentication.9046=true
where <PASSWORD> is the decrypted agent manager registration password on the provisioning server. 9. On the target computer, create a DMSSLConfig.properties file at the following locations, with the contents specified in the following: v Windows:
<eDMS_install_dir>\apps\eclipse\plugins\com.tivoli.eDMS_1.8.0.20060720D2 \DMSConfiguration
v UNIX:
<eDMS_install_dir>/apps/eclipse/plugins/com.tivoli.eDMS_1.8.0.20060720D2 /DMSConfiguration
595
The contents of the DMSSLConfig.properties file must be: On Windows

TPM_KEYSTORE_LOCATION=<eDMS_install_dir>\\SECURITY\\ KEYSTORE\\KeyStore.jks TPM_KEYSTORE_PASSWORD=<PASSWORD> TPM_TRUSTSTORE_LOCATION=<eDMS_install_dir>\\SECURITY\\ KEYSTORE\\TrustStore.jks TPM_TRUSTSTORE_PASSWORD=<PASSWORD>
Note: Note the double backslash signs in the Windows paths. On UNIX
TPM_KEYSTORE_LOCATION=<eDMS_install_dir>/security/keystore/KeyStore.jks TPM_KEYSTORE_PASSWORD=<PASSWORD> TPM_TRUSTSTORE_LOCATION=<eDMS_install_dir>/security/keystore/TrustStore.jks TPM_TRUSTSTORE_PASSWORD=<PASSWORD>
In the DMSSLConfig.properties, the <PASSWORD> value is the decrypted agent manager registration password on the provisioning server, obtained in step 7. 10. Replace the WAS_DMS_FEDERATED_AGENT_SERVER_ADDRESS in the <eDMS_install_dir>\conf\config.ini file (Windows) or <eDMS_install_dir>/conf/config.ini file (UNIX) with the fully qualified host name of your enterprise provisioning server. For example,
WAS_DMS_FEDERATED_AGENT_SERVER_ADDRESS=https://r22p02.tod.tpmserver.example.com:9045 austin.drda.host=r24x10.tod.tpmserver.example.com
11. Remove the webcontainer.properties file from the <eDMS_install_dir>\conf directory (Windows) or the <eDMS_install_dir>/conf directory (UNIX). 12. Start the lightweight device manager federated agent server by running the lwistart.bat/.sh command. The command location is: On Windows <eDMS_install_dir>\bin On UNIX <eDMS_install_dir>/bin Tip: You can run the lwistop.bat (Windows) or lwistop.sh (UNIX) command to stop the lightweight device manager federated agent server. Results The device manager federated agent is now configured to<eDMS_install_dir>/bin Configuring the device manager subagents: You can manually configure the device manager subagents installed on the targets at the branch office to communicate with the device manager federated agent.
Procedure 1. From the provisioning server, modify the TCA-JES Default by setting the value of the Addr parameter to the IP address and port of the device manager federated agent (for example, change Addr
596
parameter from https://%%TPM_SERVER_HOST_IP%%:9045/dmserver/SyncMLDMServlet to https://9.31.28.34:9045/dmserver/SyncMLDMServlet, where 9.31.28.34 is the IP address of the federated agent. 2. Install the Tivoli common agent on the target computer. If you want, you can enable the automated creation of the SDI-SAP service access point on the target, as part of the common agent installation. 3. Repeat the preceding steps for all the targets that you want to communicate with this device manager federated agent. 4. Add and install a dynamic content delivery depot server on another target computer. Results The device manager subagents installed on the target computers are now set up to successfully communicate with the device manager federated agent. Automated setup of the device manager federated agent: The eDMS_LWI.tcdriver automation package is provided to automate the configuration tasks that are required to set up the device manager federated agents to communicate with the device manager federator on the provisioning server. Before you begin The target computer on which you have set up the device manager federated agents must meet the following requirements: v Have a management IP address. v Have an RXA (Windows) or SSH (UNIX) service access point already defined for the Device.Execute and Device.Copy commands. v On Windows, does not have the SSH daemon running v On UNIX, have the GNU tar utility which must be the default tar utility to extract the files in the automation package. Note the following information about the device manager federated agent: v Windows: The device manager federated agent is installed as a Windows service. v Linux, AIX, and Solaris: A startup script for the device manager federated agent is installed and runs automatically. v By default, the device manager federated agent is automatically started after the installation. You can change the default behavior, according to your needs. See step 3 for more details. v The device manager federated agent is automatically started after restart. To set up the device manager federated agent: Procedure 1. Create and run a discovery scan using the SMB discovery configuration for Windows or the SSH discovery configuration for UNIX, to discover the target computer you are working with, its management IP address, and the RXA (Windows) or SSH (UNIX) service access point. 2. Manually add the corresponding operating system software installation to the software definition for the automation package, after the target computer has been added to the data model. For more information, see Adding a top level software resource for a software installation on page 719. 3. Install the eDMS_LWI software product. The default installation path for the eDMS_LWI.tcdriver automation package is: v Windows: <Program_Files_Dir>\ibm\edms_lwi, where <Program_Files_Dir> represents the value of the Windows registry entry.
597
v UNIX: /opt/ibm/edms_lwi By default, the device manager federated agent is set to start automatically after the installation. If you do not want it to start automatically after install, set the value of the StartImmediatelyAfterInstall parameter to false. The default value is true. Results The device manager federated agent is now set up to successfully communicate with the device manager federator on the provisioning server. You can now manually configure the device manager subagents installed on the target computers at the branch office to communicate with the installed and configured device manager federated agent. Configuring the device manager subagents: You can manually configure the device manager subagents installed on the targets at the branch office to communicate with the device manager federated agent. Select the option Run as administrator for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide.
Windows 2008
Procedure 1. From the provisioning server, modify the TCA-JES Default by setting the value of the Addr parameter to the IP address and port of the device manager federated agent (for example, change Addr parameter from https://%%TPM_SERVER_HOST_IP%%:9045/dmserver/SyncMLDMServlet to https://9.31.28.34:9045/dmserver/SyncMLDMServlet, where 9.31.28.34 is the IP address of the federated agent. 2. Install the Tivoli common agent on the target computer. If you want, you can enable the automated creation of the SDI-SAP service access point on the target, as part of the common agent installation. 3. Repeat the preceding steps for all the targets that you want to communicate with this device manager federated agent. 4. Add and install a dynamic content delivery depot server on another target computer. Results The device manager subagents installed on the target computers are now set up to successfully communicate with the device manager federated agent. Restarting the device manager federated agent: If you use the default settings, the device manager federated agent is automatically restarted after a restart. If required, you can also restart it manually from the provisioning server. Similarly, you can manually stop the device manager federated agent. Uninstalling the device manager federated agent: You can uninstall the device manager federated agent either from the List page for that computer or from the Software Products Uninstallation page. Manual uninstallation of the lightweight device manager federated agent from the GUI:
598
You can uninstall the lightweight device manager federated agent using the eDMS_LWI automation package or you can uninstall it from the GUI To manually uninstall the lightweight device manager federated agent from the GUI: Procedure 1. Click Go To > Deployment > Provisioning Computers. 2. Select the computer from which you want to uninstall the lightweight device manager federated agent. 3. From the Select Action menu, select Uninstall > Software Installation. The Uninstall Software dialog is displayed. 4. Click Select Software and specify eDMS_lwi. 5. Optionally click Select Computer and specify the more computers from which you want to uninstall the lightweight device manager federated agent. 6. Click OK > Submit. Results The lightweight device manager federated agent is uninstalled from the target computer. Depot server installation: To be able to publish the software files that you want to distribute and install on target computers, you need to define the regions, zones, and depot servers that will be used in the software distribution process. Before you begin v New depot servers can only be added after a region has been defined. For more information, see the Adding and removing regions on page 818 topic. v Also, the server that will be configured as a depot server needs to be discovered first. Discovery adds the depot server to the data model. For more information see Regions, zones, and depot servers on page 817. v If you have enabled IPv6 addressing support for the scalable distribution infrastructure, the operating system on depots must be able to communicate appropriately with other computers in your environment. For example, if you have both IPv4 and IPv6 target computers, the depot can be configured to support both IPv4 and IPv6 addressing, or you can set up separate IPv6 and IPv4 depots to support communication with each type of IP addressing. If all communication with the depot will use IPv6 addressing, the depot can be configured to support IPv6 only. v Note that regardless of your language settings, Server Traffic statistics are displayed in the following format: 0.0. The new depot server with the specified properties is added and registered with the management center. It is also listed on the Depots Management page, and its displayed status is Active. For information about how to add a depot server, see Creating the infrastructure for scalable software distribution on page 572. You can perform the following actions with the depot server: v View more details for a depot server. v Modify depot server properties, designate the depot server as a preferred upload server, or install the depot agent services on the depot server. Preferred upload servers are selected before other depot servers to receive uploaded files. If no preferred upload server is available, another depot server is selected to receive the uploaded file. Preferred upload servers must be globally accessible, not blocked by a firewall from clients. If a preferred upload server is not included in the initial publishing of a file, a temporary preferred upload
599
server is chosen by the Dynamic Content Delivery management center for the initial publishing. After all the replications are completed to the chosen depots, the file will be removed from this temporary preferred upload server. The criteria for a preferred upload server must include the following: High availability: Monitor the depot using the check status of a depot on the provisioning server. These depots must always be in an active status. Alternatively, you can use the Event Console in the Dynamic Content Delivery Admin Console. Proximity to the provisioning server or the management center. High network bandwidth availability. Large available disk space. You cannot have a preferred upload server in a zone with "Minimize traffic in and out of zone" set to enabled or incoming-blocked. A publish to this preferred upload server will fail. v Define the number of concurrent activities included in each activity plan when publishing software and patches. When you publish software products or patches to a depot, Provisioning Manager generates an activity plan. By default the activity plan contains five concurrent activities. If you want to change the number of concurrent activities, perform the following steps: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click Variables. 3. Click New Row and add the following settings: Variable Type Publish software activity concurrency level Component Entire System Value Type the value of the property with the required number of concurrent activities. The default value is five. Tip: To view information about depot server status from the Start Center, expand the Depot status portlet. Running the dynamic content delivery depot as LOCAL_SYSTEM: To run the dynamic content delivery depot as LOCAL_SYSTEM, set the value of the Windows_Run_Service_As_SYSTEM parameter to true in the TCA default.<dcmId> configuration template for the CDS_Depot_Stack. The default value is false. To run the dynamic content delivery depot as LOCAL_SYSTEM: Procedure 1. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. 2. Click CDS_Depot_Stack. 3. Expand Configuration Templates to locate Default Template and click the TCA default..<dcmId> configuration template. 4. In the Template Parameters list, the Windows_Run_Service_As_SYSTEM parameter is sorted onto the next page. Advance the parameter list page by clicking the right arrow in the Template Parameters header bar. 5. Set the value of the Windows_Run_Service_As_SYSTEM parameter to true. The default value is false. Results Setting the value of the Windows_Run_Service_As_SYSTEM parameter to true enables the credentials specified for the local system account to be used instead of the local user credentials.
600
Distributing patches before installation

After patches are approved, you can distribute them first by copying the patches to the target computers. After distributing the patches, you can install them on the targets. You can distribute patches immediately or schedule this task for a specified date and time. If you want to distribute a patch to multiple targets in a single operation, you can select, for example: v All targets in a provisioning group, customer, or application. v All targets with a particular software product installed. v All targets that are missing a particular patch. To distribute patches:
Procedure
1. Click Go To > Deployment > Patch Management > Patch Distribution. 2. Click Select Patches and select the patches that you want to distribute, then click OK.
Windows To search for a particular patch, enter the patch number in the Patch box, for example KB921823. If multiple software definitions are available for that patch number, for example, Security Update for Windows Server 2003 and Security Update for Windows XP, select all the software definitions that match the patch number. The correct patch will be distributed based on the operating system on the computers. 3. Click Select Computers and select the computers to distribute the patches to, then click OK. 4. Click Schedule and specify when you want to distribute the patches. 5. Under Notification, specify when you want to be notified about the distribution status.
6. Click Submit.
Results
If you have chosen to distribute the patch immediately, the provisioning server starts the distribution. If you have scheduled the distribution, patches will be distributed at the specified date and time. You can view distribution progress and status on the Provisioning Task Tracking page.
What to do next
When distribution is complete, you can install the patch.
Distributing software stacks

The selected target computers download the specified software stacks from the closest depot server without installing them. The software operator role must be assigned to your user account to be able to distribute software. You can start distribution immediately or schedule it for a specified date and time. If you want to perform the distribution at a different time than installation, you can use the Software Stacks page to perform the distribution, and then use the Install Software Stacks page to install the distributed stacks. To distribute software stacks:
Procedure
1. Click Go To > Deployment > Software Management > Software Stack Distribution. 2. Click Select Stacks and select the software stacks that you want to distribute, then click OK.
601
3. Click Select > Computers and select the computers where you want to copy the software, then click OK. 4. Click Schedule to specify when you want to distribute the software. 5. Under Notification, specify when you want to be notified about the status of the distribution. 6. Click Submit.
Results
If you chose to install the software immediately, the provisioning server starts the installation. If you scheduled the installation, the installation occurs at the specified date and time. You can view installation progress and status on the Provisioning Task Tracking page.
Distributing files
If you have the deployment specialist role assigned to your user account and have decided to perform the file distribution and installation separately, you can copy files in a specified file repository to selected target computers without installing them.
Before you begin

Ensure that the file is added to the file repository first. For more information, see Adding files to file repositories on page 604. You can start the file distribution immediately or schedule it for a specified date and time. To distribute one or more files to target computers:
Procedure
1. Click Go To > Deployment > Software Management > File Distribution. 2. Click Select Files and select the files that you want to distribute, then click OK. 3. Click Select > Computers and specify the target computers where you want to copy the files. 4. Under Select Path, type the Windows or UNIX path for the file distribution. Restriction: For both Windows and UNIX, only full path values must be used, no variables are allowed. For example, you cannot use %TEMP% in the Windows path, but rather the exact path value, for example, C:\temp. 5. Click Schedule and specify when you want to distribute the files. 6. Click Notification and specify when you want to be notified about the status of the distribution. 7. Click Submit.
Results
If you chose to distribute the files immediately, the provisioning server starts the distribution. If you scheduled the distribution, the distribution occurs at the specified date and time. You can view distribution progress and status on the Provisioning Task Tracking page.
File repositories
A file repository is a computer that you use to centrally store software, images, scripts, application data, and other files that you want to install or run on managed systems. File repositories are used in several ways: v When you add new software to the software catalog, you can select a file repository where you currently store the installation packages.
602
v When you capture an image from a computer, you can select the file repository where you want to store the image. v Specialized file repositories that provide software updates, such as Microsoft Windows Server Update Services, can be used to create external software catalogs.
Creating file repositories

A file repository is a server that centrally stores software. For example, a file repository can be an FTP server, a version control repository, or an image repository for boot servers. A computer can include more than one file repository. For example, you might store boot server images on the same server that you use to store your library of software packages. Each file repository has a defined root directory. When you install Tivoli Provisioning Manager, a local file repository called LocalFileRepository is created and associated with the TIO_HOME/repository directory on the provisioning server. The properties of the local file repository, such as the root path and the IP address, are automatically configured. To add a file repository:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > File Repositories. Tip: To perform this task from the Start Center, click File Repositories under Infrastructure applications. 2. Click the File Repositories tab. . 3. Click New File Repository 4. Type the file repository name and the root path where the software is stored. 5. If the file repository stores images, select the boot server that deploys the images. . 6. Click Save 7. Click the file repository that you created and configure it. a. Add a network interface card to provide physical link to the rest of the network. Click New NIC Resource and specify the required settings. Ensure that the Management check box is selected for the network interface card. b. Add a network interface so that other devices can address the computer with an IP address. Click the Network Interface tab and click New Network Interface and specify the required settings. c. Add a service access point to the file repository, and then assign credentials to control access. The type of credentials that you assign depends on the type of file repository that you created.
Results
The file repository is created. Note: For more detailed information about how to create a new file repository, see Setting up new file repositories for the Software Package Editor.
What to do next
After you have defined the file repository, identify the files on it. Note: You cannot remove a file repository if: v There are installable files associated with the file repository.
603
v The file repository was created when you set up coexistence of Tivoli Configuration Manager with Tivoli Provisioning Manager. Configuring the new file repository for the patch download: You can change the default location for the patch download to the new file repository. The default location for downloading the approved patches from the Microsoft Web site is the local file repository on the Tivoli Provisioning Manager server. To configure the newly created file repository as the default location for the patch download: Procedure 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. On the Variables tab, locate the ms-patch-default-file-repository variable. 3. Click the switch by the variable name. 4. In the Value field, replace the default LocalFileRepository value with the name of the new file repository. 5. Click Save. Results The default location for the patch download is now configured according to your settings.
Adding files to file repositories

Files that are physically stored on a file repository computer are only available for distribution if they are defined in the data model.
Before you begin

v The file that you want to add must exist in a subdirectory of the file repository. v A workflow must be associated with the FileRepository.Scan logical management operation if you want to add multiple files from a directory. To add files to the file repository:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > File Repositories. 2. Search for the appropriate file repository and then click its name in the search results. 3. Click the Files tab. 4. To add a single file, click Add New File. Specify the name, description, version, and path to the file. The package path is the directory where the software is stored, relative to the root of the file repository. For example, if the repository path is configured as /share, and the package is stored in /share/package1, then the package path is /package1. 5. To add multiple files, from the Select Action menu, click Import Files. Specify the directory where the files are stored, relative to the root of the file repository. For example, if the repository path is configured as /share, and the files are stored in /share/files, then the package path is /files. Click Run. 6. If you added a new file, click Save .
604
Results
If you added a single file, an entry for the file is added to the Files tab of the file repository. If you used the Import Files command, the specified directory is scanned. The specified directory is scanned for files and the list of files is compared against the entries in the data model. v If the file exists but there is no entry for the file in the data model, the entry is created. v If there is an entry in the data model, but the file does not exist in the package path, the data model entry is deleted.
Overriding the default distribution time interval

By default, the file distribution to target computers is set to expire in two hours (7200 seconds). Setting up an expiration interval for the file distribution enables the dynamic content delivery subagent installed on the target to try the download again after the default two-hour interval. If required, you can customize this interval, to accommodate the distribution of larger files to larger numbers of targets. If, for example, the dynamic content delivery management center or the depot servers are too busy, the download might not successfully complete within the two-hour default time frame. To override the default expiry time for the file download, define the following two variables: retryWindowSec This variable defines the maximum number of seconds the dynamic content delivery subagent must wait until the file distribution to targets expires. maxRetryIntervalSec This variable defines the maximum number of seconds to wait between retries. To override the default expiry time for file distribution:
Procedure
1. Set up the retryWindowSec variable: a. Click Go To > Administration > Provisioning > Provisioning Global Settings. b. Click the Variables tab, and then click New Row. c. In the Variable field, type retryWindowSec. In the Component field, click Entire system. In the Value field, enter the number of seconds you allow the file download to complete. By default, this time interval is set to 7200 seconds. . d. Click Save 2. Set up the maxRetryIntervalSec variable: a. Click Go To > Administration > Provisioning > Provisioning Global Settings. b. Click the Variables tab, and then click New Row. c. In the Variable field, type maxRetryIntervalSec. In the Component field, click Entire system. In the Value field, type the appropriate number of seconds between retries. By default, this time interval is set to 30 seconds. d. Click Save .
Results
The default time interval for the file distribution is now reset according to the specified values.
Canceling software distributions

You can cancel a software distribution while the software package is already being distributed.
605
You can cancel a software distribution to all target computers while the software package is already being distributed to the target computers. A target computer might be in a number of possible states during the deployment of a software distribution as follows:
Table 100. Software distribution cancellation depending on the target computer state Current state of your target computer: Computer has not started downloading the job Computer has started downloading the job Computer has started processing the job Computer has terminated processing the job If you cancel the software distribution: The job is canceled with no effect on the computer The job is canceled with no effect on the computer The job is canceled if the actual installation phase has not already started The computer is rolled back to its previous state
Canceling distributions
To cancel a software distribution, perform the following steps:
Procedure
1. To enable the cancel software distribution feature, set the following configuration parameter to true: SDI.Cancel.Through by performing the following steps: a. In the navigation pane, expand System Management. b. Click Global Settings. c. Click the Variables tab. Click the Variables tab. d. Select Add Variable from the Edit menu. e. In Key, enter SDI.Cancel.Through. f. Click Save. 2. In the Web interface, click Task Management > Track Tasks. 3. Identify and select the software distribution task that you want to cancel. 4. Select the action menu for the task to be canceled and click Cancel.
Determining the status of SDI tasks

To determine the status of SDI tasks, you can check certain log files and locations. v The file C:\Program Files\tivoli\ep\logs\trace-log-0.xml contains the indication that a job cancel request has been performed. v The file C:\Program Files\tivoli\ep\runtime\agent\subagents\jes\jobCancellations.properties contains the job ID of the submitted task that was canceled. v The statusHistory directory contains xml files with names like the entries of the jobCancellations.properties file. This file indicates download and installation statuses for software products and software package blocks. A WorkItem status of 4 indicates that the task was canceled. The Result attribute of the WorkItem indicates the size of the file downloaded. v Files are normally downloaded the /tmp folder on UNIX and C:\temp or C:\tmp on Windows endpoints. For software products and software package blocks, the file download location is the same for UNIX endpoints. However for the Windows endpoints, it is %TEMP%. In most cases, the %TEMP% env variable of Windows endpoints is set to "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp". This is the location to be monitored to check if the file was completely or partially downloaded. v The location "C:\Program Files\tivoli\ep\runtime\agent\subagents\cds\client\cache\files\1" contains the file IDs of the files and software package blocks that are to be downloaded on the endpoint. The ID of a file can be found in the Dynamic Content Delivery Console.
606
Installing software products

If the software products have already been distributed, the installation provisioning task only installs the software. If the software products have not been distributed yet, the installation provisioning task performs both the distribution and the installation of the software on selected target computers.
Before you begin

Make sure that your user role is Deployment Specialist or equivalent. To install software products:
Procedure
1. Click Go To > Deployment > Software Management > Software Product Installation. 2. Click Select Software and select the software products that you want to install, then click OK. 3. Click Select > Computers and select the target computers on which you want to install the software products, then click OK. 4. Click Schedule to specify when you want to install the software. 5. Under Notification, specify when and which users you want to be notified about the installation status. 6. If you want to select or customize the software configuration templates for the selected software or specify a separate date and time for distribution of the software before it is installed, click the Advanced tab. Note: v For software management block (SPB) management purposes, specific parameters can be added to the configuration template that is associated with the software module for the SPB. For more information, see the Software Package Editor documentation. v By default, the software package is removed from the temporary installation directory after the installation process has completed. You can override this behavior by setting the REMOVE_SPB_AFTER_PROCESS parameter to false in the configuration template. 7. Click Submit.
Results
If you chose to install the software immediately, the installation starts. If you scheduled the provisioning task, the installation occurs at the specified date and time. You can track the installation progress on the Provisioning Task Tracking page.
Overriding the temporary directory during SPB installation

You can override the temporary directory during the SPB installation. By default, when you install an SPB, the installation file is copied into a temporary directory on the target computer. This temporary directory is determined by the Java runtime system property java.io.tmpdir. To use a different temporary directory on the target computer, add the following SRT parameters to the TCA-JES Default SRT in the agent stacks. For information about SRT parameters, see Tivoli Common Agent Stack configuration template parameters on page 633. Depending on your platform, add one of the following: v temp.dir.aix v temp.dir.hp-ux v temp.dir.linux v temp.dir.solaris
607
v temp.dir.sunos v temp.dir.windows For any platform, you can add a value to these parameters that corresponds to the temporary directory you want to use on the target computer. You can add a replaceable macro value to specify environment variables. For example, if the SRT parameter temp.dir.windows is set to @[TEMP], and the target system's TEMP environment variable is set to C:\temp, the agent uses the C:\temp directory as the temporary directory.
Installing large software package blocks

This topic describes how to install a large software package block (SPB). A large SPB is considered to be larger than 2 GB. To install a large SPB, you must configure the following parameters on the target computer: v DCD depot cache size for the involved DCD depots v DCD client cache size for the involved TCA targets The default values of these parameters are not large enough to manage distributions or installations of large files. Set both parameters to a value larger than the size of the SPB that is being installed. Setting the DCD depot cache size: For large SPBs, you must set the value of the DCD depot cache size to a higher value. Procedure For a new depot, set the value of the DCD depot cache size when you create it. For an existing depot, update the parameter using the Dynamic Content Delivery Configuration application as follows: 1. 2. 3. 4. Go to Administration > Provisioning > Dynamic Content Delivery Configuration. Click the Depots tab. Select the depot. Enter a new value for Data Directory Limit (MB).
5. Click Save. What to do next Ensure that the value for the above parameter is refreshed every 24 hours on the agents. If you do not want to wait, you can refresh manually. For more information about refreshing manually, see Incorrect value for the used space on a depot on page 807. Setting the DCD client cache size: For large SPBs, you must set the value of the DCD client cache size to a higher value. By default, all agents have peer-to-peer enabled with a default DCD client cache size value set to 4 GB. To install larger files, you can either disable peering or set the DCD client cache size to a higher value. To change the value of the DCD client cache size, perform one of the following: v On the agent, open the cdsclient.properties file located here: <agent_base>/runtime/agent/subagents/ cdsclient.properites. Edit the value of cache_max_size or peering to the new value. Restart the agent. v Log on to the DCD Management Console and go to Settings > Set Client Configuration. Click Advanced Settings and select Default cache size or Enable Peering. Then, to apply the changes, click Update. The actual value will be propagated to the agents after the heartbeat between the agent and the server. You can specify the frequency of the heartbeat in the Peer reporting frequency parameter in Advanced Settings.
608
v Before installing a new common agent, edit the peering and cache_max_size parameters in the SRT of the TCA-Feature Tivoli Provisioning Manager Base Software Definition. For more information about how to change these parameters, see the following topics: Configuring the default peering cache on page 655 Disabling and enabling peering on page 815 Tivoli Common Agent Stack configuration template parameters on page 633
Installing individual patches on UNIX and Linux

After patches are approved, you can install them on the target computers where they are missing. You can install patches immediately or schedule this activity for a specified date and time. If the patches have not been distributed yet, they are distributed and installed on the target computers. If the patches have already been distributed, they are installed on the targets. During patch installation, the provisioning server checks the list of approved patches against each target and only installs the patches that are required by that target. If v v v you want to install a patch on multiple targets in a single operation, you can select, for example: All targets in a provisioning group, customer, or application. All targets with a particular software product installed. All targets that are missing a particular patch.
To install individual patches:
Procedure
1. Click Go To > Deployment > Patch Management > Patch Installation. 2. To initiate a restart for the target computer, select the Reboot if required check box. 3. Click Select Patches and select the patches that you want to install. You can display patches based on Patch, Vendor, Version or you can expand Advanced Search Options for more options. 4. Under Selected Targets, specify the target computers on which you want to install the patches. You can also expand Advanced Search for more options. 5. Under Scheduling, specify when you want to install the patches. 6. Under Notification, specify when and which users you want to be notified about the installation status. 7. If you want to select Recipients, click Add User and specify the user name. You can also specify an e-mail address by clicking Add E-mail. 8. If you want to select Events, click Add Event and specify the event type. 9. Click Submit.
Results
Installing individual patches on Windows

After patches are approved, you can install them on the computers where they are missing. Typically, users with the Deployment Specialist user role install patches. You can install patches immediately or schedule this activity for a specified date and time. If the patches have not been distributed yet, they are distributed and installed on the target computers. If the patches
609
have already been distributed, they are installed on the targets. During patch installation, the provisioning server checks the list of approved patches against each target and only installs the patches that are required by that target. If v v v you want to install a patch on multiple targets in a single operation, you can select, for example: All targets in a provisioning group, customer, or application. All targets with a particular software product installed. All targets that are missing a particular patch.
To install individual patches:
Procedure
1. Click Go To > Deployment > Patch Management > Patch Installation. 2. Click Select Patches and select the patches that you want to install. You can display patches based on Patch, Vendor, Version or you can expand Advanced Search Options for more options. To search for a particular patch, type the patch number in the Patch field, for example KB921823. If multiple software definitions are available for that patch number, for example, Security Update for Windows Server 2003 and Security Update for Windows XP, select all the software definitions that match the patch number. Tivoli Provisioning Manager will install the correct patch based on the operating system on the computers. 3. Under Selected Targets, specify the target computers on which you want to install the patches. You can also expand Advanced Search for more options. 4. Under Scheduling, specify when you want to install the patches. 5. Under Notification, specify when and which users you want to be notified about the installation status. 6. Click Submit.
Results
Setting up the target restart notification

Target computers on which patches are successfully installed can be notified before a restart (if the restart is required). This notification is intended to give warning to the user working on the target computer that the target computer needs to restart. The user has the option of postponing the installation. To be able to set up the target restart notification, you must first install the TPM user Interaction Service software definition on all of the targets that you want to apply the patches to.
Before you begin

Prerequisites: v Install the common agent on the target computers for which you want to set up the restart notification. For more information, see the Installing the common agent on page 541 topic. v Disable the Windows Automatic Updates option for your operating system. For more information, see your Windows documentation. To set up the target restart notification:
Procedure
1. Click Go To > Deployment > Software Management > Software Product Installation.
610
2. Under Select Software, search for the TPM user Interaction Service software definition, and select it. 3. Under Select Computers, select the provisioning group or the individual targets on which you want to install the selected installable. 4. Click Schedule to specify when you want to install the software. 5. Under Notification, specify when and which users you want to be notified about the installation status. 6. Click Submit.
Results
What to do next
After the TPM user Interaction Service software definition is successfully installed on all of the targets that you want to apply patches to, you can proceed with the patch installation. On the Advanced page, you can set up the restart options as described in the Installing individual patches on UNIX and Linux on page 609 topic. A restart notification will be sent to each selected target.
Installing software stacks

When you use the Install Software Stacks page, the selected target computers download the specified software stacks from the closest depot server and then install them in the specified order. If the software stacks are already distributed to the targets, the installation task will only install them on the targets. If the software stack you are installing contains elements that are not supported by the scalable distribution infrastructure, the entire software stack will be installed using the deployment engine framework. If you want to install the common agent, see Installing the common agent on page 541. The software stacks for the common agent are installed separately from regular software stacks and are therefore unavailable from the Provisioning Computers page. The common agent software stacks and any other software stacks with the capability TIVOLI_COMMON_AGENT set to tivolicommonagent are hidden from this page. To install software stacks:
Procedure
Click Go To > IT Infrastructure > Software Catalog > Software Stacks. Click Select Records and select the software stacks that you want to install. From the Select Action menu, click Install. Click Select > Computers and specify the target computers from which you want to uninstall the stacks. 5. Click Schedule to specify when you want to install the stacks. 6. If you want to select or customize the software configuration templates for the selected software, click the Advanced tab. Under Selected Software, select the software stack associated with the software configuration template that you want to work with. Under Configuration Templates, select the template that you want to use to uninstall the software stack. Customize the values as required. 7. Click Submit. 1. 2. 3. 4.
611
Results
Installing WebSphere Application Server with settings from a discovered installation

You can capture settings from an existing WebSphere Application Server 6 installation and use them to install WebSphere Application Server again.
Before you begin

v This feature is only available under the following conditions: You have an existing WebSphere Application Server Version 6 installation on a Windows computer. Other versions of WebSphere Application Server, WebSphere Application Server Network Deployment, and other operating systems are not supported for this feature. You are using Tivoli Application Dependency Discovery Manager discovery to discover the installation. This capability is not available with other types of discovery. v The IBM WebSphere Application Server V6 software definition must include an entry in the installable files list for the Windows version of WebSphere Application Server 6. The installation file (WAS_V60_win_IA32.zip) and file repository location must also be correctly configured for the Windows entry. v The deployment specialist role must be assigned to your user account to be able to distribute and install software. If you have an existing WebSphere Application Server 6 installation, you can use Tivoli Application Dependency Discovery Manager discovery to capture the installation settings. When the WebSphere Application Server installation is discovered, the installation settings are copied to a new software configuration template in the IBM WebSphere Application Server V6 software definition so that you can reuse the settings for a future WebSphere Application Server 6 deployment.
Procedure
1. Use Tivoli Application Dependency Discovery Manager discovery against the computer that has the existing WebSphere Application Server installation. For information about discovery, see Discovery basics on page 146. When the discovery is complete, the settings for the WebSphere Application Server installation are copied to the IBM WebSphere Application Server V6 software definition in the IBMWAS-6.0discovered-Windows-installationsoftware configuration template. 2. To install WebSphere Application Server with the discovered settings: a. Click Go To > Deployment > Software Management > Software Product Installation. b. Click Select Software and select IBM WebSphere Application Server V6 , then click OK. c. Click Select > Computers and select the computer where you want to install WebSphere Application Server, then click OK. d. Click the Advanced tab. e. Under Configuration Templates, select the IBMWAS-6.0-discovery-recommend-Windowsinstallation software configuration template. f. Click Submit. WebSphere Application Server 6 is installed with the selected settings. 3. If the original WebSphere Application Server had fix packs applied, you can upgrade the new installation with the same fix packs. a. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. b. Search for the target computer and then click its name in the list.
612
c. Click the Software tab. d. In the list of software resources, find the WebSphere Application Server installation. e. Select the WebSphere Application Server installation and click Select Action > Upgrade.
Performing maintenance operations on target computers

To perform maintenance operations on target computers, you define maintenance windows. Periods of time outside of the maintenance windows are called service windows. During service windows, certain operations are restricted. This implementation restricts only Dynamic Content Delivery file transfer operations. You can schedule operations to run on specific days of the week and within a specified time frame, such as, only during the day, during the night, on weekdays, or weekends. Use the maintenance window to specify a time frame within which the operation is to be performed. You can specify more than one maintenance window for each operation. For example, you can use maintenance windows to schedule maintenance operations, such as large file download, installation of software packages, and inventory scans, without affecting the operations in progress on the target computer. You can schedule the maintenance operation to take place at night, or during a downtime for the target computer. You can define the maintenance operation so that, if it does not complete during the allotted time, it automatically pauses and resumes later, during another scheduled downtime. To define maintenance windows, you use the maintenance.ics file which contains the maintenance window definitions. The *.ics format is a convention for iCalendar files. Any time periods outside of the calendar events defined in this file fall in the service window, during which maintenance operations on the target computer are not supported and must be paused. You then distribute the maintenance.ics file to the target computers in a software package. The maintenance.ics file is saved on the target computers, where the common agent detects it and loads it as its latest maintenance window definition. There are two major relevant scenarios when maintenance windows are used: v There are no jobs currently running on the target computer, so: When the maintenance window starts, the maintenance operation is performed. When the maintenance window ends, the service window starts and the target computer is available for running standard jobs. Any maintenance operations still in progress are paused and is resumed during the next maintenance window. v A job is running on the target computer, so: When the maintenance window starts, the maintenance operation resumes any work item that it paused during a service window. When the maintenance window ends, if the maintenance operation is still ongoing, the operation is paused and is resumed during the next maintenance window. If there are multiple tasks queued for a given target computer, and one of the tasks involves installing a new, or updated, maintenance calendar, then regardless of the order in which the tasks were submitted to the target computer, the maintenance calendar job has the highest priority. If an invalid maintenance.ics file is installed on a target computer, the maintenance operations fails in the maintenance window and never appears in the service window.
Defining maintenance windows

To perform maintenance operations on target computers, you can define maintenance windows during downtime so as not to affect the running of workflows on the targets. Configuring maintenance windows:
613
Before you begin Before you define maintenance windows, set up the configuration parameters, both on the provisioning server and on the target computers. You can configure the following parameters: scan.period Number of milliseconds the system waits when checking the maintenance.ics file for updates. The default value is 20000 milliseconds (20 seconds). This parameter is set in the agent/subagents/ jes.properties file on the target computer. You can add it to the TCA-Subagent JES software resource template so that it overrides the default value at installation time. DiscoveryUploadUrl Specifies the URL for the inventory upload servlet. This parameter is defined in the TCA-Subagent JES software resource template and its value is dynamically generated. For more information about the inventory upload servlet, see Inventory upload servlet on page 1111. DMS_SYSTEM_JOB_PRIORITY Determines the priority for system jobs. The default value is 1. This parameter is a provisioning server configuration parameter and must be defined in the entire system component. Set the value to be smaller than the DMS_JOB_PRIORITY parameter, which has a default value of 3. Note: All time periods defined for maintenance windows are treated as Standard Time during the Daylight Savings Time periods of the year. Creating and distributing maintenance window definitions: Before you begin To define maintenance windows, create a calendar file using a tool by an independent software vendor, for example Google calendar or Thunderbird. To define maintenance windows, you create a maintenance.ics file that contains the maintenance window definitions. The *.ics format is a convention for iCalendar files. Any time periods outside of the calendar events defined in this file fall in the service window, during which maintenance operations on the target computer are not supported and must be paused. You then distribute the maintenance.ics file to the endpoints in a software package. To create and edit maintenance windows: Procedure 1. Create a maintenance.ics file that contains the maintenance windows definitions. 2. Create a software package to distribute this file to the endpoint To facilitate creation, a sample SPD file is provided in the following path: repository/tivoli/TCA/schedule.spd. a. Create a software package block from the software package definition file using the Software Package Editor. b. Import the software package block into the Tivoli Provisioning Manager repository. c. Select the software module definition for the software package block. d. In the General tab select Edit >Add Capability, and add a capability defining the operational schedule for the maintenance window. 3. Install the software module on target computers. Results The maintenance.ics file is saved in the ep/runtime/agent/subagents directory, where the common agent detects it and loads it as its latest maintenance window definition.
614
Syntax for defining maintenance windows

The top-level language in iCalendar is the Calendaring and Scheduling Core Object, a collection of calendar and scheduling information. Typically, this information consists of a single iCalendar object. However, multiple iCalendar objects can be grouped. The file must start with the string BEGIN:VCALENDAR, and end with the string END:VCALENDAR; the contents between these lines is called the icalbody. The body of the iCalendar object consists of a list of calendar properties and one or more calendar components. The calendar properties apply to the entire calendar. The calendar components are several calendar properties, which create a calendar schema. For example, the calendar component can specify the start and end time for the maintenance window, time zone information, and the event name and rule.
VCALENDAR Properties
VCALENDAR properties define the general properties of the calendar
Table 101. iCalendar VCALENDAR Properties Tag name PRODID VERSION UID Description Identifier for the product that created the calendar object. This property is required. Calendar object version. This property is required. Unique name. It is converted to uppercase and spaces are converted to the underscore (_) character. Can contain up to 40 characters. User-defined description. Can contain up to 120 characters. Time zone to be used when interpreting date values. Default value for VEVENT.DTSTART. Date time value. Default value for VEVENT.DTEND. Date time value. Default value for VEVENT.RRULE.UNTIL. Date time value. String that can be retrieved by TSS APIs. Exclude Saturday from availability calendar. Supported values are TRUE and FALSE. Exclude Sunday from availability calendar. Supported values are TRUE and FALSE.
DESCRIPTION VTIMEZONE X-DEFAULTDTSTART X-DEFAULTDTEND X-DEFAULTUNTIL X-CALAVAILABILITYVALUE X-CALFREESATURDAY X-CALFREESUNDAY
Supported formats are as follows: v The VTIMEZONE tag applies to all date values in the file. If there is no time zone specified then the time zone of the target computer itself applies. The value associated with this tag is consistent with Java time zone specifications. For example: Europe/Rome, CST. For a complete list of possible timezones and more details, see the following Web sites: http://twiki.org/cgi-bin/xtra/tzdatepick.html http://java.sun.com/javase/timezones v Date and time values follow the RFC 3339 standard. For more information, see http://www.ietf.org/ rfc/rfc3339.txt . Supported date formats are as follows: YYYYMMDD, for example 20090314 YYYY-MM-DD, for example 2009-03-14
615
v Supported time formats are as follows: HHMMSS, for example 231000 HH:MM:SS, for example 23:10:00 v Supported date and time formats are as follows: YYYYMMDD'T'HHMMSS, for example 20090314T231000 YYYY-MM-DD'T'HH:MM:SS, for example 2009-03-14T23:10:00
Event properties (VEVENT)

VEVENT properties describe an event, which is allotted a scheduled amount of time on a calendar. Such events have a DTSTART tag which sets a starting time, and a DTEND tag which sets an ending time. If the calendar event is recurring, DTSTART sets up the start of the first event.
Table 102. iCalendar VEVENT Properties Property name UID DESCRIPTION DTSTART DTEND RRULE Description Unique name. It is converted to uppercase and spaces are converted to the underscore (_) character. User-defined description. Can contain up to 120 characters. Start date and time of the validity interval. Overrides the value defined for X-DEFAULTDTSTART. End date and time of the validity interval. Overrides the value defined for X-DEFAULTDTEND. Recurring rule (mutually exclusive with RDATE). Supported frequencies are: v DAILY v WEEKLY v MONTHLY v YEARLY You can specify the UNTIL property to indicate the validity interval end date. Overrides the value defined for X-DEFAULTUNTIL. RDATE EXDATE List of punctual dates to include (mutually exclusive with RRULE). List of punctual dates to exclude.
The following points apply: v Supported format for RRULE is as follows: RRULE:FREQ={DAILY|WEEKLY|MONTHLY|YEARLY} [;INTERVAL=n] [;{BYFREEDAY|BYWORKDAY|BYDAY=weekday_list| BYMONTHDAY=monthday_list}] [;UNTIL=date] v You can define multiple VEVENT objects in a single VCALENDAR object. In this case, the maintenance windows are determined by the association of the date ranges with the events. v VEVENTS do not span more than one day. For example, if you have a maintenance window that starts on Monday at 10:00 p.m. and ends on Tuesday at 02:00 a.m., define two separate VEVENT objects, one for Monday 10:00 p.m.-11:59 p.m., and another for Tuesday 00:00 a.m.-02:00 a.m.. The following is an example of a maintenance.ics file: BEGIN:VCALENDAR DESCRIPTION: Accounting Dept Endpoints
616
PRODID:IBM VERSION:1.0 BEGIN:VTIMEZONE TZID:CST END:VTIMEZONE BEGIN:VEVENT DESCRIPTION: Every Mon Tue Wed Thu Fri 18:00 to 21:00 DTSTART:20080901T180000 DTEND:20080901T210000 RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU; UNTIL=20200901T140000; END:VEVENT END:VCALENDAR
Generating a report for maintenance status

To perform maintenance operations on target computers, you can define maintenance windows during downtime so as not to affect the running of workflows on the targets. Whenever the agent undergoes an operational mode status change (service mode or maintenance mode), a status update is sent to the Tivoli Provisioning Manager server in the form of an inventory notification. When the data is processed, this operation creates three properties associated with the target system. In the Variables tab for each computer, the following properties are available: operational.mode Indicates the status of the target system. Supported values are Maintenance or Service. operational.mode.update.timestamp Indicates the time when the Provisioning Manager server last updated the values. This value is based on the Provisioning Manager server time zone. operational.mode.change.timestamp Indicates the time when the operational mode status change happened in the target computer. This value is based on the Provisioning Manager server time zone. Note: When the installation is performed in stand-alone mode, the variables are created only after you restart the common agent. A Provisioning Manager report is defined to list a summary of target computers with the related values. This report provides near real-time operational mode status information. To obtain real-time status information, run the TCA_Get_Operational_Mode workflow on a single system. Generating a report: To generate a report: Procedure 1. Click Go To > Administration > Reporting > Report Administration. 2. Find the report with the file name tp_pauseResume.rptdesign and click its name. 3. Click Generate Request Page. 4. After the report is generated, click Close. 5. Click Preview and in the window that is displayed specify the task ID. 6. Click Submit.
617
Results The report lists the target computers and maintenance windows information for each target computer, such as the current operational mode, the time when the server processed the update, and the time when the operational mode change happened on the target computer. You can also check the following log files for further information: v Provisioning Manager server logs v common agent logs v common agent runtime logs
Simple software product distribution

Tivoli Provisioning Manager can automatically distribute and install software products defined in the software catalog without creating specific provisioning workflows or automation packages to deploy each type of software. Tivoli Provisioning Manager includes automation for simple software installations. A simple software installation includes distributing a software package to a target computer and performing one or both of the following actions: v Extract files from an archive file such as a .zip file. v Install the software. You can optionally specify a response file or license key for the installation. Simple software product distribution supports deployment to Windows, Linux, AIX, HP-UX, and Solaris Operating Environment computers. Any installation process that uses the SoftwareInstallable.Install logical management operation can take advantage of these installation methods. If the software product does not have a specific provisioning workflow associated with the SoftwareInstallable.Install logical management operation, the HostingEnvironment.Host logical management operation is automatically called to perform simple software product distribution. If more complex actions are required to deploy a software product, and an automation package for the software is not currently available, create an automation package with provisioning workflows that can perform the required actions.
The following table describes the available methods for installing simple software without writing provisioning workflows. Decide which method is most appropriate for your installation process. There are template definitions for each installation method that you can use to quickly provide values needed by Tivoli Provisioning Manager to distribute and install the software on computers.
Table 103. Installation methods Method Unzip Only: Copy a compressed file to a target computer and extract the contents to a specified location. A tool is copied to the target computer to extract the contents of the compressed file. Use this option to automatically extract the contents of a compressed file. Windows Yes UNIX or Linux
618
Table 103. Installation methods (continued) Method Unzip and Install: Copy a compressed file to a target computer, extract the contents, and then install the software. A tool is copied to the target computer to extract the contents of the compressed file. Use this option to automatically extract a specified compressed file that contains a software installer. For example, if a compressed file contains a Windows .msi file, you can use this option to extract the file and then install it with the msiexec command. Extract Only: Copy an archive file to a target computer and extract the contents to a specified location. Use this option to automatically extract the contents of an archive file. Extract and Install: Copy an archive file to a target computer, extract the contents, and then install the software. Use this option to automatically extract a software installer from an archive file. Install Only: Copy an installation file to a target computer and run the command to install the software. Use this option for ready-to-run programs, such as a script or an .exe installer. Yes Yes Windows Yes UNIX or Linux
Yes
Yes
Yes Custom Extract and Install: Copy a compressed file to a target computer, extract the contents with a specified command, and then run the command to install the software. Use this option for archive files that are not supported by the Extract and Install installation method. For a list of supported file formats, see Supported archive file formats.
Yes
Supported archive file formats

The following table lists supported file extensions and archive formats. If your software package is in one of these file formats, ensure that it has the correct file extension so that the contents can be extracted successfully.
Table 104. Supported archive file formats Operating system Windows Installation method Unzip Only Unzip and Install Supported formats and file extensions Archive files in a compressed format only You can use any file extension supported by the operating system, but the file must be in a compressed format. The typical file extension for compressed file is .zip. Archive files in tar or compressed format. Ensure your archive has one of the following supported file extensions. If the archive has an incorrect file extension, extraction of the files from the archive will fail. tar file .tar bzip tar file .tar.bz2, .tar.bzip2, .tbz2, .tbz gzip tar file .tar.gz, .tgz, .tar.gzip compress tar file .tar.Z, .taz compressed file .zip
Linux
Extract Only Extract and Install
619
Table 104. Supported archive file formats (continued) Operating system UNIX Installation method Extract Only Extract and Install Supported formats and file extensions Archive files in tar or compressed format. Ensure your archive has one of the following supported file extensions. If the archive has an incorrect file extension, extraction of the files from the archive will fail. tar file .tar bzip tar file .tar.bz2, .tar.bzip2, .tbz2, .tbz gzip tar file .tar.gz, .tgz, .tar.gzip compress tar file .tar.Z Note: This is the only supported file extension. The file extension is case sensitive. compressed file .zip
Software product distribution requirements

Ensure that you meet requirements for software product distribution before you begin setting up your software product.
To automate installation, you must ensure that there are silent commands available for performing the file extraction and the software installation. Any actions required during the installation process must: v Be available from the command line. v Require no user interaction. Note: The ability to fully automate an installation depends on the silent installation support provided by the vendor of the software product. Not all software installations can be automated for deployment with simple software product distribution.
Target computer requirements

Verify that managed computers for the software are associated with a software installation for the operating system. You can see which computers have an associated operating system on the Manage Computers page. The operating system can automatically be associated with a computer using discovery. If you need to manually associate the operating system, perform the following steps: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers.. 2. Search for the computer that you want to update. In the search results, the Operating System field displays N/A if there is no operating system association. 3. Click the name of the computer to update. 4. Click the Software tab. 5. Click Edit > Add Software Installation. 6. In the Name field, type the name of the operating system. 7. In the Software Definition field, select the operating system that is installed on the computer. 8. Click Save. A software resource for the operating system is added to the Software page.
620
Installation method requirements

The following table shows the required and optional installation parameters by installation method. For a full description of the parameters, see the table Parameters for deploying a software product.
Table 105. Installation parameters Installation method Unzip and install (Windows) Extract and install (Linux/ UNIX) Custom extract and install
Unzip only (Windows) File Copy Only Required Extract only (Linux/ UNIX)
Parameter install-path: The path on the target computer where you want to copy the file. destination-filename: The name of the file when it is copied to the target computer. extract-command: The silent command to extract installation files from a compressed file extract-path: The path on the target computer where you want to extract contents of a compressed package. auto-file-overwrite: When enabled, existing files on the target computer are overwritten. install-command: The silent command to install the software install-command-timeout: Timeout in seconds for the command configured for install-command. rspfile-method: Indicate if a response file is required. installer-path: The path where the software installer is located. rsp-filepath: If you are using a response file, the path where the response file is located. rsp-filename: If you are using a response file, the name of the response file. license-filepath: If you are using a license key file, the path where the license key file is located. license-filename: If you are using a license key file, the file name of the license key file.
Install only
Optional
Required
Required
Required
Required Optional
Required Optional
Required Optional
Required
Required Optional
Required Optional Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
Optional
621
Defining software products for distribution

To define a software product for distribution, specify the software package and its installation options.
Before you begin

Ensure that all requirements are met as described in Software product distribution requirements on page 620. The installation options are defined in a software configuration template. For simple software product distribution, you can use the provided Hosting Configuration Template definitions to quickly define the installation option for an automated installation. If a software product has more complex installation requirements, a product-specific automation package and software configuration template are required . The automation package developer must predefine the software definition and software configuration template for the software in the automation package. To define a new software product for simple distribution:
Procedure
1. Click Go To > IT Infrastructure > Software Catalog > Software Products. . 2. Click New 3. Specify the software product information, including the name, description, vendor, and build number. 4. Click New Installable. 5. In the Software Installable field, type the name of the software package. 6. In the Version field, type the software package version. 7. In the File Repository field, select LocalFileRepository or other file repository that you have created. 8. In the Installable Path field, specify the software package location. The path is relative to the default local file repository path. It can also be some other custom file repository. For example, if the repository path is configured as TIO_HOME/repository/, and the software package is stored in TIO_HOME/repository/package, then type /package as the parameter value. 9. In the File field, type the file name of the software package. 10. Click Submit. 11. Specify the installation options in the software configuration template. a. Click Select Action > Add SRT. b. Select Create from template definition. . c. Click Select Value d. Use the filter to search for template names with the text Hosting-Environment. e. Select the software configuration template that you want to use. f. In the Configuration Templates section, specify the appropriate parameter values.
622
Table 106. Parameters for deploying a software product

Parameter auto-file-overwrite Value An option to overwrite files if they exist. UNIX only supports the Yes option, so ensure that users back up their existing files before performing an installation.
Windows Linux
Yes: Overwrite existing files. No: Do not overwrite existing files. If files exist, the workflow extracts files that are not duplicates but returns a failed status.
UNIX
Only the Yes option is available. Back up any existing files before installing the software product. destination-filename extract-command For the File Copy Only method, the name of the file when it is copied to the target computer. The silent command to extract the contents of the compressed file. The specific command and command syntax depends on the compression tool that you are using. The following examples show some simple commands. See the documentation for the tool that you want to use to uncompress the file for details about syntax and ensure that the tool is installed on target computers. v If the target computer has the WinZip Command Line Support Add-On for WinZip installed, the following command extracts all the files from example.zip, recreates the directory structure contained in the compressed file, and places the extracted files in c:\myfiles. wzunzip -d example.zip c:\myfiles v If you are using gzip, the following command extracts files from example.zip into the current directory. gzip -d example.zip v If you are using tar, the following command extracts files from example.tar to the current directory and outputs the name of each file: tar -xvf example.tar
extract-path install-command
Specify the full path on the target computer where you want to extract contents of the compressed file. The silent command to install the software. The command runs in installer-path, where the software installer is located.If the installation file name has spaces, enclose the file name in quotation marks. For example:
Windows
"installer 1.1.exe" -q
Solaris
pkgadd -n -d Note: When a response file or a license key file is required, the files will be copied to the same directory as the installer. You do not need to include absolute paths to these files in the installation command. install-command-timeout
Windows
Timeout in seconds for the command configured for install-command
This option is only supported on Windows for the Install Only, Unzip and Install, and Custom Extract and Install methods. install-path For the File Copy Only method, the path on the target computer where you want to copy the file.
623
Table 106. Parameters for deploying a software product (continued)

Parameter installer-path Value Type the path where the software installer is located and where the installation command runs as specified by the install-command parameter. The software installer is the program or script file that starts the installation. If the installer is not in any subdirectory, leave the value for installer-path blank. However if the installer is in a subdirectory, specify the path relative to the software installable. rspfile-method Indicate if a response file is required. By default, the software configuration template is configured for installation without a response file.
Solaris
A response file is always required. The default response file is located in /var/sadm/install/admin. The file is called nocheck. If you are using the default Solaris response file, do not specify a value for this parameter. The default response file will be used. rsp-filepath Type the path where the response file is located in the default file repository (LocalFileRepository). Ensure that the path is a relative to the root path of LocalFileRepository. The default root path for LocalFileRepository is TIO_HOME/repository. If you are using the default Solaris response file, do not specify a value for this parameter. The default response file will be used in the default location. Otherwise, specify the path of the response file. rsp-filename The file name of the response file. If you are using the default Solaris response file, do not specify a value for this parameter. The default response file will be used in the default location. Otherwise, specify the name of the response file. license-filepath Type the path where the license key file is located in the default file repository (LocalFileRepository). Ensure that the path is a relative to the root path of LocalFileRepository. The default root path for LocalFileRepository is TIO_HOME/repository. The file name of the license key file. An optional command used to specify a command that you want to run after the installation succeeds. This option is supported on Windows and UNIX.
license-filename post-install-command
g. Click Save.
Results
The software product is now ready to install.
Installing simple software products

You can install software products that you have defined for simple software product distribution to a selected target computer.
Before you begin

Make sure that the following requirements are met: v Your user role is Deployment Specialist or equivalent. v You have performed the steps described in Defining software products for distribution on page 622. To install a simple software product, you only need to select the software and the target computer. Because all the required installation options are already predefined, you do not need to make any changes to the software configuration template at installation time.
Procedure
1. Installations to a UNIX computer will always overwrite files if they already exist. If you require existing files from a previous installation, ensure that you back up the files.
UNIX
624
Click Go To > IT Infrastructure > Software Catalog > Software Products. Select the software product that you want to install. From the Select Action menu, click Install. Specify the name of the task and the target computers for the installation. Schedule the deployment if you want it to run later. 6. Click Submit. 2. 3. 4. 5.
Results
The installation of the software product starts. If you chose to install the software immediately, the installation starts. If you scheduled the installation, the installation occurs at the specified date and time.
Troubleshooting simple software product distribution

Use the information in this section if you encounter an error when you install a simple software product.
Installation fails with a "no permission" exception

UNIX Linux
If an installer or script fails with a "no permission" exception, verify the following
information: v Verify that original file for the installer or script has the execute permission. v Identify the tool that was used to package the installer or script. Some packaging tools change file access rights when they package a file. The best way to retain file permissions is to use the packaging tool provided with the operating system. For example, if you want to create a bzipped tar file, use the bzip2 command to pack your files. Otherwise, confirm that the packaging tool that you want to use does not change file permissions.
Error COPDEX123E is displayed when installing software

If an error message like the following example is displayed, the provisioning workflow for installing the software product cannot be identified.
COPDEX123E The provisioning workflow threw a MissingHostingSupportForOperatingSystem exception. The message is Cannot find an implementation of the HostingEnvironment.Host LDO for the OS Microsoft Windows Operating System XP Professional SP2. This default implementation of SoftwareInstallable.Install attempts to invoke a HostingEnvironment.Host operation on the operating system installed on device server.example.com.
If you see this error, verify the following conditions: v Verify that a software installation for the operating system is associated with the target computer as described in Software product distribution requirements on page 620. The operating system is displayed on the Software tab of the computer. v Verify that provisioning workflows for installing a simple software product are associated with the target computer. 1. Click the Workflows tab for the computer. 2. Verify that a device driver for the operating system is displayed. For example, if the computer is a Windows computer, the Windows Operating System device driver is displayed. If the device driver is not associated with the computer, click the arrow icon for the Currently Assigned Device Driver field and click Select Value, then select the appropriate device driver. v In the list of provisioning workflows, verify that the correct provisioning workflow is associated with the logical management operation HostingEnvironment.Host. For example, the provisioning workflow
625
Windows_HostingEnvironment_Host is associated with the logical management operation on a Windows computer. If the association is not listed, click Assign Provisioning Workflow and select the HostingEnvironment.Host logical management operation and the appropriate operating system provisioning workflow.
CTGDEC119E The cache manager sub-component detected a failure during an I/O operation.
If you are distributing a file or software product and receive the error "Unable to create directory", you need to ensure that you specify a directory relative to the subagents directory. By default, the path is set to: v v
Windows UNIX
: C:\temp : /tmp/
Uninstalling software
Software products, patches, and software stacks use different methods to remove themselves from a system. You can uninstall a piece of software from a system if a specific provisioning workflow is available to perform this action for the selected piece of software.
Uninstalling software products

Software products, patches, and software stacks use different methods to remove themselves from a system. You can uninstall a piece of software from a system if a specific provisioning workflow is available to perform this action for the selected piece of software. There are two ways to uninstall a software product: v Uninstall all software installations associated with a software definition from a computer. For example, if a computer has multiple Java runtime environment installations that were installed with the same software definition, you can remove all of the installations at the same time. v Uninstall a specific installation of a software product, instead of all installations of the software product. Note: When you uninstall a software package block (SPB), the software signatures and the binaries are not removed from the file system. If you want to completely remove a software product from the system, delete also the related software signatures and binaries.
Uninstalling all software installations for a software product

When you uninstall software using the Software Product Uninstallation application, the uninstall command calls the SoftwareModule.Uninstall logical management operation. Each software installation on a target computer that is associated with the selected software product is removed using the provisioning workflow for the SoftwareInstallation.Uninstall logical management operation.
Procedure
1. Click Go To > Deployment > Software Management > Software Product Uninstallation. 2. Click Select Software to select the software products that you want to uninstall, then click OK. 3. Click Select > Computers to select the target computers from which you want to uninstall the software, then click OK. 4. Click Schedule to specify when you want to uninstall the software. 5. Under Notification, specify the required notification options. 6. Click Submit.
626
Results
If you chose to uninstall the software immediately, the removal process starts. If you scheduled the uninstallation task, the removal process occurs at the specified date and time. You can view the task progress and status on the Provisioning Task Tracking application. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. Note: By default, a forced uninstallation is performed when uninstalling a software package block (SPB). Therefore, the operation is successful also when the product is not installed on the system, or has been manually removed.
Uninstalling a specific software installation

If you want to uninstall a specific software installation, you can go directly to the list of software resources on the target computer and select the software installation to remove.
Procedure
1. Click Go To > Deployment > Provisioning Computers. 2. Search for the computer that you want to work with and click the name it in the search results. 3. Click the Software tab. 4. In the list of software, click the name of the software that you want to uninstall. 5. From the Select Action menu, click Uninstall.
Results
If you chose to uninstall the software immediately, the removal process starts. If you scheduled the uninstallation task, the removal process occurs at the specified date and time. You can view the task progress and status on the Provisioning Task Tracking application. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking.
Uninstalling patches
You might to uninstall a patch from a target computer if, for example, the patch caused problems to your environment or if the patch was installed on a computer for the purpose of testing and is no longer needed. You can uninstall only service packs that were installed using the provisioning server from an AIX target. You cannot uninstall technology levels.
AIX
To uninstall patches from a target computer:
Procedure
1. Click Go To > Deployment > Patch Management > Patch Uninstallation. 2. Click Select Patches and specify the patches that you want to uninstall, then click OK. You can search by the patch name, vendor, or version. 3. Click Select > Computers and specify the computers from which you want to uninstall the patches, then click OK. 4. Click Schedule to specify when you want to uninstall the patches. You can select Run Now to begin the uninstallation. If you want to schedule the uninstallation task, click Scheduled Start and specify the appropriate options. 5. If you want to select Recipients click Add User and specify the user name. You can also specify an e-mail address by clicking Add E-mail. 6. If you want to select Events click Add Event and specify the event type.
627
7. Click Submit.
Results
If you specified that you wanted to uninstall the patch immediately, the provisioning server starts the removal process. If you scheduled the uninstallation task, the removal process occurs at the specified date and time. You can track the progress of the uninstallation task on the Provisioning Task Tracking page.
Uninstalling software stacks

To uninstall a software stack from a target computer, a specific provisioning workflow is required to perform this operation for the selected software stack. If you want to uninstall the common agent, see Uninstalling the common agent on page 669. The software stacks for the common agent and any other software stacks with the capability TIVOLI_COMMON_AGENT set to tivolicommonagent are hidden from the Software Uninstall Software Stacks page. To uninstall software stacks from a target computer:
Procedure
1. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. 2. Click Select Records and select the software stacks that you want to uninstall. 3. From the Select Action menu, click Uninstall. 4. Click Select > Computers and specify the target computers from which you want to uninstall the stacks. 5. Click Schedule to specify when you want to uninstall the software. 6. Click Submit.
Results
If you chose to uninstall the software stack immediately, the provisioning server starts the removal process. If you scheduled the task, the removal process occurs at the specified date and time. You can view the removal progress and status on the Provisioning Task Tracking page.
Installing Tivoli Common Agent Services

In general terms, an agent is a program that automatically performs some service, such as data collection. To take advantage of a number of software management features, the common agent must be installed on all managed target computers. Tivoli Provisioning Manager uses Tivoli Common Agent Services for software distribution and configuration compliance. Many management applications today can deploy the agent software for user systems or application servers. The deployed agent collects data from and performs operations on managed resources on behalf of a Tivoli management application. Note: If Tivoli Common Agent Services is installed using Oracle, then the schema user name CDB is automatically created. Tivoli Common Agent Services consists of the following components: Common agent The common agent is a common container for all the subagents to run within. It enables multiple management applications to share resources when managing a system.
628
Agent manager The agent manager, installed on the provisioning server, is the server component of the Tivoli Common Agent Services, which provides functions that allow clients to get information about agents and resource managers. It enables secure connections between managed target computers, maintains the database information about the targets and the software running on them, and processes queries against that database from resource managers. It also includes a registration service, which handles security certificates, registration, tracking of common agents and resource managers, and status collection and forwarding. Resource manager Each product that uses Tivoli Common Agent Services has its own resource manager and subagents. For example, Tivoli Provisioning Manager has a resource manager and subagents for software distribution and software inventory scanning.
The common agent is installed once on each target computer. For example, if two management products (product A and product B) manage the same target computer, the common agent is installed only once on that target. The common agent runs two product-specific subagents: one for product A and another for product B. When the common agent is installed on a target computer, subsequent subagents can be deployed on the existing common agent.
629
The common agent contacts the agent manager and reports its status and any configuration changes at the following times: v When a common agent starts or stops v Any time a bundle is installed, upgraded, or removed v After a configurable period Some of the typical interactions are: The resource manager interacts with the agent manager v Registers with the agent manager v Queries common agents to identify which ones are present in the environment v Requests an initial security certificate v Delivers subscription-based notification of common agent registration and configuration The resource manager interacts with the common agent v Deploys bundles for its subagents v Starts and stops the subagents v Queries the configuration of the common agent and installed bundles The resource manager interacts with the bundles installed in the common agent v Resource manager runs commands on the common agent v Subagent sends information to the resource manager The subagents interact with the common agent Subagents can take advantage of the services provided by the common agent
Tivoli Common Agent

Tivoli Provisioning Manager uses Tivoli Common Agent for some 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 target computers. 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 run time based on WebSphere Everywhere Deployment technology. The common agent services code is installed once on a managed target computer. For example, if you have two management applications on the same target computer (application A and application B), the common agent code is installed only once on the target computer. However, there will be two product-specific subagents: one for application A and one for application B. This documentation uses the term agent to see both the common agent services code and to the agent code when it runs the product-specific subagent, unless specifically stated otherwise. The common agent provides: v 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. v A single set of security credentials and a common security infrastructure for all management applications. v Automated management of security credentials. When common agent certificates near their expiration date, they are automatically renewed.
630
v 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. v 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: v When a common agent starts or stops. v After a configurable period. The default is 24 hours. v Any time a bundle is installed, upgraded, or removed. The registry contains only the most recent configuration update. By default, only the most recent status information is saved for each common agent, but the retention period is configurable.
Tivoli Common Agent Services ports

There are default ports for the common agent, the agent manager, and protocols for installing the common agent. Specific ports must be available for the common agent and Tivoli Common Agent Services components. You can optionally change some of the default port numbers. The ports required for common agent installation depend on how you have configured connectivity to the target computer. To install the common agent, one of the following configurations must be available: Default service access points (SAPs) You can predefine default service access points (SAPs) for Device.ExecuteCommand and Device.CopyFile commands. These SAPs can be used to install the common agent. The port numbers for these SAPs depend on the protocol that you have defined for the SAPs. SSH or SMB If no default SAPs are defined, a SAP for the RXA protocol is created on the target computer when you install the common agent using the Install Common Agent page. The RXA SAP is then used to perform common agent installation. RXA uses the default SSH port 22, or ports 135 (RPC) or 139 (NetBIOS over TCP/IP) to connect to the target. Ensure that any firewall on the target computer, or any corporate firewall, allows for inbound traffic.
Tivoli Common Agent Services ports

Ports for the agent manager are created during agent manager installation. A SAP for the common agent is created during the common agent installation with the default port number. If you need to change the default port number, see Changing the common agent default port number on page 651. The following default port numbers are used.
Table 107. Default ports used on the management side Component provisioning server Port 8777 Use Web service port used by the TpmAuthenticator in the dynamic content delivery. Connection security
631
Table 107. Default ports used on the management side (continued) Component Agent manager Port 9511 9512 Use Register agents and resource managers. v Provide configuration updates. v Renew and revoke certificates. v Query the registry for agent information. v Request ID resets. 9513 v Request updates to the certificate revocation list. v Request agent manager information. v Download the truststore file. v Agent recovery service. dynamic content delivery, and device manager service 9443 or 9046 Enable communication between: v The dynamic content delivery subagent and the dynamic content delivery management center. Secure SSL Unsecure Connection security Secure SSL Secure SSL with Client Authentication
v The device manager subagent and the device manager federated agent. Table 108. Default ports used on the target computer side Component Common agent Port 9510 Use The default common agent listening port. Configurable. Connection security Secure SSL Secure SSL
9010 or 9015 Enable communication between the common agent and the dynamic content delivery management center. 9514 and 9515
Nonstop service. The Nonstop agent service Unsecure monitors processes on the agent, to make sure they are running and available. The service automatically restarts the processes it monitors if they stop. Optional peering service. If peering is enabled, this port is used for other agents to pull files in the agent's cache. Used for management and downloads. Enables communication between: v The common agent and the dynamic content delivery depot servers. v dynamic content delivery depot servers v The dynamic content delivery management center and the dynamic content delivery depot servers. Secure SSL
2101
dynamic content delivery depot
2100
Secure SSL
If you have a firewall between the common agents and the agent manager server, allow inbound traffic on ports 80 and 9513 to the agent recovery service. Opening these ports allows agents to report registration problems. If you configure the agent manager to use a port other than 9513 for the public port, open that port as well, so that agents can report communication problems after their initial registration.
632
When you use Tivoli Provisioning Manager to install the agent manager, port 80 is disabled and port 9513 is used as the backup port for the agent recovery service. Opening the backup port is especially important when the agent manager use of port 80 is disabled. You can manage endpoints with multiple network interface cards (NICs). Configure the appropriate host name for that NIC and the route to be used to the provisioning server. When the common agent is installed, it discovers the IP address of the NIC which is used during communication with the Agent Manager. Tivoli Provisioning Manager uses the IP address used by the common agent to register itself as the management IP address, and the defined host name as seen by the target computer on the management IP as the computer name.
Tivoli Common Agent Stack configuration template parameters

The Tivoli Common Agent configuration template defines installation and configuration options for the software in the Tivoli Common Agent stack. The parameters in a software configuration template define installation or configuration values for the software resource that the software configuration template creates when the software is deployed.
Table 109. Tivoli Common Agent Stack configuration template parameters
Parameter TCA default Windows_Run_Service_As_System If the value of the Windows_Run_Service_As_SYSTEM parameter is set to true, this enables the credentials specified for the local system account to be used instead of the local user credentials. If you want to run the common agent service as a local administrator user, you must leave the default value of the Windows_Run_Service_As_SYSTEM parameter in the configuration template unchanged, set to false. Install_Using_Sudo If the value of this parameter is set to true, the sudo command is used to obtain root permissions for installing and uninstalling the common agent with a non-root user on UNIX and Linux target computers. false false Description Default Value
TCA-TPM default RetriesMax RetryPeriod SocketTimeout EnableFirewallSupport The number of times to try a file upload again when using HTTP. The number of seconds between retries. Socket timeout in milliseconds To enable the common agent to discover services on the other side of a firewall, you must enable firewall support on the common agent by setting this value to true. 10 60 20000 false
TCA-Subagent JES Addr This parameter specifies the IP address of the device manager https://%%TPM_SERVER_HOST_IP%%:9045/ federator that the device manager subagent installed on the dmserver/SyncMLDMServlet target computer communicates with. Depending on environment, it can be either the IP address of the device manager federator installed on the provisioning server or the IP address of the device manager federator agent installed in a branch or regional location. User name for the device. Do not modify the default value. User password. Do not modify the default value. Determines if polling is enabled. The values are true or false (case is ignored). Specifies the polling interval in hours and minutes. Specifies the size of the message files Specifies the polling start time in hours and minutes. Specifies the polling end time in hours and minutes. To enable the common agent to discover services on the other side of a firewall, you must enable firewall support on the common agent by setting this value to true. tpmuser tpmpassword true 01:00 200 02:00 02:00 false
UserName ClientPW PollingEnabled PollingInterval LogSize PollingStart PollingEnd EnableFirewallSupport
633
Table 109. Tivoli Common Agent Stack configuration template parameters (continued)
Parameter TCA-Subagent CDS Client URL Handler Default Parameters web_service_protocol Specifies the protocol preference when communicating with the dynamic content delivery management center. v 0 means to always use HTTP. v 1 means to use HTTPS when sending up passwords, but HTTP otherwise. v 2 means always use HTTPS. web_service_https_port web_service_host web_service_http_port peering This is the port used by the client to securely connect to the dynamic content delivery management center. Fully qualified domain name of the system running the dynamic content delivery management center. Port used by the client to connect to the dynamic content delivery management center (unsecured). If this is set to true, the target computer will attempt to download files from other clients and target computers within the same zone. Maximum size of peering cache in MB (megabytes). 9046 %%TPM_SERVER_HOST_IP%% 9082 true 1 Description Default Value
cache_max_size TCA-SCM default upload_servlet_url
2048
The URL of the upload servlet. This servlet is used to upload the software stack. This is an obsolete parameter and is no longer used. This is an obsolete parameter and is no longer used. Determines the kind of input (such as statistics) that are collected.
http://%%TPM_SERVER_HOST_IP%%:9080/ jdsWAR/HttpFileUploadServer false tmp/scm-collector-input.xml
upload_secure collector_input_file TCA-CIT default Windows_Cit_Install_Path_Override Windows64_Cit_Install_Path_Override AIX_Cit_Install_Path_Override Solaris_Cit_Install_Path_Override Solaris86_Cit_Install_Path_Override HPUX_Cit_Install_Path_Override HPUXItanium_Cit_Install_ Path_Override Linux86_Cit_Install_Path_Override LinuxPPC_Cit_Install_Path_Override Linux390_Cit_Install_Path_Override Installation override Windows_Install_Path_Override Windows64_Install_Path_Override AIX_Install_Path_Override Solaris_Install_Path_Override Solaris86_Install_Path_Override HPUX_Install_Path_Override HPUXItanium_Install_Path_Override Linux86_Install_Path_Override LinuxPPC_Install_Path_Override Linux390_Install_Path_Override
The path where CIT is installed. The path where CIT is installed. The path where CIT is installed. The path where CIT is installed. The path where CIT is installed. The path where CIT is installed. The path where CIT is installed. The path where CIT is installed. The path where CIT is installed. The path where CIT is installed.
@[ProgramFiles]\tivoli\cit @[ProgramFiles(x86)]\tivoli\cit /opt/tivoli/cit /opt/tivoli/cit /opt/tivoli/cit /opt/tivoli/cit /opt/tivoli/cit /opt/tivoli/cit /opt/tivoli/cit /opt/tivoli/cit
To override the installation path. To override the installation path. To override the installation path. To override the installation path. To override the installation path. To override the installation path. To override the installation path. To override the installation path. To override the installation path. To override the installation path.
C:\Program Files\tivoli\ep C:\Program Files (x86)\tivoli\ep /usr/tivoli/ep /opt/tivoli/ep /opt/tivoli/ep /opt/tivoli/ep /opt/tivoli/ep /opt/tivoli/ep /opt/tivoli/ep /opt/tivoli/ep

When you install the common agent from the provisioning server, the common agent is installed on the managed system with the related TCA-Feature Tivoli Provisioning Manager Base.
634
Preinstallation information
Before installing the common agent using the following methods, review the following information: v Requirements for common agent installation on page 547 v Installing the common agent on the provisioning server, where the agent manager is also installed, is not supported. If you want to revert to the previous version of a common agent for compatibility with other products that require the older product level, you must remove the agent and then reinstall it using the installation package included with the other product. Installing the common agent does not affect any other agents that are already installed. v Version 1.4.2.1 of the common agent is installed with the current version of the provisioning server. Note: The common agent installation does not support RSA credentials for Windows target computers. When the network discovery is performed using the RSA credentials, a set of password credentials for SMB must also be used to discover the Windows target computers.
There are two main ways to install the common agent: Using Tivoli Provisioning Manager You can use the Common Agent Installation page to install the common agent on an existing managed system. This option installs the common agent with default options. The following service access points (SAP) are created on the target computer during the common agent installation: v Agent-Server (IPv4 / CommonAgent) v SDI-SAP (IPv4/Scalable Distribution Infrastructure) v RXA-Server (IPv4/RXA) Note: The RXA SAP is created only if you provide credentials and there is no default SAP assigned to the device. The TCA.Create.EO.SAP configuration parameter determines if the SDI SAP is created as part of the agent installation. This parameter is set to true by default. To modify this parameter, go to Provisioning Global Settings->Variables. For more information, see Installing the common agent on managed systems on page 640. Outside of Tivoli Provisioning Manager The common agent can also be installed using an installation image, which provides all the required common agent installers, and their configuration. Restriction: The standalone installation does not support the installation of the dynamic content delivery depot subagent. For more information, see Installing the common agent and subagents using a stand-alone installation on page 641. The default common agent installation path is: v Windows: C:\Program Files\Tivoli\ep v Solaris or Linux: /opt/tivoli/ep v AIX or HP-UX: /usr/tivoli/ep
Checking prerequisites
To save time before deploying common agents to your managed resources, you can optionally run a prerequisite check. This way, you can determine which systems are currently ready for the agent installation and which still must be prepared. You can run a prerequisite check locally from the agent or globally from the server.
635
Note: The prerequisite check does not check the network connection with the Agent Manager on Windows target computers. The prerequisite script is called tcaInstallPrecheck.sh or tcaInstallPrecheck.vbs depending on your platform. To run a prerequisite check locally from the agent, you run the prerequisite command. To run the prerequisite check globally and for a group of computers, you use a Provisioning Workflow. The prerequisite check performs the following checks: Space requirements Checks the space required for the installation packages of the agent and the space required for the agent to be installed. Operating system patches and packages Checks the operating system patches and packages. Port conflict Checks if the port parameters in the response file are available. The following parameters are checked:
Agent installation response file parameter -w CASInstall.AgentPort -w CASInstall.NonstopPort1 -w CASInstall.NonstopPort2 Default value 9510 9514 9515
Network connection Checks that there are no network issues between the agent computer server and the Tivoli Provisioning Manager server. This check only validates the agent to agent manager connections required. The following parameters are checked:
Agent installation response file parameter -w CASInstall.PublicPort -w CASInstall.SecurePort -w CASInstall.RegistrationPort -w CASInstall.AgentManagerHostname Default value 9513 9512 9511 No default
Agent already installed Checks that the agent does not already exist on the target computer.
Return codes
The following table lists the return codes for the prerequisite check:
Table 110. Return codes for the prerequisite check Value 0 100 200 300 400 500 600 Description All tests were successful. Space requirements for the agent failed. Temporary space required during agent installation failed. Operating system patches and packages for the agent check failed. Operating system patches and packages for the subagents check failed. Port conflict check failed. Network connection test failed.
636
Table 110. Return codes for the prerequisite check (continued) Value 700 -1 -2 Description The agent is already installed. Command usage error. The response file is not valid.
Checking the endpoints that have passed the prerequisite check

To see which endpoints that have passed the prerequisite check, create a dynamic group and select the query All agent prerequisite pass servers. Checking prerequisites locally: This topic describes checking prerequisites locally. Note: The prerequisite check does not check the network connection with the Agent Manager on Windows target computers. To run a prerequisite check, from the Tivoli Provisioning Manager agent, run one of the following commands: UNIX and Linux: tcaInstallPrecheck.sh [-o output_file_name | -s | -q ] [-v] i response_file_name Windows cscript /Nologo tcaInstallPrecheck.vbs [-o output_file_name | -s | -q ] [-v] i response_file_name where -o output_file_name is the output report to file -s is the output report to stdout for success and stderr for failed tests -q is quiet with no output report -v is the verbose output of commands executed to stdout only -i <response_file>: is the response file generated for the particular platform using the prepareTCAImage.[sh|cmd] script. Provide the path of the response file, for example, <response_file>=<tcaimage_install_dir>/<OS_Type>/caInstall.rsp. Checking prerequisites globally: This topic describes creating a group to check prerequisites globally from the server. Note: The prerequisite check does not check the network connection with the Agent Manager on Windows target computers. To run a prerequisite check, from the Tivoli Provisioning Manager server, perform the following procedure: Procedure 1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. 2. Create a Task Definition.
637
3. 4. 5. 6. 7.
Enter the Provisioning Task name and select Provisioning Workflow type. In the Provisioning Workflow field, enter TCA_prereq_check. In the OutputFileDirectory field, enter the following path: /tmp. Click Save. From the Select Action menu, run the Provisioning Task.
8. From the Run Provisioning Tasks panel, select Groups. Results An output file is created in the path you provided in the OutputFileDirectory field on all targets. Note: The user "tioadmin" has permission only to the destination directory /tmp. If you want to collect the log files from any other directory, on Linux, create the directory where you want to collect the log files. Give "tioadmin" write access to this directory. On Windows,you can collect the log files from anywhere on the server.
Service access points and subagent bundles

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

After the common agent is installed, a Common Agent service access point is created and is set as the default service access point for file-transfer and execute-command device operations. This service access point type is defined as ipv4/CommonAgent. The Common Agent service access point supports the following functions: Running commands and copying files The Common Agent service access point supports the logical device operations Device.Execute.Command and Device.CopyFile. Workflows use these logical device operations to run commands on endpoints and copy files between the provisioning server and a target computer. Running scriptlets Scriptlets are a list of commands embedded in a provisioning workflow that can be run without user interaction. A Java virtual machine (JVM) is used on the provisioning server to run scriptlets. The JVM is a local daemon that connects to the Common Agent service access point on a target computer to perform scriptlet actions. By default, the JVM starts when the provisioning server starts. It listens for Telnet requests from localhost on port 5191 by default. You can edit the values in the file TIO_HOME/config/agentShellServerConfig.properties that determine if the JVM starts when Tivoli Provisioning Manager starts, and the port number for monitoring Telnet requests. The Common Agent service access point can be created using default service access points for the Device.ExecuteCommand and Device.CopyFile device operations, or can be created using an RXA service access point if default service access points do not exist. For more information about RXA and how it connects to target computers to perform common agent installation, see Remote Execution and Access (RXA) service access point on page 639. Tip: For a target computer that has Cygwin installed, if you added the Cygwin\bin directory to your Windows %PATH% environment variable, it is recommended that you restart the target, to ensure that the changes take effect.
638
Remote Execution and Access (RXA) service access point

A Remote Execution and Access (RXA) service access point (SAP) is used to install the common agent if default service access points required to install it are not configured for the target system. This service access point type is defined as ipv4/RXA. Whether RXA is used to communicate with the target computers depends on your input on the Install Common Agent page, as follows: v If you provide credentials on the Install Common Agent page, RXA will be used. A service access point for the RXA protocol is installed and set up as the default service access point (if it does not already exist). Target capabilities are set up automatically. v If you do not provide credentials on the Install Common Agent page, it is assumed that a service access point is already in place. In this case, set up the target capabilities before installing the common agent. The RXA service access point provides authentication with a user ID and password, and detects and uses existing configured protocols (SSH or Windows SMB) to install the common agent. Like the Common Agent service access point, the RXA service access point supports the Device.ExecuteCommand and Device.CopyFile device operations. However, the RXA service access point is used only for installation of the common agent. Use the Common Agent service access point for other target operations. Tip: If RXA is used to communicate with the target computers, ensure that the RXA prerequisites are met. For more information, see Requirements for common agent installation on page 547.
Subagent bundles
A product-specific subagent consists of one or more 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 infrastructure based on the WebSphere Everywhere Deployment technology. The common agent is installed once on each managed computer. For example, if two management products (product A and product B) manage the same computer, the common agent is installed only once on that computer. The common agent runs two product-specific subagents: one for product A and another for product B. Two software stacks can be used to install the common agent and subagents: v Tivoli Common Agent Stack, which installs the common agent. v CDS_Depot_Stack, which installs the common agent, subagents, and the dynamic content delivery depot. A number of subagent bundles are installed when you install the common agent. You can also install these bundles separately if a target computer already has the common agent. Tivoli Common Agent Stack includes the following software modules:
Table 111. Software modules in Tivoli Common Agent Stack
Software Module TCA-1.4.2 TCA-Feature Tivoli Provisioning Manager Base Description Tivoli Common Agent Version 1.4.2
CDS_Depot_Stack includes the following software modules:

639
Table 112. Software modules in CDS_Depot_Stack

Software Module TCA-1.4.2 TCA-Feature Tivoli Provisioning Manager Base TCA-Feature Tivoli Provisioning Manager Depot Description Tivoli Common Agent Version 1.4.2
Additional details about using the DcdAdmin automation package are available in the automation package documentation. To view the documentation: 1. Click Go To > Administration > Provisioning > Device Drivers. 2. In the list of device drivers, click DCDAdmin. 3. Click the Documentation link.
Table 113. Automation package documentation for the software modules
Software Module Common Agent service access point Remote Execution and Access (RXA) service access point Device Driver Tivoli Common Agent Service Access Point Tivoli Remote Execution and Access Service Access Point
Installing the common agent on managed systems

If all of the prerequisites are met, the common agent and the subagents must be installed on all servers and workstations so that you can install and uninstall software products and perform inventory scans. You can install the agent and subagents on multiple target computers that do not have the common agent, including discovered computers or computers that you added to the data model without using a wizard.
Before you begin

Installing the common agent on the provisioning server, where the agent manager is also installed, is not supported. To install the common agent and subagents:
Procedure
1. Click Go To > Deployment > Software Management > Common Agent Installation. 2. Under Common Agent Stacks, click the common agent software stack for the task. 3. Click Select > Computers and select one or more target computers for the task, then click OK. 4. If no default service access points (SSH or RXA) exist on the target computers, select Create Credentials and specify the credentials for creating a Remote Execution and Access (RXA) service access point on each target computer. 5. Click Schedule to schedule the task to run immediately or at a specified time. 6. Under Notification, configure the notification settings for the task. 7. Click the Advanced tab to set the configuration template parameters. For information about these parameters, see Tivoli Common Agent Stack configuration template parameters on page 633. 8. Click Submit.
Results
After the common agent and the subagents are installed on the specified target computers, the target computers are scanned and the software and hardware inventory information is added to the data model.
640
Installing the common agent and subagents using a stand-alone installation

A stand-alone installation of the common agent and subagents provides all of the required configurations for the agent and subagents to be installed.
Before you begin

To install the common agent on a computer that already has another common agent installed (deployed, for example, by another management application), you can use this stand-alone installation. Select the option Run as administrator for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide.
Windows 2008
The following script files are provided for the stand-alone installation of the common agent and subagents: prepareTCAImage.cmd/.sh Creates the required installation image at the specified location. The installation image contains all of the required common agent installers, subagents, and their configuration, and the response file and the installation scripts (install.bat and install.sh) that are used to install the common agent and the subagents. The prepareTCAImage script does not use properties from the software stack as defined in the Tivoli Provisioning Manager user interface, it uses values from the software definition. The prepareTCAImage.cmd/.sh command searches for a global variable called TCA.Standalone.Stack.Name. If the variable exists and points to an existing stack, it uses the properties from the software stack specified in the variable. If the variable does not exist or points to a nonexistent stack, it uses the properties from the software definition Restriction: The stand-alone installer does not support the installation of a dynamic content delivery depot subagent. If you receive the error COPCOM608E after running the prepareTCAImage command, ensure that the Tivoli Provisioning Manager server is running. install.bat/.sh Automatically installs the common agent and the subagents, following the specifications provided in the configuration files. To perform a stand-alone installation of the common agent and subagents, follow these steps:
Procedure
1. Create the required installation image on the provisioning server: a. Log on as tioadmin to the provisioning server. b. At a command prompt, change directory to %TIO_HOME%\tools (Windows) or $TIO_HOME/tools (UNIX). c. Run the following command: v Windows:
prepareTCAImage.cmd [-o <OS>]<tcaimage_install_dir>
where <tcaimage_install_dir> specifies the fully qualified path for the common agent image installation. For example, /var/tcaimage/. If the directory is not specified, a new directory is created. <OS> specifies the operating system. for example: sol for Solaris Operating Environment Sparc
641
Solaris Intel solx86 Solaris Sparc sol AIX aix Linux Intel linx86 Linux PowerPC linppc IBM on System z lin390 HP UNIX PA-RISC hprisc HP UNIX Itanium hpitan Windows - win
Note: When creating TCAimage files on Windows and transferring them to a UNIX computer, observe the following recommendations: Transfer all the files in a single package, for example in a .tar or a .zip file. After transferring and unpacking the files, check that all required permissions are set on all script and setup files. You can set the execute permission with the following command: chmod +x <file_name>, for example:
nc123072:~ # chmod +x example.sh nc123072:~ # ./example.sh EXECUTED
v UNIX:
prepareTCAImage.sh [-o <OS>]<tcaimage_install_dir>
where: <tcaimage_install_dir> specifies the fully qualified path for the common agent image installation. For example, /var/tcaimage/. If the directory is not specified, a new directory is created. <OS> specifies the operating system. For example: hprisc for HP UNIX PA-RISC
Solaris Intel solx86 Solaris Sparc sol AIX aix Linux Intel linx86 Linux PowerPC linppc Linux 390 lin390 HP UNIX PA-RISC hprisc HP UNIX Itanium hpitan Windows - win
Note: Before launching the common agent installation on a UNIX computer, the execute permission must be added before running the command.
[root@nc123006]# chmod +x install.sh <OS specific dir>/setup.lin
where: <OS specific dir> is, for example, linux86 for Linux Intel If a file without execution permission is launched, when files collected on a Windows platform are transferred to a UNIX computer, you have the following error.
[root@nc123006]# ./install.sh -bash: ./install.sh: Permission denied
Optionally, you can also provide the repository location for the common agent installers (if different from the default one), as a second argument to the previous command. The image that is created contains the following elements:
Table 114. Common agent installation image elements Name aix/ hpux/ Description AIX common agent and JRE installer. HP-UX common agent and JRE installer.
642
Table 114. Common agent installation image elements (continued) Name hpux-ia64/ linux390/ linux86/ linuxppc/ solaris/ solarisx86/ windows/ properties/ install.sh install.bat, ihscript.vbs caInstall.rsp readme.txt Common agent installer response file, editable. Provides instructions on how to use the common agent and subagent installer. Description HP-UX-ia64 common agent and JRE installer. Linux on S/390 common agent and JRE installer. Linux/x86 common agent and JRE installer. Linux/PPC common agent and JRE installer. Solaris common agent and JRE installer. Solaris/x86 common agent and JRE installer. Windows common agent and JRE installer. Subagent properties. UNIX installation script. Windows installation scripts.
d. Optional: Edit the configuration files, which are stored in the newly created image directory. v The Agent Manager Host name is provided by the prepareTCAImage.cmd or prepareTCAImage.sh script files. v The Agent Manager Hostname is provided in the caInstall.rsp file. e. Optional: Review the subagent configuration files, located in the properties/ directory. In the jes.properties file, review the following parameters: PollingInterval If required, you can change the default polling interval as described in the Changing the default polling interval on page 542 topic. Addr This parameter specifies the IP address of the device manager federator that the device manager subagent installed on the target computer communicates with. Depending on the environment, it can be either the IP address of the device manager federator installed on the provisioning server or the IP address of the device manager federator agent installed in a branch or regional location.
f. Optional: If required, you can provide a truststore file, by copying the agentTrust.jks file to the root directory of the image. During installation, this file is copied to the <agent_install_dir>/ runtime/agent/cert directory, where <agent_install_dir> is the common agent installation directory. If the CASInstall.TrustoreType parameter is set to copy and the CASInstall.TrustStoreLocation parameter is set to cert, then the agentTrust.jks file must be placed in the <tcaimage_install_dir>/<OS_name>/cert directory, where <tcaimage_install_dir> is the location of the common agent image installation. Example: 1) In the C:\tcaImage\windows\caInstall.rsp file, ensure that the following two parameters are set as described:
CASInstall.TruststoreType="copy" CASInstall.TrustStoreLocation="cert"
2) Replace the existing agentTrust.jks files in the following directories: v C:\tcaImage\aix\cert v C:\tcaImage\hpux\cert v C:\tcaImage\hpux-ia64\cert
643
v v v v v
C:\tcaImage\linux86\cert C:\tcaImage\linux390\cert C:\tcaImage\linuxppc\cert C:\tcaImage\solaris\cert C:\tcaImage\solaris86\cert
v C:\tcaImage\windows\cert 3) Run the C:\tcaImage\install.bat file. The agent now registers with the agentTrust.jks file. g. For Windows systems, if there is no C: drive on the target computer, complete the following steps, where the <tcaimage_install_dir> is the location of the common agent image installation directory: 1) Open the <tcaimage_install_dir>\windows_tca.tpm.feature.zip file and update the tca.tpm.feature.properties file by changing the following row to replace C: with the current system drive:
from.site=file:C:/tcatemp/com.ibm.tivoli.tpm.management.agent
2) Open <tcaimage_install_dir>\windows_tca.tpm.depot.feature.zip and update the tca.tpm.feature.properties file, changing the following row to replace C: with the current system drive:
from.site=file:C:/tcatemp/com.ibm.tivoli.cds.depot.cas.CdsDepot
3) Open <tcaimage_install_dir>\windows\caInstall.rsp and change the following two rows to replace C: with the current system drive:
-P installLocation="C:\Program Files\tivoli\ep" -W CASInstall.ProductFeaturesURL="file:/C:/tcatemp/windows_tca.tpm.feature.zip"
2. Transfer the installation image created in step 1 using mount or CD/DVD to the remote target computer on which you want to install the common agent and the subagents. 3. On the target computer, log on as Administrator (Windows) or root (UNIX or Linux), and run install.bat (Windows) or install.sh (UNIX or Linux) to silently install the common agent and all the subagents on the remote computer, using the image created in step 1 on page 641. Important: v Do not run install.bat before you have transferred the images over to the target. Tip: You can check the install.log file located in the common agent installation directory for any installer output information and error messages.
Results
The common agent and all the subagents are installed on the remote target computer.
What to do next
After the common agent installation is completed, run the Tivoli Common Agent Discovery configuration. The discovery scan will discover all the target computers that are registered with the agent manager. The data model is updated with the new target computers, which are now ready to be managed by the provisioning server. For information about the agent discovery algorithm, see Agent discovery algorithm on page 645. OEM installation using the stand-alone installer: The stand-alone installer provides an option for enabling the OEM installation.
644
The stand-alone installer also provides an option for enabling the OEM installation, which is intended to be run on an operating system that can be used as a base OS image for other new target endpoints. This enables the distribution of the common agent to multiple endpoints, as part of an operating system stack. Unlike the default installation, the OEM installation of the common agent does not automatically start the common agent after installation. The common agent however is configured and contains subagents. The common agent is started only after the first system reboot. During the first startup, the common agent determines that the operating system ID is incorrect, and triggers the generation of a new, real, Tivoli GUID value. The new value is then used to register the common agent with the agent manager. A typical use case for the common agent OEM installation can include the following steps: Procedure 1. Create the required installation image as described above. 2. Edit the C:\tcaImage\caInstall.rsp file to ensure that the line for the CASInstall.OEMInstall parameter is not commented out, and the parameter value is set to true. By default, it is set to false. -W CASInstall.OEMInstall="true" 3. On the target computer, log on as Administrator (Windows) or root (UNIX or Linux), and run install.bat (Windows) or install.sh (UNIX or Linux) to install the common agent and all of the subagents using the image created in step 1. The common agent is not automatically started after the OEM installation. You can check the install.log file located in the common agent installation directory for any installer output information and error messages. Agent discovery algorithm: You can run this discovery configuration to add the computer and its information to the data model. Note the following information about the agent discovery algorithm: IP address If the IP address of the agent changes, you must run the Tivoli Common Agent Discovery configuration to update the data model. The IP address is not updated automatically. Host name If the host name of a computer is changed, this information is only updated after the agent is restarted. However, running the Tivoli Common Agent Discovery configuration does not update the host name of the computer in the data model. Agent information If the new information matches an existing computer in the data model, the information is updated. If the new information does not match an existing computer in the data model, a new computer is created.
Return codes for the common agent installation

The installation program sets the return code to reflect the success or failure of the installation procedure. It also writes the return code to a log file. For the common agent installation, the return values can be found in the CA_HOME/runtime/agent/logs/ install/epInstallStatus.log file, where CA_HOME is the common agent installation directory. The return values have the following format for an installation:
#date_and_time InstallStatus=number
For the common agent uninstallation, return values are written to the CA_HOME/runtime/agent/logs/ install/epUnInstallStatus.log file.
645
For an uninstallation, the file has the following format:

#date_and_time UnInstallStatus=number
where the number variable has a signed integer value. For example, the following lines in the epInstallStatus.log file indicate a successful installation:
#Tue Oct 25 10:38:08 EDT 2005 InstallStatus=0
The following lines indicate that the installation failed:

#Tue Oct 25 10:38:08 EDT 2005 InstallStatus=45
The following table lists the common agent return values. Note: v Return codes from 31 to 44, and 47 are also used by the common agent toolkit. v Return codes from 3 to 6 see previous versions of common agent services.
Table 115. Installation, upgrade, and uninstallation common agent return values Value of InstallStatus or UnInstallStatus 0 1 2 3 Description Successful installation or uninstallation. Installation canceled by the user. A general installation error. The response file parameter beanEPInfoPanel.EP_Port contains an unsupported value. The numeric value must range from 1 to 65531. The response file parameter beanUpgradeApproval.selection contains an unsupported value. The numeric value must be either 1 or 2. The response file parameter beanRegSvrInfoPanel.DownoladTrustChoice contains an unsupported value. The boolean value must be either true or false. The response file parameter beanCopyCertOptionPanel.COPY_CERT contains an unsupported value. The boolean value must be either true or false. The response file parameter CASInstall.WindowsSpecifyUserAccount contains an unsupported value. The boolean value must be either true or false. The response file parameter CASInstall.PortsConfiguration contains an unsupported value. The supported value can be either: v DISABLE_HTTP v DISABLE_HTTPS v DISABLE_HTTP_DISABLE_HTTPS 9 10 11 12 The response file parameter CASInstall.InstallType contains an unsupported value or is not specified. The value must be install or upgrade. The response file parameter CASInstall.InstallMode contains an unsupported value or is not specified. The value must be choose, advanced, or typical. The response file parameter CASInstall.OEMInstall contains an unsupported value. The boolean value must be either true or false. The response file parameter CASInstall.IgnorePortConficts contains an unsupported value. The boolean value must be either true or false.
4 5 6 7 8
646
Table 115. Installation, upgrade, and uninstallation common agent return values (continued) Value of InstallStatus or UnInstallStatus 13 14 15 16 17 18 19 20 21 22 23 24 25 Description The response file parameter CASInstall.UnmanagedAgent contains an unsupported value. The boolean value must be either true or false. The response file parameter CASInstall.ForceInstall contains an unsupported value. The boolean value must be either true or false. The response file parameter CASInstall.TruststoreType contains an unsupported value. The value must be download, demo, or copy. The response file parameter CASInstall.StartCommonAgent contains an unsupported value. The boolean value must be either true or false. The response file parameter CASInstall.WaitForRegistration contains an unsupported value. The boolean value must be either true or false. The response file parameter CASInstall.WaitForSubagents contains an unsupported value. The boolean value must be either true or false. The response file parameter CASInstall.RollBackOnRegistrationFailure contains an unsupported value. The boolean value must be either true or false. The response file parameter CASInstall.RollBackOnSubagentsFailure contains an unsupported value. The boolean value must be either true or false. The response file parameter CASInstall.RemoveExistingJRE contains an unsupported value. The boolean value must be either true or false. A non-upgradeable version of common agent has been detected at the specified location. A more recent version of common agent is already installed on this computer. Unspecified destination directory name is not specified. The installer detected common agent files in PendingFileRenameOperations in Windows registry. These files will be deleted during the next computer restart. Restart the computer manually and then perform the installation, or change the installation directory. No writing permissions in the specified destination directory. The format of the specified URL is not valid. The specified URL does not point to an archive file. The compressed file specified by this URL is unavailable. The specified URL already exists. The response file parameter CASInstall.AgentName is not specified. The response file parameter CASInstall.AgentPort contains an unsupported value or is not specified. The numeric value must not range from 1 to 65536. The response file parameter CASInstall.NonstopPort1 contains an unsupported value or is not specified. The numeric value must not range from 1 to 65536. The response file parameter CASInstall.NonstopPort2 contains an unsupported value or is not specified. The numeric value must not range from 1 to 65536. The response file parameter CASInstall.WebContainerPort contains an unsupported value or is not specified. The numeric value must not range from -1 to 65536. The response file parameter CASInstall.WebContainerSSLPort contains an unsupported value or is not specified. The numeric value must not range from -1 to 65536. The specified common agent ports are already in use. Common agent port conflicts have been detected.
26 27 28 29 30 31 32 33 34 35 36
37 38
647
Table 115. Installation, upgrade, and uninstallation common agent return values (continued) Value of InstallStatus or UnInstallStatus 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 Description The response file parameter CASInstall.AgentManagerHostName is not specified. The response file parameter CASInstall.PublicPort contains an unsupported value or is not specified. The numeric value must not range from 1 to 65536. The response file parameter CASInstall.AgentManagerContextRoot is not specified. The connection to the agent manager was established successfully, but the trust certificate has expired. The connection to the agent manager was established successfully, but the trust certificate is not valid. The connection to the agent manager has failed. The directory specified in CASInstall.TruststoreLocation cannot be found. The agentTrust.jks file, specified in CASInstall.TruststoreLocation, cannot be found. The registration password is not valid. The common agent cannot register. The response file parameter CASInstall.RegistrationPassword is not specified. The password and password confirmation are not specified. The common agent registration passwords do not match. The password and the Windows account user do not match. The user has not been granted the requested logon type on this computer. The password is not specified. The password confirmation field can only be empty if the password is specified. The Windows account password and the confirmation password do not match. The response file parameter CASInstall.WindowsAccountID is not specified. The Windows account ID contains one or more unsupported characters: \",<,>,^,=,;,&,|,?,,,*,/,[,],:,+, 57 58 The response file parameter CASInstall.WindowsAccountPassword is not specified. The installation failed. Check epPreinsall.log in the common agent installation directory for details. Check also other log files in the runtime/agent/log/install directory. An error occurred during the common agent registration. An error occurred during subagents installation. An error occurred during the GUID installation. The CASInstall.OEMInstall is set to true, although a common agent is installed on the system. The common agent cannot be uninstalled because one or more subagents are installed on top of the common agent. The common agent upgrade failed because a number of locked common agents have been detected. The installer was not able to back up the files that were modified during the upgrade procedure. The installer was not able to load the common agent properties file. The installer was not able to set file attributes.
59 60 61 62 63 64 65 66 67
648
Table 115. Installation, upgrade, and uninstallation common agent return values (continued) Value of InstallStatus or UnInstallStatus 68 Description The installer was not able to upgrade the properties file during the installation or upgrade: v //conf/overrides/config.properties v //conf/webcontainer.properties v //runtime//agent//config//endpoint.properties v //conf//overrides//upgrade.properties v //conf//overrides//logging.properties 69 70 71 72 73 74 75 76 77 78 79 80 81 82 The installer was not able to update the common agent scripts during the installation or upgrade. The installer was not able to create the specified user account. The installer was not able to run the LWI JAVA_HOME script in order to set the appropriate JRE for the common agent. The installer was not able to update the common agent registry. The registry is stored in the ep.reg file. This error might be caused by inconsistent registry content. The installer was not able to update the common agent status. The installer was not able to create the common agent service. The installer was not able to start the common agent. The installer was not able to detect the existing JRE installation directory. The installer was not able to delete the existing JRE installation directory. The installer was not able to install the specified subagent. The subagent's descriptor does not contain any property file. The timeout value was not provided in the correct format. It must be a positive number. The library specified in the CASInstall.NativesLibraryName property already exists. The library name specified in the CASInstall.NativesLibraryName property is too long (maximum 10 characters are allowed). The installation location path specified in the CASInstall.installLocation property is not valid. The installer is not able to resolve the lightweight runtime environment instance root and the instance name. The lightweight runtime environment instance location path specified in the CASInstall.installLocation property already exists. The response file contains an empty value in the CASInstall.LWIInstanceApachePort field. The port number in the CASInstall.LWIInstanceApachePort field is not entirely numeric or between 1 and 65536. This property is mandatory on the OS/400 platform. The response file contains an empty value in field CASInstall.LWIInstanceApacheServerName. This property is mandatory on the OS/400 platform. An error occurred during subagents uninstallation. The validator of the connection to the agent manager was not able to perform the validation within the specified amount of time.
83 84
85
86 87
Common agent toolkit runtime logs

The following is a list of common agent runtime return codes, which are mostly generated while using the common agent toolkit. The toolkit is used to configure common agents.
649
Parameters
The following table lists the common agent runtime return values. Note: Return codes from 31 to 44 are also used by the installer.
Table 116. Common agent runtime return values Value of InstallStatus or UnInstallStatus 0 31 Description Successful operation performed by the common agent. v The response file parameter CASInstall.AgentName is not specified (installation return code). v The postinstallation configuration tool: the properties file specified with the -options property contains an empty value in the agentName field. 32 v The response file parameter CASInstall.AgentPort contains an unsupported value or is not specified. The numeric value must not range from 1 to 65536. v The postinstallation configuration tool: the properties file specified with the -options property contains an empty value in the agentPort field. 33 v The response file parameter CASInstall.NonstopPort1 contains an unsupported value or is not specified. The numeric value must not range from 1 to 65536. v The postinstallation configuration tool: the properties file specified with the -options property contains an empty value in the nonstopPort1 field. 34 v The response file parameter CASInstall.NonstopPort2 contains an unsupported value or is not specified. The numeric value must not range from 1 to 65536. v The postinstallation configuration tool: the properties file specified with the -options property contains an empty value in the nonstopPort2 field. 35 v The response file parameter CASInstall.WebContainerPort contains an unsupported value or is not specified. The numeric value must not range from -1 to 65536, excluding 0. v The postinstallation configuration tool: the properties file specified with the -options property contains an empty value in the webContainerPort field. 36 v The response file parameter CASInstall.WebContainerSSLPort contains an unsupported value or is not specified. The numeric value must not range from -1 to 65536, excluding 0. v The postinstallation configuration tool: the properties file specified with the -options property contains an empty value in the webContainerSSLPort field. 37 38 39 The specified common agent ports are already in use and port conflicts might occur. The common agent might not start or operate correctly. Common agent port conflicts have been detected. v The response file parameter CASInstall.AgentManagerHostName is not specified. The numeric value must not range from -1 to 65536. v The postinstallation configuration tool: the properties file specified with the -options property contains an empty value in the agentManagerHostName field. 40 v The response file parameter CASInstall.PublicPort contains an unsupported value or is not specified. The numeric value must not range from 1 to 65536. v The postinstallation configuration tool: the properties file specified with the -options property contains an empty value in the publicPort field.
650
Table 116. Common agent runtime return values (continued) Value of InstallStatus or UnInstallStatus 41 Description v The response file parameter CASInstall.AgentManagerContextRoot is not specified. v The postinstallation configuration tool: the properties file specified with the -options property contains an empty value in the agentManagerContextRoot field. 42 43 44 4546 47 4886 87 88 89 The connection to the agent manager was established successfully, but the trust certificate from the certificate authority has expired. The connection to the agent manager was established successfully, but the trust certificate is not valid yet. The connection to the agent manager has failed. Installation return codes. The registration password is not valid. The common agent cannot register. Installation return codes. Validation timeout. The validator of the connection to the agent manager was not able to perform the validation within the specified amount of time. Downloading of the trust certificates has failed, null certificates returned. Configure.sh/bat script error. One of required parameters are not provided. Specify one of the following options: v -options v -unmanaged v -amhost v -password v -prompt 90 Configure.sh/bat script error. The common agent has already been configured and it contains the certificate files. Running the configuration tool might delete or unregister the common agent. Specify the -force option to unregister or reconfigure the common agent. Configure.sh/bat script error. An error occurred while reading the password form console. Configure.sh/bat script error. An error occurred while applying the configuration to the common agent. Configure.sh/bat script error. An error occurred while installing the nonstop service for the common agent. Configure.sh/bat script error. An error occurred while starting the common agent.
91 92 93 94
Configuring the common agent

The common agent is configured with default settings when it is installed on the target computers. Some of the default configuration settings of the common agent can be modified according to your needs.
Changing the common agent default port number

The common agent configures its communication ports when you install it on a target computer. The default port number is defined in the configuration template associated with the common agent software module and is configurable.
651
The default listening port number for the common agent is 9510. If required, you can change the default common agent port number before the common agent installation. To be able to override the default common agent port number, you must define a CA-Listening-Port variable in the configuration template associated with the common agent software module. To change the default port number for the common agent installation:
Procedure
1. 2. 3. 4. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. Click the software stack, for example, Tivoli Common Agent Stack. Under Configuration Templates, click TCA default. Under Template Parameters, click New Parameter and specify the following values: a. In the Parameter field, type CA-Listening-Port. b. In the Parameter Value field, type the new default port number for the common agent. Be sure to specify an unused port, because the common agent does not check for port conflicts. c. In the Parameter Type field, click String. . 5. Click Save 6. Go to $TIO_HOME/repository/tivoli/TCA and modify the response files that are found in this directory. The file name format is caInstall.<OS>.rsp. In each file, find the line-W CASInstall.AgentPort="9510" and set the port 9510 to the new port number. Save each response file with the new value. 7. Install the agent. 8. Update the port number configured in the common agent service access point: a. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. b. In the list, find the computer that you want to update and click its name. c. Click the Credentials tab. d. In the list, find Agent-Server and click its icon. e. In the Port field, type the new common agent port number. f. Click Save .
Results
You have finished changing the default listening port number for the common agent. The new port number will be used during the common agent installation.
Starting and stopping the common agent

You can start and stop the common agent on a target computer. Stop and start the common agent when you need to restart the agent, or when you make configuration changes. Using the command line: To start the agent using the command line: Windows Use the Windows Services window or the Services folder in the Microsoft Management Console to stop the service with the following name:
IBM Tivoli Common Agent - agent_installdir
For example, the Windows service name might be:
652
Tivoli Common Agent - C:\Program Files\Tivoli\ep
The default location for installing the common agent can be customized as required. For more information about how to override the default installation path, see the Overriding the default common agent installation path topic. UNIX Run the following command: ./<agent_installdir>/runtime/agent/bin/endpoint.sh start To stop the agent on all systems using the command line: Windows Use the Windows Services window or the Services folder in the Microsoft Management Console to stop the service with the following name:
IBM Tivoli Common Agent - agent_installdir
For example, the Windows service name might be:

Tivoli Common Agent - C:\Program Files\Tivoli\ep
UNIX Run the command: ./agent_installdir/runtime/agent/bin/endpoint.sh stop Using provisioning workflows: If you have installed the common agent with RXA and already have one (not more) RXA service access point defined on the target computer, you can also use the TCA_SoftwareInstallation_Start.wkf and TCA_SoftwareInstallation_Stop.wkf provisioning workflows to start and stop the common agent and subagents. To run the provisioning workflow: 1. Click Go To > Administration > Provisioning > Provisioning Workflows. 2. Find the provisioning workflow name and click it. 3. From the Select Action menu, click Run Workflow. 4. In the SoftwareInstallationID field, type the software installation ID for the common agent installation object. To find the software installation ID, use the Data Model Object Finder application. 5. Click Run. The Workflow Status page is displayed with the status of the workflow execution. You can also use the TCA_Restart_Agent workflow to stop and start the agent. To run the provisioning workflow: 1. 2. 3. 4. 5. Click Go To > Administration > Provisioning > Provisioning Workflows. Find the provisioning workflow name and click it. From the Select Action menu, click Run Workflow. In the DeviceID field, type the DCM ID of the target system. In the Name field, type the software installation instance for Tivoli Common Agent, for example TCA-1.4.2.
6. Click Run.
Overriding the default common agent installation path

The default installation path for the common agent can also be customized at the configuration template level. The default installation path for the common agent is C:\Program Files\Tivoli\ep (Windows), /opt/tivoli/ep (Solaris or Linux), and /usr/tivoli/ep (AIX or HP-UX). You can customize the default installation path as required.
653
The install-path variable that is defined in the configuration template associated with the common agent software module specifies the default common agent installation path. The following installation path variables can be used to override the default common agent installation path: v v v v v v v v AIX_Install_Path_Override where value is /usr/tivoli/ep HPUX_Install_Path_Override where value is /opt/tivoli/ep Solaris_Install_Path_Override where value is /opt/tivoli/ep Linux86_Install_Path_Override where value is /opt/tivoli/ep Linux390_Install_Path_Override where value is /opt/tivoli/ep LinuxPPC_Install_Path_Override where value is /opt/tivoli/ep Windows_Install_Path_Override where value is C:\Program Files\tivoli\ep HPUXItanium_Install_Path_Override where value is /opt/tivoli/ep
v Solaris86_Install_Path_Override where value is /opt/tivoli/ep To override the default common agent installation path, you need to set the value of the selected parameter, for example, Windows_Install_Path_Override, to the new installation path for the common agent, for example, C:\Programme\tivoli\ep in the configuration template. To override the default common agent installation path:
Procedure
1. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. 2. Find the software stack called Tivoli Common Agent Stack and click it. 3. Under Configuration Templates, click TCA defaultnumber. 4. Under Parameter, click the icon for the appropriate parameter, for example, Windows_Install_Path_Override. 5. In the Parameter Value field, type the new installation path for the common agent, for example, C:\Programme\tivoli\ep. 6. Click Save .
Results
The default common agent installation path for the selected software definition has now changed to the specified new location. This change is permanent, meaning that any upgrades for this agent will use this value. Tip: If you want to change the common agent installation path just for the current installation of the common agent: 1. Click Go To > Deployment > Software Management > Common Agent Installation. 2. Click the Advanced tab. 3. Under Configuration Templates, click Default Template > TCA default. 4. Under Template Parameters, click the icon for the appropriate parameter, for example, Windows_Install_Path_Override. 5. In the Parameter Value field, type the new installation path for the common agent, for example, C:\Programme\tivoli\ep. 6. Click Save .
Changing the default polling interval

Before installing the common agent and the depot server, you might need to change the default polling interval from target computers and depot servers. To reduce network traffic, the default polling interval is set to one hour. You can change the default polling interval to something more appropriate to your needs.
654
Based on the total number of managed systems, you must determine the most appropriate polling interval for your needs. For small numbers of managed systems, reducing the target polling interval can be acceptable. For large numbers of managed systems, short polling intervals might be detrimental to the overall system performance. Important: You can specify values for the polling interval in two places, in the software definition, and in the software stack. If you are using the prepareTCAImage script to complete a stand-alone common agent installation, the properties for the polling interval from the software definition are used by default. You can change this behavior by setting the TCA.Standalone.Stack.Name variable and specifying a software stack to use. The prepareTCAImage command searches for a global variable called TCA.Standalone.Stack.Name. If the variable exists and points to an existing stack, it uses the properties from the stack specified in the variable. If the variable does not exist or points to a nonexistent stack, the properties from the software definition are used for the default polling interval. You can change the polling interval in the TCA-Subagent JES configuration template, available in both the Tivoli Common Agent Stack and CDS_Depot_Stack configuration templates. Each stack contains its own unique copy of the PollingInterval template parameter. If a change is required in both places, the procedure must be performed in both stacks. The following procedure describes how to change the polling interval where the properties from the software stack are used to define the polling interval. If you are using the prepareTCAImage script for common agent installations, the following procedure does not change the default polling interval unless you have set the TCA.Standalone.Stack.Name variable and specified the software stack to use for the polling interval. If you are using the properties from the software stack, complete the following steps to change the polling interval:
Procedure
1. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. 2. Find the software stack called Tivoli Common Agent Stack or CDS_Depot_Stack and click it. 3. Under Configuration Templates, expand the TCA-TPM-Base Feature default template. 4. Select TCA-JES Default. 5. Click the icon for the PollingInterval parameter and type the new interval in the Value field. For example, if you want to set it to 10 minutes, enter 00:10.
Results
You are now ready to install the common agent and the depot server. The default polling interval is reset to the specified value.
What to do next
After the polling interval is reset to the specified value, you can install the common agent and the depot server.
Configuring the default peering cache

Before installing the common agent, you can change the default size of the peering cache for dynamic content delivery files on the target computers. The dynamic content delivery files can cache on a target until they reach a default maximum limit, which is configurable. Beyond this value, the oldest files will be replaced by newest ones. If the default value is too big, you can adjust it to something more appropriate to your needs, by configuring the value of the cache_max_size parameter in the configuration template for the Tivoli Common Agent software stack. To configure the default size of the peering cache:
655
Procedure
1. 2. 3. 4. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. In the list of stacks, find Tivoli Common Agent Stack. Under Configuration Templates, expand TCA-Feature Tivoli Provisioning Manager Base.<number>. Click TCA-CDS Client URL Handler Default.
5. Under Template Parameters, expand the cache_max_size parameter, and type the new value in the Parameter Value field. 6. Click Save .
Results
You have finished configuring the default peering cache size for the target computers.
Running the common agent as a local administrator user or as LOCAL_SYSTEM

The common agent installed on a target computer runs as a service. By default, the service is set to start as the user that the agent was installed with. If the user password is changed or expires, the service fails to start until the password used to start the common agent is updated. Based on how often credentials for running the common agent are likely to change, you must determine how you want the common agent to run on your target computer: v If credentials expire or are changed frequently, you can avoid the credential-change issues by running the common agent as LOCAL_SYSTEM. In this case, the service credentials specified for the local system account are used for running the common agent service instead of the local user credentials. v If credentials are less likely to change, you can run the common agent as a local user, defined either as a local user or as a domain user. In this case, the RXA credentials specified on the Install Common Agent page are used for running the common agent service. Running the common agent as LOCAL_SYSTEM: To run the common agent as LOCAL_SYSTEM, you must set the value of the Windows_Run_Service_As_SYSTEM parameter to true in the TCA default.<dcmId> configuration template for the Tivoli Common Agent stack. The default value is false. To run the common agent as LOCAL_SYSTEM: 1. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. 2. Click Tivoli Common Agent Stack. 3. Expand Configuration Templates, of the Tivoli Common Agent Stack, Default Template, and click the TCA default.<dcmId> child template. 4. In the Template Parameters list, the Windows_Run_Service_As_SYSTEM parameter is sorted onto the next page. Advance the parameter list page by clicking the right arrow in the Template Parameters header bar. 5. Set the value of the Windows_Run_Service_As_SYSTEM parameter to true. The default value is false. Setting the value of the Windows_Run_Service_As_SYSTEM parameter to true enables the credentials specified for the local system account to be used instead of the local user credentials. Running the common agent as a local administrator user: If you want to run the common agent service as a local administrator user, you must leave the default value of the Windows_Run_Service_As_SYSTEM parameter in the configuration template unchanged, set to false.
656
The local administrator user can be defined either as a local user or as a domain user. The local administrator user will use the RXA credentials specified on the Common Agent Installation page for running the common agent service. Running the common agent as a local administrator user or as LOCAL_SYSTEM: When installing the agent, if the domain user must be used, then provide it as domain_name\domain_user not as just domain_user. The user can also be passed as domain_user@domain. However domain_name\domain_user is the recommended usage.
Configuring dynamic content delivery

Information regarding the Dynamic Depot Selection (DDS) algorithm in dynamic content delivery.
Distribution
The Dynamic Depot Selection (DDS) algorithm in dynamic content delivery determines the best depots in which to cache a file when it is passed into a list of target computers. It uses a configurable ratio between depots and target computers to figure out how many depots to put in the target list. It generates a custom target list for the deployment. You will not see this target list in the list of user defined target lists. The default ratio between depots and target computers is 50. If you do not have more than 50 target computers, it will only put the file on a single depot. For example, if you have 100 target computers, and CDS_DDSS_RATIO=20 then it will try to publish to 5 depots. That is, if 5 depots have been created. You can change this ratio by creating a variable with the name CDS_DDSS_RATIO under Systems Mangement > Global Settings.
Retry window
The retry window represents the time, in seconds, that a distribution is set to expire. The distribution will expire so that the client can keep retrying the download if it fails (for example, if the management center is too busy or the depot servers are too busy during the first try). By default, Tivoli Provisioning Manager sets the retry value to 7200 seconds. You can change this window by creating a variable named retryWindowSec under Systems Management > Global Settings. The value of maxRetryIntervalSec is the maximum time to wait between retries, in seconds. The default for this value is 30 seconds. You can change the default value by creating a variable with name maxRetryIntervalSec and specifying its value in seconds.
Setting temporary directory for file publishing

Set the global variable com.ibm.tivoli.cds.common.config.tmpdir under Provisioning Global Settings > Variables to specify the temp directory that will be used for file publishing. If this variable does not exist, the propertyjava.io.tmpdir directory will be used as the temp.
Changing the data source password

Instructions on how to change the data source password in WebSphere Application Server. These steps show you how to change the data source password in WebSphere Application Server.
Procedure
1. Log on to the WebSphere Application Server console. 2. On the Security tab, click Global Security. 3. Expand JAAS Configuration and select J2C Authentication Data.
657
4. Click CDSDataAuth. 5. Enter the new password. Click Apply > OK. 6. Save your changes.
Setting up default log cleanup

To prevent cluttering the directory in a production environment, you can enable default log cleanup of the %TIO_HOME%\SCMCollectorAgent directory. Log files accumulated in the %TIO_HOME%\SCMCollectorAgent directory are useful for testing purposes, but clutter the directory in a production environment. To remedy this, you can enable default log cleanup of the %TIO_HOME%\SCMCollectorAgent directory. Log properties are defined in the %TIO_HOME%\config\log4j.prop file. The log cleanup in the directory above is specified by the log level of the com.ibm.tivoli.orchestrator.datacentermodel.helper.ComplianceHelper category in the log4j.prop file. To enable cleanup of the %TIO_HOME%\SCMCollectorAgent directory:
Procedure
1. Add the following line to the %TIO_HOME%\config\log4j.prop file:
log4j.category.com.ibm.tivoli.orchestrator.datacentermodel.helper. ComplianceHelper=<LOG LEVEL>
2. Set the value of <LOG LEVEL> to anything higher than DEBUG. For example, OFF, FATAL, ERROR, or WARN are all valid entries.
Verifying that a file was published

You can check log files to verify whether a file has been published to the depot server. After a file has been published to a depot server, you can verify whether the file was published. To do so, look at the following logs on the endpoint:
Procedure
v cds_trace_depot.log: Search for addFile: It indicates if the file was published. v rcp.log: This log verifies if it received a job to process. Look for a message like this:
2006.04.24 15:08:43-05:00 JES023I Processing job: name = SPBDistribute, requestId = 20dc8ea1d3ce11dabc68000d609d5a54
v tmp.log: This log verifies if it received a call, copyFile, to the FileManagementService. Look for a message like this:
2006.04.24 15:08:43-05:00 TPMFMS001I File copy: source file: cdss://CDS_Administrator:@9.48.182.9:9453/1145908975030 target file: file:C:\WINNT\TEMP\CitScannerAgent_w2k.jar 2006/07/14 0:49:48 com.ibm.tivoli.tpm.osgi.service.impl. FileManagementServiceImpl copyFile INFO: TPMFMS005I File copy: Copied 711 bytes.
Logging and tracing

The cdsLog.properties file contains the logging and tracing properties for each component and subcomponents. The logging and tracing properties for the dynamic content delivery depot server, management center, and client are stored locally on each component in the cdsLog.properties file. This file contains the logging and tracing properties for the component and its subcomponents. For a default installation, find the cdsLog.properties file in the following location: v
Windows
%CDS_Install_Location%\DCD\Manager\logprop
658
UNIX
$CDS_Install_Location/CDS/Manager/logprop
Important: After making changes to the logging and tracing, restart the provisioning server. v v
Windows UNIX
tio.cmd start
Linux
tio.sh start
Enabling and disabling logging and tracing

Logging and tracing for any component is determined by the component_name.logger.message.logging property in the cdsLog.properties file of that component. By default, logging and tracing is enabled for all components, meaning that the component_name.logger.message.logging property is set to true by default. To disable it, change the value to false. For example, to disable logging and tracing for a client, set the client.logger.message.logging property in the client cdsLog.properties file to false as shown in the following example:
client.logger.message.logging=false
Setting logging and tracing levels

Table 117. Tracing levels Level ERROR WARN INFO DEBUG_MIN DEBUG_MID DEBUG_MAX Description Only error messages are logged. No tracing is logged. Only warning and error messages are logged. No tracing is logged. All messages (informational, warning and error) are logged. No tracing is logged. All messages are logged. Minimal tracing information is logged. All messages are logged. Moderate tracing information is logged. All messages are logged. All tracing information is logged.
By default, the logging and tracing level of all components is set to DEBUG_MIN. To configure the logging and tracing level of a component, set the component_name.logger.level property for that component in the cdsLog.properties file to the required level. For example, to set the logging and tracing level for a depot server to the maximum setting, set the server.logger.level property in the depot server cdsLog.properties file to DEBUG_MAX as shown in the following example:
server.logger.level=DEBUG_MAX
Configuring the size and number of files

The default size for log and trace files is 8192 KB (8 MB). When a file reaches 8 MB, it is renamed and a new file is created. By default, three copies of each file are created: file_name.log The current log file. file_name1.log The log file previous to file_name.log. file_name2.log The log file previous to file_name1.log. For example, the depot server writes messages to msg_depotserver.log. When that file reaches 8 MB, it is renamed msg_depotserver1.log and a new msg_depotserver.log file is created. When that file reaches 8
659
MB, msg_depotserver1.log is renamed msg_depotserver2.log, msg_depotserver.log is renamed msg_depotserver1.log, and a new msg_depotserver.log is created. To configure the maximum number of log and trace files for a component, set the component_nameFileHandler.maxFiles property for the component in the cdsLog.properties file. For example, to set the maximum number of log and trace files for the depot server to 5, set the serverFileHandler.maxFiles property in the depot server cdsLog.properties file as shown in the following example:
serverFileHandler.maxFiles=5
To configure the maximum size of log and trace files for a component, set the component_nameFileHandler.maxFileSize value for the component in the cdsLog.properties file. Specify the value in KB. For example, to set the maximum size of log and trace files for the depot server to 10 240 KB (10 MB), set the serverFileHandler.maxFiles property in the depot server cdsLog.properties file as shown in the following example:
serverFileHandler.maxFileSize=10240
Setting logging and tracing levels

Table 118. Tracing levels Level ERROR WARN INFO DEBUG_MIN DEBUG_MID DEBUG_MAX Description Only error messages are logged. No tracing is logged. Only warning and error messages are logged. No tracing is logged. All messages (informational, warning and error) are logged. No tracing is logged. All messages are logged. Minimal tracing information is logged. All messages are logged. Moderate tracing information is logged. All messages are logged. All tracing information is logged.
By default, the logging and tracing level of all components is set to DEBUG_MIN. To configure the logging and tracing level of a component, set the component_name.logger.level property for that component in the cdsLog.properties file to the required level. For example, to set the logging and tracing level for a depot server to the maximum setting, set the server.logger.level property in the depot server cdsLog.properties file to DEBUG_MAX as shown in the following example:
server.logger.level=DEBUG_MAX
Configuring the size and number of files

The default size for log and trace files is 8192 KB (8 MB). When a file reaches 8 MB, it is renamed and a new file is created. By default, three copies of each file are created: file_name.log The current log file. file_name1.log The log file previous to file_name.log. file_name2.log The log file previous to file_name1.log.
660
For example, the depot server writes messages to msg_depotserver.log. When that file reaches 8 MB, it is renamed msg_depotserver1.log and a new msg_depotserver.log file is created. When that file reaches 8 MB, msg_depotserver1.log is renamed msg_depotserver2.log, msg_depotserver.log is renamed msg_depotserver1.log, and a new msg_depotserver.log is created. To configure the maximum number of log and trace files for a component, set the component_nameFileHandler.maxFiles property for the component in the cdsLog.properties file. For example, to set the maximum number of log and trace files for the depot server to 5, set the serverFileHandler.maxFiles property in the depot server cdsLog.properties file as shown in the following example:
serverFileHandler.maxFiles=5
To configure the maximum size of log and trace files for a component, set the component_nameFileHandler.maxFileSize value for the component in the cdsLog.properties file. Specify the value in KB. For example, to set the maximum size of log and trace files for the depot server to 10 240 KB (10 MB), set the serverFileHandler.maxFiles property in the depot server cdsLog.properties file as shown in the following example:
serverFileHandler.maxFileSize=10240
Management center log and trace files

This section describes the log and trace files that are stored on the dynamic content delivery management center. Location of files By default, the management center log and trace files are stored in the following locations: /var/ibm/tivoli/common/ctgde/logs By default, the logging properties file for the management center is stored in the following location: /opt/IBM/tivoli/cds/manager/logprop Description of files The following log and trace files are stored on the management center:
Table 119. Log and trace files for the management center File name cdsLog.properties msg_admingui.log trace_admingui.log msg_cdsmgr.log trace_cdsmgr.log msg_cdssec.log trace_cdssec.log msg_distribution.log trace_distribution.log msg_monitoring.log trace_monitoring.log Contents The logging properties for the management center. Message and trace information for the administration user interface. Message and trace information for download plans as well as general message and trace information. Message and trace information for security. Message and tracing information for the distribution agent. Message and tracing information for the monitoring agent.
661
Table 119. Log and trace files for the management center (continued) File name msg_client.log trace_client.log msg_EPM_Install.log trace_EPM_Install.log MC_DB_Install.err MC_DB_Install.out MC_WAS_* msg_EPM_Install.log trace_EPM_Install.log trace_manager_install.log trace_rxa.log msg_rxa.log CDS_DB2_install_schema.log Contents Message and tracing information for the download applet. Message and tracing information about the installation of the management center. Logging information about the installation of the management center database. Logging information about the WebSphere Application Server settings configured during installation and uninstallation. Message and tracing information about the WebSphere Application Server settings configured during installation and uninstallation. Tracing information about the installation and uninstallation of the management center. Logging information about the Remote Execution and Access (RXA) component. Logging information for the DB2 installation.
The log and trace files are in ASCII format. If an .err file displays 0 KB as file size, the file might not necessarily be empty.
Configuring the device manager service

How to change the polling interval for lightweight run time, and how to change runtime values.
Changing the polling interval

To change the polling interval for lightweight run time: 1. Open the file C:\Program Files\IBM\tivoli\tpm\lwi\conf\overrides\TPMconfig.properties. 2. Edit the WAS_DMS_FEDERATED_AGENT_POLL_INTERVAL_IN_MINUTES property to reflect the interval that you want. To change the polling interval for WebSphere Application Server: 1. Open the WebSphere Application Server admin console using one of the following URLs. v https://<TPM_hostname>:9043/admin (secure) v https://<TPM_hostname>:9060/admin 2. Click Environment > WebSphere Variables. 3. Edit the DMS_FEDERATED_AGENT_POLL_INTERVAL_IN_MINUTES property to reflect the interval that you want. 4. Click Apply, then click Save twice. 5. Restart the provisioning server.
Changing the runtime value

The workflow JES_Parameter_Set takes three parameters: v device id v parameter name v parameter value The valid parameter names are: PollingEnabled, PollingEnd, PollingInterval, PollingStart.
662
The current values for these parameters are located in the jes.properties file in the common agent. When you run the workflow, the target computer will update the property file and then set the runtime value without restarting the common agent. If the common agent is not able to save the change to the property file, the workflow will fail and the runtime value will remain unchanged. The property file has to be updated, or else restarting the common agent or rebooting the computer will revert the file to its original value.
Device manager job timing

A formula that helps you understand the amount of time that a job will take before it is completed.
Device manager job time formula

The scalable distribution infrastructure jobs will take some time to get to the target and return. Here is a formula to help understand the time the job will take before it is completed:
(2 * DMS_F_Pi ) + JES_Pi + JT = + (optional) DI
where: v DMS_F_Pi is the device manager federated polling interval set in the WebSphere Application Server or the lightweight run time. v JES_Pi is the job execution services polling interval on the common agent. This is set in the Tivoli Common Agent stack or in the jes.properties file on the target computer. v JT is the time it takes the scalable distribution infrastructure job to run. This can include the time it takes to download files, run scans, and upload results. v DI is the time it takes the dmsresultserver to process the incoming results from all of the target computers. It is typically a quick process, but it can take some time, depending on the number of target computers.
Device manager tracing

How to turn on device manager tracing to collect logs that can be submitted to IBM Tivoli Software Support.
Before you begin

The device manager logs to collect for IBM Tivoli Software Support are: v TraceDMSn.log v DMSMsgn.log v SystemOut.log v SystemErr.log Logs are recorded in the C:\Program Files\IBM\WebSphere\AppServer\profiles\ctgAppSrv01\logs\ MXServer\TraceDMS<number>.log file. Turning on tracing for the device manager involves editing the traceConfig.properties file by doing the following steps:
Procedure
1. Locate the traceConfig.properties file. v Location of the device manager only:
%WAS_HOME%/profiles/ctgAppSrv01/installedApps/ctgCell01/DMS_WebApp.ear/ dmserver.war/WEB-INF/classes/traceConfig.properties
v Location of the device manager (includes all of the device manager servers in a cluster):
663
/opt/ibm/tivoli/tpmfsw/DeviceManager/config/dmserver.war/ WEB-INF/classes/ traceConfig.properties
2. Set the following values in the traceConfig.properties file: v TraceLevel: Set this value to 3. The default value is 1. There are four possible TraceLevel values: 0, 1, 2, and 3, where 3 gives the most detail and 0 means that no trace messages will be shown. v DISPLAY_ENTRY_EXIT: Set this value to true. v MaxFileSize: Sets the maximum file size of each file. Set this value to 55555. v MaxTraceFiles: Sets the maximum of files. When the maximum is reached, the oldest file is deleted. Set this value to 10. v Set tracing for all of the following device manager components to true: component.console=false component.dmserver=true component.event=false component.notification=false component.plugins=true component.resultscollector=false component.twgapi=false component.database=true component.enrollserver=true component.datconverter=false
component.mcollect=false component.notificationhandler=false component.api=true component.userservices=true component.federator=true
What to do next
When the changes have been implemented, restart the server so that the changes will take effect. Note: If you think there are problems, copy the trace files to another location so that they are not overwritten.
Device manager trace log files

Lists of log file names, their locations, and what information they record.
Device manager trace file

The device manager trace files are named TraceDMSn.log, where n indicates the number of the trace file. The full file path is WAS_PROFILE_DIR/logs/DMS_AppServer/DMSMsgn.log, where WAS_PROFILE_DIR is the WebSphere Application Server profile directory.
Application server log files

The following log files are produced for device manager byWebSphere Application Server. These message logs include messages found in the device manager log files, WebSphere Application Server messages and possibly device manager messages (which are not logged in the device manager log files). These application server logs might become very large, so you should frequently check them and manage their size. SystemOut.log This log file gathers standard out information from the DMS_AppServer application server. The full
664
file path is WAS_PROFILE_DIR/logs/DMS_AppServer/SystemOut.log. You can use this log file to determine whether DMS_AppServer was started without exceptions and to view trace messages when tracing is active. SystemErr.log This file gathers standard error information from the DMS_AppServer application server. Use this log file to view exceptions by device manager servlets that were added to the standard error stream. The full file path is WAS_PROFILE_DIR/logs/DMS_AppServer/SystemErr.log.
WebSphere Application Server log files

The directory in which WebSphere Application Server log files are placed is determined by the WAS_LOGS_DIR variable. This parameter is set in the Common Properties tab of the WebSphere Application Server console. The /DMS_AppServer directory is the correct directory for an unmanaged server deployment (single computer), unmanaged server with remote database deployment (single computer with remote database), and proof of concept deployment. Note: For a managed server deployment, the log files for the first device manager server in a cluster are located in the WAS_PROFILE_DIR/Server directory.
Using the device manager console

Using the device manager console to view your jobs.
Before you begin

Ensure that the device manager application server (MXServer) and the TPMVirtualHost match. The following steps describe how to use the device manager console.
Procedure
1. Log on to the WebSphere Application Server console. 2. Navigate to Servers -> Application Servers -> MXServer -> Web Container Settings -> Web container transport chains. 3. Record the WCInboundDefault port number. 4. Navigate to Environment ->Virtual Hosts -> TPMVirtualHost -> Host Alias. 5. Ensure that there is an entry for the host name and port. This is the port from step 3. 6. Restart WebSphere Application Server. 7. Launch dmconsole and specify the device manager server. For example:
<fully_qualified_hostname>:port
where port is the port number from step 3. 8. Change the directory to dmconsole_dev and run the DMconsole.bat file. For the user name and password, use dmadmin / dmadmin. Leave the other fields with their default values. Ignore the error that appears. 9. In the left navigation pane, click Jobs and then click Submit.
Results
You will now be able to view your jobs. Click View > Refresh to update the data.
Verifying the device manager installation

A command and log file that use to verify that the device manager service was installed and configured correctly.
665
Follow these steps when you want to make sure that the device manager is installed and configured correctly.
Procedure
v Run the command:
https://<fully_qualified_host_name_server>:9045/dmserver/TraceServlet?trace=set
If the installation is successful, the command returns SUCCESS! v Check the log files for errors. The log files are located in the %WAS_HOME%\profiles\ctgAppSrv01\ logs\MXServer directory, in the DMSMsgn.log and TraceDMSn.log files (where the last n is replaced by 1).
Device manager log files

These log files contain important information, warning, and error messages and must be monitored by the administrator. These files are self propagating and are limited in size.
Device manager log file locations

The administrator must monitor the device manager log files, which contain important information, warning, and error messages. These files are self propagating and are limited in size. The files are named DMSMsgn.log and DMScareMsgn.log, where n indicates the number of the message log file that wraps between numbers 1, 2, and 3. The number of each log file indicates how new each message is, with log files ending with 1 containing the newest device manager device managermessages and the log files with 3 containing the oldest. DMSMsgn.log The log file contains messages from the device manager servlets. The log is located in the WAS_PROFILE_DIR/logs/DMS_AppServer/DMSMsgn.log (where the n at the end is 1, 2, or 3, and WAS_PROFILE_DIR is the WebSphere Application Server profile directory). Log messages are also added to the trace log files so it is easier to trace the flow of actions. DMScareMsgn.log This log file contains messages from the device manager care applications. The log is located in WAS_PROFILE_DIR/logs/DMS_AppServer/DMScareMsgn.log (where the n at the end is 1, 2, or 3, and WAS_PROFILE_DIR is the WebSphere Application Server profile directory).
Log file locations for the device manager console

Errors and messages are logged in the C:\console_install_dir\logs\DMconsole_stdout.log and C:\console_install_dir\logs\DMconsole_stderr.log files. The following log files are used by the device manager console for logging errors and messages: v Standard out information from the device manager console is located in the C:\console_install_dir\ logs\DMconsole_stdout.log file. v Standard error information from the device manager console is located in the C:\console_install_dir\ logs\DMconsole_stderr.log file.
Installation, migration and removal log file locations

Locations and descriptions for log files that are used during the device manager installation. These log files are used during the device manager installation:
666
Table 120. Log file locations File name /TEMP_DIR/DMS_install.log /TEMP_DIR/DMS_uninstall.log /DeviceManager/log/dms_config_trace.log Description Contains information about the device manager installation. Contains information about the uninstallation of the device manager. Contains detailed installation information for device manager server and device manager database configurations. Contains information about the device manager migration.
/DeviceManager/log/dms_migrate_trace.log
Lightweight device manager log files

Log file locations for the Lightweight device manager.
Log file location

Lightweight device manager log files: These log files are located at: lwi_Install_Location\runtime\ base\workspace\.metadata\.plugins\com.tivoli.eDMS\.temp\com.tivoli.eDMS
Upgrading the common agents

Verify that the workflow TCAupgrade_CreateSPBs has run successfully. This workflow creates the upgrade software package blocks that are used to upgrade the common agent. If the workflow was not run successfully, you can run it again. You can upgrade the common agents, versions 5.1.1.2 and 7.1 and higher to version 7.2, that is, from the Tivoli Common Agent, version 1.3.2.29 or higher version to version 1.4.2.1. You can perform the upgrade using the deployment engine infrastructure or the scalable distribution infrastructure. The deployment engine infrastructure is used for automating operations on smaller sets of managed target computers. You can centrally manage software distribution using the scalable distribution infrastructure.
Upgrading the common agent with the deployment agent infrastructure

To 1. 2. 3. 4. 5. 6. 7. 8. upgrade the common agent with the deployment engine infrastructure, follow these steps: Click Go To > Deployment > Provisioning Computers. Click the Credentials tab. Ensure that no default service access point is defined in the Custom operations for endpoints field for the target on which you want to perform the upgrade. Click Go To > Deployment > Software Management > Software Product Upgrade. Select one or more target computers where you want to upgrade the common agent. Select Upgrade to a new version. (Optional) Schedule the provisioning task to run at a specified time. Click Submit.
Upgrading the common agent with the scalable distribution infrastructure

To upgrade the common agent with the scalable distribution infrastructure, follow these steps: 1. 2. 3. 4. Log on to the web interface. Click Go To > Deployment > Provisioning Computers. Click the Credentials tab. Ensure that a default service access point is defined in the Custom operations for endpoints field for the target on which you want to perform the upgrade.
667
5. Publish the required installables for the agent upgrade for your operating system to selected depot servers: Note: From the list of installables provided for the common agent upgrade, you must determine what operating systems you have on your target computers and publish only the installables that are required for those operating systems. You can avoid generating unnecessary traffic by publishing only the required installables over a fast connection and to a depot server that is close by. a. Click Go To > Deployment > Software Management > Software Product Publishing. b. Type a name for the provisioning task. This name is used to view the provisioning task status on the Provisioning Task Tracking page. c. Under Select Software, specify the installation file for the provisioning task. d. Under Select Depots, select one or more target depot servers for the provisioning task. e. Click Submit. 6. (Optional) Distribute the installables to the target computers. If files are not distributed, the upgrade step also performs the distribution. a. Click Go To > Deployment > Software Management > Software Product Distribution. b. Under Select Software, select the software product that you want to distribute. For example, TCA-1.4.2.1 Upgrade. c. Under Targets, specify the target computers where you want to copy the software. d. Schedule the provisioning task to run at a specified time. e. Click Submit. A single implementation of the SoftwareInstallable.Distribute logical management operation is assigned to each selected installable. To distribute all of the required packages, select to distribute the required upgrade software package, and all the other packages are distributed automatically to the target systems. 7. Upgrade the common agent on the target computers: a. Click Go To > Deployment > Software Management > Software Product Upgrade. b. Under Select Software, select the common agent installable for the upgrade, for example, TCA-1.4.2.1. c. Under Targets, filter the displayed targets By Computer or By Group, and then select the target computers or the provisioning group for the provisioning task. Tip: To be able to sort the target computers By Group, first create a dynamic provisioning group that includes all of the computers that have the upgradeable version of the common agent, 1.4.2.1. The dynamic provisioning group can be created based on a specific inventory report. d. (Optional) Schedule the provisioning task to run at a specified time. e. Click Submit. The provisioning task is run against the specified target computers. When the provisioning task has completed successfully, the common agents on all the selected target computers are upgraded to the 1.4.2.1 version.
Upgrading the common agent using the stand-alone procedure

The common agent upgrade can also be performed as part of the stand-alone procedure. To perform this operation, create an installation image and transfer it to the target. You can upgrade the common agent by running the following script: On Windows upgrade.bat On UNIX or Linux upgrade.sh
668
The script is located in the root directory of the common agent installation image. For example, C:\tcaimage (Windows) or /var/tcaimage/ (UNIX or Linux). To perform a stand-alone upgrade of the common agent and subagents, follow these steps:
Procedure
1. Create the required installation image on the provisioning server. For more information about creating the installation image, see Installing the common agent and subagents using a stand-alone installation on page 641. 2. Transfer the installation image created in step 1 using mount or a CD, or DVD to the remote target computer on which you want to upgrade the common agent and the subagents. 3. On the target computer, log on as Administrator (Windows) or root (UNIX or Linux). Run upgrade.bat (Windows) or upgrade.sh (UNIX or Linux) to silently upgrade the common agent and all the subagents on the remote computer, using the image created in step 1. During the upgrade, the common agent is upgraded first, and then some of the subagents are removed, added, or updated. The log files for the upgrade are located in /tmp/TCAUpgrade/.
Uninstalling the common agent

Regardless of the installation method, you can remove the common agent and subagents from one or more target computers using the Uninstall Software Products wizard. You can also perform the uninstallation using the uninstaller in the home folder where the common agent was installed.
Before you begin

To remove the common agent from a target computer, a service access point other than the Common Agent service access point (SAP) must exist on the target computer. This service access point must support the Device.ExecuteCommand command. Software packages in the Tivoli Provisioning Manager software catalog are used when the common agent and subagents are installed.
Uninstalling from provisioning groups

When you remove the common agent using the Software Product Uninstallation page, you can select the common agent to remove, and the computers targeted for the common agent removal. You can remove the common agent and all of its subagents, or individual subagents. To uninstall the common agent from all the target computers in a provisioning group:
Procedure
1. Click Go To > Deployment > Software Management > Software Product Uninstallation. 2. Click Select Software and select the TCA-1.4.2 software product, then click OK. 3. Click Select > Groups and select your group of computers, then click OK. 4. Click Submit to uninstall the common agent.
Results
The common agent is removed from all the target computers in the selected group. Together with the common agent, all of its subagents are also removed from the target computers. Note: For an alternative way of uninstalling the common agent from a group of computers, see Unpublishing the software and uninstalling the common agent on page 581.
669
Uninstalling from individual computers

Before you begin
From the Select Action menu, click Uninstall > Common Agent You can remove the common agent from one or more selected target computers. To uninstall the common agent from an individual computer:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Search for the target computer and click its name. 3. From the Select Action menu, click Uninstall > Common Agent.
Results
The common agent is removed from the selected target computer. Removing the common agent also removes all its subagents.
Uninstalling the common agent manually

You can also manually uninstall the common agent from a target computer by using the uninstaller in the home folder where the common agent was installed. To manually uninstall the common agent from the target computer: On Windows 1. Click Start > Settings > Control Panel > Add/Remove Programs. 2. On the Add/Remove Programs dialog, select the Tivoli Common Agent program and then click Remove. The program is uninstalled and its files and registry entries are removed. 3. Manually delete the common agent installation directory from the target computer. The default installation directory on Windows is <Program_Files_Dir>\tivoli\ep>, where <Program_Files_Dir> represents the value of the Windows registry entry. 4. Delete the following files located in <Program_Files_Dir>\tivoli> if they exist: v ep.reg v ep.bak Note: If you are uninstalling all common agents from the system, delete both the ep.reg and ep.bak files. If you are uninstalling a specific common agent, delete the line in the ep.reg and ep.bak files that lists the installation directory of the common agent that you are uninstalling. For example, to uninstall the common agent installed in the /opt/tivoli/ep1 directory, delete the line that begins with:
0 | cygnus0317b | /opt/tivoli/ep1 | 1.3.0.5 | 0 | 1.4.2 | IBM Corp...
5. On Windows operating systems, delete the Windows service for the common agent. Use one of the following methods: v Run the srvinstw.exe command, which is available in the Windows Resources Toolkit. This command launches a window in which you select the service to be deleted. v Download the InstallUtil utility. Run the following command:
InstallUtil uninstallservice service_name
670
v Manually edit the Windows Registry. Important: Be careful when editing the Windows Registry. An incorrect change can damage the operating system. a. Make a backup copy of the registry. b. In a registry editor such as regedit or "regedit32", expand the following keys: My Computer HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services IBMTivoliCommonAgentn, where n is an integer starting with 0 for the first common agent that was installed on the system. c. Check the value of the Image Path key for the IBMTivoliCommonAgentn entry. This value specifies the directory in which the common agent was installed. Use the value to make sure that you are deleting the registry entry for the correct common agent. d. Delete the IBMTivoliCommonAgentn key for each common agent that you are removing. 6. 7. e. Save the changes to the registry. If a Windows account was created for the common agent and you do not need it when reinstalling the common agent, delete the account. Remove the entry for the common agent in the registry. On the server, use the RetrieveAgents, PurgeAgents, and LogicallyDeleteAgents utilities to identify and remove registry entries for the common agent. On Windows operating systems, restart the operating system to remove the Windows service. Optionally, delete the common agent installation directory. Optionally, uninstall the Tivoli GUID. On Windows, use Add or Remove Programs to uninstall TivGuid.
8. 9. 10.
On UNIX 1. Log on to the target computer as root. 2. At a command prompt, change directory to the common agent installation directory. The default installation directory is: v AIX or HP-UX: /usr/tivoli/ep v Linux or Solaris: /opt/tivoli/ep 3. In the _uninst directory, run the following command: ./uninstall.sh -console or ./uninstall -console, depending on your platform. 4. Delete the following files if they exist: v ep.reg v ep.bak Note: If you are uninstalling all common agents from the system, delete both the ep.reg and ep.bak files. If you are uninstalling a specific common agent, delete the line in the ep.reg and ep.bak files that lists the installation directory of the common agent that you are uninstalling. For example, to uninstall the common agent installed in the /opt/tivoli/ep1 directory, delete the line that begins with:
The elements are located in:

671
AIX or HP-UX /usr/tivoli/ Linux or Solaris /opt/tivoli/ 5. Manually delete the common agent installation directory from the target. From the tivoli subfolder, run the following command: rm -rf ep*. If ep is the only subfolder in the /opt/tivoli folder, you can also run the following command from the /opt directory: rm -rf tivoli.
Manually uninstalling TivGUID

Before you begin
TivGUID is a shared component and you must ensure that no other component or product is using it before you remove it from the system. To manually uninstall TivGUID, perform the following steps: On Windows 1. Use Add or Remove Programs. 2. Delete the %WINDIR%\TIVGUID file. On AIX 1. List all installed TivGUID file sets with the following command:
lslpp -L -c |grep tivguid
2. Uninstall all prerequisite file sets. 3. Uninstall the TivGUID with the following command
installp -u tivoli.tivguid
4. Delete the etc/TIVGUID file. On Linux 1. List all installed TivGUID packages with the following command:
rpm -qa |grep guid
and note the version number. 2. Uninstall the TivGUID with the following command:
rpm -e TIVguid-<version_number>
3. Delete the etc/TIVGUID file. On Solaris 1. Remove the TivGUID folder with the following command:
rm -rf /opt/tivoli/guid
2. Delete the etc/TIVGUID file. On HP 1. List all TivGUID packages with the following command:
swlist |grep guid
2. Uninstall the TivGUID packages with the following command:

swremove TIVguid
3. Delete the etc/TIVGUID file.
Manually uninstalling Common Inventory Technology (CIT)

If you want to completely remove all the files installed with the common agent, remove the TivGUID directory and the CIT directory.
672
Before you begin

For more information about removing Common Inventory Technology, see Failures during manual uninstallation of common agent on page 782. For more information about removing the TivGUID directory, see Manually uninstalling TivGUID on page 672. To manually uninstall Common Inventory Technology, perform the following steps:
Procedure
1. Delete the CIT directory. The CIT directory is located in the following path, depending on the operating system: Windows Program_Files_Dir\tivoli, where Program_Files_Dir is the value of the Windows registry entry. AIX or HP-UX /usr/tivoli Linux or Solaris: /opt/tivoli 2. Remove the cit.ini file. The cit.ini file is located in the following path: Windows %WINDIR%\cit UNIX /etc/cit
Cleaning up the data model after the manual removal of the common agent
After you have manually uninstalled the common agent, you must clean up the data model to remove all the software modules in the common agent stack that were created during the common agent installation. The default Agent-Server service access point from the target computer must be removed as well. To clean up the data model, you must run the IBM Tivoli Common Agent Discovery configuration. For more information, see Running the common agent discovery scan on page 575.
Uninstalling when regular uninstallation fails

When the regular uninstallation of the common agent fails, you can run the TCA_Force_Uninstall_Agent.wkf provisioning workflow to uninstall the agent and clean up the data model. Use the provisioning workflow to uninstall the agent and clean up the data model only when the regular agent uninstallation fails for some reason, or the data model is not aware that the agent is installed. For example, when the common agent fails to connect to the agent manager and a reinstallation is required. To run the TCA_Force_Uninstall_Agent.wkf workflow:
Procedure
1. Click Go To > Administration > Provisioning > Provisioning Workflows. 2. Search for the TCA_Force_Uninstall_Agent provisioning workflow and click its name. 3. From the Select Action menu, click Run Workflow. 4. In the DeviceID field, type the device ID for the target computer. In the EpInstallPath field, type the fully qualified path where the common agent is installed. If the fully qualified path is not specified, the workflow will look up the installation path for the specified target in the data model. An exception is thrown if the path is not found in the data model. 5. Click Run.
673
What to do next
The workflow runs successfully and uninstalls the agent and cleans up the data model.
Removing expired agents

You can use the commands in the Agent Manager toolkit to remove expired agents.
Before you begin

In a typical scenario, you perform the following steps: 1. Use the RetrieveAgents utility to request a list of all common agents. 2. Use the LogicallyDeleteAgents utility to logically delete common agents that have not sent an update recently. The certificates for the logically deleted common agents are revoked. 3. Use the PurgeAgents utilities to delete any common agents that are marked as expired. 4. Run the common agent discovery. Note: You can use the commands in the Agent Manager toolkit to remove expired agents from the Agent Manager or the workflow TCA_DeleteServerFromAMAndDCM. For more information, see Cleaning up the agent manager database on page 689. You can use the commands in the Agent Manager toolkit to list all the registered agents, delete an agent, and remove expired agents. You can also use the workflow TCA_DeleteServerFromAMAndDCM. For more information about cleaning up the agent manager database, see Cleaning up the agent manager database on page 689. You can find the usage for each script in the read me file for each command in the AgentManager_Home/toolkit directory. The default directory for AgentManager_Home is as follows: On Windows C:\Program Files\IBM\AgentManager On UNIX /opt/IBM/AgentManager To remove expired agents:
Procedure
1. Log in as root, Administrator, or Provisioning Administrator (tioadmin). 2. Browse to the AgentManager_Home/toolkit/bin directory and run the following command:
RetrieveAgents.sh [bat] -toolkitPassword <password> [-me<IDS>]
where: password Is the password of your database administrator. me Is the Managed Element ID
This parameter is optional. If you do not specify it, the command returns all agents. The following text is an example of the output of the command:
todxs05:/opt/IBM/AgentManager/toolkit/bin # ./RetrieveAgents.sh -toolkitPassword mypassword 3 Agent(s) found. Agent 0: Agent Name: todaix06.think.lab.austin.ibm.com Hostname: todaix06.think.lab.austin.ibm.com IP(s): 10.0.1.47 Port: 19510 Install Directory: file:///usr/tivoli/ep/runtime/agent Managed Element ID: 46d461faecc33e718b2b21259fc2cb71
674
Operating System ID: 9e68170443c511dd915308630a00012f Agent 1: Agent Name: todblade05 Hostname: todblade05.think.lab.austin.ibm.com IP(s): 10.0.1.53 Port: 9510 Install Directory: file:///C:/Program Files/tivoli/ep/runtime/agent Managed Element ID: 6f5148b2876839adadd7e8bb05663b5d Operating System ID: 853fbb21b5d911dd890500096bb561a3 Agent 2: Agent Name: todblade06 Hostname: todblade06 IP(s): 10.0.1.54 Port: 19510 Install Directory: file:///C:/Program Files/tivoli/ep/runtime/agent Managed Element ID: 4f11277a9b993df5b9f1781362399fc1 Operating System ID: 26a20321ca4c11dda67b000d604e985b
3. To delete the expired agents, run the following command specifying the managed element ID retrieved in step 2 on page 674:
LogicallyDeleteAgents.sh [.bat] -toolkitPassword <password> me <IDS>
For example, to delete the todblade05 agent, with managed element ID 6f5148b2876839adadd7e8bb05663b5d, type the following command:
todxs05:/opt/IBM/AgentManager/toolkit/bin # ./LogicallyDeleteAgents.sh -toolkitPassword mypassword -me 6f5148b2876839adadd7e8bb05663b5d
4. To remove the expired agent from the list of active agents, type the following command:
PurgeAgents.sh [.bat] -toolkitPassword <password> [-me <managed_element_ID>]
For example, to purge the todblade05 agent, with managed element ID 6f5148b2876839adadd7e8bb05663b5d, type the following command:
todxs05:/opt/IBM/AgentManager/toolkit/bin # ./PurgeAgents.sh -toolkitPassword mypassword -me 6f5148b2876839adadd7e8bb05663b5d
5. You can now list all the agents again to see which agents are still active. 6. Run the common agent discovery.
Agent registration
During installation, the common agent registers with the agent manager. You can configure settings for agent registration and manage registration of agents.
Tivoli Common Agent registration process

The agent manager issues and maintains the security certificates required for communication between the resource managers and common agents. Every common agent and resource manager must be registered with the agent manager. This registration process occurs automatically. During registration, the agent manager provides security certificates to the agents and monitors the services with which each of the agents can communicate. The agent manager uses the following three port numbers to communicate with the common agents: Port number 9511 - Primary registration The agent manager listens on port number 9511 for registration requests from new agents. This communication is based on server-side SSL authentication. Port number 9512 Primary configuration The agent manager uses port number 9512 for registration of resource manager services and for
675
general communication with registered agents. This communication is based on mutually authenticated SSL. After the registration process completes, the common agent connects to the agent manager on port number 9512. Port number 9513 Public ports The agent manager uses this non-SSL port number to work around secure communication problems if the registration process fails. If a new agent cannot complete the registration process on port number 9511, it attempts to establish a connection using a non-SSL connection on port number 9513. The agent uses this unsecured connection to log the registration failure. Port number 9513 is also used to download the entire agent manager configuration. This is the first connection that is established by the agent and has to be successful to proceed with actual registration attempts on the other port numbers. It can also be used to download truststore if you choose that option during installation. The common agent registration with agent manager is available as a Web service. The common agent contacts the agent manager on the registration Web service to register itself using the information provided in the response file during installation and credentials in the agentTrust.jks file. After successful registration, the certificate revocation list, the keystore agentKeys, and password are stored in the agent cert directory. The common agent registration process with the agent manager is as follows: 1. The common agent downloads agent manager configuration through the catalog service. The common agent then uses server-side SSL communication to contact the agent manager on port number 9511. Because it is SSL communication, the host name and port number are required and security validation is performed using the certificates and agent identity. 2. The identity of the agent manager is validated automatically by testing the certificate provided by the agent manager against the certificate in the truststore file distributed with the common agent. The truststore file is called agentTrust.jks and is located in the ../ep/runtime/agent/cert directory. 3. The agent manager validates the common agent registration password, which is stored in the endpoint.properties file. 4. The X.509 certificate is generated by the agent manager and sent to the common agent, which stores it locally in the ../ep/runtime/agent/cert directory. The certificate file is named agentKeys.jks. 5. A registration event notifies the agent manager that the common agent is initialized. The registry is updated and the agent manager recognizes the agent as registered.
Agent registration attempts

When the registration process starts, the common agent makes attempts to register with the agent manager. These attempts occur at intervals of 15 seconds, 15 minutes, 1 hour, and then every hour. You can change these intervals by editing the following properties in the endpoint.properties file: v Registration.Retry.Interval=15000 v Registration.Second.Retry=900000 v Registration.Third.Retry=3600000 These values are in milliseconds and you can edit them according to your network configuration. During the registration process, the first registration attempt tries to register the agent for 15 seconds plus a random time which is set in the Registration.Random=30 value in the endpoint.properties file. If this does not succeed, the next attempt occurs after 15 minutes and then an hour, and then every hour. Note: You can only edit the endpoint.properties file after the agent has been installed because the endpoint.properties is generated during the agent installation. Registration can fail for the following reasons: v The agent manager might reject the registration
676
v The registration server cannot be found v The registration credentials are invalid Changes in endpoint IP between registration attempts does not prevent the agent from registering if the new IP configuration allows for the agent to communicate with the configured agent manager and none of the other failure scenarios cause a new failure. If the reason for a registration failure is due to a communication problem, such as having the wrong IP configuration, you can initiate a registration attempt by restarting the agent. The registration information is available in the agent manager run time log files. These log files are available in the agent manager server logs and are named as activity.log and SystemOut.log. You can view information about enabling tracing, as follows: v For information about enabling agent manager tracing on the TPM server, refer to Enabling or disabling agent manager tracing. v For information about enabling tracing for the agent on endpoint computers, refer to Setting log levels for Tivoli Common Agent.
Determining the common agent name

The common agent name (also known as the agent label) is set to the name of the local machine by default. It is determined on the endpoint computer by running the hostname command. When the endpoint.properties file is created during run time, a check is performed automatically to assign the short name of the common agent. The name assigned is the system host name, depending on the IP address.
Determining the common agent host name

The common agent host name is determined on the endpoint computer and DNS must be configured properly and must be running. For the correct host name to exist in the agent manager database, the host name has to match the IP address on the endpoint computer when a reverse DNS lookup is performed. The agent host name is determined on the endpoint computer as follows: 1. The agent checks for all the network interfaces on the endpoint computer during the common agent installation. 2. The agent determines all IP and host name addresses bound to all network interfaces. 3. The agent checks all addresses to determine if they are loopback addresses (127.0.0.1). 4. If the address is not a loopback address, there are two possibilities: v If the InetAddress was created with a host name, this host name is returned as agent host name. or v A reverse name lookup is performed because the address is an IP address, and the result is returned on the basis of system configured name lookup service. Note: For the reverse DNS lookup to work correctly, a DNS pointer record must exist for the IP addresses used by the agent. If the DNS pointer is not set up correctly, an IP address might be returned instead of the host name. The agent host name is the short name for the result of the lookup of the host in DNS. Canonical host name is the fully qualified domain name of the endpoint.
677
Running the RetrieveAgent.sh script returns the agent name and the agent host name that are stored in the agent registry database.
Agent update in the data model

After you complete the postinstallation steps, an event is sent to Tivoli Provisioning Manager to run the Tivoli Common Agent Discovery, which updates the data model. Every time that a Tivoli Common Agent Discovery runs, it uses the information in the agent manager database to update the data model. The agent discovery queries the agent manager for the agent canonical host name and the agent host name. You can view these values by running the RetrieveAgents.sh file. If the Console.log is in debug mode, you can also see their values in the log files. The matching algorithm for the agent discovery from Tivoli Provisioning Manager is as follows: v The agent matches on existing GUID in the data model. If there is a match, it updates the existing server in the data model. The GUID is the managed element ID in the agent manager. v If there is no GUID match, the agent looks in the data model for a server that matches, as follows: 1. Agent canonical host name to the server name in the data model. 2. Agent host name to the server name in the data model. 3. Agent IP address where the host name is like the server name of the server in the data model. For example, host1.ibm.com matches host1 and host1.ibm.com matches HOST1 Note: You can omit IP addresses from matches by adding them to a list of items to be ignored. To do this, click Go to Inventory -> Discovery Configurations -> IBM Tivoli Common Agent Discovery -> Parameters. Edit the properties, adding the IP addresses that you want to omit to the Ignored IP Addresses list. 4. Agent canonical host name to the server name in the data model. 5. Agent host name statement to the server in the data model. The provisioning server then checks if there is an existing GUID in the data model for the server. If there is an existing GUID, it identifies which of the agents is new and uses that one. v If the agent does not find any server in the data model, it creates a new server. If the host name of an endpoint computer changes, the agent manager database is updated if you restart the agent. However, IBM Tivoli Common Agent Discovery does not update the host name of the endpoint computer in the provisioning server. The name of the server in the data model is only used as a label. When you discover the agent for the first time, the server is created using the host name if the server does not exist. After that point, the host name is never updated automatically. If the IP address of the endpoint computer changes, the IP address is updated automatically in the data model in the provisioning server. You can then see the IP address change reflected in the provisioning server after you perform IBM Tivoli Common Agent Discovery.
Changing the agent registration password

During agent manager installation, the default agent registration password is set to changeMe. You must change these passwords after installation, or if the current password is compromised.
Before you begin

Select the option Run as administrator for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide.
Windows 2008
The agent registration password serves two purposes: v Validating the registration of agents v Locking the agentTrust.jks truststore file
678
Therefore, when you change the password, you must update the agent manager properties, change the password in the truststore file, and redistribute the truststore file to unregistered agents and to resource managers that remotely install common agents. To change the agent registration password:
Procedure
1. Log on to the provisioning server as the user who runs the WebSphere Application Server processes. 2. Change to the AM_HOME/bin directory. 3. Change the value of the Registration.Agent.Access.Password property in the agent manager configuration file, AgentManager.properties by running the following command:
EncryptAMProps new_password
Replace new_password with the new agent registration password. This command updates the AgentManager.properties file. Note: The double quote character ( " ) is a known limitation and must not be used when creating the password. 4. Restart the provisioning server to start using the new properties file. 5. Update the agentTrust.jks truststore file by encrypting it with the new password that you specified in the preceding step. a. Start the IBM Key Management utility that is provided with WebSphere Application Server: 1) Change to the WAS_installdir/bin directory. 2) Run one of the following commands: v Windows: ikeyman.bat v AIX, Linux, and Solaris: ikeyman.sh b. In the IBM Key Management window, click Key Database File > Open. c. In the Open window, specify the truststore file: 1) In the Key database type field, click JKS. 2) Click Browse to locate the agentTrust.jks truststore file in the AM_installdir/certs directory. If that file is missing or corrupted on the agent manager server, you can copy the agentTrust.jks from an agent or resource manager in your deployment. However, because the password for the file changes when the agent or resource manager registers, you must use the password that unlocks the file on that system, rather than the agent registration password. 3) Click OK to open the truststore file. 6. In the Password Prompt window, type the current agent registration password and then click OK. The IBM Key Management window now shows the agentTrust.jks file, which contains the signer certificate named rootcert. 7. Update the key database password: a. Click Key Database File > Change Password. The Change Password window is displayed. b. Type a new password in the Password field, and retype it in the Confirm Password field. c. Click OK. A message in the status bar indicates that the request completed successfully. 8. Copy the agentTrust.jks file to the repository/tivoli/TCA directory on the provisioning server. 9. Change the value of registration-pw in the agentmanager.xml file by running the following command: v Windows: changePassword.cmd -c agent -n <new_password> v UNIX: changePassword.sh -c agent -n <new_password> where <new_password> is the same as the new_password in step 3.
679
10. Run the TCA_PingAgentManager workflow to test that the registration password change was successful. 11. If you plan to use the standalone installation mechanism, create an installation image. For more information about creating an installation image, see Installing the common agent and subagents using a stand-alone installation on page 641. 12. Run the TCAupgrade_CreateSPBs workflow to recreate the TCA upgrade SPB's.
Results
The agent registration password is now changed.
Configuring how long agent configuration information is saved

By default, the registry contains only the most recent operational state and the associated error state record for each agent. You can configure the agent manager to save additional information. To change the retention period for configuration information:
Procedure
1. Edit the AgentManager.properties file using a text editor. The properties file is located in the following directory: WAS_HOME/InstalledApps/cell/AgentManager.ear/AgentManager.war/WEB-INF/classes/ resources. 2. Set the Status.timeToLive property to one of the following values: 0 n -1 Only the most recent record is kept for each agent. This is the default value. Keeps agent configuration records for n hours, where n is a positive integer.
Keeps all agent operation and error state records. This setting will greatly increase the size of your registry database. To estimate the storage that is needed, see Estimating database usage by the agent manager. 3. Save the file. 4. Restart the provisioning server.
Estimating database usage by the agent manager

When you install the agent manager with the provisioning server, the agent manager uses the same database as the provisioning server. There are several important factors that affect the amount of information that is stored by agent manager in the database: v The number of agents in your deployment v The length of time that configuration updates are saved By default, only the most recent configuration information is saved. However, you can configure the registry to save all updates or to delete updates after a specified number of hours. v The length of rows in the agent tables Some rows in the registry contain variable length data. For example, one column in the row for an agent error contains the message text, which can be up to 2,000 characters but is typically shorter. The calculations in Table 121 on page 681 include an average row size, as determined by examining the database during testing, and the maximum row size. The effect of row size is greater as you retain configuration updates for a longer time. The following table estimates the size of a registry containing information about one hundred, one thousand, and ten thousand agents. It shows the database size in megabytes (MB) for both average and maximum row sizes, and shows the impact of increasing the retention period for configuration updates
680
from keeping a single update to 7 and 14 days. In this estimate, the registry receives four configuration updates per day. This includes one daily update plus three event-driven updates.
Table 121. The estimated size of a registry with varying numbers of agents, configuration update retention times, and row sizes Retain most recent only Number of agents 100 1,000 10,000 Average Rows 55 MB 96 MB 511 MB Maximum Row 70 MB 246 MB 2009 MB Retain for 7 days Average Rows 69 MB 240 MB 1951 MB Maximum Row 91 MB 455 MB 4102 MB Retain for 14 days Average Rows 86 MB 408 MB 3631 MB Maximum Row 115 MB 699 MB 6543 MB
Removing old agents from the registry

Agents are not automatically removed from the registry when they become inactive or are uninstalled. To identify and remove obsolete agents from the registry, use the agent registration tools that are available in the toolkit subdirectory of the agent manager installation directory (AM_HOME). For details about the agent de-registration tools, see the README file in the toolkit directory.
Recovering unregistered agents

Periodically check the agent manager logs for common agents that are unable to communicate with the agent manager server. The recovery messages can be found in the following log file on the WebSphere Application Server WAS_HOME/logs/app_server_name/SystemOut.log. Use the information in the log files to determine why the common agents cannot register, and take corrective action.
Controlling duplicate registration

You can control whether the agent manager allows an agent that is registering with the registration password to assume the identity of another agent that is registered. This situation is referred to as duplicate registration. Duplicate registration can happen when an agent reregisters itself or when an agent maliciously attempts to assume the identity of another. By default, duplicate registration is allowed. When duplicate registration is not allowed, an agent that loses its key cannot reregister until its entry in the registry is reset. To modify the duplicate registration policy:
Procedure
1. Edit the AgentManager.properties file using a text editor. The properties file is located in the following directory: WAS_HOME/InstalledApps/cell/AgentManager.ear/AgentManager.war/WEB-INF/classes/ resources 2. Set the Registration.Agent.Reregistration.Policy property to one of the following values: Any OS Any agent might reregister. This is the default value. An agent cannot reregister, but multiple agents are allowed on a single computer system, as identified by the operating system GUID. There is no restriction on the number of resource managers on a computer system. An agent might not reregister and there can be only one agent per computer system, as defined by the operating system GUID.
None
681
Other values Any unrecognized value is treated as None. 3. Save the file. 4. Restart the provisioning server.
Setting the frequency of agent status reports

The common agent has a heartbeat function that provides periodic status reports to the agent manager. You can enable and disable the heartbeat function or change the frequency of periodic status reports. The default reporting period is 24 hours. To configure the heartbeat function:
Procedure
1. In the agent_installdir/config directory, open the endpoint.properties file. 2. Change the value for the status.heartbeat.frequency property to the appropriate time interval. The value is specified in minutes and the default value is 1440 minutes, that is 24 hours. To disable the heartbeat function, set the value to 0.
Agent manager
The agent manager supports the WebSphere Application Server service-oriented architecture run time. WebSphere Application Server products provide a highly available, reliable, and scalable application environment. You can use the agent manager in any WebSphere deployment, from a standalone WebSphere application server to more advanced configurations using application server clusters and WebSphere workload management. You can run the agent manager in its own application server or in an application server shared with other products. The agent manager has the following parts: v Agent manager server v Registry v Agent recovery service
The agent manager server

The agent manager server is the computer system where the agent manager service and the agent recovery service run. The agent manager server can run in the WebSphere Application Server environment. The agent manager can use an existing installation of a supported version of WebSphere Application Server. The agent manager applications can be installed in the same application server as your other products, or in an application server that is dedicated to the agent manager. Resource managers and agents must register with the agent manager before they can use its services to communicate with each other. Registration is password-protected, with separate passwords for the registration of agents and management applications. This makes it more difficult for a Trojan horse agent or management application to register and to gain a valid identity. You can define different users and passwords for specific types of resource managers.
The registry
The registry is a database that contains the current configuration of all known agents and resource managers. The registry contains the identity, certificates, and communication information for each resource manager, and the following information about agents: v The identity of every known agent and its computer system v The certificate issued to each agent
682
v Basic configuration information about each agent, including information about the type and version of the hardware and operating system v The configuration of each agent (updated by the agent at a configurable interval) v The errors reported by each agent (updated by the agent at a configurable interval) v The communication parameters for the agent, including the IP address, the port or ports for which the agent is configured, and the supported protocol v The agents on which each bundle is installed The information in the registry is updated by asynchronous events, such as the registration of agents and resource managers, and by updates from the agent. The agent provides a configuration update when it starts, when a bundle is installed or uninstalled, and at a configurable interval (by default, daily). By default, the registry contains only the most recent configuration update and error information about each agent. However, the retention period for these records is configurable. For all other information, the registry contains the complete history of your agents and resource managers. The registry can be placed in one of the following types of database: v In a DB2 or Oracle Database on the same computer system as the agent manager server (a local DB2 or Oracle Database). v In a DB2 or Oracle Database on a different computer system (a remote DB2 or Oracle Database). v In a DB2 database on a different computer system that is accessed using a local database alias, using DB2 Administration Client or DB2 server. To place the registry in a remote DB2 or Oracle Database, install a supported version of the database server on the remote system before installing the agent manager.
The agent recovery service

The agent recovery service is a network service that provides error logging for agents that cannot communicate with other agent manager services. Agents use an unsecured (non-SSL encrypted) HTTP connection to communicate with the agent recovery service which runs on the agent manager server as a WebSphere servlet. Because the connection is unsecured, an agent can always communicate with the agent recovery service, even when the agent is incorrectly configured or has expired or revoked certificates. Agents locate the agent recovery service using an unqualified host name. Your Domain Name System (DNS) server must map the host name TivoliAgentRecovery to the computer system where you installed the agent manager. The typical DNS lookup mechanism iterates through the domain search list for the agent, appends each domain in the list to the unqualified host name, and then performs a DNS lookup to attempt to resolve the name. The agent recovery service listens for recovery messages on up to three ports: port 80, the default unsecure port 9513 , and the unsecure port that was specified when the agent manager was installed. Using port 80 makes the request more likely to pass through a firewall between the agent and the agent recovery service. However, the agent recovery service cannot use port 80 in the following situations: v When the agent manager is on the same system as an HTTP server that uses port 80 v When the agent manager is running as a non-root user under WebSphere Application Server on a UNIX or Linux system When Tivoli Provisioning Manager is installed, the agent recovery service is configured to listen for recovery requests on port 9513. If you have a firewall between the agents and the agent manager server, allow inbound traffic on ports 80 and 9513 to the agent recovery service. Opening those ports allows agents to report registration problems. If you configure the agent manager to use a port other than 9513 for the public port, open that port as well, so that agents can report communication problems after their initial registration. Opening the
683
backup port is especially important if you disable the agent manager use of port 80.
Agent manager configuration and administration

Tivoli Provisioning Manager is closely integrated with agent manager to facilitate agent manager configuration and administration. v During Tivoli Provisioning Manager installation, the agent manager server generates new security certificates and these certificates are automatically imported into the WebSphere Application Server keystore. The installation program sets default passwords for the certificates which must be changed after installation. v When you start Tivoli Provisioning Manager, agent manager is automatically started. When you stop Tivoli Provisioning Manager, agent manager is automatically stopped. For information about agent manager installation, see the Tivoli Provisioning Manager Installation Guide.
Agent manager administration

Tivoli Provisioning Manager is a resource manager for the common agent. You can perform several administration tasks for resource managers. You can also regenerate security certificates for the agent manager server if required. Changing the resource manager registration password: Before you begin Note that the new password must match the password in the tpm/config/agentmanager.xml file. To change the password for resource manager registration, use the AuthXMLAddUser command to redefine the user whose password you want to change: Procedure 1. Edit the Authorization.xml file using a text editor. The file is located in the AM_HOME/config directory. 2. Identify all of the authType elements whose userList attribute contains the user's name. The authorization type for TPM is for the provisioning server. In the following sample Authorization.xml file, the user TPMAdmin (shown in bold face type) is in the userList attribute of the TPC and TPM authorization types:
<authorization> <user id="TPMAdmin" password="encrypted_password"/> <user id="RMAdmin" password="encrypted_password"/> <authType name="Resource Manager" userList="RMAdmin"/> <authType name="TPC" userList="TPMAdmin"/> <authType name="TPM" userList="RMAdmin,TPMAdmin"/> </authorization>
The file might contain a generic authorization list. The use of the type "*" in the following example shows that the default user, manager, can register all types of resource managers:
<authorization> <user id="manager" password=" encrypted_password"> <authType name="*" userList="manager"> </authorization>
3. At a command prompt, use the AuthXMLAddUser command to change the password. The use of the AuthXMLAddUser is described in Creating users for resource manager registration on page 685. For example, to change the password for the TPCAdmin user in the first sample Authorization.xml, when the agent manager is on an AIX, Linux, or Solaris system, run the following command:
AM_HOME/bin/AuthXMLAddUser.sh TPCAdmin mynewpassword TPC TPM
Be sure to specify all of the authorization types that are currently listed. If you omit an existing type, the user cannot register that type of resource manager. 4. Restart the provisioning server.
684
Creating users for resource manager registration: When the agent manager is installed, a single user named manager has the authority to register any resource manager. You can provide more granular authorization by restricting the access of the default user and creating users who have authority to register only specified resource managers. To create a user for resource manager registration, use the AuthXMLAddUser command, which has the following syntax: AuthXMLAddUser user_name clear_text_password auth_type [ auth_type ...] where: user_name The name of the new user. clear_text_password The password you want to set. auth_type [ auth_type ...] One or more resource manager authorization types that this user is permitted to register. The value is case sensitive. The authorization type TPM is for the provisioning server. To allow the user to register any type of resource manager, specify "*" (an asterisk symbol enclosed in double quotation marks). For example, to create the user TPMAdmin on a Windows system, setting the resource manager registration password to the string myPassword and granting the authority to register resource managers of type TPM, run the following command:
AM_HOME\bin\AuthXMLAddUser TPMAdmin myPassword TPM
To create the user rmadmin on an AIX, Linux, or Solaris system, with the password myPassword and authority to register resource managers of type TPC and TPM, run the following command:
AM_HOME/bin/AuthXMLAddUser rmadmin myPassword TPC TPM
To create the user moosa on an AIX, Linux, or Solaris system, with the password myPassword and authority to register any type of resource manager, run the following command:
AM_HOME/bin/AuthXMLAddUser moosa myPassword "*"
Configuring the login threshold and lockout periods for resource managers: The agent manager protects resource manager registration against attacks by limiting the number of unsuccessful login attempts that can be made by a user in a fixed time period. This makes it impractical for an attacker to try a large number of user and password combinations. Unsuccessful login attempts are logged. Monitor the log. A large number of failed login attempts might indicate an attack. To change the threshold for unsuccessful attempt to register using a resource manager user or the amount of time that the user is locked out: Procedure 1. Edit the AgentManager.properties file using a text editor. The properties file is located in the following directory: WAS_HOME/InstalledApps/cell/AgentManager.ear/AgentManager.war/WEB-INF/classes/ resources 2. Change the Registration.Manager.Authorization.Strikes, Registration.Manager.Authorization.ResetIntrvl, and Registration.Manager.Authorization.ResetScanIntrvl properties as follows:
685
Registration.Manager.Authorization.Strikes Specifies the threshold. Set this to the number of times a resource manager user can unsuccessfully attempt to register before the user is locked out. To disable tracking of unsuccessful attempts, set the value to zero. Registration.Manager.Authorization.ResetIntrvl Specifies both the lockout duration and the reset interval. Set this to the number of seconds that the user is locked out, which is also the amount of time before the strike count is reset (set to zero) when no additional unsuccessful attempts are logged. Registration.Manager.Authorization.ResetScanIntrvl Specifies the reset scan interval. Specify how often, in seconds, the agent manager must scan for users that are eligible to be unlocked or whose strike count can be reset because no additional unsuccessful attempts are logged. 3. Save the file. 4. Restart the provisioning server. Example
Table 122. Example of lockout configuration Parameter Registration.Manager.Authorization.Strikes Registration.Manager.Authorization.ResetIntrvl Registration.Manager.Authorization.ResetScanIntrvl Value 3 600 30
The following examples show how these settings respond to failed attempts to register. v If a user makes an unsuccessful attempt to register every 11 minutes, the user cannot be locked out because the account is unlocked after 10 minutes. v If there is one failed attempt every 9 minutes, then the strike count accumulates until the threshold is reached. When the threshold is reached, the user is locked out for 10 minutes plus any additional seconds before the next reset scan. When the ID is reset, the strike count is set to zero. Changing the password encryption key: The passwords in the AgentManager.properties and Authorization.xml files are encrypted using the HMAC-SHA1 keyed-hashing algorithm and a key that is randomly generated when the agent manager is installed. You can change the key if you suspect a security breach or if your security policy requires that passwords be changed. To change the password encryption key: Procedure 1. Stop the agent manager. For more information, see Starting and stopping the common agent on page 652. 2. Locate and delete the key file. In the AgentManager.properties file, the directory is specified in the ARS.directory property and the file name is specified in the REG.keyPWfile.name property. The next time a program that requires the key is run, the agent manager randomly generates a new key. The name of the key file and its location relative to the AM_HOME directory are indicated by the REG.keyPWfile.name property in the AgentManager.properties file. The AM_HOME directory is specified by the ARS.directory property. 3. Run the EncryptAMProps command to update the agent registration password in the AgentManager.properties file and re-encrypt the agentTrust.jks file. See Changing the agent registration password on page 678 for instructions.
686
4. Run the AuthXMLAddUser command to redefine each resource manager user in the Authorization.xml file. For information, see Changing the resource manager registration password on page 684. 5. Start the agent manager. 6. Redistribute the agentTrust.jks file to unregistered common agents and resource managers. Regenerating security certificates: In some situations, you might need to regenerate the security certificates for the agent manager. This change affects the agent manager server, the provisioning server, and all target computers with the common agent. Therefore, you must plan for implementation of security certificate files. Planning a maintenance window After you create new certificates on the agent manager server, the resource manager, and agents that rely on agent manager functions such as registration, authentication, and registry queries are unable to access these services until they have been provided with a copy of the new truststore. Plan a maintenance window for the time during which agent management functions are unavailable to existing resource manager and agent systems. Begin by creating new certificates for the agent manager on the provisioning server. You can then process the certificates for the common agent on each managed system. Creating security certificate files: Generate new security certificate files on the provisioning server. To regenerate certificates: Procedure 1. Stop the provisioning server, which also stops the agent manager. 2. Obtain the current password for the agent manager database, agent manager and the agent registration service. 3. Back up the files in AM_HOME/certs, where AM_HOME is the agent manager installation directory. Do not delete the files. 4. Open the command line processor. 5. Type "Ctrl+C" to escape the DB2 prompt. Type "set db2instance=ctginst1", then type "db2" to enter the DB2 prompt again. Type "connect to maxdb71 user maximo". Enter the following commands:
a. b. c. d. ALTER ALTER ALTER ALTER TABLE TABLE TABLE TABLE CDB.X509_CERT DROP PRIMARY KEY; CDB.MNGD_ELEMENT DROP PRIMARY KEY; CDB.AGENT_MANAGER DROP PRIMARY KEY; CDB.MNGD_ELEMENT DROP CONSTRAINT ME_FK_CON_01;
6. Delete all the rows of the table named CDB.MNGD_ELEMENT by entering the following command:
DELETE FROM CDB.MNGD_ELEMENT
7. Run the following script:

%AM_HOME%/GenerateCertificates.[sh/bat] -amPassword AM_PASSWORD -arsPassword ARS_PASSWORD -dbPassword data_base_password
This step will generate the certificates and will update the certificates if they were not deleted or backed up before running this script. 8. Add constraint to the table MNGD_ELEMENT with the following SQL query:
ALTER TABLE "CDB"."MNGD_ELEMENT" ADD CONSTRAINT "ME_FK_CON_01" FOREIGN KEY ("CLS_GUID") REFERENCES "CDB"."CLASS_TYPE"
687
("CLS_GUID") ON DELETE RESTRICT ON UPDATE RESTRICT ;
9. Restart the agent manager. 10. Verify that new files for agentTrust.jks, agentManagerTrust.jks, and agentManagerKeys.jks have been generated in AM_HOME/certs. 11. To verify if the agent manager is up and running, the following two tests need be performed: a. Enter the following URL into a web browser:
http://AM_IP:9513/AgentMgr/Info
or:
http://AM_HOST_NAME:9513/AgentMgr/Info
where: AM_IP Is the IP address of the agent manager. AM_HOST_NAME Is the host name of the agent manager. b. Run the agent manager health check tool as follows:
%AM_HOME%/toolkit/bin/ HealthCheck.[bat/sh] -toolkitPassword password
Windows AM_HOME: C:\Program Files\IBM\AgentManager Unix/Linux AM_HOME: /opt/IBM/AgentManager Note: The toolkit password should be the agent manager password. Note: If these two tests have been successful, you have replaced the security certificates. 12. Delete all files in TIO_HOME/cert. 13. Copy the agentTrust.jks file from AM_HOME/certs to TIO_HOME/cert. 14. Copy the agentTrust.jks file to the repository/tivoli/TCA directory on the provisioning server. 15. Restart the provisioning server, which automatically starts the agent manager. 16. Run the TCA_PingAgentManager.wkf provisioning workflow to verify that the provisioning server can connect to the agent manager. To run the provisioning workflow: a. Use the Find box at the top of the navigation pane to search for the TCA_PingAgentManager provisioning workflow, and click its name. b. On the Workflow Editor page, click Run > Run. No input parameters are required. Click Run again to run the provisioning workflow. What to do next You are now ready to configure managed systems with the common agent to use the new certificates. Configuring agents with new security certificate files: After you have generated new security certificate files on the provisioning server, you must distribute the new certificates to managed systems that have an installed common agent. Tip: Consider creating a favorite task that performs the steps in this procedure so that you can update certificates on multiple managed systems.
688
To configure managed systems with new certificates: Procedure 1. Stop the agent on all systems. See Using the command line on page 652. 2. Delete the contents of the agent_installdir/runtime/agent/cert directory to force the agent to reregister when it contacts the agent manager server again. 3. Copy the agentTrust.jks file stored in the repository directory to the agent_installdir/runtime/ agent/cert directory. 4. Start the agent.
Agent manager toolkit

In addition to the commands in AM_HOME/bin, the agent manager provides a toolkit of "as-is" administration tools. The toolkit is located in the AM_HOME/toolkit directory. Each set of tools in the toolkit has a README file that describes how to use it. These tools might be deleted or changed in the future, and the interfaces are subject to change. The tools are not globalized and the output of the commands is not translated.
Cleaning up the agent manager database

If you reimage a computer without uninstalling the agent, you must clean up the agent manager database. If you do not do this, every time that you run the Tivoli Common Agent Discovery, you repopulate the server with the old agent information. To clean up a server from the Data Center Model and the agent manager, run the workflow TCA_DeleteServerFromAMAndDCM. This workflow uses the DeviceID of the computer and the Agent Manager Toolkit password. The workflow only deletes the endpoint computer from the agent manager database and the Data Center Model if it cannot ping the agent. Note: This workflow removes the agent from the agent manager. If you delete a valid agent by mistake, you must reregister the agent using the configure command on the agent. You can register the agent with the Agent Manager using the following command on the endpoint: %CA_HOME%/toolkit/bin/./configure.sh -amhost <AM_HOSTNAME> -passwd <AM_PASSWORD>.
Administering installed software

After you install software on a target system, Tivoli Provisioning Manager adds information to the data model about the software components and data that are created on the system. These components are called software resources. Software resources are created based on the settings defined in software configuration templates. The software configuration template defines the default parameters for a software resource. The software resource stores information about the actual parameter values that were used during installation on the target system.
689
During installation, administrators have the opportunity to change the default values for any template parameters that are configured as editable. For instance, the example diagram shows that the default installation directory in the software installation template is C:\DB2. If this parameter is editable, an administrator can change the installation directory to another value, such as C:\IBM\DB2, at installation time. Parameter changes made at installation time do not change the template, they only affect the current installation.
Software resource types

The following types of software resources can be created on a managed system: Software installation The software installation resource represents the associated software definition in the Tivoli Provisioning Manager software catalog. v For a software product, operating system, or software patch, the software installation is a parent software resource to all other software resource types. v When software stacks are installed, an installation resource is associated with each software definition in the software stack. Instance Instances provide the ability to use Tivoli Provisioning Manager to start and stop an application instance or an application that you are running as a service. For example, the default Apache automation package includes a software configuration template with an Apache instance so that you can stop and start Apache from Tivoli Provisioning Manager. An application such as DB2 supports multiple instances. To create several database instances whenDB2 is installed, the software definition must include one software instance template for each database instance. During installation, each template creates a software resource in the data model for each instance that is configured on the target system. Application data Application data that is added to the managed system. For example, if you have saved customer data for an application that you want to copy to a target during installation, you can configure the software configuration template to create this data as an application data resource.
690
Configuration Software configuration options defined by the software configuration template associated with the installable file. This can include configuration for the software installation itself, or configuration for software that hosts the software installation. For example, a software patch might include configuration for the software product that it fixes. Cluster Domain A cluster domain managed by Tivoli Provisioning Manager is defined in the data model as software resources. Generic resource Other types of resources for specific operations. Some of these software resources are not tied to an item in the software catalog. Examples include: v A backup resource defines the backup scope for backing up the associated software installation. v Clusters members represented as software resources. v If you are using discovery to identify Windows user groups and Windows services on managed Windows computers, the information about discovered users, user groups, and services are stored as child software resources of the Windows software installation.
Resource configuration
Over time, installed software is often reconfigured or updated, making the information stored in the software configuration template out-of-date. Changes made to the configuration of a software resource are therefore stored as resource configuration data. For example, the resource configuration might include an entry that stores the directory for temporary files or an entry for the time zone of the computer. If these values change, the values for these entries must be updated.
Software concepts
Tivoli Provisioning Manager supports deployment of many types of software. Before you start working with software, it is important to understand software information is stored, and how this information is used to deploy and manage software. The software catalog is a library of all the software managed by Tivoli Provisioning Manager. Tivoli Provisioning Manager entries in the software catalog are called software definitions. A software definition stores information about a piece of software such as the name of the software, version, the file used to install the software, requirements to install or use the software, and installation options. When you install Tivoli Provisioning Manager, the software catalog includes software definitions for many types of software. If you install an automation package for a piece of software, a software definition is typically added to the software catalog automatically. You can also add software definitions manually. This option is particularly useful for adding simple software products that do not have complex installation requirements. Tivoli Provisioning Manager provides templates and built-in provisioning workflows for setting up the installation and configuration of simple software products so that you do not need to create a customized automation package to deploy them. The topics in this section describe how information is stored in the software catalog and how to manually create software definitions.
How software information is stored

A software definition is used to store information about a piece of software how it is installed. A software resource is used to describe how the software is installed on a specific computer.
691
Software definitions are typically created by Tivoli Provisioning Manager or a provisioning workflow developer who builds the automation package for a piece of software. Some parts of the software definition are closely tied to the provisioning workflows in the automation package. For example, The provisioning workflow developer can ensure that the software configuration template includes the parameters required by provisioning workflows in the automation package, and that the correct device drivers are to defined in the automation package The provisioning server automatically creates a software definition when it is provided with enough information to configure it. For example, if you configure the provisioning server to import patch entries from Microsoft Windows Server Update Services, the provisioning server can use the available information to automatically create software definition and installable file entries in the software catalog. Similarly, if an automation package includes a software definition, device drivers, and other software elements, the software elements are automatically added to the software catalog when you install the automation package.
Creation of software resources

A software definition represents a piece of software and all the information required to install and configure it. The library of software definitions is stored as a software catalog.
When software is installed, the person who installs it might select specific options or use specific parameter values. The actual configuration of software when it is deployed is stored in the data model as software resources. Software resources are created for each computer where the software is installed.
Software terminology
To manage software and automate software distribution, Tivoli Provisioning Manager stores several types of information about each software item. How to deploy the software The following information is stored together in the software catalog as a software definition.
692
The file to use for installation An installable file is the installation package or image that is used to install the software on a computer. Examples include a Windows .exe file, a .zip file, or a Ghost operating system image. The requirements of the software Software often has specific prerequisites to install or run it. These prerequisites are stored as requirements. Requirements can include specific hardware or software that must be available on the same computer. The capabilities of the software A capability is an attribute of the software that becomes associated with a computer when it is installed. Capabilities are used to validate requirements. For example, specific database capabilities are associated with DB2 in the data model. If another piece of software requires DB2, the provisioning server can check for the required capabilities on a computer before installing the software. Installation and configuration parameters To automate installation and configuration of software, the installation and configuration parameters to use must be predefined. Configuration parameters are stored in a software configuration template, which is similar to a response file for a silent installation of software. The software configuration template identifies parameters that are required by provisioning workflows that install the software. A software configuration template can contain child templates that define different parts of the installation and configuration. How software is configured when it is installed When software is installed on a computer, software resources are associated with the computer in the data model. The software configuration templates define the parameters to use for installation and configuration. The software resources store the actual values that were used with each parameter. For example, the software configuration templates might include a parameter for the installation directory and a default value. The actual value that is specified for the installation directory during installation is stored in the software resource. Installable files: An installable file is the actual software package or image file that is distributed and installed on a target system. There are two types of installable files: v General software packages. Examples include: Software packages such as Red Hat Package Manager (.rpm) files, AIX packages for use with installp (.lpp), and Microsoft Installer (.msi) files. A self-extracting file, such as a .exe file. An archived file in a format such as .zip or .tar. v System images that are installed by boot servers. When you define a installable file, you must specify the file name, file repository location. You can also specify requirements that are specific to this installable file, such as the required operating system or locale. Associating installable files with software definitions Each software definition can be associated with one or more installable files, but only one installable file is selected for installation. When there are multiple installable files, the provisioning server identifies the appropriate one to use during installation based on: v Requirements: The provisioning server compares the requirements of the installable files with the hardware and software configured on the target system.
693
v Priority: The order of installable files in a software definition determines the priority. During installation, the provisioning server starts by checking the configuration of a target computer against the requirements of the first installable file. If the target computer meets the requirements of the software definition and this installable file, the installable file is selected for installation. Other installable files are not evaluated. If the target computer does not meet the requirements, it checks for the requirements of the next installable file. Example The following example shows a software definition with three installable files.
The software definition is for a software product called Sample Product. It has an installation requirement for Windows 2000 on the target computer. Three software packages are available to install the software on a target computer: package.zip This software package has the highest priority because it is the first one on the list. It requires WinZip on the target computer to install the software. package.msi This software package is next in the priority order. It requires Windows Installer on the target computer to install the software. package.exe This software package is last in the priority order. It does not have any defined requirements. In this example, the target computer has both Windows 2000 and WinZip installed. When the provisioning server checks the target computer for requirements, it identifies a match for the Windows 2000 requirement of the software definition and the WinZip requirement for the package.zip installable file. It therefore selects package.zip as the installation mechanism for the target computer. If the target computer has Windows 2000 but does not have WinZip, the provisioning server proceeds to check the requirements of each item in the list of installable files until an appropriate match is found.
694
The iterator An iterator is a special item that you can add to the list of installable files in a software stack. It is not a file. For details, see Defining software stacks on page 709. When to use multiple installable files Situations where you might want to include multiple installable files in a software definition include: v A software definition for a software stack that has multiple associated image files. Each image has the same software but has different hardware dependencies. For each installable image, the requirements list is configured with the appropriate hardware dependencies. During installation, the provisioning server can select the correct image by matching the image requirements with the hardware configuration of the target computer. v A software definition for a patch that has software packages for different combinations of target computer configurations. For example, the software definition can contain software packages for each combination of locale and operating system. For each installable package, the prerequisites list is configured with the appropriate combination of locale and operating system. During installation, the provisioning server can select the correct installable file by matching the patch requirements with the configuration of the target computer. v A software definition that is associated with different package formats for the same software. For example, a software definition might include a self-extracting .exe file, a.zip file, and a .tar file. During installation the provisioning server can select the correct package format based on the configuration of the target computer. Software dependencies: Software dependencies are used to identify relationships between pieces of software. Dependency information is defined as requirements and capabilities. Requirements Specific hardware or software that must be available to a piece of software. Requirements are stored as individual attributes such as vendor name, product type, product family, version number, storage capacity, and available memory. Capability An attribute of hardware or software that can be used to satisfy a requirement. Requirement types define a set of related attributes. Each requirement type is associated with one or more requirement names that represent specific attributes. For example, the OS requirement type includes an attribute for different characteristics of an operating system: os.distribution The specific edition of the operating system. For example, Red Hat or Windows 2000 Advanced Server. os.family The type of operating system. For example, Linux or Windows. os.kernel.version The kernel version. For example, 2.4. This capability primarily applies to Linux. os.name The name that you want to use to identify the operating system. For example Windows 2000 Advanced Server SP2. os.servicepack The service pack level of the operating system. For example U5 or SP2.
695
os.version The version of the operating system. For example 3.0 or 2000. The labels for requirements and capabilities are the same. The defined requirement types and requirement names determine the available capability types and capability names. 'For example, jdk.version is used to identify a required Java runtime environment version number. v If you add a jdk.version requirement to a software definition with a value of 1.4.1, you are indicating that the software requires a Java runtime environment at the version 1.4.1 level. v If you add a jdk.version capability with a value of 1.4.1, you are indicating that when this software is installed, the computer will have a Java runtime environment at the version 1.4.1 level and can support any piece of software that has a matching requirement for that Java runtime environment version. Hardware requirements are for resources such as disk space or memory. For example, a software definition can include a requirement for an Intel processor. When an administrator initiates installation of the software, the provisioning server checks the target computer for an Intel processor hardware resource. Some hardware resource information can be automatically added to the data model using discovery. For more information about discovery, see the Tivoli Provisioning Manager information center. Tivoli Provisioning Manager includes predefined requirements for a variety of different types of software. Reuse available requirement types whenever possible. New requirement types are typically defined by workflow developers. Types of relationships A requirement or capability can be assigned to software definitions, software configuration templates, and software resources. Installation requirements can also be assigned to installable files. v Requirements and capabilities in software configuration templates are copied to the software resources they create when the software is installed. v Requirements and capabilities defined in software definitions are copied to all software resources that they create when the software is installed. Requirements: Requirements define dependencies on software or hardware. Requirement types Requirements can be used to define different types of relationships. v Requirements that identify an installation mechanism. For example, if a software definition definition contains a .zip and a .tar file, the requirements of each installation file identify the software required to handle the file. At installation time, the appropriate file is selected by checking the target computer against the installation requirements for each installation file. Installation requirements are only used at installation time and are not inherited by software resources on the target computer. v Requirements to run the software. For example, a Java application might have a requirement for a specific version of the Java runtime environment on the target computer. v Hosting requirements. This requirement must be met by a hosting application, or an application that acts as a containing environment for the software. This type of requirement is more common for composite applications and Java programs. For example, a servlet is a Java program that runs on a Web server and extends server functions by generating dynamic content in response to Web client requests. It requires a standalone servlet engine or an application server with servlet support to load the servlet. The servlet engine therefore acts as a
696
container for running the software. If the servlet requires a specific container environment, such as WebSphere Application Server, the software definition for the servlet can include a host requirement for it. Defining requirements You can define requirements for three different software elements: v Installation requirements are defined on installable files. v Functional requirements: Global functional requirements apply to all deployments of the software. They are defined in - The software definition for an operating system, software product, or software patch. - A software stack. Requirements that are specific to a particular configuration of the software are defined at the software configuration template level. v When software is deployed, the created software resources inherit global functional requirements and the functional requirements defined in the software configuration template used for deployment. The element where you define requirements depends on the type of requirement and the type of validation that you want to perform. Use requirements on software definitions and installable files to help you to manage installation options. For example: Requirements for different target environments You can create a software definition for a software patch that is available for different operating systems and locales. You define the operating system and locale requirements in each installable file, and then add all the installable files to the single software definition for the patch. When an administrator installs the patch, Tivoli Provisioning Manager compares the requirements in each installable with the configuration of the target system to identify the correct patch file to install. Requirements for different installation mechanisms You can create a software definition that contains the same software in different software package formats.
Each package contains the same software. For all software packages, Windows 2000 is required to run the software, so this requirement is defined at the software definition level. Two of the software packages have their own requirements that are specific to the software package installation mechanism. package.zip requires WinZip on the target computer and package.msi requires Windows Installer on the target computer.
697
If you include multiple installable files in a software definition, but you do not specify requirements at the installable file level, Tivoli Provisioning Manager chooses the first installable file in the list. In some cases, you might want to use other criteria to determine the installation priority of an installable file, such as the distance of a target from the file repository where the software package or image is stored. This type of alternative decision-making is configured and managed by the workflow developer who creates the automation package for the software. Validating requirements When software is installed, the software resources for a software installation inherits requirements and capabilities from the software definition. Requirements and capabilities in a software configuration template are also inherited by the software resource that it creates. For example, DB2 for Windows requires the Windows operating system. In an environment where DB2 is installed on systems with Windows 2003, Service Pack 2, the following settings must be configured to define this dependency: v In the software definition for Windows 2003, Service Pack 2, configure an OS capability type, and two capabilities: os.version with a value of Windows2003 os.servicepack with a value of SP2 v In the software definition for DB2, configure a prerequisite for an operating system with Windows 2003 as the version number and SP2 as the service pack level. When The Windows 2003 software is deployed to a computer, a software resource for the operating system is associated with the computer in the data model. When you deploy DB2, to the same computer, the requirement information in the software resources is checked to ensure that the required operating system version is already installed. You can assign a requirement type without a requirement name to define a less restrictive dependency. For example, you can assign the RDBRT:RDB requirement type without any requirement names if a database is required and any version or type of database will satisfy the requirement. Tivoli Provisioning Manager includes some predefined requirement types and associated requirement names. If required, you can add new requirement types and requirements to define other types of software dependencies When you start the installation of a piece of software, there are two ways that you can configure validation of a requirement: v Pass validation only if a matching capability is on the target computer. v Pass validation if a matching capability is present or if capability is absent. If you use this option, the provisioning server rejects a capability with an incompatible value, but accepts the absence of the capability. For example, if a multimedia program requires a Creative Labs Sound Blaster sound card. v Computer A has a capability for a Sound Blaster sound card. v Computer B has a capability for a Dynex sound card. v Computer C does not have a capability for a sound card. the following behavior will occur: v If the requirement for the sound card is configured for a matching capability only, the software be installed on Computer A only. v If the requirement for the sound card is configured for a matching capability or no sound card capability, the software be installed on Computer A and Computer C.
698
Capabilities: Capabilities identify attributes of a piece of software that can be used for prerequisite and corequisite validation. Capabilities can be configured in a software definition or a software configuration template. Because all installable files in a software definition share the same capabilities, you cannot define specific capabilities for an installable file. For example, a software definition for DB2, Version 8.1 can contain multiple installable files in different package formats. However, if software contained in each package shares the following capabilities: v Software name: DB2 v Software version: 8.1 When any of the software packages is used to install DB2, Version 8.1 on a target system, these two capabilities are become associated with the target computer. Tivoli Provisioning Manager checks the capabilities of the system whenever it is the target of a software deployment and requirements are specified. Capabilities are assigned to software configuration template when you will need to use attributes about each type of deployment to validate requirements for another piece of software. For example, if you have specific database instance configurations for test deployments and production deployments of DB2, you can specify capabilities on the software configuration template for each type of deployment and then other software can use this information to determine if a computer has a test or production database instance installed. The available capability types match the available requirement types. Requirement types are typically defined by a workflow developer during automation package development. If the software has requirements that are not predefined, the workflow developer can add them to the XML data that it imports into the data model. Software configuration templates: A software configuration template identifies software resources and associated configuration details that you want to represent in the Tivoli Provisioning Manager data model after the software is installed on a system. Each software configuration template is used to create a software resource on the target system.
699
In the example diagram, there are three software configuration templates. During the installation process, provisioning workflows run for each template to create software resources that are associated with the target computer. v The parent template is a software installation template. It creates a software installation resource. v Each instance template creates a corresponding software instance on the target computer. v The software configuration templates used to create the software resources are stored with the software resource information. Each template stores the parameter values that were used during software deployment. You can create one or more software configuration templates in a software definition. For example, an installation of an operating system can include different components and configuration options, depending on the requirements of the managed system and the standards in your organization. If you create a software definition for Windows 2000 workstations, you might include software configuration templates for user workstations and administrator workstations. Software configuration template types The parent template of a software configuration template is typically a software installation. Child templates then define settings for other components of the software. You can define the following types of software resources in a software configuration template: Installation The template that represents a software definition for a piece of software. It is used to create a software installation resource on a target computer. Application data The template for software entities that are generated when an application is used, such as data in a database. Application data resources are typically entities that cannot be recreated if they are lost and cannot be recovered by reinstalling and configuring a product. Back up application data resources so that they can be recovered if they are lost. Cluster domain The template for a cluster domain.
700
Configuration Configuration settings for a software installation. The entries in a software configuration template are like parameters in a response file for a silent installation of software. Feature An optional installation component of the software. For example, a software product might include optional utilities, plug-ins, or language packs that you define in a configuration template as features that a user can select during installation. Foreign configuration Configuration settings for software that hosts the software installation. For example, a software definition for a software patch might include configuration settings for the software product it fixes. Instance An application instance. This template is useful for providing the ability to start and stop an application that you are running as a service, or control an application instance in a product such as a DB2. Unspecified This special type is used in software stacks for the topmost software configuration template. This is the only type of software configuration template that does not create a corresponding software resource during software deployment. Parameters Settings in a 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 following options are also available for each parameter: v Define the type value that is required: a string, integer, or boolean value. v Select the default value. v v v v Indicate Indicate Indicate Indicate if if if if the the the the parameter is optional or required value is fixed or if a software installer can change the value at installation time value is encrypted parameter is hidden from software installers during installation
Target environments for software

There are several types of environments where you can deploy software. The actions to perform depends on the deployment environment.
Table 123. Environments for software deployment Asset Resource pools Software configuration Computers in a resource pool typically contain some common software that is required by all application tiers that use the resource pool to provision additional resources. You can define software stacks that contain the common software that you want to install on computers in a resource pool, and use compliance features to ensure that computers in the resource pool contain the required software. For information about compliance, see Compliance checks. Clusters If you use clusters to manage application workload, you can define them in the data model and deploy software to them.
701
Managed user computers
You can manage software distribution to user computers including desktops, administrator computers, and other general computers that you need to manage. v Patch management v Image management v For general software product or software stack installation, see Software distribution.
Software deployment using the scalable distribution infrastructure: You can distribute and install software products, patches, and software stacks that are defined in the software catalog. The infrastructure solution for a scalable software distribution enables the management of large numbers of target computers in a variety of topologies. The distribution infrastructure enables you to centrally manage the software distribution from Tivoli Provisioning Manager, while using a number of software packaging, software distribution, and job management services to perform the actual software deployment operations. The scalable distribution infrastructure provides a fast and reliable way to distribute and install software on individual target computers or groups of computers in complex branch office environments. Distribute and Install pages are provided for deploying software products, software patches, and software stacks to target computers. Targets are periodically scanned for installed software, to keep software inventory information up-to-date, and to check for managed computer compliance.
Defining software in the software catalog

The provisioning server stores information about all your software in a software catalog. To deploy a piece of software, the software must have an entry in the software catalog. Some Tivoli Provisioning Manager processes update the software catalog automatically. You can also manually add software to the software catalog and configure software installation options. There are several ways to add an individual pieces of software to the software catalog v Discovery. Use discovery to identify software that is already installed. v Import software. You can manually import a software package and specify the basic data required to deploy it. v Add installation files to existing software catalog entries. When you install an automation package for a piece of software, the automation package might also create a software catalog entry for you. To deploy the software, you can update the entry with information about where the installation file is stored. v Set up simple software products. A simple software product is a piece of software that only requires a you to uncompress a file or run a silent installation command to install the software on a computer. For Windows target computers, you can quickly set up this type of software for distribution. v Manually define the software. For software that you cannot add to the software catalog using other methods, you can manually configure all the data required to deploy it. Importing software packages: You can import software packages from a file repository or a local drive or directory. If you upload a file, it is stored in the default file repository. Before you begin Prerequisites: To deploy a software package, provisioning server must have information about how to install it.
702
Review the following requirements before you import a software package: v The device driver that identifies provisioning workflows to install and manage the software. v If you are importing a software package from a file repository, you must know the directory where the software package is stored. v The maximum size limit for file uploads is 2 GB. You can import any type of software package if you have a device driver installed that is capable of distributing and installing the software package. For example, a software package can be an RPM package, a .zip file, or a self-extracting file. The device driver for the software package includes the provisioning workflows needed to install the software package. When you import the software package, the wizard might prompt you for required parameters based on the selected device driver. To import software packages: Procedure 1. Click Go To > IT Infrastructure > Software Catalog > Software Product Import. 2. In the Define Software Product section, specify the name, version number, and vendor of the software. 3. In the Define Software Installable section, specify information about the actual file that you are importing. Operating system Select the operating system that the software can be installed on. File repository If you are importing from a file repository, select the one that contains the file that you are importing. If you are uploading a file, click Upload File and select a file. The file will be stored in the default file repository called LocalFileRepository. Package path The package path is relative to the root directory of the file repository. For example, if the repository path is configured as /share, and the package is stored in /share/package1, then the package path is /package1. v If you are importing from a file repository, specify the package path of the file. v If you are uploading a file, you can optionally specify a subdirectory for the file relative to the local file repository. 4. In the Installation Method section, select a Hosting Configuration Template option or Device Driver option to specify how the software is installed. If you select the Hosting Configuration Template option the operating system manages the installation so you do not need to write a workflow or specify a Device Driver. 5. Click Save. Results The software package is added to the software catalog. Importing software package blocks from the Web interface: You can now import software package block files (.SPB files) using the Web interface, and not only from the Software Package Editor like in earlier versions of Tivoli Provisioning Manager. Before you begin Prerequisites: To import a software package block file from the Web interface, the SPB file must already be created locally.
703
When you import the software package block, the import wizard prompts you for required parameters based on the installation method you selected. To import software packages, perform the following steps: Procedure 1. Click Go To > IT Infrastructure > Software Catalog > Software Product Import. 2. In the Select Installation Method section, select SPB Import. 3. In the Define Software Installable section, specify the following information about the actual SPB file that you are importing. (Optional) Operating system Select the operating system that the SPB file can be installed on. File repository Specify the destination file repository on which you want to save the SPB file. Package path The package path is relative to the root directory of the file repository where the SPB file is stored. 4. Click Upload File to choose the SPB file to upload. In File name the name of the SPB file is displayed. 5. Click Save. Results The software package block (.SPB file) is added to the software catalog of Tivoli Provisioning Manager. Manually defining software: If you want to manually define a piece of software, you must specify all the information necessary to install and configure it. The provisioning server can deploy software packages or software images in any format if an automation package with the ability to deploy the software is installed. Each software package or software image provides different kinds of information about the software, or might not contain any information that the provisioning server can automatically extract to describe the software or how to install it. As a result, each piece of software must be associated with a software definition. A software definition describes attributes, dependencies, and configuration for a piece of software in a common format that the provisioning server understands. Individual pieces of software are stored as software definitions and associated elements contained by a software definition. You can define the following types of individual pieces of software: Software product The most general type of software definition. You can define any piece of software that you want to manage as a software product. Operating system An operating system such as Windows 2000 or Red Hat Linux. An operating system is defined the same way as a software product except that you must specify the operating system information when you define the software. Software patch A software maintenance package that updates a software product after the software product is installed. When you add a software patch, you can include additional information such as the patch severity and approval status.
704
There are several other special types of software that you can define in the software catalog: Image A software image that is deployed by a boot server. Software stack A software stack is a list of software in a specific installation order. A software stack can include software products, software patches, operating systems, and other software stacks. The items in the software stack can either be specified as a list of software definitions, or an image file can be associated with the software stack. You can also remove a software definition that you no longer require. Removing a software definition also removes installable files associated with it. Before you remove a software definition, consider the impact of removing it. v Consider the impact on with software stacks that reference the software definition. When you remove a software definition, it is also removed from software stacks that reference it. Does the software stack need to be changed to handle the impact of removing the software definition? v Consider software dependencies. Do other software definitions have prerequisites that can only be met when this software is installed? Do other software definitions reference the software configuration template? You can use software views to identify software with prerequisites that this software definition meets, and to identify software with matching capabilities. v Consider the impact on computers where the software is installed. If you remove the software definition, you will not be able to uninstall it using the provisioning server in the future. Manually defining software products: By default, the software catalog includes software definitions for many common software products. If you need to manually add a new software products, the first step is creating its software definition. Procedure 1. Click Go To > IT Infrastructure > Software Catalog > Software Products. . 2. Click New 3. In the Name section, specify the name, description, vendor, and version number. Note: Each software product name must be unique. 4. In the Software Installables section, specify the actual installation file for the software. Click New Installable to add a file. Note: Use a single installable file if you only have a single software package or software image that is associated with the software definition. You can associate multiple installable files with a software definition if you have different mechanisms for installation. For example, you can include an .msi package for computers that have the Microsoft Software Installer and a compressed file for computers that have software to extract the contents of the file. At installation time, the requirement attributes of the installation files will be compared against the information about the target computer to determine which installation file to use. a. Specify the name, version number, and description. b. In the Status list, select the appropriate status of the file. c. If you are adding the file from a file repository, click the file repository name in the File Repository list. d. In the Installable Path field, type the path where the software package is stored. The path is relative to the root directory of the file repository. For example, if the repository path is configured as /share, and the package is stored in /share/package1, then the package path is /package1. e. In the File field, type the name of the file. f. If this file is specific to a locale, select the locale.
705
g. Click Submit. An entry is added to the list of installation files. 5. Optional: In the Provisioning Groups section, you can add the software to a provisioning group to categorize and organize your software. Click Assign to Provisioning Group and select a provisioning group. 6. Requirements and capabilities for the software can be defined in several ways and will be explained in a later step. Create your software configuration templates with the specific installation parameters to use during installation of the software. For details see Creating software configuration templates on page 714. 7. Specify requirements for the software. v Define global requirements first in the Requirements section of the software. These requirements apply for any deployment of the software, regardless of which installation file is used or which software configuration template is used to perform configuration of the software during installation. a. Click Add Requirement. b. In the Requirement Type list, select the requirement type. c. If you only want to specify a requirement type, leave the Requirement field blank. If you want to add a requirement name, select a requirement name. d. If you selected a requirement name, select one or more values for it. You must specify at least one value. To add a value, type it in the Value field, and then click Add. e. If you are creating a hosting requirement, select the Hosting check box. Use this option when the software you are defining needs to run in the context of another software application. For example, a servlet requires a standalone servlet engine or an application server with servlet support to load the servlet. The servlet engine therefore acts as a container for running the software. If the servlet requires a specific container environment, such as WebSphere Application Server, you can specify a hosting requirement for it. f. If you want the provisioning server to reject a mismatched capability but accept a missing capability, select the Accept Non Existing Capability check box. g. Click Save. v If you added more than one file to the Installables list, expand the entry for each one in the Installable list and specify file-specific requirements. For example, if you have added different installation files for different hardware or different operating systems, specify the particular requirements for each file. v If you are using multiple software configuration templates to define different ways to configure the installation, specify requirements to check for each type of deployment. For example, if you are defining a J2EE application and want to deploy it to WebSphere Application Server and WebLogic Server, the software configuration templates that you create for each type of deployment can contain requirements for the type of J2EE server. 8. Capabilities identify attributes of the software that can be used for installation requirement validation. For example, if you are creating a software definition for WinZip 11, you can specify the vendor (Winzip Computing) and the version number (11). After you deploy WinZip 11, other software deployments that require WinZip 11 can verify whether a particular computer has the software installed. a. Click Add Capability b. Specify the capability details. 1) In the Capability Type field, select the appropriate capability type. 2) In the Name section, specify the appropriate values for each capability name. 3) Click Save. 9. Click Save . The changes you have made to the page are saved.
706
Results The software definition for the software product is created. What to do next To install the software, you must specify the provisioning workflows required for this software. For information about assigning provisioning workflows, see the provisioning workflows documentation. Manually defining patches: If you need to manually add a new patch, the first step is creating its software definition. The recommended way to add software patches to the software catalog is to use a supported software update system such as Microsoft Windows Server Update Services, because the provisioning server can automatically create software definitions for imported patches. Software definitions for patches include patch-specific information, such as the severity and issue date in software definitions for patches. Procedure 1. Click Go To > IT Infrastructure > Software Catalog > Patches. . 2. Click New 3. Type the name, description, vendor, and select the locale. 4. 5. 6. 7. In the Approval Status field, select the approval status of the patch. In the Severity field, select the importance of the patch. Type the version number. Select the appropriate check boxes: v Restart application indicates that customer application must be restarted.
v Can request restart indicates that the operating system must be restarted. v Patch can coexist indicates that patched servers can coexist in the same application tier as servers that have not been patched. 8. In the Software Installables section, specify the actual installation file for the software. Click New Installable to add a file. Note: Use a single installable file if you only have a single software package or software image that is associated with the software definition. You can associate multiple installable files with a software definition if you have different mechanisms for installation. For example, you can include an .msi package for computers that have the Microsoft Software Installer and a compressed file for computers that have software to extract the contents of the file. At installation time, the requirement attributes of the installation files will be compared against the information about the target computer to determine which installation file to use. a. Specify the name, version number, and description. b. In the Status list, select the appropriate status of the file. c. If you are adding the file from a file repository, click the file repository name in the File Repository list. d. In the Installable Path field, type the path where the software package is stored. The path is relative to the root directory of the file repository. For example, if the repository path is configured as /share, and the package is stored in /share/package1, then the package path is /package1. e. In the File field, type the name of the file.
707
f. If this file is specific to a locale, select the locale. g. Click Submit. An entry is added to the list of installation files. 9. Optional: In the Provisioning Groups section, you can add the software to a provisioning group to categorize and organize your software. Click Assign to Provisioning Group and select a provisioning group. 10. Requirements and capabilities for the software can be defined in several ways and will be explained in a later step. Create your software configuration templates with the specific installation parameters to use during installation of the software. For details see Creating software configuration templates on page 714. 11. Specify requirements for the software. v Define global requirements first in the Requirements section of the software. These requirements apply for any deployment of the software, regardless of which installation file is used or which software configuration template is used to perform configuration of the software during installation. a. Click Add Requirement. b. In the Requirement Type list, select the requirement type. c. If you only want to specify a requirement type, leave the Requirement field blank. If you want to add a requirement name, select a requirement name. d. If you selected a requirement name, select one or more values for it. You must specify at least one value. To add a value, type it in the Value field, and then click Add. e. If you are creating a hosting requirement, select the Hosting check box. Use this option when the software you are defining needs to run in the context of another software application. For example, a servlet requires a standalone servlet engine or an application server with servlet support to load the servlet. The servlet engine therefore acts as a container for running the software. If the servlet requires a specific container environment, such as WebSphere Application Server, you can specify a hosting requirement for it. f. If you want the provisioning server to reject a mismatched capability but accept a missing capability, select the Accept Non Existing Capability check box. g. Click Save. v If you added more than one file to the Installables list, expand the entry for each one in the Installable list and specify file-specific requirements. For example, if you have added different installation files for different hardware or different operating systems, specify the particular requirements for each file. v If you are using multiple software configuration templates to define different ways to configure the installation, specify requirements to check for each type of deployment. For example, if you are defining a J2EE application and want to deploy it to WebSphere Application Server and WebLogic Server, the software configuration templates that you create for each type of deployment can contain requirements for the type of J2EE server. 12. Capabilities identify attributes of the software that can be used for installation requirement validation. For example, if you are creating a software definition for a Example Patch version 5, you can specify the vendor (Example) and the version number (5). After you deploy Example Patch 5, other software deployments that require Example Patch 5 can verify whether a particular computer has the patch installed. a. Click Add Capability b. Specify the capability details. 1) In the Capability Type field, select the appropriate capability type. 2) In the Name section, specify the appropriate values for each capability name. 3) Click Save. 13. Click Save .
708
Results The software definition for the software patch is created. What to do next To install the software, you must specify the provisioning workflows required for this software patch. For information about assigning provisioning workflows, see the provisioning workflows documentation. Defining software stacks: A software stack is a special type of software definition that you can use to identify groups of software that you want to install at the same time and in a specific sequence on target systems. A software stack can include installable files and software definitions for software products, software patches, and other software stacks. Software stacks serve several purposes: v You can consistently install the same software in the correct order and with the same configuration on managed systems. v You can add software stacks to computer templates so that Tivoli Provisioning Manager can identify managed systems that are not compliant with the software stack. v You can install software stacks on individual systems or add them to computer templates for automatic installation on provisioned servers. Using software definitions You can deploy software stack using a list of software definitions or using an image. The list of software definitions in a software stack represent each piece of software that you want to install and the required installation order. You can nest one software stack inside another software stack by adding the child software stack to the list of software definitions in the parent software stack. To plan software stacks and ways to combine them, consider groups of software that you can install in different environments. You can create software stacks for these groups and then incorporate them into larger software stacks that are for specific deployments.
709
For example, if you are setting up Apache Web servers and you want each Web server to include both Apache and two administration tools, you can create the following software definitions:
Table 124. Software definitions for software stacks Software Definition Apache for Windows Monitoring tool File manager Administration Tools Stack Apache Server Stack Contents A software definition for the Apache for Windows software stack. A software definition for one of the administration tools A software definition for one of the administration tools A software stack that contains the software definitions for both administration tools A software definition that contains the following software definitions: v Apache for Windows v Administration Tools Stack
Using images If you have an image that contains the set of software that you want to deploy, you can add it to the list of installable files in a software stack. This option can be easier to deploy than using software definitions because it does not require the provisioning server to install each piece of software individually. However, this method can also be less flexible. Re-create the whole image if you need to update an item in the software stack, and you cannot easily nest software stacks. Installation methods The items that you include in a software stack determine how it is installed. Your software stack can include a special configuration item called an iterator. Its placement in the list of installable files determines which software stack installation method to use when a software stack contains both a list of installable files and an image. v 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. v If you add an iterator, its placement of in the installable file list determines when the provisioning server deploys the software stack by installing individual software definitions. For example, if the iterator is the first item in the list, the provisioning server uses the software definitions before considering the installable files. If the iterator is the last item in the list, the provisioning server only uses the software definitions to install the software stack if a managed system does not match the requirements of installable files in the software stack. The iterator is typically placed at the end of the installable file list, because deploying images is typically more efficient than installing individual pieces of software. The following examples show different deployment scenarios.
710
Install individual items using a list of software definitions

Software definitions
Product 1
Installable files
Iterator
Product 2
Product 3
In this configuration, the software stack contains a list of software definitions. Each software definition represents an item in the software stack. The provisioning server uses the software definitions to install each piece of software individually. To use this option, every software definition in the software stack must include at least one installable file. The software stack must also include a special entry in the list of installable files called an iterator. The iterator indicates that the provisioning server must use the software definitions to install the software stack. Install all items at the same time using a software image
Product 1
Installable files
Image 1
Product 2
Image 2
Product 3
A software stack can include one or more software images in its list of installable files. For example, you can create a standard Windows 2000 software stack that has three installable images that you use for three different types of servers. Based on the requirements of each image, the provisioning server determines the image to deploy to a particular target computer. If you use this option, it is not necessary to include software definitions in the software stack. However, you might want to include a list of software definitions so that you have a record of the items in the software stack. The installation of an image typically triggers provisioning workflows for deploying the image from a boot server. Use software images for software stacks that you deploy to new systems or systems that you want re-image because installing an image overwrites software that is installed on the target system.
711
Both options are available

Product 1
Installable files
Iterator
Product 2
Image 1
Product 3
Image 2
If you want to make both software stack installation methods available, include the following items in the software stack: v A list of software definitions for the software in the software stack. Each software definition must include at least one installable file. v An iterator. v One or more images that contain the same pieces of software that are represented by the list of software definitions. The placement of the iterator in the installable file list determines the priority of the installation methods. For example, if the iterator is the first item in the list, the provisioning server uses the list of software definitions to install the software instead of the images in the list. If the iterator is the last item in the list, the provisioning server uses list of software definitions to install the software stack if the target computer does not match the requirements of all images listed in the software stack. Because deploying images is typically more efficient than installing individual pieces of software, the iterator is typically placed at the end of the installable file list. Making changes to software stacks When you make changes to existing software stacks that are associated with a resource pool or tier, consider the impact of the changes and take the following actions: v Ensure that existing servers in the resource pool or tier can coexist with servers that are added to the group with the updated software stack, or update the existing servers to match the new software stack. v If this software stack is referenced by other software stacks, ensure that the changes you are making do not create compatibility or dependency problems in the parent software stack. Adding software stacks: Create software stacks so that you can easily and consistently install a standard set of software on managed systems. To add a software stack: Procedure 1. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. . 2. Click New 3. Specify the name, version, and description for the software stack. 4. If you are creating a software stack that performs an installation using list of other software definitions, perform the following steps:
712
a. Add the list of software to the Modules list. From the Select Action menu, click Add Stack Entry. Follow the instructions in the wizard. b. Add an iterator to the Installable Files list to indicate that you want to use the list to deploy software. Click Add Iterator. If you do not use an iterator, the list of software in the Modules list is stored for reference purposes only and is not used for deployment. 5. If you want to use an image to deploy the software stack, perform the following steps: a. b. c. d. e. f. Click Add Installable. Specify a name and description for the image. In the Status fields, select the testing status of the image file. In the Status fields, select the testing status of the image file. If the image is specific to a locale, select the locale. In the Image Type list, click the type of image you are adding.
g. In the Boot Server list, click the boot server to use for installing the image. h. Click Save. If you add more than one image, the provisioning server uses the requirements defined for each image to identify the appropriate image to deploy on a target computer. The order of the images indicates the priority of the image. The first image with requirements that the target computer can meet will be selected. 6. Optional: In the Provisioning Groups section, you can add the software to a provisioning group to categorize and organize your software. Click Assign to Provisioning Group and select a provisioning group. 7. In most situations, requirements for the software stack must be configured in the software definition of each entry in the Modules list or with each image in the Installable Files list. If you want to specify some requirements that apply to a list of multiple images in this software definition, you can define those requirements in the Requirements section. a. Click Add Requirement. b. In the Requirement Type list, select the requirement type. c. If you only want to specify a requirement type, leave the Requirement field blank. If you want to add a requirement name, select a requirement name. d. If you selected a requirement name, select one or more values for it. You must specify at least one value. To add a value, type it in the Value field, and then click Add. e. If you are creating a hosting requirement, select the Hosting check box. Use this option when the software you are defining needs to run in the context of another software application. For example, a servlet requires a standalone servlet engine or an application server with servlet support to load the servlet. The servlet engine therefore acts as a container for running the software. If the servlet requires a specific container environment, such as WebSphere Application Server, you can specify a hosting requirement for it. f. If you want the provisioning server to reject a mismatched capability but accept a missing capability, select the Accept Non Existing Capability check box. g. Click Save. 8. Specify capabilities if you are using an image to deploy the software stack and the capabilities apply to deployments with any software configuration template. For example, if all images contain the common agent, you can add this capability. If you are using entries in the Modules list, each entry must have specific capabilities defined already. a. Click Add Capability b. Specify the capability details. 1) In the Capability Type field, select the appropriate capability type. 2) In the Name section, specify the appropriate values for each capability name. 3) Click Save.
713
9. In the Configuration Templates section, software configuration templates are automatically added for items that are in the Modules list. If you are using an image to deploy the software stack, manually create the software configuration template for the image. For more information, see Creating software configuration templates. Results The software definition for the software stack is created. What to do next If you are deploying with an image, specify the provisioning workflows required to deploy the software. For information about assigning provisioning workflows, see the provisioning workflows documentation. Duplicating software stacks: If you need to create multiple software stacks with similar software and configuration information, you can duplicate an existing software stack, and then update the copied software stack. When you duplicate a software stack, references to embedded software stacks remain the same. Embedded software stacks are not duplicated. Software Resource Templates of the duplicated software stack have no references to Software Resource Templates of the original software stack. Procedure 1. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. 2. Select the software stack to duplicate. 3. From the Select Action menu, click Clone. 4. To display the software stack that you have cloned in the List tab: a. Click Go To > Administration > Provisioning > Provisioning Global Settings. b. c. d. e. Click the Variables tab. Click New Row to create a new variable. Create a new variable called display-cloned-stacks and set its value to true. Save the changes.
Results The new software stack is created with the name SWStack_name-ObjectID. For example, if duplicating MyStack, the new cloned software stack is named MyStack-13456 where MyStack is the software stack name and 13456 is the software stack object ID. To modify the new software stack, click its name in the software stack list, and then make the required changes. Creating software configuration templates: Software configuration templates are typically designed by workflow developers. If you are manually modeling software in the software catalog, you can manually add software configuration templates. Workflow developers typically include the required software definitions and software configuration templates in the automation packages they create for software. They are added to the data model when the automation package is installed. If you create a software configuration template manually, you can include parameters with fixed values or values that can be selected or changed at installation time.
714
Templates can be organized in a hierarchy when you want to define related resources. For example, you can define multiple templates for features within a parent template. There are several ways to create a software configuration template. v For some software, you can use a template definition to create the software configuration template. A template definition contains all the parameters required by the provisioning workflows that implement the installation and configuration of the software, and default values for the parameters. This option requires the least amount of customization or knowledge of the provisioning workflow implementation. v You can copy a software configuration template from an existing software definition and customize it as required. v If you are creating multiple software configuration templates in the same software definition with similar parameters, you can duplicate an existing software configuration template using the Clone command and then and then modify the copy as required. v If a template definition or existing software configuration template does not meet your needs, you can create an empty software configuration template and manually add all the parameters, requirements, capabilities, and child templates that you require. If there are multiple software configuration templates in a software definition, the first one in the list is the default. You cannot remove the default software configuration template. Software configuration templates and dependencies for software stacks: You can deploy software stack using a list of software definitions or using an image. When you add software definitions to a software stack, a copy of the software configuration templates for each software definition are used to build the software configuration template for the entire software stack. The following example shows the structure of a software configuration template for a software stack:
Apache (Software Definition)
Apache Test Template
Web Site Software Stack

Web Site Software Stack Template
Apache Production Template
Apache Test Template.3019
Web Module (Software Definition)

Web Module Template
Web Module Template.3022
The parent software configuration template type is Unspecified resource instantiation because a software resource is not created on the target system to represent the entire software stack. Under the
715
parent software configuration template, a copy of the software configuration template from each software definition in the software stack appears as a child template. The number at the end of the template name is the identifier for the copy of the template. Changes to the original templates do not affect the templates in the software stack because the child templates are copies. In addition, changes to the template copies in the software stack do not affect the original templates. This separation provides you with the ability to change the parameter values for installation of the software stack without affecting the original software configuration templates. Dependencies Requirements in software stack apply to any images that are included in the installable file list of the software stack. If you are using software definitions to install the software stack, the provisioning server uses requirements defined in the individual software definitions and in the software configuration template contained in the software stack to perform validation of a target computer. The provisioning server takes into consideration that the requirements of one software definition might be met by the capabilities of another software definition that is also in the software stack. Creating software configuration templates from template definitions: A template definition is a predefined software configuration template that you can use as the basis for your own software configuration template. If a template definition exists for the software configuration template that you want to create, the template definition can help you to quickly create software configuration template with the appropriate parameters and default values for deploying the software. You can create more than one software configuration template from a template definition. For example, if you want to include software configuration templates for deploying a piece of software on different operating systems, you can use the appropriate template definitions to add the required software configuration templates. Procedure 1. Open the page for the software that you are configuring. 2. In the Software Configuration Template section, click New Configuration Template. 3. Specify the following information: a. In the Name field, type the name of the software configuration template. b. In the Creation Method section, select Create from a template definition. c. In the Configuration Template Definition list, select the template definition that matches the type of software configuration template that you want to create. d. Click Save. Results The software configuration template is created. What to do next Review the parameters and default values in the new software configuration template and make changes as required. You can also add requirements and capabilities beyond those that are already configured. Copying a software configuration template from a software definition:
716
If you want to create a software configuration template with settings that are similar to a software definition in another software definition, you can copy the software configuration template and then make changes to the copy. Procedure 1. Open the page for the software that you are configuring. 2. In the Software Configuration Template section, click New Configuration Template. 3. Specify the following information: a. In the Name field, type the name of the software configuration template. b. In the Creation Method section, select Copy from a software definition. c. Select a Software Module that contains the software configuration template that you want to copy. d. In the Configuration Template list, select the software configuration template that you want to copy. e. Click Save. Results The software configuration template is copied from the specified software definition to the current software definition. What to do next Review the parameters and default values in the copied software configuration template and make changes as required. You can add or remove requirements and capabilities as required.
Rollback
Rollback is the capability to bring the system back to its prior state. It applies only to software products based on software package blocks. When you perform a rollback operation, the system returns to its previous state, before the installation or upgrade of a software product based on a software package block (SPB file). This operation is applicable only to software products which you installed enabling the rollback functions. As an example, the following scenario is provided: 1. You install on your system application version 1. 2. You upgrade the application to version 2. This installation is performed with the rollback option enabled. 3. You uninstall the application version 2 from your system, without the Force uninstall option selected. 4. Result: You have removed the application version 2 from your system and brought back the application to version 1. In the following cases, rolling back the installed software application to its previous state is a more convenient operation to perform, instead of completely uninstalling that software application: v When installing software applications that replace some system files. v When upgrading software applications. The rollback function is not usable on software package blocks built using the native installation wizards. If the installation of native packages, such as MSI or InstallShield packages, fails, use the rollback capability provided with the native installation tool. In case of native installers such as MSI, the rollback function is allowed but behaves like a remove operation.
717
Enabling the rollback feature

You can enable the rollback feature for software products based on software package blocks (SPB files) when defining an install activity inside a plan using the Activity Plan Editor. To enable the rollback feature when creating an activity inside a plan:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. 2. 3. 4. 5. 6. . Click New Type a name for the task. Click Activity Plan for the type. Click Edit > Create Activity > Software Management. Enter a name and a description for the activity.
7. Select Install from the Operation section and click Properties. 8. In the Rollback section, click Enabled. By default this setting has the same value as the value set for the Rollback_Enabled global variable.
Enabling or disabling rollback for all software package blocks

You can enable or disable the rollback feature globally by setting a variable using the Web interface. To enable or disable the rollback feature globally:
Procedure
1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Variables tab. 3. Find the Rollback_Enabled variable and click the icon beside it. 4. Set the appropriate value for the variable: v To enable the feature, set the value of the variable to TRUE. v To disable the feature, set the value of the variable to FALSE. 5. Click Save .
Disabling the rollback feature

You can disable the rollback feature for software products based on software package blocks (SPB files) when defining an install activity inside a plan using the Activity Plan Editor. To disable the rollback feature when creating an activity inside a plan:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. 2. Click New . 3. Type a name for the task. 4. Click Activity Plan for type. 5. Click Edit > Create Activity > Software Management. 6. Enter a name and a description for the activity. 7. Select Install from the Operation section and click Properties. 8. In the Rollback section, click Disabled.
Removing backup software package blocks

You can remove the backup software package block created using the rollback feature.
718
When you install a software package block with the rollback feature enabled, a backup software package block is created to be used to perform a rollback operation. You can remove this backup software package block on the target computer if needed. Run the following command from the target computer on which you want to remove the backup software package block:
$install_dir\runtime\agent\agentcli spbhandler accept -n "Software Installable name.Software Installable version"
where: $install_dir Is the directory where the Tivoli Common Agent (TCA) is installed on the target computer. Software Installable name Is the name of the software package block which was installed with the rollback feature enabled, and for which a backup software package block exists. Software Installable version Is the version of the software package block which was installed with the rollback feature enabled, and for which a backup software package block exists. You can also run the SPB_Synch_Accept workflow from the Web interface by performing the following steps: 1. Click Go To > Administration > Provisioning > Provisioning Workflows. 2. Find the workflow named SPB_Synch_Accept. 3. Click the Run icon for the workflow.
Viewing software resources

You can view the software resources installed on a specific computer.
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Search for the computer that you want to view and then click its name in the search results. 3. Click the Software tab.
Results
The Software page displays the software that is installed on the computer based on information in the data model.
Adding a top level software resource for a software installation

A software resource for a software installation is typically created when the software is installed. If you want to model a software resource that is installed but not yet modeled in the data model, you can manually add a software installation.
Before you begin

To fully model the software installation, a software definition and installable file that you want to associate with the software installation must exist in the software catalog. For example, if you are modeling a DB2 software installation, an DB2 appropriate software definition that matches the installed product must exist in the software catalog, and the software definition must contain an installable file that matches the product version and edition that was used to install the software.
719
Procedure
1. 2. 3. 4. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. Search for the computer that you want to view and then click its name in the search results. Click the Software tab. Click Add Software.
5. In the Software Installation field, specify the name of the software installation. 6. In the Locale field, specify the locale of the software. 7. In the Software Definition field, select the software definition that represents the software installation. 8. In the Configuration Template list, select the software configuration template that most closely matches the configuration of the software. 9. In the Software Installable list, select the software installable that matches the product edition and version that was used to install the software. . 10. Click Save 11. If you want to edit details of a software resource, click its name in the Software Installations list.
Results
The software installation is added.
Adding child software resources

Software resources are typically created when software is installed. If you are manually modeling software that is installed, but not yet modeled in the data model, you can manually add the software resources. The top level software resource is a software installation. Software installations can have child software resources, such as software instances.
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Search for the computer that you want to view and then click its name in the search results. 3. Click the Software tab. 4. From the Software Installations list, identify and click the software installation to which you want to add a child software resource. The Details tab of the Software Resources application is displayed. 5. Click Add Child Resource. 6. Click the appropriate option: Add Software Instance Select this option for an instance of the parent software resource. For example, you can add an instance to a , DB2 or WebSphere Application Server software installation. Add Software Configuration Select this option to model configuration data for the parent software resource. Add Software Resource Select this option for software resources that do not fall into any of the other categories. Add Software Installation Select this option for a software installation. Add Software Application Data Select this option to model application data for the parent software resource. 7. Specify the following information:
720
a. In the Name field, specify the name of the child software resource. b. In the Locale field, specify the locale of the child software resource. c. In the Configuration Template field, select the software configuration template that represents the child software resource. d. If you are adding a software installation, select the software installable that matches the product edition and version that was used to install the software in the Software Installable list. e. Click OK .
Results
The child software resource is added. From the Software Resources application, you can also view the configuration templates of the software resource, change the device models for the software resource, or start and stop the software instances.
What to do next
If you are removing a WebSphere Application Server instance later, verify the following: v The first instance in the default profile is running. By default, the instance is called server1. v The instance that you want to remove is running. You cannot remove the instance if it is stopped. Note: The instance in the default profile cannot be removed. An instance running the node agent cannot be removed.
Updating the data model with changes to software resources

If you make changes to a piece of software outside of Tivoli Provisioning Manager, you can update the data model with changes that were made.
Before you begin

Prerequisites: v A configured software definition must be in the data model for the piece of software. v A software resource for the software installation must be in the data model. It is automatically created if you install the software using Tivoli Provisioning Manager or discover the software. v A workflow for the SoftwareResource.UpdateDCMlogical management operation must be defined in the software definition for the software. The automation packages for applications such as WebSphere Application Server include specific workflows to perform this operation. The scope of the update depends on the software resource that you select. You can update an entire software installation, or specific software resources. For example, if you want to update a WebSphere Application Server software resource: v Selecting the WebSphere Application Server software installation runs discovery against the entire WebSphere Application Server environment to identify and apply updates. v Selecting a WebSphere Application Server profile runs discovery against the profile and software instances in the profile. v Selecting a specific software instance within a profile updates that software instance only.
Procedure
1. 2. 3. 4. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. Search for the computer that you want to view and then click its name in the search results. Click the Software tab. Find the software resource that you want to update.
721
5. Click Update Data Center Model.
Results
The workflow for updating the data model runs.
Upgrading software resources

You can upgrade a software resource if a provisioning workflow associated with the SoftwareResource.Upgrade logical management operation is assigned to the software. For example, the WebSphere Application Server Version 6 automation package includes a provisioning workflow for updating WebSphere Application Server Version 6 with fix packs.
Procedure
1. Click Go To > Deployment > Software Management > Software Product Upgrade. 2. In the Software section, select the software that you want to upgrade. 3. In the Targets section, select the target computers for the upgrade. 4. In the Upgrade Method section, specify how you want to upgrade the software: The available options and appropriate option to choose depend on the software product that you selected and the provisioning workflow that is associated with the software product. Upgrade existing configuration Upgrade the configuration of the existing software resource only. Upgrade to a new version Upgrade the software resource by installing a new version of the software on the computer. 5. Specify any additional options for the upgrade task. 6. Click Submit.
Results
The provisioning workflow for upgrading the software runs and performs the selected upgrade action either immediately or at the specified scheduled date and time.
Cluster domains overview

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. The cluster domain integration ensures that your applications and services are available whenever customers need them. Cluster domain nodes can be configured for either availability or scalability. High availability High availability is the ability to provide access to applications for as high a percentage of scheduled time as possible, by reducing unexpected outages and minimizing the impact of planned downtime on certain systems. The system is continuously available and has a self-healing infrastructure that prevents downtime caused by various system problems. High availability provides quick and consistent recovery of failed resources and whole applications. Scalability Scalability is the ability of the system to adapt to varying demands, by increasing or decreasing computing capacity. 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
722
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. Whenever necessary, for example, in a failover scenario, the peer domain cluster redistributes the workload from the failed master node to a standby node, therefore increasing the availability. Although high availability is the main reason for setting up the peer cluster domain, scalability can also be increased, by making it possible to easily adjust the number of nodes in the cluster domain, based on demand. 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 are not aware 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. Based on the cluster domain model, sets of logical management operations are provided that can be used to perform cluster domain configuration tasks such as provisioning or deprovisioning cluster domain nodes, or to perform management tasks such as starting or stopping cluster domains. Specific workflows implementing these logical management operations have been developed and are also provided. For more information about all the available logical management operations associated with cluster domain configuration and management, see the Tivoli Provisioning Manager information center.
Creating cluster domains

To be able to model and manage the application tiers in your data center, you need to build and configure a cluster domain. The type of cluster domain that you need depends on the type of the data center that you want to manage and possibly on other data center-specific requirements. The following scenarios describe two different ways you can build a cluster domain using the provisioning server. Importing the configuration of an existing cluster domain If a cluster domain is already running in the data center, you can populate the data model with the cluster domain configuration, by performing the following tasks: 1. Manually create an XML file that describes the configuration of the existing cluster domain in the data center. For more information, see the topic Software configuration template for cluster domain configuration on page 724. 2. Import the XML file into the data model using the XMLImport utility. Building a new cluster domain If no cluster domain configuration is defined in the data center, you need to create a data model for the new cluster domain that you want to build, and then distribute it to the data center. Two different ways to build a new cluster domain are described: v Manually building a new cluster domain using the web interface. v Building a new cluster domain using a predefined software configuration template. Building cluster domains using software configuration templates:
723
Software configuration templates are provided to define all of the cluster resources, resource groups, and resource relationships available within cluster domains. For an example of software configuration templates, see the topic Software configuration template for cluster domain configuration. Based on the type of clustering technology that is used, you can use a predefined software configuration template as an example for building and configuring a new cluster domain. An example of software configuration templates can be found in the venice.xml file. Venice.xml is located in the $TIO_HOME/xml directory, where $TIO_HOME is the home directory of the provisioning server. This template is defined in XML format, and is associated with a software module. You can customize the XML definition of the software configuration template according to your needs, and then you can use the XMLImport utility to import the template into the data model. A specific logical management operation is also provided for configuring new cluster domains. When the ClusterDomain.Config logical management operation is run, the software configuration template associated with the specified cluster domain is identified, and is used to retrieve all predefined resource and resource group settings. After the resource and resource group settings are retrieved, you can import them into both the data model and the data center. For more information about logical management operations associated with cluster domain and resource configuration, see the topic Logical management operations for cluster domains and resources on page 733. To build a cluster domain using a software configuration template: Procedure 1. Create an XML software configuration template for the cluster domain that you want to build. You can use an existing example. See Software configuration template for cluster domain configuration. 2. Import the XML software configuration template into the data model using the XMLImport utility. 3. Using the web interface, you can either add cluster domain nodes to the cluster domain manually, or you can directly use the ClusterDomain.Config logical management operation, to automatically add nodes to the cluster domain. Software configuration template for cluster domain configuration: An existing software configuration template can be used as an example to build and configure a cluster domain. The software configuration template defines all the resources, resource groups, and resource relationships within a cluster domain. The following is an example of a software configuration template used for cluster domain configuration:
<datacenter>  <software-module name="DB2 H/A Software for Linux" is-device-model="Simulator" version="1.0"> <installable-package name="H/A Cluster Product" version="1.0" service="true" install-path="C:\" file-repository="test file repository" status="tested"> <file name="H/A Cluster Product File" path="/usr/local"/> </installable-package> <software-resource-template name="ClusterResources"> <software-resource-template name="cr1"> <software-resource-template name="cr1-cra">  <template-param name="StartCommand" value="mount_start.ksh" /> <template-param name="StopCommand" value="mount_stop.ksh" /> <template-param name="MonitorCommand" value="mount_monitor.ksh" /> <template-param name="MonitorCommandPeriod" value="6" /> <template-param name="MonitorCommandTimeout" value="4" /> <template-param name="StartCommandTimeout" value="120" /> <template-param name="StopCommandTimeout" value="300" />
724
<template-param name="UserName" value="root" /> <template-param name="ProtectionMode" value="1" /> </software-resource-template> <template-param name="name" value="nfsserver-server" /> <template-param name="resource-type" value="IBM.Application" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> <software-resource-template name="cr2"> <template-param name="name" value="nfsserver-ip" /> <template-param name="resource-type" value="IBM.Service" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> <software-resource-template name="cr3"> <template-param name="name" value="nfsserver-data-vars" /> <template-param name="resource-type" value="IBM.Application" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> <software-resource-template name="cr4"> <software-resource-template name="cr4-cra">  <template-param name="StartCommand" value="db2_start.ksh" /> <template-param name="StopCommand" value="db2_stop.ksh" /> <template-param name="MonitorCommand" value="db2_monitor.ksh" /> <template-param name="MonitorCommandPeriod" value="20" /> <template-param name="MonitorCommandTimeout" value="10" /> <template-param name="StartCommandTimeout" value="60" /> <template-param name="StopCommandTimeout" value="60" /> <template-param name="UserName" value="root" /> </software-resource-template> <template-param name="name" value="db2-dbinst1-rs" /> <template-param name="resource-type" value="IBM.Application" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> <software-resource-template name="cr5"> <template-param name="name" value="db2-dbinst1-rs_mount" /> <template-param name="resource-type" value="IBM.Service" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> <software-resource-template name="cr6">  <software-resource-template name="cr6-cra">  <template-param name="ProtectionMode" value="1" /> <template-param name="IPAddress" value="9.21.31.4" /> <template-param name="MNetMask" value="255.255.255.0" /> </software-resource-template> <template-param name="name" value="db2-dbinst1-rs_ip" /> <template-param name="resource-type" value="IBM.ServiceIP" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> </software-resource-template> <software-resource-template name="ClusterResourceGroups" software-resource-template-source="ClusterResources"> <software-resource-template name="crg1"> <software-resource-template name="crg1-groupMember"> <template-param name="member1" value="nfsserver-server" /> <template-param name="member2" value="nfsserver-ip" /> <template-param name="member3" value="nfsserver-data-vars" /> </software-resource-template> <template-param name="name" value="SA-nfsserver-rg" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template>
725
<software-resource-template name="crg2"> <software-resource-template name="crg2-groupMember"> <template-param name="member1" value="db2-dbinst1-rs" /> <template-param name="member2" value="db2-dbinst1-rs_mount" /> <template-param name="member3" value="db2-dbinst1-rs_ip" /> </software-resource-template> <template-param name="name" value="db2-rg" /> <template-param name="is-device-model" value="Cluster Domain Simulator" /> </software-resource-template> </software-resource-template> <software-resource-template name="ClusterResourceRelationships" software-resource-template-source="ClusterResources"> <software-resource-template name="crr1"> <template-param name="name" value="rel1" /> <template-param name="sourceResource" value="db2-dbinst1-rs" /> <template-param name="targetResource" value="db2-dbinst1-rs_mount" /> <template-param name="dependency" value="Dependson" /> </software-resource-template> <software-resource-template name="crr2"> <template-param name="name" value="rel2" /> <template-param name="sourceResource" value="db2-dbinst1-rs" /> <template-param name="targetResource" value="db2-dbinst1-rs_ip" /> <template-param name="dependency" value="Dependson" /> </software-resource-template> </software-resource-template> </software-module>  <cluster-domain name="tsaHA2" display-name="TSA DB2 H/A 2-Node Cluster" cluster-type="Peer-Domain" is-device-model="Cluster Domain Simulator" virtual-ipaddress="VIP for StateBank Web/App" software-module="DB2 H/A Software for Linux" observed-state="Online" desired-state="Online"> </cluster-domain> </datacenter>
Configuring cluster domains

After building a cluster domain, you need to perform a number of additional configuration steps. Sets of logical management operations are provided, to be used to perform cluster domain configuration and management tasks. A set of specific provisioning workflows that implement these logical management operations is provided. To automate some of these tasks, you must ensure that the required provisioning workflows implement the appropriate logical management operations and are assigned to the appropriate cluster domains. For cluster domains, you should assign provisioning workflows for configuring automatically, starting, stopping, and removing cluster domains. The configuration tasks for cluster domains include: v v v v v v v Adding or removing cluster domains on page 727 Associating device drivers with cluster domains on page 727 Automatically configuring cluster domains on page 727 Editing the cluster domain properties on page 727 Adding or removing subclusters on page 727 Configuring cluster domain nodes on page 728 Configuring cluster domain resources on page 730
726
Adding or removing cluster domains: Adding new cluster domains To be able to model and manage the application tiers in your data center, you need to create a cluster domain. The type of cluster domain that you need depends on the type of the data center that you want to manage and possibly on other data center-specific requirements. After the new cluster domain has been successfully added, its name is added to the cluster domain list. Removing cluster domains If a cluster domain is no longer required by an application, you can remove it. If the cluster domain that you want to remove contains one or more subclusters, you must ensure that all of its subclusters are removed before you can remove the cluster domain itself. Before proceeding with this task, you must ensure that the provisioning workflow that implements the ClusterDomain.remove logical management operation, is assigned to the cluster domain that you want to remove. Associating device drivers with cluster domains: To be able to perform a number of configuration tasks on a cluster domain, you must ensure that the appropriate device driver is assigned to that cluster domain. By associating a device driver with a cluster domain, you assign a number of provisioning workflows that implement a number of cluster domain-specific logical management operations to that cluster domain. After the specified device driver has successfully been assigned to the cluster domain, all provisioning workflows and logical management operations associated with the device driver are available to be used with that cluster domain. Automatically configuring cluster domains: Prerequisite: This procedure assumes that you have already associated the cluster domain to be configured with the appropriate device driver. By associating a device driver with the cluster domain, you assign a number of provisioning workflows implementing cluster domain-specific logical management operations to that cluster domain. To become fully operational, a newly added cluster domain must be properly configured and provisioned with cluster domain nodes. To automate the cluster domain configuration and node provisioning, Tivoli Provisioning Manager provides the ClusterDomain.config logical management operation and a set of specific provisioning workflows that implement it. A larger data center might require more than one management node to administer all redundancy nodes in a management server cluster domain. Therefore, you might need to provision more management nodes to this cluster domain, by running the provisioning workflow that implements the ClusterDomain.config logical management operation more than once. After the cluster domain has been successfully configured and the specified nodes provisioned, the cluster domain remains in an unknown state until you start it. If the automatically configured cluster domain requires more nodes, you can manually provision it with additional nodes. Editing the cluster domain properties: You can make changes to the main details for a cluster domain, such as the cluster domain name, description, target status, and software definition. Adding or removing subclusters: Adding new subclusters To be able to provide additional functionality to an existing cluster domain, you might need to create a hierarchical cluster domain structure. For example, you might want to expand the functionality of an existing management server cluster domain so that it can function as a peer cluster domain as well. This additional functionality can be provided by creating a hierarchical or nested cluster domain structure.
727
Cluster domains nested inside other cluster domains are called subclusters. Subclusters, in turn, contain cluster domain nodes. Each cluster domain node can be a member of only one subcluster. A subcluster can have only one parent cluster domain. Removing subclusters If the hierarchical structure of a cluster domain is no longer required, it can be deleted by removing all nested subclusters. Removing subclusters from the cluster domain removes the additional functionality that was achieved by creating the nested cluster domain structure. If you want to remove the entire cluster domain, you must ensure that you remove all of its subclusters first. Cluster domain status: Using the provisioning server, two cluster domain or cluster domain node states can be consistently monitored in parallel: Current status This is the actual status of the cluster domain or cluster domain node. The current status of the physical cluster domain and its status in the data model must be synchronized. Tivoli Provisioning Manager provides a dedicated logical management operation, ClusterDomain.Config, that can be used to keep the data model and the physical cluster domain synchronized. Whenever a change in the configuration of a cluster domain or cluster domain node takes place, you can run the ClusterDomain.Config logical management operation directly to update the cluster domain's configuration in the data model. Target status The target status is the cluster domain or node status as it appears in the configuration of the high-availability application. In most cases, the current status and the target status are synchronized, because the cluster domain has the capability to manage its own status. However, you might encounter situations when the current and target states are different. For example: v A node in the cluster domain has failed. In this case, the target state says that the node must be Online, while the actual current status of the node is Failed. v A standby node in a peer cluster domain is Offline as long as the master node is Online and functioning as expected in the high-availability application. If the master node fails, the standby node comes Online. In this case, the target status of the standby node says it is Offline, while its actual current state is Online. A cluster domain node can be in one of the following states:
Table 125. Cluster domain nodes status types Status Online Offline Failed Unknown Description The node is fully operational and actively provides high-availability services in the cluster domain. The node is a passive part of the cluster domain. It is functional but does not run any high-availability services. The node cannot be controlled programmatically. In this case, a human operator has to resolve the failure and restore the node back to service. The node status cannot be determined or might not be required in the current implementation.
Configuring cluster domain nodes: A cluster domain node is an element in a cluster domain. It can be either a physical element such as a server, or a virtual element such as a software module instance. You can have two or more servers in a peer domain cluster, functioning as master and standby nodes. Similarly, you can have two or more software module instances running in a management server domain cluster as redundancy nodes.
728
The maximum number of cluster domain nodes that are allowed to run in a cluster domain depends on the clustering technology that is used, but there are no preset limitations. The maximum number can vary significantly from one clustering technology to another, and can range anywhere from two to a few dozens cluster domain nodes. After provisioning a new cluster domain node, additional configuration tasks must be performed before you can start it. You can configure only an offline node. Configuration tasks include editing the cluster domain node properties, adding resources to the cluster domain node, grouping resources, and so on. Sets of logical management operations are provided, which can be used to perform cluster domain node configuration tasks. A set of provisioning workflows that implement these logical management operations is provided. To automate these provisioning tasks, you must ensure that the provisioning workflows implement the appropriate logical management operations, and are assigned to the appropriate cluster domain nodes. For cluster domain nodes, you must assign provisioning workflows for adding and removing cluster domain nodes, creating resource groups, and starting and stopping cluster domain nodes. The following provisioning tasks can be performed with cluster domain nodes: v v v v Manually provisioning additional nodes Deprovisioning nodes Editing cluster domain node properties on page 730 Starting and stopping nodes on page 730
Manually provisioning additional nodes: Prerequisite: This procedure can be used whenever you want to add additional cluster domain nodes to an already configured cluster domain. It assumes that you have already configured the cluster domain and provisioned it with at least two nodes automatically. A cluster domain node can be either a physical element such as a server, or a virtual element such as a software module instance. v In a peer domain cluster, you can have 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. Manually provisioning a cluster domain node to a peer domain cluster means adding a standby server to the cluster. In a failover scenario, for example, the peer domain cluster requires Tivoli Provisioning Manager to provision a new standby node that runs the same clustering software as the master node in order to replace the failed node. v In a management server domain cluster, you can have two or more software module instances running as redundant nodes. Manually provisioning a cluster domain node to a management server domain cluster means adding a redundant node to the cluster domain. You might need to do this for load balancing purposes, for example. Before proceeding with this provisioning task, ensure that the required provisioning workflow, that implements the ClusterDomain.addNode logical management operation, is assigned to the cluster domain that you want to work with. After the cluster domain node is successfully added to the cluster domain, the node remains in an unknown state until you start it. Deprovisioning nodes: If the cluster domain no longer requires as many cluster domain nodes, you can remove or deprovision one or more nodes. Ensure that all resources are stopped within the node and that the node's current status is offline before removing it. Before proceeding with this provisioning task, ensure that the provisioning workflow that implements the ClusterDomain.removeNode logical management operation, is assigned to the cluster domain that you want to work with.
729
Editing cluster domain node properties: You can modify the description of a cluster domain node by editing the cluster domain node properties. Starting and stopping nodes: Starting nodes After adding a cluster domain node to a cluster domain, you need to start it for the node to be operational in the cluster domain. Before proceeding with this provisioning task, ensure that the provisioning workflow that implements the ClusterDomain.StopNode logical management operation, is assigned to the cluster domain that you want to work with. Stopping nodes A cluster domain node must be stopped before you can remove it. While the node is stopped, its current state is offline. Before proceeding with this provisioning task, ensure that the provisioning workflow that implements the ClusterDomain.StopNode logical management operation, is assigned to the cluster domain that you want to work with. Configuring cluster domain resources: Depending on its type, a cluster domain can run different types of resources: v Software resources, such as the database server program v Network resources, such as the virtual IP address v Disk resources, such as the volume group or share mount, and so on. For most of the tasks that can be performed with cluster resources, provisioning workflows that implement specific logical management operations are initiated. The main tasks that can be performed with cluster domain resources include: v Associating device drivers with cluster resources v v v v Starting and stopping cluster resources Creating cluster resource groups on page 731 Managing resources within groups on page 731 Managing resource relationships on page 731
Associating device drivers with cluster resources: To be able to perform a number of tasks on a cluster resource, you must ensure that the appropriate device driver is associated with that resource. By associating a device driver with a resource, you assign a number of provisioning workflows that implement resource-specific logical management operations to that resource. After a device driver is successfully associated with the cluster resource, all provisioning workflows and logical management operations associated with the device driver are available to be used with that resource. Starting and stopping cluster resources: Starting cluster resources After a cluster resource is added to a cluster domain node, you need to start the resource to make it operational in the cluster domain node. To proceed with this task, you must ensure that the provisioning workflow that implements the ClusterResource.Start logical management operation is assigned to the cluster domain that you want to work with.
730
Stopping cluster resources Before removing a cluster domain node, first you must ensure that all of its resources are stopped. To proceed with this task, you must ensure that the provisioning workflow that implements the ClusterResource.Stop logical management operation is assigned to the cluster domain that you want to work with. Creating cluster resource groups: You can also create cluster resource groups within a cluster domain node. Managing resources within groups: You can add cluster resources to resource groups or remove cluster resources from resource groups by initiating provisioning workflows that implement resource-specific logical management operations. Adding cluster resources to groups: To proceed with this task, you must ensure that the provisioning workflow that implements the ClusterResource.AddGroupMember logical management operation is assigned to the cluster resource that you want to work with. Removing cluster resources from groups: To proceed with this task, you must ensure that the provisioning workflow that implements the ClusterResource.RemoveResource logical management operation is assigned to the cluster resource that you want to work with. Managing resource relationships: You can define one or more relationships between two cluster resources. For example, a relationship can specify the precedence order for starting the resources in a group. When the group is started, the relationship indicates the order in which the clustering software must start the resources in that group. The format of the resource relationship depends on the type of clustering technology that you are using. For example, for starting resources, some clustering technologies might use StartAfter, while others might use DependsOn. Creating resource relationships: To automate the process of creating relationships between cluster resources, the ClusterResource.CreateDependency logical management operation is provided, as well as a number of provisioning workflows that implement it. Before proceeding with this task, ensure that the provisioning workflow that implements the ClusterResource.CreateDependency logical management operation is assigned to the cluster resource that you want to work with. Removing resource relationships: When a relationship between two cluster resources is no longer needed, you can remove it.
Cluster domain management

The administrative tasks that can be performed on configured cluster domains include: v Viewing cluster domains on page 732 v Viewing node details in a cluster domain on page 732 v Viewing resource groups in a cluster domain on page 732 v Viewing resource groups and details on page 732 v Starting and stopping cluster domains on page 732
731
v Updating cluster domain states in the data model Viewing cluster domains: You can display a list of all cluster domains that are available in the system. For each of the cluster domains in the list, details such as the cluster domain's name, description, type, and its current and target states are displayed. Viewing node details in a cluster domain: For a selected cluster domain, you can display a list of all cluster domain nodes that are operational in the cluster domain. A number of additional details can also be displayed: v The cluster domain nodes' current and target states. v The system type, whether the node in the cluster domain is a dedicated, assigned, or overflow server. v Whether the cluster domain nodes are management nodes. v The subclusters and their states if the selected cluster domain is nested. Viewing resource groups in a cluster domain: For a selected cluster domain, you can also display a list of all resource groups that are defined in the cluster domain. Also displayed are the current and target states for each of the resource groups in the list. Viewing resource groups and details: For a selected resource group, you can display a list of all resources that are defined in it. For each resource in the list, you can also view the name of the cluster domain node that the resource is defined in. If the current resource group is nested, you can also display a list of all resource subgroups that are defined in it. Additional details such as the resource's name, description, type, its current and target states, its relationships with other resources, and the name of the parent group can also be displayed Starting and stopping cluster domains: Starting cluster domains Configuration tasks can be performed on a cluster domain only when it is offline. After you configured the cluster domain as required, you need to start it, so that it becomes operational within the high-availability application and managed by the system. The status of a started cluster domain is online. For more information about cluster domain states, see the topic Cluster domain status on page 728. Before proceeding with this task, you must ensure that the provisioning workflow that implements the ClusterDomain.Start logical management operation is assigned to the cluster domain that you want to work with. Stopping cluster domains Configuration tasks can be performed on a cluster domain only when it is offline. Before proceeding with this task, you must ensure that the provisioning workflow that implements the ClusterDomain.Stop logical management operation is assigned to the cluster domain that you want to work with. Updating cluster domain states in the data model: Whenever a change is made in the cluster domain configuration, you can automatically update the data model to reflect this change, by running the ClusterDomain.UpdateState logical management operation. Before proceeding with this task, you must ensure that the required provisioning workflow, that implements the ClusterDomain.UpdateState logical management operation is assigned to the cluster domain that you want to work with. If the workflow is run successfully, the data model is automatically updated with the latest changes in the cluster domain configuration.
732
Logical management operations for cluster domains and resources

Based on the cluster domain model, sets of logical management operations that can be used to automate a number of cluster domain configuration and management tasks. You must ensure that provisioning workflows that implement these logical management operations are assigned to the appropriate cluster domains. For cluster domains, for example, assign provisioning workflows for provisioning and deprovisioning cluster domain nodes, starting, stopping, and removing nodes, and starting, stopping, and removing cluster domains. Two categories of logical management operations associated with cluster domain and cluster resource management and configuration tasks are provided: v Logical management operations for cluster domains v Logical management operations for cluster resources
Logical management operations for cluster domains

The following logical management operations are provided for cluster domain configuration and management tasks: v ClusterDomain.AddNode v ClusterDomain.Config v ClusterDomain.CreateResource v ClusterDomain.CreateResourceGroup v ClusterDomain.Remove v ClusterDomain.RemoveNode v ClusterDomain.Start v v v v v ClusterDomain.StartNode ClusterDomain.Stop ClusterDomain.StopNode ClusterDomain.UpdateDomainStatus ClusterDomain.UpdateNodeStatus
Logical management operations for cluster resources

The following logical management operations are provided for cluster resource configuration and management tasks: v ClusterResource.AddGroupMember v ClusterResource.CreateDependency v ClusterResource.RemoveResource v ClusterResource.RemoveResourceGroup v ClusterResource.Start v ClusterResource.Stop v ClusterResource.Update
Administrative domains
An administrative domain is a set of one or more nodes whose administrative servers share an administrative database. Administrative domains help you to centralize administration of a distributed server environment that consists of multiple servers. The administrative domain provides a single point for administration for all servers that belong to it.
733
You can model your administrative domains in the data model and create clusters to share workload for common server processes. An administrative domains defines the physical topology of servers and how the servers and their software resources are grouped for administration. A cluster defines the functional organization of software resources in an administrative domain, and how application servers are grouped to share workload for business functionality. When you create a WebSphere Application Server cluster, you can use it as a target for components of a composite application. An administrative domain consists of the following main parts: Subdomains A subdomain is a server within an administrative domain and the software installations on the server. Resource member A software installation on the server associated with a subdomain. Cluster You can create a cluster to manage workload for common components that are installed on multiple subdomains. Tivoli Provisioning Manager provides an automation package that enables you to create WebSphere Application Server clusters based on an administrative domain. WebSphere Application Server and administrative domains: In the data model, administrative domains are represented by servers that are managed in the administrative domain and the software installed on the servers. WebSphere Application Server uses its own terms to describe the parts of an administrative domain. WebSphere Application Server concepts The following two diagrams shows an administrative domain and how WebSphere Application Server terms map to both administrative domain concepts and software model concepts. It is only one possible topology that you can configure.
734
Cell (Administrative Domain)
Deployment Manager
Application Server Node (Subdomain)

Node Agent
Application Server Node (Subdomain)

Node Agent
Cluster Cluster Member (Cluster Member) Cluster Member (Cluster Member) Cluster Member (Cluster Member) Cluster Member (Cluster Member)
Application Server (Resource Member)
Application Server (Resource Member)
Cell (Software Resource)
Deployment Manager
Application Server Node (Software Resource)

Node Agent
Application Server Node (Software Resource)

Node Agent
Cluster Cluster Member (Software Instance) Cluster Member (Software Instance) Cluster Member (Software Instance) Cluster Member (Software Instance)
Application Server (Software Installation)
Application Server (Software Installation)
Cell
In WebSphere Application Server, an administrative domain is called a cell. Within a cell, a deployment manager serves as a single point for administration of the cell. The deployment manager is installed on one of the nodes within the cell.
735
In the data center model, administrative domains are associated with the WebSphere Application Server software definition that represents the version of the product that you are using to manage the cell. Nodes A subdomain corresponds to a node within a cell. A node is a logical grouping of server processes that share common configuration and operational control. It is associated with one physical installation of WebSphere Application Server. v In WebSphere Application Server Network Deployment, a cell can contain multiple nodes. The application and configuration files are stored centrally, so that the nodes can be administered from a single administration server. v In a standalone WebSphere Application Server configuration, a cell contains one node. A node can contain multiple servers, but the configuration files for each server are stored and maintained individually. Alternatively, WebSphere Application Server nodes can be added to a cell that is managed by a WebSphere Application Server Network Deployment server. For each subdomain, you must identify the host server for the node and the existing WebSphere Application Server software installation on the server. Clusters WebSphere Application Server Network Deployment provides the ability to create application server clusters to manage workload. You can create WebSphere Application Server Network Deployment clusters and distribute components of a composite application to it. An administrative domain can include zero or more clusters. All cluster members must belong to the same cell. Cluster members are represented by software instances in the data model. You can use discovery to automatically identify existing WebSphere Application Server cells and nodes and add them to the data model, or you can manually model them. You can create clusters within a cell from the Web interface. WebSphere Application Server Network Deployment clusters are created as management server clusters in the data model. Requirements to define administrative domains: The following requirements must be met to define a WebSphere Application Server administrative domain in the data model: v WebSphere Application Server or WebSphere Application Server Network Deployment must be installed on any computers that you want to include in the administrative domain. WebSphere Application Server Network Deployment must be installed on the computer that you want to use to administer multiple nodes within a cell. v Nodes and cells must be configured using WebSphere Application Server. For more information, see the WebSphere Application Server documentation. v To create a cluster, the application servers that you want to include must have identical application components deployed on them. The servers do not need to share other configuration data. For example, one cluster member might be running on a large multiprocessor enterprise server, while another member of that same cluster might be running on a smaller system. The configuration for each server is different, but the same application components must be installed if you want to include them both in the same cluster. v The appropriate WebSphere Application Server automation package and software definition must exist in the data model. Defining administrative domains: You can add an administrative domain to model a set of nodes that are managed from a single point, such as a WebSphere Application Server cell. After you have added the administrative domain, you must define the nodes and software that it manages.
736
Adding subdomains: A subdomain represents a server that is managed by an administrative domain. Before you begin Prerequisites: If you are modelling a WebSphere Application Server cell, a subdomain represents a node. The node that you want to define must already be configured in WebSphere Application Server. After the subdomain is added to the administrative domain, you can identify the software on the server that will be managed by the administrative domain. Adding resource members: Resource members represent the software resources that an administrative domain manages. Before you begin Prerequisites: If you are modelling a WebSphere Application Server cell, a resource member is a WebSphere Application Server installation on a node. The software installation that represents the WebSphere Application Server must be in the data model. You can then associate the software installation with the appropriate subdomains. The only type of resource member that can be associated with the parent administrative domain is a cluster. After the resource member is successfully added, its name is added to the list of resource members in the subdomain. Adding clusters to administrative domains: You can create a WebSphere Application Server cluster for fully defined WebSphere Application Server administrative domains in the data model. Before you begin Prerequisites: You must configure administrative domains to which you are adding the cluster with the appropriate subdomains and resource members. For WebSphere Application Server clusters, this configuration includes defining the cell as an administrative domain, defining the nodes as subdomains, and defining the WebSphere Application Server software installations as resource members. When you create a WebSphere Application Server cluster, the cluster type is set to Management Server Domain. You can use the cluster as a target for J2EE application components. Removing clusters from administrative domains: There are two options for removing clusters from an administrative domain. You remove a cluster from the data model only, or remove it from the actual administrative domain using a provisioning workflow.
Configuring Wake on LAN (WOL)

Wake on LAN (WOL) is a broadcast protocol that can be used to remotely power on "sleeping" target computers by sending special network data packets. This enables you to remotely perform maintenance and send updates to systems that have been powered off by their users. The target computers must be enabled to receive and respond to the WOL data packets.
737
Before you begin

v To enable each target computer configured for WOL to respond to the packets, ensure that the value of the WOL option in the BIOS (typically under network settings) is set to Enabled. For PCI network cards, attach a WOL power cable to the system board (where applicable). v To be able to set up and use the WOL protocol with the provisioning server, you must know the IP address, the MAC address, and the subnet of all of the targets that you want to "wake up", or use the Tivoli common agent to discover these parameters using its Tivoli Provisioning Manager Inventory Discovery. Tip: You can either obtain all of these parameters by manually adding a new target computer, install the common agent on it, set up all of the required service access points and credentials, and specify all of these parameters yourself, or you can first install the common agent by clicking Go To > Deployment > Software Management > Common Agent Installation. After that, run the Tivoli Provisioning Manager Inventory Discovery scan on the target computer to set up all the parameters automatically. The WOL.tcdriver automation package provides a number of provisioning workflows that can be used to set up the WOL for all the target computers. First, assign the WOL device driver to the targets.
Assigning the WOL device driver to targets

To be able to configure the target computers for WOL using a set of predefined provisioning workflows, you must first assign the WOL device driver to either a specified target or to a group of targets. When the WOL device driver is assigned to a specified target, all of its WOL-specific provisioning workflows become available to be used with the selected target computer.
Using Wake on LAN (WOL) with Tivoli Provisioning Manager

After you have configured the computers for Wake on LAN (WOL) in Tivoli Provisioning Manager, there are several ways you can turn them on.
Before you begin

If you have not already configured the target computers for WOL, see the Configuring Wake on LAN (WOL) on page 737 topic for more information. The following options for turning on target computers are described: v You can turn on an individual target, by clicking Management on the List page. v You can turn on a group of targets by running a favorite task initiated by the Device.PowerOn.wkf provisioning workflow on the target group. v You can turn on a number of targets in a group as part of a software distribution task. The software distribution task might have completed successfully on most of the targets in the provisioning group, but some of the remaining targets might still be in progress. To check whether the targets that are still in progress are turned on or not, you can run a specific WOL provisioning workflow on the group. You can define a favorite task using the WOL_TaskTargetsSubmitted.wkf workflow and run it on the target group. The workflow will turn on the targets that were shut down, which in turn allows the software distribution task to resume and complete successfully on the targets.
Overriding the default WOL port

You can override the default Wake on LAN (WOL) port and use another port.
738
Before you begin

If you have not already configured the target computers for WOL, see the Configuring Wake on LAN (WOL) on page 737 topic for more information. You can override the default port on an individual system by creating a new variable in the variable tab on the server. Or, you can override the default port for all servers in the datacenter using the same IP port by creating a global variable. For both of these options, set the variable as follows: Key Enter WOL_IP_PORT.
Value Enter the override value as an integer. Component Enter Deployment Engine.
Configuring firewall components

A built-in firewall is provided for scenarios where servers (managers) are separated from destination clients (agents) by one or more intermediary networks because of firewall policies or address space concerns. The firewall components are used to tunnel traffic between network zones, and can be chained together to allow for multiple hops. Note: The firewall components are intended to be used with the scalable distribution infrastructure. It does not allow communication between the provisioning server and the common agent using the port number 9510 for any provisioning workflow that you want to run. If your scenario requires a provisioning workflow to communicate with the common agent, then the provisioning server must be able to communicate with the common agent using the listening port (9510 by default) or an alternative protocol. The following graphic is a high-level, functional overview of the firewall components:
739
Agent
1
Gateway service
Proxy Relay
Command Channel
Gateway Manager
5 3
1. An agent connects to gateway service and sends a command to connect to the Agent Manager on the provisioning server. 2. The gateway service sends a command to gateway manager. 3. The gateway manager creates connection to manager. 4. The gateway creates a connection to the gateway service using the proxy relay. 5. The gateway manager ties connections 3 and 4 to form a virtual connection from the manager to the gateway service. 6. The gateway service ties connections 4 and 6 to form a virtual connection from the manager to the agent. Proxy relay The firewall components operate by opening default port 1960 on the proxy relay system, and then listening on this port for routed traffic. When a connection is made to this port, the proxy relay expects control information to be sent, which instructs the relay to create a TCP/IP connection to the specified address and port. After the new connection is created, the two input and output stream connections are joined together using a thread that reads data from an input stream and writes data to another output stream. Each proxy relay is configured with an access control list (ACL) which determines which incoming and outgoing connections to allow. The proxy relay is optional, as described in the Scenario 1: Connectivity using unidirectional firewall on page 746 topic. Gateway manager and service The gateway includes the gateway manager and the gateway service. The gateway is used to tunnel TCP/IP traffic from point 1 through the gateway service and gateway manager to the final destination 2.
740
Each gateway manager can connect to and manage one or more gateway services. In turn, each gateway service can be managed by one or more gateway managers. For gateway communications, all connections are created from the gateway manager to the gateway service.
Resource Manager
Resource Manager
Resource Manager
Gateway Manager
Gateway Manager
Gateway Manager
Proxy Relays
Gateway Service
Gateway Service
Target
Target
For example, a target computer (1, illustrated in the preceding image) must create a TCP/IP connection to a resource (2). Because of unidirectional firewall rules, connections can only originate from the network where the resource (2) resides. Using the gateway, the target computer (1) creates a connection to the gateway service (3), which is allowed, as they are in the same network. A gateway manager (4) creates a connection to a resource (2), which resides in the same network. Next, the gateway manager (4) creates a connection to the gateway service (3). Then, using the input and output streams, the original connection from the target computer (1) to the gateway service (3) acts as though it is connected directly to the resource (2). When the gateway manager and gateway service are operating correctly, there is a persistent TCP/IP from the gateway manager to the gateway service. This command channel enables the gateway service to alert the gateway manager when it receives a new connection request. A periodic heartbeat signal is sent to keep the connection alive. If the command channel is closed, the gateway manager will attempt to reconnect periodically. The gateway service will automatically stop listening on that particular gateway manager's service ports when the connection is broken. The gateway service can be configured to advertise a particular service. To use this feature, user datagram protocol (UDP) broadcasting must be enabled for the local subnet. A target computer can discover a service by sending a broadcast UDP packet containing the service's name. If the gateway service receives the UDP packet and it currently advertises that service name, then it will respond back with an addressed UDP packet which contains the port number that service is listening on. The target computer can then use the source address of the UDP packet and the port contained within the packet to connect to the given service. The following procedures are required to configure the firewall components, including setting up the gateway manager, starting the gateway service and gateway manager, and enabling the firewall support for the common agent. A couple of sample scenarios are also provided, to better illustrate how to set up the firewall components in complex network environments.
Setting up the gateway manager

Before you can use the gateway manager, first create a gateway.private file for it, and then start the gateway manager and the gateway service.
741
Prerequisites
The following prerequisites must be met before setting up the gateway manager: v A SDI-SAP service access point is required on your target computers, so that the scalable distribution infrastructure is used instead of the deployment engine when deployment occurs. This service access point can be created automatically when the common agent is installed. To enable this functions: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Variables tab. 3. Find the TCA.Create.EO.SAP global variable and verify that its value is set to true, which enables the automated creation of the SDI-SAP service access point as part of the common agent installation process. v The provisioning server must be able to connect to agents directly during the agent installation. v The dynamic content delivery management center must be able to connect to depots directly, without using a proxy. This restriction does not apply to connections in the other direction, so that depots can use a proxy to connect to the management center. v Enable the user datagram protocol (UDP) broadcasting for the local subnet. The gateway service provides a broadcast UDP-based discovery mechanism, which allows the target computers to query the network for a gateway service that provides connectivity to a given service name. The targets must be able to UDP broadcast in order to be able to discover the gateway service.
Generating the keystore

The gateway manager and server use secure socket layer (SSL) to communicate their command channel, which means that there is key management. When the gateway manager is activated, it looks for a file called gateway.private in the same directory as the gateway.xml configuration file (the directory where you start the gateway manager). This file is in the standard Java keystore. You can use iKeyMan (which comes with the IBM JDK) to create a file. You can generate the keystore using the tioadmin user or any other user. To generate the keystore: 1. Start the IBM Key Management application. a. Change to the WAS_installdir/bin directory. b. Run one of the following commands: v On Windows systems: ikeyman.bat v On AIX, Linux, and Solaris systems: ikeyman.sh 2. Click Key Database File > New. 3. Set the file name to gateway.private and remember its location. Also ensure that the Key database type value is JKS. 4. Click OK and enter a password value. Use the value password, as this is the current default value for the main method. 5. Click Create > New Self-Signed Certificate. Type the required information. Leave the version set to X509 V3 and the key size at 1024. Make the key label gateway for future use. 6. Click File > Close and exit the application. 7. Copy the new gateway.private file to the same directory as the gateway.xml configuration file. 8. Start the gateway manager to create the gateway.public file (see Starting the components on page 744) and then exit (Ctrl+C). Note: This step is required only once, to create the gateway.public file. Then, whenever you want to make the connection between the gateway manager and gateway service, start the gateway service first.
742
9. When the gateway manager starts, it reads the gateway.private file and creates a file called gateway.public. This file needs to be copied to the current directory of the gateway service. The file can be renamed, but must retain the .public extension. When the gateway service starts up, it loads the public keys found in all .public files, which allows a gateway service to accept SSL connection from multiple gateway managers.
Configuring each component

The firewall components are packaged into a .jar file called proxy.jar in the $TIO_HOME/repository/ FirewallProxy directory on the provisioning server. The proxyosgi.jar provides OSGI-compliant packaging. Gateway manager You can install the gateway manager on the provisioning server or on the same side of the firewall as the provisioning server. Ensure that Java is at the beginning of your PATH environment variable. The following files are required in the directory where you start the gateway manager: 1. gateway.xml: The gateway.xml sample provided in the Scenario 1: Connectivity using unidirectional firewall on page 746 topic is a single firewall scenario. You can change the default port that the gateway service listens to, 1961, by editing the gateway.xml file. Start the gateway service using that port. 2. gateway.private 3. proxy.jar Gateway service You can install the gateway service on any computer on the same side as the agents. Ensure that: v Java is at the beginning of your PATH environment variable. v You use either the Java version from the target computer (SR6 or SR7), or at least the same version or higher. The following files are required in the directory where you start the gateway service: 1. gateway.public (This file is not generated on the gateway service computer, but rather needs to be manually copied from the gateway manager computer to the gateway service computer.) 2. proxy.jar This computer will accept connections from the target computers. Connections made to the gateway service are forwarded using the gateway manager to the resource manager. When the gateway service is started, it waits for a connection from a gateway manager. A gateway service can handle multiple gateway managers simultaneously. Note: Starting with Tivoli Provisioning Manager version 5.1.0.2 (Fix Pack 2), the gateway service port can be configured. To specify the port, run the following command:
java -jar proxy.jar -gwservice <port_number>
In earlier versions of Tivoli Provisioning Manager, the gateway service port had to be 1961. Proxy relay If a proxy relay is required, use the gateway.xml sample for the gateway manager provided in the Scenario 2: Connectivity using unidirectional firewall with additional network on page 748 topic. The following files are required in the directory where you start the proxy relay: 1. proxyrelay.xml A proxyrelay.xml sample is also provided in the Scenario 2: Connectivity using unidirectional firewall with additional network on page 748 topic.
743
2. proxy.jar
Starting the components

Start the firewall components in the following order: 1. Gateway service: Start the gateway service on any computer on the same side as the agents using the following command:
java -jar proxy.jar -gwservice <port_number>
where <port_number> is the port that the gateway service listens on. You can either specify the path of the proxy.jar file or you can run the command from the directory where the proxy.jar was saved. The default port number is 1961. Note: The provided sample .xml files use the default port number. 2. Proxy relay: If you have any proxy relays, start them by typing: java -jar proxy.jar -relay. 3. Gateway manager: Start the gateway manager on the provisioning server or on the same side of the firewall as the provisioning server by running the following command:
java -jar proxy.jar -gwmanager gateway.xml
You can either specify the paths for the proxy.jar and gateway.xml files, or run the command from the directory where both of these files are saved. Next, you need to configure the provisioning server from the web interface to enable the firewall support.
Enabling firewall support for the common agent

To allow the common agent to communicate through a firewall, enable the firewall support. For new agents To enable the firewall support for a new agent: 1. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. 2. Find Tivoli Common Agent Stack and click its name. 3. Under Configuration Templates, click TCA-TPM-Base Feature default. 4. Click TCA-TPM default and change the value of the EnableFirewallSupport parameter from false to true. 5. Click TCA-Subagent JES and change the value of the EnableFirewallSupport parameter from false to true. . 6. Click Save 7. Install the agent. 8. Enable the user datagram protocol (UDP) broadcasting for the local subnet, on which the agent and gateway service are located. For existing agents To enable the firewall support for an existing agent: 1. Modify the following property files on the agent: v $Install_Dir/runtime/agent/subagents/jes.properties: Set the value of the EnableFirewallSupport parameter to true. v $Install_Dir/runtime/agent/subagents/tpm.properties: Set the value of the EnableFirewallSupport parameter to true. 2. Restart the agent.
744
Firewall support without using UDP

When user datagram protocol (UDP) traffic is blocked between the common agent and the Gateway Service system, the discovery mechanism does not function. The common agent cannot automatically find routing information to access the Tivoli Provisioning Manager components behind network discontinuities. You can hard code the network addresses and ports in an appropriate property files named proxy.conf, and point the common agent directly to the Gateway Service to allow communication across firewalls. The proxy.conf file is used to communicate which IP must be used (the GW Service IP) to access the services normally provided by the Tivoli Provisioning Manager server. The syntax of the proxy.conf file is:
tpmServer_ip:targetport=gatewayService_ip:proxyport .... depotServer_ip:proxyport=gatewayService_ip:proxyport gatewayService_ip:proxyport=gatewayService_ip:proxyport .... gatewayService_hostName:proxyport=gatewayService_hostName:proxyport ....
The following is a sample proxy.conf file where v tpmServer_ip = 9.48.162.4 v depotServer_ip = 9.3.5.88 v gatewayService_ip = 9.48.162.226 v gatewayService_hostName = GWServiceMachine
9.48.162.4:9045=9.48.162.226:9045 9.48.162.4:9046=9.48.162.226:9046 9.3.5.88:2100=9.48.162.226:2100 9.48.162.4:9511=9.48.162.226:9511 9.48.162.4:9512=9.48.162.226:9512 9.48.162.4:9513=9.48.162.226:9513 9.48.162.226:9045=9.48.162.226:9045 9.48.162.226:9046=9.48.162.226:9046 9.48.162.226:2100=9.48.162.226:2100 9.48.162.226:9511=9.48.162.226:9511 9.48.162.226:9512=9.48.162.226:9512 9.48.162.226:9513=9.48.162.226:9513 GWServiceMachine:9045=GWServiceMachine:9045 GWServiceMachine:9046=GWServiceMachine:9046 GWServiceMachine:2100=GWServiceMachine:2100 GWServiceMachine:9511=GWServiceMachine:9511 GWServiceMachine:9512=GWServiceMachine:9512 GWServiceMachine:9513=GWServiceMachine:9513
The proxy.conf file must contain the Tivoli Provisioning Manager server IP and not the Gateway Manager IP. The proxy.conf file must be in both of the following directories, depending on your operating system: v $CA_HOME/runtime/agent/config or %CA_HOME%\runtime\agent\config v $CA_HOME/runtime/agent/subagent/cds/client or %CA_HOME%\runtime\agent\subagent\cds\ client where CA_HOME is the common agent installation directory. Make sure to set the advertise fields of the gateway configuration file to false. The gateway configuration file is called gateway.xml by default. Set the fields that indicate which Gateway Services connect to the Gateway Manager.
745
For example:
<!DOCTYPE gatewaymanager> <gatewaymanager> <gatewayservice name="barcelona" type="remote" host="9.48.162.226 " port="1961"> <service name="nice.itsc.austin.ibm.com:2100" port="2100" advertise="false"> <resource host="9.3.5.88" port="2100" /> </service> <service name="9.48.162.4 :9511" port="9511" advertise="false"> <resource host="9.48.162.4 " port="9511" /> </service> <service name="9.48.162.4 :9512" port="9512" advertise="false"> <resource host="9.48.162.4 " port="9512" /> </service> <service name="9.48.162.4 :9513" port="9513" advertise="false"> <resource host="9.48.162.4 " port="9513" /> </service> <service name="9.48.162.4 :9045" port="9045" advertise="false"> <resource host="9.48.162.4 " port="9045" /> </service> <service name="9.48.162.4 :9046" port="9046" advertise="false"> <resource host="9.48.162.4 " port="9046" /> </service> </gatewayservice> </gatewaymanager>
If the Tivoli Provisioning Manager server has multiple Network Interface Cards (NIC), insert both eth and eth0 IPs into the proxy.conf file. The format of the proxy.conf file is, in this case:
TPMSERVER_IP[NIC_eth]:9045=GS_IP:9045 TPMSERVER_IP[NIC_eth]:9046=GS_IP:9046 DepotServer_IP:2100= GS_IP:2100 TPMSERVER_IP[NIC_eth]:9511=GS_IP:9511 TPMSERVER_IP[NIC_eth]:9512=GS_IP:9512 TPMSERVER_IP[NIC_eth]:9513=GS_IP:9513 TPMSERVER_IP[NIC_eth0]:9045=GS_IP:9045 TPMSERVER_IP[NIC_eth0]:9046=GS_IP:9046 TPMSERVER_IP[NIC_eth0]:9511=GS_IP:9511 TPMSERVER_IP[NIC_eth0]:9512=GS_IP:9512 TPMSERVER_IP[NIC_eth0]:9513=GS_IP:9513 GS_IP:9045=GS_IP:9045 GS_IP:9046=GS_IP:9046 GS_IP:2100=GS_IP:2100 GS_IP:9511=GS_IP:9511 GS_IP:9512=GS_IP:9512 GS_IP:9513=GS_IP:9513 GS_HOSTNAME:9045=GS_HOSTNAME:9045 GS_HOSTNAME:9046=GS_HOSTNAME:9046 GS_HOSTNAME:2100=GS_HOSTNAME:2100 GS_HOSTNAME:9511=GS_HOSTNAME:9511 GS_HOSTNAME:9512=GS_HOSTNAME:9512 GS_HOSTNAME:9513=GS_HOSTNAME:9513
Scenario 1: Connectivity using unidirectional firewall

This sample shows how the gateway manager and service can provide target connectivity to the server through a unidirectional firewall.
746
Prerequisites: To be able to use the gateway manager, you must set it up first. For more information, see Setting up the gateway manager on page 741. Ensure that all the prerequisites are met before proceeding with the setup. The server is behind a firewall which only allows traffic from the gateway manager to the target computers on port 1961. To operate correctly, the targets need to connect to the gateway service on TCP/IP port 9443, 9046, 2100, and 9511-9513, which are the ports necessary for tasks running over the scalable distribution infrastructure. Note: In the following setup, all ports from the gateway service to the gateway manager are closed.
Tivoli Provisioning Manager Server
Depot
Gateway Manager
Firewall
Gateway Service
Target
747
The gateway manager is configured to connect to the gateway service on port 1961. To configure the gateway manager, you can use a file called gateway.xml. The contents of this file indicate to the gateway manager where to forward packets when they reach the manager from the service. This is a sample gateway.xml file:
<!DOCTYPE gatewaymanager> <gatewaymanager> <gatewayservice name="SERVICE_NAME" type="remote" host="GW_SERVICE_IP" port="1961"> <service name="DEPOT_HOSTNAME:2100" port="2100" advertise="true"> <resource host="DEPOT_IP" port="2100" /> </service> <service name="TPM_SERVER_HOSTNAME:9511" port="9511" advertise="true"> <resource host="TPM_SERVER_IP" port="9511" /> </service> <service name="TPM_SERVER_HOSTNAME:9512" port="9512" advertise="true"> <resource host="TPM_SERVER_IP" port="9512" /> </service> <service name="TPM_SERVER_HOSTNAME:9513" port="9513" advertise="true"> <resource host="TPM_SERVER_IP" port="9513" /> </service> <service name="TPM_SERVER_HOSTNAME:9443" port="9443" advertise="true"> <resource host="TPM_SERVER_IP" port="9443" /> </service> <service name="TPM_SERVER_HOSTNAME:9046" port="9046" advertise="true"> <resource host="TPM_SERVER_IP" port="9046" /> </service> </gatewayservice> </gatewaymanager>
When connected, the gateway manager instructs the gateway service to listen on the following ports: 9443, 9046, 2100, and 9511-9513. When a connection is made to the gateway service on one of these ports, the gateway manager creates a connection to the provisioning server on the same port. It then creates another connection to the gateway service. When this connection is made, the gateway manager and service use a set of input-output data streams to create a seamless connection from the target computer to the provisioning server on the required port.
Scenario 2: Connectivity using unidirectional firewall with additional network

This sample is similar to scenario 1 with the addition of another network between the provisioning server and the target computers. This configuration requires a proxy relay to provide a hop from the gateway manager to the gateway service. In this case, the gateway manager talks to the proxy relay on port 1960, and the proxy relay talks to the gateway service on port 1961. Prerequisites: You must set up the gateway manager before you can use it. For more information, see Setting up the gateway manager on page 741. Ensure that all the prerequisites are met before proceeding with the setup. As illustrated in the following image, between the provisioning server network zone and the target network zone there is an additional network zone. There is connectivity from both the provisioning server and target network zones to the middle zone, but not from the provisioning server network zone to the target network zone. Note: In the following setup, all ports from the gateway service to the proxy relay and gateway manager are closed.
748
Tivoli Provisioning Manager Server
Depot
Gateway Manager
Firewall
Proxy Relay
Firewall
Gateway Service
Target
To operate correctly, the target computers need to connect to the gateway service on TCP/IP ports 9056, 9046, 2100, and 9511-1913. The gateway manager is configured to contact the gateway service through the proxy relay. To configure the gateway manager, you can use a file called gateway.xml. The contents of this file indicate to the gateway manager where to forward packets when they reach the manager from the service. The following is a sample gateway.xml file:
<!DOCTYPE gatewaymanager> <gatewaymanager>
749
<gatewayservice name="SERVCE_NAME" type="remote" host="GW_SERVICE_IP" port="1961"> <routepath> <pathElement host="RELAY_IP" port="1960" /> </routepath> <service name="DEPOT_IP:2100" port="2100" advertise="true"> <resource host="DEPOT_IP" port="2100" /> </service> <service name="TPM_SERVER_IP:9511" port="9511" advertise="true"> <resource host="TPM_SERVER_IP" port="9511" /> </service> <service name="TPM_SERVER_IP:9512" port="9512" advertise="true"> <resource host="TPM_SERVER_IP" port="9512" /> </service> <service name="TPM_SERVER_IP:9513" port="9513" advertise="true"> <resource host="TPM_SERVER_IP" port="9513" /> </service> <service name="TPM_SERVER_IP:9443" port="9443" advertise="true"> <resource host="TPM_SERVER_IP" port="9443" /> </service> <service name="TPM_SERVER_IP:9046" port="9046" advertise="true"> <resource host="TPM_SERVER_IP" port="9046" /> </service> </gatewayservice> </gatewaymanager>
When connected, the gateway manager instructs the gateway service to listen on those ports. You also need a file to configure the proxy relay computer called proxyrelay.xml. This is a template that instructs the proxy relay on where to get and send its information to pass onto the gateway manager. This is a sample proxyrelay.xml file:
<!DOCTYPE proxyrelay> <proxyrelay port="1960"> <inboundACL> <entry>GW_MANAGER_IP/24:1960</entry> </inboundACL> <outboundACL> <entry>GW_SERVICE_IP/24:1961</entry> </outboundACL> </proxyrelay>
When a connection is made to the gateway service on one of those ports, the gateway manager creates a connection to the provisioning server on the same port. It then creates another connection to the gateway service. When this connection is made, the gateway manager and service use a set of input-output data streams to create a seamless connection from the target computer to the provisioning server on required port.
Packaging software for distribution

Tivoli Provisioning Manager uses the Software Package Editor to create and customize software packages. The Software Package Editor is a Java-based software distribution and packaging utility.
750
For information about creating software packages, see the Software Package Editor documentation in the Administrator Guide.
Troubleshooting software distribution

When you run software distribution jobs, there are multiple product components that handle the software distribution job. To identify the source of a software distribution problem, it is important to understand the components that process a software distribution job. Use the information in the Process section to learn about the main steps that occur during software distribution. Use the remaining sections to find out how to troubleshoot errors that occur during specific parts of the process. v Process v 1. Task Status v 2. Publish status on page 752 v 3. Job status on page 753 v 4. Target status on page 754 v 5. Results on page 755
Process
To demonstrate how components interact, the following steps outline the component interactions during a software package (SPB) deployment in an environment that uses the scalable distribution infrastructure. 1. The task is submitted and activity plan engine starts task execution. 2. The deployment engine runs the workflow to perform the software distribution. 3. The software package file is published to the depot. 4. The job is submitted to device manager. 5. The target computer polls device manager for the job and downloads the software package and installs it. 6. The results are returned to device manager. If an error occurs during software distribution: 1. Verify that all requirements for software distribution are met as described in Prerequisite checklist. 2. Use the subsections of this topic to learn more about how to troubleshoot specific parts of a software distribution task.
1. Task status
Check the status of the software distribution task. For information about task status, see Tracking a provisioning task on page 1165. 1. Check for error messages that might explain the source of the problem. 2. On the provisioning server, check the log files for the activity plan engine and the deployment engine. By default, the log level for console.log is info and the log level for trace.log is error. Change the log level to debug to obtain more troubleshooting information. For information about setting the log level, see Configuring log4j dynamically.
Windows
%TIO_LOGS%
Linux
UNIX
$TIO_LOGS
751
Table 126. Log files (continued) Log file trace.log Location

Windows
%TIO_LOGS%
Linux
UNIX
$TIO_LOGS
The following excerpts from console.log show key messages for a successful software distribution task: This line indicates that the task has started:
DEBUG [Activity Plan Engine] ( TpmTask.java:55) manager.TpmTask: Task execution started: Install Software
The following line shows that permissions were successfully verified on the target computer:
DEBUG [Install Software(88491) from com.ibm.tivoli.tpm.activityplan.manager.AggregateTaskDispatcher] (WorkflowAccessManager.java:106) accesscontrol.WorkflowAccessManager: checking permission (target:6027)Software.Install Software.Install on 24982 succeeded DEBUG [Install Software(88491) from com.ibm.tivoli.tpm.activityplan.manager.AggregateTaskDispatcher] (WorkflowAccessManager.java:106) accesscontrol.WorkflowAccessManager: checking permission (target:6027)Device.ManagerSoftware Device.ManagerSoftware on 24967 succeeded
The following line shows the dispatch of the target to the SDI infrastructure:
DEBUG [Install Software(88491) from com.ibm.tivoli.tpm.activityplan.manager.AggregateTaskDispatcher] (AggregateTaskDispatcher.java:73) manager.AggregateTaskDispatcher: Dispatching 1 targets to com.ibm.tivoli.tpm.infrastructure.SdiTaskInfrastructure
3. Check console log and trace log for more information. The examples in the software deployment topic use the Software.Install logical operation. Search for the associated ID (88491) for the software installation and look for the workflows that are associated with that task. You can then search for the workflow name or ID to look for error messages. 4. Open the Workflow Execution Logs view if it is not displayed. a. From the Eclipse menu, click Window > Show View > Other. b. Expand Automation Package and click Workflow Execution Logs. c. Click OK. The Workflow Execution Logs page displays the provisioning workflow run history. There is a limit of 4000 characters for provisioning workflow output. If this limit is exceeded, the output is truncated.
2. Publish status
Verify that the file was published to the depot. 1. The following line shows that the .spb file was published to the depot:
DEBUG [Install Software(88491) from com.ibm.tivoli.tpm.infrastructure.soa.OSGiSdiTaskDispatcher] (FileManager.java:317) cds.FileManager: Published file C:/Program Files/IBM/tivoli/tpm/repository/ \/Noname.1.0.spb with taskId 88491 to CDS depots: tpmlabw2k8.romelab.it.ibm.com
2. Verify in the dynamic content delivery console that the file is on the depot server. In a supported web browser, type the following URL:
3. Log on with the Tivoli Provisioning Manager administrator user name and password that you specified during core components installation. The default user is maxadmin. 4. If more information is required for the depot, check the following log files on the provisioning server:
752
Table 127. Log files Log file trace_cdsmgr.log Message and trace information for download plans as well as general message and trace information trace_cdssec.log Message and trace information for Web services authentication and authorization trace_distribution.log Message and trace information for the distribution agent Location
Windows
%TIO_LOGS%\..\..\ctgde\logs
Linux
UNIX Windows
$TIO_LOGS/../../ctgde/logs
Linux
UNIX Windows
Linux
UNIX
3. Job status
Verify the status of the software distribution job. 1. On the provisioning server, check console.log for a message to indicate that the job was submitted:
INFO [Install Software(88491) from com.ibm.tivoli.tpm.infrastructure.soa.OSGiSdiTaskDispatcher] (JobManagementServiceClient.java:534) client.JobManagementServiceClient: Submitted job to the job management server. Job id is: [128766740182461234]
2. If more information is required for device manager, check the following log files on the provisioning server:
Windows
%WAS_PROFILE_DIR%\logs\MXServer
Linux
UNIX
$WAS_PROFILE_DIR/logs/MXServer
DMSMsgn.log
Windows
%WAS_PROFILE_DIR%\logs\MXServer\
Linux
UNIX
$WAS_PROFILE_DIR/logs/MXServer
3. In TraceDMSnumber.log, search for the job ID. For example, the log file example in step 1 has the job ID 128766740182461234. The default DMS polling interval is 60 minutes, so the timestamp in the log might be as much as 60 minutes after the job was submitted. The following example shows an excerpt from the log:
INSERT INTO SUBMITTED_JOB (JOB_ID, EXPIRATION_TIME, TARGET_DEVICE_SCOPE, ENROLLMENT_JOB, INSERTING, JOB_TYPE, ACTIVATION_TIME, JOB_PRIORITY, SEND_NOTIFICATION, TARGET_DEVCLASS_ID, ALL_DEVICES) VALUES (128766740182461234, {ts 2010-11-09 10:33:00}, BOTH, T, T, FEDERATOR, {ts 2010-10-20 10:33:01}, 3, F, 128766740182461234, T)
4. DMS logs provide the following information: a. Connected endpoint hostname/ip and eligible jobs for that endpoint:
Activity: When registered device connects to DMS server Log messages Event: ELIGIBLE_JOBS Host: xyz.in.ibm.com Job ID: J1 (JDS Command), J2 (Inventory), J3 (Patch install)
b.
Connected endpoint hostname/ip and job result returned by that endpoint:
753
Activity: When registered device connects to DMS server Log messages Event: JOB_RESULT Host: xyz.in.ibm.com Job ID: J1 Result: OK
c. Enrollment activity of new devices:

Activity: When new device makes connection to DMS server Log messages Event: ENROLLMENT Host : wer.in.ibm.com
d. DMS job federation activity and the resultant actual JDML job created:
Activity: When DMS federator federates job Log messages Event: JOB_FEDERATION Federator Job ID: 123456 JDML Job ID : 554433
Note: These messages are provided in Level 1 tracing and can be stopped by changing the value of key component.serviceability to false in the traceConfig.properties file. This is a new key introduced in this file for serviceability changes. The fix pack installer modifies the existing traceConfig.properties file, adding this new key by setting its value as true. 5. TraceDMS1.log entry examples:
06/29/2011 5:00:19.403 com.tivoli.dms.plugin.syncmldm.SyncMLDMDeviceObject sendSyncMLResponse WebContainer: 4 Event: ELIGIBLE_JOBS Host: 9.122.19.93 Job ID: 130881793422967296(DMSInventoryJob)
06/29/2011 5:00:21.150 com.tivoli.dms.dmserver.DeviceManagementServerServlet processDeviceJobProcessingCompleteEvent WebContainer: 4 Event: JOB_RESULT Host: 9.122.19.93 Job ID: 130881793422967296 Result: OK
06/29/2011 5:04:30.921 com.tivoli.dms.federator.FederatorDeviceJob execute DMSFederatorAgent Event: JOB_FEDERATION Federator Job ID: 130934180771897460 JDML Job ID: 130934187080707782
6. DeviceEnroll1.log entry example:

06/29/2011 5:00:18.336 java.lang.Class logEnrollMsg WebContainer: 0 9.167.40.3:tpmOSGi
4. Target status
Check the progress of the software distribution job on the target computer for the software distribution task. 1. Change the log level on the Tivoli Common Agent and enable the highest level of tracing as described in Setting log levels for Tivoli Common Agent. Retrieve the requestId from the log on the provisioning server. The following line is an example of what you will see in the log file:
INFO [Install Software 24982(88603) from com.ibm.tivoli.tpm.infrastructure.soa.OSGiSdiTaskDispatcher] (JobManagementServiceClient.java:515) client.JobManagementServiceClient: job.requestId = e0b1fef0e1a111df9188000c291214c0
2. On the target computer, verify that the software distribution job was received for processing. In CA_HOME/logs/trace-log-number.xml look for the requestId:
JES045I Dequeued new job: name = [SPBInstall], request id = [e0b1fef0e1a111df9188000c291214c0]
CA_HOME The agent installation directory v v

Windows HP UX
Linux Solaris
/opt/tivoli/ep
754
AIX
/usr/tivoli/ep
number A number such as 1. If the job was not received, check the following items: a. Verify communication with the target computer. Run the TCA_PingAgent provisioning workflow. b. If the software distribution task is taking a long time to complete, one possible cause is that the target computer is not polling for jobs, so the job is never received. To fix this problem, see Jobs not reaching target computer. 3. Look for a call to the FileManagementService, copyFile:
INFO: TPMFMS001I File copy:...
4. Verify the status of the installation by checking the log for the following message:
DSM0002I Operation INSTALL (Name=swName, Version=1.0) completed with Return Code 0
5. On the target computer, check the following log files for additional information:
Table 129. Log files Log file error-log-number.log For error messages generated during agent run time. Location
Windows
C:\Program Files\tivoli\ep\logs
Linux Solaris
HP UX
/opt/tivoli/ep/logs
AIX
/usr/tivoli/ep/logs
5. Results
1. Check the file CA_HOME/logs/trace-log-number.xml for the status of the job completion event sent to device manager:
JES052I Sending job status notification for request [e0b1fef0e1a111df9188000c291214c0].
Check the log that begins with EVT009I Sending event for JobStatus and WorkItemStatus. The following log file example shows the possible values: JobStatus v JOB_STATE_QUEUED = 1; v JOB_STATE_SUBMITTED = 2; v JOB_STATE_CANCELLED_ALL = 4; v JOB_STATE_CANCELLED_PARTIAL = 5; v JOB_STATE_COMPLETE_ALL = 6; v JOB_STATE_COMPLETE_PARTIAL = 7; v JOB_STATE_FAIL = 8; v JOB_STATE_REJECTED = 9; WorkItemStatus v WORK_ITEM_STATUS_EXECUTING = 1; v WORK_ITEM_STATUS_COMPLETED = 2; v WORK_ITEM_STATUS_FAILED = 3; v WORK_ITEM_STATUS_CANCELLED = 4; (not used) v WORK_ITEM_STATUS_PENDING = 5; (not used) 2. Check TIO_LOGS\console.log to see if the results were received on the Tivoli(r) Provisioning Manager server:
DEBUG [Status Updater] (DmsService.java:546) dms.DmsService: js Application Data: SoftwareModule.Install DEBUG [Status Updater] (TaskTarget.java:124) instance.TaskTarget: Task target id=6403, name=null status=SUCCEEDED
755
3. To log the endpoint DMS polling for jobs and OSGI bundles interaction, you can enable the OSGiAgent log: To debug the OSGiAgent, add the property osgiagent.debug=true in <ep home>\conf\overrides\ agent.properties. The log data is located at C:\osgiAgentLog1.txt. Related links Support information about the scalable distribution infrastructure Recovering from software provisioning problems on page 760 Uninstalling software on page 626
Deploying software troubleshooting checklist

If you have problems deploying software, use the following checklist to help diagnose and troubleshoot your issue. Information for troubleshooting and problem diagnosis: v Identifying the problem v Job processing end-to-end on page 757 v Common device manager service issues on page 758 v Gathering information for IBM Support on page 759
Identifying the problem

Try to identify the problem: v Did you get an error message? Tivoli Provisioning Manager error message IDs are designed to provide you with some information about the source of the error. All Tivoli Provisioning Manager error message IDs consist of 10 alphanumeric characters that uniquely identify the message: A 3-character product identifier A 3-character component or subsystem identifier A 3-digit serial or message number A 1-character type code indicating the severity of the message Check the Messages for information about your specific error message. v Is your issue a deployment engine issue or a scalable distribution infrastructure issue? Deployment engine jobs run immediately and have a deployment request ID number, for example 12345. But scalable distribution infrastructure jobs run based on polling intervals at the agent and therefore are not as easy to track from the Tivoli Provisioning Manager UI. The scalable distribution infrastructure requires the SDI service access point on the Credentials tab and a depot must be available and operational. All virtualization tasks are run using the deployment engine. Most patch management jobs are run using the scalable distribution infrastructure, except on those platforms on which the scalable distribution infrastructure is not available, for example, Solaris. v When you experience an issue deploying software, you first need to identify the source of the issue. If you can identify where the problem occurred, that points you to the component that you need to troubleshoot: Check if the job reached the target computer. If the job reached the target computer, check the target computer logs. At this point, the issue is most likely a common agent issue. If the job did not reach the target computer the issue is normally a device manager service (DMS) issue. Proceed by checking DMS issues. Check what is installed on the target computer by changing directory to /opt/tivoli/ep/runtime/ agent and running
agentcli spbhandler state -n *
756
For more information, see Listing the software catalog . v Check the scalable distribution infrastructure log files for your platform. Log files for deploying software using the scalable distribution infrastructure are available in Log files on page 761. Checking the log files can help you to identify the cause of your problem. v Is your error listed in the deploying software problems list? See Software deployment problems and limitations on page 763 for a list of known scalable distribution infrastructure issues. Review this list after you have identified the component to which the issue applies. v Have you set up the hardware and software correctly? Check the documentation on setting up the scalable distribution infrastructure. v Have you checked the hardware and software prerequisites for your platform? Hardware and software prerequisites on page 547.
Job processing end-to-end

All scalable distribution infrastructure jobs go through a similar processing flow. By understanding the end-to-end flow from job creation to completion, you can better identify the point in the process at which problems occur. An example of the end-to-end process flow for installing a software package block on a group of target computers is as follows: 1. When you click install, the software package block installation job is submitted to the device manager service. Check the consol.log.3 file to view the log and see how this was processed, for example:
va:521) client.JobManagementServiceClient: Submitting JDML job 2010-11-29 17:19:23,537 INFO [Install Software 1638316(2925850) from com.ibm.tivoli.tpm.infrastructure.soa.OSGiSdiTaskDispatcher] (JobManagementServiceClient.java:523) client.JobManagementServiceClient: job.requestId = b83c4c62fc0611dfa7483ad3ceae56da : : 2010-11-29 17:19:33,637 INFO [Install Software 1638316(2925850) from com.ibm.tivoli.tpm.infrastructure.soa.OSGiSdiTaskDispatcher] (JobManagementServiceClient.java:542) client.JobManagementServiceClient: Submitted job to the job management server. Job id is: [129106917338403726]
2. The job is federated for the target computers. Check the tracedms32.log file to view how this step was processed, for example:
11/29/2010 5:35:10.602 com.tivoli.dms.common.DBOperation getPreparedStatement SDIServerThreadPool : 11 INSERT INTO BRANCH_JOB_HISTORY (FEDERATED_JOB_ID, TARGET_DEVICE_NAME, TARGET_DEVICE_CLASS_NAME, TARGET_DEVICE_ID, BRANCH_SERVER_HOSTNAME, BRANCH_JOB_ID, BRANCH _JOB_TYPE, JOB_COMP_STATUS, BRANCH_JOB_COMP_TIME_LONG, BRANCH_JOB_COMPLETION_MSG) VALUES (129106917338403726, BAA3CDE94B54398B97C596C66B77ED69, tpmOSGi , 128015342003392107, u060tpma11.<your_domain>.com-126020498629587685 129106960855003727, JDS_COMMAND , STARTED , 129107011060204191, ?)
11/29/2010 5:35:17.255 com.tivoli.dms.common.DBOperation getPreparedStatement SDIServerThreadPool : 9 INSERT INTO BRANCH_JOB_HISTORY (FEDERATED_JOB_ID, TARGET_DEVICE_NAME, TARGET_DEVICE_CLASS_NAME, TARGET_DEVICE_ID, BRANCH_SERVER_HOSTNAME, BRANCH_JOB_ID, BRANCH_JOB_TYPE, JOB_COMP_STATUS, BRANCH_JOB_COMP_TIME_LONG, BRANCH_JOB_COMPLETION_MSG) VALUES (129106917338403726, BAA3CDE94B54398B97C596C66B77ED69, tpmOSGi , 12 8015342003392107, u060tpma11.<your_domain>.com-126020498629587685, 129106960855003727, JDS_COMMAND , OK , 12910
3. The target computers receive the job and the job is processed. Check the tracedms32.log file to view how this step was processed. 4. The target computers send the results for the job back to DMS. Check the tracedms32.log file to view how this step was processed, for example:
11/29/2010 5:35:17.223 com.tivoli.dms.plugin.syncmldm.SynMLDMDeviceCommunicationManager completeJob SDIServerThreadPool : 9 fire COMPLETE_JOB for DMS DeviceID=tpmOSGi:BAA3CDE94B54398B97C596C66B77ED69 Status=1
5. DMS processes the results for the job and the results are not federated. Check the tracedms32.log file to view how this step was processed, for example:
757
11/29/2010 5:35:17.232 com.tivoli.dms.common.DBOperation getPreparedStatement SDIServerThreadPool : 9 INSERT INTO ACTIVE_JOB_HISTORY (JOB_ID, DEVICE_ID, DEVCLASS_ID, JOB_COMP_STATUS, MESSAGE_KEY, DMS_ID, MESSAGE_PARMS) VALUES (129106960855003727, 1280153420033 92107, 125976661511753217, OK, JDS_COMMAND_EXECUTION_RESULTS, 126020498629587685, ?)
6. DMS federates the results for the job. Check the tracedms32.log file to view how this step was processed, for example,
11/29/2010 5:35:17.255 com.tivoli.dms.common.DBOperation getPreparedStatement SDIServerThreadPool : 9 INSERT INTO BRANCH_JOB_HISTORY (FEDERATED_JOB_ID, TARGET_DEVICE_NAME, TARGET_DEVICE_CLASS_NAME, TARGET_DEVICE_ID, BRANCH_SERVER_HOSTNAME, BRANCH_JOB_ID, BRANCH _JOB_TYPE, JOB_COMP_STATUS, BRANCH_JOB_COMP_TIME_LONG, BRANCH_JOB_COMPLETION_MSG) VALUES (129106917338403726, BAA3CDE94B54398B97C596C66B77ED69, tpmOSGi , 12 8015342003392107, u060tpma11.<your_domain>.com-126020498629587685, 129106960855003727, JDS_COMMAND , OK , 129107011725504197, ?)
Identify the following components in the log files to determine where the issue occurred: v The target computer IP address v The agent GUID v The Tivoli Provisioning Manager DCM device ID v The Tivoli Provisioning Manager task ID v The Tivoli Provisioning Manager job ID v v v v v The The The The The Tivoli Provisioning Manager job request ID Tivoli Provisioning Manager deployment request ID DMS federated job ID DMS branch job ID DMS results sent from the target computers
v The DMS device ID v The SyncML session ID
Common device manager service issues

Use the information in the following table to troubleshooting common component-specific issues:
Table 130. Device manager service issues Component device manager service Potential issues Verify that DMS is installed and configured correctly, as follows: v Enter https://<fullyQualifiedHostNameOfServer>:9045/dmserver/ TraceServlet?trace=set in a browser. It should return a SUCCESS! message. v Check the log files at C:\IBM\tivoli\tpmfsw\tioprofile\logs\server1 and identify if there are errors in the DMSMsg1.log and TraceDMS1.log files. To change the polling interval for the device manager service: v For WebSphere Application Server, open the WebSphere Application Server Administration console, click Environment > Websphere Variables > server1 and change the DMS_FEDERATED_AGENT_POLL_INTERVAL_IN_MINUTES property. The restart Tivoli Provisioning Manager.
758
Table 130. Device manager service issues (continued) Component Potential issues For DMS polling on target computers, if jobs are not reaching the target computer or if the agent is not polling, you might need to change the polling. To view and change the device manager service client configuration and polling, complete the following: 1. Install the osgiagentservlet.jar file using the agentcli command: agentcli deployer install file:C:\bundles\osgiagentservlet.jar If the installation completed successfully, you will see a message similar to the following: The file:C:\bundles\osgiagentservlet.jar bundle was successfully installed. 2. Start the osgiagentservlet.jar file using the agentcli command: agentcli deployer start file:C:\bundles\osgiagentservlet.jar If the startup is successful, you will see a message similar to the following: BTC3146I The file:C:\bundles\osgiagentservlet.jar bundle was successfully started. 3. Use a browser that is in the same system as the agent to navigate to http://localhost:21080/osgiagentservlet. The OSGi agent control panel is displayed.
Gathering information for IBM Support

If you cannot identify the source of your problem and you need to contact IBM Customer Support, you need to collect some system data before you call IBM Customer Support. Providing this required information enables IBM Customer Support to identify the source of your problem faster. Follow the instructions in the Collect Data document to collect information that you will need when you contact IBM Customer Support. Before contacting IBM Support, use the IBM ISA Lite tool to gather information about your configuration and environment. For more information, see the following documents: v IBM Support Assistant Introduction v v Collecting data with IBM Support Assistant Lite Collecting data with IBM Support Assistant
Review the following table for information that you need to provide to IBM Customer Support for deploying software jobs.
Table 131. Information required by IBM Support for some common issues Job where issue occurred Scan and Inventory (hardware and software) Compliance scan Patch deployment Required information Collect the CIT logs. Invoke the CIT scanner subagent to scan the system. For information about how to collect the CIT logs, see Log files for Common Inventory Technology. Collect the log file. For information about the log files, see Compliance log file locations. See the patch management checklist for a list of the items you need to collect for patch management jobs Patch management troubleshooting checklist on page 992.
759
Table 131. Information required by IBM Support for some common issues (continued) Job where issue occurred SPB installation Required information v CASservice.zip logs. For information about how to collect this, see Collecting target computer logs on page 765. v For complex issues, you can increase the trace level, as described in Tracing software package block installation errors.
Recovering from software provisioning problems

The following tables list software provisioning problems and how you can resolve them.
Table 132. Recovering from software resources problems Step where the problem occurs Uninstall software resource Upgrade software resource Resolving the problem Check errors in the workflow log. Check errors in the workflow log. Log files SoftwareInstallation.Uninstall workflow log SoftwareResource.Upgrade workflow log
Table 133. Recovering from software products problems Step where the problem occurs Add image Distribute software product Uninstall software product Unpublish/publish software product Install software product Import software product Resolving the problem Check Tivoli Provisioning Manager console log. Check errors in workflow log. Check errors in workflow log. Check errors in workflow log. Check errors in workflow log. Check Tivoli Provisioning Manager console log. Check errors in workflow log. Log files %TIO_LOGS%\console on the server SoftwareModule.DistributeInstallable workflow log SoftwareModule.Uninstall workflow log SoftwareInstallable.UpdatePublish workflow log SoftwareModule.Install workflow log v %TIO_LOGS%\console on the server v FileRepository.PutFile workflow log v FileRepository.RemoveFile workflow log Add SRT Check error message in user interface.
Table 134. Recovering from software stacks problems Step where the problem occurs Install software stack Add image Clone stack Resolving the problem Check errors in workflow log. Check Tivoli Provisioning Manager console log. Check error message in user interface. Check Tivoli Provisioning Manager console log. Log files SoftwareModule.Install workflow log %TIO_LOGS%\console on the server %TIO_LOGS%\console on the server
760
Table 134. Recovering from software stacks problems (continued) Step where the problem occurs Uninstall software Add SRT Add stack entry Resolving the problem Check errors in workflow log. Check error message in user interface. Check error message in user interface. Log files SoftwareModule.Uninstall workflow log
Table 135. Recovering from file problems Step where the problem occurs File distribute File publish Resolving the problem Check error message in user interface. Check Tivoli Provisioning Manager console log. Check errors in workflow log. File unpublish Check error message in user interface. Check errors in workflow log. Table 136. Recovering from agent installation problems Step where the problem occurs Common agent installation Windows update agent installation Resolving the problem Check errors in workflow log. Check errors in workflow log. Log files Install_Agent workflow log SoftwareModule.Install workflow log v SoftwareInstallable.UpdatePublish workflow log v %TIO_LOGS%\console on the server File.UpdatePublish workflow log Log files
Table 137. Recovering from patches problems Step where the problem occurs Patch installation Windows update agent installation Patch distribution Patch uninstallation Patch publishing Patch unpublishing Resolving the problem Check errors in workflow log. Check errors in workflow log. Check errors in workflow log. Check errors in workflow log. Check errors in workflow log. Check errors in workflow log. Log files SoftwareModule.Install workflow log SoftwareModule.Install workflow log SoftwareModule.DistributeInstallable workflow log SoftwareModule.Uninstall workflow log SoftwareInstallable.UpdatePublish workflow log SoftwareInstallable.UpdatePublish workflow log
Log files
The following are common troubleshooting problems that you might encounter and how you can resolve them. v Recovering from software resource problems v Recovering from software product problems v Recovering from software stack problems v Recovering from file problems
761
v Recovering from agent installation problems v Recovering from patch problems

Table 138. Recovering from software resource problems Step where the problem occurs Uninstall software resource Upgrade software resource Resolving the problem Check errors in the workflow log Check errors in the workflow log Log files SoftwareInstallation.Uninstall workflow log SoftwareResource.Upgrade workflow log
Table 139. Recovering from software product problems Step where the problem occurs Add image Distribute software product Uninstall software product Unpublish/publish software product Install software product Import software product Resolving the problem Check Tivoli Provisioning Manager console log Check errors in workflow log Check errors in workflow log Check errors in workflow log Check errors in workflow log Check Tivoli Provisioning Manager console log Check errors in workflow log Log files %TIO_LOGS%\console on the server SoftwareModule.DistributeInstallable workflow log SoftwareModule.Uninstall workflow log SoftwareInstallable.UpdatePublish workflow log SoftwareModule.Install workflow log %TIO_LOGS%\console on the server FileRepository.PutFile workflow log FileRepository.RemoveFile workflow log Add SRT Check error message in user interface
Table 140. Recovering from software stack problems Step where the problem occurs Install software stack Add image Clone stack Resolving the problem Check errors in workflow log Check Tivoli Provisioning Manager console log Check error message in user interface. Check Tivoli Provisioning Manager console log Uninstall software Add SRT Add stack entry Check errors in workflow log Check error message in user interface Check error message in user interface SoftwareModule.Uninstall workflow log Log files SoftwareModule.Install workflow log %TIO_LOGS%\console on the server %TIO_LOGS%\console on the server
Table 141. Recovering from file problems Step where the problem occurs File distribute Resolving the problem Check error message in user interface Log files
762
Table 141. Recovering from file problems (continued) Step where the problem occurs File publish Resolving the problem Check Tivoli Provisioning Manager console log Check errors in workflow log File unpublish Check error message in user interface. Check errors in workflow log Table 142. Recovering from agent installation problems Step where the problem occurs Common agent installation Windows update agent installation Resolving the problem Check errors in workflow log Check errors in workflow log Log files Install_Agent workflow log SoftwareModule.Install workflow log Log files SoftwareInstallable.UpdatePublish workflow log %TIO_LOGS%\console on the server File.UpdatePublish workflow log
Table 143. Recovering from patch problems Step where the problem occurs Patch installation Windows update agent installation Patch distribution Patch uninstallation Patch publishing Patch unpublishing Resolving the problem Check errors in workflow log Check errors in workflow log Check errors in workflow log Check errors in workflow log Check errors in workflow log Check errors in workflow log Log files SoftwareModule.Install workflow log SoftwareModule.Install workflow log SoftwareModule.DistributeInstallable workflow log SoftwareModule.Uninstall workflow log SoftwareInstallable.UpdatePublish workflow log SoftwareInstallable.UpdatePublish workflow log
Software deployment problems and limitations

Common agent problems

If you encounter problems with the common agent, use the information provided in this documentation to diagnose and troubleshoot the problems. This section will help you resolve problems with the common agent. Agent or depot upgrade fails on an endpoint with error messages in workflow: Symptoms An agent or depot upgrade fails on an endpoint with error messages in workflow TivoliCommonAgent_Upgrade_CheckUpgradeStatus. Causes
763
When the system is on IPv4, the nonstop services stop working when both IPv4 and IPv6 are configured in the /etc/hosts file. The agent nonstop process binds for localhost and if there are messages such as "agent stopped listening on 9510" or "BTC7849E Unable to start a nonstop service" in $TCA_HOME/ep/runtime/agent/logs/install/epInstall.log. Resolving the problem If the system is on IPv4, comment out the line ::1 local host in /etc/hosts. Determining the version of the currently installed common agent: Resolving the problem To determine the version of the currently installed common agent, run the script endpoint.bat or the endpoint.sh on the target computer, depending if Windows or UNIX is installed on the target computer. The location of the script is $CA_HOME/ep/runtime/agent/bin. The output of the command indicates the version, major release, minor release (modification level), and fix pack level of the common agent. It also includes a build identifier. Collecting common agent diagnostic information: The service command automatically collects diagnostic information into a file named CASservice.zip which can then be sent to IBM Software Support. To run the service command to collect diagnostic information: 1. Open a command window. 2. Change to the following directory: <agent_install>runtime/agent/toolkit/bin/ 3. Run the script for your operating system: v
Windows
service
UNIX Linux service.sh v The script creates an archive file named CASservice.zip file in the Install directory.
If you have more than one common agent on a managed system, run the tool in the Install directory of the common agent for which you want to capture diagnostic information. Note: If you plan to send multiple CASservice.zip files to IBM Software Support, rename the files so that they each have unique names. Verifying that the common agent is running: Symptoms You need to know whether the common agent is installed and started correctly. Resolving the problem v Check the msgAgent.log file in the agent_installdir\logs directory for any errors that might have occurred during installation. v On a Windows target computer, you can open the Windows Services control panel and look for a service called IBM Tivoli Common Agent. Make sure that the service is started. v At a command prompt, run the following command from the common agent installation directory: Windows agentcli.bat connector alive
764
UNIX or Linux ./agentcli.sh connector alive If the agent is running, the message The agent is alive. is displayed. If the agent is not running, the message CLI command failed. A communication error occurred. Verify that the agent is registered and active on port agent_port is displayed. Collecting target computer logs: When common agent problems occur on a target computer, you can use the TCA_Collect_Logs.wkf workflow to collect logs from the target computer. When common agent or subagent problems occur on a target computer, you can use the TCA_Collect_Logs.wkf workflow that is provided with Tivoli Provisioning Manager version 5.1.0.2 (Fix Pack 2) to collect logs from the target computer. In the event of a common agent or subagent problem, you can either schedule a task using this workflow or run the workflow to collect the target computer logs. The workflow provides information regarding the target computer on which the common agent is running. For each target computer that the workflow is run against, the %TIO_LOGS%\tivolicommonagent directory ($TIO_LOGS/tivolicommonagent for UNIX or Linux) on the Tivoli Provisioning Manager server receives an archive (.zip or .tar) with the deviceID_IDnumber_TimeStamp_actualTimeStamp_CASservice.zip/tar file name. The archive contains all the startup and console logs for that target computer, and can be used for troubleshooting or sent to IBM Software Support for analysis. Log files for the common agent: Symptoms The following table lists the logs created during the installation and uninstallation of the common agent. The locations of the logs are v v v
Windows HP UX AIX
Linux Solaris
/opt/tivoli/ep
/usr/tivoli/ep
Table 144. Runtime logs for the common agent Log File (located in $CA_HOME/logs/) error-log-0.xml error-log-1.xml, error-log-2.xml error-log-3.xml nonstop.log nonstopbundle.log trace-log-0.xml trace-log-1.xml, trace-log-2.xml, or trace-log-3.xml Description Error messages generated during agent run time.
The log of the nonstop process. The log for the nonstop bundle. Trace messages generated during agent run time.
The following table lists the runtime logs for the common agent and subagents.
Table 145. Installation logs for the common agent Log File $CA_HOME/runtime/agent/logs/agentcli.log.0 Description The log for agent command line.
765
Table 145. Installation logs for the common agent (continued) Log File $CA_HOME/runtime/agent/logs/install/epInstall.log $CA_HOME/runtime/agent/logs/install/ epInstallStatus.log Description Processing information collected during common agent installation. Return codes for the installation of the common agent.
$CA_HOME/runtime/agent/logs/install/epPreinstall.log Processing information collected before the common agent installation has started. $CA_HOME/runtime/agent/logs/install/epUnInstall.log $CA_HOME/runtime/agent/logs/install/ epUnInstallStatus.log AgentCliErr.log* AgentCliOut.log* InstallNonstopUtilErr.log* InstallNonstopUtilOut.log* lwiJavaHomeErr.log lwiJavaHomeOut.log LwiStatusErr.log* LwiStatusOut.log* SetFileSecurityErr.log* SetFileSecurityOut.log* tivGuidInstallErr.log tivGuidInstallOut.log WindowsInstallUtilErr.log* WindowsInstallUtilOut.log* winTivGuidInstall.log Processing information collected during common agent uninstallation. Return codes for the uninstallation of the common agent. Logs for steps run in the installation or uninstallation process. A * symbol indicates that there might be more than one instance of the log file with an associated timestamp instead of the * symbol.
Useful commands: A list of common agent commands, including commands for uninstalling and logging. Symptoms Uninstall the common agent and subagents. 1. Change to the following directory: v v
Windows UNIX
: C:\Program Files\tivoli\ep\_uninst
Linux
: /opt/tivoli/ep/_uninst
AIX : /usr/tivoli/ep/_uninst v 2. Run the following command
Windows
uninstall.exe -silent -W CASInstall.forceUninstall=true
UNIX
Linux
./uninstall -console
List the bundles and their state 1. Change to the following directory: v v
Windows UNIX
: C:\Program Files\tivoli\ep\runtime\agent\bin
Linux
: /opt/tivoli/ep/runtime/agent/bin
766
2. Run the following command: v

Windows
agentcli deployer list bundles state
UNIX
Linux
./agentcli.sh deployer list bundles state
Retrieve all of the common agent logs 1. Change to the following directory: v
Windows
: C:\<agent_install_directory>\runtime\agent\toolkit\bin
UNIX Linux : <agent_install_directory>/runtime/agent/toolkit/bin/ v 2. Run the following command:
Windows
service.bat
UNIX
Linux
service.sh
The CASservice.zip file will be created in the runtime/agent directory. Common agent installation: Cannot connect to the target using RXA: Symptoms Agent Installation error message occurs during install of common agent on a target system from Tivoli Provisioning Manager 7.1. The install fails with the error "COPCOM494E Cannot connect to the endpoint using RXA". Causes The Agent Installation error can be caused by the following: 1. Ports are blocked on the target system. Resolving the problem 1. Check the target to establish that the ports are open. Installing the common agent and the agent manager is not supported: Symptoms The common agent and the agent manager cannot be installed Causes Installing the common agent on the provisioning server, where the agent manager is also installed, is not supported. Resolving the problem Manually uninstall the common agent. The agent software stack installation fails: Symptoms
767
The installation of the Tivoli Common Agent Stack is run from Go To > Deployment > Software Management > Software Product Installation. The install fails with: AgentInstallException exception occurred. The exception was caused by the following problem: Agent installation failure. Agent install return code log file contents: The response file parameter CASInstall.RegistrationPassword is not specified. Causes Tivoli Common Agent installation is not supported via direct stack install from the Software Product Installation menu. Resolving the problem Run the Tivoli Common Agent install through one of the supported mechanisms. Common agent reinstallation failure on Windows: Restart the computer before you reinstall the common agent to ensure that all services marked for deletion are actually deleted. Symptoms You cannot reinstall the common agent on Windows. Causes The Windows computer was not restarted after the previous Tivoli common agent was uninstalled. In some cases, if Windows cannot delete a service, it will mark that service for deletion on the next restart of the computer. In these cases, the common agent installer will not be able to install the common agent because the installer detects the previous common agent which, although marked for deletion, still exists until the next restart. Resolving the problem Restart the computer before you reinstall the common agent. Installing the common agent on Security-Enhanced Linux: This section describes how to install the common agent on Security-Enhanced Linux. Before you begin Check if the Linux security is on by running the following command at a Linux command line:
getenforce
If you obtained an enforcing as an output, it means that the security is on. You can also check the security status in the configuration file in the /etc/selinux/config directory. To install the common agent on Security-Enhanced Linux: Procedure 1. Switch off the security enhancement using either of these commands: setenforce 0
768
or echo 0 > /selinux/enforce 2. Install the common agent. 3. Turn on the security enhancement back using either of these commands: setenforce 1 or echo 1 > /selinux/enforce 4. Restart the computer. What to do next The common agent is now installed. Common agent installation failure due to duplicated GUID: Common agent installation fails when the Tivoli Global Unique Identify (Tivoli GUID) )is the same on different machines. Symptoms The common agent installation fails with the error "Agent installation failure. Agent install return code log file contents: Success". In the workflow logs you can see that the GUID created for the target machine is the same as the GUID of a previously installed machine. Causes You cannot have different machines with the same Tivoli GUID. Resolving the problem Uninstall the common agent and remove the GUID from the target machine, as explained in Uninstalling the common agent on page 669. To prevent this error during the common agent installation on the target machine, ensure that the common agent is not installed and the Tivoli GUID is removed from the computer that you are capturing the image from. Error during Tivoli GUID installation: Errors will occur if Windows Installer is turned off when you install the common agent. Symptoms On Windows, Tivoli GUID fails to install properly and the following error is given in the runtime/agent/logs/guid_install.log log file:
Failed to connect to server. Error: 0x80070422
An additional error message might also be given in the same file:

Failed to grab execution mutex. System error 258
Causes If you install the common agent, the installer also installs the Tivoli GUID component. On Windows platforms, the Microsoft Windows Installer is responsible for that. For this reason, the Windows Installer
769
system service cannot be turned off, or else the first error will be caused. Moreover, when installing Tivoli GUID there cannot be any other MSI installations in progress, which is the cause of the second error. Resolving the problem Make sure that the Windows Installer system service is enabled and all other MSI installation processes are finished before running the common agent installer. Cannot install common agent on Solaris: Due to a known limitation, you cannot install the common agent on Solaris if you are using certain locales. Symptoms You cannot install the common agent on a Solaris computer system. Causes Due to a known limitation with Java Runtime Environment (JRE) for Solaris 1.3.1, you cannot install the common agent on a Solaris computer system if you are using any of the following locales: -en_US.UTF-8 -de_DE.UTF-8 -fr_FR.UTF-8 -it_IT.UTF-8 -es_ES.UTF-8 Resolving the problem Set the locale of the Solaris system to a non-UTF-8 locale to perform the installation. Use the export LANG command to set the locale. For example, run the command export LANG=fr_FR.ISO8859-1 to change the locale to fr_FR.ISO8859-1. After the installation is complete, reset the system to the original locale. You can use common agent commands to check and change the locale: 1. Ensure that the common agent is running. 2. Change to the directory where the common agent is installed. 3. Run the following command to check the current locale setting:
agentcli logmgr getlocale
4. To set the locale, run the following command:

agentcli logmgr setlocale language region
where language is a two-letter lowercase code defined by ISO-639 and region is a two-letter uppercase code defined by ISO-3166. For example, to set the location to United States English, use the following command:
agentcli logmgr setlocale en US
Tivoli Common Agent installation fails on Solaris SPARC target computers: Installation will fail if the target computers are missing required SUNW packages. Symptoms Tivoli Common Agent installation fails on Solaris SPARC target computers with the following error message:
770
COPDEX123E A AgentInstallException exception occurred. The exception was caused by the following problem: Agent failed to install with install error: The installation process was cancelled by the user.
Causes The target computers are missing required SUNW packages, such as SUNWxcu4. Resolving the problem Review the required packages for Solaris target computers listed in the Requirements for Solaris targets topic in the Tivoli Provisioning Manager Information Center and ensure that all packages are installed. You can verify this by running the following command on the Solaris target computers:
pkginfo -i | grep <package-name>
Common agent installation failure on Red Hat 5: The firewall needs to be disabled before installing the common agent. Symptoms Common agent installation fails on Red Hat 5 with the following error message:
COPDEX123E A AgentInstallException exception occurred. The exception was caused by the following problem: Agent failed to Install with install error: The installation process was cancelled by the user.
In the workflow logs, the following error is reported by Tivoli Provisioning Manager:
std err: Log: common_agent_1.4.2.1_200902171611_linux.tar has been extracted into /tmp/tcatemp Log: common_agent_1.4.2.1_200902171611_linux.tar has been removed from /tmp/tcatemp Log: agentTrust.jks copied to: /tmp/tcatemp/cert No Java Runtime Environment (JRE) was found on this system
Causes Red Hat 5 has the Security-Enhanced Linux firewall utility enabled by default. This firewall prevents Tivoli Provisioning Manager from installing the common agent. Note: You can manually check if the firewall is enabled by entering the getenforce command at a Linux command line. If enforcing is returned, it means the firewall is enabled. Resolving the problem The firewall needs to be disabled before installing the common agent. There are two ways to do this: v Switch off security enhancement by entering the following command:
setenforce 0
v Edit the configuration file on the Linux computer. The file is found in the /etc/selinux/config directory. In the file, find this line:
SELINUX=enforcing
Modify the line into the following:

SELINUX=disabled
Save the file and restart the computer.
771
With the firewall disabled, the common agent can now be installed. After the installation has completed, you can turn the firewall back on. v If you disabled the firewall using the setenforce 0 command, you can re-enable it by entering setenforce 1 in the command line. v If you disabled the firewall by modifying the configuration file, you can re-enable it by editing the configuration file again and setting the SELINUX variable back to enforcing. Remember to restart the computer to apply these changes if you use this method. Common agent installation fails when using commands: These commands might fail if the /tmp directory is full. Symptoms An installation on a UNIX operating system fails when using copy or put file commands. Causes The /tmp directory or device might be full on the UNIX computer. The common agent installation copies files to the /tmp/tcatemp directory. Resolving the problem Run the df -k/tmp command to determine if the disk is full. If the disk is full, create the necessary space required in order for the installation to succeed. Common agent reinstallation failure on Windows: Restart the computer before you reinstall the common agent to ensure that all services marked for deletion are actually deleted. Symptoms You cannot reinstall the common agent on Windows. Causes The Windows computer was not restarted after the previous Tivoli common agent was uninstalled. In some cases, if Windows cannot delete a service, it will mark that service for deletion on the next restart of the computer. In these cases, the common agent installer will not be able to install the common agent because the installer detects the previous common agent which, although marked for deletion, still exists until the next restart. Resolving the problem Restart the computer before you reinstall the common agent. UAC not supported for common agent installation on Windows 7 target computers: On Windows 7 computers, the default level of the UAC mechanism for the Tivoli Common Agent installation is not supported. You cannot use the default level of the Windows user access control mechanism for installing the Tivoli Common Agent on Windows 7 target computers. Symptoms
772
The Tivoli Common Agent installation fails. You cannot use the default level of the Windows user access control mechanism for Windows 7 target computers. Causes There are four security levels for Windows UAC on Windows 7 computers. Level 3, which is the default level, does not allow Tivoli Common Agent to be installed. Environment Tivoli Provisioning Manager v7.2 and Windows 7 target computers. Resolving the problem To resolve this issue, disable Windows user access control on Windows 7 target computers. Installation does not create the tpm_default.xml file: Installation does not create the tpm_default.xml file Symptoms The stand-alone agent installation on Windows using the LocalSystem account does not create the tpm_default.xml file. It does not copy the getVersionBuild.bat file to the <AGENT_INSTALL_DIR>/ep/ runtime/agent/bin directory. Causes The stand-alone agent installation uses the LocalSystem account. When the service runs, it cannot access the AppData environmental variable. Resolving the problem Do not install the stand-alone agent using the Windows LocalSystem. SSLHandshakeException error when installing: This error will occur if signer certificates do not match. Symptoms You receive an SSLHandshakeException exception while installing a resource manager or common agent. Causes The signer certificate on the resource manager or common agent do not match the certificates offered by the agent manager server when the two computers attempt to set up a secure SSL connection. If the certificates do not match, the resource manager or common agent cannot determine whether it is communicating with the correct agent manager server. Resolving the problem 1. If you just created new certificates for the agent manager server, make sure that the agent manager server was restarted after the new certificates were created. The agent manager server will not start using the new certificates until it restarts.
773
2. Make sure that the resource manager or the common agent have a copy of the current truststore file for the agent manager server. The truststore file contains the signer certificate for the agent manager server. A simple way to do this is to copy the file to the resource manager or the common agent again. 3. Try the program that failed again. Common agent installation failure due to no stack: The common agent installation fails unless the common agent stack is selected. Symptoms The common agent installation from a Server Provisioning application fails unless the common agent stack is selected as the software to install. After installing version 1.4.2.1 of Tivoli Common Agent, a TCA-1.4.2.1 entry is added to the installed software list on the target computer, but the software is not actually installed. Causes The common agent does not install completely unless the software stack is used. Resolving the problem Use the Tivoli Common Agent Stack as the selected software, instead of Tivoli Common Agent 1.4.2.1, when you install the common agent from the Server Provisioning application. Installing common agent using sudo fails: Symptoms When installing the common agent on a target computer using sudo, the installation fails with the following error:
COPDEX040E An unexpected deployment engine exception occurred: class java.lang.RuntimeException:java.lang.RuntimeException: server indicated an error: scp: /tmp/tcatemp/common_agent_1.4.2.1_201003080501_linux.tar: Permission denied.
Causes The non-root user does not have permission to write to the /tmp/tcatemp directory because it was created by a different user such as root. This situation might occur if the target has been configured to run workflow commands using sudo. Installing the common agent using sudo does not require configuring the target computer to perform workflow commands using sudo. Resolving the problem To resolve the issue, perform the following steps: 1. Delete the /tmp/tcatemp directory, using sudo to obtain root permissions. For example, run the command:
sudo rm -rf /tmp/tcatemp
2. Ensure that the service access point of the target computer does not have any variables with names starting with "sudoers". If such variables exist, delete or rename the variables. 3. Install the common agent using sudo by following the steps described in Installing the common agent on page 570. Common agent installation fails in directory with DBCS characters:
774
Symptoms Installing into a directory that has double byte character set (DBCS) characters in its path causes the common agent installation to fail. Causes The nondefault installation path containing DBCS characters becomes corrupted and the agent installation fails. Resolving the problem Do not install into a directory that has DBCS characters in its path. The installation path can only contain ASCII characters. Tivoli Common Agent installation fails with invalid password: The installation will fail if the password on the target computer contains a double quotation mark. Symptoms The installation of the common agent on a target computer fails. Causes The password for the common agent on the target computer contains a double quotation mark. The double quotation mark is not a valid character. Resolving the problem Do not include double quotation marks in the password. Tivoli Common Agent installation fails if agent is already installed: This will happen if the target computer already had an agent installed that is not the currently supported agent version. Symptoms The installation of the common agent returns the following error:
The response file parameter CASInstall.InstallType contains an unsupported value or is not specified. The value must be install or upgrade.
Causes The target computer already had an agent installed that is not the currently supported agent version. Resolving the problem Uninstall the current agent from the target computer, or modify the software configuration to use an alternative installation location. The configurations can be found on the Tivoli Common Agent Stack software catalog entry. The software configuration can also be modified for a particular installation using the Advanced options on the agent installation user interface. Common agent files deleted after installation:
775
Files are marked for deletion upon restart when the common agent was uninstalled. These files are deleted on restart even if they were replaced by a reinstall. Symptoms Files from a recently installed Tivolicommon agent are deleted after the computer is restarted. Causes In some cases, Windows will mark files for deletion upon the next restart if it cannot delete those files during the uninstallation process. If a user uninstalls Tivoli Common Agent and Windows cannot delete all the files immediately, it will mark them for deletion upon restart. If the user installs another version of the common agent on that computer without restarting, the files that were marked for deletion will be deleted upon the next restart of that computer. Resolving the problem Try to uninstall the Tivoli common agent. If the uninstall fails, follow these steps: 1. Remove the common agent service from the Windows Registry using one of the following methods: v Method 1 (Recommended): Use the common agent utility to remove the common agent service.
agent_installdir\InstallUtil -uninstallservice -service service_name
where service_name is the name of the service listed in the Windows Services control panel. The default service name is IBMTivoliCommonAgent0. v Method 2: Use the Regedit program to delete the service from the Windows Registry. 2. Remove the common agent entry from the common agent registry (located in %ProgramFiles%\tivoli\ ep.reg). You might have more than one entry if you have more than one common agent on that computer. Remove only the entry for this common agent, which you can identify by its installation location. 3. Delete the installation directory. 4. Restart the computer. 5. Reinstall the common agent. Registration errors: Common agent cannot register on HP-UX: The logs show a Java exception #231628960 error, which means that the GUID shared library cannot be read. Symptoms When the common agent is installed on HP-UX, the agent ID cannot be read, preventing the common agent from registering. This problem is intermittent. The following information is written to the log:
java.lang.Exception: 231628960 at com.tivoli.agentmgr.resources.GUIDHelper.getHostId (GUIDHelper.java:53) at com.tivoli.agent.id.IDServiceImpl.getEndpointId (IDServiceImpl.java:99) at com.tivoli.agent.id.IDServiceImpl.checkForOEMInstall (IDServiceImpl.java:60) at com.tivoli.agent.id.IDActivator.start(IDActivator.java:54) at com.ibm.osg.smf.BundleContext$1.run(BundleContext.java:1300) at java.security.AccessController.doPrivileged(Native Method) at com.ibm.osg.smf.BundleContext.start(BundleContext.java:1282) at com.ibm.osg.smf.Bundle.startWorker(Bundle.java:709)
776
at com.ibm.osg.smf.Bundle.start(Bundle.java:655) at com.tivoli.agent.system.SMFLauncher.startSMF(SMFLauncher.java:240) at com.tivoli.agent.system.SMFLauncher.main(SMFLauncher.java:94) Caused by: 231628960 at com.tivoli.srm.guid.GuidOFactory.<init>(GuidOFactory.java:79) at com.tivoli.agentmgr.resources.GUIDHelper.getHostId (GUIDHelper.java:48) ... 10 more
Causes Java exception #231628960 means that the GUID shared library cannot be read. Resolving the problem Uninstall the common agent and then install it again. If the problem persists, remove the agent ID and add it again with using the following steps: 1. Run the command swremove TIVGUID. 2. From the common agent installation image in the GUID directory, run installguid.sh. Cannot register target computers in firewall: The target computers cannot complete their registration with the provisioning server when the firewall toolkit is used. Symptoms You cannot register target computers with the provisioning server in a firewall environment. This issue has been described in an environment where a firewall is used between the provisioning server and the target computers. The updated firewall toolkit from Tivoli Provisioning Manager 5.1.0.1 (Fix Pack 1) has been used. This behavior has been consistently described in firewall environments, and occasionally in non-firewall environments. Causes The target computers cannot complete their registration with the provisioning server when the firewall toolkit is used. The process appears to work properly up to the final step when the target certificate is passed back to the target computer. The certificate is not created on the target computer (only three files are created in the cert directory on the target, namely agentTrust.jks CertificateRevocationList, and pwd). When the provisioning server attempts to create a target, it is able to connect to the target, install the common agent binary files, and start the agent. The agent is able to communicate back to the provisioning server, but the final certificate file (target key file) is not created on the target computer. Resolving the problem To avoid this issue, the following requirements must be met: v Port 9510 is required for TCA_PingAgent. v RXA ports (445 TCP and 139 RPC) are enabled. v Use the standalone agent when a firewall is between the provisioning server and the target computers. Common agent security error during registration:
777
Security errors will occur if system clock on the agent system does not match the clock on the agent manager computer. Symptoms A security error (for example, SSLHandshakeException) occurs when: v The common agent attempts to register with the agent manager. v The common agent is contacted by another entity (for example, a resource manager) already registered with the agent manager. Causes The system clock on the agent system does not match the clock on the agent manager computer. The agent manager compares the clocks in Universal Time Coordinated (UTC). Resolving the problem Reset the system clock on the agent system to match the clock on the agent manager computer. Common agent registration and uninstallation errors on Windows: Restart the computer to ensure that the endpoint.properties file is deleted before reinstalling the common agent. Symptoms The endpoint.properties file is truncated (approximately 6-8 lines long instead of approximately 20). The common agent cannot register and cannot be uninstalled. Causes Windows was not restarted after uninstalling the common agent. This problem can occur in the following situation: 1. The user tries to uninstall the common agent, but the common agent uninstaller on Windows cannot delete the endpoint.properties file if it is locked or in use. It therefore queues deletion for the next restart. 2. The user installs a new common agent in the same directory, which creates a new endpoint.properties file that must not be deleted, but the file is still queued for the next restart. 3. When the user reboots the computer, the endpoint.properties file is deleted from the newly installed common agent. 4. When the common agent starts, it tries to register and creates a truncated version of the endpoint.properties file. The common agent cannot work properly. It cannot register because the port value is missing in endpoint.properties file, resulting in a parsing error. It also cannot be uninstalled because the uninstaller is looking for values in the endpoint.properties file that are not there. Resolving the problem Ensure that the endpoint.properties file is deleted when you uninstall the Windows common agent. You need to restart the computer before reinstalling the common agent in the original installation directory. Reregistering a common agent: You might want to perform this operation if you are experiencing multiple connectivity or registration problems which do not have obvious causes.
778
Various connectivity and registration problems can be resolved by forcing the common agent to reregister with the agent manager. You might want to perform this operation if you are experiencing multiple connectivity or registration problems which do not have obvious causes. Two methods are available for performing this operation: 1. Change directory to agent_installdir/runtime/agent/bin. 2. Run the agentcli.sh/bat security renew cert command. You can also perform the following steps: Procedure 1. Stop the common agent. 2. Delete the contents of agent_installdir/runtime/agent/cert. 3. Verify that the agent.ssl.truststore.download parameter is set to true in file endpoint.properties located in agent_installdir/runtime/agent/config. 4. Restart the common agent. Cannot register common agent or resource manager: This can happen if configuration regarding the agentTrust.jks is incorrect. Symptoms You cannot register either the common agent or the resource manager. Causes This can happen if you select the installation option to provide a copy of the agentTrust.jks truststore file to the common agent or resource manager, and then point to the wrong file. For example, you might point to the agentTrust.jks file in the cert directory of the installation image instead of pointing to the real file on a network share. Another possible cause is that you pointed to the agentTrust.jks file of your production environment when the common agent or resource manager is connecting to a test environment. Resolving the problem 1. Copy the agentTrust.jks file from the AM_HOME/certs directory on the agent manager server to the CA_HOME/certs directory on the common agent. 2. Restart the common agent. Upgrade errors: Common agent upgrade failure: Symptoms The upgrade of the common agent fails with a message like the following message: COPDEX123E A FailureLogStatus exception occurred. The exception was caused by the following problem: TCA upgrade exited with status: FAILURE. Check the log file C:\DOCUME~1\ADMINI~1\ LOCALS~1\Temp\TCA_upgrade_1.4.2.1\TCA_Install_1.0.log_13205. Causes One of the directories used by the common agent is being accessed by another user or process. During the upgrade, the process backs up some directories. If the directory or file is in use or locked, the process cannot back up the required files, causing the upgrade to fail.
779
Resolving the problem Check the log file indicated in the error message for error code 65. This error code indicates that the directory is being accessed by another user or process. Ensure that no user or process is accessing the common agent directories or files. Installing up-level common agent over existing common agent level: Symptoms an agent installation error message occurs during installation of the common agent on a target computer. The installation fails because the specified common agent ports are already in use and port conflicts might occur. The common agent might not start or operate correctly. Causes The Agent Installation error can be caused by another version of the common agent that is already present on the target computer. Note: Having an agent installed is not the only reason one might see such an error as IBM has not registered any of the agent ports for exclusive use. Any application might cause this error. It most likely is another agent, but might be something else. Resolving the problem Check the target to see if another version of the common agent already exists. Uninstall the previous version of the common agent before attempting to install the new version. For more information, see Manually uninstalling the common agent. The computer name is not updated after the common agent is upgraded: After upgrading the common agent, the correct host name (related to the NIC used for communication, if present) is not registered in the data model. Symptoms After upgrading the common agent, the computer name is not updated. If there was already a system with a name in the data model, the name does not change on subsequent discoveries, even if the host name reported by the agent changed. Causes The computer name is not updated Resolving the problem To register the new computer name in the data model, delete the computer from the data model and run the discovery. This operation brings in the host name associated with the NIC that is routable to the agent manager. Uninstalling the agent: Manually uninstalling the common agent: How to remove the common agent manually if the uninstallation wizard does not complete successfully.
780
This section describes how to remove the common agent manually if the uninstallation wizard does not complete successfully. Some of the following steps might not be necessary, depending on how much of the uninstallation wizard completed. This procedure removes all instances of the common agent from the system: 1. Stop the common agent. v Windows operating systems: In the Windows Services window, find the Tivoli Common Agent service, right-click on it, and then select Stop. v Other operating systems:
./endpoint.sh stop
If more than one common agent is installed, stop each one. 2. Verify that the common agent processes are all stopped by checking for the nonstop process. If the common agent stopped properly, the nonstop process will not be running. However, if the processes are still running, stop them as follows: v Windows operating systems: Using the Windows Services window to stop the common agent typically cleans up any remaining processes. No additional action is required. v AIX operating systems:
ps -ef | grep nonstop ps -ef | grep java
Use the kill -9 command to stop both processes. Stop both processes quickly, to prevent them from starting each other up again. v Other operating systems:
ps -aef | grep nonstop ps -aef | grep java
Use the kill command to stop the process ID with the lowest number for each process. (Linux has multiple process IDs shown, pointing up to lowest starting ID). 3. Use the uninstallation wizard to uninstall all common agents on the workstation. If more than one common agent is installed, run the wizard for each one. For any common agent that you can not uninstall, delete the common agent installation directory, including all files and subdirectories. 4. Clean up the ep.reg file and, if it exists, the ep.bak file: v If you are uninstalling all common agents from the system, delete both files. v If you are uninstalling a specific common agent, delete the line in each file that lists the installation directory of the common agent you are uninstalling. For example, to uninstall the common agent installed in the /opt/tivoli/ep1 directory, delete the line that begins like this:
The files are in the following directory: v Windows operating systems: %ProgramFiles%\Tivoli v AIX operating systems: /usr/tivoli v All other platforms: /opt/tivoli 5. On Windows operating systems, delete the Windows service for the common agent. Use one of the following methods: v Run the srvinstw.exe command, which is available in the Windows Resources Toolkit. This command launches a window in which you select the service to be deleted. v Download the InstallUtil utility. Run the following command:
InstallUtil uninstallservice service_name
v Manually edit the Windows Registry.
781
Important: Be careful when editing the Windows Registry. An incorrect change can damage the operating system. a. Make a backup copy of the registry. b. In a registry editor such as regedit or "regedit32", expand the following keys: My Computer HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services IBMTivoliCommonAgentn, where n is an integer starting with 0 for the first common agent that was installed on the system. c. Check the value of the Image Path key for the IBMTivoliCommonAgentn entry. This value specifies the directory in which the common agent was installed. Use the value to make sure you are deleting the registry entry for the correct common agent. d. Delete the IBMTivoliCommonAgentn key for each common agent that you are removing. e. Save the changes to the registry. 6. On UNIX and Linux, delete the s71 and k71 scripts from the /etc/rc.d directory. 7. If a Windows account was created for the common agent and you will not need it when reinstalling the common agent, delete the account. 8. Remove the entry for the common agent in the registry. On the server, use the RetrieveAgents, PurgeAgents, and LogicallyDeleteAgents utilities to identify and remove registry entries for the common agent. 9. On Windows operating systems, restart the operating system to remove the Windows service. 10. Optionally, delete the common agent installation directory. 11. Optionally, uninstall the Tivoli GUID. On Windows, use Add or Remove Programs to uninstall TivGuid. The common agent is removed from your system. Failures during manual uninstallation of common agent: If you manually delete the Common Inventory Technology (CIT) directory from a target computer when uninstalling the common agent, all products and technologies that rely on CIT will fail. Symptoms The IBM Tivoli Common Agent discovery scan fails after manually removing the C:\Program Files\tivoli\cit directory (opt/tivoli/cit for UNIX). For example, you might have removed this directory manually when uninstalling the common agent and then encountered this failure after reinstalling the common agent. Causes Common Inventory Technology (CIT) is a shared component that must not be removed manually. If you manually delete the CIT directory from a target computer, all of the products and technologies that are installed on that computer and are reliant on CIT will fail. Resolving the problem If you decide to remove the CIT directory manually, you also need to manually remove the cit.ini file from the %WINDIR%\cit directory (/etc/cit for UNIX). In an environment where no manual removal of files is performed, if no exploiter product uses CIT, the CIT uninstaller removes the CIT native code and cit.ini file.
782
Manual uninstall does not automatically update the data model: To work around this issue you will need to either run an Agent Compliance Scan or run the discovery configuration called IBM Tivoli Common Agent Discover Device against the computer. Symptoms Uninstalling the common agent manually results in the status being refreshed to display stopped. The status must be updated as uninstalled. Causes The common agent status will not be updated to uninstalled. The common agent uninstall will not send a message to the provisioning server. The Agent Manager is updated. Resolving the problem 1. To work around this issue you will need to either run an Agent Compliance Scan or run the discovery configuration called IBM Tivoli Common Agent Discover Device against the computer. Either option will update the common agent status and clean up the common agent information from the computer. This is only an issue for a manual uninstall initiated from the common agent system and does not affect the common agent uninstall initiated from the computer. Authentication errors after agent installation: Symptoms Authentication errors occur after installing the common agent. Causes Authentication errors can be caused by the following: 1. Incorrect password. 2. Corrupted or missing authentication files in agent_installdir\cert directory, where agent_installdir is the agent installation directory. Diagnosing the problem Following installation of the common agent, the agent is unable to register with the agent manager. Authentication errors are logged in msgAgent.log. Resolving the problem 1. Verify that you are using the correct password. 2. Change the registration password on the common agent. This password is stored in encrypted form, so that a special command is required in to change it. a. Change directory to the agent installation directory. b. Use the following command to create and store a new encrypted registration password in the endpoint.properties file using the registration key Registration.Server.PW. In the command, password represents the registration password. Windows: jre\bin\java -cp lib\ep_install.jar;lib\ep_common.jar com.tivoli.agent.install.EncrPwdInConfFile config\endpoint.properties Registration.Server.PW password UNIX or Linux: jre/bin/java -cp lib/ep_install.jar:lib/ep_common.jar com.tivoli.agent.install.EncrPwdInConfFile config/endpoint.properties Registration.Server.PW password 3. Restart the common agent.
783
IP address change at NAT server not detected by common agent: When you change the IP address on the NAT server, the common agent cannot automatically detect that the address has changed. An agent status update is required for the change to be registered. Symptoms The common agent does not detect the IP address change. Causes The common agent discovery does not detect the change. Resolving the problem 1. Stop the common agent. 2. Restart the common agent. Common agent is unable to read GUID upon startup on Linux: The common agent cannot read the GUID if the GUID failed to install. Symptoms After installation, the common agent is unable to read the GUID upon startup on Linux x86 and Linux ppc. The following message is logged in the traceAgent.log file when the common agent is starting up and tries to read the GUID:
13:05:18.980+01:00 com.tivoli.agent.id.IDServiceImpl getEndpointId main java.lang.Exception: 231628950
Causes The GUID failed to install. During the installation of the common agent, the Tivoli GUID is installed. After the common agent is installed, it attempts to read the GUID upon startup. If the agent cannot read the GUID, it will fail to start. Resolving the problem Rebuild the RPM database, then reinstall the common agent. RPM is the package manager for Linux. User response: The commands to rebuild the RPM database are:
rm -f /var/lib/rpm/__db* rpm -vv --rebuilddb
Incorrect information after Tivoli Common Agent installation: A remediation workflow calls the provisioning workflow SoftwareModule.Install against Tivoli Common Agent 1.4.2, but the result that it produces is incorrect. Symptoms If the compliance check Require Tivoli Common Agent (TCA) 1.4.2 is created and the end file does not have Tivoli Common Agent installed, a recommendation to install Tivoli Common Agent 1.4.2 will be provided. After installing Tivoli Common Agent 1.4.2, TCA 1.4.2 will show up in the installed software list of the target computer but has not actually been installed. Causes
784
A remediation workflow calls the provisioning workflow SoftwareModule.Install against Tivoli Common Agent 1.4.2, but the result that it produces is incorrect. It creates a Tivoli Common Agent 1.4.2 installation on the provisioning server, but does not install Tivoli Common Agent 1.4.2 on the target computer. Resolving the problem To verify that the Tivoli Common Agent is installed, create a compliance check against the Tivoli Common Agent stack instead of against Tivoli Common Agent 1.4.2. TCA_PingAgent workflow hangs: This might happen if a nonstop process is still running because the previous uninstallation did not remove all components. Symptoms Testing communication with the TCA_PingAgent workflow hangs on Windows computers. Causes A nonstop process might still be running because the previous uninstall did not remove all components. Diagnosing the problem Check theSystemErr.out file on the Windows computer for an error message similar to this error:
com.tivoli.agent.system.SystemStreamMgr$LogPrintStream println(String) SEVERE: NOTE ==><4> Server socket failed to accept incoming connections. [java.io.IOException: SSL session object is null. Socket resource may not be available.]
This error might indicate that the common agent cannot open the port, which means that it is already open by something else. Resolving the problem Determine which type of the error is causing the problem and follow the appropriate steps to resolve the error: v Access privileges are missing for the local administrator (error -121): The local administrator account for the Windows computer is missing the required privileges. 1. On the Windows computer, navigate to Control Panel > Administrative Tools > Local Security Policy > Local Policies > User Rights Assignment. 2. Ensure that the following policies are assigned to the administrator: Act as a part of the operating system Log on as service v Ports specified for install are already in use (error -124): To successfully install the common agent on target computers, you must ensure that ports 21080 (WebContainerPort) and 21443 (WebContainerSSLPort) are free on the target computers. If the common agent installation is attempted on an target computer that already uses these ports, the common agent installation will fail. For more information, you can refer to the preinstall.log file, located in the C:\Program Files\tivoli\ep\runtime\agent\logs directory. v A user action was not successful (error -101): This error, in the preinstall.log file might occur when you use the InstallUtil tool. This tool manipulates the system user. Launch the tool manually in the same way to reproduce the error. For example, C:\tcatemp\utility\InstallUtil.exe" - userexists -user <user_name>.
785
Common agents cannot communicate with agent manager: Improper setup or failed installations can prevent common agent computers from being able to resolve the fully qualified name of the agent manager server. Symptoms Communication problems between the common agents and the agent manager might include, for example, a failed ping agent, or failed subagent installations when installing the common agent. Causes The Domain Name Server (DNS) was not set up properly. By default, the agent manager requires the common agent computers to be able to resolve the fully qualified name of the agent manager server. Resolving the problem If the target computer that you want to install the common agent on cannot resolve the fully qualified name of the agent manager server, follow these steps: 1. Stop the provisioning server. 2. On the provisioning server, edit the AgentManager.properties file that is located in the following directory:
$WAS_HOME/installedApps/<nodename>/AgentManager.ear/ AgentManager.war/WEB-INF/classes/resources
a. Find this line:

ARS.host=<fully qualified name>
where <fully qualified name> can be, for example, bvtwin1.tpmserver.example.com. b. Replace the IP address with the fully qualified name, for example, 9.2.2.2. The resulting line is:
ARS.host=9.2.2.2
c. Restart the agent manager. d. Try installing the common agent on the target computer again. Common Agent service access point: Symptoms Tivoli Provisioning Manager provides an automation package with the following bundles to support the functions of the Common Agent service access point: Tivoli Provisioning Manager Core agent TivoliCommonAgent-core COP-CommonAgent-TPM.jar Scalable File Distribution Content Delivery Service v CDSClientAPIBundle.jar v CDSDepotServer.jar Job-processing subagents dms-client-subagent v httpadpator.jar v httpsadaptor.jar v osgiagent.jar
786
v syncml-core.jar v syncml-dm.jar v TPMAgentExt.jar event-subagent v EventAdmin.jar jes-subagent v jes.jar Scanning subagents SCMCollectorAgent v SCMCollectorAgent_<os>.jar CitScannerAgent v CitScannerAgent_<os>.jar v citBundle.jar SPB-processing subagents SPBHandler v spb_handler_<os>.jar Agent discovery of deleted agents reports incorrect version: Agent discovery of deleted agents at 1420 level reports an incorrect version. Symptoms If you reimage an endpoint or delete the entry of an endpoint from the Provisioning Computers panel, and then rerun the discovery, the endpoint might display an incorrect version. After running the Tivoli Common Agent Discovery or the Tivoli Common Agent Discovery Device, the agent status is reported as offline in Tivoli Provisioning Manager. Causes The Tivoli Provisioning Manager Agent Manager maintains its own database of the servers where the common agent is installed. If you delete the endpoint entry from the Provisioning Computers page, the entry still exists in the Agent Manager database and the agent status is displayed as offline. Resolving the problem Perform the following steps: 1. To clean up the agent from the Agent Manager and the data model, run the workflow TCA_DeleteServerFromAMAndDCM. 2. To register the agent with the Agent Manager, run the following command on the endpoint: %CA_HOME%/toolkit/bin/./configure.sh -amhost <AM_HOSTNAME> -passwd <AM_PASSWORD> 3. Run Tivoli Common Agent Discovery. Make sure that you run Tivoli Common Agent Discovery, and not the Tivoli Common Agent Discovery Device. After server upgrade, agent status is offline: Symptoms After the Tivoli Provisioning Manager server upgrade, the agent status is displayed as offline.
787
The following database exception error might occur on the server:

Caused by: com.ibm.db2.jcc.a.ym: DB2 SQL Error: SQLCODE=-530, SQLSTATE=23503, SQLERRMC=CDB.AGENT_OPER_STATE.LAST_CERT_FK, DRIVER=3.51.90 at com.ibm.db2.jcc.a.wc.a(wc.java:588) at com.ibm.db2.jcc.a.wc.a(wc.java:60) ................... Caused by: com.ibm.db2.jcc.a.ym: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=16, TABLEID=2, COLNO=5, DRIVER=3.51.90 at com.ibm.db2.jcc.a.wc.a(wc.java:588) at com.ibm.db2.jcc.a.wc.a(wc.java:60) ...................
Causes There might be inconsistencies in the database for example, a null value in a field where the value null is not permitted. Resolving the problem Reconfigure the agent by running the following script from the endpoint:
%Agent_Home%/toolkit/bin/configure.[sh/bat] -amhost <Agent_Manager_Host_Name> -passwd <Agent_Registration_Password> -force
Windows SDI patch scan fails: Symptoms The Windows endpoint takes more than 30 minutes to complete the patch scan. The scan fails with a timeout error. Causes Due to slow endpoints, the scan command fails with a timeout error after 30 minutes. Resolving the problem By default, the timeout variable is set to 30 minutes. You can set the timeout value to one hour by performing the following steps: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Variables tab. 3. Click New Row. 4. Type the variable name patch-scan-timeout. 5. Type the value in seconds. For example, to set the value to one hour, type 3600. 6. Click Save. Note: To see how long the patch scan takes on an endpoint, see the windowsupdate.log file on the endpoint. Configuring OSGi bundle logging on the endpoint: Symptoms The trace log does not produce enough data while tracking job processing on the endpoint. Resolving the problem
788
To log the endpoint DMS polling for jobs and OSGI bundles interaction, you can enable the OSGiAgent log. To debug the OSGiAgent, add the property osgiagent.debug=true in <ep home>\conf\overrides\ agent.properties. The log data is located in C:\osgiAgentLog1.txt.
Software distribution and installation problems

This section describes how to recover from software distribution and installation problems. File distribution between a dual stack computer and a computer supporting only IPv4, fails: Symptoms File distribution between a computer with dual stack configuration and a computer supporting IPv4 addressing only fails with the following error:
com.ibm.tivoli.tpm.osgi.service.FileManagementException: Error while attempting file transfer: Cannot obtain an InputStream to a file after download failed., cause: Cannot obtain an InputStream to a file after download failed.
Causes The depot server is inactive and the download plan must include a peer from the zone, or the published files were deleted from the depot. The dual stack computer is registered in the dynamic content delivery administration console with IPv6 address format. The dynamic content delivery administration console only records the IPv6 address format of the dual stack computer, and this information is used in the download plan for the IPv4 computer. The IPv4 endpoint is not able to download the file from the peer even though the peer has a dual stack configuration. The dynamic content delivery administration console continues to prepare the download plans until the dynamic content delivery timeout occurs (the dynamic content delivery default timeout value is set to approximately 2 hours). Because the IPv4 endpoint is not able to download the file, the task fails. Resolving the problem To avoid this issue, choose one of the following options: v Restart the depot server and Tivoli Common Agent Services. v Distribute the file to an IPv4 computer first or to a dual stack computer on which the IPv4 address format is registered in the dynamic content delivery administration console. File distribution times out if the device manager service timeout is set to one hour: Symptoms The file distribution times out if the device manager service timeout value is set to one hour. Causes The depot server is inactive. The target computer is not able to connect to the peers which contain the file to be downloaded. Therefore, the file download does not take place and the task times out. Resolving the problem Consider one of the following options to resolve this problem: v From the provisioning global settings, change the value for the variable DMS.Job.Interval.In.hours to 2 hours or more. v Restart the depot server and then restart the Tivoli Common Agent services. v Distribute the file to an IPv4 computer or to a dual stack computer registered with an IPv4 address in the Dynamic Content Delivery management center.
789
To check the endpoint IP address registered on the Dynamic Content Delivery management center, follow the next steps: 1. Open the Dynamic Content Delivery properties file: v v
AIX Solaris HP UX Red Hat
/usr/tivoli/ep/runtime/agent/subagents/cdsclient.properties
SUSE
/opt/tivoli/ep/runtime/agent/subagents/cdsclient.properties
Windows C:\Program Files\tivoli\ep\runtime\agent\subagents\cdsclient.properties v 2. In the properties file, ensure that the key value pair of user_ip is IPv4 address. If you change the file key value pair, then you must also change the value initial_login_done=true to false. 3. In <Tivoli Common Agent installation directory\runtime\agent\bin, run endpoint.sh restart or endpoint.bat stop 4. Run endpoint.bat start
Software package distribution overwritten by installation: When you manually perform a distribution first before installing a software package, a second software package is created even though the files have not changed since the first packaging. The manual distribution is overwritten. Symptoms If you manually perform a distribution of a software package before you install it, the software package redistributes automatically during installation, overwriting the first distribution in the process and making it unnecessary. Causes Software packages (but not software package blocks) are distributed and installed at the same time by default. They normally do not perform the two tasks separately. When you manually perform a distribution before installing a software package, a second software package is created even though the files have not changed since the first packaging. Because this second software package was created with a different MD5 hash, the result is that the whole software package gets redistributed, overwriting the first distribution in the process. Resolving the problem Use software package blocks (SPBs) instead of software packages, because software package blocks are not affected by this limitation and you can distribute and install separately. Note: Although default software packages have this limitation, you can design your own workflows that do not have this problem, even without using software package blocks. Software product distribution to target computers fails when filtered by group: The software products do not have logical management operation implemented, the target computers were not enabled for scalable distribution infrastructure , or the target computer filtering was done using the By Group option. Symptoms Distribution of software products that do not have the SoftwareInstallable.Distribute logical management operation implemented on target computers that are not SDI enabled fails with the following error if the target computers were filtered using the By Group option:
COPDEX137E: There is no workflow that implements the VALUE_0 logical operation associated with device VALUE_1.
790
Causes The following factors contribute to this failure: v The software products that have been selected for distribution do not have the SoftwareInstallable.Distribute logical management operation implemented. For the SoftwareInstallable.Distribute LDO, a workflow is required for the specific Software Product being distributed. You must create one when required v The computers targeted for distribution are not SDI enabled, which means that they have do not have an SDI-SAP defined. v The target computer filtering was done using the By Group option. Resolving the problem Do the software product distribution by first filtering the target computers By Computer, and then consider the following behavior when making the software and computer selections on the Distribute Software Products page: v If no software product is selected in the Selected Software section, the list of target computers under Selected Targets displays only the computers that have an SDI-SAP defined. v If one or more software products that do not have the SoftwareInstallable.Distribute logical management operation implemented are selected, then only the computers that have an SDI-SAP defined are listed. v If one or more software products that all have the SoftwareInstallable.Distribute logical management operation implemented are selected, then all the target computers are listed, regardless of whether they are SDI-enabled or not. Software publish task fails: The software publish task fails Symptoms After successfully migrating the server, the File Publish operation does not work. One or more error messages similar to the following messages might be displayed:
COPDEX040E An unexpected deployment engine exception occurred: COPINF002E Failed to publish file: /opt/IBM/tivoli/tpm/repository/TCA_upgrade_SPB/spb/TCA_upgrade_AIX.spb with id 46210 to CDS depot servers. CTGDEC029E The file, TCA_upgrade_AIX.spb, could not be uploaded successfully to any of the depot servers chosen by the management center. CTGDEC035E The upload proxy certificate was denied by the depot server. The file, downloadGridtmp15101073668464212321247841674319, could not be uploaded to server: tpmserver32.in.ibm.com:2100.
Causes This problem is due to the time difference between the depot and the server. Resolving the problem Align the time on the depot with the time on the server. Software product distribution fails on HP-UX target computer: Symptoms When trying to install a software package block (.SPB file) on a HP-UX target computer with Tivoli common agent (TCA) version 1.4.1.0, the following error is displayed:
791
COPINF050E Failed to install software product PackageExample with error: Installation of package PackageExample failed with return code [137], and message: sh[3]: SHLIB_PATH: not found sh[3]: SystemDrive: not found /usr/lib/hpux32/dld.so: Unable to find library libeacmr.sl. sh[3]: 5792 Killed; return code = 137
Causes This is a known issue with the 7.1 software package block handler. Resolving the problem It is recommended that you upgrade the HP-UX target computers to TCA version 1.4.2.1 to resolve this issue. Deleting and re-creating the depot causes distributions to fail: You delete and re-create a depot. The operation completes successfully but subsequent distributions fail. Symptoms When you try publish a file after re-creating the depot, a series of messages like the following messages is returned:
COPDEX040E An unexpected deployment engine exception occurred: COPINF002E Failed to publish file: C:/Program Files/IBM/tivoli/tpm/repository/testtextfile5.txt with ID 16444 to CDS depot servers. CTGDEC030E The management center was unable to find potential depot servers to upload the file. The file, testtextfile5.txt, could not be uploaded. Make sure that there is at least one active depot server available, that it has enough space to store the file, and that it is not in an unreachable or restricted zone.
Causes If you delete a depot without uninstalling the depot stack, then re-create the depot, the correct server version and disk space information are missing in the management center administrative console Resolving the problem You can perform one of the following operations: v Uninstall the depot stack before reinstalling the depot. v Restart the depot after reinstalling if you have not uninstalled it Upload server times out on idle connections to Oracle server: Firewall timeout for idle connections might sever a connection. This can cause JDBC applications to hang while waiting for a connection. Symptoms The upload server might time out on an idle connection to the Oracle server if the following conditions are met: v The provisioning server runs on Solaris with a remote Oracle database. v The upload server is on a separate server that connects to the Oracle server using a firewall. If the timeout occurs, the following error message is displayed:
792
COPCOM093E The JDBC driver caused an SQL exception.
Causes Firewall timeout for idle connections might sever a connection. This can cause JDBC applications to hang while waiting for a connection. Resolving the problem You can perform one or more of the following actions to avoid connections from being severed due to firewall timeout: v If you are using connection caching or connection pooling, then always set the inactivity timeout value on the connection cache to be shorter than the firewall idle timeout value. v Pass oracle.net.READ_TIMEOUT as connection property to enable read timeout on socket. The timeout value is in milliseconds. v For both JDBC OCI and JDBC Thin drivers, use a net descriptor to connect to the database and specify the ENABLE=BROKEN parameter in the DESCRIPTION clause in the connect descriptor. Also, set a lower value for tcp_keepalive_interval. v Enable Oracle Net DCD by setting SQLNET.EXPIRE_TIME=1 in the sqlnet.ora file on the server side. Canceled task does not cancel jobs in progress: When a task is canceled, its job is canceled only on the provisioning server. Symptoms When a file distribution task is canceled, agents that have already started processing the job will continue processing it. Results for the additional jobs that are in progress to finish the (now canceled) job are communicated back to the provisioning server. Causes When a task is canceled, its job is canceled only on the provisioning server. This does not stop any agent that has already begun processing the job. Resolving the problem To cancel the additional jobs that are run by the agents, restart the corresponding endpoints. Task status is not updated when distributing or installing software products: Database lock time-outs might occur when submitting a software product distribution or installation task with over 10000 targets. Symptoms When you are distributing or installing software products, database lock time-outs occur and the task status is not updated. Causes Database lock time-outs might occur when submitting a software product distribution or installation task with over 10000 targets. Resolving the problem
793
1. Stop Tivoli Provisioning Manager. 2. Connect to the database from a DB2 command window. 3. Increase the LOCKTIMEOUT configuration parameter to 10 minutes: db2 update db cfg using LOCKTIMEOUT 600. 4. Restart the database. 5. Start Tivoli Provisioning Manager. 6. Allow the status of the existing task to finish updating. If the task does not complete successfully, cancel it and submit a new task. Problems associating discovered software resources with software definitions: You can only associate a discovered software resource with a software product, patch, or operating system software definition. Symptoms When you manually associate a discovered software resource on a computer with a software definition, you can only select a software product, patch, or operating system software definition. The following scenario is described: v You manually associated a discovered software resource on a computer with a software stack definition. v When you look at the properties of the software stack, no software modules are displayed. v Compliance checking also incorrectly defines the software stack as missing when the software stack is included in the server template. Causes You can only associate a discovered software resource with a software product, patch, or operating system software definition. Associations with a software stack or distributed application are not supported. Resolving the problem Avoid associating software stacks or distributed applications with identified software resources on a server. Linux on IBM System z fails to import a software signature: The 1024MB that is required for the task to run is too large for the Java virtual memory (JVM). Change the amount of required memory. Symptoms You cannot import a software signature when using Linux on IBM System z. Causes An out of memory exception occurs because the 1024MB that is required for the task to run is too large for the Java virtual memory (JVM). Resolving the problem
794
Change the required memory and then manually run the script to import a software signature. To change the memory, follow these steps: 1. Open a terminal window and go to the tools directory by typing cd $TIO_HOME/tools. 2. Open the importSoftwareSignature.sh script for editing.
vi importSoftwareSignature.sh
3. Replace Xmx1024m with Xmx900m. 4. From the $TIO_HOME/tools folder, run the script to import the software signature Out of memory when querying for software signatures: To avoid this problem, you need to manage your large object (LOB) locators appropriately. Symptoms Running a query using the JDBC type 2 driver to pull all Windows software signatures might cause the computer to run out of memory. Resolving the problem To avoid this problem, you need to manage your large object (LOB) locators appropriately. To do this, add the following line to the sqllib/cfg/db2cli.ini file:
PATCH2=50
This entry ensures that the command line interface frees a LOB locator when the next LOB is to be fetched. Software distribution troubleshooting: Symptoms The service access points on the Tivoli Provisioning Manager server, the file repository for the dynamic content delivery management center, and the variables that are required for software distribution using the scalable distribution infrastructure are not created automatically. Causes The tpmserver.xml and infrastructure.xml files have not been successfully imported as part of the agent installation. Resolving the problem 1. Ensure that the tpmserver.xml and infrastructure.xml files are imported successfully as part of the agent installation. You can check the following log files for error or warnings, in the %TIO_LOGS%\install (Windows) or $TIO_LOGS/install (UNIX) folder: v xmlimport.log v xmlimport_soa.log For more information, see the Deploying software using the scalable distribution infrastructure tutorial. Canceled task does not cancel jobs in progress: When a task is canceled, its job is canceled only on the provisioning server. Symptoms
795
When a file distribution task is canceled, agents that have already started processing the job will continue processing it. Results for the additional jobs that are in progress to finish the (now canceled) job are communicated back to the provisioning server. Causes When a task is canceled, its job is canceled only on the provisioning server. This does not stop any agent that has already begun processing the job. Resolving the problem To cancel the additional jobs that are run by the agents, restart the corresponding endpoints. Software distribution using DE fails with depot not found error: Symptoms The following error is found when deploying a software package to a target computer that has the common agent (TCA) installed:
COPINF003E The software product C:/Program Files/IBM/tivoli/tpm/repository/filename with the ID id_number could not be published to the dynamic content delivery depot for the specified targets.
The error message is:

CTGDED080W When using dynamic depot server selection, depot servers could not be obtained for the endpoint clients.
Causes The TCA installation might have automatically created the SDI-SAP and assigned to the endpoint a task operation. This will create a problem when deploying the software package in a Deployment Engine (DE) infrastructure where no depot server is required. You receive the error message because the task is performing an SDI operation. Resolving the problem If you want to run the deployment in a Deployment Engine (DE) infrastructure, perform the following steps: 1. Go to the Provisioning Computers application. 2. Select the target computer to which you want to deploy the software product. 3. Click the Credentials tab. 4. Ensure that the SDI-SAP is not assigned to the endpoint task operation. 5. If the SDI-SAP is assigned, delete the SAP. 6. Click Save. Error 20006 occurs while uploading the package: A shell command error can occur after trying to import an SPB file on the Tivoli Provisioning Manager server. Symptoms When you are importing an SPB file on the server, you might see the following error:
DISSP6050E error 20006 occurred while uploading the package.
796
Follow these steps to diagnose and fix: 1. Log in as root to the provisioning server. 2. Enter the su - user1 command. The command must complete successfully. 3. Enter the su - user2 command. If this command fails with the su: incorrect password error, even though the correct password was entered, follow these steps to fix the problem: a. Log in as root to the provisioning server. b. Go to /etc/pam.d. c. Open the su control module. d. Comment out the following line:
# Uncomment the following line to add a user to the "wheel" group. auth required pam_wheel.so use_uid
This adds the user tioadmin to the wheel group. This allows provisioning workflows to run without error. Old download plans display after SPB is installed: Tivoli Provisioning Manager displays old download plans when a software package block (SPB) is installed using scalable distribution infrastructure. Symptoms A new download plan is created for a first-time installation. If you publish an SPB before installing it, the SPB remains on the depot or in the endpoint cache. When you uninstall the software and then reinstall it, or reinstall it with the force option, no new download plan is created. Tivoli Provisioning Manager displays the old download plan data in the task view. Causes If you publish an SPB to a depot and then install it on a target computer, when the SPB is installed again, it is not downloaded again. This is because the target computer is a peer and the SPB is already cached and so, the second install does not have a download plan generated. Tivoli Provisioning Manager shows the original download plan because it is the download plan used for the actual distribution. Resolving the problem Do not publish the SPB before installing it. This way, the SPB is deleted each time and a new download plan is generated each time. Error deploying SPB using scalable distribution infrastructure: An error can occur if you deploy a software package block using scalable distribution infrastructure. Symptoms The following error can occur if you deploy a software package block using scalable distribution infrastructure:
com.ibm.tivoli.tpm.osgi.service.FileManagementException: Error while attempting file transfer:An exception was detected while returning the output stream from the CDS URL handler., cause: An exception was detected while returning the output stream from the CDS URL handler.
Causes
797
The installation failed because there was not enough disk space on the computer. The target log files contain the following error:
TPMFMS001E File copy: Error while attempting to copy file; Exception: An exception was detected while returning the output stream from the CDS URL handler., cause: CTGDEQ046E The client does not have enough free space to download the file (C:\Program Files\tivoli\ep\runtime\agent\subagents\cds\downloads;1267379347631) with a size of (27050983326) bytes. The client has (5854089216) bytes free.
Resolving the problem The error might occur because the target ran out of the disk space necessary to store the large file. Allot some disk space to continue. Windows patch management on SDI infrastructure using WSUS: Symptoms Using a small environment patch management scenario, Windows Server Update Services (WSUS), you must configure SDI. Causes If you configured WSUS to manage Windows patches in your Tivoli Provisioning Manager environment, by default, you are using Deployment Engine instead of SDI. You can use SDI by defining the following variable: wsus-over-sdi. Resolving the problem To set the variable, perform the following: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. In the Variables tab, set wsus-over-sdi to true. Silent installation of interactive Windows patches fails: One or more Windows patches that require an interactive installation might fail in Windows environments that do not have the Microsoft Windows Server Update Services (WSUS) set up. Symptoms One or more Windows patches that require an interactive installation mode might fail in both the Deployment Engine (DE) and the Scalable Distribution Infrastructure (SDI) modes if the environment has been configured without the Microsoft Windows Server Update Services (WSUS) server. Causes Microsoft suppresses the silent installation of some of the newly released patches to ensure that system administrators are aware of the upgrade. Consequently, interactive patches, such as Windows Server 2008 R2 Service Pack 1 x64 Edition (KB976932) and Windows Internet Explorer 9 for Windows Server 2008 R2 for x64-based systems, cannot be installed in silent mode using Tivoli Provisioning Manager. Resolving the problem To install these patches using Tivoli Provisioning Manager, configure your environment using the Microsoft Windows Server Update Services (WSUS) server.
798
Administrative console problems

This section will help you resolve problems with the administrative console. Agent Manager log files on the WebSphere Application Server run time: Log file names and descriptions regarding the agent manager Agent Manager installation log files The log files generated during the installation and initial configuration of the agent manager are located in the AM_HOME/logs directory.
Table 146. Agent manager installation log files Log File AMReturnValues.log Description Summary of return values of the steps of the agent manager installation. If the agent manager was installed silently, check this log for the results of each step of the installation. If you installed using the agent manager installation wizard, this information is displayed automatically. If you are performing a silent installation, check this log for a step-by-step summary of the installation's results. InstallShield MultiPlatform (ISMP) log for installing the agent manager. Check this log first to verify that the agent manager installed properly and that the agent manager server is started. Information about whether a new installation was performed or an existing version of the agent manager was upgraded. Standard output and standard error logs for the AuthXMLUpgrade program. Standard output and standard error logs for generating the root certificate for the agent manager certificate authority. Log of the Data Definition Language (DDL) script that creates and initializes the registry database. Standard output and standard error logs for creating and initializing the tables in the registry database. An ISMP log for installing the files necessary to create the registry database. Standard output and standard error logs for creating the registry database. Standard output and standard error logs for the EncryptAMProps program. Standard output and standard error logs for installing the Tivoli globally unique identifier (GUID). Messages and trace information generated during the installation and configuration of the agent manager applications in WebSphere Application Server. Standard output and standard error logs for starting the application server for the agent manager.
am_install.log
am_upgrade.log
auth_stdout.log auth_stderr.log certGen_stdout.log certGen_stderr.log datastore.out datastore_stdout.log datastore_stderr.log ds_install.log dh_stdout.log db_stderr.log encrypt_stdout.log encrypt_stderr.log guid_install.log guid_stdout.log guid_stderr.log msg_EPM_Install.log trace_EPM_Install.log serverStatus_out.log serverStatus_err.log
799
Table 146. Agent manager installation log files (continued) Log File startserver_stdout.log startserver_stderr.log jacl/amApp_out.log jacl/amApp_err.log Description Standard output and standard error logs for starting the agent manager application server under WebSphere. Standard output and standard error logs generated while installing the AgentManager and AgentRecoveryService applications and WAR files. These logs are generated by the EPMInstallApp.jacl configuration script. Standard output and standard error logs generated while installing the application server for the agent manager. These logs are generated by the EPMAppServer.jacl script. Standard output and standard error logs for verifying the cell for the WebSphere Application Server configuration. These logs are generated by the EPMValidate.jacl script. Standard output and standard error logs for verifying the node for the WebSphere Application Server configuration. These logs are generated by the EPMValidate.jacll script. Standard output and standard error logs for configuring the WebSphere Java Database Connectivity (JDBC) provider, data source, and J2C Authentication Data Entry. These logs are generated by the EPMJdbcProvider.jacl script. Standard output and standard error logs for Secure Sockets Layer (SSL) configuration. These logs are generated by the EPMSSLConfig.jacl script. Standard output and standard error logs for creating the WebSphere virtual host. These logs are generated by the EPMVirtualHost.jacl script.
jacl/appServer_out.log jacl/appServer_err.log
jacl/checkcell_out.log jacl?checkcell_err.log jacl/checknode_out.log jacl/checknode_err.log
jacl/jdbc_out.log jacl/jdbc_err.log
jacl/ssl_out.log jacl/ssl_err.log jacl/virHost_out.log jacl/virHost_err.log
Agent Manager uninstallation log files The log files generated when you uninstall the agent manager are located in the AM_HOME/logs directory.
Table 147. Agent manager uninstallation log files Log File uninstall.log AMUninstallReturnValues.log msg_EPM_Install.log trace_EPM_Install.log Description InstallShield MultiPlatform (ISMP) log for uninstalling the agent manager. Summary of return values of the steps of the agent manager uninstallation. Messages and trace information generated when uninstalling the agent manager applications in WebSphere Application Server.
Remote registry installation log files If the registry is on a system other than the agent manager computer, install a subset of the agent manager files on the database server to create and initialize the registry database.
800
Table 148. Remote registry installation log files Log File datastore.out ds_install.log db_stdout.log db_stderr.log Description A log of the SQL statements that are run to create the registry database and its tables. An ISMP log for installing the files necessary to create the registry database. Standard output and standard error logs for creating the registry database. Check db_stdout.log first to see if the registry was created successfully.
Other log files The runtime logs for the agent manager running on WebSphere Application Server are located in the app_server_root/profiles/profile_name/logs/app_server_name' directory, where app_server_name is the name of the application server. By default, the name is AgentManager. The runtime logs for the agent manager running on the embedded version of IBM WebSphere Application Server are in the app_server_root/agentmanager/logs/app_server_name directory. The runtime logs for WebSphere Application Server are in the app_server_root/profiles/profile_name/ logs/server1 directory. Additional logs are in the app_server_rootprofiles/default/logs/ffdc directory, but no such directory exists for the embedded version of IBM WebSphere Application Server. DB2 provides several First Failure Data Capture (FFDC) facilities that log information as errors occur. The DB2 FFDC facilities are used with command-line interface and DB2 traces to diagnose problems. The information captured by DB2 for FFDC includes: db2diag.log When an error occurs, the db2diag.log file logs information about the error. This is the primary log to use when debugging DB2 problems. db2alert.log If an error is an alert, entries are made in the db2alert.log file and in the operating system or native logging facility. dump files For some error conditions, additional information is logged in external binary dump files that are named after the failing process ID. These files are intended for DB2 Customer Support. trap files The database manager generates a trap file if it cannot continue processing because of a trap, segmentation violation, or exception. Trap files contain a function flow of the last steps that were executed before a problem occurred. Other useful DB2 commands include: db2trc This command gives you the ability to control tracing. db2support This command collects environment information and log files and places them into a compressed archive file. On WebSphere Application Server, the agent recovery service logs are in the log for the application server server1. This is the SystemOut.log file in the app_server_root/profiles/default/logs/server1 directory. This is true even if the WebSphere Application Server is installed in an application server other than
801
server1. However, this is not true for the embedded version of IBM, on which the agent recovery services logs are not supported. Cannot run backup tool with WebSphere Application Server: The backup tool might not run if the agent manager is installed with WebSphere Application Server in a version earlier than 6.0.2.15. You need to manually run the wsadmin command to run the backup tool. Symptoms The WebSphere Application Server backup tool will not run. Causes If you have the agent manager installed with WebSphere Application Server in a version earlier than 6.0.2.15 and then upgraded to the version required, it might not be possible to run the backup tool (receiving a message saying that the control service is not available instead). You can check if this is the cause of the problem by looking in the WebSphere Application Server wsadmin.traceout log file. Resolving the problem You need to manually run the wsadmin command from the location AM_HOME/tools/resources as shown in the following line:
/wsadmin.ext -conntype NONE -lang jython -f getConfig.py
This command refreshes .jar files, and you will be able to run the backup tool after running it. Installation or upgrade of agent manager fails with embedded version of IBM WebSphere Application Server: If you install or upgrade the agent manager with the embedded version of IBM WebSphere Application Server, you need to ensure that there is enough disk space for the operating system temporary directory. Symptoms Agent Manager fails to install or upgrade with the embedded version of IBM WebSphere Application Server. Causes If you install or upgrade the agent manager with the embedded version of IBM WebSphere Application Server, you need to ensure that there is enough disk space for the operating system temporary directory. Resolving the problem Ensure that your have at least this much disk space:: On On On On On On Windows operating systems: 200 MB AIX operating systems: 220 MB HP-UX 1A64: 310 MB HP-UX PA-RISC: 250 MB Linux operating systems: 200 MB Solaris: 260 MB
User response: To correct the problem, change the location of the operating system temporary directory.
802
Remote Execution and Access (RXA) problems

This section will help you resolve problems with Remote Execution and Access (RXA). Enabling RXA on Windows target computers: How to set up Remote Execution and Access (RXA) on Windows computers. The RXA version shipped with Tivoli Provisioning Manager supports the Windows security protocol NTLM v2. To use Remote Execution and Access (RXA) on Windows computers, complete the following steps: Procedure 1. Check if you can access c$ on the target computer. You need to be able to access \\servername\c$ to continue. 2. Check that Windows Firewall is not blocking the required ports. Ensure that RXA requirements for target computers are met. For more information, see Requirements for Windows target computers on page 556 3. Use Telnet to connect to port 139. If the port is listening, you will get a blank screen because port 139 does not support Telnet. If the port is not listening, the computer will pause for a short time before generating an error message. 4. If port 139 is listening, run the command netstat -an on the target. Ensure that both TCP 135 and TCP 139 are listening. If TCP 139 is not listening, the network interface card (NIC) must be set to Enable NetBIOS over TCPIP. 5. Disable Simple File Sharing by doing these steps: a. In a Windows Explorer window, click Tools > Folder Options, and then click the View tab. b. In the Advanced settings list, clear the Simple File Sharing check box. c. Click Apply and then click OK. 6. Enable file and printer sharing by navigating to Control Panel > Network Connections > Local Area Connection > Properties and then selecting File and Printer Sharing for Microsoft Networks. 7. Verify that the remote registry service is running. 8. Check for blocked traffic: a. Navigate to Control Panel > Administrative Tools > Local Security Policy. b. Right-click IP Security Policies on Local Computer and then select Manage IP filter lists and filter actions. c. Select the blocked items and then click Remove. Enabling RXA logging: To enable Remote Execution and Access (RXA) logging, edit the $TIO_HOME/config/jlog.properties file and follow the instructions in the comments. Procedure 1. Use the following command to stop the Tivoli Provisioning Manager engines:
tio stop TPM_ONLY
2. Edit the $TIO_HOME/config/jlog.properties file. 3. Make the appropriate changes as indicated by comments inside the file. 4. Enter the following command to start the Tivoli Provisioning Manager engines:
tio start TPM_ONLY
RXA cannot connect with UNIX target computers:
803
RXA does not supply SSH code for UNIX machines. You must ensure SSH is installed and enabled on any target computer you want to access using SSH protocol. Symptoms Remote Execution and Access (RXA) cannot establish connections with any UNIX target computer that has all remote access protocols (RSH, REXEC, or SSH) disabled. Causes RXA does not supply SSH code for UNIX machines. You must ensure SSH is installed and enabled on any target computer you want to access using SSH protocol. Versions of OpenSSH that are version 3.71 or newer contain security enhancements that were not available in earlier releases. In all UNIX environments except Solaris, the Bourne shell (sh) is used as the target shell. On Solaris targets, the Korn shell (ksh) is used instead, due to problems encountered with sh. Resolving the problem Ensure that you are using OpenSSH 4.4 or newer. A known issue in version 4.3 can cause problems when the provisioning server runs Expect scripts on a target computer. In order for RXA to communicate with Linux and other SSH targets using password authentication, you must edit the file /etc/ssh/sshd_config file on the target computers and set: PasswordAuthentication yes (the default is no). After changing this setting, stop and restart the SSH daemon using the following command:
/etc/init.d/sshd stop /etc/init.d/sshd start
In order to use SFTP for file transfers, in addition to calling SSHPProtocol.setUSESFTP(true), make sure that the SFTP server is enabled on the target computer. Note that the location of the sftp-server directory is dependent on your operating system. It is typically found in the following locations: v v v v
Solaris Linux HP UX AIX
: /usr/lib/ssh/sftp-server : /usr/libexec/openssh/sftp-server : /opt/ssh/libexec/sftp-server : /usr/sbin/sftp-server
The ssh_config file contains a line similar to the one below. Make sure the line that enables the sftp-server subsystem is not commented out, and that it points to the operating system-specific location of the sftp-server subsystem. For example:
Subsystem sftp /one_of/the_paths/shown_above
Dynamic content delivery problems

This section will help you resolve problems with the dynamic content delivery. Dynamic content delivery depots: Information regarding dynamic content delivery depots. Symptoms When you create a depot, ensure that you specify a directory relative to the subagents directory. If you do not, you will receive the following error:
CTGDEC119E The cache manager sub-component detected a failure during an I/O operation. The error was: Unable to create directory. The file was: C:\Program Files\tivoli\ep\subagents\cds\C:\data
804
Resolving the problem Verifying that the depot is active To check if depot is active from the dynamic content delivery management console server: 1. telnet depot-server 2100. 2. Run the command syst from the management console. The response will be, for example:
DS:pendolino.tpmserver.example.com=1.3.0.0
Publishing files to an unavailable depot If you try to publish a file to a depot (Depot A) that is unavailable, the dynamic content delivery management console will look for an available depot (Depot B) from the list of depots. It will temporarily place the published file in the available depot (Depot B). When the dynamic content delivery management console scans all the depots, and it detects that depot (Depot A) that you tried to publish the file to is now available, it will copy the file from the original depot (Depot B) to the intended depot (Depot A). It will also delete the temporary file from the Depot B. Cannot reinstall depot servers after removal: If the depot server reinstallation fails, remove GUID first and try again. Symptoms The reinstallation of a depot server, which has been previously deleted from the Manage Depots page using the Remove option might fail with the following exception recorded in the agentInstall.log file:
... com.tivoli.cas.install.common.InstallGUID, err, java.lang.Exception: Cannot get system GUID STACK_TRACE: 14 java.lang.Exception: Cannot get system GUID at com.tivoli.agentmgr.resources.GUIDHelper.getSystemGuid(GUIDHelper.java:247) at com.tivoli.cas.install.common.InstallGUID.saveGUID(InstallGUID.java:139) at com.tivoli.cas.install.common.InstallGUID.execute(InstallGUID.java:129) at com.installshield.wizard.RunnableWizardBeanContext.run(RunnableWizardBeanContext.java:21) Caused by: java.lang.Exception: 231628960 at com.tivoli.agentmgr.resources.GUIDHelper.getHostId(GUIDHelper.java:83) at com.tivoli.agentmgr.resources.GUIDHelper.getSystemGuid(GUIDHelper.java:241) ...
Causes The depot server was deleted and unregistered from the dynamic content delivery management center, but the GUID is still present. The depot needs to be completely removed from that computer Resolving the problem Removing the GUID is recommended as a workaround to solve this problem. Follow these steps: 1. Check whether the GUID still exists by running the following command:
rpm -qa ] grep TIVguid
2. If the GUID exists, run the following command to remove it:

rpm -evv TIVguid-1.3.0-0
805
3. Attempt to install the depot server again. Silent installation of the management center fails: The silent installation will fail if the value of the LICENSE_ACCEPT_BUTTON parameter is not set to TRUE. Symptoms The silent installation of the dynamic content delivery management center fails. Causes The value of the LICENSE_ACCEPT_BUTTON parameter is not set to TRUE. Resolving the problem To 1. 2. 3. 4. change the value of the LICENSE_ACCEPT_BUTTON parameter, follow these steps: Open the cds_manager_opts file in a text editor. Set the LICENSE_ACCEPT_BUTTON parameter by adding -V LICENSE_ACCEPT_BUTTON="TRUE". Save the cds_manager_opts file. Try the silent installation of the management center again.
Software distribution troubleshooting: Symptoms The service access points on the Tivoli Provisioning Manager server, the file repository for the dynamic content delivery management center, and the variables that are required for software distribution using the scalable distribution infrastructure are not created automatically. Causes The tpmserver.xml and infrastructure.xml files have not been successfully imported as part of the agent installation. Resolving the problem 1. Ensure that the tpmserver.xml and infrastructure.xml files are imported successfully as part of the agent installation. You can check the following log files for error or warnings, in the %TIO_LOGS%\install (Windows) or $TIO_LOGS/install (UNIX) folder: v xmlimport.log v xmlimport_soa.log For more information, see the Deploying software using the scalable distribution infrastructure tutorial. Published task files saving on different depot server: If the first depot server does not have enough space, published task files will also be saved on the next server. Symptoms There are two servers on Tivoli Provisioning Manager server. When a file is published on the first server, it is also published on the second depot server.
806
Causes There is not enough space on the first depot server to save a file. Resolving the problem Make enough space on the first depot server to store a file. Depot stack not removed on uninstall: The uninstallation of the depot does not automatically remove the depot from the dynamic content delivery system. The depot needs to be removed manually. Symptoms After successfully uninstalling the depot agent stack, you find that the entry for the depot stack in Tivoli Provisioning Manager has not been removed. Causes The uninstallation of the depot does not link with the removal of the depot from the dynamic content delivery system. It will cause the depot to still exist in Tivoli Provisioning Manager even though the depot is not available. Any files published to this depot will not get to the depot until a new depot is installed again for the same depot instance on the same computer. Resolving the problem 1. Navigate to the dynamic content delivery configuration page in the Tivoli Provisioning Manager web interface. Delete the entry of the depot server where the depot agent stack is to be uninstalled. 2. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. Select the computer where you want to uninstall the depot from. From the Select Action menu, click Uninstall > Software Installation. 3. To verify whether the depot stack is uninstalled, go to the computer and change the directory path to: <tca-install-dir>/runtime/agent/subagents/eclipse/plugins. If the uninstall was successful, you will not see the com.ibm.tivoli.cds.depot.cas.CdsDepot_2.1.0.jar file any longer. Incorrect value for the used space on a depot: The value for the used space is refreshed every 24 hours. If you do not want to wait, then the refresh can be done manually. Symptoms On the Depot page, if the data directory limit value is changed, the used space value is not updated automatically. Causes The value for the used space is refreshed every 24 hours. Resolving the problem To resolve the problem, do one of the following tasks: v After the change is made, wait for 24 hours so that the refresh is done automatically. v Click Refresh on the Depot Server Details window. To do this, start the Dynamic Content Delivery console from the Select Action menu, click the Depot tab, and then click Refresh under Cache Size.
807
v Change the MA_DEPOT_SPACE_CHECK_INTERV AL_HOURS parameter in Management Center Configuration to a smaller value so that the refresh is done automatically. Note: We recommend that the last task be done by the Tivoli Provisioning Manager administrator, and not by the user. This is because setting the MA_DEPOT_SPACE_CHECK_INTERV AL_HOURS variable to a smaller value might have an impact on performance. Login to dynamic content delivery console: To log in to the dynamic content delivery console, you need to add the user name to the Web service group, for example, TPWEBSERVICEUSER If you do not, you receive an authentication error. Symptoms When you log in to the to dynamic content delivery console or create a depot, make sure that the user name is added to the Web service group, for example TPWEBSERVICEUSER. If the user name is not included in the Web service group, you receive the following error:
CTGDEG005E The specified username or password is incorrect.
Causes To allow users to log in to the dynamic content delivery console, you must add the user name to the Web service group, for example TPWEBSERVICEUSER. Resolving the problem Add the user name to the Web service group, for example TPWEBSERVICEUSER. Depot servers are not available during a software product publish operation: Symptoms When deploying a software product the depot servers are not available and the following error is thrown:
COPINF003E The software product C:/Program Files/IBM/tivoli/tpm/repository/filename with the ID id_number could not be published to the dynamic content delivery depot for the specified targets.
The following error message is displayed:

CTGDED080W When using dynamic depot server selection, depot servers could not be obtained for the endpoint clients.
Causes If you have an active depot server set up correctly, probably the depot server port, whose default value is 2100, is not open between the Tivoli Provisioning Manager server and the depot server, and among all depot servers of the environment as well. Also, the port 2101 is used for peering. If peering is enabled, the port 2101 must be accessible on each system that acts as a peer. Resolving the problem If the systems of your environment are behind a firewall, modify the settings to allow the depot server port access from all systems for port 2100. Dynamic Content Delivery Management Center is not alive: Information regarding the message: Dynamic Content Delivery Management Center is not alive.
808
Symptoms You receive the following error message in the console.log every two minutes.
2010-02-24 13:09:33,778 ERROR [Status Updater] (CdsManagementCenter. java:89) cds.CdsManagementCenter: DCD Management Center is not alive. com.ibm.webahead.downloadgrid.exception.CDSException: CTGDEC003E Unable to authenticate user maxadmin. at com.ibm.tivoli.cds.administration.api.AdministrationServices. getRegio
Resolving the problem To disable all scalable distribution infrastructure component checks and to prevent dynamic content delivery error messages in $TIO_LOGS/console.log: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click Variables. 3. Filter and search for SDI.Comp.Status.Check and change the value to false. 4. Stop and start the Tivoli Provisioning Manager WebSphere Application Server using: v $TIO_HOME/tools/tio.sh stop v $TIO_HOME/tools/tio.sh start
Windows 2008 Select the option Run as administrator for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide. 5. To disable the SOAP and Web services so that both cannot be used on the Tivoli Provisioning Manager server, edit TIO_HOME/lwi/conf/overrides/TPMconfig.properties and add start.tpm.soapservice=false. 6. Restart the WebSphere Application Server and Tivoli Provisioning Manager.
Reference
Configuring RSA credentials and service access points

If you are using RSA authentication, you need to configure RSA credentials and set up a client and server service access point for your target computers and server.
Before you begin

The target computers must already be defined in Tivoli Provisioning Manager. You must configure RSA credentials and set up a service access point for target computers and the server. To do this, complete the following steps:
Procedure
1. Create a directory named keys in the TIO_HOME directory. 2. Copy the RSA private generated key to TIO_HOME/keys/RSA and rename the file to identity. 3. Copy the contents of the .pub file public key to $USER_HOME/.ssh/authorized_keys directory on the target computer. 4. Log in to Tivoli Provisioning Manager. 5. Click Go To > Deployment > Provisioning Computers. 6. Click the target computer for which you are configuring the RSA credentials. 7. Click the Credentials tab and click the SSH-Server SAP.
809
8. In the RSA Credentials section, select the identity key from the Private Key list. Note: The RSA private key is an optional field. If you do not define it, you need to create a global variable for the default private key and the value that you specify for the global variable is used. The global variable must have the key name RSA credential default private key and the component must be Entire system. To create the global variable: a. b. c. d. e. f. g. Log on to the Tivoli Provisioning Manager web interface. Click Go To > Administration > Provisioning > Provisioning Global Settings. Click the Variables tab. Click New Row. In the Variable field, enter RSA credential default private key. From the Component list, select Entire system. In the Value field, enter the location of the default private key.
h. Click Save. Note: To set up a server and client service access point for the target computer and server, complete the following steps: a. Click Go To > Deployment > Provisioning Computers. b. Select the target computers for which you want to set up the service access point. c. From the Select Action menu, click Add Credentials > SSH and SCP. d. In the Add Credential Pair dialog, click the Create RSA Credential option. e. Specify a user name, private key and passphrase. f. Click OK. You have now configured RSA credentials and set up a server service access point for the target computer and a client service access point for the server.
Bulk data distribution and storage

The dynamic content delivery is one of the core components of Tivoli Provisioning Manager, which uses depot servers in defined regions to distribute uploaded files to any number of target computers. Using the dynamic content delivery component, you can upload or publish files to a file repository called a depot server. The depot server then replicates the file to the depot servers specified in the publishing request. When a target computer downloads a file, the target opens connections to multiple depot servers or peers, and simultaneously retrieves different segments of the file from different systems. The file segments are then reassembled on the target computer. With this design, multiple targets can quickly download files with a minimal impact to your network infrastructure. The dynamic content delivery component provides the following features: v Scalable design: You can add depot servers to accommodate the needs of your network. v Optional peer-to-peer file sharing: A file can be downloaded from peer systems that have previously downloaded the same file. v Adaptive bandwidth control: You can throttle the transfer rate from both depot servers and peers to minimize the impact of downloads on existing network traffic from other applications. v Automatic replication of files to depot servers near the network location of the targets requesting the file. v Optional encryption of files. The following elements are used by the dynamic content delivery for software distribution:
810
Management center The dynamic content delivery management center, installed on the provisioning server, provides centralized control of the upload, replication, and download of files. It also monitors the state of depot servers and stores file data and download statistics. It performs the following functions: v Maintains a catalog of the files stored on each depot server and peer. v Stores the configuration parameters of each depot server. v Directs the replication of uploaded files. v Authorizes clients to download a file. v Generates and authenticates download plans. v Stores information such as file data, user data, region information, download statistics in the database. v Monitors the state of depot servers. v Communicates with the database. The dynamic content delivery management center maintains a record data set for the managed bulk data. The branch depot servers maintain a working data set which is a cache of the management data set. To enhance performance, the management elements implement a cache pre-fill strategy in which data is distributed to the branch elements, in advance of when it is needed on the target computers, at the branch office. Depot servers A depot server is a system that stores files for distribution. Files are uploaded to a depot server using a client or subagent. By default, uploaded files are stored in the data directory in the path in which the depot server is installed. Depot servers can replicate uploaded files to other depot servers to optimize the efficiency of network traffic. Target computers download the uploaded files and install them. v Each depot server is assigned to a region. Regions are used to group systems that are located near one another to optimize upload, replication, and download times. v You can minimize the impact of downloads on network traffic by configuring adaptive or static bandwidth control for a depot server: Adaptive bandwidth control enables the depot server to automatically increase or decrease its transfer rate depending on the level of network traffic. Static bandwidth control limits the transfer rate of the depot server to a specified number of kilobytes (KB) per second. v You can define the number of concurrent activities included in each activity plan when publishing software and patches. When you publish software products or patches to a depot, Provisioning Manager generates an activity plan. By default the activity plan contains five concurrent activities. If you want to change the number of concurrent activities, perform the following steps: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click Variables. 3. Click New Row and add the following settings: Variable Type Publish software activity concurrency level Component Entire System Value Type the value of the property with the required number of concurrent activities. The default value is five. v You can designate a depot server as a preferred upload server. Preferred upload servers are selected before other depot servers to receive uploaded files. If no preferred upload server is available, another depot server is selected to receive the uploaded file.
811
Consider the following points for the Preferred upload server setting: Design at least one depot server as the preferred upload server. Using the Preferred upload server option provides a way to promote a depot server's precedence to an initial upload server during the file publishing process. Setting up this option only impacts the choice of the initial upload server (or the first server selected to add the file to a depot server) in the dynamic content delivery system. From there, replication is performed in the background to send that file to other servers in the dynamic content delivery system, and with that, this option has no further value. To take advantage of this special designation, use valid criteria when selecting a preferred upload depot server, such as: - High availability. - Close proximity to the publishing point into the dynamic content delivery system. - High network bandwidth availability. - Large available disk space. - Good administrator monitoring of uptime and resources. Using these criteria ensures the quickest initial (first upload) publishing times with minimal failures. More depot servers can be designated as preferred upload servers. In this case, the publishing process allows for some load balancing during consecutive publishing operations, to make use of the greater number of resources. - As a general recommendation, you might want to designate about 10-20% of your depot servers as preferred, which can be scoped by region. For example, if you had ten depot servers in your region, you can have the two best servers (based on the criteria enumerated previously) designated as preferred upload depot servers. These two depot servers are selected with higher precedence of the eight other depot servers, and from some load balancing between them. - A preferred depot server can be selected as the initial upload server, which is not included in your publishing list (target list). This selection is only temporary, and the file is removed from that server when all depot servers have been replicated to. - It is not recommended that you overuse the Preferred upload server setting, or it will thin its value in the overall system. If every depot server is set up as preferred, no depot server can benefit with this precedence against another server. - Avoid setting depot servers in a branch office to preferred. In some scenarios, the Preferred upload server setting might conflict with the Minimize In And Out Traffic zone setting, if the depot server resides in that zone definition. In these cases, the Minimize In and Out Traffic setting will prevent files from being published to the preferred depot server. The Minimize In and Out Traffic setting is typically used to help define a branch office scenario, and thus has a rule that prevents publishing into those branches from outside that branch. Regions and zones Regions and zones provide a mechanism to map out the configuration of the network to provide the management center with the information needed to produce optimal plans when transferring data from one host to another. A region is a geographical grouping of systems (depot servers, peer servers, and clients). More than one region can be created to separate one group of systems from another group of systems. Systems within the same region are considered before other regions when distributing data. One or more regions can be created as needed. A minimum network configuration consists of at least one region and one depot server. A region consists of one or more zones. Systems within a zone are considered before systems within the same region when creating upload and download plans.
812
Depot servers are configured to regions, not zones. A depot server is manually mapped to a region upon its registration. Clients and peer servers are mapped to a region through zones. A depot server can belong to only one region, but a region can have more than one depot server. Zones can be defined as IP address ranges or a DNS domain. A depot server is mapped to a domain zone upon registration when specifying the domain served. The zones are used to determine the depots and peers that are nearby a target computer when the target needs to download a file. Unlike a DNS domain-defined zone, a zone that is defined as an IP address range can also be used to determine the best depots to publish to when performing dynamic publishing for a set of targets. The management center uses the configuration of regions and zones to select the best depot server for a client request, such as a request to download a file. Without regions and zones, clients connect to depot servers and other peers randomly. When a client is not assigned to any configured zone, it is considered unclassified. Unclassified clients connect to depot servers and peer servers, randomly, thus not utilizing the network efficiently. Configuring zones result in better use of the local area network thus reducing the wide area network usage. In a branch office scenario, you can create a region for depot servers in the branch office. Then you can upload a file to a depot server in the branch office and then replicate the file to other depot servers in the branch office region.
Downloading files
Files that have been uploaded to depot servers can be downloaded by target computers and installed. The file download using the distribution infrastructure includes the following processes: 1. An agent initiates the download of a file. 2. The client subagent requests a download plan from the management center. 3. The management center authenticates the requestor of the file and verifies that the requestor has permission to download the file. 4. The management center generates a download plan that includes a list of available depot servers and peers specified in the publishing requests or chosen by proximity to the client subagent and past performance. 5. The client subagent pulls the file from one or more depot servers or peers. If data is pulled from multiple systems, the client subagent pulls segments of the file from each system and then reassembles the data into a single file. 6. The client subagent computes a checksum to ensure the integrity of the downloaded file. 7. The client subagent returns the transfer rates of each depot server to the management center for use in the creation of future download plans. Note: The default time interval for a successful file distribution to targets is set to two hours. A file distribution that has not successfully completed within two hours can be considered failed. If required, you can customize this interval to accommodate the distribution of larger files to larger numbers of targets. For more information, see the Overriding the default distribution time interval on page 605 topic.
The dynamic content delivery management center

The dynamic content delivery management center provides centralized control of the upload, replication, and download of files. It also monitors the state of depot servers and stores file data and download statistics. The management center performs the following functions: v Maintains a catalog of the files stored on each depot server and peer. v Stores the configuration parameters of each depot server. v Directs the replication of uploaded files.
813
v v v v v
Authorizes clients to download a file. Generates and authenticates download plans. Stores information such as file data, user data, region information, download statistics in the database. Monitors the state of depot servers. Communicates with the database.
When you publish a new file, the management center authorizes the upload and replicates the file to depot servers or peers located around the network. When a client requests a file, the management center authenticates the requestor of the file and verifies that the requestor has permission to download the file. Next, the management center generates a download plan that includes a list of depot servers and peers from which the client can download the file. The management center selects these depot servers based publishing requests or on their location and past performance history. After the download completes, the client notifies the management center whether download was successful and the sends the file transfer rates achieved during downloads. The management center stores this data for use in creating future download plans. The following components comprise the management center: Download plan generator The component of the management center that generates download plans. Peer manager The component of the management center that keeps track of the files stored on each client. The download plan generator uses the peer manager to create the lists of peers included in a download plan. Monitoring agent The component of the management center that periodically checks the health of the depot servers. If problems occur, the monitoring agent can attempt to restart a depot server or send a warning e-mail to a system administrator. Distribution agent The component of the management center that controls the distribution of files to depot servers. When you publish a file, the distribution agent manages the replication of the file to the depot servers that you specify. When you delete a file, the distribution agent deletes the file from the specified depot server that stores the file. Trimming data from the dynamic content delivery management center database: Data about deleted files or old peer data can affect the performance of the dynamic content delivery management center database. To reduce the impact on the database performance, you need to periodically trim the historical and peering data. Removing data from the management center database cannot be undone. Back up your database before performing the data trimming operation. Trimming historical data: To trim the historical data, use the dynamic content delivery administration console to complete the following steps: Procedure 1. Click Settings > Trim Historical Data. 2. To automatically remove historical data in the background (run at regularly scheduled times as determined by the management center):
814
a. b. c. 3. To a.
Select the Automatically trim historical data in the background check box. Enter the number of Days of data to preserve. Click Update. manually remove historical data: Clear the Automatically trim historical data in the background check box.
b. Specify the cutoff date for the deletion operation in the Trim all database data before field. All records for files deleted before this date will be deleted. c. Click Trim Historical Data. Results The historical data is deleted from the management center database. Trimming peering data: To trim the old peer data, use the dynamic content delivery administration console to complete the following steps: Procedure 1. Select Settings > Trim Peer List. 2. Specify the cutoff date for the deletion operation. All records for peers that have not contacted the management center since this date will be deleted. 3. Click Trim Peer List. Results The old peer data is deleted from the management center database.
Peer-to-peer file sharing

Peering enables target computers to download files from peer systems and depot servers. By default, peering is enabled when you install the management center. When peer-to-peer file sharing is disabled, target computers can download files only from depot servers. When peer-to-peer file sharing is enabled, targets that do not have the full dynamic content delivery client installed can share downloaded files with peer systems on the network, provided you create an IP zone with an IP address range that all endpoints match. Peer-to-peer file sharing enables you to shift download traffic from the WAN to LANs. Peer-to-peer file sharing enables target computers to act as miniature depot servers. Before submitting distribution operations, publish the software packages or files. After the files are published, when a target downloads a file from a depot server, the file is cached on the local system. If other targets request a file that is already cached on a peer system, the management center can instruct the requesting client to download the file from a network peer. Disabling and enabling peering: Peering enables computer systems to share downloaded files with peer systems on the network. By default, peering is enabled when the agent is installed. Peering is controlled at the zone level and also using the dynamic content delivery management center. If necessary, you can disable peering either before installing the agent or after installing it. v Before installing the agent, you can disable peering by configuring the peering parameter directly in the configuration template of the dynamic content delivery client software configuration template.
815
v After installing the agent, you can disable peering by running the CDS_Set_Parameter.wkf provisioning workflow, which will turn peering off and update the configuration template for the TCA-Subagent CDS Client URL Handler software installation accordingly. To disable peering in the configuration template, before installing the agent, you must set the value of the peering parameter in the TCA-Subagent CDS Client URL Handler Default Parameters template to false. The default value is true. When you install the agent, the peering will be turned off, based on your changes to the configuration template. To disable peering after installing the agent, you can run the CDS_Set_Parameter provisioning workflow, which requires two parameters, the DeviceID of the target computer, and the ParameterName whose value needs to be set to peering, and its value, ParameterValue, set to false. Similarly, you can modify other client parameters. The provisioning workflow runs successfully, disables peering, and updates the configuration template accordingly. The subagent will be restarted automatically during the parameter change. Enabling peering on a dual stack of IPv4 and IPv6 targets: Peering enables computer systems to share downloaded files with peer systems on the network. By default, peering is enabled when the agent is installed. If you have a dual stack of IPv4 and IPv6 targets, you can force the target computers to use IPv6. Perform the following steps: Procedure 1. Browse to and open the cdsclient.properties file. The file is located in tca install dir/runtime/agent/ subagents, where tca install dir varies depending on the operating system UNIX /opt/tivoli/ep Linux /opt/tivoli/ep AIX /usr/tivoli/ep
Windows c:\Program Files\tivoli\ep 2. Create a property named domain and specify the IP domain the system is in. 3. Replace the value of the user_ip parameter with an IPv6 IP. 4. Change the value of the initial_login_done parameter to false. 5. Restart the agent using the endpoint.[sh|bat] restart command. The command is located in the tca_install_dir/runtime/agent/bin directory. Results The targets computers now use the IPv6 protocol.
Security and authentication in the branch office

Communication between the dynamic content delivery management center, depot servers, and client subagents at the branch office can flow through firewalls. Authentication of client subagents is obtained through the common agent services. Specific ports must be available for the common agent and dynamic content delivery components. You can optionally change some of the default port numbers. The dynamic content delivery management center and depot servers use secure SSL connections. SSL uses certificates for authentication. An SSL certificate consists of a public key and a private key. The
816
public key is used to encrypt information; the private key is used to decrypt it. The management center can connect to depot servers directly, without using proxies. The client subagents are authenticated with certificates obtained through the common agent services. The management center registers as resource manager as part of the common agent services infrastructure. The following default port numbers are used by the dynamic content delivery depot servers and client subagents:
Table 149. Default dynamic content delivery ports on target computers Ports 2100 Use Enables communication between: v The common agent and the dynamic content delivery depot servers. v dynamic content delivery depot servers. v The dynamic content delivery management center and the dynamic content delivery depot servers. 9010 or 9015 Enable communication between the common agent and the dynamic content delivery management center. Enable communication between thedynamic content delivery client subagent and the dynamic content delivery management center. Secure SSL Connection security Secure SSL
9045 or 9046
Secure SSL
Regions, zones, and depot servers

The scalable distribution infrastructure includes regions, zones, and depot servers that are used in the software distribution process. Region A region is a geographical grouping of systems (depot servers, peer servers, and clients). Zone A zone is an IP range or domain that is used to logically group computers into regions. You can define one or more zones for each region.
Depot server Depot servers are systems that store files for distribution. Distribution files are uploaded to a depot server using a client. Uploaded files are stored in a directory that is specified when the depot server is installed. Depot servers can replicate uploaded files to other depot servers to optimize the efficiency of network traffic. Regions and zones provide a mechanism to map out the configuration of the network to provide the management center with the information needed to produce optimal plans when transferring data from one host to another. More than one region can be created to separate one group of systems from another group of systems. Systems within the same region are considered before other regions when distributing data. One or more regions can be created as needed. A minimum network configuration consists of at least one region and one depot server. A region consists of one or more zones. Systems within a zone are considered before systems within the same region when creating upload and download plans. Depot servers are configured to regions, not zones. A depot server is manually mapped to a region upon its registration. Clients and peer servers are mapped to a region using zones. A depot server is mapped to
817
a domain zone upon registration when specifying the domain served. A depot server is mapped to an IP range zone based on its IP address. A depot server can belong to only one region, but a region can have more than one depot server. Adding and removing regions: Regions are used to group depot servers that are located near one another to optimize upload, replication, and download times. A depot server is either manually mapped to a region before its registration or automatically mapped to a region after its registration. Clients and peer servers are mapped to a region by zones. A depot server can belong to only one region, but a region can have more than one depot server. Before you can add a depot server, the region it belongs to must be defined. For information about adding a new region, see Creating the infrastructure for scalable software distribution on page 572. After the region is added, you can perform the following actions with it: v To view more details for a region, find the region in the list and click its name. v To modify the name or description of a region, find it in the list and click Properties. There are options available to control access to zones and servers, for example: 1. Incoming-blocked : Prevent other zones accessing servers in this zone. 2. Outgoing-blocked: Prevent this zone from accessing servers in other zones. 3. Minimize-traffic: Prevents systems in other zones from using this zone for uploads and downloads. Removing regions: To be able to remove a region, you must first ensure that it has no depot servers assigned to it and no zones defined. If depot servers are assigned to it or zones are defined within the region you want to remove, you must remove the depot servers and the zones first and then remove the region. Adding zones: A zone can be used to define an IP range or a domain name within a region. Zones are used to group systems associated with a region. One or more zones can be created for each region. Regions can be generic, without a real network definition, or they can be specific, when zones are used to define domain names within the region. Before you begin When you create a zone, specify a region for the zone. New zones can only be added after a region has been defined. Zones can be defined as IP address ranges or a DNS domain. v An IP range defines a range of IP addresses, for example, 34.34.130.1 to 34.34.130.250. Systems having an IP address within this range are included in the zone. Unlike a DNS domain-defined zone, a zone that is defined as an IP address range can also be used to determine the best depots to publish to when performing dynamic publishing for a set of target computers. v A domain defines a group of host names, such as lab.example.com. Systems with a host name that includes this domain are included in the zone. A depot server is mapped to a domain zone upon registration when specifying the domain served. The zones are used to determine the depots and peers that are nearby a target computer when the target needs to download a file.
818
Tip: When DNS domain zones are used, it is important to define the Domain served field on depot servers, to ensure that the depots are included in the domain when files are dynamically published to them. For more information, see Adding depot servers. IP ranges or domains can be used to control distributions to certain systems or networks in your enterprise. For example, the domain lab.example.com can be specified to create a zone for all systems in the lab domain, or different IP ranges can be used to create one zone for systems on dial-up connections and another zone for systems with broadband connections. Zones enable you to optimize upload and download times. Using zones, you can group systems that are located near one another geographically or are linked across fast network connections. Without zones, clients connect to depot servers and other peers randomly. Adding depot servers: To be able to publish the software files that you want to distribute and install on target computers, you need to define the regions, zones, and depot servers that will be used in the software distribution process. Before you begin v New depot servers can only be added after a region has been defined. For more information, see the Adding and removing regions on page 818 topic. v Also, the server that will be configured as a depot server needs to be discovered first. Discovery adds the depot server to the data model. For more information see Regions, zones, and depot servers on page 817. v If you have enabled IPv6 addressing support for the scalable distribution infrastructure, the operating system on depots must be able to communicate appropriately with other computers in your environment. For example, if you have both IPv4 and IPv6 target computers, the depot can be configured to support both IPv4 and IPv6 addressing, or you can set up separate IPv6 and IPv4 depots to support communication with each type of IP addressing. If all communication with the depot will use IPv6 addressing, the depot can be configured to support IPv6 only. v Note that regardless of your language settings, Server Traffic statistics are displayed in the following format: 0.0. The new depot server with the specified properties is added and registered with the management center. It is also listed on the Depots Management page, and its displayed status is Active. For information about how to add a depot server, see Creating the infrastructure for scalable software distribution on page 572. You can perform the following actions with the depot server: v View more details for a depot server. v Modify depot server properties, designate the depot server as a preferred upload server, or install the depot agent services on the depot server. Preferred upload servers are selected before other depot servers to receive uploaded files. If no preferred upload server is available, another depot server is selected to receive the uploaded file. Preferred upload servers must be globally accessible, not blocked by a firewall from clients. If a preferred upload server is not included in the initial publishing of a file, a temporary preferred upload server is chosen by the Dynamic Content Delivery management center for the initial publishing. After all the replications are completed to the chosen depots, the file will be removed from this temporary preferred upload server. The criteria for a preferred upload server must include the following: High availability: Monitor the depot using the check status of a depot on the provisioning server. These depots must always be in an active status. Alternatively, you can use the Event Console in the Dynamic Content Delivery Admin Console. Proximity to the provisioning server or the management center. High network bandwidth availability.
819
Large available disk space. You cannot have a preferred upload server in a zone with "Minimize traffic in and out of zone" set to enabled or incoming-blocked. A publish to this preferred upload server will fail. v Define the number of concurrent activities included in each activity plan when publishing software and patches. When you publish software products or patches to a depot, Provisioning Manager generates an activity plan. By default the activity plan contains five concurrent activities. If you want to change the number of concurrent activities, perform the following steps: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click Variables. 3. Click New Row and add the following settings: Variable Type Publish software activity concurrency level Component Entire System Value Type the value of the property with the required number of concurrent activities. The default value is five. Tip: To view information about depot server status from the Start Center, expand the Depot status portlet. Accessing the Tivoli Provisioning Manager Dynamic Content Delivery administration console: You can start the Tivoli Provisioning Manager for Dynamic Content Delivery administration console from the Manage Depots page. The dynamic content delivery administration console provides read-only access to additional information about regions, zones, depot servers, and files. You can also view file transfer information, download plans used during the file distribution, and global configuration information. A number of reports are also available, which you can use to filter and display event details, obtain additional information about file downloads, an overview of the file traffic, or details about the file traffic per region or zone. The dynamic content delivery administration console can be accessed from the Manage Depots page. To access the functions of the administration console, use the menu on the left side of the screen. To display the context-sensitive Help, click the question mark button at the upper right corner of the Welcome page. Click Close on the left menu to close the window. Migrating published files after changing the data directory on a depot server: You can change the Data directory for a depot server. You can move the directory to a different path on the same partition, or to a different partition. If you perform this operation, also manually migrate all the files that have been published to that depot server to the new cache location, otherwise problems can occur when installing or distributing software. To manually migrate the published files to the new data directory: Procedure 1. Stop the common agent on the depot server. This operation stops the depot server and client subagents. 2. Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. Tip: To perform this task from the Start Center, click Dynamic Content Delivery Configuration under Provisioning administration applications. 3. Click the Depots tab.
820
4. Change the data directory. 5. Create the directory in the dynamic content delivery cache location, if you have not already done so. For example, if the current directory is abc (C:\Program Files\Tivoli\ep\runtime\agent\subagents\ cds\depot\abc), create a xyz directory (C:\Program Files\Tivoli\ep\runtime\agent\subagents\cds\ depot\xyz). Note: The subdirectory /files/1 are created automatically inside the new xyz directory. 6. Copy or move all the directories and files under abc to xyz. 7. Start the common agent on the depot server. This operation starts the depot server and client subagents and adds the files to the new location. Important: If the common agent is not started on the target computer, the newly published files are not added to the new location. If you change the publish file location and then try to publish the file, you might get either of the following error messages:
COPDEX040E: An unexpected deployment engine exception occurred COPINF002E: Failed to publish file: C:/Program Files/IBM/ tivoli/tpm/repository/<file name>with id 5979 to CDS depot servers. CTGDEC030E: The management center was unable to find potential depot servers to upload the file. The file,<file name>, could not be uploaded. Make sure that there is at least one active depot server available,that it has enough space to store the file, and that it is not in an unreachable or restricted zone.
To resolve these errors, restart the common agent. Results You have finished migrating the files published to the depot server to the new cache location. Removing depot servers: You can remove a depot server when it is no longer needed. Also remove depot servers before uninstalling Tivoli Provisioning Manager. When the depot server is deleted, it is also unregistered from the management center. The agent is not removed from the depot server. When deleting the depot server, also uninstall the depot stack. Removing depot stacks: To remove a depot stack, you can use the procedure you use to uninstall any agent. However, you can also remove a depot stack as follows: Procedure 1. Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. 2. On the Depots tab, select the Mark row for delete icon. 3. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. 4. In the Select Action menu, click Uninstall. 5. Select the target and submit the task. Automation package for management of large numbers of regions, zones, and depot servers:
821
You can create, update, and delete large numbers of zones, regions, and depot servers using provisioning workflows and scripts. The provisioning workflows and scripts provided with the DcdAdmin.tcdriver automation package refer to an .xml file that conforms with the dcdAdmin.dtd file, in which specific settings can be defined for the zones, regions, and depot servers that are used for the large-scale software distribution tasks. An extension to the automation package includes the ability to define isolated zones or exception depots, or configure depot access rules that can be used with specific attributes for the isolated zones. The elements defined in the dtd file cannot be imported using xmlimport. Instead, provisioning workflows are provided to create, update, and delete zones, regions, and depot servers. A sample xml file, dcdAdminSample.xml, which you can customize according to your needs, is provided in the following directory. v v
Windows UNIX
%TIO_HOME%\tools\DcdAdmin $TIO_HOME/tools/DcdAdmin
The DcdAdmin automation package provides a number of provisioning workflows and scripts. v The provisioning workflow file names start with DCD_*.wkf. The command line interface can be used to invoke any of the provisioning workflows. v The scripts are located in the following directory.
Windows UNIX
%TIO_HOME%\tools\DcdAdmin $TIO_HOME/tools/DcdAdmin
To be able to run the scripts, you must be on the provisioning server.

Additional details about using the DcdAdmin automation package are available in the automation package documentation. To view the documentation: 1. Click Go To > Administration > Provisioning > Device Drivers. 2. In the list of device drivers, click DCDAdmin. 3. Click the Documentation link.
Job distribution and management

The device manager service provides a flexible solution for online and offline device management, regardless of connection models or device capabilities. The device manager service mainly performs job management operations, but can also be used for device configuration, inventory data collection, and software distribution. The management features available for particular device types can be tailored based on device and operating system capabilities. Management actions performed using the device manager service are called jobs. Jobs can be applied to or targeted to individual devices or device groups. You can also monitor the job progress on various devices. If applied to a specified device, a job is run when the device connects to the device manager server. The server maintains a history of job status for all jobs and all devices. The device manager service provides support for federated job management. Web services interfaces are used to ensure communication with the device manager server and to submit jobs. To build a federated environment, a device manager server is configured to act as a federator. The device manager federated agents at the branch offices are configured to communicate with the federator periodically, and are
822
treated as any other frequently disconnected pervasive devices. The device manager federator provides a capability for submitting jobs and collecting results from the intermittently connected device manager federated agents. Currently, a two-tiered federated environment is supported, including the following elements: Device manager federator The device manager federator, installed on the provisioning server at the enterprise, is configured to act as a federated server. The federator implements a job distribution policy that delivers incoming jobs to all of the regional federated agents that are configured to communicate with it. Currently, a two-tiered federated environment is supported. Device manager federated agents Device manager federated agents are installed as device manager servers at the branch and are configured to communicate with the federator periodically to get jobs and to distribute them to the set of currently known clients installed on the target computers in the branch. The agents determine whether there is a federator job available to be distributed to the clients, and work in conjunction with a federator plug-in to run the job. When a job is run, a JDS_Command provisioning task, in XML format, is created on the agent, and targeted to all of the clients that are known to that agent. Device manager subagents Clients are installed as device manager subagents on the managed systems or targets at the branch, and are used for receiving command jobs from and returning results to the federated agents. Command jobs are automatically propagated out to the clients at the branch offices and the results gathered are returned to the device manager federator, which in turn returns them to the provisioning server.
Deploying the device manager service

The following deployment options for the device manager federator and the device manager federated agents are supported.
Device manager federator

The device manager federator can have either of the following deployments: v Device manager deployment that communicates with either a DB2 or Oracle Database. The device manager deployment options are an unmanaged server (one computer running all servers and services required by the device manager, installed on a standalone WebSphere Application Server; the device manager database is installed on the same computer) or an unmanaged server with a remote database. v Lightweight device manager server that communicates with either a DB2, or Oracle Database.
Device manager federated agents

A device manager federated agent can have either of the following deployments: v Device manager deployment that communicates with either a DB2 or Oracle Database. The device manager deployment options are an unmanaged server or an unmanaged server with a remote database. v Lightweight device manager server that communicates with either a DB2, or Oracle Database.
Security and authentication

Communication between the device manager federator and the device manager federated agents can flow through firewalls. The device manager federator and the device manager federated agents use HTTP and rely on agents contacting the federated server for work. Client-to-server and server-to-server interactions can also occur over SSL connections. The device manager subagents and the federated agents can use SSL connections.
823
The subagents are authenticated with certificates obtained through the common agent services. All device manager servers and lightweight device manager servers in the branch office and the enterprise must register as resource managers as part of the common agent services infrastructure. When registered, these servers will keep up-to-date with respect to SSL certificate management for secure communications with the managed clients. If subagents are not authorized, either they will not have certificates or their certificates will be on the certificate revocation list. The following default port number is used by the device manager federated agents and subagents:
Table 150. Default device manager service ports on target computers Ports 9046 Use Enables communication between the device manager subagent and the device manager federated agent. Connection security Secure SSL
Job processing
The device manager federator provides the "federation" capability for submitting jobs and collecting results from the intermittently connected device manager federated agents. The job instructions are typically series of encapsulated Job Execution Service (JES) commands in XML format and are stored as a job parameter in the device manager JDS_COMMAND job. The device manager federator and federated agents do not parse the job instructions or results. Their role is to just pass the job instructions through the device manager servers to the device manager subagents and collect the results: v The device manager federated agents periodically contact the device manager federator to see if there are any jobs waiting in the job queue. If JDS_COMMAND jobs are awaiting, they are automatically propagated to the federated agents. v The device manager subagents intermittently or periodically connect with the federated agents to see if there are any jobs waiting in the job queue, obtain the jobs, process them, and send the job results back to the federated agents. v From the federated agents, the job results are then returned to the federator, where they are finally retrieved by the provisioning server. Subagents periodically connecting to the federated agent: Often, the job processing occurs between the federated agent and the subagent on the target computer, but the federated agent does not have network connectivity with the federator. Every time a federated agent connects to the federator, the federator sends a request to gather job results. That request has a job priority of 2 so it typically runs first, but jobs with a priority of 1 can be created to run before the job results are gathered. All operations to device manager subagents through the JDS_COMMAND flow only through Job Execution Service (JES) and common agent services interfaces. All interfaces to other subagent components are made available through common agent services. Real-time control or queued control are possible through common agent services interfaces. To ensure against rerunning jobs from the beginning, the tpmOSGi agent on the federator and the Job Execution Service agent support checkpoint and restart during job processing. So, if a subagent disconnects from the federated agent or is restarted, the job resumes at the last checkpoint to avoid processing the job from the beginning. Sending job results: The federated agent keeps track of which records are sent so no duplicate records are sent and if there is a loss of connectivity or an error, records can be resent without duplication. When there are multiple federated agents at a branch office, the job results are tracked so that the same job results are not sent by more than one federated agent. When the federated agent receives a confirmation
824
that the federator received and successfully processed the job results, it deletes the branch job history records in the range for the matching host name. This removes all records that were successfully sent to the federator. If there is an error while storing the job results in the database on the provisioning server, an error message is returned to the federated agent. If the federator or the federated agent is powered off before the processing of the job results is completed, those job results are resent the next time the federated agent connects to the federator. When the job results threshold is reached on the federator, an HTTP post is sent to the provisioning server informing that job results are ready for gathering. If the provisioning server is busy, the results can be gathered from the federator at the next periodic poll from the provisioning server. Overriding the default job expiry interval: Each job has an expiry interval. By default, jobs submitted to the device manager service are set to expire after 336 hours (two weeks). This expiry interval starts at the task submission time. For example, a target computer that requires more than two weeks to ask for a new job, does not receive the job from the device manager service, because the job would have expired by then. If necessary, you can override the default job expiry interval by defining a DMS.Job.Window.In.Hours global variable and setting up its value to whatever you want the new job expiry interval to be.
825
826
Chapter 8. Checking compliance

Compliance management eases and automates the task of ensuring that each computer in your environment meets the required security standards and matches the software configuration that is appropriate to its role in your enterprise. Using the compliance management function of Tivoli Provisioning Manager, you can create the following types of compliance check: Security Security compliance checks can be used to check for a variety of security issues. You can select from a list of predefined security checks. For example, you can check for the existence of hard disk and power-on passwords or for the values of firewall settings. You can also define your own security checks to cover situations that are not included in the predefined list. Software and patch Software and patch compliance checks are used to ensure that computers have the appropriate software products, software stacks, and patches installed, and that inappropriate software is not installed. You can define groups of software and specify that one software product from the group must be installed. For example, a software group can include all approved antivirus software, and a compliance check can ensure that all target computers have at least one of the approved antivirus products installed. Software configuration Software configuration compliance checks can ensure that applications installed in your environment maintain required configuration settings. You can create your own discovery method to obtain configuration information from a different source. Configuration information collected by TADDM can be replicated in the data model using a discovery method delivered with Tivoli Provisioning Manager. You can create your own discovery method to obtain configuration information from a different source. You can define compliance checks for individual computers or for groups of computers. For example, all computers running Windows operating systems can be grouped together for Windows security compliance checks. After you have selected the compliance checks to be performed on a computer or group of computers, you can start compliance checking immediately or define a schedule for the checks to run at a future date and time, with an option to repeat checks on a regular basis. When compliance checks are performed for a computer or group of computers, the system performs a discovery that collects the information that is required for the compliance checks that were defined. If any noncompliance issues are detected, recommendations are generated. You can review the recommendations and approve them as appropriate. The following noncompliance issues can be automatically resolved: v Software and patch issues. Note: Automatic installations and uninstallations can be performed for software that has a software definition that implements the SoftwareInstallation.Install and the SoftwareInstallation.Uninstall software device operations. v Software configuration issues relating to: IBM DB2 Universal Database Enterprise Edition Version 8 IBM WebSphere Application Server Version 6 IBM HTTP Server Version 2.0
827
Oracle Version 10g v Windows Antivirus, Windows Power-On Password, and Windows User Password security checks. When recommendations related to these types of issue have been approved, they can be run immediately or scheduled to run at a convenient time. When you run or schedule an approved recommendation, a workflow is created to resolve the noncompliance issue. For example, if software that must not be present was detected, an uninstallation activity is created. Automation packages are available in the IBM Integrated Service Management Library for some of the noncompliance issues that are not supported by Tivoli Provisioning Manager workflows. You can also create your own automation packages for performing user-defined security compliance checks and remediation.
Compliance basics
Find out more about the compliance process, the key terms for compliance, who are the users that perform compliance checks, and what are the requirements that you need to verify before managing compliance. Review the troubleshooting information and the log files names and location for this feature and also additional resources that help you complete your Compliance Management tasks. After you have discovered resources, you can examine the software and security setup you have on them, and then compare that setup to your required setup in order to determine if they match. If they do not match, noncompliance occurs, and recommendations on how to fix the noncompliance issues are generated. v v v v Process User roles on page 831 Requirements on page 831 Key terms on page 832
v Troubleshooting on page 832 v Log files on page 832 v Resources on page 833
Process
The following diagram depicts a typical compliance process to determine whether the installed software, configuration, and security in your enterprise matches your required setup. If systems are noncompliant, Tivoli Provisioning Manager can make recommendations to fix them.
828
Discover computers
Verify compliance
The compliance process includes the following tasks: 1. Discover computers The data model must include information about all the computers for which you want to check compliance. Information is added to the data model by running a computer discovery. Ensure that this is done when the system is first set up and when any new computers are added to the environment. 2. Install the Tivoli Common Agent The Tivoli Common Agent stack is required to perform security compliance checks and remediation actions. It can be installed on all discovered computers during the computer discovery if you define the discovery using discovery wizards 3. Discover software configurations If you are using Tivoli Application Dependency Discovery Manager, you can use the software configuration information it collects to perform software configuration compliance checks. To do this, a TADDM discovery must be run to import the up-to-date information collected by Tivoli Application Dependency Discovery Manager into the data model. 4. Create provisioning groups Compliance checking can be defined for groups of computers and for individual computers. If the same set of compliance checks apply to several computers, define a provisioning group to include the computers with the same compliance requirements. 5. Create software configuration templates Software configuration templates represent the required configuration settings for an application. A template is created by copying the application configuration from a computer where the application
829
is known to have the correct settings. The computer must be monitored by Tivoli Application Dependency Discovery Manager and its configuration must have been imported to the data model using a configuration change discovery. 6. Create compliance checks Compliance checks define the compliant state of the computer or group of computers to which they apply. A set of compliance checks can include the following: v Security requirements, for example password rules and firewall requirements. v Required software and patches v Prohibited software v Requirement to install one software product from a group. v Required software configuration. 7. Run compliance checks Compliance checks can be run immediately or scheduled to run at a convenient time. If the schedule option is used, the checks can be scheduled to repeat at regular intervals. Compliance checking can include a scan of the target computers, to ensure that the information against which the checks are made is completely up-to-date. Depending on the types of compliance checks requested, a series of discoveries are performed to collect all the relevant information. If scans are required, the task must be performed the provisioning configuration librarian. If you already have regular discoveries scheduled, you can choose to perform the compliance checking without a scan. The compliance analyst can perform the checks without the scan. 8. Review and approve recommendations When the compliance checking process detects a noncompliance situation, it generates a recommendation that identifies the action required. Recommendations must be approved before any automated action can be taken to resolve the noncompliance issue. It is possible to set up compliance checks so that they are automatically given a status of "Approved". 9. Perform recommended actions Tivoli Provisioning Manager provides workflows to automate the following actions required to resolve the following noncompliance issues: v Installation of software and patches v Uninstallation of software and patches, provided that they were installed using Tivoli Provisioning Manager v Reconfiguration of: IBM DB2 Universal Database Enterprise Edition Version 8 IBM WebSphere Application Server Version 6 IBM HTTP Server Version 2.0 Oracle Version 10g v Application of Windows Antivirus, Windows screen saver, and Windows user password security rules. Automation packages can be created to resolve other issues. 10. Verify compliance When actions have been taken to apply approved recommendations, the compliance checks can be rerun to ensure that all recommended actions have been successful. If a repeating schedule has been created, the success of the actions taken is automatically checked next time the compliance checks are scheduled to run. Note: Using Tivoli Provisioning Manager to run compliance checks and perform compliance remediation for the computer where Tivoli Provisioning Manager is installed is not supported.
830
User roles
You must be assigned to the appropriate user role to manage compliance.
Table 151. User roles Role Provisioning Administrator Description of role v Discover and group target computers. v Set up servers and infrastructure, including the installation of the Tivoli Common Agent on targets. Compliance Analyst Skills v A detailed knowledge of the provisioning environment. v Knowledge of the target operating systems. v Knowledge of Internet technologies. v Detailed knowledge of the security policies in force in the organization. v Regularly updated knowledge of security issues.
v Defines and runs the compliance checks required for computers or groups of computers. v Evaluates the recommendations produced when non-compliance issues are identified. v Reviews and approves recommended remedial actions.
v Performs and monitors the progress of any remedial actions. v Discover and group target computers. v Define software definitions to enable automation of remedial actions.
v Understanding of the software distribution process using the scalable distribution infrastructure. v A detailed knowledge of the software and hardware inventory v Knowledge of the target operating systems.
Provisioning Configuration Librarian
Requirements
User roles and requirements on page 835 Target computer requirements: Requirements for Windows target computers on page 556 Requirements for Red Hat Linux target computers on page 560 Requirements for SUSE Linux Enterprise Server (SLES) target computers on page 561 Requirements for AIX target computers on page 562 Requirements for Solaris Operating Environment target computers on page 563 Requirements for HP-UX target computers on page 565 v Software prerequisites on page 837
831
Key terms
compliance A state of being in accordance with established software and security specification on target computers, or the process of becoming so. recommendation When noncompliance occurs, recommendations are generated to suggest how to fix the noncompliance issues. remediation The task required to return a resource back to a specific state. Remediation can be policy driven (automated) or a manual effort based on audit reports or notification of a change.
Troubleshooting
v Troubleshooting compliance on page 858 v Log files for troubleshooting compliance v Compliance problems and limitations on page 864 v COPDSE messages v Support information about compliance v Contacting Support
Log files
Follow the steps below and review the indicated log files to recover from compliance problems: Web interface errors If you encounter Compliance Management errors in the web interface, check the following log for details: v v
Windows UNIX
%TIO_LOGS%\j2ee\console.log
Linux
$TIO_LOGS/j2ee/console.log
Compliance and remediation processing errors If you encounter compliance and remediation processing errors, check the following log for details: v v
Windows UNIX
Linux
$TIO_LOGS/console.log
Using SCM collector and SCMCollectorSubagent result XML files
The subagent and collector output XML files can be used for troubleshooting compliance-related problems. In o 1. Enable tracing for the common agent, as described in Setting log levels for Tivoli Common Agent 2. Run the inventory scan.
832
Resources
To learn more about compliance, see one of the following resources: v Tutorial: Managing compliance on page 844 v Example: Defining a multiple-rule security compliance check on page 854 v Example: Restricting software on page 855 v Example: User-defined compliance checks on page 856 v Compliance checks export and import tools on page 839 v For a description of a field in the Tivoli Provisioning Manager console, press Alt+F1.
Related links Chapter 8, Checking compliance, on page 827 Requirements on page 835 Tutorial: Managing compliance on page 844
Compliance process
It is important to understand the overall compliance process before you start managing compliance with Tivoli Provisioning Manager. The following diagram depicts a typical compliance process to determine whether the installed software, software configuration and security in your enterprise matches your required set up. If systems are noncompliant, Tivoli Provisioning Manager can make recommendations to fix them.
Discover computers
Verify compliance
The compliance process includes the following tasks:

833
1. Discover computers The data model must include information about all the computers for which you want to check compliance. Information is added to the data model by running a computer discovery. Ensure that this is done when the system is first set up and when any new computers are added to the environment. 2. Install the Tivoli Common Agent The Tivoli Common Agent stack is required to perform security compliance checks and remediation actions. It can be installed on all discovered computers during the computer discovery if you define the discovery using discovery wizards 3. Discover software configurations If you are using Tivoli Application Dependency Discovery Manager, you can use the software configuration information it collects to perform software configuration compliance checks. To do this, a TADDM discovery must be run to import the up-to-date information collected by Tivoli Application Dependency Discovery Manager into the data model. 4. Create provisioning groups Compliance checking can be defined for groups of computers and for individual computers. If the same set of compliance checks apply to several computers, define a provisioning group to include the computers with the same compliance requirements. 5. Create software configuration templates Software configuration templates represent the required configuration settings for an application. A template is created by copying the application configuration from a computer where the application is known to have the correct settings. The computer must be monitored by Tivoli Application Dependency Discovery Manager and its configuration must have been imported to the data model using a configuration change discovery. 6. Create compliance checks Compliance checks define the compliant state of the computer or group of computers to which they apply. A set of compliance checks can include the following: v Security requirements, for example password rules and firewall requirements. v v v v Required software and patches Prohibited software Requirement to install one software product from a group. Required software configuration.
7. Run compliance checks Compliance checks can be run immediately or scheduled to run at a convenient time. If the schedule option is used, the checks can be scheduled to repeat at regular intervals. Compliance checking can include a scan of the target computers, to ensure that the information against which the checks are made is completely up-to-date. Depending on the types of compliance checks requested, a series of discoveries are performed to collect all the relevant information. If scans are required, the task must be performed the provisioning configuration librarian. If you already have regular discoveries scheduled, you can choose to perform the compliance checking without a scan. The compliance analyst can perform the checks without the scan. 8. Review and approve recommendations When the compliance checking process detects a noncompliance situation, it generates a recommendation that identifies the action required. Recommendations must be approved before any automated action can be taken to resolve the noncompliance issue. It is possible to set up compliance checks so that they are automatically given a status of "Approved". 9. Perform recommended actions Tivoli Provisioning Manager provides workflows to automate the following actions required to resolve the following noncompliance issues:
834
v Installation of software and patches v Uninstallation of software and patches, provided that they were installed using Tivoli Provisioning Manager v Reconfiguration of: IBM DB2 Universal Database Enterprise Edition Version 8 IBM WebSphere Application Server Version 6 IBM HTTP Server Version 2.0 Oracle Version 10g v Application of Windows Antivirus, Windows screen saver, and Windows user password security rules. Automation packages can be created to resolve other issues. 10. Verify compliance When actions have been taken to apply approved recommendations, the compliance checks can be rerun to ensure that all recommended actions have been successful. If a repeating schedule has been created, the success of the actions taken is automatically checked next time the compliance checks are scheduled to run. Note: Using Tivoli Provisioning Manager to run compliance checks and perform compliance remediation for the computer where Tivoli Provisioning Manager is installed is not supported.
Requirements
Before you start working with compliance, ensure that you meet all requirements.

To perform the tasks in compliance, ensure that you have the required knowledge and access rights to perform your role.
Table 152. User roles Role Provisioning Administrator Description of role v Discover and group target computers. v Set up servers and infrastructure, including the installation of the Tivoli Common Agent on targets. Compliance Analyst Skills v A detailed knowledge of the provisioning environment. v Knowledge of the target operating systems. v Knowledge of Internet technologies. v Detailed knowledge of the security policies in force in the organization. v Regularly updated knowledge of security issues.
v Defines and runs the compliance checks required for computers or groups of computers. v Evaluates the recommendations produced when non-compliance issues are identified. v Reviews and approves recommended remedial actions.
v Performs and monitors the progress of any remedial actions.
v Understanding of the software distribution process using the scalable distribution infrastructure.
835
Table 152. User roles (continued) Role Provisioning Configuration Librarian Description of role v Discover and group target computers. v Define software definitions to enable automation of remedial actions. Skills v A detailed knowledge of the software and hardware inventory v Knowledge of the target operating systems.
Oracle and WebSphere Application Server prerequisites

Ensure that you have the correct Oracle and WebSphere Application Server prerequisites.
Defining the Service Access Point for computers discovered from TADDM
Ensure that you define the Service Access Point (SAP) for computers which have been detected using a TADDM discovery before running any recommendations on them. When a computer is discovered into the data model from TADDM, you need to create a SAP for a root or administrator user ID, before running any recommendations on this computer. To manually add the service access point to the computer, perform the following steps:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Identify and click the computer for which you want to add a SAP. 3. Click the Credentials tab. 4. Click Add Credentials > New Service Access Point. 5. Add the user name root or administrator. 6. Set a password for the root or administrator user ID. 7. In the Workflows tab, assign the appropriate workflows to the SAP. 8. Specify the Protocol Type and Application Protocol parameters. 9. Assign the created SAP to the Command execution and File Transfer sections. 10. Click Save .
What to do next
Now that you have manually added the service access point to the computers imported from TADDM, you can run any recommendations on them.
Setting Oracle parameters

If you have detected Oracle 10g using a TADDM discovery, before running any recommendations on it, you must set the Oracle administrator password. Ensure that you set the Oracle administrator password after running the compliance scan and check to avoid that SRT parameters are cleared when performing the scan.
Before you begin

If Oracle was installed using Tivoli Provisioning Manager and the parameter values of oracle_sys_password was already provided, you can skip this configuration. When a computer is discovered into the data model from TADDM, before running any recommendations on its Oracle software resource, perform the following steps:
836
Procedure
Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. Identify and click the computer on which Oracle was detected. Click Software tab. Locate the software installation of Oracle and click to see its Details page in the Software Resources application. 5. Expand the Software Resources tree and select Oracle to find the parameter named oracle_sys_password in the Template Parameters table. 6. Change its value to match the Oracle administrator password. 1. 2. 3. 4. 7. Click Save .
Setting WebSphere Application Server parameters

If you have detected WebSphere Application Server version 6 using a TADDM discovery, before running any recommendations on it, you must set the WebSphere Application Server administrator user id and password.
Before you begin

If WebSphere Application Server was installed using Tivoli Provisioning Manager and the parameter values of wsadmin.username and wsadmin.password were already provided, you can skip this configuration. When a computer is discovered into the data model from TADDM, before running any recommendations on its WebSphere Application Server software resource, perform the following steps:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Identify and click the computer on which WebSphere Application Server was detected. 3. Click Software tab. 4. Locate the software installation of WebSphere Application Server and click to see its Details page in the Software Resources application. 5. Expand the Software Resources tree and select WebSphere Application Server to find the parameters named wsadmin.username and wsadmin.password in the Template Parameters table. 6. Change their values to match the WebSphere Application Server administrator user id and password. 7. Click Save .
Software prerequisites
Ensure that the computers on which you want to manage compliance meet the software prerequisites. The following topic provides information about software prerequisites. Note: A depot is required if you want to run security compliance checks or if you want to run software remediation in a scalable distribution infrastructure. To use software configuration compliance management, you must have Tivoli Application Dependency Discovery Manager (TADDM) installed in your environment. The computers for which you want to monitor software configurations must have been discovered by TADDM and the resulting information replicated to the data model by running a TADDM discovery. The Tivoli Common Agent is required for security compliance management. For other types of compliance the common agent is only required if you are using the scalable distribution infrastructure.
837
Information about requirements for installing the Tivoli Common Agent is available at the following locations: v Requirements for Windows target computers on page 556 v Requirements for Red Hat Linux target computers on page 560 v Requirements for SUSE Linux Enterprise Server (SLES) target computers on page 561 v Requirements for AIX target computers on page 562 v Requirements for Solaris Operating Environment target computers on page 563 v Requirements for HP-UX target computers on page 565
Supported operating systems for target computers

Before you start managing compliance, ensure that you meet all requirements. You can manage compliance for the following Windows operating systems and versions: v Microsoft Windows Server 2008 R2 Standard Edition (x86 64-bit) any SP v Microsoft Windows Server 2008 R2 Enterprise Edition (x86 64-bit) any SP
Windows
v Microsoft Windows Server 2008 R2 Datacenter Edition (x86 64-bit) any SP v Microsoft Windows Server 2008 Standard Edition (x86 64-bit) any SP v Microsoft Windows Server 2008 Standard Edition (x86 32-bit) any SP v v v v v Microsoft Microsoft Microsoft Microsoft Microsoft Windows Windows Windows Windows Windows Server 2008 Enterprise Edition (x86 64-bit) any SP Server 2008 Enterprise Edition (x86 32-bit) any SP HPC (High Performance Computing) Server 2008 R2 7 Professional (x86 32-bit/ 64-bit) any SP 7 Enterprise (x86 64-bit) any SP
v Microsoft Windows 7 Enterprise (x86 32-bit) any SP v Windows Vista Ultimate Edition (x86 64-bit) any SP v v v v v Windows Windows Windows Microsoft Microsoft Vista Ultimate Edition (x86 32-bit) any SP Vista Enterprise Edition (x86 64-bit) Vista Enterprise Edition (x86 32-bit) Windows Server 2003 Standard Edition (AMD 64-bit) any SP Windows Server 2003 Enterprise Edition (AMD 64-bit) any SP
v Microsoft Windows Server 2003 Standard Edition (x86 64-bit) any SP v Microsoft Windows Server 2003 Enterprise Edition (x86 64-bit) any SP v v v v Microsoft Microsoft Microsoft Microsoft
AIX
Windows Windows Windows Windows
Server 2003 Standard Edition (x86 32-bit) any SP Server 2003 Enterprise Edition (x86 32-bit) any SP XP Professional (64-bit) any SP XP Professional (32-bit) any SP
You can manage compliance for the following AIX operating systems and versions: 7.1 6.1 6.1 5.3 5.3 5.2 any TL (IBM System p 64-bit) any TL (IBM System p 64-bit) any TL (IBM System i 64-bit) any TL (IBM System p 32bit/64bit) ML 3 or above (IBM System i 32bit/64bit) ML 7 or above (IBM System p 64-bit) 32-bit emulation You can manage compliance for the following Solaris operating systems and versions:
v v v v v v
AIX AIX AIX AIX AIX AIX

Solaris
838
v v v v
Solaris Solaris Solaris Solaris

Red Hat
10 (AMD 64-bit) 10 (x86 64-bit) 10 (Sun SPARC) 9 (Sun SPARC)
v v v v v v v v v v
Red Red Red Red Red Red Red Red Red Red
You can manage compliance for the following Red Hat Linux operating systems and versions: Hat Enterprise Linux 6 Server Advanced Platform (x86 32-bit) Hat Enterprise Linux 6 Server Advanced Platform (x86 64-bit) Hat Enterprise Linux 6 Server Advanced Platform (IBM System z 64-bit) Hat Enterprise Linux 5 Server Advanced Platform (x86 32-bit) Hat Hat Hat Hat Hat Hat Enterprise Enterprise Enterprise Enterprise Enterprise Enterprise Linux Linux Linux Linux Linux Linux 5 Server Advanced Platform (x86 64-bit) 5 Server Advanced Platform (IBM System z 64-bit) 4 AS/ES (x86 32-bit) 4 AS/ES (x86 64-bit) 4 AS/ES (IBM System i 32-bit/64-bit) 4 AS/ES (IBM System p 32-bit/64-bit)
v Red Hat Enterprise Linux 4 AS/ES (AMD 64-bit) You can manage compliance for the following SUSE Linux operating systems and versions: v SUSE Linux Enterprise Server Enterprise Server 11 (x86 32-bit) v SUSE Linux Enterprise Server Enterprise Server 11 (x86 64-bit)
SUSE
v SUSE Linux Enterprise Server Enterprise Server 10 (x86 32-bit) v SUSE Linux Enterprise Server Enterprise Server 10 (x86 64-bit) v SUSE Linux Enterprise Server Enterprise Server 10 (IBM System z 64-bit) v v v v v SUSE SUSE SUSE SUSE SUSE
HP UX
Linux Linux Linux Linux Linux
Enterprise Enterprise Enterprise Enterprise Enterprise
Enterprise Enterprise Enterprise Enterprise Enterprise
9 9 9 9 9
(x86 32-bit) (x86 64-bit) (IBM System i 32-bit/64bit) (IBM System p 32-bit/64bit) (IBM System z 64-bit)
You can manage compliance for the following HP-UX operating systems and versions: v HP-UX 11i v1 (PA-RISC) v HP-UX 11i v2 (PA-RISC) v HP-UX 11i v2 (Itanium) v HP-UX 11i v3 (PA-RISC) v HP-UX 11i v3 (Itanium)
Compliance checks export and import tools

You can export or import compliance checks that you defined for individual computers or for groups of computers. Using the ccexport and ccimport commands you can export compliance checks on computers or groups from one Tivoli Provisioning Manager server and import them into another Tivoli Provisioning Manager server. These commands can be run from the Tivoli Provisioning Manager server command line.
839
You have two options to import and export compliance checks, either using the new ccimport and ccexport commands or using the xmlimport and dcmexport commands, which have been extended to manage also compliance checks. With these tools you can easily move compliance checks between servers, for example from a test or development system into a production environment. The following table shows the differences between the ccimport/ccexport commands and the xmlimport/dcmexport commands:
Table 153. Export and import commands Command dcmexport ccexport xmlimport ccimport Description Exports all data model objects from the data model to a specified XML file, including the compliance checks. Exports only the compliance checks from the data model to a specified XML file. Imports all data model objects specified in an XML file into the data model, including the compliance checks. Imports only the compliance checks specified in an XML file into the data model.
Note: You cannot mix the usage of these two different set of commands. You can either use the set of tools dcmexport and xmlimport, or ccexport and ccimport, depending on the types of object that you want to export and import. Even if it is strongly recommended that you use one single set of tools, if you have the output of a dcmexport command and you cannot run a ccexport command, you can copy and paste the compliance check sections into a dummy ccexport output XML file, and then run the ccimport command, because the DTD format is the same in both cases.
Exporting compliance checks for selected computers or groups

You can export from the data model only the compliance checks for the selected target computers or groups of computers.
Before you begin

Ensure that the Tivoli Provisioning Manager deployment engine is started by running the tioStatus command, as described in tioStatus command. Create and edit the input files named compList.txt and groupList.txt, which contain a list of the computer names or group names to be exported. To export from the data model the compliance checks for selected computers or groups, perform these steps: 1. Log on as Tivoli Provisioning Administrator, for example as tioadmin, to the system where the Tivoli Provisioning Manager server is installed. 2. Move to the %TIO_HOME%\tools directory on Windows platforms or to the $TIO_HOME/tools directory on UNIX platforms.
Windows 2008 Select the option Run as administrator for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide. 3. Run the command:
ccexport -f myCompChecksOutput.xml -c compList.txt -g groupList.txt
840
Note: It is recommended that you specify the absolute path for the output file. If you specify only the file name, as in this example, the output file is created in the TIO_HOME/lwi/runtime/core directory. For details about the contents and syntax of the files used by the command, see ccexport command.
Results
An XML output file, named myCompChecksOutput.xml, is created. The file includes all compliance checks for the selected targets. On the command line, a message is displayed and indicates that the command ran successfully.
Exporting compliance checks for all computers and groups

You can export from the data model the compliance checks for all target computers and groups of computers in your environment. You might want to perform this task, for example, if you want to back up or archive all the current compliance checks, or if you intend to move all compliance checks from the staging system into the production system.
Before you begin

Ensure that the Tivoli Provisioning Manager deployment engine is started by running the tioStatus command, as described in tioStatus command. Select the option Run as administrator for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide.
Windows 2008
To export from the data model all the current compliance checks, perform these steps: 1. Log on as Tivoli Provisioning Administrator, for example as tioadmin, to the system where the Tivoli Provisioning Manager server is installed. 2. Move to the %TIO_HOME%\tools directory on Windows platforms or to the $TIO_HOME/tools directory on UNIX platforms. 3. Run the command:
ccexport -f myCompChecksOutput.xml
Note: It is recommended that you specify the absolute path for the output file. For details about the contents and syntax of the files used by the command, see ccexport command.
Results
An XML output file, named myCompChecksOutput.xml, is created. The file includes all the compliance checks stored in the data model. On the command line, a message is displayed and indicates that the command ran successfully.
Importing compliance checks for selected computers or groups

You can import into the data model the compliance checks defined in an XML file for the selected target computers or groups of computers.
Before you begin

Ensure that the Tivoli Provisioning Manager deployment engine is started by running the tioStatus command, as described in tioStatus command. Create and edit the input files named compList.txt and groupList.txt, which contain a list of the computer names or group names to be imported.
841
Procedure
1. Log on as Tivoli Provisioning Administrator, for example as tioadmin, to the system where the Tivoli Provisioning Manager server is installed. 2. Move to the %TIO_HOME%\tools directory on Windows platforms or to the $TIO_HOME/tools directory on UNIX platforms. 3. Export the compliance checks for selected computers or groups by running the command:
ccexport -f myCompChecksOutput.xml -c compList.txt -g groupList.txt
Note: If you do not specify the absolute path for the three file names used by the command, you must manually copy these files into the $TIO_HOME/tools directory. For details about the contents and syntax of the files used by the command, see ccexport command. After the ccexport command is successfully performed, the output file myCompChecksOutput.xml is created. 4. Copy the XML output file onto the Tivoli Provisioning Manager server on which the compliance checks must be imported. 5. Import the compliance checks to the Tivoli Provisioning Manager server by running the command:
ccimport -f myCompChecksOutput.xml
Note: If you do not specify the absolute path for the file name used by the command, you must manually copy the file into the $TIO_HOME/tools directory. For details about the contents and syntax of the files used by the command, see ccimport command.
Results
All compliance checks defined in the XML file are imported into the Tivoli Provisioning Manager server. The selected computers and groups in the Tivoli Provisioning Manager server are correlated correctly when importing the checks defined in the XML file. On the command line, a message is displayed and indicates that the command ran successfully. If a computer or a group specified in the XML file does not exist on the Tivoli Provisioning Manager server, on which you run the command, an error message is displayed and the command stops. If a computer or a group specified in the XML file has already been assigned a compliance check, which the XML file assigns to it, an error message is displayed, and the ccimport command proceeds with the next compliance check to be imported.
Importing compliance checks for all computers and groups

You can import into the data model all the compliance checks defined for the target computers or groups in your environment. You might want to perform this task for backup or restore purposes, if you already exported all compliance checks into an output XML file.
Before you begin

Ensure that the Tivoli Provisioning Manager deployment engine is started by running the tioStatus command, as described in tioStatus command. Export all the compliance checks into an XML output file named myCompChecksOutput.xml. To import all the compliance checks defined for the target computers or groups in your environment, perform these steps: 1. Log on as Tivoli Provisioning Administrator, for example as tioadmin, to the system where the Tivoli Provisioning Manager server is installed.
842
2. Move to the %TIO_HOME%\tools directory on Windows platforms or to the $TIO_HOME/tools directory on UNIX platforms. 3. Import all the compliance checks defined in the XML file, without specifying any target computers or groups, by running the command:
ccimport -f myCompChecksOutput.xml
Note: If you do not specify the absolute path for the file name used by the command, you must manually copy the file into the $TIO_HOME/tools directory. Select the option Run as administrator for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide.
Windows 2008
Results
All compliance checks defined in the XML file are imported into the Tivoli Provisioning Manager server. On the command line, a message is displayed and indicates that the command ran successfully. If a computer or a group specified in the XML file does not exist on the Tivoli Provisioning Manager server, on which you run the command, an error message is displayed and the command stops. If a computer or a group specified in the XML file has already been assigned a compliance check, which the XML file assigns to it, an error message is displayed, and the ccimport command proceeds with the next compliance check to be imported.
Importing compliance checks to different target computers

Using this advanced option, you can import a list of compliance checks that you already defined for one target computer into another computer. You might want to perform this task if you created some compliance checks for computer A and you want to have the same compliance checks defined for computer B.
Before you begin

Ensure that the Tivoli Provisioning Manager deployment engine is started by running the tioStatus command, as described in tioStatus command. Ensure that the target computers are available in the data model. Create and edit the input file named compList.txt, which contains the name of computer A. Create and edit the file named importCfg.properties, which contains the mapping information between computer A and computer B for the compliance checks. Select the option Run as administrator for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide.
Windows 2008
To import a list of compliance checks that you already defined for one target computer into another computer, perform these steps: 1. Log on as Tivoli Provisioning Administrator, for example as tioadmin, to the system where the Tivoli Provisioning Manager server is installed. 2. Move to the %TIO_HOME%\tools directory on Windows platforms or to the $TIO_HOME/tools directory on UNIX platforms. 3. Export the compliance checks defined for computer A into an output XML file by running the command:
ccexport -f myCompChecksOutput.xml -c compList.txt
Note: Specify the absolute path for the file names used by the command. Otherwise you must manually copy the files into the $TIO_HOME/tools directory. For details about the contents and syntax of the files used by the command, see ccexport command.
843
4. Import the compliance checks defined for computer A to computer B by running the command:
ccimport -f myCompChecksOutput.xml -p importCfg.properties
Note: All compliance checks contained in the XML file are processed to be imported. If the XML file contains also compliance checks for computers different from computer A, also these compliance checks are imported on the Tivoli Provisioning Manager server. Note: Specify the absolute path for the file names used by the command. Otherwise you must manually copy the files into the $TIO_HOME/tools directory. For details about the contents and syntax of the files used by the command, see ccimport command.
Results
On the Tivoli Provisioning Manager Web interface, the compliance checks are displayed also for computer B. If a computer or a group specified in the XML file does not exist on the Tivoli Provisioning Manager server, on which you run the command, an error message is displayed and the command stops. If a computer or a group specified in the XML file has already been assigned a compliance check, which the XML file assigns to it, an error message is displayed, and the ccimport command proceeds with the next compliance check to be imported.
Tutorial: Managing compliance

This tutorial demonstrates compliance management in Tivoli Provisioning Manager. The tutorial provides a scenario that demonstrates use of compliance management. In the scenario, compliance checks are defined for a provisioning group of Windows computers that must have DB2 installed and configured with standard settings. A software configuration template must be created to define the standard settings against which the software configuration checks are made. This template is created by copying the configuration of the application on a computer that has been configured with the approved settings. The computers in the group must also comply with a set of Windows security requirements. The same security requirements can apply to other groups of Windows computers. So, a set of Windows security checks is created and then used as a basis for creating a set of security checks to which software and software configuration checks are added. The compliance checks must be performed weekly, so a schedule is created to automate regular compliance checking. When checks are performed, any noncompliance issues are reported and recommendations are created. If the compliance checks find that the specified version of the DB2 Enterprise Server Edition is not installed or its configuration is not compliant on one of more of the computers in the group, accepting the related recommendation creates an activity to resolve the issue. Note: Compliance can be managed by group or by individual computer. The instructions given in this scenario are for a group. To manage compliance for a computer, select Provisioning Computers from the Start Center instead of Provisioning Groups and select the target computer. The remaining instructions are the same.
Learning objectives
In this tutorial you will learn how to: v Create security compliance checks. v Add compliance checks to a provisioning group. v Create software compliance checks. v Create a software configuration template
844
v v v v
Create software configuration compliance checks Schedule compliance checks. Review compliance recommendations. Run remediations for noncompliance issues.
Prerequisites
Before you start, the following tasks must have been done: v Creation of the provisioning groups required in this scenario: A group to which the Windows security compliance checks are associated. As this set of compliance checks is being used as a model for creating sets of compliance checks for other groups, this provisioning group can be empty. A group that includes the computers that are to be subject to the same security, software, and software configuration checks. v A hardware discovery to ensure that the computers for which you want to check compliance are included in the data model . v A TADDM discovery to store details about software configurations, collected by Tivoli Application Dependency Discovery Manager, in the data model. Configuration information must be collected for all computers in the group for which the compliance checks are to be defined and for the computer that is to be used to create the software configuration template for the DB2 Enterprise Server Edition. v Installation of the Tivoli Common Agent stack on the computers for which you want to check compliance.
Part 1: Creating compliance checks

Compliance checks define the required state of security settings, installed software, and software configuration on the targets to which they are applied. You will perform the following compliance tasks: Create a set of security compliance checks The security compliance checks include security settings for Windows computers. Create a set of compliance checks by copying them from another group or computer and add software compliance checks You create an initial set of compliance checks by copying the set of Windows security compliance checks. Then you add software compliance checks that Adobe Reader must be installed and the HTTP server must not be installed on all the computers in the group. Define software configuration compliance checks You create a software configuration template for DB2 by specifying a computer that has been discovered by Tivoli Application Dependency Discovery Manager, where DB2 is installed and configured with the approved settings. You then add a software configuration compliance check for DB2 to the list of compliance checks defined for the group. Run the compliance checks You run the set of compliance checks that you created. Schedule the compliance checks You schedule the set of compliance checks that you created to repeat automatically every week.
Creating a set of security compliance checks

The compliance management feature includes a set of predefined security compliance checks that you can select to be performed on a target computer or a group of target computers. In this lesson you will create a set of compliance checks that includes some of the security checks that apply to Windows computers.
845
To complete this task you must be logged on as a user with compliance analyst access. To create a set of security compliance checks: 1. 2. 3. 4. In the Start Center, click Provisioning Groups. Select the group that you created for the Windows security checks, and click the Compliance tab. Click New Compliance Check and select Security Check. The Add Security Check panel opens. Select the following security checks: v Windows Antivirus v Windows Power-on Password v Windows Screen Saver v Windows User Password
Note: Before setting the Windows Screen Saver security check, ensure that you have enabled the Screen Saver function at least once on the target computers if they are Windows 2008 or Windows 7 workstations. This action is required for creating the ScreenSaveTimeOut registry key under the following path: "HKEY_USERS\<user SID>\Control Panel\Desktop\" of the Windows registry. 5. Click Save. The selected security checks are displayed in the Compliance Check table. 6. Define and activate the settings to be checked for each of the selected security checks, as follows: a. Click Detail Menu in a row of the Security Check table and select Settings. The Settings panel for the selected security check opens. b. Enable the settings you want to check and define the required values. Default settings are automatically enabled. Though if you choose to change the default settings, they are not active until you have saved them. You can clear the check box to disable a setting you do not want to check. Default values are provided for most settings. To change a value, click the arrow to open the Properties panel and type or select the value that you want. For example, if all Windows computers must have active, password-protected screen savers that automatically lock after 15 minutes. Open the settings panel for the Windows Screen Saver compliance check, enable all the settings and define the following values: Active Yes Password protected Yes Maximum timeout value 15 c. Click Save. You have now created a set of compliance checks that apply to Windows computers.
Creating compliance checks using a model

You can create compliance checks using a source computer as a model. You can create compliance checks using a source computer as a model. The compliance checks that are created are set up so that they match the settings on the source computer. This can save you time because the compliance checks and settings are created automatically and you do not have to start over each time. For example, if the source computer has a hard disk password and Windows 2000 installed, but no power-on password, a compliance check that ensures a hard disk password is enabled. Windows 2000 is installed and a power-on password is disabled for the target system. Note: The source computer must have had an inventory scan run before it can be used as a model.
846
To create compliance checks using a model:
Procedure
1. Search for the computer or group you want to work with and select it from your search results. 2. Click the Compliance tab. 3. Click Edit > Creating Compliance Checks using Model. The Creating Compliance Checks using Model dialog opens 4. Fill in the fields as necessary. For more information on the fields, click Help. 5. Click Save.
Results
The compliance checks are added to your computer or group and listed in the Security Compliance Checks and Software Compliance Checks tables.
Adding software compliance checks

Software compliance checks can be defined to require or restrict software modules or software stacks or to require the installation of one software product from a selected software group. Compliance checks for an individual software module or software stack have the following options: Required If you select this option, the software must be on the computer. This is the default choice. Prohibited If you select this option, the software must not be on the computer. Optional If you select this option, the software can be on the computer, but it does not have to be. This option is used in conjunction with the Restrict Other Software security compliance check. These options are not available for a software group. The compliance check for a software group is satisfied if at least one member of the software group is installed. In the scenario described in this lesson, a set of compliance checks is to be created for a group of Windows computers all of which must have the Adobe Reader, version 9.0.0 installed and must not have the HTTP Server installed. All computers in the group must also have the Windows security checks that were defined in the previous lesson for a different group. In this lesson you will create a set of compliance checks for a provisioning group, by copying the security checks created in the previous lesson and then adding the following software module compliance checks: v Adobe Reader, version 9.0.0, is installed v HTTP Server is not installed To complete this task you must be logged on as a user with compliance analyst access. To create a set of compliance checks by copying an existing set and adding new software checks: 1. In the Start Center, click Provisioning Groups. 2. Select the group for which you want to create a set of compliance checks, and click the Compliance tab. 3. Click Copy Checks The Copy Compliance Checks panel opens. 4. Click the Groups tab and select the group for which you created the Windows security compliance checks. The security compliance checks that you created for that group are copied into the Compliance Checks table for the group you are now working with.
847
5. Click New Compliance Check and select Software Check > Software Module Check . The Add Software Check panel opens. 6. Search for the HTTP Server and Adobe Reader, version 9.0.0 modules, select them and click Save. Software checks for the selected modules are added to the Compliance Checks table. The default settings of software module compliance checks include a required state setting of Software must be installed. No changes are required to the settings for the Adobe Reader module. 7. Define the settings for the HTTP Server as follows: a. Click Detail Menu for the HTTP Server module and select Settings. The Settings panel opens. b. Change the Desired state setting to Software must not be installed. c. Click Save. You have now created a set of compliance checks that includes security and software checks. You can now add a software configuration check to the set of compliance checks for this provisioning group.
Defining software configuration compliance checks

Software compliance checks are performed by comparing the configuration of an application on target computers with a standard configuration for that application. Each application for which software compliance checks are to be requested must have a software configuration template that represents the standard configuration that must be implemented on the target computers. When a software configuration compliance check is run against a target, if any noncompliance issues are detected, software configuration recommendations are generated. If the software is not installed on the target, a software recommendation is generated. When you implement this recommendation, it installs the software and then configures it according to the standard configuration. In this scenario, the computers in the target group must have DB2 installed with a standard configuration. You define the standard configuration by creating a software configuration template using the configuration discovered on a computer in your environment that you know is correctly configured. When the template has been created, you add a software configuration check to the target group for which you already created security and software checks. Note: To use software configuration checking, a discovery must have been run to store the software configuration information in the data model. Tivoli Provisioning Manager provides a discovery method for Tivoli Application Dependency Discovery Manager. If you are using a different product to monitor configurations, you can define your own discovery. To complete the tasks in this lesson you must be logged on as a user with compliance analyst access. To create software configuration template for DB2: 1. In the Start Center, click Software Configuration Templates. . Click New In the Template field, enter a name for the software configuration template. Select Source Computer where DB2 is configured with the approved settings. In the Software Name field, select DB2. Details of the software application and its configuration on the source computer are displayed. 6. Select a Discovery Configuration that has been created using the TADDM discovery method or your own custom configuration discovery method. 2. 3. 4. 5. 7. Click Save .
848
To create a software configuration check based on that template: 1. In the Start Center, click Provisioning Groups. 2. Select the group for which you created security and software compliance checks in the preceding lesson, and click the Compliance tab. 3. Click Software Configuration Checks. 4. Click New Software Configuration Check. The Add Software Configuration Check panel is displayed. 5. Select the software configuration template you want to use for your configuration checks from the list. 6. Click Save. . 7. Click Detail Menu 8. Select Settings from the pop-up window to see details about the software configuration check. The Software Configuration Check Details panel is displayed and all the parameters from the template are listed. You can do the following: Change a parameter Click Select Value parameter. . The Properties panel opens and you can change the value of the
Delete a parameter Click Mark for Delete . Parameters that are marked for deletion are removed from the template when you save the settings. 9. Click Save. You have created a software configuration template for DB2 and added a related software configuration check to a provisioning group. You can now create a schedule for applying the checks. Editing software configuration remediation parameters: You can change some of the parameters in the software configuration remediation template. This topic describes the parameters that you can modify to change the behavior of the remediation recommendations of the software configuration type. Normally there is no need for you to edit the default remediation configuration parameters. However, if you want to change some of these parameters, you can edit their associated files located on the Tivoli Provisioning Manager server. The parameters are described in the following tables: Parameters for the HTTP server To edit parameters for the HTTP server, edit the file config/remediationConfiguration.xml. The following table describes the parameters you can change in this file:
Table 154. Editable parameters in config/remediationConfiguration.xml Section or attribute parameter section instance-reboot attribute configuration section Description Add or remove installed software parameters. You can only add a parameter that is supported by the discovery scan. Enter true or false to reboot the instance of the software after remediation has occurred. You can change any of the configuration parameters: file name, path, or delimiter.
849
Table 154. Editable parameters in config/remediationConfiguration.xml (continued) Section or attribute taddm-configuration use-existing-profile attribute Description Enter true to run a TADDM profile discovery using the profile that is defined in the section <profile>. Enter false to run a TADDM sensors discovery using the sensors that are listed in the sections named <sensor>. If you do not want the remediation operation to trigger a TADDM discovery at the end of the task, remove the taddm-configuration section from the file.
Parameters for the WebSphere Application Server, DB2, and Oracle To edit parameters for the WebSphere Application Server, DB2, and Oracle, edit the file config/remediationConfigurationCustom.xml. The following table describes the parameters you can change in this file:
Table 155. Editable parameters in config/remediationConfigurationCustom.xml Section or attribute instance-reboot attribute admin-config section Description Enter true or false to reboot the instance of the software after remediation has occurred. You can change the WebSphere Application Server scope. For example, you can change Server or Cell, but by doing so you would refer to a different set of parameters that must be defined at that scope. The list of scopes is available in the WebSphere Application Server tools. You can enter true to run a TADDM profile discovery using the profile that is defined in the section <profile>. Enter false to run a TADDM sensors discovery using the sensors that are listed in the sections named <sensor>. If you do not want the remediation operation to trigger a TADDM discovery at the end of the task, remove the taddm-configuration section from the file.
taddm-configuration use-existing-profile attribute
Running compliance checks

Compliance checks that have been defined for a target computer or a group of target computers can be run immediately. In this lesson you will run the set of compliance checks that you created. To perform a compliance check: 1. In the Start Center, click Provisioning Groups. 2. Select the provisioning group for which you created software, software configuration, and security compliance checks, and click the Compliance tab. 3. Click Run > Scan and Check. 4. Click the Notification Setup tab to specify notification options if you want users to be notified about the compliance scan and check. You have now run a compliance check. If you set up a notification for compliance, you receive a notification only if the scan and check is successful, and if it finds some target computers which are not compliant. You do not receive any notification if the scan and check task fails. Note: If you run an external TADDM discovery, Tivoli Provisioning Manager cannot use the discovery data to check compliance. In this situation, to successfully check compliance, you must run discovery by using the Scan and Check option.
850
Scheduling compliance checks

Compliance checks that have been defined for a target computer or a group of target computers can be scheduled to run automatically at a specified date and time and, if necessary, to repeat on a regular basis. You can even schedule a compliance check on an empty group. Then later, you can populate the group, either manually or automatically, so that the group contains computers when the check is run. On the specified date and time, the system performs an inventory scan on the target computers to collect the information required for the checks and compares the results to the required state as defined by the settings for each configuration check. In this lesson you will create a schedule for the set of compliance checks that you created to be run every week, starting from the current date. To create a schedule for performing compliance checks: 1. In the Start Center, click Provisioning Groups. 2. Select the provisioning group for which you created software, software configuration, and security compliance checks, and click the Compliance tab. 3. Click Schedule > Schedule Scan and Check. 4. Clear the Run Now check box and specify a date and time for Scheduled Start 5. In the repeating schedule definition, define a schedule to repeat every 1 week and specify the day of the week and the time at which the schedule will repeat. 6. Click the Notification Setup tab to specify notification options if you want users to be notified about the compliance scan and check. Note: If you set up a notification for compliance, you receive a notification only if the scan and check is successful, and if it finds some target computers which are not compliant. You do not receive any notification if the scan and check task fails. 7. Click OK. You have now created a schedule for weekly compliance checks. When the first repeat of the schedule has been performed, you can check on the Recommendations tab to see whether there are any noncompliance issues to resolve.
Part 2 Recommendations
Recommendations identify the actions required to resolve noncompliance issues. The compliance checking process generates a recommendation for each noncompliance issue. You will perform the following compliance tasks: Review and approve the recommendations The recommendations generated by the compliance checking process are listed. Use the list to get an overview of the noncompliance issues and approve the recommendations that you want to implement. Run or schedule the recommendations When the recommendations are in the approved state, you can run the related workflows immediately or schedule them to run at a convenient time.
Reviewing and approving the compliance recommendations

When the compliance checking process is completed, a list of recommendations for fixing any noncompliance issues is available for review.
851
The recommendations describe the action to be taken to resolve the noncompliance issue. In many cases, workflows are available to automate the remediation of the issue. By default, recommendations are created in the Open state. You can take the following actions to change the state: Approve Before an automated remediation can be applied for a recommendation, you must approve it. Close Closing a recommendation changes its state to Implemented. Use this action for issues that must be resolved manually.
Ignore Use this action if you do not want to apply a recommendation. Open Use this action to reopen a recommendation that is in any of the other states.
Note: When creating compliance checks, you can enable automatic approval. Recommendations are then created with the state already set to Approved. You can view all recommendations for a computer or group of computers by clicking the Recommendations tab on the Provisioning Computer or Provisioning Group page. If you want to view recommendations for a particular compliance check, select the compliance check in the table of compliance checks, open the context menu and select Recommendations. In this scenario, the compliance check has found that two computers do not have the Adobe Reader, version 9.0.0 installed and that the HTTP Server is installed on one of the computers in the group. Recommendations have been generated to install Adobe Reader on the two computers where it is missing and to uninstall the HTTP Server from the computer where it is installed. To complete this task you must be logged on as a user with compliance analyst access. To review and approve these recommendations: 1. In the Start Center, click Provisioning Groups. 2. Select the provisioning group for which you have run compliance checks, then click the Recommendations tab. 3. Select the check box for each recommendation and click Approve. The recommended actions can now be implemented.
Implementing recommendations
When recommendations have been approved, the recommended actions can be performed by implementing a workflow to run immediately or at a convenient time. In this scenario, recommendations were generated for the installation of the Adobe Reader, version 9.0.0 on two computers and the uninstallation of the HTTP Server from one computer. All recommendations have been approved. In this lesson, the HTTP Server is to be uninstalled and the Adobe Reader installations are to be scheduled to run. To complete this task you must be logged on as a user with deployment specialist access. 1. In the Start Center, click Provisioning Groups. 2. Select the provisioning group for which you have run compliance checks and click the Recommendations tab. 3. Select the recommendation for the uninstallation of the HTTP Server and the installation of Adobe Reader. 4. Click Implement. A provisioning task is created to run the workflow for the software. A panel appears giving you the option to view and configure the task. You can choose to run the task now or schedule it to run at a later date. 5. Click Submit.
852
You have created tasks to apply the recommended actions to bring the computers into a compliant state. To monitor the tasks that you have created, click Provisioning Task Tracking in the start center and filter the list of provisioning tasks to include only those with the type compliance remediation.
Example: Running a Sarbanes-Oxley compliance report

You can run a report to determine if you are compliant with Sarbanes-Oxley Act standards.
The Sarbanes-Oxley Act (SOX) was introduced in 2002. The act focuses on the accuracy of financial records and controls related to income, expenses, accounting, liabilities, and more. Tivoli Provisioning Manager provides a report you can generate to determine which computers in your organization are not compliant with SOX policies.
Example: Running a SOX report

Before you begin
You must generate a report request page before running your SOX compliance reports. This is a procedure that you must perform only once before running SOX compliance reports. For information about generating a report request page see, Add the custom report to the list of reports on page 184. Tivoli Provisioning Manager provides an empty SOX Group as a sample group. You must install the Tivoli Common agent for this sample SOX group because it is required to run security scans. For information about other prerequisites, see Requirements on page 835. You must ensure that the prerequisites for each compliance check are met. To determine if the policies of your company policies are compliant with SOX standards, perform the following procedure:
Procedure
1. Determine what policies you need in your organization to be compliant with SOX standards. 2. You can use the empty SOX Group as a sample group. Or, create your own groups for SOX-compliance. If compliance checks are defined, you can run a SOX report on any custom group that is static and of computer type. Manually add any computers that you want to be SOX-compliant to the SOX Group by performing the following: a. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. b. Click SOX Group and manually add the computers to the group. For information about groups, see Provisioning groups on page 38. 3. Click the Compliance tab of the group. The sample SOX group provides the following predefined checks: v Windows Antivirus v Windows Screen Saver v Windows Power-On Password v Windows User Password You can add additional checks for the SOX policies that you are interested in by selecting New Compliance Check > Choose Type 4. Click Run > Scan and Check. 5. Run the SOX compliance report by selecting Run Reports from the Select Action menu. 6. Click the report Is the Group of Computers compliant against the defined SOX rules?. 7. Select the SOX Group and click Submit.
853
Results
A report appears that lists all the computers in the SOX Group that are NOT compliant with the list of the compliance checks. It also lists all of the compliance checks defined for the group.
Example: Defining a multiple-rule security compliance check

Some security compliance checks support the definition of multiple rules.
The set of compliance checks that you define for a computer or group of computers cannot include multiple instances of a security compliance check. Instead, when a check might be applied to several objects on a computer, you define multiple rules that identify the objects to be checked and the settings that they must conform to. For example, you can define rules for checking for the permissions of multiple files or for the existence and state of UNIX or Windows services.
The following security compliance checks support multiple rules. v Linux System Logging v UNIX File Permissions v UNIX Services v User Defined Check v Windows File Permissions v Windows Services In the following example, a Windows Services compliance check is added to a group of computers to ensure that: v The LiveUpdate service is present, is configured to start automatically, and has started. v The NetMeeting Remote Desktop Sharing service is present and is configured to start manually. Its current state is not important. To complete this task you must be logged on as a user with compliance analyst access. To define these checks, perform the following steps:
Procedure
1. In the Start Center, click Provisioning Groups. 2. Select the group for which you want to create the Windows Services check and click the Compliance tab. 3. Click New Compliance Check and select Security Check from the pop-up window. The Add Security Check panel opens. 4. Select Windows Services and click Save. The Windows Security check is added to the Compliance Check table. . for the Windows Services check and select Settings from the pop-up window. 5. Click Detail Menu The Settings panel opens. 6. Define the LiveUpdate service checking rule, as follows: a. In the Compliance Checks section of the Settings panel, click Add. The Properties dialog opens. Complete it as follows: Compliance check A string to identify the compliance check. This appears in the list of Windows Services checks shown in Settings panel.
854
Service Specify LiveUpdate. b. Define the required settings for the LiveUpdate service as follows: Startup type Automatic Service applicability Required Service state Started Change a setting by clicking the arrow next to it. The settings Properties dialog opens. 7. Define the NetMeeting Remote Desktop Sharing service checking rule, as follows: a. In the Compliance Checks section of the Settings panel, click Add. The Properties dialog opens. Complete it as follows: Compliance check A string to identify the compliance check. This appears in the list of Windows Services checks shown in Settings panel. Service Specify NetMeeting Remote Desktop Sharing. b. Define the required settings for the NetMeeting Remote Desktop Sharing service as follows: Startup type Manual Service applicability Required Service state Clear the check box for this setting. 8. Click Save.
Example: Restricting software

You can define compliance checks to ensure that software that has not been approved is not installed on target computers.
Compliance checking in Tivoli Provisioning Manager supports the following scenarios in which installation of software is restricted: Allowed software scenario The software that can be installed on a computer or group of computers is restricted to a list of software that you define. The list can include software modules, stacks, and groups. Prohibited software scenario on page 856 Some software products are specifically prohibited. All other software products can be installed on the computer or group of computers.
To complete these tasks you must be logged on as a user with compliance analyst access.
Allowed software scenario

To restrict allowed software to a specified list:
Procedure
1. In the Start Center, click Provisioning Groups or Provisioning Computers.
855
2. Select the group or computer for which you want to define allowed software. and click the Compliance tab. 3. Click the Security Checks tab and then click New Security Check. 4. Select Restrict Other Software and click Save. 5. Select the software that is to be allowed on the target computer or computers: a. Click the Software Checks tab and then click New Software Check. b. From the pop-up window, choose Software Module, Software Group, or Software Stack c. Select all the software modules, stacks or groups you want to allow and click Save.
Results
You have created a list of allowed software that you can see if you click the Allowed Software tab. A noncompliance would be generated if any other software was detected on the target computer or computers.
Prohibited software scenario

To complete this task you must be logged on as a user with compliance analyst access. To add a prohibited software compliance check:
Procedure
1. In the Start Center, click Provisioning Groups or Provisioning Computers. 2. Select the group or computer for which you want to add a compliance check. and click the Compliance tab. 3. Click the Software Checks tab and then click New Software Check. The software check pop-up window opens. 4. Choose Software Module or Software Stack 5. Select the software modules or stacks that are not permitted and click Save. Software checks for the selected modules are added to the Compliance Checks table. The default settings of software module compliance checks include a Desired state setting of Software must be installed. 6. Change the Desired state setting for each check as follows: and select Settings from the pop-up window. The Settings panel opens. a. Click Detail Menu b. Change the Desired state setting to Software must not be installed. c. Click Save.
Example: User-defined compliance checks

You can create user-defined security compliance checks, which are used to cover security situations that are not covered by the standard compliance checks.
Using automation packages that include user-defined workflows, you can build your own security compliance checks and their associated remediation actions. When you have created and installed the automation package, you can add the user-defined security check to the compliance checks defined for provisioning groups and computers.
856
Defining a compliance check

Tivoli Provisioning Manager includes a sample automation package for compliance validation that you can use as a starting point for defining your compliance check. To define your compliance check and the associated remediation, do the following:
Procedure
1. Create an automation package to include the user-defined workflow and compliance definition. You can use the sample automation package, sample-compliance-validation as a starting point. 2. Define the compliance checking workflow, implementing the Compliance.ValidateServer LDO. The Sample_IP_Check.wkf file in the sample-compliance-validation package provides an example of how to implement the Compliance.ValidateServer LDO. 3. Create the compliance definition in the XML file in your automation package. The sample-compliance-definition.xmlfile in the sample-compliance-validation package provides an example. 4. Define the remediation workflow, implementing the ComplianceRecommendation.Remediate LDO. 5. Install the automation package.
Adding user-defined security compliance checks

The list of available security compliance checks includes a user-defined check. When you select this compliance check for a computer or group of computers, you must select the user-defined check to be applied. To complete this task you must be logged on as a user with compliance analyst access. To add a user-defined security compliance check:
Procedure
1. In the Start Center, click Provisioning Groups or Provisioning Computers. 2. Select the group or computer for which you want to add a compliance check. and click the Compliance tab. 3. Click New Compliance Check and select Security Check from the pop-up window. The Add Security Check panel opens. 4. Select User Defined Check and click Save. User Defined Check is added to the compliance check table. . in a row of the table and select Settings from the pop-up window. The 5. Click Detail Menu Settings panel opens showing any user-defined checks that have already been added. 6. Click Add. The Properties dialog opens. Complete it as follows: Compliance check A string to identify the compliance check. This appears in the list of user-defined checks shown in Settings panel. Compliance name The name of the compliance definition created in the XML file of the automation package. 7. Click Add. The compliance check is added to the list. You can continue to add more checks. 8. When you have added all the required checks, click Save.
857
Troubleshooting compliance
To help you troubleshoot problems with compliance, it is important to understand the process that occurs during a compliance operation. Use the information in the Process section to learn about the main steps that occur during a compliance operation. Use the remaining sections to find out how to troubleshoot errors that occur during specific parts of the process. v Process v 1. Task status on page 859 v 2. Target status on page 862
Process
There are three compliance processes to consider when troubleshooting compliance: 1. Compliance Scan 2. Compliance Check 3. Compliance Remediation To demonstrate how components interact, the following steps outline the component interactions during a compliance operation. Compliance Scan 1. The user submits the Compliance Scan operation. 2. The provisioning task is built to run the Compliance Scan operation and it is submitted to the activity plan engine. 3. The activity plan engine runs the Compliance Scan task: v Each activity in the plan triggers a corresponding action. The checks defined on the computer where the compliance scan is requested can trigger one or more of the following actions: a. Install or Uninstall Software The SoftwareModule.Install logical operation runs. b. SCMCollectorAgent discovery Security compliance check c. IBM Tivoli Common Agent Discovery The Target Agent security check d. Tivoli Application Dependency Discovery Manager discovery Software configuration check e. Patch Scan Operating system patch compliance check Note: The compliance process does not add any steps to discovery or software installation actions. If an error occurs during discovery, see Troubleshooting discovery on page 239. If an error occurs during software installation see Troubleshooting software distribution on page 751. Compliance Check 1. The user submits the Compliance Check operation. 2. The provisioning task is built to run the Compliance Check operation and it is submitted to the activity plan engine. 3. The activity plan engine runs the Compliance Check task: v The Deployment Engine runs the Compliance_Validation workflow. Compliance Remediation
858
1. The user selects one or more recommendations and triggers the Implement operation. 2. A provisioning task is created that contains the required activities for running the remediation activities selected by the user. It is submitted to the activity plan engine. 3. The activity plan engine runs the Compliance Remediation task: v Each activity in the plan triggers a corresponding operation. Different operations occur depending on the remediation activity. For example: a. Install or Uninstall Software SoftwareModule.Install logical operation runs. Note: If an error occurs during software installation, see Troubleshooting software distribution on page 751. b. Install Patch SoftwareModule.Install logical operation runs. Note: If an error occurs during a patch deployment, see Troubleshooting SDI Windows patch management on page 989. c. Security Remediation workflow ComplianceRecommendation.Remediate or ComplianceRecommendationGroup.Remediate logical operation runs. d. Finalization Workflow ComplianceRecommendation.Finalize workflow runs. Deployment infrastructures used when running a compliance-related operation Compliance Scan and Compliance Remediation operations go through different deployment infrastructures depending on the operation and the target. For example: 1. Compliance Scan v The operation will go through scalable distribution infrastructure or through deployment engine, depending on the targets and executed discovery. Note: This operation is not specific to compliance. Only the preparation and submission are compliance-specific. See Troubleshooting discovery on page 239 for more information about this topic. 2. Compliance Check v The operation is server-side and runs through deployment engine. 3. Compliance Remediation v Security Remediation and Software Configuration Remediation operations go through the deployment engine. Patch Installation and Software Install/Uninstall Remediation operations go through scalable distribution infrastructure or through deployment engine, depending on the targets and software. Note: Patch and software installation operation rules apply.
1. Task status
1. If an error occurs for one of the following actions, the error is related to the web interface: v Viewing compliance-related information in the Provisioning Computers and Provisioning Groups applications. v Creating, deleting, copying, or editing compliance checks. v Approving, opening, ignoring, closing, or viewing recommendations.
859
v Configuring advanced options for remediation, before the dialog regarding Task Tracking application is displayed. Check the following logs for errors relating to actions triggered from the interface:
%TIO_LOGS%\j2ee\console.log %WAS_HOME%\AppServer\profiles\ctgAppSrv01\logs\MXServer\SystemOut.log %WAS_HOME%\AppServer\profiles\ctgAppSrv01\logs\MXServer\SystemErr.log
UNIX Linux Windows
$TIO_LOGS/j2ee/console.log $WAS_HOME/AppServer/profiles/ctgAppSrv01/logs/MXServer/SystemOut.log $WAS_HOME/AppServer/profiles/ctgAppSrv01/logs/MXServer/SystemErr.log
2. Check the status of the compliance task. For information about task status, see Tracking a provisioning task on page 1165. a. Go into the task details and review at the task instance level. b. Information pertaining to the error message associated with each task instance can be accessed by clicking the >> arrows on the right of the task status column. c. If the message details are not clear, go into details at the target level and check for a workflow log and log number associated with each target of the operation. Then click the workflow number and open the workflow execution log. If no workflow log number is associated with the task, the operation was executed through scalable distribution infrastructure, therefore the log, and trace files must be inspected to retrieve additional diagnostic information. 3. If the information contained in the workflow execution log cannot be used to identify the cause of the failure, or if a scalable distribution infrastructure was used, the next step is to look at the activity plan engine and the deployment engine logs. By default, the log level for console.log is info and the log level for trace.log is error. Change the log level to debug to obtain more troubleshooting information. For information about setting the log level, see Configuring log4j dynamically.
Windows
%TIO_LOGS%
Linux
UNIX
$TIO_LOGS
trace.log
Windows
%TIO_LOGS%
Linux
UNIX
$TIO_LOGS
In the logs, use the following information to locate messages related to the compliance operation. Search for these items and the word Exception to quickly locate the failure. v The workflow number v The workflow name (Compliance_Validation, ComplianceRecommendation.Remediate, SoftwareModule.Install, Discovery.OnDevice) v The provisioning task name (Compliance Check, Compliance Scan, or Compliance Remediation) To help you troubleshoot compliance-related tasks, look for the following key words in the log file: v Compliance_Validation v v v v v v ComplianceRecommendation.Remediate SoftwareModule.Install Discovery.OnDevice Compliance Check Compliance Scan and Check Compliance Remediation
860
Sample log entries for compliance-related operations Compliance Check Check the status of a compliance check in the log file:
DEBUG [Status Updater] (StatusUpdateProcessor.java:80) manager.StatusUpdateProcessor: Start processing for task instance id=89217, name=Compliance_Validation DEBUG [Compliance_Validation(17212)] (WorkflowExecutionMonitor.java:66) komodor.WorkflowExecutionMonitor: Starting workflow: Compliance_Validation.java INFO [Compliance_Validation(17212)] (ExecutionLogger.java:342) runtime.ExecutionLogger: Start configuration compliance validation check for device with id: 6603 DEBUG [Compliance_Validation(17212)] (GroupComplianceValidator.java:229) validation.GroupComplianceValidator: The Compliance Check has completed successfully INFO [Compliance_Validation(17212)] (ExecutionLogger.java:342) runtime.ExecutionLogger: Finish configuration compliance validation check for device with id: 6603
Compliance Scan To check the status of a compliance scan in the log, search for the discovery workflow that is used for the task:
DEBUG [Discovery.OnDevice(17213)] (WorkflowExecutionMonitor.java:66) komodor.WorkflowExecutionMonitor: Starting workflow: Discovery$OnDevice.java DEBUG [Discovery.OnDevice(17213)] (WorkflowExecutionMonitor.java:74) komodor.WorkflowExecutionMonitor: DiscoveryID = 4476 DEBUG [Discovery.OnDevice(17213)] (WorkflowExecutionMonitor.java:74) komodor.WorkflowExecutionMonitor: DeviceID = 23024
Compliance Remediation To check the status of a compliance remediation task, search for log entries associated with the type of remediation that you are performing. The following log excerpts show the status of a software installation remediation using the deployment engine. In this example, when you find the deployment request ID 17215 in the log, you can track the progress of the software installation by searching for the deployment request 17215.
DEBUG [Status Updater] (StatusUpdateProcessor.java:211) manager.StatusUpdateProcessor: current status for plan: Compliance Remediation [11/2/10 3:41 PM](7804) is IN_PROGRESS DEBUG [Status Updater] (StatusUpdateProcessor.java:218) manager.StatusUpdateProcessor: Updating plan instance status of: Compliance Remediation [11/2/10 3:41 PM](7804) from SUBMITTED to: IN_PROGRESS ... INFO [Install Software 5179(93732) from com.ibm.tivoli.orchestrator.de.task.OSGiDETaskDispatcher] (MessageTranslatorProxy.java:319) messagetranslator.MessageTranslatorProxy: New deployment request was created (id=17215) DEBUG [Install Software 5179(93732) from com.ibm.tivoli.orchestrator.de.task.OSGiDETaskDispatcher] (DETaskExecutor.java:181) task.DETaskExecutor: Deployment request 17215 is created for task target: 6816 ... DEBUG [SoftwareModule.Install(17215)] (WorkflowExecutionMonitor.java:74) komodor.WorkflowExecutionMonitor: SoftwareModuleID = 5179
The following log excerpts show the status of a software installation remediation using the scalable distribution infrastructure. The log examples show the task starting, permissions verification on the target computer, and the workflow starting. In this example, you would use task ID 23963 to search for additional information about the task in the log.
DEBUG [Activity Plan Engine] (QueuedActivity.java:80) activityplan.QueuedActivity: dequeuing Install_Software_23963(7816) DEBUG [Activity Plan Engine] ( TpmTask.java:55) manager.TpmTask: Task execution started: Install Software 23963 DEBUG [Install Software 23963(93752) from com.ibm.tivoli.tpm.activityplan.manager.AggregateTaskDispatcher] (WorkflowAccessManager.java:104) accesscontrol.WorkflowAccessManager: checking permission (target:6822)Software.Install Software.Install on 23963 DEBUG [Install Software 23963(93752) from com.ibm.tivoli.tpm.activityplan.manager.AggregateTaskDispatcher] (WorkflowAccessManager.java:106) accesscontrol.WorkflowAccessManager: checking permission (target:6822)Software.Install Software.Install on 23963 succeeded DEBUG [Install Software 23963(93752) from com.ibm.tivoli.tpm.activityplan.manager.AggregateTaskDispatcher] (WorkflowAccessManager.java:104) accesscontrol.WorkflowAccessManager: checking permission (target:6822)Device.ManagerSoftware Device.ManagerSoftware on 23024 DEBUG [Install Software 23963(93752) from com.ibm.tivoli.tpm.activityplan.manager.AggregateTaskDispatcher] (WorkflowAccessManager.java:106) accesscontrol.WorkflowAccessManager: checking permission (target:6822)Device.ManagerSoftware Device.ManagerSoftware on 23024 succeeded
The following log excerpts show the status of a security remediation, beginning from the point where the workflow starts. You can use the IDs for the remediation workflow (15219), the recommendation (85507), and the target computer (83564) to look for relevant information in the log.
DEBUG [ComplianceRecommendation.Remediate(15219)] (WorkflowExecutionMonitor.java:66) komodor.WorkflowExecutionMonitor: Starting workflow: ComplianceRecommendation$Remediate.java DEBUG [ComplianceRecommendation.Remediate(15219)] (WorkflowExecutionMonitor.java:74) komodor.WorkflowExecutionMonitor: ComplianceRecommendationID = 85507
861
DEBUG [ComplianceRecommendation.Remediate(15219)] (WorkflowExecutionMonitor.java:74) komodor.WorkflowExecutionMonitor: TargetID = 83564 DEBUG [ComplianceRecommendation.Remediate(15219)] (WorkflowExecutionMonitor.java:68) komodor.WorkflowExecutionMonitor: Calling workflow: Remediation_Antivirus_Remediation.java INFO [ComplianceRecommendation.Remediate(15219)] (ExecutionLogger.java:342) runtime.ExecutionLogger: start
4. If the provisioning workflow fails, a message will appear in the log.

COPINF029E The system failed to run the workflow Compliance_Validation in order to process execution through the infrastructure.
Check the logs for the Cit_SDI_OnDevice provisioning workflow in the web interface to determine where the error occurred. The error messages in the log can help you to identify which component is the source of the problem. v Open the Workflow Execution Logs view if it is not displayed. a. From the Eclipse menu, click Window > Show View > Other. b. Expand Automation Package and click Workflow Execution Logs. c. Click OK. The Workflow Execution Logs page displays the provisioning workflow run history. There is a limit of 4000 characters for provisioning workflow output. If this limit is exceeded, the output is truncated. Workflow execution log a. From the Tivoli Provisioning Manager user interface go to the "Provisioning Workflows Status" application and select the "Compliance_Validation" workflow instance to be analyzed: v Use the "Go To" menu: Click Go To > Administration > Provisioning > Provisioning Workflow Status b. Alternatively you can reach the same execution log starting from the "Provisioning Task Tracking" application where you can select the task and expand its details: v Use the "Go To" menu: Click Go To > Provisioning Reports > Provisioning Task Tracking 5. The log console.log also contains errors for compliance and remediation errors as described here Compliance log file locations.
2. Target status
Check the progress of the job on the target computer for the compliance task. Check the log that corresponds to the task that ran and the infrastructure that was used to perform the task. This only applies if using scalable distribution infrastructure. 1. On the target computer verify that the job was received for processing. Look in CA_HOME/logs/ trace-log-number.xml. CA_HOME The agent installation directory v v v
Windows HP UX AIX
Linux Solaris
/opt/tivoli/ep
/usr/tivoli/ep
number A number such as 1. The following message shows that the job was received.
JES023I Processing job: name = [CitScan], requestId = 6e58be70988b11dfbef4000c291214c0]
If the job was not received, check the following items: a. Verify communication with the target computer. Run the TCA_PingAgent provisioning workflow.
862
b. If the compliance task is taking a long time to complete, one possible cause is that the target computer is not polling for jobs, so the job is never received. To fix this problem, see Jobs not reaching target computer. 2. If using scalable distribution infrastructure, verify that the discovery job ran in trace-log-number.log. For an Inventory discovery, the following line indicates that the results of the discovery were generated on the target computer.
CIT034I Combined CIT output file as an XML import format C:\Program Files x86)\tivoli\ep\conf\org.eclipse.osgi\bundles\167\data\cit_tpmlabw2k82010.08.04.11.26.20.xml
The following line indicates that the discovery results were uploaded to the provisioning server:
JES037I Done executing work item: Job [CitScan], Work Item [ScanFileUpload]
3. If using scalable distribution infrastructure, check the following log files on the target computer for additional information.
Windows HP UX AIX
Linux Solaris
/opt/tivoli/ep
/usr/tivoli/ep
4. If an error occurs in step 3 on the target computer, check the TCA log files by reviewing Log files for the common agent. Additional troubleshooting information can also be found in the troubleshooting section specific to the triggered operation. Using Tivoli Security Compliance Manager result XML files The subagent and collector output XML files can be used for troubleshooting compliance-related problems. In order to obtain them, you must turn on debugging for the common agent: a. Enable tracing for the common agent, as described in Compliance log files. b. Run the inventory scan. XML files will be generated on the target computer in the common agent installation directory. The files will have the following name patterns:
scm_<hostname>_collectors<timestamp>.xml scm_<hostname>__converted<timestamp>.xml
Note: For more troubleshooting information for the target computer, see the troubleshooting documentation for the specific task that ran. Related links Support information about compliance Log files Example: Restricting software on page 855
Log files
Log files help in diagnosing problems and recording commands.
Web interface errors

If you encounter Compliance Management errors in the web interface, check the following log for details: v v
Windows UNIX
%TIO_LOGS%\j2ee\console.log
Linux
$TIO_LOGS/j2ee/console.log
863
Compliance and remediation processing errors

If you encounter compliance and remediation processing errors, check the following log for details: v v
Windows UNIX
Linux
Using SCM collector and SCMCollectorSubagent result XML files

The subagent and collector output XML files can be used for troubleshooting compliance-related problems. In order to obtain them, you must turn on debugging for the common agent: 1. Enable tracing for the common agent, as described in Setting log levels for Tivoli Common Agent 2. Run the inventory scan. XML files will be generated on the target computer in the common agent installation directory. The files will have the following name patterns: scm_<hostname>_collectors<timestamp>.xml and scm_<hostname>__converted<timestamp>.xml,
Compliance problems and limitations

Remediation task cannot be run

You cannot perform a remediation task if you have not approved the related recommendation from the web interface.
Symptoms
You attempt to perform a remediation task but you receive the following error message:
The recommendation with ID: ID_number is not in a valid state for the run action
Causes
You cannot perform a remediation task if you have not approved the related recommendation from the web interface.

Verify the compliance recommendation state and, if needed, approve the recommendation before trying to run the remediation task.
Compliance checks are duplicated if computer belongs to multiple groups

If a computer belongs to more than one group, the compliance checks of those groups might conflict with each other.
Symptoms
A computer has a compliance check listed more than once.
Causes
This occurs when a computer is a member of more than one group and two or more of these groups define the same compliance check. Because each compliance check has specific settings, they can be set up differently from each other, and there might be conflicting compliance checks.
864
For example, one group might require that a certain software product be installed, and another group, that the computer belongs to, might prohibit the same software.

This can be resolved by using the Ignore action on one of the recommendations associated with the duplicate check, or by changing the group memberships of the computer to avoid the conflict.
Compliance checks are duplicated if computer belongs to a group

If a computer is part of a group, the compliance checks of the computer and of the group might conflict with each other.
Symptoms
A computer has a compliance check listed more than once.
Causes
This occurs when the same compliance check is defined for a computer and also for at least one group to which that computer belongs. Because each compliance check has specific settings, they can be set up differently from each other, and there might be conflicting compliance checks. For example, one group might require that a certain software product be installed, and one of the computers in the group might prohibit the same software.

This can be resolved by using the Ignore action on one of the recommendations associated with the duplicate check, or by changing the group memberships of the computer to avoid the conflict.
Compliance inventory scan will not run

The common agent must be installed on the target machines when running certain compliance checks.
Symptoms
The compliance inventory scan will not finish successfully.
Causes
If you are running a compliance inventory scan on a target computer or group for any of the following compliance checks: v AIX Activity Logging v AIX Remote Root Login v Linux System Logging v UNIX File Permissions v UNIX Services v v v v v v v Windows Antivirus Windows Event Logging Windows File Permissions Windows Firewall Windows Screen Saver Windows Services Windows Unauthorized Guest Access
865
v Windows User Password then the common agent must be installed on the target machines. If the common agent is not installed, then the compliance inventory scan will fail.

To resolve this problem, run the compliance inventory scan again after installing the common agent. Alternatively, you can remove any of the compliance checks listed above from your computer or group, and then run the inventory scan again.
Compliance check settings cannot be modified

If a computer is a member of a group, it inherits all of the compliance checks of its parent group. You cannot modify an inherited compliance check directly.
Symptoms
You cannot modify a compliance check directly when it is inherited from another group.
Causes
If a computer is a member of a group, it inherits all of the compliance checks of its parent group. These compliance checks are listed in the Compliance tab for the computer, but you cannot modify an inherited compliance check directly.

To edit inherited compliance checks, you must work directly with the group they are inherited from. To access the parent group for a compliance check, click its name in the Group column.
No recommendation after Linux System Logging check

The SCM collector agent of the common agent does not collect syslog information on SUSE Linux Enterprise Server 10 (x86 32-bit).
Symptoms
You receive no recommendation after running a Linux System Logging check on SUSE Linux Enterprise Server 10 (x86 32-bit).
Causes
The SCM collector agent of the common agent does not collect syslog information about SUSE Linux Enterprise Server 10 (x86 32-bit).
Compliance check does not recognize that Windows Native firewall is running
This is a known limitation if the computer is the member of a domain. It can be ignored.
Symptoms
The following message is given when you run a Windows Firewall compliance check on a computer that is using Windows Native Firewall, and when the Track traffic setting is set to Yes:
Change the value of the "Track traffic" setting for the firewall software "Windows Native Firewall" to match the compliant value "true"
This occurs even when the firewall is active.
Causes 866
This occurs if the computer is the member of a domain. This is a known limitation.

You can ignore this recommendation by selecting it in the Recommendation page and clicking Ignore. You can also specify the reason you have chosen to ignore the recommendation.
Recovering from compliance problems

Perform the following steps to recover from compliance problems. For additional information about compliance log files, see Compliance log files.
Step where the problem occurs Resolving the problem Log files Windows v %TIO_LOGS%\j2ee\console.log v <WAS_PROFILE_DIR>\logs\MXServer\ SystemOut.log v <WAS_PROFILE_DIR>\logs\MXServer\ SystemErr.log UNIX and Linux v $TIO_LOGS/j2ee/console.log v <WAS_PROFILE_DIR>/logs/MXServer /SystemOut.log v <WAS_PROFILE_DIR>/logs/MXServer /SystemErr.log
The problem is related to the Web v Viewing compliance-related information in the Provisioning interface. Check for exceptions or errors in the Web interface log files. Computers and Provisioning Groups applications v Creating, deleting, copying, or editing compliance checks v Approving, opening, ignoring, closing, or viewing recommendations v Configuring advanced options for remediation, before the dialog regarding Task Tracking application is displayed
867
Step where the problem occurs Running a compliance scan or compliance remediation
Resolving the problem Running through the deployment engine: The problem is related to the workflow execution in the deployment engine. If the problem occurs in common agent-related activities, check the endpoint logs.
Log files Server side on Windows v $TIO_LOGS/console.log v $TIO_HOME/SCMCollectorAgent/ <deviceID>-scmSubagentInput.xml v $TIO_HOME/SCMCollectorAgent/scm_ <hostname>_converted <timestamp>.xml
Endpoint side on Windows v %AGENT_INSTALL_DIR%\logs\ The workflow log from the error-log-xx.xml Provisioning Task Tracking v %AGENT_INSTALL_DIR%\logs\ interface is also useful for trace-log-xx.xml problem determination. The v %AGENT_INSTALL_DIR%\ SCMCollector xml files are scm_<hostname> related only to compliance _collectors.xml scans. They are written only Endpoint side on UNIX or Linux if the server and endpoint v $AGENT_INSTALL_DIR/logs/ log level have been error-log-xx.xml respectively set to DEBUG. v $AGENT_INSTALL_DIR/logs/ Running through the scalable trace-log-xx.xml distribution infrastructure: v $AGENT_INSTALL_DIR/ Use the same procedure as scm_<hostname>_collectors.xml described above for the deployment engine. Additionally check the console.log. It is useful for tasks submission, result management, and other small tasks like DMS jobs triggering. Be sure to check the endpoint log files. No workflow execution log is available from Provisioning Task Tracking. It is available only from Workflow Status interface and only in the case of patch management. Running a compliance check The problem is related to the workflows execution in the deployment engine. Nothing is run on the endpoint side. Also check the workflow log from the Provisioning Task Tracking interface. Windows %TIO_LOGS%\console.log UNIX $TIO_LOGS/console.log
Incorrect recommendation generated by password security check

When the BIOS properties of a specific computer do not contain the power-on password setting value, it cannot be detected by Tivoli Provisioning Manager Inventory Discovery, and an incorrect recommendation is generated.
Symptoms
When you define a Windows Power-On Password security check in the Compliance tab and run a scan and check task on a computer, the following incorrect recommendation might be generated:
868
Run an inventory scan to discover information about the "Windows Power-on Password" setting for this computer
Causes
This error occurs when the BIOS properties of a specific computer do not contain the power-on password setting value. In this case the information about the power-on password cannot be detected by the Tivoli Provisioning Manager Inventory Discovery and a wrong recommendation is generated.
IBM WebSphere Application Server configuration generates incorrect recommendation

To ensure that the WebSphere Application Server configuration compliance is correctly checked, create the software configuration template check using the Profile: default installation option.
Symptoms
When you create a software configuration template for a WebSphere Application Server installation, selecting IBM WebSphere Application Server - xxx for both creating the template and defining the software configuration check, the recommendation generated after running a compliance scan and check might become incorrect, and cause the following message to be displayed:
Define the configuration settings on the computer for the software installation "Profile: default" to match the compliant value.
Causes
The TADDM discovery populates the data model with IBM WebSphere Application Server - xxx as the base WebSphere Application Server installation. This object contains only some installation parameters. When the compliance check is run, the parameters are checked also against Profile: default as the base WebSphere Application Server installation. This generates recommendations that are incorrect.

To ensure that the WebSphere Application Server configuration compliance is correctly checked, create the software configuration template check using the Profile: default installation option.
Reference
Security compliance reference

This topic provides a summary of the security compliance checks that you can define for a computer or group of computers. Table 158 shows the types of security compliance check that you can add for a computer or group of computers and the settings that you can define. Only one of each type of security compliance check can be added for any computer.
Table 158. Security compliance checks Compliance check AIX Activity Auditing Platform AIX Purpose Checks for the existence of certain AIX activity audit logs. Settings Select the logs to be checked: v Connection time logs v Set user ID logs v Logon failure logs Multi-rule? No
869
Table 158. Security compliance checks (continued) Compliance check AIX Remote Root Login Target Agent Platform AIX Purpose Settings Multi-rule? No No
Checks remote root login settings. v Remote login allowed: Yes, No. v Status of the agent v Maximum number of hours between contact.
AIX, Linux, Checks target agent settings Solaris, HP-UX, and Windows Linux
Linux System Logging
Checks for the existence and v Facility configuration of different types of v Priority Linux system logs. Define a rule v Destination for each log to be checked. Note: It is not possible to enable or disable these settings individually.
Yes
Operating System Patches and Updates (Patch Check)
AIX, Solaris, Linux, HP-UX, and Windows
Checks that all operating system patches and updates required by Tivoli Provisioning Manager patch management are installed.
v Patch approval group Note: You cannot change the patch approval group after you have saved the setting. If you have chosen the wrong group, delete the check and create it again.
No
Restrict Other Software
AIX, Linux, Solaris, HP-UX, and Windows
No settings Checks that only the required software specified in the software compliance checks is installed on the target computers. When this check is added, the Allowed Software tab shows all the required software.
No
UNIX File Permissions
AIX, Linux, Solaris, and HP-UX AIX, Linux, Solaris, and HP-UX
Checks UNIX file permissions for v IsDirectory each file you specify. You can v Permissions create a rule for each file you want to check. Checks for missing or prohibited UNIX services. Also checks for configuration of the service and state of the service. You can create a rule for each service you want to check. v Port number v Protocol v Service state
Yes
UNIX Services
Yes
User Defined Check
AIX, Linux, Solaris, HP-UX, and Windows
Implements checks that you have v Name of the check defined as automation packages. v Provisioning workflow You can create a rule for each to implement the check automation you have created.
Yes
870
Table 158. Security compliance checks (continued) Compliance check Windows Antivirus Platform Windows Purpose Checks for various antivirus settings, such as the maximum virus definition age. Settings v Maximum elapsed time between virus scans Multi-rule? No
v Maximum virus definition age The following antivirus programs are supported: v Auto update virus definition schedule v Symantec Antivirus Corporate Edition (Versions 8.x and 9.x)
v Norton Antivirus Corporate Edition (Version 7.x) v Norton Antivirus (Versions 5.x and 6.x) v Trend Micro Antivirus (Version 7) v McAfee VirusScan Enterprise (Versions 7.0, 8.0i, and 8.5i) v Sophos Anti-Virus (Versions 3.xx, 4.5x, and 5.x). Windows Event Logging Windows Checks Windows event logging settings. v Minimum retention period of application data v Minimum retention period of security data v Minimum retention period of system data v Minimum value of the maximum application log size v Minimum value of the maximum security log size v Minimum value of the maximum system log size No
871
Table 158. Security compliance checks (continued) Compliance check Windows File Permissions Platform Windows Purpose Settings Multi-rule? Yes
Checks Windows file permissions v List folder/Read Data for each file you specify. You can v Create Files/Write Data create a rule for each file that you v Create Folders/Append want to check. Data v Read Extended Attributes v Write Extended Attributes v Traverse Folder/Execute File v Delete Subfolders and Files v Read Attributes v Write Attributes * Delete v Read Permissions v Change Permissions v Take Ownership v Synchronize
Windows Firewall
Windows
Checks firewall settings. The following firewall programs are supported v McAfee Desktop Firewall (Versions 8.0 and 8.5) v Windows Native Firewall v Windows Zone Alarm Integrity Flex Firewall (Version 3.5.175.057).
v Track traffic v Activate Windows service v Windows Service enabled to start automatically
No
Windows Hard Disk Password Windows Power-on Password Windows Screen Saver
Windows Windows Windows
Checks for a hard disk password. v Hard disk password required: Yes, No. Checks for a power-on password. v Power-on password required: Yes, No.
No No
No Checks screen saver settings. v Active Note: Running a compliance v Password protected check for a Windows screen saver v Maximum timeout value might return incorrect results if (minutes) there are two identical user IDs Note: For this setting on the same computer. you are required to log off and reboot the When the local user ID and system after applying domain user ID are identical but the remediation. each user ID has different screen saver settings, Tivoli Provisioning Manager will arbitrarily choose one user ID and read its screen saver settings, and ignore the screen saver settings for the other user ID.
872
Table 158. Security compliance checks (continued) Compliance check Windows Services Platform Windows Purpose Settings Multi-rule? Yes
Checks the existence and v Startup type configuration of selected v Service applicability Windows services. You can create v Service status a rule for each service you want to check. Checks for appropriate guest access settings. v Guest account can only be a member of Guests group v Guest account must be active v Guest account must be locked
Windows Unauthorized Guest Access
Windows
No
Windows User Password
Windows
Checks for password settings.
v Enforce password history (passwords remembered) v Maximum password age v Minimum password length (characters)
No
Running recommendations for DB2

This topic provides a summary of the DB2 version 8 configuration parameters that you can define and check their compliance for a computer or group of computers. You can run recommendations for the following DB2 parameters:
873
DB2 version 8 Parameters v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v agentpri aslheapsz audit_buf_sz authentication catalog_noauth clnt_krb_plugin clnt_pw_plugin comm_bandwidth conn_elapse cpuspeed datalinks diaglevel dir_cache discover discover_inst dft_mon_bufpool dft_mon_lock dft_mon_sort dft_mon_stmt dft_mon_table dft_mon_timestamp dft_mon_uow dftdbpath fcm_num_anchors fcm_num_buffers fcm_num_connect fcm_num_rqb fed_noauth Federated fenced_pool health_mon intra_parallel instance_memory v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v java_heap_sz jdk_path keepfenced local_gsspplugin max_connections max_connretries max_coordagents max_querydegree max_time_diff maxagents maxcagents mon_heap_sz notifylevel num_initagents num_initfenced numdb query_heap_sz rqrioblk sheapthres spm_log_file_sz spm_log_path spm_max_resync spm_name start_stop_time sysadm_group sysctrl_group sysmaint_group sysmon_group tm_database tp_mon_name trust_allclnts trust_clntauth util_impact_lim
Running recommendations for Oracle

This topic provides a summary of the Oracle version 10g configuration parameters that you can define and check their compliance for a computer or group of computers. You can run recommendations for the following Oracle parameters:
Oracle version 10g parameters v v v v AUDIT_FILE_DEST BACKUP_TAPE_IO_SLAVES OBJECT_CACHE_MAX_SIZE_PERCENT OBJECT_CACHE_OPTIMAL_SIZE v OLAP_PAGE_POOL_SIZE v SORT_AREA_RETAINED_SIZE v SORT_AREA_SIZE
Running recommendations for WebSphere Application Server

This topic provides a summary of the WebSphere Application Server version 6 configuration parameters that you can define and check their compliance for a computer or group of computers. You can run recommendations for the following WebSphere Application Server parameters:
874
WebSphere Application Server version 6 parameters v v v v v v v v v v v v v v v v v v v v v v v v ActiveIIOPProtocol AllowOverflow AppClassloaderPolicy AppClassloadingMode AuthDataAlias AutoRestart BaseDN BindDN BootClasspath CacheTimeoutMSeconds Classpath DebugArgs DebugMode DefaultDatasourceJNDIName DisableJIT Enabled EnableJava2SecRuntimeFiltering EnableServletCaching EnforceJava2Security ExecutableJarFileName GenericJvmArguments HprofArguments InactivePoolCleanupIntervalMsecs InitalHeapSizeMB v v v v v v v v v v v v v v v v v v v v v v v InvalidationTimeout IssuePermissionWarning MappingConfigAlias MaximumHeapSizeMB MaxInMemSessionCount MaxStartupAttempts MonitorInterval NodeRestartState PassivationDirectory PingIntervalSecs PingTimeoutMSecs ReuseCollection RunHprof SearchTimeout SessionAffinityFailoverServer SessionAffinityTimeout SslConfig SslEnabled UseDomainQualitifedUserNames UseLocalSecurityServer VerboseModeClass VerboseModeGarbageCollection VerboseModeJNI
Running recommendations for IBM HTTP Server

This topic provides a summary of the IBM HTTP Server version 2.0 configuration parameters that you can define and check their compliance for a computer or group of computers. You can run recommendations for the following IBM HTTP Server parameters:
IBM HTTP Server version 2.0 parameters v v v v v v v v v v v v v v v v v v v v v AccessFileName CoreDumpDirectory DefaultIcon DefaultType DirectoryIndex DocumentRoot EnableMMAP EnableSendfile ErrorLog ExtendedStatus Group HeaderName HostnameLookups IndexIgnore IndexOptions KeepAlive KeepAliveTimeout Listen LogLevel MaxClients MaxKeepAliveRequests v v v v v v v v v v v v v v v v v v v v MaxRequestPerChild MaxSpareThreads MinSpareThreads PidFile ReadmeName ScriptAlias ServerAdmin ServerLimit ServerName ServerRootP ServerSignature ServerTokens StartServers ThreadLimit ThreadsPerChild Timeout TypesConfig UseCanonicalName User UserDir
875
876
Chapter 9. Deploying patches

Patch management is an integral part of protecting customer services, corporate and customer data, and day-to-day operations. Ensuring that computers in your organization have the most up-to-date patches is only a part of your overall computer security strategy, but it is probably the most important one. To get your computers to the most current frame of security, you need an automatic process to apply the latest patches on your computers. Keeping systems up-to-date and compliant with corporate security requirements is complex, because of the following considerations: v Vendors release a large number of updates on a frequent basis. v Tracking and evaluating security risks and the appropriate software updates is time-consuming and requires in-depth knowledge of installed software, hardware and software dependencies, and corporate requirements. v Deployment of patches must be managed to reduce downtime or service interruptions. v Effective auditing and reporting is required to monitor deployment, verify compliance, and troubleshoot errors. You can automatically manage patch acquisition, evaluation, and deployment. You can use Tivoli Provisioning Manager to manage patches for a large number of target computers in a variety of topologies. Note: Using Tivoli Provisioning Manager to manage patches for the computer where Tivoli Provisioning Manager is installed is not supported.
Patch management basics

Find out more about the patch management, the key terms and examples, who the main users are that use patch management, and how to keep your systems up-to-date and compliant with corporate security requirements. Review the troubleshooting information for this feature and additional resources that help you complete your patch management tasks. v v v v v v Process User roles on page 878 Requirements on page 881 Key terms on page 882 Troubleshooting on page 882 Log files on page 883
Process
To learn about the patch management process, see the following platform-specific topics:
Windows AIX Red Hat SUSE Solaris
Patch management process for Windows environments using SDI Patch management for AIX environments Patch management process for Red Hat Enterprise Linux version 5 environments Patch management process for SUSE Linux Enterprise Server 11 environments. Patch management process for Solaris environments
877
User roles
You must be assigned to the appropriate user role to manage patches. For more information about the necessary roles and skills for managing patches on your platform, see the following topics:
Roles and skills for Windows environments Roles and skills for AIX environments Roles and skills for Red Hat Linux Enterprise environments Roles and skills for SUSE Linux Enterprise Server environments Roles and skills for Solaris environments
Table 159. Roles and skills for patch management in Windows environments Role Provisioning Administrator Provisioning tasks v Discover and group target computers v Set up servers and infrastructure Skills v Knowledge of the provisioning environment v Knowledge of the Windows operating system v Knowledge of Internet technologies v Knowledge of scalable distribution infrastructure Provisioning Configuration Librarian v Acquire patches v Scan the target computers for missing patches v Organize and maintain the patch catalog v Create and maintain patch groups, delete patches from the data model Compliance Analyst v Approve patches in the data model v Knowledge of the Windows operating system v Set up compliance v Perform patch check v Approve compliance recommendations v Verify compliance results Deployment Specialist v Install required software on target computers v Publish patches v Distribute patches v Unpublish patches v Implement compliance recommendations to install missing patches v Monitor patch installation v Uninstall patches v Knowledge of the Windows operating system v Knowledge of the patch management life cycle v Knowledge of the patch management life cycle v Knowledge of the Windows operating system v Knowledge of the patch management life cycle
878
Table 160. Roles and skills for patch management on AIX Role Provisioning Administrator Provisioning tasks v Discover target computers v Group target computers Skills v Knowledge of the of the provisioning environment v Knowledge of the AIX operating system v Knowledge of Internet technologies Provisioning Configuration Librarian v Acquire patches v Scan the target computers for missing patches Compliance Analyst v Set up compliance v Approve compliance recommendations v Verify compliance results Deployment Specialist v Install patches v Monitor patch installation v Uninstall patches v Knowledge of the AIX operating system v Knowledge of the patch management life cycle v Knowledge of the AIX operating system v Knowledge of the patch management life cycle v Knowledge of the AIX operating system v Knowledge of the patch management life cycle
Table 161. Roles and skills for patch management in Red Hat Enterprise Linux environments Role Provisioning Administrator Provisioning tasks v Discover and group target computers v Set up servers and infrastructure Skills v Knowledge of the provisioning environment v Knowledge of the Red Hat Enterprise Linux operating system v Knowledge of Internet technologies v Knowledge of scalable distribution infrastructure v Knowledge of how to set up the YUM repository Provisioning Configuration Librarian v Acquire patches v Scan the target computers for missing patches v Organize and maintain the patch catalog v Create and maintain patch groups, delete patches from the data model Compliance Analyst v Approve patches in the data model v Knowledge of the Red Hat Enterprise Linux operating system v Set up compliance v Approve compliance recommendations v Verify compliance results v Knowledge of the patch management life cycle v Knowledge of the Red Hat Enterprise Linux operating system v Knowledge of the patch management life cycle
879
Table 161. Roles and skills for patch management in Red Hat Enterprise Linux environments (continued) Role Deployment Specialist Provisioning tasks v Install required software on target computers v Publish patches v Distribute patches v Unpublish patches v Implement compliance recommendations to install missing patches v Monitor patch installation v Uninstall patches Table 162. Roles and skills for patch management in SUSE Linux Enterprise Server environments Role Provisioning Administrator Provisioning tasks v Discover and group target computers v Set up servers and infrastructure Skills v Knowledge of the provisioning environment v Knowledge of the SUSE Linux Enterprise Server operating system v Knowledge of Internet technologies v Knowledge of the scalable distribution infrastructure v Knowledge of how to configure the SMT or YUM repository Provisioning Configuration Librarian v Acquire patches v Scan the target computers for missing patches v Organize and maintain the patch catalog v Create and maintain patch groups, delete patches from the data model Compliance Analyst v Approve patches in the data model v Knowledge of the SUSE Linux Enterprise Server operating system v Set up compliance v Approve compliance recommendations v Verify compliance results Deployment Specialist v Install required software on target computers v Publish patches v Distribute patches v Unpublish patches v Implement compliance recommendations to install missing patches v Monitor patch installation v Knowledge of the SUSE Linux Enterprise Server operating system v Knowledge of the patch management life cycle v Knowledge of the patch management life cycle v Knowledge of the SUSE Linux Enterprise Server operating system v Knowledge of the patch management life cycle Skills v Knowledge of the Red Hat Enterprise Linux operating system v Knowledge of the patch management life cycle
880
Table 163. Roles and skills for patch management in Solaris environments Role Provisioning Administrator Provisioning tasks v Discover and group target computers v Set up servers and infrastructure Skills v Knowledge of the provisioning environment v Knowledge of the Solaris operating system v Knowledge of Internet technologies Provisioning Configuration Librarian v Scan the target computers for missing patches v Organize and maintain the patch catalog v Create and maintain patch groups, delete patches from the data model Compliance Analyst v Set up compliance v Approve compliance recommendations v Verify compliance results Deployment Specialist v Install required software on target computers v Knowledge of the Solaris operating system v Knowledge of the patch management life cycle v Knowledge of the Solaris operating system v Knowledge of the Solaris operating system v Knowledge of the patch management life cycle
v Implement compliance v Knowledge of the patch recommendations to install missing management life cycle patches v Monitor patch installation v Uninstall patches
Requirements
Target computer requirements:
Requirements for Windows on page 895 Requirements for AIX on page 918 Requirements for Red Hat Enterprise Linux 6 and 5 environments on page 933 Requirements for SUSE Linux Enterprise Server 11 environments on page 956 Requirements for Solaris on page 978
881
Key terms
compliance A state of being in accordance with established software and security specification on target machines, or the process of becoming so. compliance check A group of settings used to determine whether a computer or group of computers is compliant or not. There are two types of compliance checks: software and security. compliance report A report that provides information about the patch compliance status of all selected target computers. compliant state The state of conforming to the defined rules of compliance. deployment engine A component of Tivoli Provisioning Manager that runs provisioning workflows. depot server The component that stores files for distribution. Files are uploaded to a depot server using a client and stored in a directory that is specified when the depot server is installed. Depot servers can replicate files to other depot servers. Target computers can download files from depot servers or peers. distribute To disperse software packages, software patches, and software stacks to be installed over one or more targets. distribution infrastructure A framework for software distribution supporting software management tasks including configuration, distribution, installation, and asset inventory management. noncompliance The failure to comply with compliance checks. region A logical grouping of depot servers. Regions typically group depot servers by network proximity or geographical region to optimize replication and download times.
scalable distribution infrastructure A solution that ensures fast and reliable software distribution to large numbers of target computers in a variety of topologies. It enables central management of software distribution, and relies on core services such as Tivoli Common Agent services, the dynamic content delivery, and device manager service to perform the actual software distribution and federated job management operations. service access point (SAP) The protocol and credentials associated with an IT asset for authentication of remote operations. An IT asset can have more than one service access point. zone An IP range or domain that is used to logically group computers into regions. You can define one or more zones for each region.
Troubleshooting
v Patch management troubleshooting checklist on page 992 v Log files on page 996 v Patch management problems and limitations on page 997 v Patch messages v Support information about patch management v Contacting Support
882
Log files
Follow the steps below and review the indicated log files to recover from patch management problems: v Scalable distribution infrastructure patch acquisition v Scalable distribution infrastructure patch installation v Windows patch installation v Scalable distribution infrastructure patch scan v Solaris patch management log files
Scalable distribution infrastructure patch acquisition If you encounter patch management errors during patch acquisition using the scalable distribution infrastructure, check the following log file for details: v
Windows
TIO_LOGS/wsusscan.log (On the Tivoli Provisioning Manager server)
Scalable distribution infrastructure patch installation If you encounter patch management errors during patch installation using the scalable distribution infrastructure, check the following log files for details: v v v
Windows Red Hat SUSE
<systemdrive>:\Windows\windowsupdate.log <agent logs> /tmp/tpminstallupdates.log (on target computers) /tmp/tpmzypperinstallupdates.log (on target computers)
Windows patch installation If you encounter problems during patch installation on Windows using Windows Server Update Services, check the <systemdrive>:\Windows\windowsupdate.log log file. Scalable distribution infrastructure patch scan If you encounter patch management errors during a patch scan using the scalable distribution infrastructure, check the following log files for details: v v v
%TEMP%\<date>__patchscan__<time>.log <agent logs> /tmp/tpmscanupdates.log (on target computers) /tmp/tpmzypperscanupdates.log (on target computers)
Solaris patch management log files The following table provides information about where you can find Solaris patch management log files.
Table 164. Solaris patch management log files Description Information about applied or uninstalled patches Information about patches installed successfully Log files /var/sadm/spool/sunucLog/job_history.log /var/sadm/<patch id>/log
883
Resources
To learn more about patch management, refer to one of the following resources: v
Windows Tutorial: Managing patches in Windows environments using the Scalable Distribution Infrastructure on page 895 AIX Red Hat
v v
Tutorial: Managing patches in AIX environments on page 917 Tutorial: Managing patches in Red Hat Enterprise Linux 6 and 5 environments on Tutorial: Managing patches in SUSE Linux Enterprise Server 11 environments on
page 932 v
SUSE
page 955 v
Solaris Tutorial: Managing patches in Solaris environments using Sun Update Connection on page 977 HP UX
Managing patches in HP-UX environments on page 985
v Demo: Patch management across multiple operating systems in the product wiki. v Chapter 9, Deploying patches, on page 877 v Cross platform feature support v For a description of a field in the web interface, press Alt+F1.
Related links Chapter 9, Deploying patches, on page 877 Cross platform feature support Troubleshooting SDI Windows patch management on page 989 Tutorial: Managing patches in Windows environments using the Scalable Distribution Infrastructure on page 895 Tutorial: Managing patches in AIX environments on page 917 Tutorial: Managing patches in Red Hat Enterprise Linux 6 and 5 environments on page 932 Tutorial: Managing patches in SUSE Linux Enterprise Server 11 environments on page 955 Tutorial: Managing patches in Solaris environments using Sun Update Connection on page 977
Cross platform feature support

There are a number of important Tivoli Provisioning Manager patch management features that are common across some, but not all platforms.
Patch acquisition
Depending on your platform, you need to complete a procedure to directly acquire patches into the data model. On some platforms, you do not complete the patch acquisition process. The following table provides information about the platforms on which you need to perform patch acquisition.
You can uninstall patches on some platforms. Before uninstalling patches, you need to be certain that there are no dependencies on the patches that you are uninstalling and you need an in-depth knowledge of the platform and potential issues that might arise when patches are uninstalled. Do not uninstall patches unless you are certain that the patches are no longer required and that there are no adverse effects on your target computers or environment. The following table provides information about the platforms for which you can uninstall patches.
884
Rebooting target computers

You might need to reboot target computers after you install patches on those target computers. The following table provides information about the platforms on which reboot is supported.
Commit
You need to commit the patch installation only on AIX. Commit is not supported on any other platform.
Proxy support
Depending on your platform, you can use a proxy server. The following table provides information about the platforms for which you can use a proxy server.
Cross platform support

Depending on your platform, some features are unavailable. The following table provides a quick reference on cross platform features that are available.
Table 165. Cross platform support Platform Windows Version Any Windows operating system using Windows Server Update Services Any Windows operating system using the scalable distribution infrastructure AIX All supported AIX operating systems Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 SUSE Linux Enterprise Server SUSE Linux Enterprise Server 10 SUSE Linux Enterprise Server 11 Solaris Patch acquisition Yes Reboot if required Yes Commit No Uninstall Yes Proxy support Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes, except for AIX 7.1 No
No
Red Hat Enterprise Linux
No
Yes
No
Yes
Yes
No
No
No
Yes
No
No
No
No
Yes
Yes
No
No
No
Yes
Any supported No Solaris operating systems
Yes
No
Yes
Yes
885
Table 165. Cross platform support (continued) Platform HP-UX Version Patch acquisition Reboot if required Yes Commit No Uninstall No Proxy support No
Any supported No HP-UX operating systems
Managing patches in Windows environments

You can manage patches in Windows environments using the scalable distribution infrastructure and using the deployment engine. By automating patch management, you can ensure that all target computers in your environment are fully compliant with the latest patches in your data model. You can complete compliance checks and identify any target computers that do not have the correct patches installed.
Supported platforms
You can manage patches for the following Windows operating systems and versions: v Microsoft Windows Server 2008 Standard Edition (x86 64-bit) any SP v v v v v Microsoft Microsoft Microsoft Microsoft Microsoft Windows Windows Windows Windows Windows Server 2008 Standard Edition (x86 32-bit) any SP Server 2008 Enterprise Edition (x86 64-bit) any SP Server 2008 Enterprise Edition (x86 32-bit) any SP Server 2008 R2 Standard Edition (x86 64-bit) any SP HPC (High Performance Computing) Server 2008 R2
v Microsoft Windows 7 Professional (x86 32-bit/ 64-bit) any SP v Microsoft Windows 7 Enterprise (x86 32-bit) any SP v v v v v v v v v v v v Microsoft Windows Windows Windows Windows Microsoft Microsoft Microsoft Microsoft Microsoft Microsoft Microsoft Windows 7 Enterprise (x86 64-bit) any SP Vista Ultimate Edition (x86 64-bit) any SP Vista Ultimate Edition (x86 32-bit) any SP Vista Enterprise Edition (x86 64-bit) Vista Enterprise Edition (x86 32-bit) Windows Server 2003 Standard Edition (AMD 64-bit) any SP Windows Server 2003 Enterprise Edition (AMD 64-bit) any SP Windows Windows Windows Windows Windows Server 2003 Standard Edition (x86 64-bit) any SP Server 2003 Enterprise Edition (x86 64-bit) any SP Server 2003 Standard Edition (x86 32-bit) any SP Server 2003 Enterprise Edition (x86 32-bit) any SP XP Professional (64-bit) any SP
v Microsoft Windows XP Professional (32-bit) any SP The following sections provide information about managing patches in Windows environments using the scalable distribution infrastructure and the deployment engine. v Tutorial: Managing patches in Windows environments using the Scalable Distribution Infrastructure on page 895 v Managing patches in Windows environments using the deployment engine on page 911
886
Windows environments using the scalable distribution infrastructure

You can manage patches in Windows environments using the scalable distribution infrastructure. This section provides information about how to manage patches in Windows environments using the scalable distribution infrastructure. It describes the patch management process and includes a tutorial about how to manage patches.
Patch management process

It is important to understand the overall patch management process before you start to manage patches using the provisioning applications.
This topic applies to patch management for Windows environments using the Scalable Distribution Infrastructure (SDI).
Patch management includes the processes that are illustrated and detailed later in this section. Roles for each step in the process are noted in parentheses.
Discover computers
Set up environment
Install WUA
Acquire patches
Test patches
Approve patches in the data model
Set up compliance Scan for missing patches Approve compliance recommendations Install patches
Legend
Provisioning Administrator Provisioning Configuration Librarian Compliance Analyst Deployment Specialist
Verify compliance results
Monitor patch installation
1. Discover computers and set up the environment (Provisioning Administrator) This process consists of the following tasks:
887
v Run initial discovery to discover all computers and to add them to the data model. Initial discovery identifies what operating system is installed on your target computers, which is required to make sure that patches for that operating system are acquired in a later step in the process. As part of initial discovery, you group the discovered target computers to manage patches for multiple computers at the same time. Tip: The provisioning configuration librarian can also complete the task of discovering computers. v Depending on the configuration used in your organization, you must set up a number of servers to discover the patches that are released by the vendor. This might include a patch server, download server, and proxy server. v Set up the scalable distribution infrastructure to manage distribution and installation of patches on the target computers. Tip: The provisioning configuration librarian can also complete the task of setting up the infrastructure. 2. Install required software on target computers (Deployment Specialist) This process consists of installing the common agent and Windows Update Agent (WUA) on the target computers. The common agent is a software product that is required for software distribution and software compliance management. WUA is a Windows software product that is required so that you can determine which target computers require patches. 3. Acquire patches (Provisioning Configuration Librarian) This process consists of specifying your patches of interest from those released by the vendor, and bringing those patches into the data model. 4. Test patches Testing patches is recommended as part of the patch management life cycle process. Testing patches ensures that all possible conflicts have been identified in a test environments before installing the patches in the production environment. You can install the patches to defined test environments using the patch installation application, but the actual testing of patches must be performed outside of the provisioning applications. Therefore, this task does not have a role associated with it. Normally, the test engineer in your organization performs this task. 5. Approve patches (Compliance Analyst) This process consists of approving which patches you want to install. Two levels of approval are required: for the entire organization (at the data model level), and per target computer or group of target computers, if a patch is missing from the group. 6. Set up compliance (Compliance Analyst) This process consists of creating compliance checks to determine if the software installed on the target computers matches your requirements. Compliance checks define the state of compliance of your target computers and are used to detect, report, and recommend how to fix noncompliance. You add a patch check to a group of target computers. When doing so, you can identify specific patch approval groups to scan. 7. Scan for missing patches (Provisioning Configuration Librarian) This process consists of scanning the target computers and checking to identify which patches are missing from the target computers. After the scan, a list of missing patches is generated and then the check creates compliance recommendations for each computer or group. 8. Approve compliance recommendations (Compliance Analyst) This process consists of approving the patches that you want to install. You approve patches per target computer or group of computers, if a patch is missing on the target computers. 9. Install patches and monitor patch installation (Deployment Specialist)
888
This process consists of distributing and installing the patches on target computers. You can distribute and install patches at the same time or schedule these tasks separately. You can install patches on a specific target computer or multiple target computers into one task. You can also monitor the progress of patch installation. 10. Verify compliance results (Compliance Analyst) This process consists of validating that the patches were successfully applied to all the target computers. You run the compliance check again to verify that the installed patches are no longer displayed on the list of recommendations.
Components for Windows environments using SDI

To manage patches in Windows environments, set up your configuration so that all components work together.
Supported configurations are presented later in this section. Windows installed on the provisioning server: In the configuration illustrated in the following diagram, the provisioning server has the Windows operating system installed and has direct access to the Internet.
Internet
Provisioning server (Windows)
In the configuration illustrated in the following diagram, the provisioning server has the Windows operating system installed. Internet access is provided using a proxy server.
Internet
Proxy server
Proxy authentication with SAP
Provisioning server (Windows)
UNIX operating system installed on the provisioning server without download server: If the provisioning server has a UNIX operating system installed, but there is no requirement to have a Windows computer (Microsoft patch download server) to extract the cab file that contains the patches, you must complete the following steps: 1. Unset the <wsus-download-server-name> global variable.
889
2. Create a variable named cabextractcommand to extract the cab file, setting its value as follows:
Important considerations: v The cabextract variable and the <wsus-download-server-name> variable are alternatives for extracting the .cab files on UNIX systems and you cannot use them together. If you are using the cabextract variable, you cannot use the <wsus-download-server-name> variable. v The cabextract utility that you use must be supported by the UNIX operating system that is installed on the provisioning server. v Do not include any paths in the cabextract command. v Make sure that the executable file is in the system path. UNIX operating system installed on the provisioning server with download server: In the configuration illustrated in the following diagram, the provisioning server has a UNIX operating system installed, for example AIX or Red Hat Linux. A computer called the Microsoft patch download server is used to download and extract the .cab files from the Internet. The Microsoft patch download server has the Windows operating system installed.
Internet
Microsoft patch download server
Provisioning server (AIX or Red Hat Linux)
In the configuration illustrated in the following diagram, the provisioning server has a UNIX operating system, such as AIX or Red Hat Linux, installed. A computer, called the Microsoft patch download server, downloads and extracts the .cab files from the Internet. The Microsoft patch download server has the Windows operating system installed. Internet access is provided using a proxy server.
890
Internet
Proxy server
Proxy authentication with SAP
Microsoft patch download server
Provisioning server (AIX or Red Hat Linux)
Note: Downloaded patches are saved in .zip format. If you download a large number of patches, ensure that the native extract utility installed on the UNIX provisioning server has large file support. Related tasks Setting up the target restart notification on page 610 Related information Setting up the proxy server on page 900 Tutorial: Managing patches in Windows environments using the Scalable Distribution Infrastructure on page 895 Windows environments using the scalable distribution infrastructure on page 887
Acquiring patches over the scalable distribution infrastructure

To acquire Windows patches, you can use a Microsoft Windows Server Update Services server or you can acquire patches directly from the Microsoft Update website. You can use Tivoli Provisioning Manager to provision operating system patches that you acquire from Microsoft. You cannot use Tivoli Provisioning Manager to manage patches for Microsoft software products such as Microsoft Internet Explorer.
Table 166. Windows patch acquisition options over SDI Patch acquisition method Microsoft Windows Server Update Services server Directly from Windows Update Network Description The WSUS server acquires the patches from Microsoft Update site. You acquire patches directly from the Microsoft Update site.
Acquiring patches using a Microsoft Windows Server Update Services server

Complete information about the patch management process over the scalable distribution infrastructure is described in Tutorial: Managing patches in Windows environments using the Scalable Distribution Infrastructure on page 895. However, you must use the information provided here for the WSUS server-specific configuration.
891
If you use a Microsoft Windows Server Update Services server to acquire patches over the scalable distribution infrastructure, you require the following Microsoft components: Microsoft Windows Server Update Services (WSUS) server The WSUS server is a computer that is connected to the Microsoft Update Web site to get the latest patches. The system administrator must ensure that this computer is maintained. This is a manual process performed outside of the provisioning server. To be able to install patches on target computers that belong to a provisioning group, you create an association between the WSUS server and that group. After this association is established, all the approved patches can be installed on the target computers. Multiple provisioning groups can use the same WSUS server. If more than one WSUS server is used in your organization, at least one of them must connect to the Microsoft Update Web site to obtain the available updates. This WSUS server can then be used as an update source for all of the other WSUS servers. After installing the WSUS server, synchronize it with the Microsoft Update Web site to get the latest software updates. By default, the WSUS server is configured to use the Microsoft Update Web site as the location to obtain updates. To automatically update your WSUS server with the latest Windows patches, ensure that synchronization with the Microsoft Update Web site is enabled. Based on the software security policy in your organization, schedule synchronization to update the WSUS server. For more information about the synchronization feature, see your WSUS documentation. Windows Update Agent (WUA) The client component installed on the target computers is required to receive updates either from a WSUS server or directly from the Microsoft Update site. If the target computers belong to a provisioning group that is not associated with a WSUS server, the WUA clients installed on the target computers are set up to connect to the Microsoft Update site to search for the latest patches, download them, and then install them on the target computers. If a proxy server is present, the WUA client uses the Internet Explorer settings for authentication. The proxy server must be configured outside the provisioning applications. Verify that the following requirements are met: v The WSUS server must have WSUS 3.0 and Microsoft .NET Framework 3.5 installed on it. Review the software and hardware requirements, and then download and install Microsoft Windows Server Update Services and its prerequisites using the documentation from the Microsoft Web site. Run initial discovery to add the WSUS server to the data model. v User roles for patch management are listed in the User roles and requirements on page 896 topic. v Requirements for the target computers are listed in the Requirements for Windows target computers on page 556 topic. To associate the WSUS server with the target computers, create a variable named WSUServer with the value http://<WSUS_server_name>:<port_number> or https://<WSUS_server_name>:<port_number>, where WSUS_server_name is the name of the WSUS server. This computer must exist in the data model. If using the https:// notation, make sure that the target computers trust the certificate from the WSUS server. If you are using a WSUS server over the scalable distribution infrastructure, you must set the wsus-over-sdi global variable for the patch provisioning and deployment. By default, a configuration including a WSUS server uses the deployment engine for patch provisioning, rather than scalable distribution infrastructure. Setting the wsus-over-sdi global variable, the patch provisioning on targets having scalable distribution infrastructure service access points are performed over the deployment engine using WSUS, other tasks like Inventory or Software Distribution are performed over the scalable distribution infrastructure. To set the wsus-over-sdi global variable, complete the following steps: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Variables tab.
892
3. Click New Row to create the wsus-over-sdi global variable. 4. Enter the following details for the WSUS variable: a. In the Variable field, enter wsus-over-sdi. b. In the Component field, select Entire system. c. In the Value field, type true. d. Save the changes.
Acquiring patches using the Windows Update Network

If you are not using a Microsoft Windows Server Update Services server to acquire patches, you acquire patches directly from the Microsoft Update site. Complete information about how to configure your environment to acquire patches directly from the Windows Update Network is described in Tutorial: Managing patches in Windows environments using the Scalable Distribution Infrastructure on page 895.
Acquiring Windows patches offline through the scalable distribution infrastructure

You can also acquire Windows patches offline, over the scalable distribution infrastructure (SDI), using the MS_Patch_Offline_For_SDI automation package. Tivoli Provisioning Manager currently offers enterprise-level patching for Microsoft Windows target computers. This style of patching allows a single point of control. Tivoli Provisioning Manager becomes the central conduit, through which all patches pass before being distributed to the infrastructure. This process works well when the provisioning server is able to contact the Internet directly or through a proxy. You can also use a Windows target to do all patch processing, when Tivoli Provisioning Manager is on a UNIX operating system. In some secure environments, Tivoli Provisioning Manager might not have access to the Internet. Infrastructures that are isolated in this way still need the protection and functionality made available by Microsoft Updates. For these environments, the patch processing that Tivoli Provisioning Manager needs is provided without a direct connection to the Internet. Before you begin Ensure that you meet the following requirements: v v v v Tivoli Provisioning Manager, version 7.2 or later An Internet-facing Windows or UNIX computer A scalable distribution infrastructure (SDI) of Windows targets to patch UnZip 6.0 installed on the provisioning server, to extract large files when using the -cabextract flag with the MS_Patch_Offline_For_SDI automation package. Ensure that UnZip is referenced at the system level for all users.
Note: v An Internet-facing computer with a fast connection is recommended. Running the offline collection of patches must be done after Microsoft's Patch Tuesday. It must also be run if high-priority patches are released by Microsoft. v The ms_patch_download_offline.sh/.cmd command can accept the optional flag -cabextract, which causes the extraction of the wsusscn2.cab file to take place on the Internet-facing Windows computer. This can be useful if the provisioning server is on UNIX (which does not include any cab-extraction utilities) and the cabextractcommand global variable is not used. To acquire Windows patches offline using the Tivoli Provisioning Manager web interface:
893
Procedure
1. Set the global variable ms.sdi.patch.use.offline to true. 2. Run the workflow MS_Patch_Generate_Offline_Script with no parameters. 3. Copy the ms_offline_patch_scripts.tar/.zip to the Internet-facing computer (the bundle is located in /tmp or /cygwin/tmp) . 4. Decompress the bundle ms_offline_patch_scripts.tar/.zip and enter the ms_patch_download_offline.sh/.cmd command. This creates the offline_patches.tar/zip file. The ms_patch_download_offline.sh/.cmd command accepts the optional flag -cabextract, which performs the extraction of the wsusscn2.cab file to the Internet-facing Windows computer. For example, ms_patch_download_offline.cmd -cabextract. 5. Copy the file offline_patches.tar/.zip to the TIO_HOME/repository/wua directory. 6. Run the workflow MS_Patch_Process_Offline_Download_Bundle to import the patch bundle. 7. Set the properties for the Microsoft Updates Discovery configuration, and then run it. This populates the data model with patch metadata. 8. The metadata is used to generate all the download commands. 9. Repeat steps 2 through 7. Once complete, you can scan and deploy patches into the infrastructure.
Results
After you have completed steps 1-9, you can begin scanning targets while repeating the steps 2-7, which populate the actual patch data. Cabextract support on UNIX: When UNIX-based cab-extraction utilities are supported, to enable this functionality: Procedure 1. Create a global variable named cabextractcommand. 2. In this variable, include the full cabextract command with Tivoli Provisioning Manager placeholders. For example: v If the command uses the following syntax:
cabextract <cab_file_Name> -d <extract_directory>
v Substitute with:
3. Enter the cabextract command. It looks similar to this: Note: Do not include paths in the cabextract command. Ensure that the executable is in the user path.
cabextract wsusscn2.cab -d /tmp/update
The command extracts wsusscn2.cab to the /tmp/update directory. Processing the cab file without cabextract: When the Tivoli Provisioning Manager is running on UNIX, but the cabextract utility is not supported, you can process the wsusscn2.cab file on a Windows Internet-facing computer. To enable this functionality, add the option cabextract to the download command. v For example:
ms_patch_download_offline.cmd -cabextract
v If the connection requires proxy information:
894
ms_patch_download_offline.cmd -cabextract proxyUser proxyPassword
Depending on the speed of the Windows Internet-facing computer, it might take about 10 minutes longer to process the downloads. The size of the offline_patches.tar/zip bundle file will also be about 100 MB larger. The rest of the process is automated, and Tivoli Provisioning Manager automatically uses the decompressed data, if present. Note: If the import fails on the UNIX provisioning server, and the offline_patches.tar/zip file has been removed by the provisioning workflow, it might be required that the bundle be copied to the UNIX Tivoli Provisioning Manager server. For more information, see MS_Patch_Offline_For_SDI.
Tutorial: Managing patches in Windows environments using the Scalable Distribution Infrastructure
This tutorial demonstrates patch management using the scalable distribution infrastructure, on target computers that have the Windows operating system installed. The scalable distribution infrastructure allows you to manage a large number of target computers in various topologies. It provides a fast and reliable way to scan, distribute and install patches on target computers that require them.
Learning objectives
In this tutorial, you learn how to: v Discover and group target computers v Set up servers, infrastructure, and target computers v Acquire patches v Approve patches v Set up compliance for the target computers v v v v Scan the target computers for missing patches Distribute patches Install patches Verify compliance results
Allow several hours to discover your target computers, set up the infrastructure, set up the target computers, and install the patches on them. Acquiring the patches from the Microsoft Web site might take four to six hours depending on the number of patches that are available and your connection speed.
Prerequisites
Before you start, verify that your systems meet the requirements listed in Requirements for Windows. Modules in this tutorial v Requirements for Windows v Part 1: Environment setup on page 897 v Part 2: Day-to-day tasks on page 904 Requirements for Windows:
895
Before you start managing patches in Windows environments using the scalable distribution infrastructure, ensure that your systems meet all of the requirements.
You can manage patches for the following Windows operating systems and versions using the scalable distribution infrastructure: v Microsoft Windows Server 2008 Standard Edition (x86 64-bit) any SP v Microsoft Windows Server 2008 Standard Edition (x86 32-bit) any SP v Microsoft Windows Server 2008 Enterprise Edition (x86 64-bit) any SP v Microsoft Windows Server 2008 Enterprise Edition (x86 32-bit) any SP v Microsoft Windows Server 2008 R2 Standard Edition (x86 64-bit) any SP v v v v v v v v v v v v v Microsoft Microsoft Microsoft Windows Windows Windows Windows Microsoft Microsoft Microsoft Microsoft Microsoft Microsoft Windows 7 Professional (x86 32-bit/ 64-bit) any SP Windows 7 Enterprise (x86 32-bit) any SP Windows 7 Enterprise (x86 64-bit) any SP Vista Ultimate Edition (x86 64-bit) any SP Vista Ultimate Edition (x86 32-bit) any SP Vista Enterprise Edition (x86 64-bit) Vista Enterprise Edition (x86 32-bit) Windows Server 2003 Standard Edition (AMD 64-bit) any SP Windows Windows Windows Windows Windows Server 2003 Standard Edition (x86 64-bit) any SP Server 2003 Enterprise Edition (x86 64-bit) any SP Server 2003 Standard Edition (x86 32-bit) any SP Server 2003 Enterprise Edition (x86 32-bit) any SP XP Professional (64-bit) any SP
v Microsoft Windows Server 2003 Enterprise Edition (AMD 64-bit) any SP
v Microsoft Windows XP Professional (32-bit) any SP User roles and requirements: To perform the tasks in patch management, ensure that you have the required knowledge and access permissions to perform your role.
This topic applies to patch management for Windows environments using the Scalable Distribution Infrastructure (SDI). Table 167. Roles and skills for patch management in Windows environments Role Provisioning Administrator Provisioning tasks v Discover and group target computers v Set up servers and infrastructure Skills v Knowledge of the provisioning environment v Knowledge of the Windows operating system v Knowledge of Internet technologies v Knowledge of scalable distribution infrastructure
896
Table 167. Roles and skills for patch management in Windows environments (continued) Role Provisioning Configuration Librarian Provisioning tasks v Acquire patches v Scan the target computers for missing patches v Organize and maintain the patch catalog v Create and maintain patch groups, delete patches from the data model Compliance Analyst v Approve patches in the data model v Knowledge of the Windows operating system v Set up compliance v Perform patch check v Approve compliance recommendations v Verify compliance results Deployment Specialist v Install required software on target computers v Publish patches v Distribute patches v Unpublish patches v Implement compliance recommendations to install missing patches v Monitor patch installation v Uninstall patches v Knowledge of the Windows operating system v Knowledge of the patch management life cycle v Knowledge of the patch management life cycle Skills v Knowledge of the Windows operating system v Knowledge of the patch management life cycle
Server requirements: If your Tivoli Provisioning Manager server is not a Windows system, see the Configuration section. Otherwise, there are no specific requirements.
Target computer requirements: There are no specific requirements for target computers for managing patches in Windows environments using the scalable distribution infrastructure. However, the common agent is required on target computers to complete many Tivoli Provisioning Manager tasks. You might also want to install a specific version of Windows Update Agent.
Part 1: Environment setup: Before starting to manage patches for Windows environments, you must set up the servers depending on the configuration that you are using. Also, you must set up the scalable distribution infrastructure and install required software on your target computers.
897
Discovering and grouping target computers: You need to make your target computers known to the data model. To do this, you can run initial discovery. Initial discovery searches for unknown resources and adds them to the data model. For existing resources, the data model is updated with any new or changed information. After that, you can group your target computers so that you can manage patches for multiple computers at the same time. Make sure that the following requirements are met: v Your user role is Provisioning Administrator, Provisioning Configuration Librarian, or equivalent. v Your target computers meet the requirements listed in the Target computer requirements on page 897 topic.
Tip: You can use the Computer Discovery, Common Agent Installation and Inventory Discovery discovery wizard to run a network discovery of the computers, install the common agent on these computers, and run a hardware and software scan. For more information, see Discovering your environment using the ready-to-use network discoveries on page 231. To discover and group your target computers, complete the following steps: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. Tip: To perform this task from the Start Center, click Discovery Configurations under Provisioning administration applications or Discovery and task applications. 2. Find the discovery configuration called Initial Discovery and click its name on the list. 3. Click the IP Address Ranges tab. 4. Click New Row. 5. In the Start and End fields, type the IP addresses of your target computers. After each set of IP addresses, click New Row. Tip: You can also specify subnetworks that you want to discover. If, for example, all the target computers that you want to discover are in a LAN, click the Subnetworks tab and specify the IP address and mask for the LAN. After specifying each subnetwork, click New Row. 6. Click the Credentials tab. 7. Click New Row. 8. Type the user name and password. After each set of credentials, click New Row. If you specify more than one set of credentials, those credentials are used for each target computer in the order that they are listed. If the logon attempt on a target computer is successful, the computer is added to the data model. Notes: v The system attempts to connect to each IP address using each user name and password provided until it finds a user name and password that it can use to connect successfully. This might cause user accounts to be locked out, depending on the security policy enforced on the target computers. v You might need to increase the default timeout value if you are on a slower network or you are attempting to discover slower computers.
898
9. In the Add Computers to Group field, click Select Value computer to after running initial discovery. Tip: If you want to create a group, see Creating groups. 10. 11. 12. 13.
and select the group to add the target
. Click Save Click Run Discovery. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. Under Notification, specify notification options if you want users to be notified about the task status. 14. Click Submit. 15. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The discovery task is displayed with a status of Success on the Provisioning Task Tracking page and the discovered computers are recorded in the details of the discovery task. Setting up the patch server: When you set up a patch server, you can use it to connect to the Internet, download, and store locally the required patches. You can then make the downloaded patches available in your environment. To set up the patch server, perform the steps in this topic. If you do not set up the patch server, Provisioning Manager downloads the patches directly. To use the provisioning server as patch server, do not set up patch server explicitly. If you are using the provisioning server as the patch server, the provisioning server must have access to the internet. If the provisioning server has a UNIX operating system installed, you can configure a Microsoft patch download server to download and extract the .cab files from the Internet. This computer must have the Windows operating system installed. Note that the patch download server is not a Microsoft Windows Server Update Services server. If you are using a WSUS server, you need to set it up separately. Make sure that the following requirements are met: v Your user role is Provisioning Administrator or equivalent. v The Microsoft patch download server meets the requirements listed in the Server requirements on page 897 topic.
If you are setting up a Microsoft patch download server, perform the task documented in this section. Alternatively if you want to manage patches when the provisioning server has a UNIX operating system installed, but without a Windows computer as the Microsoft patch download server, see the Components for Windows environments using SDI on page 889. To define the patch server in the data model: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. Tip: To perform this task from the Start Center, click Provisioning Global Settings under Provisioning administration applications. 2. Click the Variables tab. 3. Find the wsus-download-server-name variable and set its value to the fully qualified name of the Microsoft patch download server.
899
Note: The wsus-download-server-name variable is unrelated to the WSUS server, if you are using a WSUS server to acquire patches. This is a separate variable and the patch download server you are setting up here is not the WSUS server. 4. Click Save .
Setting up the proxy server: When the provisioning server is installed on a Windows computer that has Internet access using a proxy server, you must set up the proxy server. Make sure that your user role is Provisioning Administrator or equivalent.
You need to perform a number of tasks to set up the proxy server. Defining the proxy server in the data model: To define the proxy server in the data model: 1. Click Go To > Deployment > Provisioning Computers. Tip: To perform this task from the Start Center, click Provisioning Computers under Automation development applications. 2. In the Computer field, type the name of the computer where the Windows patches will be downloaded (Microsoft patch download server or provisioning server). In the list, click the computer name. 3. Click the Credentials tab. 4. Click Add Credentials > New Service Access Point. 5. Type a name for the service access point. 6. 7. 8. 9. In the Protocol Type field, click Network protocol IPv4. In the Application Protocol field, click HTTP Access. In the Context field, type WUA. Type the port number for the proxy server, for example, 8080.
Note: Port 8080 is the default port for most proxy servers. If you are using a different proxy server port in your environment, type the correct proxy server number. 10. In the Domain field, type the fully qualified host name or IP address of the proxy server. 11. Select the Host check box. 12. If the proxy server requires authentication, select the Authentication check box. Otherwise, leave this check box blank. 13. Click New Password Credential. 14. In the Search Key field, type wua-download. 15. Type the user name and the password for the proxy server. 16. Click Save .
Configuring your Internet browser to use a proxy server: To configure your Internet browser to use a proxy server: 1. In the Microsoft Internet Explorer window, click Tools > Internet Options.
900
2. Click the Connections tab, and then click LAN Settings. 3. On the Local Area Network (LAN) Settings window, under Proxy Server, select the Use a proxy server for your LAN check box. 4. In the Address field, type the host name of the proxy server. 5. In the Port field, type the port number for the proxy server, for example, 8080. 6. Clear the Bypass proxy server for local addresses check box and click OK. Related information Setting up the patch server on page 899 Setting up the infrastructure Installing required software on target computers on page 902 Setting up the infrastructure: You can set up a region, a zone, and a depot server, which will be used to distribute and install the patches on the target computers. Make sure that your user role is Provisioning Administrator or equivalent.
You need to perform a number of tasks to set up the infrastructure. Setting up a region: Regions are used to group depot servers that are located near one another to optimize upload, replication, and download times. When you create a depot server, associate it with a region. You can assign a depot server to only one region. To set up a region: 1. Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. Tip: To perform this task from the Start Center, click Dynamic Content Delivery Configuration under Provisioning administration applications. 2. Click the Regions tab. 3. Click New Row. 4. Type a name and a description for the new region. 5. Click Save Setting up a zone: Optionally, you can set up a zone to define an IP address range or a domain name within a region. Regions can be generic, without a real network definition, or they can be specific, when zones are used to define domain names within a region. Zones are used to logically group computers within regions. To set up a zone: 1. Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. Tip: To perform this task from the Start Center, click Dynamic Content Delivery Configuration under Provisioning administration applications. 2. On the Dynamic Content Delivery Configuration page, click the Zones tab.
901
3. Click New Row. 4. Type a name and a description for the new zone. and click the region that you created in the previous task. 5. In the Regions field, click Select Value 6. Select Domain Name, and then specify the domain that your depot server and target computers are in. 7. Click Save .
Setting up a depot server: A depot server is a system that stores files for distribution. Distribution files are uploaded to a depot server using a client. Uploaded files are stored in a directory that is specified when the depot server is installed. Depot servers can replicate uploaded files to other depot servers to optimize the network traffic. The target computers download the files from the depot servers. To set up a depot server: 1. Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. Tip: To perform this task from the Start Center, click Dynamic Content Delivery Configuration under Provisioning administration applications. 2. On the Dynamic Content Delivery Configuration page, click the Depots tab. 3. Click New Row. 4. Type a name and description for the depot server. and click the region that you have created in the previous 5. In the Region field, click Select Value task. This is the region that the depot server is assigned to. 6. In the Computer field, click Select Value set up as a depot server. and click the name of the computer that you want to
Attention: The depot server must not be included in your group of target computers. 7. In the Fully qualified host name field, type the fully qualified host name of the depot server that has already been discovered. 8. Select the Install the depot agent services? check box to install the depot agent services on the depot server. 9. In the Domain Zone Served field, click Select Value previous task. 10. Type the user name and password for the depot server. and select the zone that you set up in the
11. If using only one depot server, select the Preferred upload server check box. At least one preferred depot server is required. . 12. Click Save Related information Setting up the patch server on page 899 Setting up the proxy server on page 900 Installing required software on target computers Installing required software on target computers:
902
You can install the common agent and Windows Update Agent (WUA) on the target computers. The common agent is a software product that is required for software distribution and software compliance management. WUA is a Windows software product that is required so that you can determine which target computers require patches. Make sure that the following requirements are met: v Your user role is Deployment Specialist or equivalent. v The target computers meet the requirements listed in the Target computer requirements on page 897 topic.
Installing Windows Update Agent: Windows Update Agent (WUA) is required to determine which target computers require patches and to install these patches on the computers. In this task, you download and install WUA on the target computers. If you include a specific version of the Windows Update Agent in the repository, that version is installed on target computers. If you do not include a version of Windows Update Agent in the repository, Tivoli Provisioning Manager downloads the latest version of Windows Update Agent and installs that version on target computers. To install Windows Update Agent (WUA): 1. Click Go To > Deployment > Patch Management > Windows Update Agent Installation. Tip: To perform this task from the Start Center, click Windows Update Agent Installation under Patch management applications. 2. Click Select > Groups and select your group of target computers, then click OK. 3. 4. 5. 6. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. Under Notification, specify notification options if you want users to be notified about the task status. Click Submit. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed.
The WUA installation task is displayed with a status of Success on the Provisioning Task Tracking page. In addition, the Windows Update Agent (WUA) software definition is displayed on the Software tab, in the Provisioning Groups page for your group of computers. Installing the common agent: The common agent is a software product that provides infrastructure for management applications. The common agent installed on the target computers provides remote deployment capability, shared computer resources, secure connectivity, and a single entry point. The common agent can be installed once on each target computer. After the common agent is installed on a target computer, subsequent subagents can be installed on the top of an existing common agent. To install the common agent, perform the steps listed later in this section. If you used the Computer Discovery, Common Agent Installation and Inventory Discovery discovery wizard to discover your computers, then the common agent is already installed. Proceed to Acquiring patches on page 904. 1. Click Go To > Deployment > Software Management > Common Agent Installation. 2. Click Select > Groups and select your group of target computers, then click OK. 3. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 4. Under Notification, specify notification options if you want users to be notified about the task status.
903
5. Click Submit. 6. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The common agent installation task is displayed with a status of Success on the Provisioning Task Tracking page. Related reference Target computer requirements on page 897 Related information Setting up the patch server on page 899 Setting up the proxy server on page 900 Setting up the infrastructure on page 901 Part 2: Day-to-day tasks: After setting up the environment, there are a number of tasks that you must perform as day-to-day patch management activities to ensure that your target computers are always up-to-date with the required patches.
Acquiring patches: You must set up your model so that you specify which patches you want to check for from the ones that are made available by the vendor. These options that you set include the product family, locale, and severity of the patches. After setting up your options, run a task to bring these patches into the data model. Make sure that the following requirements are met: v Your user role is Provisioning Configuration Librarian or equivalent. Note: Though not a requirement, your patch acquisition might run more smoothly if you turn off Windows Automatic Updates on the target computers. For more information, see the Turning off automatic updates on page 905 topic.
By default, the ms.sdi.patch.create.bulletin.groups global variable is set to true. When this variable is set to true, Microsoft bulletin groups are imported into the data model when you complete the patch acquisition process. If you do not want to import Microsoft bulletin groups into the data model and want to import individual patches, unset the ms.sdi.patch.create.bulletin.groups global variable. To unset the variable: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Variables tab and search for the ms.sdi.patch.create.bulletin.groups variable. 3. Change the ms.sdi.patch.create.bulletin.groups variable setting to false.
To acquire patches: 1. Click Go To > IT Infrastructure > Software Catalog > Patch Acquisition. Tip: To perform this task from the Start Center, click Patch Acquisition under Discovery and task applications.
904
2. From the Operating System list, click Select Value systems.
and click Windows from the list of operating
and click Scalable Distribution Infrastructure. 3. From the Infrastructure list, click Select Value 4. Click Select Product Family and select the product family for which you want to acquire patches, then click OK. 5. Optional: To approve the acquired patches automatically, in the Initial Patch Status list, click Select and click APPROVED. This option is useful if you want to mark as approved all the Value patches that have been made available by the vendor, without having to approve them in a later step. 6. Click Select Severity and select the check boxes corresponding to the severity values for the patches that you want to acquire, then click OK. 7. Click Select Products and select the check boxes corresponding to the software products for the patches that you want to acquire, then click OK. 8. Click Select Locale and select the check boxes corresponding to the locales for the patches that you want to acquire, then click OK. 9. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 10. Under Notification, specify notification options if you want users to be notified about the task status. 11. Click Submit. 12. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The patch acquisition task is displayed with a status of Success on the Provisioning Task Tracking page. The patches are added into the data model. To view the patches catalog, in the Start Center, click Patches under Favorite applications. Turning off automatic updates: Before acquiring patches for Windows 2003 target computers, you might want to disable the Windows automatic updates. By default, the Windows automatic updates are enabled. If you do not disable them, the operating system and the Patch Acquisition application might attempt to run the same updates, which could block the update process.
To 1. 2. 3.
disable the automatic updates: On the Windows 2003 desktop, right-click the Computer icon and click Properties. Click the Automatic Updates tab. Select Turn off automatic updates and click OK.
The automatic updates are now disabled. Next you will be acquiring the patches into the data model. Testing patches: It is recommended to test the released patches before installing them, to ensure that all possible conflicts have been identified in a test environment before installing them in the production environment. You can install the patches to a test computer using the Patch Installation application. However, the actual testing of patches must be performed outside of the provisioning applications.
905
Approving patches in the data model: After patches are acquired, the first step in the approval process is to approve the patches for the entire organization (at the data model level). Only the approved patches are included when scanning the target computers for missing patches. For example, in some organizations all patches are approved at the data model level and then the compliance analyst decides which patches to approve per provisioning group. This second step in the approval process is done when scanning for missing patches. In other organizations, there might be particular patches that the compliance analyst does not want to approve immediately after acquisition, because further testing is required before approving. Make sure that your user role is Compliance Analyst or equivalent.
To approve the acquired patches in the data model: 1. Click Go To > IT Infrastructure > Software Catalog > Patches. Tip: To perform this task from the Start Center, click Patches under Favorite applications. 2. Press Enter to display all patches from the catalog. Tip: You can filter down the list of displayed patches by patch name, version, severity, vendor, release date, and so on. To search for a particular patch, type the patch name in the Patch field, for example, KB921823. To use more search fields, click Advanced Search and customize the options in the window, then click Find. 3. Click Select Records and select the patches that you want to approve, then click Approve. Note: To be able to select records, filter down your list of patches to a maximum of 200. If you want to approve more than 200 patches at the same time, filter down your patches, then click Approve and click OK on the confirmation message. Patches that you have approved are displayed with a status of Approved on the Patches page. Setting up compliance: You can set up a compliance check to verify if patches are required on the target computers. Compliance checks define the compliance state of your target computers and are used to detect, report, and recommend how to fix noncompliance. Make sure that your user role is Compliance Analyst or equivalent.
To set up compliance: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Find your group of target computers and click its name on the list.
906
3. Click the Compliance tab. 4. Click New Compliance Check > Patch Check. 5. In the Patch Approval Group field, click Select Value scanned, then click Save. and select a group of patches to be
Tip: By default, all patches that have been approved in the data model are scanned, and target computers are verified against all approved patches to see if computers are compliant. You can also select a patch approval group, which is used to specify a set of allowed patches, or approval lists. The patch approval group limits the patches for which recommendations are generated to the specified set of patches only. You might want to use this option to tightly control patches for critical computers where more exhaustive testing of patches is needed before they are required to be installed. Do not perform the patch check using a software compliance check of type Software Group associated to the Patch Approval Group. Doing this can cause the following problems: v If a software patch contained in the Patch Approval Group is installed, target computers result as compliant. v The check is performed for the specific software patch installation and disregards any relation between the software patches, for example, superseding patches. v The check is performed on all computers belonging to the group and disregards if the software patch is applicable to only certain platforms. 6. Optional: To automatically approve recommendations when they are generated, click Enable Automatic Approval and click OK in the message box. All recommendations that are generated by this compliance check will be created in the Approved state. 7. Click Save .
The Operating System Patches and Updates compliance check is displayed in the list of compliance checks defined for the group of target computers. Scanning for missing patches: You can compare the software installed on your target computers with a list of the patches that have been approved for the entire organization to see which patches are missing on which computers. By default, all patches that have been approved in the data model are scanned, and target computers are verified against all approved patches to see if computers are compliant. You can also select a patch approval group, which is used to specify a set of allowed patches, or approval lists. The patch approval group limits the patches for which recommendations are generated to the specified set of patches only. You might want to use this option to tightly control patches for critical computers where more exhaustive testing of patches is needed before they are required to be installed. To scan for missing patches, some of the patches must in the Approved state, otherwise the scan and check fails. Make sure that at least some of the patches are in the Approved state before you begin this procedure. Make sure that your user role is Provisioning Configuration Librarian or equivalent.
To scan for missing patches: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Compliance tab.
907
4. Click Run Scan and Check. Tip: If you want to schedule the provisioning task for a later time, click Schedule Scan and Check to specify scheduling options. 5. Click the Notification tab to specify notification options if you want users to be notified about the task status. 6. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. Attention: Wait until the task completes before starting another compliance scan task on the target computers. If you run concurrent compliance scan tasks on a target computer, the tasks might fail. The scanning and checking task is displayed with a status of Success on the Provisioning Task Tracking page. The recommendations to install missing patches are generated. On the Compliance tab for the group, the patch check displays either Yes or No in the Compliant column, depending on whether all required patches are installed on the target computers. If notification was set up, recipients will be notified that recommendations need be approved. Approving compliance recommendations: After scanning your target computers to see which patches are missing on them, compliance recommendations are generated. Based on these recommendations, you can decide which patches you want to install on your target computers. Make sure that your user role is Compliance Analyst or equivalent.
To approve compliance recommendations: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Recommendations tab. 4. In the recommendations list, select the check boxes corresponding to the missing patches that you want to approve and click Approve. The selected patches are displayed with a status of Approved on the Recommendations tab. Distributing patches: After patches are approved, you can distribute them first and then install them on the target computers. During distribution, the patch binaries are downloaded into the data model, and then the patch binaries and other files (for example cab file, vbscript) are published to a depot server. From the depot server, patches are distributed for installation on target computers. You can distribute patches immediately or schedule this task for a specified date and time. Make sure that your user role is Deployment Specialist or equivalent.
908
To distribute patches: 1. Click Go To > Deployment > Patch Management > Patch Distribution. Tip: To perform this task from the Start Center, click Patch Distribution under Patch management applications. 2. Click Select Patches and select the patches that you want to distribute, then click OK. Tip: You can filter down the list of displayed patches by patch name, vendor, and version. To search for a particular patch, type the patch name in the Patch field, for example, KB921823. If multiple software definitions are available for that patch number, for example, Security Update for Windows Server 2003 and Security Update for Windows XP, select the check boxes for all the software definitions that match the patch number. The correct patch, based on the operating system on the target computer, will be distributed to the appropriate target computer. To use more search fields, expand Advanced Search Options and customize the options in the window, then click Refine. Click Select > Groups and select your group of target computers, then click OK. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. Under Notification, specify notification options if you want users to be notified about the task status. Click Submit. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed.
3. 4. 5. 6. 7.
The patch distribution task is displayed with a status of Success on the Provisioning Task Tracking page. Installing patches: After patches are approved, you can install them on the target computers where they are missing. Make sure that your user role is Deployment Specialist or equivalent.
To install patches: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. Click your group of target computers. Click the Recommendations tab. Select all the patches that are approved from the recommendations list and click Implement. Specify the options you want for installing and click Submit. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed.
2. 3. 4. 5. 6.
The patch installation task is displayed with a status of Success on the Provisioning Task Tracking page. Verifying compliance results: After installing patches on the target computers, you can verify that patches installed successfully. Make sure that your user role is Compliance Analyst or equivalent.
909
You can verify compliance results either by running the compliance scan again and verifying the list of recommendations or by running patch reports that provide information about missing patches. Running the compliance scan again: To run the compliance scan: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. Click your group of target computers. Click the Compliance tab. Click Run > Check to run a compliance check before displaying the recommendations so that the results are accurate. Click the Recommendations tab. In the list of recommendations, verify that the installed patches are no longer displayed as missing. Click OK.
2. 3. 4. 5. 6. 7.
Installed patches are no longer listed on the list of recommendations because they are not missing from the target computers. Generating patch compliance reports: To generate patch compliance reports: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. Click the group of target computers to generate the report for. Click the Compliance tab. Click Run > Check to run a compliance check before running the report so that the results are accurate. Click Go To > Administration > Reporting > Report Administration. Search for the report with the description Do Windows servers comply with the patch policy? and click the report name. Click Generate Request Page. After the report is generated, click Close. The report lists all the target computers that have a patch compliance check defined. The Is Compliant column lists the compliance status of the target computers. Click Preview and in the window that is opened click Submit. Tip: You can also generate the report with the description What patches are missing on what Windows servers? to list all the missing patches and their corresponding target computers. Installed patches are not listed because they are not missing from the target computers.
2. 3. 4. 5. 6. 7. 8.
9.
910
Related information Testing patches on page 905 Approving patches in the data model on page 906 Setting up compliance on page 906 Scanning for missing patches on page 907 Approving compliance recommendations on page 908
Managing patches in Windows environments using the deployment engine

This patch management solution for Windows environments uses the deployment engine rather than the scalable distribution infrastructure to manage patches. If you are using the deployment engine to manage patches in a Windows environment, you can use a MicrosoftWindows Server Update Services (WSUS) to manage patches or your target computers can acquire patches directly from the Microsoft Update Web site.
Deployment engine: This topic applies to Windows environments in which Tivoli Provisioning Manager uses the deployment engine to manage patches.

You can manage patches for the following Windows operating systems and versions: v Microsoft Windows Server 2008 Standard Edition (x86 64-bit) any SP v v v v v Microsoft Microsoft Microsoft Microsoft Microsoft Windows Windows Windows Windows Windows Server 2008 Standard Edition (x86 32-bit) any SP Server 2008 Enterprise Edition (x86 64-bit) any SP Server 2008 Enterprise Edition (x86 32-bit) any SP Server 2008 R2 Standard Edition (x86 64-bit) any SP 7 Professional (x86 32-bit/ 64-bit) any SP
v Microsoft Windows 7 Enterprise (x86 32-bit) any SP v Microsoft Windows 7 Enterprise (x86 64-bit) any SP v v v v v v v v v v v v Windows Windows Windows Windows Microsoft Microsoft Microsoft Microsoft Microsoft Microsoft Microsoft Microsoft Vista Ultimate Edition (x86 64-bit) any SP Vista Ultimate Edition (x86 32-bit) any SP Vista Enterprise Edition (x86 64-bit) Vista Enterprise Edition (x86 32-bit) Windows Server 2003 Standard Edition (AMD 64-bit) any SP Windows Server 2003 Enterprise Edition (AMD 64-bit) any SP Windows Server 2003 Standard Edition (x86 64-bit) any SP Windows Windows Windows Windows Windows Server 2003 Enterprise Edition (x86 64-bit) any SP Server 2003 Standard Edition (x86 32-bit) any SP Server 2003 Enterprise Edition (x86 32-bit) any SP XP Professional (64-bit) any SP XP Professional (32-bit) any SP
Use one of the following sections for information about managing patches using the deployment engine, depending on whether or not you are using a WSUS server for patch acquisition: v Acquiring patches without using a WSUS server on page 912 v Acquiring patches with a WSUS server on page 912
911
Acquiring patches without using a WSUS server

You can use the deployment engine to manage patches in a configuration in which you do not use a WSUS server. All of the target computers require access to the internet and you must have Windows Update Agent installed on each target computer. To use the deployment engine to manage patches in an environment in which you do not use a WSUS server, you must set up the configuration as follows: v You do not create the WSUS variable v All of the target computers must be connected to the internet to access the Microsoft Update website to search for and download patches v All of the target computers must have Windows Update Agent installed
Day-to-day patch management tasks

You can use the information described in Part 2: Day-to-day tasks on page 904 to manage patches using the deployment engine. However, when you are specifying the mode using the Patch Acquisition application as described in Acquiring patches on page 904, specify the deployment engine rather than the scalable distribution infrastructure.
Automation packages
The following automation packages are used for Windows patch management: v MS_WSUS For information about the automation packages, search for automation package descriptions in the information center.
Acquiring patches with a WSUS server

If you are using the deployment engine to manage patches in a Windows environment, you can use a WSUS server for patch acquisition. If you are using a WSUS server, the WSUS server connects to the Microsoft Update website and acquires the patches. To use a WSUS server, you must set up the WSUS server and set a WSUS-specific variable in Tivoli Provisioning Manager.
Components
This patch management solution requires the following Microsoft components: Microsoft Windows Server Update Services (WSUS) server The WSUS server is a computer that is connected to the Microsoft Update website to get the latest patches. The system administrator must ensure that this computer is maintained. This is a manual process performed outside of the provisioning server. To be able to install patches on target computers that belong to a provisioning group, you create an association between the WSUS server and that group. After this association is established, all the approved patches can be installed on the target computers. Multiple provisioning groups can use the same WSUS server. If more than one WSUS server is used in your organization, at least one of them must connect to the Microsoft Update website to get the available updates. This WSUS server can then be used as an update source for all of the other WSUS servers.
912
After installing the WSUS server, synchronize it with the Microsoft Update website to get the latest software updates. By default, the WSUS server is configured to use the Microsoft Update website as the location to obtain updates. To automatically update your WSUS server with the latest Windows patches, ensure that synchronization with the Microsoft Update website is enabled. Based on the software security policy in your organization, schedule synchronization to update the WSUS server. For more information about the synchronization feature, see your WSUS documentation. Windows Update Agent (WUA) The client component installed on the target computers is required to receive updates either from a WSUS server or directly from the Microsoft Update site. If the target computers belong to a provisioning group that is not associated with a WSUS server, the WUA clients installed on the target computers are set up to connect to the Microsoft Update site to search for the latest patches, download them, and then install them on the target computers. If a proxy server is present, the WUA client uses the Internet Explorer settings for authentication. The proxy server must be configured outside the provisioning applications.
Requirements
Verify that the following requirements are met: v The WSUS server must have WSUS 3.0 and Microsoft .NET Framework 3.5 installed on it. Review the software and hardware requirements, and then download and install Microsoft Windows Server Update Services and its prerequisites using the documentation from the Microsoft Web site. Run initial discovery to add the WSUS server to the data model. v User roles for patch management are listed in the User roles and requirements on page 896 topic. v Requirements for the target computers are listed in the Requirements for Windows target computers on page 556 topic.
Variables and settings

To associate the WSUS server with the target computers, create a variable named WSUServer with the value http://<WSUS_server_name>:<port_number> or https://<WSUS_server_name>:<port_number>, where WSUS_server_name is the name of the WSUS server. This computer must exist in the data model. If using the https:// notation, make sure that the target computers trust the certificate from the WSUS server.
Day-to-day patch management tasks

You can use the information described in Part 2: Day-to-day tasks on page 904 to manage patches using the deployment engine. However, when you are specifying the mode using the Patch Acquisition application as described in Acquiring patches on page 904, specify the deployment engine rather than the scalable distribution infrastructure.
Automation packages
The MS_WSUS automation package is used for Windows patch management: For information about automation packages, search for automation package descriptions in the information center.
Managing patches in AIX environments

You can use IBM Tivoli Provisioning Manager to manage patches in AIX environments.
913
Supported platforms for AIX computers

The following AIX platforms are supported: v AIX 7.1 any TL (IBM System p 64-bit) v AIX 6.1 any TL (IBM System p 64-bit) v AIX 5.3 any TL (IBM System p 32bit/64bit) v AIX 5.2 ML 7 or above (IBM System p 64-bit) 32-bit emulation

It is important to understand the overall patch management process before you start to manage patches using the provisioning applications. Patch management includes the processes that are illustrated and detailed later in this section. Roles for each step in the process are noted in parentheses.
Discover computers
Set up environment
Acquire patches
Test patches
Set up compliance
Scan for missing patches Approve compliance recommendations Install patches
Legend
Provisioning Administrator Provisioning Configuration Librarian Compliance Analyst Deployment Specialist Verify compliance results
1. Discover computers and set up the environment (Provisioning Administrator) This process consists of the following tasks: v Run initial discovery to discover all computers and to add them to the data model. Initial discovery finds out what operating system is installed on your target computers, which is required to make sure that patches for that operating system will be acquired in a next step in the process. Also, the AIX satellite server that is part of your configuration is added to the data model. Tip: The task of discovering computers can also be performed by the provisioning configuration librarian. v Group the discovered target computers to manage patches for multiple computers at the same time.
914
2. Acquire patches (Provisioning Configuration Librarian) This process consists of specifying your patches of interest from those released by the vendor, and bringing those patches into the data model. 3. Test patches Testing patches is recommended as part of the patch management life cycle process. Testing patches ensures that all possible conflicts have been identified in a test environments before installing the patches in the production environment. You can install the patches to defined test environments using the patch installation application, but the actual testing of patches must be performed outside of the provisioning applications. Therefore, this task does not have a role associated with it. Normally, the test engineer in your organization performs this task. 4. Set up compliance (Compliance Analyst) This process consists of creating compliance checks to determine if the software installed on the target computers matches your requirements. Compliance checks define the state of compliance of your target computers and are used to detect, report, and recommend how to fix noncompliance. You add a patch check to a group of target computers. When doing so, you can identify specific patch approval groups to scan. 5. Scan for missing patches (Provisioning Configuration Librarian) This process consists of scanning the target computers and checking to identify which patches are missing from the target computers. After the scan, a list of missing patches is generated and then the check creates compliance recommendations for each computer or group. 6. Approve compliance recommendations (Compliance Analyst) This process consists of approving the patches that you want to install. You approve patches per target computer or group of computers, if a patch is missing on the target computers. 7. Install patches and monitor patch installation (Deployment Specialist) This process consists of installing the patches on target computers. You can install patches on a specific target computers or multiple target computer into one task. 8. Verify compliance results (Compliance Analyst) This process consists of validating that the patches were successfully applied to all the target computers. You run the compliance check again to verify that the installed patches are no longer displayed on the list of recommendations.
Components for AIX environments

To manage patches in AIX environments, set up your configuration so that all components can work together. The following diagram illustrates the supported configuration.
915
AIX target computers
Provisioning server
AIX Fix Center
AIX satellite server
Internet
FTP or HTTP proxy (optional)
The required components are the target computers and the AIX satellite server. The AIX satellite server connects to the AIX Fix Center over the Internet to download the AIX patches. The AIX satellite server is defined as a target computer in your configuration. Downloaded patches are moved to the provisioning server. The patches are distributed to the target computers from the provisioning server. Optionally, you can use a proxy server to provide Internet access to the AIX satellite server. In this configuration, you must set up SUMA to work with a proxy server. For information about how to configure SUMA, see the System p and AIX information center.
916
Note: Downloaded patches are saved in .zip format. If you download a large number of patches, ensure that the native extract utility installed on the AIX provisioning server has large file support.
Fix types
You can download the following fix types, which are available from the IBM Support Web site. Technology Level (TL), previously known as Maintenance Level (ML) Technology level fixes contain new hardware and software features and updates. They are intended to be installed as a whole, to avoid working with individual updates and installing configurations that are not supported. After you apply a Technology level fix, you cannot reject it. Technology level fixes are supported for two years. Service Pack Service packs, which are released between Technology Levels, contain fixes for customer reported problems (APARs) that cannot wait until the next Technology Level. These fixes address critical problems. Service packs are released approximately every 8-12 weeks. Related concepts Patch management process on page 914 Managing patches in AIX environments on page 913 Related reference Requirements for AIX on page 918
Tutorial: Managing patches in AIX environments

This tutorial demonstrates patch management for target computers that have the AIX operating system installed.
Learning objectives
In this tutorial you will learn how to: v Discover and group target computers. v Acquire patches. v Set up compliance for the target computers. v Scan the target computers for missing patches. v Distribute patches. v Install patches. v Verify compliance results. Allow several hours to discover and group your target computers, and to install the patches on them. Getting the list of missing patches from the AIX FIX Center might take two hours depending on the number of patches that are available and your connection speed.
Prerequisites
Before you start, verify that you meet the requirements listed in Requirements for AIX on page 918. Modules in this tutorial v Requirements for AIX on page 918 v Part 1: Environment setup on page 920 v Part 2: Day-to-day tasks on page 921
917
Requirements for AIX

Before you start managing patches in AIX environments, ensure that you meet all requirements. You can manage patches for the following AIX operating systems and versions: v v v v AIX AIX AIX AIX 7.1 6.1 5.3 5.2 any TL (IBM System p 64-bit) any TL (IBM System p 64-bit) any TL (IBM System p 32bit/64bit) ML 7 or above (IBM System p 64-bit) 32-bit emulation
User roles and requirements: To perform the tasks in patch management, ensure that you have the required knowledge and access permissions to perform your role.
Table 168. Roles and skills for patch management on AIX Role Provisioning Administrator Provisioning tasks v Discover target computers v Group target computers Skills v Knowledge of the of the provisioning environment v Knowledge of the AIX operating system v Knowledge of Internet technologies Provisioning Configuration Librarian v Acquire patches v Scan the target computers for missing patches Compliance Analyst v Set up compliance v Approve compliance recommendations v Verify compliance results Deployment Specialist v Install patches v Monitor patch installation v Uninstall patches v Knowledge of the AIX operating system v Knowledge of the patch management life cycle v Knowledge of the AIX operating system v Knowledge of the patch management life cycle v Knowledge of the AIX operating system v Knowledge of the patch management life cycle
Server requirements: There are a number of requirements that must be met by the AIX satellite server so that you can manage patches in AIX environments. Satellite server requirements The AIX satellite server must meet the following requirements: v Operating system: AIX 5L Version 5.3 TL5 (5300-05) or later v Service Update Management Assistant (SUMA) must be installed. SUMA is included with the following AIX versions: AIX 5L Version 5.3. AIX 7.1 TLO SP3 (7100-00-03).
918
Note: The suma command is used to download updates for the satellite server from the AIX Fix Center. The suma command requires root permissions or equivalent. Ensure that the credentials used by the provisioning server to access the satellite server has root permissions or equivalent. v Internet access, either directly, or using a proxy server. v Recommended: Has a file system mounted on the directory where you plan to download your patches. This directory must have a minimum of 20 GB of space and the possibility to extend it. To find out the directory that is used by your system, run the command:
suma -D
The output of the command displays the patch download directory in the DLTarget field. The default directory is /usr/sys/inst.images. Target computer requirements: There are a number of requirements that must be met by the target computers so that you can manage patches in AIX environments. Note: All prerequisites of the target should also be met by the satellite server. Ensure that the following prerequisites are met on all the target computers running AIX.
Table 169. Requirements for AIX Requirement Command prompt Details When running scriptlets, the provisioning server expects that the command prompt ends in $, # or >. The PS1 environment variable governs the appearance of the prompt. If you change this variable on your target computer (managed-to) or provisioning server (managed-from), you might run into problems running provisioning workflows. The following examples show command prompts you can use: command$ $ command# # command> > There has to be a blank character at the end of the prompt on AIX target computer in order to run on it a workflow containing a scriptlet (bash / perl). If a blank character is not present at the end of the prompt then the scriplets (both perl and bash) called inside a workflow stop and do not return to executing workflow. Required packages v openSSH 4.4 or later v bash v Expect 5.4 or later (required for compliance patch management) Tip: OpenSSH for AIX 5 can be obtained from https://sourceforge.net/projects/ openssh-aix.
919
Table 169. Requirements for AIX (continued) Requirement Package locations Details The location of the shells or script interpreters is important because scripts that are run must include this information about the first line of the script. Ensure that the packages are installed in the following locations. v Bash location: /usr/bin/bash v Expect location: /usr/bin/expect v Perl location: /usr/bin/perl Note: Expect is only required to be installed on a target computer if a certain automation package runs expect code on the target computer itself. This installation is optional depending on the requirements. The runtime code, which is a The xlC.rte 6.0 runtime code can be downloaded as a fix from the AIX Support site prerequisite of GSKit7 on at: https://techsupport.services.ibm.com/server/aix.fdc. AIX 5.2.
Part 1: Environment setup

Before starting to manage patches for AIX environments, you must set up the computers depending on the configuration that you are using. Discovering the AIX satellite server and the target computers: Make the AIX satellite server and the target computers known to the data model. To do this, run initial discovery. This operation searches for resources that are unknown to the data model and adds them to it. For existing resources, the data model is updated with any new or changed information. Make sure that the following requirements are met: v Your user role is Provisioning Administrator or equivalent. v Your target computers meet the requirements listed in the Target computer requirements on page 919 topic. To discover your target computers: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. Tip: To perform this task from the Start Center, click Discovery Configurations under Provisioning administration applications. 2. Find the discovery configuration called Initial Discovery and click its name on the list. 3. Click the IP Address Ranges tab. 4. Click New Row. 5. In the Start and End fields, type the IP addresses of your target computers. After each set of IP addresses, click New Row. Tip: You can also specify subnetworks that you want to discover. If, for example, all the target computers that you want to discover are in a LAN, click the Subnetworks tab and specify the IP address and mask for the LAN. After specifying each subnetwork, click New Row. 6. Click the Credentials tab. 7. Click New Row. 8. Type the user name and password. After each set of credentials, click New Row. If you specify more than one set of credentials, those credentials are used on each target computer in the order that they are listed. If the logon attempt on a target computer is successful, the computer is added to the data model.
920
Notes: v The system attempts to connect to each IP address using each user name and password provided until it finds a user name and password that can be used to connect successfully. This might cause user accounts to be locked out, depending on the security policy enforced on the target computers. v You might need to increase the default timeout value if you are on a slower network or you are attempting to discover slower computers. 9. 10. 11. 12. . Click Save Click Run Discovery. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. Under Notification, specify notification options if you want users to be notified about the task status. 13. Click Submit. 14. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The discovery task is displayed with a status of Success on the Provisioning Task Tracking page. Note: If you want to use the provisioning server as your satellite server, make sure that your provisioning server meets the requirements listed in the Server requirements on page 918 topic, then follow the steps to set up your provisioning server as documented in the Setting up the provisioning server as a satellite server topic. Grouping target computers: Defining groups is a way of organizing managed computers for patch management and other tasks. You can group your target computers so that you manage patches for multiple computers at the same time. Make sure that the following requirements are met: v Your user role is Provisioning Administrator, Provisioning Configuration Librarian, or equivalent. v Your target computers meet the requirements listed in the Target computer requirements on page 919 topic. To group the target computers: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Discovery Configurations under Provisioning administration applications or Discovery and task applications. . 2. Click New 3. Type a name and description for the new group. and click Computer. 4. In the Member Type field, click Select Value 5. Click Add Members and select your target computers, then click OK. Attention: Do not select the AIX satellite server as part of the group, because you will not manage patches for the satellite server together with the target computers. 6. Click Save .
Part 2: Day-to-day tasks

After setting up the environment, there are a number of tasks that you must perform as day-to-day patch management activities to ensure that your target computers are always up-to-date with the required patches.
921
Acquiring patches: You must set up your model so that you specify which patches you want to check for from the ones that are made available by the vendor. You might want to check for all AIX patches that are made available regardless of the version, or you might want to check for a specific version only, for example, patches that apply to AIX version 6.1. After setting up your options, you can download these patches into the data model. Make sure that your user role is Provisioning Configuration Librarian or equivalent. Note: Starting with AIX 7.1, SUMA uses eCC (Electronic Customer Care) to retrieve AIX updates. It will download AIX 5.3 TL6 and later updates, as 5.3 TL6 is the starting level of updates that are loaded into eCC. To acquire patches: 1. Click Go To > IT Infrastructure > Software Catalog > Patch Acquisition. Tip: To perform this task from the Start Center, click Patch Acquisition under Discovery and task applications. 2. In the Operating System list, click Select Value systems. 3. In the Satellite Server list, click Select Value list of computers. and click AIX from the list of operating and click the name of the satellite server from the
4. Click Refresh TL/SP Definitions to bring all available AIX patches, whether for version 7.1, 6.1, 5.3, or 5.2 into the data model. 5. Click Submit. 6. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. 7. Click Go To > IT Infrastructure > Software Catalog > Patch Acquisition. 8. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 9. Under Notification, specify notification options if you want users to be notified about the task status. 10. Under Technology Levels and Service Packs, select the check boxes corresponding to the patches that you want to acquire and click Download Patches. This step is mandatory for the selected patches to be considered for installation. 11. Click Submit. 12. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The patch acquisition task is displayed with a status of Success on the Provisioning Task Tracking page. The patches are added into the data model. To view the patches catalog, in the Start Center, click Patches under Favorite applications. Testing patches: It is recommended to test the released patches before installing them, to ensure that all possible conflicts have been identified in a test environment before installing them in the production environment. You can install the patches to defined test environments using the Patch Installation application, but the actual testing of patches is to be performed outside of the provisioning applications. Setting up compliance:
922
You can set up a compliance check to verify if patches are required on the target computers. Compliance checks define the compliance state of your target computers and are used to detect, report, and recommend how to fix noncompliance. Make sure that your user role is Compliance Analyst or equivalent. This topic shows you how to set up compliance using the Latest Level scan model. To customize your scan model, see the Customizing the patch scanning model topic. To set up compliance: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Find your group of target computers and click its name on the list. 3. Click the Compliance tab. 4. Click New Compliance Check > Patch Check. 5. In the Select Patch Group dialog, click Save. Tip: By default, all patches that have been approved in the data model are scanned, and target computers are verified against all approved patches to see if computers are compliant. You can also select a patch approval group, which is used to specify a set of allowed patches, or approval lists. The patch approval group limits the patches for which recommendations are generated to the specified set of patches only. You might want to use this option to tightly control patches for critical computers where more exhaustive testing of patches is needed before they are required to be installed. Do not perform the patch check using a software compliance check of type Software Group associated to the Patch Approval Group. Doing this can cause the following problems: v If a software patch contained in the Patch Approval Group is installed, target computers result as compliant. v The check is performed for the specific software patch installation and disregards any relation between the software patches, for example, superseding patches. v The check is performed on all computers belonging to the group and disregards if the software patch is applicable to only certain platforms. 6. Optional: To automatically approve recommendations when they are generated, click Enable Automatic Approval and click OK in the message box. All recommendations that are generated by this compliance check will be created in the Approved state. 7. Click Save .
The Operating System Patches and Updates compliance check is displayed in the list of compliance checks defined for the group of target computers. Customizing the patch scanning model: If you want to change the default patch scanning model, which scans only the latest level for available AIX patches, specify options in a discovery configuration. Make sure that your user role is Compliance Analyst or equivalent. To customize the scanning model: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations.
923
Tip: To perform this task from the Start Center, click Discovery Configurations under Automation development applications . 2. Find the AIX Discover Patches discovery configuration and click it. for the Maintenance Strategy Model field, and click the option that you 3. Click Select Value want for the scanning model: v Latest Level: Scans for the latest available technology level and service pack for the current operating system level. v Recommended: Scans for the latest available technology level and the latest service packs for one level before the latest technology level. v Latest for current TL: Scans for the latest service pack for the current technology level. v Custom: Technology Level + Service Pack: Scans for a specific technology level and service pack for a specific OS version. In the OS Level, Technology Level, and Service Pack fields, select the appropriate values depending on what you want to scan for. The technology level must be the same as your current technology level on the target computer. Tip: You can use the Info: Discover current TL and SP option to display the current technology level and service pack for your target computers. for the Satellite Server field, and click the name of the computer that you 4. Click Select Value want to use as theAIX satellite server. 5. In the Download Location for All Targets field, type the path for downloading the patches into the file repository, in the format <base_path>/installp/ppc. To find out the base path that is used on your system, run the command
suma -D
The output of the command displays the base path that you need to enter in the DLTarget field. The default base path is /usr/sys/inst.images/installp/ppc. . 6. Click Save 7. Click Run Discovery. 8. Click Select > Groups and select the check box corresponding to your group of target computers, then click OK. 9. Click Submit. 10. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The discovery task is displayed with a status of Success on the Provisioning Task Tracking page. Next you will be scanning for missing patches. Scanning for missing patches: You can compare the software that exists on your target computers with the list of patches that are available to see which patches are missing on which computers. By default, all patches that have been approved in the data model are scanned, and target computers are verified against all approved patches to see if computers are compliant. You can also select a patch approval group, which is used to specify a set of allowed patches, or approval lists. The patch approval group limits the patches for which recommendations are generated to the specified set of patches only. You might want to use this option to tightly control patches for critical computers where more exhaustive testing of patches is needed before they are required to be installed.The AIX patch scan generates recommendations based on AIX patch updates available in the data model. Make sure that your user role is Provisioning Configuration Librarian or equivalent.
924
To scan for missing patches: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Compliance tab. 4. Click Run Scan and Check. Tip: If you want to schedule the provisioning task for a later time, click Schedule Scan and Check to specify scheduling options. 5. Click the Notification tab to specify notification options if you want users to be notified about the task status. 6. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. Attention: Wait until the task completes before starting another compliance scan task on the target computers. If you run concurrent compliance scan tasks on a target computer, the tasks might fail. The scanning and checking task is displayed with a status of Success on the Provisioning Task Tracking page. The recommendations to install missing patches are generated. On the Compliance tab for the group, the patch check displays either Yes or No in the Compliant column, depending on whether all required patches are installed on the target computers. If notification was set up, recipients will be notified that recommendations need be approved. Approving compliance recommendations: After scanning your target computers to see which patches are missing on them, compliance recommendations are generated. Based on these recommendations, you can decide which patches you want to install on your target computers. The AIX patch scan generates recommendations based on AIX patch updates available in the data model. Make sure that your user role is Compliance Analyst or equivalent. To approve compliance recommendations: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Recommendations tab. 4. In the recommendations list, select the check boxes corresponding to the missing patches that you want to approve and click Approve. The selected patches are displayed with a status of Approved on the Recommendations tab. Distributing patches: After patches are approved, you can distribute the already downloaded technology levels or service packs to the target computers before installation. Because the size of the AIX patches is quite large, it is recommended to distribute the AIX patches before installing, especially if the maintenance window for installing the patch is not very long. You can distribute patches immediately or schedule this task for a specified date and time.
925
Make sure that your user role is Deployment Specialist or equivalent. To distribute patches: 1. Click Go To > Deployment > Patch Management > Patch Distribution. Tip: To perform this task from the Start Center, click Patch Distribution under Patch management applications. 2. Click Select Patches and select the patches that you want to distribute, then click OK. Tip: You can filter down the list of displayed patches by patch name, vendor, and version. To search for a particular patch, type the patch name in the Patch field, for example, AIX_SP 6100-00-01. To use more search fields, expand Advanced Search Options and customize the options in the window, then click Refine. 3. Click Select > Groups and select your group of target computers, then click OK. 4. 5. 6. 7. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. Under Notification, specify notification options if you want users to be notified about the task status. Click Submit. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed.
The patch distribution task is displayed with a status of Success on the Provisioning Task Tracking page. Installing patches: After patches are approved, you can install them on the target computers where they are missing. You need to install technology levels before you install service packs. Make sure that your user role is Deployment Specialist or equivalent. To install patches: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Recommendations tab. 4. From the recommendations list, select all of the patches that are approved and click Implement. 5. Specify the options you want for installing and click Submit. 6. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The patch installation task is displayed with a status of Success on the Provisioning Task Tracking page. Verifying compliance results: After installing patches on the target computers, you can verify that patches installed successfully. Make sure that your user role is Compliance Analyst or equivalent You can verify compliance results either by running the compliance scan again and verifying the list of recommendations or by running patch reports that provide information about missing patches. Running the compliance scan again:
926
To run the compliance scan: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Compliance tab. 4. Click Run > Check to run a compliance check before displaying the recommendations so that the results are accurate. 5. Click the Recommendations tab. 6. In the list of recommendations, verify that the installed patches are no longer displayed as missing. 7. Click OK. Installed patches are no longer listed on the list of recommendations because they are not missing from the target computers. Generating patch compliance reports: To generate patch compliance reports: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click the group of target computers to generate the report for. 3. Click the Compliance tab. 4. Click Run > Check to perform a compliance check before running the report so that the results are accurate. 5. Click Go To > Administration > Reporting > Report Administration. 6. Search for the report with the description Are servers compliant with their compliance checks? and click the report name. 7. Click Generate Request Page. 8. After the report is generated, click Close. The report lists all the target computers that have a patch compliance check defined. The Is Compliant column lists the compliance status of the target computers. 9. Click Preview and in the dialog box that is opened click Submit. Tip: You can also generate the report with the description What patches are missing on what servers? to list all the missing patches and their corresponding target computers. Installed patches are not listed since they are not missing from the target computers.
927
Related information Testing patches on page 922 Setting up compliance on page 922 Scanning for missing patches on page 924 Distributing patches on page 925 Installing patches on page 926 Discovering the AIX satellite server and the target computers on page 920
Managing patches in Red Hat Enterprise Linux environments

You can use IBM Tivoli Provisioning Manager to manage patches in Red Hat Enterprise Linux 6, 5, and 4 environments. You can manage patches in Red Hat Enterprise Linux 6 and 5 environments using the scalable distribution infrastructure. You do not use the scalable distribution infrastructure to manage patches in Red Hat Enterprise Linux 4 environments.
Supported platforms
You can use IBM Tivoli Provisioning Manager to manage patches for the following Red Hat Enterprise Linux environments: v Red Hat Enterprise Linux only) v Red Hat Enterprise Linux only) v Red Hat Enterprise Linux infrastructure only) v Red Hat Enterprise Linux only) 6 Server Advanced Platform (x86 32-bit) (scalable distribution infrastructure 6 Server Advanced Platform (x86 64-bit) (scalable distribution infrastructure 6 Server Advanced Platform (IBM System z 64-bit) (scalable distribution 5 Server Advanced Platform (x86 32-bit) (scalable distribution infrastructure
v Red Hat Enterprise Linux 5 Server Advanced Platform (x86 64-bit) (scalable distribution infrastructure only) v Red Hat Enterprise Linux 5 Server Advanced Platform (IBM System z 64-bit) (scalable distribution infrastructure only) v Red Hat Enterprise Linux 4 AS/ES (x86 32-bit) v Red Hat Enterprise Linux 4 AS/ES (x86 64-bit) v Red Hat Enterprise Linux 4 AS/ES (IBM System i 32-bit/64-bit) v Red Hat Enterprise Linux 4 AS/ES (IBM System p 32-bit/64-bit) v Red Hat Enterprise Linux 4 AS/ES (AMD 64-bit) Note: Only 64-bit packages are installed with the default installation of Red Hat Enterprise Linux 6 Server Advanced Platform (x86 64-bit), which might cause 32-bit applications running on 64-bit targets to fail. To avoid this, during the installation, select Custom installation, and then, from the Base Server component, select the Compatibility Libraries and Unix Legacy Library boxes, to also install the 32-bit packages that are required to run 32-bit binaries. The following sections provide information about how to manage patches for Red Hat Enterprise Linux versions 6, 5 and 4: v Tutorial: Managing patches in Red Hat Enterprise Linux 6 and 5 environments on page 932 v Managing patches in Red Hat Enterprise Linux 4 environments on page 949
Red Hat Enterprise Linux environments

You can manage patches in Red Hat Enterprise Linux 6 and 5 environments. This section provides information about how to manage patches in Red Hat Enterprise Linux 6 and 5 environments.
928

Red Hat Enterprise Linux 6 and 5 environments: This topic applies to patch management for Red Hat Enterprise Linux 6 and 5 environments.
Patch management includes the processes that are illustrated and detailed the information later in this section. Roles for each step in the process are noted in parentheses.
Discover computers
Set up environment
Configure YUM Repository
Acquire patches
Test patches
Legend
1. Discover computers and set up the environment (Provisioning Administrator) This process consists of the following tasks: v Run initial discovery to discover all computers and to add them to the data model. Initial discovery finds out what operating system is installed on your target computers, which is required to make sure that patches for that operating system are acquired in a later step in the process. As part of initial discovery, group the discovered target computers to manage patches for multiple computers at the same time. Tip: The task of discovering computers can be performed also by the provisioning configuration librarian.
929
v Depending on the configuration used in your organization, you might need to set up a proxy server for connecting the provisioning server and the YUM server. v Set up the scalable distribution infrastructure to manage distribution and installation of patches on the target computers. Tip: The task of setting up the infrastructure can be performed also by the provisioning configuration librarian. 2. Install required software on target computers (Deployment Specialist) This process consists of installing the common agent on the target computers. The common agent is a software product that is required for software distribution and software compliance management. 3. Acquire patches (Provisioning Configuration Librarian) This process consists of specifying which patches you want to acquire from those released by the vendor, and bringing those patches into the data model. 4. Test patches This process is recommended as part of the patch management life cycle process, to ensure that all possible conflicts have been identified in a test environment before installing the patches in the production environment. You can install the patches in defined test environments using the Patch Installation application, but the actual testing of patches is performed outside the provisioning applications. Therefore, this task does not have a role associated with it. Typically, the test engineer in your organization performs this task. 5. Approve patches (Compliance Analyst) This process consists of approving which patches you want to install. Two levels of approval are required: for the entire organization (at the data model level), and for each target computer or group of target computers, if a patch is missing on a specific group of computers. 6. Set up compliance (Compliance Analyst) This process consists of creating compliance checks to determine if the software installed on the target computers matches your requirements. Compliance checks define the compliant state of your target computers and are used to detect, report, and recommend how to fix noncompliance. Add a patch check to a group of target computers, and, optionally, identify specific patch approval groups to scan. 7. Scan for missing patches (Provisioning Configuration Librarian) This process consists of scanning the target computers and checking to see which patches are missing from the target computers. After the scan, a list of missing patches is generated and then the check creates compliance recommendations for each computer or group. 8. Approve compliance recommendations (Compliance Analyst) This process consists of approving which patches you want to install. You approve patches for each target computer or group of computers, if a patch is missing on the target computers. 9. Install patches and monitor patch installation (Deployment Specialist) This process consists of distributing and installing the patches on target computers. You can distribute and install patches at the same time or schedule these tasks separately. You can install patches on a specific target computer or multiple target computers as one task. You can also monitor the progress of patch installation. 10. Verify compliance results (Compliance Analyst) This process consists of validating that the patches were successfully applied to all the target computers you selected. Run the compliance check again to verify that the installed patches are no longer listed in the list of recommendations.
Components for Red Hat Enterprise Linux 6 and 5 environments

To manage patches in Red Hat Enterprise Linux 6 and 5 environments, set up your configuration so that all components work together.
930
The following diagram illustrates the supported configuration.
Internet
YUM Repository
Proxy server (optional)
Provisioning server (any supported OS)
You can install any supported operating system on the provisioning server. The provisioning server is connected to the YUM repository. If the provisioning server and the YUM repository are separated by a firewall, you need to set up a proxy server. The patches are stored on the YUM repository.
Customizing the Red Hat Enterprise Linux 6.0 installation for common agent support
During the Red Hat Enterprise Linux version 6.0 installation, you can install several optional packages to ensure support for the common agent. To customize the Red Hat Enterprise Linux 6.0 installation for common agent support:
Procedure
1. When the RHEL 6.0 installation wizard prompts you to customize the packages to be installed, select the Customize now radio button, and then click Next. 2. Select Base System in the left list, then make the following selections in the right list: a. Select the Compatibility libraries check box, then right-click it and select the Select all optional packages option in the pop-up menu. b. Select the Legacy UNIX compatibility check box, then right-click and select Select all optional packages. c. Select the Networking Tools check box, then right-click and select Select all optional packages. 3. Click Next, and then follow the default wizard steps until the installation completes.
931
4. After the installation, verify that the required libraries have been installed successfully: For x86_64 bit platforms Enter the following commands. The output looks similar to the following:
ldconfig -p | grep -i ld should give similar to below output 1564 libs found in cache `/etc/ld.so.cache librpmbuild.so.1 (libc6,x86-64) => /usr/lib64/librpmbuild.so.1 librpmbuild.so (libc6,x86-64) => /usr/lib64/librpmbuild.so libplds4.so (libc6,x86-64) => /lib64/libplds4.so libplds4.so (libc6,x86-64) => /usr/lib64/libplds4.so libnss_ldap.so.2 (libc6,x86-64) => /lib64/libnss_ldap.so.2 libnss_ldap.so (libc6,x86-64) => /usr/lib64/libnss_ldap.so libldb.so.0 (libc6,x86-64) => /usr/lib64/libldb.so.0 libldap_r-2.4.so.2 (libc6,x86-64) => /usr/lib64/libldap_r-2.4.so.2 libldap_r-2.3.so.0 (libc6,x86-64) => /usr/lib64/libldap_r-2.3.so.0 libldap-2.4.so.2 (libc6,x86-64) => /usr/lib64/libldap-2.4.so.2 libldap-2.3.so.0 (libc6,x86-64) => /usr/lib64/libldap-2.3.so.0 libkldap.so.4 (libc6,x86-64) => /usr/lib64/libkldap.so.4 libkldap.so (libc6,x86-64) => /usr/lib64/libkldap.so libkdeinit4_kbuildsycoca4.so (libc6,x86-64) => /usr/lib64/libkdeinit4_kbuildsycoca4.so ld-linux.so.2 (ELF) => /lib/ld-linux.so.2 ld-linux-x86-64.so.2 (libc6,x86-64) => /lib64/ld-linux-x86-64.so.2
For zSeries platforms Enter the following commands. The output looks similar to the following:
1327 libs found in cache `/etc/ld.so.cache librpmbuild.so.1 (libc6,64bit) => /usr/lib64/librpmbuild.so.1 librpmbuild.so (libc6,64bit) => /usr/lib64/librpmbuild.so libplds4.so (libc6,64bit) => /lib64/libplds4.so libnss_ldap.so.2 (libc6,64bit) => /lib64/libnss_ldap.so.2 libnss_ldap.so (libc6,64bit) => /usr/lib64/libnss_ldap.so libldb.so.0 (libc6,64bit) => /usr/lib64/libldb.so.0 libldap_r-2.4.so.2 (libc6,64bit) => /usr/lib64/libldap_r-2.4.so.2 libldap-2.4.so.2 (libc6,64bit) => /usr/lib64/libldap-2.4.so.2 libkldap.so.4 (libc6,64bit) => /usr/lib64/libkldap.so.4 libkldap.so (libc6,64bit) => /usr/lib64/libkldap.so libkdeinit4_kbuildsycoca4.so (libc6,64bit) => /usr/lib64/libkdeinit4_kbuildsycoca4.so ld64.so.1 (libc6,64bit) => /lib64/ld64.so.1 ld.so.1 (ELF) => /lib/ld.so.1
Tutorial: Managing patches in Red Hat Enterprise Linux 6 and 5 environments

This tutorial demonstrates patch management using the scalable distribution infrastructure, on target computers that have Red Hat Enterprise Linux 6 or 5 installed. The scalable distribution infrastructure allows you to manage a large number of target computers in various topologies, and provides a fast and reliable way to scan, distribute, and install patches on target computers that require them.
Learning objectives
In this tutorial, you learn how to: v Discover and group target computers. v v v v v v Set up servers, infrastructure, and target computers. Acquire patches. Approve patches. Set up compliance for the target computers. Scan the target computers for missing patches. Distribute patches.
932
v Install patches. v Verify compliance results. Allow several hours to discover your target computers, set up the infrastructure, set up the target computers, and install the patches on them. Acquiring the patches from the YUM repository might take from 30 minutes to a few hours, depending on the number of patches that are available, the connection speed, and the location of the YUM repository, if local or remote.
Prerequisites
Before you start, verify that you meet the requirements listed in Requirements for Red Hat Enterprise Linux 6 and 5 environments. Modules in this tutorial v Requirements for Red Hat Enterprise Linux 6 and 5 environments v Part 1: Environment setup on page 935 v Part 2: Day-to-day tasks on page 941 Requirements for Red Hat Enterprise Linux 6 and 5 environments: Before you start managing patches in Red Hat Enterprise Linux 6 and 5 environments, ensure that you meet all requirements.
You can manage patches for the following Red Hat Enterprise Linux 6 and 5 operating systems and versions: v Red Hat Enterprise Linux 6 Server Advanced Platform (x86 32-bit) v Red Hat Enterprise Linux 6 Server Advanced Platform (x86 64-bit) v Red Hat Enterprise Linux 6 Server Advanced Platform (IBM System z 64-bit) v Red Hat Enterprise Linux 5 Server Advanced Platform (x86 32-bit) v Red Hat Enterprise Linux 5 Server Advanced Platform (x86 64-bit) v Red Hat Enterprise Linux 5 Server Advanced Platform (IBM System z 64-bit) Note: Only 64-bit packages are installed with the default installation of Red Hat Enterprise Linux 6 Server Advanced Platform (x86 64-bit), which might cause 32-bit applications running on 64-bit targets to fail. To avoid this, during the RHEL 6 installation, select Custom installation, and then, from the Base Server component, select the Compatibility libraries, and Legacy UNIX compatibility check boxes, to also install the 32-bit packages that are required to run 32-bit binary files. User roles and requirements: To perform the tasks in patch management, ensure that you have the required knowledge and access permissions to perform your role.
933
Table 170. Roles and skills for patch management in Red Hat Enterprise Linux environments Role Provisioning Administrator Provisioning tasks v Discover and group target computers v Set up servers and infrastructure Skills v Knowledge of the provisioning environment v Knowledge of the Red Hat Enterprise Linux operating system v Knowledge of Internet technologies v Knowledge of scalable distribution infrastructure v Knowledge of how to set up the YUM repository Provisioning Configuration Librarian v Acquire patches v Scan the target computers for missing patches v Organize and maintain the patch catalog v Create and maintain patch groups, delete patches from the data model Compliance Analyst v Approve patches in the data model v Knowledge of the Red Hat Enterprise Linux operating system v Set up compliance v Approve compliance recommendations v Verify compliance results Deployment Specialist v Install required software on target computers v Publish patches v Distribute patches v Unpublish patches v Implement compliance recommendations to install missing patches v Monitor patch installation v Uninstall patches v Knowledge of the Red Hat Enterprise Linux operating system v Knowledge of the patch management life cycle v Knowledge of the patch management life cycle v Knowledge of the Red Hat Enterprise Linux operating system v Knowledge of the patch management life cycle
Server requirements: There are a number of requirements that must be met by the components in your configuration so that you can manage patches in Red Hat Enterprise Linux 6 and 5 environments. You must have cURL installed on the provisioning server. cURL is a free URL transfer library and supports several protocols such as FTP, HTTP, HTTPS, and LDAP. Note: For AIX systems, ensure that you use a cURL version with SSL support. You can install cURL from http://curl.haxx.se/. Target computer requirements: There are some requirements that must be met by the target computers so that you can manage patches in Red Hat Enterprise Linux 6 and 5 environments.
934
v All files required for patch installation on the target computers are downloaded to the /tmp directory. Ensure that the file system where the directory is located has enough disk space to store at least all the patches you want to install in one installation or remediation task. v For information about the general requirements for Red Hat Enterprise Linux target computers, see Requirements for Red Hat Linux target computers on page 560. v For common agent support on RHEL 6.0, see Customizing the Red Hat Enterprise Linux 6.0 installation for common agent support on page 931. Part 1: Environment setup: Before starting to manage patches for Red Hat Enterprise Linux 6 and 5 environments, you must set up the servers depending on the configuration that you are using. Also, you must set up the scalable distribution infrastructure and install required software on your target computers.
Discovering and grouping target computers: You must make your target computers known to the data model. To do this, you can run initial discovery, which searches for unknown resources and adds them to the data model. For existing resources, the data model is updated with any new or changed information. You can then group your target computers so that you can manage patches for multiple computers at the same time. Make sure that the following requirements are met: v Your user role is Provisioning Administrator, Provisioning Configuration Librarian, or equivalent. v Your target computers meet the requirements listed in Target computer requirements on page 934.
To discover and group your target computers, perform the following steps. Tip: You can use the Computer Discovery, Common Agent Installation, and Inventory Discovery discovery wizard to run a network discovery of the computers, install the common agent on these computers, and run a hardware and software scan. For more information, see Discovering your environment using the ready-to-use network discoveries on page 231. 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. Tip: To perform this task from the Start Center, click Discovery Configurations under Provisioning administration applications or Discovery and task applications. 2. Find the discovery configuration called Initial Discovery and click its name on the list. 3. Click the IP Address Ranges tab. 4. Click New Row. 5. In the Start and End fields, type the IP addresses of your target computers. After each set of IP addresses, click New Row.
935
Tip: You can also specify subnetworks that you want to discover. If, for example, all the target computers that you want to discover are in a LAN, click the Subnetworks tab and specify the IP address and mask for the LAN. After specifying each subnetwork, click New Row. 6. Click the Credentials tab. 7. Click New Row. 8. Type the user name and password. After each set of credentials, click New Row. If you specify more than one set of credentials, those credentials are used on each target computer in the order that they are listed. If the logon attempt on a target computer is successful, the computer is added to the data model. Notes: v The system attempts to connect to each IP address using each user name and password provided until it finds a user name and password that can be used to connect successfully. This might cause user accounts to be locked out, depending on the security policy enforced on the target computers. v You might need to increase the default timeout value if you are on a slow network or you are attempting to discover slow computers. 9. In the Add Computers to Group field, click Select Value the target computer after running initial discovery. Tip: If you want to create a group, see Creating groups. . 10. Click Save 11. Click Run Discovery. 12. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 13. Under Notification, specify notification options if you want users to be notified about the task status. 14. Click Submit. 15. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The discovery task is displayed with a status of Success on the Provisioning Task Tracking page and the discovered computers are recorded in the details of the discovery task. Configuring the YUM repository: Red Hat Enterprise Linux 6 or 5 uses Yellow dog Updater Modified (YUM) as its package management solution. Make sure that your user role is Provisioning Administrator or Provisioning Configuration Librarian.
and select the group in which to add
To define the YUM repository in the data model: 1. Click Go To > IT Infrastructure > Provisioning Inventory > File Repositories. Tip: To perform this task from the Start Center, click File Repositories under Infrastructure applications. 2. Click the File Repositories tab. . 3. Click New File Repository 4. In File Repository, type the file repository name and root path of the local YUM repository.
936
5. In Root Path, type the root path of the local YUM repository. The value depends on the configuration of the YUM repository and on the protocol you use. For example, if the YUM repository is configured with this structure, where repodata is in the /storage/repository/redhat/ yum/5/server/os/servers/fix/ path, depending on the protocol you use, the root path is as follows: SSH protocol /storage/repository Note: The SSH protocol is supported only if there is no proxy server between the provisioning server and the YUM repository. Prerequisite: The SSH protocol must be enabled on the repository. FTP protocol / Note: / represents the local_root variable in /etc/vsftpd/vsftpd.conf. For example, if local_root is set to /storage/repository/, then the root path in the user interface must be mentioned as /, and it affects the path added using the Add Path option, as described later in step 11. By default, local_root is set to /. Prerequisite: The FTP protocol must be enabled on the repository. HTTP or HTTPS protocols / Note: v / represents the DocumentRoot variable in /etc/httpd/conf/httpd.conf. For example, if DocumentRoot is set to /storage/repository/, then the root path in the user interface must be mentioned as /, and it affects the path added using the Add Path option, as described later in step 11. By default, DocumentRoot is set to /var/www/html/. v While using the HTTPS protocol, SSL certificates must be imported into the provisioning server. For more information, see Importing the SSL certificate on page 1064. Prerequisite: The HTTP and HTTPS protocols must be enabled on the repository. 6. When you select the Is YUM Repository check box, new fields are displayed to specify YUM configuration parameters. 7. In IP Address, type the IP address of the YUM repository. 8. In Protocol, select the supported protocol from the list. 9. If you need to change the default port number, which is populated when you select the protocol, type your port number in the Port field. 10. If authentication is required for the YUM repository, type a user name in the User Name field, a new password in the Password field, and retype it in the Confirm Password field. 11. Click Add Path and specify the information to dynamically configure the repository paths. For example, if the YUM repository is configured with this structure /storage/repository/redhat/yum/5/ server/os/servers/fix, as exemplified earlier in step 5, you use the following path: SSH protocol /redhat/yum/5/server/os/servers/fix/ FTP protocol /redhat/yum/5/server/os/servers/fix/ HTTP or HTTPS protocols /redhat/yum/5/server/os/servers/fix/ 12. Click Save .
937
Based on the information provided, the YUM repository, data model objects, software module, and credentials are created in the Provisioning Manager data model database to capture the YUM repository structure. Setting up the proxy server: When the provisioning server and the YUM repository are separated by a firewall, you must set up the proxy server. Make sure that your user role is Provisioning Administrator or equivalent.
Defining the proxy server: To define the proxy server: 1. Click Go To > Deployment > Provisioning Computers. Tip: To perform this task from the Start Center, click Provisioning Computers under Automation development applications. 2. 3. 4. 5. 6. In the Computer field, type the name of the provisioning server. In the list, click the computer name. Click the Credentials tab. Click Add Credentials > New Service Access Point. Type a name for the service access point. In the Protocol Type field, click Network protocol IP.
7. In the Application Protocol field, click HTTP Access. 8. In the Context field, type URLGrabProxy. 9. Type the port number for the proxy server, for example, 3128. Note: Port 3128 is the default port for most proxy servers. If you are using a different proxy server port in your environment, type that proxy server number. 10. In the Domain field, type the fully qualified host name or IP address of the proxy server. 11. If the proxy server requires authentication, select the Authentication check box. Otherwise, leave this check box blank. 12. Click New Password Credential. 13. In the Search Key field, type a meaningful string. 14. Type the user name and the password for the proxy server, if required. . 15. Click Save Related information Configuring the YUM repository on page 936 Setting up the infrastructure Installing required software on target computers on page 940 Red Hat Enterprise Linux environments on page 928 Setting up the infrastructure: You can set up a region, a zone, and a depot server, which are used to distribute and install the patches on the target computers.
938
Make sure that your user role is Provisioning Administrator or equivalent.

Setting up a region: Regions are used to group depot servers that are located near one another to optimize upload, replication, and download times. When you create a depot server, associate it with a region. You can assign a depot server to only one region. To set up a region: 1. Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. Tip: To perform this task from the Start Center, click Dynamic Content Delivery Configuration under Provisioning administration applications. 2. Click the Regions tab. 3. Click New Row. 4. Type a name and a description for the new region. 5. Click Save Setting up a zone: Optionally, you can set up a zone to define an IP address range or a domain name within a region. Regions can be generic, without a real network definition, or they can be specific, when zones are used to define domain names within a region. Zones are used to logically group computers within regions. To set up a zone: 1. On the Dynamic Content Delivery Configuration page, click the Zones tab. 2. Click New Row. 3. Type a name and a description for the new zone. and click the region that you created in the previous task. 4. In the Regions field, click Select Value 5. Select Domain Name, and then specify the domain that your depot server and target computers are in. 6. Click Save . .
Setting up a depot server: A depot server is a system that stores files for distribution. Distribution files are uploaded to a depot server using a client. Uploaded files are stored in a directory that is specified when the depot server is installed. Depot servers can replicate uploaded files to other depot servers to optimize the network traffic. The target computers download the files from the depot servers. To set up a depot server: 1. On the Dynamic Content Delivery Configuration page, click the Depots tab. 2. Click New Row. 3. Type a name and description for the depot server. and click the region that you created in the previous task. 4. In the Region field, click Select Value This is the region that the depot server is assigned to.
939
5. In the Computer field, click Select Value set up as a depot server.
and click the name of the computer that you want to
Note: The depot server must not be included in your group of target computers. 6. In the Fully qualified host name field, type the fully qualified host name of the depot server that has already been discovered. 7. Select the Install the depot agent services check box to install the depot agent services on the depot server. and select the zone that you set up in the 8. In the Domain Zone Served field, click Select Value previous task. 9. Type the user name and password for the depot server. 10. If using only one depot server, select the Preferred upload server check box. At least one preferred depot server is required. . 11. Click Save Related information Configuring the YUM repository on page 936 Setting up the proxy server on page 938 Installing required software on target computers Red Hat Enterprise Linux environments on page 928 Installing required software on target computers: Install the common agent on the target computers. The common agent is a software product that is required for software distribution and software compliance management. Make sure that the following requirements are met: v Your user role is Deployment Specialist or equivalent. v The target computers meet the requirements listed in the Target computer requirements on page 934 topic.
Installing the common agent: The common agent is a software product that provides infrastructure for management applications. The common agent installed on the target computers provides remote deployment capability, shared computer resources, secure connectivity, and a single entry point. The common agent can be installed once on each target computer. After the common agent is installed on a target computer, subsequent subagents can be installed on top of an existing common agent. To install the common agent, perform the steps listed later in this section. Note: If you used the Computer Discovery, Common Agent Installation, and Inventory Discovery discovery wizard to discover your computers, then the common agent is already installed. Proceed to Acquiring patches on page 941. 1. Click Go To > Deployment > Software Management > Common Agent Installation. 2. Click Select > Groups, and select your group of target computers, and then click OK. 3. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 4. Under Notification, specify notification options if you want users to be notified about the task status.
940
5. Click Submit. 6. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The common agent installation task is displayed with a status of Success on the Provisioning Task Tracking page. Related information Configuring the YUM repository on page 936 Setting up the proxy server on page 938 Setting up the infrastructure on page 938 Red Hat Enterprise Linux environments on page 928 Part 2: Day-to-day tasks: After setting up the environment, there are a number of tasks that you must perform as day-to-day patch management activities to ensure that your target computers are always up-to-date with the required patches.
Acquiring patches: Patch acquisition is the process of discovering available patches and importing the patch metadata from the YUM repository. Make sure that the following requirement is met: v Your user role is Provisioning Administrator or Provisioning Configuration Librarian.
Note: When the provisioning server and the YUM repository are separated by a firewall, you must set up a proxy server. Ensure that the FTP user has the required access permissions to access the YUM repository. No error is displayed if the FTP user does not have the required access permissions. To acquire patches: 1. Click Go To > IT Infrastructure > Software Catalog > Patch Acquisition. Tip: To perform this task from the Start Center, click Patch Acquisition under Discovery and task applications. 2. In the Operating System list, click Select Value systems. 3. In the YUM File Repository field, click Select Value that you previously created. 4. Select the repository paths. and click Linux from the list of operating and click the name of the YUM repository
Note: Any subsequent patch scan, performed either using a compliance check or a YUM scan discovery, is performed on the patches acquired at patch acquisition time based on this selection.
941
5. Optional: To approve the acquired patches automatically, in the Initial Patch Status list, click Select and click APPROVED. This option is useful if you want to mark as approved all the Value patches that were made available by the vendor, without having to approve them in a later step. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. Under Notification, specify notification options if you want users to be notified about the task status. Click Submit. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed.
6. 7. 8. 9.
The patch acquisition task is displayed with a status of Success on the Provisioning Task Tracking page. The patches are brought into the data model. To view the patches catalog, in the Start Center, click Patches under Favorite applications. Note: After completing the patch acquisition, you can run the compliance scan and check directly if the scan settings required are identical to the settings you used for patch acquisition. For example, if you plan to scan for a certain level of patches on the repository paths defined at acquisition time. If you need to customize the scan for specific levels and architecture, use the YUM scan to set up specific scan settings, which must be a subset of selections made at acquisition time. Testing patches: It is recommended to test the released patches before installing them, to ensure that all possible conflicts have been identified in a test environment before installing them in the production environment. You can install the patches on a test computer using the Patch Installation application, but you need to test patches outside of the provisioning applications.
Approving patches in the data model: After patches are acquired, the first step in the approval process is to approve the patches for the entire organization (at the data model level). Only the approved patches are considered when scanning the target computers for missing patches. For example, in some organizations all patches are approved at the data model level and then the compliance analyst decides which patches to approve for each provisioning group. This second step in the approval process is done when scanning for missing patches. In other organizations, there might be some patches that the compliance analyst does not want to approve immediately after acquisition, because further testing is required before approving. Make sure that your user role is Compliance Analyst or equivalent.
To approve the acquired patches in the data model: 1. Click Go To > IT Infrastructure > Software Catalog > Patches. Tip: To perform this task from the Start Center, click Patches under Favorite applications. 2. Press Enter to display all patches from the catalog.
942
Tip: You can filter down the list of displayed patches by patch name, version, severity, vendor, release date, and so on. To search for a particular patch, type the patch name in the Patch field, for example, redhat-release-5Server. To use more search fields, click Advanced Search and customize the options in the window, then click Find. 3. Click Select Records and select the patches that you want to approve, then click Approve. Note: To select records, filter down your list of patches to a maximum of 200. If you want to approve more than 200 patches at the same time, filter down your patches, then click Approve and click OK on the confirmation message. Patches that you have approved are displayed with a status of Approved on the Patches page. Configuring the YUM scan discovery: Before running the compliance scan, you must configure the YUM repository in the YUM Scan discovery configuration and run the discovery configuration. Make sure that your user role is Provisioning Administrator or Provisioning Configuration Librarian or equivalent. To customize the scanning model: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. Tip: To perform this task from the Start Center, click Discovery Configurations under Automation development applications . 2. Find the YUM Scan discovery configuration and click it. 3. Click Select Value for the YUM File Repository field, and select the repository where the scan is to be performed. 4. In the Select YUM Repository Paths section, select the architecture and level of updates to scan for. . 5. Click Save 6. Click Run Discovery. 7. Click Select > Groups and select the check box corresponding to your group of target computers, then click OK. 8. Click Submit. 9. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The discovery task is displayed with a status of Success on the Provisioning Task Tracking page. You can now scan for missing patches. Setting up compliance: You can set up a compliance check to verify if patches are required on the target computers. Compliance checks define the compliance state of your target computers and are used to detect, report, and recommend how to fix noncompliance. Make sure that your user role is Compliance Analyst or equivalent.
943
To set up compliance: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Find your group of target computers and click its name in the list. 3. Click the Compliance tab. 4. Click New Compliance Check > Patch Check. 5. In the Patch Approval Group field, click Select Value scanned, then click Save. and select a group of patches to be
Tip: By default, all patches that have been approved in the data model are scanned, and target computers are verified against all approved patches to see if computers are compliant. You can also select a patch approval group, which is used to specify a set of allowed patches, or approval lists. The patch approval group limits the patches for which recommendations are generated to the specified set of patches only. You might want to use this option to tightly control patches for critical computers where more exhaustive testing of patches is needed before they are required to be installed. Do not perform the patch check using a software compliance check of type Software Group associated to the Patch Approval Group. Doing this can cause the following problems: v If a software patch contained in the Patch Approval Group is installed, target computers result as compliant. v The check is performed for the specific software patch installation and disregards any relation between the software patches, for example, superseding patches. v The check is performed on all computers belonging to the group and disregards if the software patch is applicable to only certain platforms. 6. Optional: To automatically approve recommendations when they are generated, click Enable Automatic Approval and click OK in the message box. All recommendations that are generated by this compliance check will be created in the Approved state. 7. Click Save .
The Operating System Patches and Updates compliance check is displayed in the list of compliance checks defined for the group of target computers. Scanning for missing patches: You can compare the software installed on your target computers with a list of the patches that have been approved for the entire organization, to see which patches are missing on which computers. By default, all patches that have been approved in the data model are scanned, and target computers are verified against all approved patches to see if computers are compliant. You can also select a patch approval group, which is used to specify a set of allowed patches, or approval lists. The patch approval group limits the patches for which recommendations are generated to the specified set of patches only. You might want to use this option to tightly control patches for critical computers where more exhaustive testing of patches is needed before they are required to be installed. Make sure that your user role is Provisioning Configuration Librarian or equivalent.
To scan for missing patches: 1. Click Go To > Deployment > Provisioning Groups.
944
Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Compliance tab. 4. Click Run Scan and Check. Tip: If you want to schedule the task for a later time, click Schedule Scan and Check to specify scheduling options. 5. Click the Notification tab to specify notification options if you want users to be notified about the task status. 6. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. Attention: Wait until the task completes before starting another compliance scan task on the target computers. If you run concurrent compliance scan tasks on a target computer, the tasks might fail. The scanning and checking task is displayed with a status of Success on the Provisioning Task Tracking page. The recommendations to install missing patches are generated. On the Compliance tab for the group, the patch check displays either Yes or No in the Compliant column, depending on whether all required patches are installed on the target computers. If notification was set up, recipients are notified that recommendations must be approved. Approving compliance recommendations: After scanning your target computers to see which patches are missing on them, compliance recommendations are generated. Based on these recommendations, you can decide which patches you want to install on your target computers. Make sure that your user role is Compliance Analyst or equivalent.
To approve compliance recommendations: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Recommendations tab. 4. In the recommendations list, select the check boxes corresponding to the missing patches that you want to approve and click Approve. The selected patches are displayed with a status of Approved on the Recommendations tab. Publishing patches to depots: After patches are approved, you can optionally publish them to the depots, then distribute, and install them on the target computers. During the publishing phase, the patch binaries are downloaded into the data model, and then the patch binaries and other files (for example cab file, vbscript) are published to a depot server. From the depot server, patches are distributed for installation on target computers. You can distribute patches immediately or schedule this task for a specified date and time. Make sure that your user role is Deployment Specialist or equivalent.
945
Tip: You can also publish, distribute, and install patches in one step from the Recommendations tab for both Provisioning Computers and Provisioning Groups. To perform this operation: 1. Click Go To > Deployment > Provisioning Computers. or Click Go To > Deployment > Provisioning Groups. 2. Select the group or computer in the list and click it. 3. Select the Recommendations tab. 4. Select one or more patches and click Approve. The recommended actions can now be run or scheduled. The selected patches are published, distributed, and installed. To distribute patches: 1. Click Go To > Deployment > Patch Management > Patch Publishing. Tip: To perform this task from the Start Center, click Patch Publishing under Patch management applications. 2. Click Select Patches and select the patches that you want to distribute, then click OK. Tip: You can filter down the list of displayed patches by patch name, vendor, and version. To search for a particular patch, type the patch name in the Patch field, for example, redhat-release-5Server. If multiple software definitions are available for that patch number, select the check boxes for all the software definitions that match the patch number. The correct patch, based on the operating system on the target computer, are distributed to the appropriate target computer. To use more search fields, expand Advanced Search Options and customize the options in the window, then click Refine. 3. Click Select Depots and select one or more depots, then click OK. 4. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 5. Under Notification, specify notification options if you want users to be notified about the task status. 6. Click Submit. 7. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The patch distribution task is displayed with a status of Success on the Provisioning Task Tracking page. Distributing patches: After patches are published to depots, you can optionally distribute them first and then install them on the target computers, or distribute and install them in one step. During distribution, the patch binaries are downloaded into the data model, and then the patch binaries and other files (for example cab file, vbscript) are published to a depot server. From the depot server, patches are distributed for installation on target computers. You can distribute patches immediately or schedule this task for a specified date and time. Make sure that your user role is Deployment Specialist or equivalent.
Tip: You can also publish, distribute, and install patches in one step from the Recommendations tab for both the Provisioning Computers and Provisioning Groups. To perform this operation:
946
1. Click Go To > Deployment > Provisioning Computers. or Click Go To > Deployment > Provisioning Groups. 2. Select the group or computer in the list and click it. 3. Select the Recommendations tab. 4. Select one or more patches and click Approve. The recommended actions can now be run or scheduled. The selected patches are published, distributed, and installed. To distribute patches: 1. Click Go To > Deployment > Patch Management > Patch Distribution. Tip: To perform this task from the Start Center, click Patch Distribution under Patch management applications. 2. Click Select Patches and select the patches that you want to distribute, then click OK. Tip: You can filter down the list of displayed patches by patch name, vendor, and version. To search for a particular patch, type the patch name in the Patch field, for example, redhat-release-5Server. If multiple software definitions are available for that patch number, select the check boxes for all the software definitions that match the patch number. The correct patch, based on the operating system on the target computer, is distributed to the appropriate target computer. To use more search fields, expand Advanced Search Options and customize the options in the window, then click Refine. 3. Click Select > Groups and select your group of target computers, then click OK. 4. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 5. Under Notification, specify notification options if you want users to be notified about the task status. 6. Click Submit. 7. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The patch distribution task is displayed with a status of Success on the Provisioning Task Tracking page. Installing patches: After patches are approved, you can install them on the target computers where they are missing. Make sure that your user role is Deployment Specialist or equivalent.
Tip: You can also publish, distribute, and install patches in one step from the Recommendations tab for both the Provisioning Computers and the Provisioning Groups task. To perform this operation: 1. Click Go To > Deployment > Provisioning Computers. or Click Go To > Deployment > Provisioning Groups. 2. Select the group or computer in the list and click it. 3. Select the Recommendations tab. 4. Select one or more patches and click Approve. The recommended actions can now be run or scheduled. The selected patches are published, distributed, and installed. To install patches: 1. Click Go To > Deployment > Provisioning Groups.
947
2. 3. 4. 5. 6.
Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. Click your group of target computers. Click the Recommendations tab. Select all the patches that are approved from the recommendations list and click Implement. Specify the options you want for installing and click Submit. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed.
The patch installation task is displayed with a status of Success on the Provisioning Task Tracking page. Verifying compliance results: After installing patches on the target computers, you can verify that the patches installed successfully. Make sure that your user role is Compliance Analyst or equivalent.
You can verify compliance results either by running the compliance check again and verifying the list of recommendations or by running patch reports that provide information about missing patches. Running the compliance check again: To run the compliance check: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Compliance tab. 4. Click Run > Check to run a compliance check before displaying the recommendations so that the results are accurate. 5. Click the Recommendations tab. 6. In the list of recommendations, verify that the installed patches are no longer displayed as missing. 7. Click OK. Installed patches are no longer listed on the list of recommendations because they are not missing from the target computers.
948
Related information Testing patches on page 942 Approving patches in the data model on page 942 Configuring the YUM scan discovery on page 943 Setting up compliance on page 943 Scanning for missing patches on page 944 Approving compliance recommendations on page 945 Publishing patches to depots on page 945 Distributing patches on page 946 Installing patches on page 947
Managing patches in Red Hat Enterprise Linux 4 environments

The patch management solution for Red Hat Linux environments uses Red Hat Network for Red Hat Enterprise Linux, which is a system management platform for Red Hat Enterprise Linux infrastructures. You receive access to Red Hat Network as part of your subscription to Red Hat Enterprise Linux. Red Hat Network uses a web-based graphical interface, and its services are provided by modules and components that help you to manage your environment. The Red Hat Network Update Agent up2date is included with all subscriptions to Red Hat Enterprise Linux. This agent ensures timely access to the latest available software updates from Red Hat, and provides the tools to download and install the updates on your computers. Using Red Hat Network and the up2date agent, the target computers communicate with the Red Hat Network servers to perform the following operations: v Scan for available updates. v Distribute recommended updates to target computers. v Install approved updates on individual or multiple target computers.
Red Hat Enterprise Linux 4 environments: This topic applies to managing patches in Red Hat Linux 4 environments.

You can manage patches for v Red Hat Enterprise Linux v Red Hat Enterprise Linux v Red Hat Enterprise Linux the following Red Hat Linux operating systems and versions: 4 AS/ES (x86 32-bit) 4 AS/ES (x86 64-bit) 4 AS/ES (IBM System i 32-bit/64-bit)
v Red Hat Enterprise Linux 4 AS/ES (IBM System p 32-bit/64-bit) v Red Hat Enterprise Linux 4 AS/ES (AMD 64-bit)
Components
This patch management solution requires the following Red Hat Linux components: Hosted model The following diagram illustrates the hosted model configuration.
949
Provisioning server
Red Hat Network
Red Hat Linux target computers

Internet
Firewall
RHN proxy (optional)
Firewall
The target computers are connected to Red Hat Network over the Internet, and they exchange packages and information with the Red Hat Network servers. Your environment and system information is stored in the Red Hat Network database. To reduce download times and facilitate distribution, you can use a proxy server to cache packages locally. The target computers are connected to the Red Hat Network server with the Red Hat Network proxy server. Adding a proxy server improves performance on low-bandwidth networks. Satellite model The following diagram illustrates the satellite model configuration.
950
Provisioning server
Red Hat Network
Red Hat Linux target computers

Internet
Firewall
RHN proxy (optional)
Firewall
RHN satellite server
Red Hat CDs
In the satellite model, full Red Hat Network functions is available in your own environment. The satellite server is the only computer that is connected to Red Hat Network over the Internet to download the patches and all target computers are connected to the satellite server. If required, you can take your Red Hat Network solution completely offline using the satellite model. Your environment and system information is stored in a local database repository in your infrastructure. To reduce download times and facilitate distribution, you can use a proxy server to cache packages locally. The target computers are connected to the satellite server using the Red Hat Network proxy server. Adding a proxy server to remote locations with many systems improves scalability and performance.
Requirements
Verify that the following requirements are met depending on configuration: v The Red Hat Network satellite server is a computer that has Red Hat Linux 4 or 5 installed on it and has Internet access. This computer downloads the patches from Red Hat Network over the Internet. v In the configuration where the target computers are connected to Red Hat Network directly, they must have Internet access. In the configuration where a satellite server is present, Internet access for the target computers is not necessary. Additional target computer requirements are listed in the Requirements for Red Hat Linux target computers on page 560 topic. v User roles for patch management are listed in the Patch management basics on page 877 topic.

Set up a number of variables depending on the configuration that you use:
951
v In the satellite model, create a variable named ORG_CA_CERT and set its value to the full path and name of the Red Hat Network RPM used, for example, http://tpmserver.rhn.linux.ibm.com/pub/rhn-orgtrusted-ssl-cert-1.0-5.noarch.rpm. Set up this variable globally (for all computers) or at the group level. v In the satellite model, create a variable named sslCACert and set its value to the full path and name of the organizational certificate that you are using, for example, /usr/share/rhn/RHNS-CA-CERT. v In the satellite model, set up the value for the RHN.SERVER-SATELLITE variable to the fully-qualified name of the Red Hat Network satellite server, for example, xmlrpc.rhn.redhat.com. v If using a proxy server, create a variable named RHN.httpProxy and set its value to the fully-qualified name of the Red Hat Network proxy server. v To specify how long you want to wait when scanning for available patches, create a variable named RHN.timeout and set its value to the timeout, in seconds. This value must be an integer.
Automation packages
The following automation packages are used for Red Hat Linux patch management: v redhat-linux-operating-system v RedHat_EL_Update v For information about the automation packages, search for automation package descriptions in the information center.
Managing patches in SUSE Linux Enterprise Server environments

You can use Tivoli Provisioning Manager to manage patches in SUSE Linux Enterprise Server environments. You can manage patches in SUSE Linux Enterprise Server 11 environments using the scalable distribution infrastructure. You do not use the scalable distribution infrastructure to manage patches in SUSE Linux Enterprise Server 10 environments.
Supported platforms
You can manage patches in SUSE Linux Enterprise Server 11 environments for the following operating systems: v SUSE Linux Enterprise Server Enterprise Server 11 (IBM System z 64-bit) v SUSE Linux Enterprise Server Enterprise Server 11 (x86 32-bit) v SUSE Linux Enterprise Server Enterprise Server 11 (x86 64-bit) You can manage patches in SUSE Linux Enterprise Server 10 environments for the following operating systems: v SUSE Linux Enterprise Server Enterprise Server 10 (x86 32-bit) v SUSE Linux Enterprise Server Enterprise Server 10 (x86 64-bit) v SUSE Linux Enterprise Server Enterprise Server 10 (IBM System z 64-bit)
SUSE Linux Enterprise Server 11 environments

You can manage patches in SUSE Linux Enterprise Server 11 environments using the scalable distribution infrastructure. This section provides information about how to manage patches in SUSE Linux Enterprise Server 11 environments using the scalable distribution infrastructure. It provides information about the patch management process, configuration and topology, and a tutorial that describes how to complete patch management in SUSE Linux Enterprise Server 11 environments using the scalable distribution infrastructure.
952

Supported environments: This topic applies to patch management for SUSE Linux Enterprise Server 11 environments only.
Patch management includes the processes that are illustrated and detailed the information later in this section. Roles for each step in the process are noted in parentheses.
Discover computers
Set up environment
Configure SMT or YUM Repository
Acquire patches
Test patches
Legend
1. Discover computers and set up the environment (Provisioning Administrator) This process consists of the following tasks: v Run initial discovery to discover all computers and to add them to the data model. Initial discovery finds out what operating system is installed on your target computers, which is required to make sure that patches for that operating system are acquired in a later step in the process. As part of initial discovery, group the discovered target computers to manage patches for multiple computers at the same time.
953
Tip: The task of discovering computers can be performed also by the provisioning configuration librarian. v Depending on the configuration used in your organization, you might need to set up a proxy server for connecting the provisioning server and the SMT or YUM server. v Set up the scalable distribution infrastructure to manage distribution and installation of patches on the target computers. Tip: The task of setting up the infrastructure can be performed also by the provisioning configuration librarian. 2. Install required software on target computers (Deployment Specialist) This process consists of installing the common agent on the target computers. The common agent is a software product that is required for software distribution and software compliance management. 3. Acquire patches (Provisioning Configuration Librarian) This process consists of specifying which patches you want to acquire from those released by the vendor, and bringing those patches into the data model. 4. Test patches This process is recommended as part of the patch management life cycle process, to ensure that all possible conflicts have been identified in a test environment before installing the patches in the production environment. You can install the patches in defined test environments using the Patch Installation application, but the actual testing of patches is performed outside the provisioning applications. Therefore, this task does not have a role associated with it. Normally, the test engineer in your organization performs this task. 5. Approve patches (Compliance Analyst) This process consists of approving which patches you want to install. Two levels of approval are required: for the entire organization (at the data model level), and for each target computer or group of target computers, if a patch is missing on a specific group of computers. 6. Set up compliance (Compliance Analyst) This process consists of creating compliance checks to determine if the software installed on the target computers matches your requirements. Compliance checks define the compliant state of your target computers and are used to detect, report, and recommend how to fix noncompliance. Add a patch check to a group of target computers, and, optionally, identify specific patch approval groups to scan. 7. Scan for missing patches (Provisioning Configuration Librarian) This process consists of scanning the target computers and checking to see which patches are missing from the target computers. After the scan, a list of missing patches is generated and then the check creates compliance recommendations for each computer or group. 8. Approve compliance recommendations (Compliance Analyst) This process consists of approving which patches you want to install. You approve patches for each target computer or group of computers, if a patch is missing on the target computers. 9. Install patches and monitor patch installation (Deployment Specialist) This process consists of distributing and installing the patches on target computers. You can distribute and install patches at the same time or schedule these tasks separately. You can install patches on a specific target computer or multiple target computers as one task. You can also monitor the progress of patch installation. 10. Verify compliance results (Compliance Analyst) This process consists of validating that the patches were successfully applied to all the target computers you selected. Run the compliance check again to verify that the installed patches are no longer listed in the list of recommendations.
954
Components for SUSE Linux Enterprise Server 11 environments

To manage patches in SUSE Linux Enterprise Server environments, set up your configuration so that all components work together.
The following diagram illustrates the supported configuration.
Internet
SMT/YUM Repository
Proxy server (optional)
Provisioning server (any supported OS)
You can install any supported operating system on the provisioning server. The provisioning server is connected to the SMT or YUM repository. If the provisioning server and the SMT or YUM repository are separated by a firewall, you must set up a proxy server. The patches are stored on the SMT or YUM repository.
Tutorial: Managing patches in SUSE Linux Enterprise Server 11 environments

This tutorial demonstrates patch management using the scalable distribution infrastructure, on target computers that have SUSE Linux Enterprise Server 11 installed. The scalable distribution infrastructure allows you to manage a large number of target computers in a variety of topologies, and provides a fast and reliable way to scan, distribute, and install patches on target computers that require them.
Learning objectives
In this tutorial you learn how to: v Discover and group target computers.
955
v v v v v
Set up servers, infrastructure, and target computers. Acquire patches. Approve patches. Set up compliance for the target computers. Scan the target computers for missing patches.
v Distribute patches. v Install patches. v Verify compliance results. Allow several hours to discover your target computers, set up the infrastructure, set up the target computers, and install the patches on them. Acquiring the patches from the SMT or YUM repository might take from 30 minutes to a few hours, depending on the number of patches that are available, the connection speed, and the location of the SMT or YUM repository, if local or remote.
Prerequisites
Before you start, verify that you meet the requirements listed in Requirements for SUSE Linux Enterprise Server 11 environments. Modules in this tutorial v Requirements for SUSE Linux Enterprise Server 11 environments v Part 1: Environment setup on page 958 v Part 2: Day-to-day tasks on page 963 Requirements for SUSE Linux Enterprise Server 11 environments: Before you start managing patches in SUSE Linux Enterprise Server 11 environments, ensure that your system meets all of the requirements.
You can manage patches for the following SUSE Linux Enterprise Server operating systems and versions: v SUSE Linux Enterprise Server Enterprise Server 11 (x86 32-bit) v SUSE Linux Enterprise Server Enterprise Server 11 (x86 64-bit) v SUSE Linux Enterprise Server Enterprise Server 11 (IBM System z 64-bit) User roles and requirements: To complete the tasks in patch management, ensure that you have the required knowledge and access permissions to perform your role.
956
Table 171. Roles and skills for patch management in SUSE Linux Enterprise Server environments Role Provisioning Administrator Provisioning tasks v Discover and group target computers v Set up servers and infrastructure Skills v Knowledge of the provisioning environment v Knowledge of the SUSE Linux Enterprise Server operating system v Knowledge of Internet technologies v Knowledge of the scalable distribution infrastructure v Knowledge of how to configure the SMT or YUM repository Provisioning Configuration Librarian v Acquire patches v Scan the target computers for missing patches v Organize and maintain the patch catalog v Create and maintain patch groups, delete patches from the data model Compliance Analyst v Approve patches in the data model v Knowledge of the SUSE Linux Enterprise Server operating system v Set up compliance v Approve compliance recommendations v Verify compliance results Deployment Specialist v Install required software on target computers v Publish patches v Distribute patches v Unpublish patches v Implement compliance recommendations to install missing patches v Monitor patch installation v Knowledge of the SUSE Linux Enterprise Server operating system v Knowledge of the patch management life cycle v Knowledge of the patch management life cycle v Knowledge of the SUSE Linux Enterprise Server operating system v Knowledge of the patch management life cycle
Server requirements: There are a number of requirements that must be met by the components in your configuration so that you can manage patches in SUSE Linux Enterprise Server 11 environments. You must have cURL installed on the provisioning server. cURL is a free URL transfer library and supports several protocols such as FTP, HTTP, HTTPS, and LDAP. Note: For AIX systems, ensure that you use a cURL version with SSL support. You can install cURL from http://curl.haxx.se/. Target computer requirements: There are a number of requirements that must be met by the target computers so that you can manage patches in SUSE Linux Enterprise Server 11 environments.
957
All files required for patch installation on the endpoints are downloaded to the /tmp directory. Ensure that the file system where the directory is located has enough disk space to store at least all the patches you want to install in one installation or remediation task. Part 1: Environment setup: Before starting to manage patches for SUSE Linux Enterprise Server 11 environments, you must set up the servers depending on the configuration that you are using. Also, you must set up the scalable distribution infrastructure and install required software on your target computers.
Discovering and grouping target computers: You must make your target computers known to the data model. To do this, you can run initial discovery, which searches for unknown resources and adds them to the data model. For existing resources, the data model is updated with any new or changed information. You can then group your target computers so that you can manage patches for multiple computers at the same time. Make sure that the following requirements are met: v Your user role is Provisioning Administrator, Provisioning Configuration Librarian, or equivalent. v Your target computers meet the requirements listed in Target computer requirements on page 934.
To discover and group your target computers, perform the following steps. Tip: You can use the Computer Discovery, Common Agent Installation, and Inventory Discovery discovery wizard to run a network discovery of the computers, install the common agent on these computers, and run a hardware and software scan. For more information, see Discovering your environment using the ready-to-use network discoveries on page 231. 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. Tip: To perform this task from the Start Center, click Discovery Configurations under Provisioning administration applications or Discovery and task applications. 2. Find the discovery configuration called Initial Discovery and click its name on the list. 3. Click the IP Address Ranges tab. 4. Click New Row. 5. In the Start and End fields, type the IP addresses of your target computers. After each set of IP addresses, click New Row. Tip: You can also specify subnetworks that you want to discover. If, for example, all the target computers that you want to discover are in a LAN, click the Subnetworks tab and specify the IP address and mask for the LAN. After specifying each subnetwork, click New Row. 6. Click the Credentials tab. 7. Click New Row.
958
8. Type the user name and password. After each set of credentials, click New Row. If you specify more than one set of credentials, those credentials are used on each target computer in the order that they are listed. If the logon attempt on a target computer is successful, the computer is added to the data model. Notes: v The system attempts to connect to each IP address using each user name and password provided until it finds a user name and password that can be used to connect successfully. This might cause user accounts to be locked out, depending on the security policy enforced on the target computers. v You might need to increase the default timeout value if you are on a slow network or you are attempting to discover slow computers. 9. In the Add Computers to Group field, click Select Value the target computer after running initial discovery. Tip: If you want to create a group, see Creating groups. . 10. Click Save 11. Click Run Discovery. 12. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 13. Under Notification, specify notification options if you want users to be notified about the task status. 14. Click Submit. 15. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The discovery task is displayed with a status of Success on the Provisioning Task Tracking page and the discovered computers are recorded in the details of the discovery task. Configuring the SMT or YUM repository: For SUSE Linux Enterprise Server 11 environments, you can use Subscription Management Tool (SMT) or Yellow dog Updater Modified (YUM) as your package management solution. Make sure that your user role is Provisioning Administrator or Provisioning Configuration Librarian.
and select the group in which to add
To define the SMT or YUM repository in the data model: 1. Click Go To > IT Infrastructure > Provisioning Inventory > File Repositories. Tip: To perform this task from the Start Center, click File Repositories under Infrastructure applications. . 2. Click New File Repository 3. In the File Repository field, type the file repository name. 4. In Root Path field, type the root path of the local SMT or YUM repository. The value depends on the configuration of the SMT or YUM repository and on the protocol you use. For example, if the SMT repository is configured as follows: /srv/www/htdocs/repo/$RCE/SLES11-Updates/sle-11-x86_64depending on the protocol you use, the root path is as follows:
959
SSH protocol /srv/www/htdocs/repo/$RCE Note: The SSH protocol is supported only if there is no proxy server between the provisioning server and the SMT repository. FTP protocol /../srv/www/htdocs/repo/$RCE HTTP or HTTPS protocols /repo/$RCE 5. When you select the Is YUM or SMT Repository? check box, additional fields are displayed to specify the SMT or YUM configuration parameters. 6. In the IP Address field, type the IP address of the SMT or YUM repository server. 7. From Protocol menu, select the supported protocol from the list. 8. If you need to change the default port number, which is populated when you select the protocol, type your port number in the Port field. 9. If authentication is required for the SMT or YUM repository, type a user name in the User Name field, a new password in the Password field, and retype it in the Confirm Password field. 10. Click Add Path and specify the information to dynamically configure the repository paths. Enter values in the following fields: a. For the Operating System field, select suse. b. For the Version field, select 11. c. For Edition, select server. d. For the Category field, select os for SLES11-Pool, and updates for SLES11-Updates. e. For Architecture, select your architecture. f. In the Repository Path field, enter the path to the repository. For example, /suse/catalogs/ SLES11-Updates/sle-11-x86_64 11. Click Save .
Based on the information provided, the SMT or YUM repository, data model objects, software module, and credentials are created in the Provisioning Manager data model database to capture the SMT or YUM repository structure. Setting up the proxy server: When the provisioning server and the SMT or YUM repository are separated by a firewall, you must set up a proxy server. Make sure that your user role is Provisioning Administrator or equivalent.
Defining the proxy server: To define the proxy server: 1. Click Go To > Deployment > Provisioning Computers. Tip: To perform this task from the Start Center, click Provisioning Computers under Automation development applications. 2. In the Computer field, type the name of the provisioning server, then click the computer name.
960
3. 4. 5. 6. 7.
Click the Credentials tab. Click Add Credentials > New Service Access Point. Type a name for the service access point. In the Protocol Type field, click Network protocol IP. In the Context field, type URLGrabProxy.
8. In the Application Protocol field, click HTTP Access. 9. Type the port number for the proxy server, for example, 3128. Note: Port 3128 is the default port for most proxy servers. If you are using a different proxy server port in your environment, type that proxy server number. In the Domain field, type the fully qualified host name or IP address of the proxy server. If the proxy server requires authentication, select the Authentication? check box. Otherwise, leave this check box blank. Click New Password Credential. In the Search Key field, type a meaningful string. Type the user name and the password for the proxy server, if required.
10. 11. 12. 13. 14.
. 15. Click Save Related information Configuring the SMT or YUM repository on page 959 Setting up the Infrastructure Installing required software on target computers on page 962 Setting up the Infrastructure: You can set up a region, a zone, and a depot server, which are used to distribute and install the patches on the target computers. Make sure that your user role is Provisioning Administrator or equivalent.
Setting up a region: Regions are used to group depot servers that are located near one another to optimize upload, replication, and download times. When you create a depot server, associate it with a region. You can assign a depot server to only one region. To set up a region: 1. Click Go To > Administration > Provisioning > Dynamic Content Delivery Configuration. Tip: To perform this task from the Start Center, click Dynamic Content Delivery Configuration under Provisioning administration applications. 2. Click the Regions tab. 3. Click New Row. 4. Type a name and a description for the new region. 5. Click Save Setting up a zone:
961
Optionally, you can set up a zone to define an IP address range or a domain name within a region. Regions can be generic, without a real network definition, or they can be specific, when zones are used to define domain names within a region. Zones are used to logically group computers within regions. To 1. 2. 3. set up a zone: On the Dynamic Content Delivery Configuration page, click the Zones tab. Click New Row. Type a name and a description for the new zone.
and click the region that you created in the previous task. 4. In the Regions field, click Select Value 5. Select Domain Name, and then specify the domain that your depot server and target computers are in. 6. Click Save .
Setting up a depot server: A depot server is a system that stores files for distribution. Distribution files are uploaded to a depot server using a client. Uploaded files are stored in a directory that is specified when the depot server is installed. Depot servers can replicate uploaded files to other depot servers to optimize the network traffic. The target computers download the files from the depot servers. To set up a depot server: 1. On the Dynamic Content Delivery Configuration page, click the Depots tab. 2. Click New Row. 3. Type a name and description for the depot server. and click the region that you created in the previous task. 4. In the Region field, click Select Value This is the region that the depot server is assigned to. 5. In the Computer field, click Select Value set up as a depot server. and click the name of the computer that you want to
Note: The depot server must not be included in your group of target computers. 6. In the Fully qualified host name field, type the fully qualified host name of the depot server that has already been discovered. 7. Select the Install the depot agent services check box to install the depot agent services on the depot server. 8. In the Domain Zone Served field, click Select Value previous task. 9. Type the user name and password for the depot server. and select the zone that you set up in the
10. If using only one depot server, select the Preferred upload server check box. At least one preferred depot server is required. . 11. Click Save Related information Configuring the SMT or YUM repository on page 959 Setting up the proxy server on page 960 Installing required software on target computers Installing required software on target computers:
962
Install the common agent on the target computers. The common agent is a software product that is required for software distribution and software compliance management. Make sure that the following requirements are met: v Your user role is Deployment Specialist or equivalent. v The target computers meet the requirements listed in the Target computer requirements on page 934 topic.
Installing the common agent: The common agent is a software product that provides infrastructure for management applications. The common agent installed on the target computers provides remote deployment capability, shared computer resources, secure connectivity, and a single entry point. You install the common agent once on each target computer. After the common agent is installed on a target computer, subsequent subagents can be installed on top of an existing common agent. To install the common agent, complete the following steps: Note: If you used the Computer Discovery, Common Agent Installation, and Inventory Discovery discovery wizard to discover your computers, then the common agent is already installed. Proceed to Acquiring patches on page 941. 1. Click Go To > Deployment > Software Management > Common Agent Installation. 2. Click Select > Groups, and select your group of target computers, and then click OK. 3. 4. 5. 6. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. Under Notification, specify notification options if you want users to be notified about the task status. Click Submit. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed.
The common agent installation task is displayed with a status of Success on the Provisioning Task Tracking page. Related information Configuring the SMT or YUM repository on page 959 Setting up the proxy server on page 960 Setting up the Infrastructure on page 961 Part 2: Day-to-day tasks: After setting up the environment, there are a number of tasks that you must perform as day-to-day patch management activities to ensure that your target computers are always up-to-date with the required patches.
Acquiring patches: Patch acquisition is the process of discovering available patches and importing the patch metadata from the SMT or YUM repository.
963
Make sure that your user role is Provisioning Administrator or Provisioning Configuration Librarian.
Note: When the provisioning server and the SMT or YUM repository are separated by a firewall, you must set up a proxy server. Ensure that the FTP user has the required access permissions to access the SMT or YUM repository. No error is displayed if the FTP user does not have the required access permissions. To acquire patches: 1. Click Go To > IT Infrastructure > Software Catalog > Patch Acquisition. Tip: To perform this task from the Start Center, click Patch Acquisition under Discovery and task applications. 2. In the Operating System list, click Select Value systems. and click Linux from the list of operating and click the name of the SMT or
3. In the YUM or SMT File Repository field, click Select Value YUM repository that you created previously. 4. Select the repository paths.
Note: Any subsequent patch scan, performed either using a compliance check or an SMT or YUM scan discovery, is performed on the patches acquired at patch acquisition time based on this selection. 5. Optional: To approve the acquired patches automatically, in the Initial Patch Status list, click Select and click APPROVED. This option is useful if you want to mark as approved all the Value patches that were made available by the vendor, without having to approve them in a later step. 6. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 7. Under Notification, specify notification options if you want users to be notified about the task status. 8. Click Submit. 9. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The patch acquisition task is displayed with a status of Success on the Provisioning Task Tracking page. The patches are brought into the data model. To view the patches catalog, in the Start Center, click Patches under Favorite applications. Note: After completing the patch acquisition, you can run the compliance scan and check directly if the scan settings required are identical to the settings you used for patch acquisition, for example, if you plan to scan for a certain level of patches on the repository paths defined at acquisition time. If you need to customize the scan for specific levels and architecture, use the SMT or YUM scan to set up specific scan settings, which must be a subset of selections made at acquisition time. Note: deltarpm patches are not included in the patches that are imported. Testing patches: It is recommended to test the released patches before installing them, to ensure that all possible conflicts have been identified in a test environment before installing them in the production environment. You can install the patches on a test computer using the Patch Installation application, but the actual testing of patches is to be performed outside of the provisioning applications.
964
Approving patches in the data model: After patches are acquired, the first step in the approval process is to approve the patches for the entire organization (at the data model level). Only the approved patches are considered when scanning the target computers for missing patches. For example, in some organizations all patches are approved at the data model level and then the compliance analyst decides which patches to approve for each provisioning group. This second step in the approval process is done when scanning for missing patches. In other organizations, there might be some patches that the compliance analyst does not want to approve immediately after acquisition, because further testing is required before approving. Make sure that your user role is Compliance Analyst or equivalent.
To approve the acquired patches in the data model: 1. Click Go To > IT Infrastructure > Software Catalog > Patches. Tip: To perform this task from the Start Center, click Patches under Favorite applications. 2. Press Enter to display all patches from the catalog. Tip: You can filter down the list of displayed patches by patch name, version, severity, vendor, release date, and so on. To search for a particular patch, type the patch name in the Patch field, for example, glibc-devel. To use more search fields, click Advanced Search and customize the options in the window, then click Find. 3. Click Select Records and select the patches that you want to approve, then click Approve. Note: To select records, filter down your list of patches to a maximum of 200. If you want to approve more than 200 patches at the same time, filter down your patches, then click Approve and click OK on the confirmation message. Patches that you have approved are displayed with a status of Approved on the Patches page. Configuring the SMT or YUM repository discovery: Before running the compliance scan, you must configure the SMT or YUM repository in the SLES10 SDI Patch Scan or SLES11 SDI Patch Scan discovery configuration and run the discovery configuration. Make sure that your user role is Provisioning Administrator or Provisioning Configuration Librarian or equivalent. To customize the scanning model: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. Tip: To perform this task from the Start Center, click Discovery Configurations under Automation development applications . 2. Find the SLES10 SDI Patch Scan or SLES11 SDI Patch Scan discovery configuration and click it. 3. Click Select Value for the YUM or SMT File Repository field, and select the repository where the scan is to be performed. 4. In the Select Repository Paths section, select the architecture and level of updates to scan for.
965
5. Click Save . 6. Click Run Discovery. 7. Click Select > Groups and select the check box corresponding to your group of target computers, then click OK. 8. Click Submit. 9. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The discovery task is displayed with a status of Success on the Provisioning Task Tracking page. You can now scan for missing patches. Setting up compliance: You can set up a compliance scan to verify if patches are required on the target computers. Compliance checks define the compliance state of your target computers and are used to detect, report, and recommend how to fix noncompliance. Make sure that your user role is Compliance Analyst or equivalent.
To set up compliance: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Find your group of target computers and click its name in the list. 3. Click the Compliance tab. 4. Click New Compliance Check > Patch Check. 5. In the Patch Approval Group field, click Select Value scanned, then click Save. and select a group of patches to be
Tip: By default, all patches that have been approved in the data model are scanned, and target computers are verified against all approved patches to see if computers are compliant. You can also select a patch approval group, which is used to specify a set of allowed patches, or approval lists. The patch approval group limits the patches for which recommendations are generated to the specified set of patches only. You might want to use this option to tightly control patches for critical computers where more exhaustive testing of patches is needed before they are required to be installed. Do not perform the patch check using a software compliance check of type Software Group associated to the Patch Approval Group. Doing this can cause the following problems: v If a software patch contained in the Patch Approval Group is installed, target computers result as compliant. v The check is performed for the specific software patch installation and disregards any relation between the software patches, for example, superseding patches. v The check is performed on all computers belonging to the group and disregards if the software patch is applicable to only certain platforms. 6. Optional: To automatically approve recommendations when they are generated, click Enable Automatic Approval and click OK in the message box. All recommendations that are generated by this compliance check will be created in the Approved state.
966
7. Click Save
The Operating System Patches and Updates compliance check is displayed in the list of compliance checks defined for the group of target computers. Scanning for missing patches: You can compare the software installed on your target computers with a list of the patches that have been approved for the entire organization, to see which patches are missing on which computers. By default, all patches that have been approved in the data model are scanned, and target computers are verified against all approved patches to see if computers are compliant. You can also select a patch approval group, which is used to specify a set of allowed patches, or approval lists. The patch approval group limits the patches for which recommendations are generated to the specified set of patches only. You might want to use this option to tightly control patches for critical computers where more exhaustive testing of patches is needed before they are required to be installed. Make sure that your user role is Provisioning Configuration Librarian or equivalent.
To scan for missing patches: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Compliance tab. 4. Click Run Scan and Check. Tip: If you want to schedule the task for a later time, click Schedule Scan and Check to specify scheduling options. 5. Click the Notification tab to specify notification options if you want users to be notified about the task status. 6. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. Attention: Wait until the task completes before starting another compliance scan task on the target computers. If you run concurrent compliance scan tasks on a target computer, the tasks might fail. The scanning and checking task is displayed with a status of Success on the Provisioning Task Tracking page. The recommendations to install missing patches are generated. On the Compliance tab for the group, the patch check displays the number of computers that are compliant in the Compliant column, depending on whether all required patches are installed on the target computers. If notification was set up, recipients are notified that recommendations must be approved. If target computers are not compliant, you can see a list of recommendations in the Recommendations tab. Approving compliance recommendations: After scanning your target computers to see which patches are missing on them, compliance recommendations are generated. Based on these recommendations, you can decide which patches you want to install on your target computers. Make sure that your user role is Compliance Analyst or equivalent.
967
To approve compliance recommendations: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Recommendations tab. 4. In the recommendations list, select the check boxes corresponding to the missing patches that you want to approve and click Approve. The selected patches are displayed with a status of Approved on the Recommendations tab. Publishing patches to depots: After patches are approved, you can optionally publish them to the depots, then distribute, and install them on the target computers. During the publishing phase, the patch binaries are downloaded into the data model, and then the patch binaries and other files (for example cab file, vbscript) are published to a depot server. From the depot server, patches are distributed for installation on target computers. You can distribute patches immediately or schedule this task for a specified date and time. Make sure that your user role is Deployment Specialist or equivalent.
Tip: You can also publish, distribute, and install patches in one step from the Recommendations tab for both Provisioning Computers and Provisioning Groups. To perform this operation: 1. Click Go To > Deployment > Provisioning Computers. or Click Go To > Deployment > Provisioning Groups. 2. Select the group or computer in the list and click it. 3. Select the Recommendations tab. 4. Select one or more patches and click Approve. The recommended actions can now be run or scheduled. The selected patches are published, distributed, and installed. To publish patches: 1. Click Go To > Deployment > Patch Management > Patch Publishing. Tip: To perform this task from the Start Center, click Patch Publishing under Patch management applications. 2. Click Select Patches and select the patches that you want to distribute, then click OK. Tip: You can filter down the list of displayed patches by patch name, vendor, and version. To search for a particular patch, type the patch name in the Patch field, for example, glibc-dlevel. If multiple software definitions are available for that patch number, select the check boxes for all the software definitions that match the patch number. The correct patch, based on the operating system on the target computer, are distributed to the appropriate target computer. To use more search fields, expand Advanced Search Options and customize the options in the window, then click Refine.
968
3. 4. 5. 6. 7.
Click Select Depots and select one or more depots, then click OK. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. Under Notification, specify notification options if you want users to be notified about the task status. Click Submit. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed.
The patch distribution task is displayed with a status of Success on the Provisioning Task Tracking page. Distributing patches: After patches are published to depots, you can optionally distribute them first and then install them on the target computers, or distribute and install them in one step. During distribution, the patch binaries are downloaded into the data model, and then the patch binaries and other files (for example cab file, vbscript) are published to a depot server. From the depot server, patches are distributed for installation on target computers. You can distribute patches immediately or schedule this task for a specified date and time. Make sure that your user role is Deployment Specialist or equivalent.
Tip: You can also publish, distribute, and install patches in one step from the Recommendations tab for both the Provisioning Computers and Provisioning Groups. To perform this operation: 1. Click Go To > Deployment > Provisioning Computers. or Click Go To > Deployment > Provisioning Groups. 2. Select the group or computer in the list and click it. 3. Select the Recommendations tab. 4. Select one or more patches and click Approve. You can run the recommended actions now or you can schedule them for later. The selected patches are published, distributed, and installed. To distribute patches: 1. Click Go To > Deployment > Patch Management > Patch Distribution. Tip: To perform this task from the Start Center, click Patch Distribution under Patch management applications. 2. Click Select Patches and select the patches that you want to distribute, then click OK. Tip: You can filter down the list of displayed patches by patch name, vendor, and version. To search for a particular patch, type the patch name in the Patch field, for example, glibc-devel. If multiple software definitions are available for that patch number, select the check boxes for all the software definitions that match the patch number. The correct patch, based on the operating system on the target computer, is distributed to the appropriate target computer. To use more search fields, expand Advanced Search Options and customize the options in the window, then click Refine. 3. Click Select > Groups and select your group of target computers, then click OK. 4. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 5. Under Notification, specify notification options if you want users to be notified about the task status. 6. Click Submit.
969
7. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The patch distribution task is displayed with a status of Success on the Provisioning Task Tracking page. Installing patches: After patches are approved, you can install them on the target computers where they are missing. Make sure that your user role is Deployment Specialist or equivalent.
Tip: You can also publish, distribute, and install patches in one step from the Recommendations tab for both the Provisioning Computers and the Provisioning Groups task. To perform this operation: 1. Click Go To > Deployment > Provisioning Computers. or Click Go To > Deployment > Provisioning Groups. 2. Select the group or computer in the list and click it. 3. Select the Recommendations tab. 4. Select one or more patches and click Approve. You can run the recommended actions now or you can schedule them for later. The selected patches are published, distributed, and installed. To install patches: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. Click your group of target computers. Click the Recommendations tab. Select all the patches that are approved from the recommendations list and click Implement. Specify the options that you want for installing and click Submit.
2. 3. 4. 5.
6. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The patch installation task is displayed with a status of Success on the Provisioning Task Tracking page. Verifying compliance results: After installing patches on the target computers, you can verify that the patches installed successfully. Make sure that your user role is Compliance Analyst or equivalent.
You can verify compliance results either by running the compliance check again and verifying the list of recommendations or by running patch reports that provide information about missing patches. Running the compliance check again:
970
To run the compliance check: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Compliance tab. 4. Click Run > Check to run a compliance check before displaying the recommendations so that the results are accurate. 5. Click the Recommendations tab. 6. In the list of recommendations, verify that the installed patches are no longer displayed as missing. 7. Click OK. Installed patches are no longer listed on the list of recommendations because they are not missing from the target computers. Related information Testing patches on page 964 Approving patches in the data model on page 965 Configuring the SMT or YUM repository discovery on page 965 Setting up compliance on page 966 Scanning for missing patches on page 967 Approving compliance recommendations on page 967 Publishing patches to depots on page 968 Distributing patches on page 969 Installing patches on page 970 Acquiring patches on page 963
SUSE Linux Enterprise Server 10 environments

The patch management solution for SUSE Linux Enterprise Server 10 environments uses the rug command-line tool, which is provided with SUSE Linux Enterprise Server 10 operating systems.

You can manage patches for the following SUSE Linux Enterprise Server operating systems and versions: v SUSE Linux Enterprise Server Enterprise Server 10 (x86 32-bit) v SUSE Linux Enterprise Server Enterprise Server 10 (x86 64-bit) v SUSE Linux Enterprise Server Enterprise Server 10 (IBM System z 64-bit)
Supported configurations
This patch management solution supports the following configurations. SUSE Linux patch server (ZENworks or YUP) model The following diagram illustrates the SUSE Linux patch server model.
971
Provisioning server
SUSE Linux target computers
SUSE Linux patch server (ZENworks or YUP)
SUSE Linux update site

Internet
The target computers retrieve the patches from a patch server (ZENworks or YUP). The patch server is used as a patch repository for the patches downloaded from the SUSE Linux update site over the Internet. The SUSE Linux patch server communicates directly with the target computers. Optionally, you can use a proxy server to provide Internet access to the patch server. SUSE Linux update site model The following diagram illustrates the SUSE Linux update site model.
Provisioning server
SUSE Linux target computers
SUSE Linux update site

Internet
The target computers are connected to the SUSE Linux update site over the Internet to download the patches. Optionally, you can use a proxy server to provide Internet access to the target computers.
Requirements
Verify that the following requirements are met depending on configuration: v The ZENworks server is a computer that has SUSE Linux 10 or SUSE Linux 10 SP1 and ZENworks Linux Management 7.2 installed, and has Internet access. This computer is used as a patch repository
972
for the patches downloaded from the SUSE Linux update site over the Internet. The system administrator must ensure that the latest patches exist on the ZENworks patch server. This is a manual process performed outside of the provisioning server. v The YUP server is a computer that has SUSE Linux 10 or SUSE Linux 10 SP1 and the Yum Update Proxy (YUP) package installed, and has Internet access. This computer is used as a patch repository for the patches downloaded from the SUSE Linux update site over the Internet. The system administrator must ensure that the latest patches exist on the YUP patch server. This is a manual process performed outside of the provisioning server. v The target computers have SUSE Linux 10 installed. In the configuration where the target computers are connected to the SUSE Linux update site directly, they must have Internet access. In the configuration where a patch server is present, Internet access for the target computers is not necessary. For additional requirements for the SUSE Linux target computers, see the Requirements for SUSE Linux Enterprise Server (SLES) target computers on page 561 topic. v User roles for patch management are listed in the Patch management basics on page 877 topic. Note: Do not add any target computer to more than one SUSE Linux Enterprise Server 10 patch management group because the property defined on first patch management group is used for patch management on the target computer.

Depending on the configuration that you use, set up a number of variables at the system level: v Set the value for the SUSELinux.Catalog.Name variable to a unique catalog name, for example, SLES10-Updates. v If connecting to the SUSE Linux update site directly, set the value for the SUSELinux.Update.Server.url variable to the IP address of the SLES Linux Update site, for example, ftp://ftp.suse.com/pub/suse/ update/10.1. Set the value for the SUSELinux.Service.Type variable to zypp. Note: The site specified for the SUSELinux.Update.Server.url variable might change over time. In this case, try and connect to the Novell Web site for mirror sites (http://www.novell.com/products/ opensuse/downloads/ftp/int_mirrors.html), or contact your SUSE Linux representative. v If using a ZENworks server, set the value for the SUSELinux.Update.Server.url to the IP address of the ZENworks patch server in the format https://<IP_address_zen>, for example, https://10.77.88.15/. Set the value for the SUSELinux.Service.Type variable to zenworks. v If using a YUP server, set the value for the SUSELinux.Update.Server.url to the IP address of the YUP patch server in the format ftp://<IP_address_YUP>/SLES10-YUP/<product>/<architecture>, for example, ftp://10.77.88.42/SLE10-YUP/SLES10/i586. Set the value for the SUSELinux.Service.Type variable to yum. v If using an FTP or HTTP proxy server, create a variable named SUSELinux.proxy.server and set its value to the host name of the proxy server. Either run initial discovery to add the proxy server to the data model or add it manually. Also, define a service access point (SAP) of type http, https, or ftp, depending on the proxy server configuration in the organization. The SAP must have password credentials defined and the Context field set to Proxy Server Connection. Tip: If you have a configuration where different groups of target computers use different methods to retrieve the patches, you need to set up variables per group to specify each download method. For example, a group of target computers might be connected directly to the SUSE Linux update site, a group of target computers might use a ZENworks patch server to retrieve the patches, and a group of target computers might use a YUP patch server to download the patches. In this configuration, must set up the variables for patch management at the group level, not at the system level.
973
Automation packages
The following automation packages are used for SUSE Linux patch management: v sles-operating-system v suse_patch For information about the automation packages, search for automation package descriptions in the information center.
Managing patches in Solaris environments

You can use Tivoli Provisioning Manager to manage patches in Solaris environments using Sun Update Connection (smpatch). Tivoli Provisioning Manager also supports patch management in Solaris Zone environments.

You can manage patches for the following Solaris operating systems and versions: v Solaris 10 (AMD 64-bit) v Solaris 10 (x86 64-bit) v Solaris 10 (Sun SPARC) v Solaris 9 (Sun SPARC) v Solaris 8 (Sun SPARC)
Solaris Zone environments

You can manage patches for Solaris Zone environments if your Solaris Zone environment is Solaris version 10 global zone. Your non-global zones can be Solaris versions 8, 9, or 10. The process for managing patches in a Solaris Zone environment is similar to the process for managing patches using Sun Update Connection in a Solaris environment. However, there is no support for a HTTP proxy server or Sun proxy server for the Solaris non-global zones. To complete patch management on Solaris, the smpatch command is used. The smpatch command is not supported on Solaris non-global zones. You can use the tutorial that describes how to manage patches using Sun Update Connection (smpatch) to manage patches in a Solaris Zone environment. However, as noted above, there is no support for a HTTP proxy server or Sun proxy server on Solaris non-global zones.
The Sun Update Connection solution using smpatch

You can use the Sun Update Connection solution using smpatch to manage patches in the following Solaris environments: v Solaris 10 (AMD 64-bit) v v v v Solaris Solaris Solaris Solaris 10 (x86 64-bit) 10 (Sun SPARC) 9 (Sun SPARC) 8 (Sun SPARC)
The Sun Update Connection Enterprise solution

You can use the Sun Update Connection Enterprise solution to manage patches in the following Solaris environments: v Solaris 10 (AMD 64-bit) v Solaris 10 (x86 64-bit)
974
v Solaris 10 (Sun SPARC) v Solaris 9 (Sun SPARC)
Solaris environments using Sun Update Connection

You can use Sun Update Connection (smpatch) to manage patches in Solaris versions 8, 9, and 10 environments. This section provides information about how to manage patches in Solaris environments using Sun Update Connection. It outlines the patch management process and provides a tutorial on how to manage patches using Sun Update Connection. You can manage both regular patches and patches that require single user mode. Sun Update Connection is available to all registered users of the Solaris 10 operating system. Using Sun Update Connection, systems are periodically checked to compare software release levels against available updates. When applicable updates are made available, notifications are sent out so that the recommended updates can be installed. When managing multiple systems, it considerably reduces the amount of time spent on manual processes such as monitoring software release levels, searching for software updates, and selecting the target computers that require the updates.
Requirements
Verify that the following requirements are met: v You must have a valid Sun Online account to use Sun Update Connection. To sign up for a Sun Online account, go to the Sun Developer Network. Register each target computer with the Sun Update Connection. v The target computer requirements are listed in the Requirements for Solaris Operating Environment target computers on page 563 topic. v User roles for patch management are listed in the Patch management basics on page 877 topic.

Set up a number of variables depending on the configuration that you use: v If you want to use a URL for the Sun patch server that is different from the default value https://getupdates1.sun.com, create a variable named Sun.patchpro.patch.source and set its value to this URL. This variable associates the target computers with the Sun patch server. v If the URL of your Sun patch server requires a relative path, create a variable named Sun.patch.source.relativepath and set its value to the relative path. For example, if the URL of your Sun patch server is https://getupdates1.sun.com/solaris, type /solaris. v If using an HTTP proxy server, create a variable named Sun.patchpro.proxy.host and set its value to the host name of the HTTP proxy server, in the format http://local_httproxy_updates. This variable associates the target computers with the HTTP proxy server.
Automation packages
The following automation packages are used for Solaris patch management: v Sun_Update_Connection for the Sun Update Connection solution For information about the automation packages, search for automation package descriptions in the information center.

It is important to understand the overall patch management process before you start to manage patches using the provisioning applications. Patch management includes the processes that are illustrated and described later in this section. Roles for each step in the process are noted in parentheses.
975
1. Discover computers and set up the environment (Provisioning Administrator) This process consists of running initial discovery to discover all computers and to add them to the data model. Initial discovery identifies what operating system is installed on your target computers. This information is required to make sure that patches for that operating system are acquired in a later step in the process. As part of initial discovery, group the discovered target computers to manage patches for multiple computers at the same time. Tip: The task of discovering computers can be performed also by the provisioning configuration librarian. 2. Optional: Install required software on target computers (Deployment Specialist) This process consists of installing the common agent on the target computers. The common agent is a software product that is required for software distribution and software compliance management. 3. Set up compliance (Compliance Analyst) This process consists of creating compliance checks to determine if the software installed on the target computers matches your requirements. Compliance checks define the compliant state of your target computers and are used to detect, report, and recommend how to fix noncompliance. Add a patch check to a group of target computers, and, optionally, identify specific patch approval groups to scan. 4. Scan for missing patches (Provisioning Configuration Librarian) This process consists of scanning the target computers and checking to see which patches are missing from the target computers. After the scan, a list of missing patches is generated and then the check creates compliance recommendations for each computer or group. 5. Approve compliance recommendations (Compliance Analyst) This process consists of approving which patches you want to install. You approve patches for each target computer or group of computers, if a patch is missing on the target computers. 6. Install patches and monitor patch installation (Deployment Specialist) This process consists of distributing and installing the patches on target computers. You can distribute and install patches at the same time or schedule these tasks separately. You can install patches on a specific target computer or multiple target computers as one task. You can also monitor the progress of patch installation. 7. Verify compliance results (Compliance Analyst) This process consists of validating that the patches were successfully applied to all the target computers you selected. Run the compliance check again to verify that the installed patches are no longer listed in the list of recommendations.
Components for Solaris environments

To manage patches in Solaris environments, set up your configuration so that all components work together. The following diagram illustrates the supported configuration.
976
Provisioning server
Sun Update Connection
Solaris target computers

Internet
Sun proxy (optional)
Firewall
HTTP proxy (optional)
Firewall
Note: The configuration displayed in this diagram is not applicable for patch management for Solaris non-global zone environments. Sun proxy server In environments where the Solaris computers are not connected directly to Sun Update Connection over the Internet, a Sun proxy server is used. This server acts as a gateway between the target computers and Sun Update Connection. In this configuration, the Sun proxy server is the only computer that connects to Sun Update Connection over the Internet to download the patches. All the target computers are connected to the Sun proxy server, and are configured to use the Sun proxy server as their only patch source. All the patch requests originating from the target computers are directed to the Sun proxy server. If a patch is not found in the local cache, the Sun proxy server retrieves it from Sun Update Connection, stores it in its cache for future references, and then distributes it to the target computer that issued the request. HTTP proxy server The target computers can either be connected directly to Sun Update Connection or to a Sun proxy server to retrieve the patches. Optionally, you can use an HTTP proxy server to provide Internet access to the Sun proxy server.
Tutorial: Managing patches in Solaris environments using Sun Update Connection

This tutorial demonstrates patch management using Sun Update Connection and smpatch on target computers that have Solaris versions 8, 9, or 10 installed. You can also use this tutorial as a reference if you are managing patches in a Solaris Zone environment and your non-global zones are Solaris versions 8, 9, or 10. However, your global zone must be Solaris version 10.
Learning objectives
In this tutorial, you learn how to: v Discover and group target computers. v Set up servers and target computers. v Set up compliance for the target computers.
977
v v v v
Scan the target computers for missing patches. Approving compliance recommendations Install patches. Verify compliance results.
Allow several hours to discover your target computers, set up the infrastructure, set up the target computers, and install the patches on them.
Prerequisites
Before you start, verify that you meet the requirements. Modules in this tutorial v Requirements for Solaris v Part 1: Environment setup on page 979 v Part 2: Day-to-day tasks on page 981 Requirements for Solaris: Before you start managing patches in Solaris environments, ensure that your systems meet all requirements. You can manage patches for the following Solaris operating systems and versions using Sun Update Connection (smpatch): v Solaris 10 (AMD 64-bit) v Solaris 10 (Sun SPARC) v Solaris 10 (x86 64-bit) v Solaris 9 (Sun SPARC) v Solaris 8 (Sun SPARC) User roles and requirements: To perform the tasks in patch management, ensure that you have the required knowledge and access permissions to perform your role.
Table 172. Roles and skills for patch management in Solaris environments Role Provisioning Administrator Provisioning tasks v Discover and group target computers v Set up servers and infrastructure Skills v Knowledge of the provisioning environment v Knowledge of the Solaris operating system v Knowledge of Internet technologies Provisioning Configuration Librarian v Scan the target computers for missing patches v Organize and maintain the patch catalog v Create and maintain patch groups, delete patches from the data model v Knowledge of the Solaris operating system v Knowledge of the patch management life cycle
978
Table 172. Roles and skills for patch management in Solaris environments (continued) Role Compliance Analyst Provisioning tasks v Set up compliance v Approve compliance recommendations v Verify compliance results Deployment Specialist v Install required software on target computers Skills v Knowledge of the Solaris operating system v Knowledge of the patch management life cycle v Knowledge of the Solaris operating system
v Implement compliance v Knowledge of the patch recommendations to install missing management life cycle patches v Monitor patch installation v Uninstall patches
Server requirements: There are a number of requirements that must be met by the components in your configuration so that you can manage patches in Solaris environments. There are no specific requirements for the provisioning server for patch management in Solaris environments. Target computer requirements: There are a number of requirements that must be met by the target computers so that you can manage patches in Solaris environments. All files required for patch installation on the target computers are downloaded to the /tmp directory. Ensure that the file system where the directory is located has enough disk space to store at least all the patches you want to install in one installation or remediation task. All target computers must have access to the Internet. Additionally, all target computers must have wget installed and available. wget is normally available on Solaris by default. Part 1: Environment setup: Before starting to manage patches for Solaris environments, you must complete some setup tasks. You need to discover your Solaris target computers and you need to add the Sun Update Connection to the data model. Discovering the Solaris target computers: You must make your Solaris target computers known to the data model. To do this, you can run discovery, which searches for unknown resources and adds them to the data model. For existing resources, the data model is updated with any new or changed information. Make sure that the following requirements are met: v Your user role is Provisioning Administrator, Provisioning Configuration Librarian, or equivalent. 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. Tip: To perform this task from the Start Center, click Discovery Configurations under Provisioning administration applications or Discovery and task applications. 2. Find the discovery configuration called Initial Discovery and click its name on the list.
979
3. Click the IP Address Ranges tab. 4. Click New Row. 5. In the Start and End fields, type the IP addresses of your target computers. After each set of IP addresses, click New Row. Tip: You can also specify subnetworks that you want to discover. If, for example, all the target computers that you want to discover are in a LAN, click the Subnetworks tab and specify the IP address and mask for the LAN. After specifying each subnetwork, click New Row. 6. Click the Credentials tab. 7. Click New Row. 8. Type the user name and password. After each set of credentials, click New Row. If you specify more than one set of credentials, those credentials are used on each target computer in the order that they are listed. If the logon attempt on a target computer is successful, the computer is added to the data model. Notes: v The system attempts to connect to each IP address using each user name and password provided until it finds a user name and password that can be used to connect successfully. This might cause user accounts to be locked out, depending on the security policy enforced on the target computers. v You might need to increase the default timeout value if you are on a slow network or you are attempting to discover slow computers. 9. In the Add Computers to Group field, click Select Value the target computer after running initial discovery. Tip: If you want to create a group, see Creating groups. . 10. Click Save 11. Click Run Discovery. 12. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 13. Under Notification, specify notification options if you want users to be notified about the task status. 14. Click Submit. 15. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The discovery task is displayed with a status of Success on the Discovery Configurations page and the discovered computers are recorded in the details of the discovery task. Adding Sun Update Connection to the data model: You need to add Sun Update Connection to the data model. This is necessary to ensure that you receive the latest patches for your Solaris target computers. Make sure that the following requirements are met: v Your user role is Provisioning Administrator, Provisioning Configuration Librarian, or equivalent. v You require a Sun Online Account with user name and password credentials. To add the Sun Update Manager to the data model, complete the following steps: 1. Click Go To > Deployment > Provisioning Computers. 2. From the Select Action menu, click Add Computer. 3. In the Computer field on the Computer tab, type getupdates1.sun.com. and select the group in which to add
980
4. 5. 6. 7. 8.
Click the Hardware tab and click the Network Interface subtab. Click New Network Interface. Select the Dynamic check box. Click the Credentials tab. Click Add Credentials > New Service Access Point.
9. Complete the following steps on the Details subtab: v In the Service Access Point field, type the name of the service access point. v From the Protocol Type menu, select Network protocol IP. v In the Context field, type Sun Update Connection. v From the Application Protocol menu, select HTTP Secure Access. v In the Port field, type 443. 10. Click New Password Credentials. You need a Sun Online Account to complete this section. Type your Sun account details in the Password Credentials section of the screen. 11. Click the Save icon to save your settings. The task is displayed with a status of Success on the Provisioning Computer page. If you are planning to use a HTTP proxy server, you can proceed to set up the proxy server now. For information about how to set up the HTTP proxy server on Solaris, see ../../com.ibm.tivoli.tpm.apk.doc/ Sun_Update_Connection_package.html Part 2: Day-to-day tasks: After setting up the environment, there are a number of tasks that you must perform as day-to-day patch management activities to ensure that your target computers are always up-to-date with the required patches. Setting up compliance: You can set up a compliance check to verify if patches are required on the target computers. Compliance checks define the compliance state of your target computers and are used to detect, report, and recommend how to fix noncompliance. Make sure that your user role is Compliance Analyst or equivalent. To set up compliance: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Find your group of target computers and click its name in the list. 3. Click the Compliance tab. 4. Click New Compliance Check > Patch Check. 5. In the Patch Approval Group field, click Select Value scanned, then click Save. and select a group of patches to be
Tip: By default, all patches that have been approved in the data model are scanned, and target computers are verified against all approved patches to see if computers are compliant. You can also select a patch approval group, which is used to specify a set of allowed patches, or approval lists. The patch approval group limits the patches for which recommendations are generated to the specified set
981
of patches only. You might want to use this option to tightly control patches for critical computers where more exhaustive testing of patches is needed before they are required to be installed. Do not perform the patch check using a software compliance check of type Software Group associated to the Patch Approval Group. Doing this can cause the following problems: v If a software patch contained in the Patch Approval Group is installed, target computers result as compliant. v The check is performed for the specific software patch installation and disregards any relation between the software patches, for example, superseding patches. v The check is performed on all computers belonging to the group and disregards if the software patch is applicable to only some platforms. 6. Optional: To automatically approve recommendations when they are generated, click Enable Automatic Approval and click OK in the message box. All recommendations that are generated by this compliance check will be created in the Approved state. 7. Click Save .
The Operating System Patches and Updates compliance check is displayed in the list of compliance checks defined for the group of target computers. Scanning for missing patches: You can compare the software installed on your target computers with a list of the patches that have been approved for the entire organization to determine which patches are missing on which computers. By default, all patches that have been approved in the data model are scanned, and target computers are verified against all approved patches to see if computers are compliant. You can also select a patch approval group, which is used to specify a set of allowed patches, or approval lists. The patch approval group limits the patches for which recommendations are generated to the specified set of patches only. You might want to use this option to tightly control patches for critical computers where more exhaustive testing of patches is needed before they are required to be installed. Make sure that your user role is Provisioning Configuration Librarian or equivalent. To scan for missing patches: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Compliance tab. 4. Click Run Scan and Check. Tip: If you want to schedule the task for a later time, click Schedule Scan and Check to specify scheduling options. 5. Click the Notification tab to specify notification options if you want users to be notified about the task status. 6. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. Attention: Wait until the task completes before starting another compliance scan task on the target computers. If you run concurrent compliance scan tasks on a target computer, the tasks might fail. The scanning and checking task is displayed with a status of Success on the Provisioning Task Tracking page. The recommendations to install missing patches are generated. On the Compliance tab for the group, the patch check displays the number of computers that are compliant in the Compliant column,
982
depending on whether all required patches are installed on the target computers. If notification was set up, recipients are notified that recommendations must be approved. Approving compliance recommendations: After scanning your target computers to see which patches are missing on them, compliance recommendations are generated. Based on these recommendations, you can decide which patches you want to install on your target computers. Make sure that your user role is Compliance Analyst or equivalent. To approve compliance recommendations: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Recommendations tab. 4. In the recommendations list, select the check boxes corresponding to the missing patches that you want to approve and click Approve. The selected patches are displayed with a status of Approved on the Recommendations tab. Installing patches: After patches are approved, you can install them on the target computers on which they are missing. Make sure that your user role is Deployment Specialist or equivalent. To install patches: 1. Click Go To > Deployment > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Recommendations tab. 4. Select all the patches that are approved from the recommendations list and click Implement. 5. Specify the options that you want for installing and click Submit. 6. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed. The patch installation task is displayed with a status of Success on the Provisioning Task Tracking page. Verifying compliance results: After installing patches on target computers, you can verify that the patches installed successfully. Make sure that your user role is Compliance Analyst or equivalent. You can verify compliance results either by running the compliance check again and verifying the list of recommendations or by running patch reports that provide information about missing patches. Running the compliance check again:
983
To run the compliance check: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Groups. Tip: To perform this task from the Start Center, click Provisioning Groups under Provisioning administration applications. 2. Click your group of target computers. 3. Click the Compliance tab. 4. Click Run > Check to run a compliance check before displaying the recommendations so that the results are accurate. 5. Click the Recommendations tab. 6. In the list of recommendations, verify that the installed patches are no longer displayed as missing. 7. Click OK. Installed patches are no longer listed on the list of recommendations because they are not missing from the target computers. Related information Scanning for missing patches on page 982 Approving compliance recommendations on page 983 Installing patches on page 983 Setting up compliance on page 981
Using Sun Update Connection Enterprise to manage patches in Solaris environments

You can use Sun Update Connection Enterprise to manage patches in Solaris environments.

You can manage patches for the following Solaris operating systems and versions: v Solaris 10 (AMD 64-bit) v Solaris 10 (x86 64-bit) v Solaris 10 (Sun SPARC) v Solaris 9 (Sun SPARC)
Sun Update Connection Enterprise

Sun Update Connection Enterprise is a software application that allows you to manage the complete life cycle deployment for software in Solaris and Linux environments. To use the patch management solution with Sun Update Connection Enterprise, install and configure a system dependency server in your environment. For information about how to use Sun Update Connection Enterprise support with the provisioning server, see the documentation for the Sun_Update_Connection_Enterprise automation package, which is available from the Web interface. To view the automation package documentation: 1. Click Go To > Administration > Provisioning > Device Drivers. 2. In the Device Drivers list, type Sun_UCE* to display all device drivers that are related to Sun Update Connection Enterprise support. 3. In the list, click any device driver. 4. Click the Documentation link.
984
Automation packages
The following automation packages are used for Solaris patch management: v Sun_Update_Connection_Enterprise for the Sun Update Connection Enterprise solution For information about the automation packages, search for automation package descriptions in the information center.
Registering a group of computers with Sun Update Connection

If v v v managing patches in a Solaris environment in the following configuration: The target computers do not have a support contract from Sun There is no local patch server and no update connection proxy server There is no Sun subscription and the target computers do not require Sun authentication.
v The patch scan, download, and installation is done directly from getupdates1.sun.com. To 1. 2. 3. register one target computer only: Click Go To > Administration > Provisioning > Provisioning Workflows. Find the workflow called Sun_Update_Connection_Register and click Run Type the device ID for the target computer and click Run.
To register a group of computers: 1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. . 2. Click New 3. Type a name for the provisioning task and select Provisioning Workflow for the type. 4. In the Provisioning Workflow field, click Select Value Sun_Update_Connection_Register. 5. In the Target Parameter field, click Select Value 6. Leave the Default Value field empty. and click
and click DeviceID.
. 7. Click Save 8. From the Select Action menu, click Run Provisioning Task. 9. Under Targets, click Select > Groups and select the group name, then click OK. 10. Click Submit.
Managing patches in HP-UX environments

The patch management solution for HP-UX environments uses Software Distributor (SD-UX), which automates the software and security update process for HP-UX 11i systems, and HP-UX Software Assistant (SWA). SWA simplifies patch and security bulletin management on HP-UX systems. The SWA tool supersedes the now obsolete Security Patch Check (SPC), and is the HP-recommended utility for maintaining consistency with HP-published security bulletins and recommended patch levels for HP-UX software.

You can manage patches for the following HP-UX operating systems and versions: v HP-UX 11i v3 (Itanium) v HP-UX 11i v2 (Itanium)
985
v HP-UX 11i v1 (PA-RISC)
Components
This patch management solution requires the following HP-UX components: SD-UX server The SD-UX server is an HP-UX 11i server where Software Distributor (SD-UX) is installed for managing patches. All released patches are downloaded from the IT Resource Center site and stored on the SD-UX server. This server also hosts a depot containing Software Assistant and Perl with the related dependencies, to be installed on the endpoints. This server must have enough disk space to create a patch depot at run time. The patch depot is required when installing patches on endpoints. The disk space can vary based on the site requirements and the number of patches stored on the SD-UX server. To store all patches from IT Resource Center site and to hold the temporary depot, 25+ GB disk space is sufficient. You can optionally use an FTP proxy to download patches.
HP IT Resource Center
Provisioning server
HP-UX target computers

Internet
SD-UX server
FTP proxy (optional)
FTP proxy server Optionally, you can use an FTP proxy server to provide Internet access to the SD-UX server.
Requirements
Verify that the following requirements are met: v The SD-UX server is an HP-UX computer with Ignite-UX, Software Distributor (SD-UX), and openSSH 4.4 or higher installed. This computer must run HP-UX 11i and must have Internet access to download the Security Catalog and patches from the HP ITRC (IT Resource Center) server or from an FTP Web site. Optionally, wget installed if using this tool to create the FTP mirror. The SD-UX server must have SSH service access points enabled so that the HP-UX target computers can access it. Patches are manually downloaded and stored on this server. v The target computer requirements are listed in the Requirements for HP-UX target computers on page 565 topic. v User roles for patch management are listed in the Patch management basics on page 877 topic.
986
Setting up the SD-UX server

Set up the SD-UX server, download the SWA catalog, create an ITRC patch mirror, and add Software Assistant and Perl to the tools depot. To download the SWA catalog, you need to: 1. If the SD-UX server connects to Internet with a FTP proxy, export the ftp_proxy variable with the following command: export ftp_proxy=http://<user>:<password>@<host>:<port> 2. Download the SWA catalog using following command: wget -P <patches_dir> -nd --mirror --proxy=on ftp://ftp.itrc.hp.com/export/patches/ swa_catalog.xml.gz 3. Extract the swa_catalog.xml.gz file with the following command: cd <patches_dir> gunzip swa_catalog.xml.gz To optionally download the HP Security Catalog, you need to perform the following steps. The HP Security Catalog is required for endpoints using Security Patch Check. 1. Download the HP Security Catalog with the following command: wget -P <patches_dir> -nd --mirror --proxy=on ftp://ftp.itrc.hp.com/export/patches/ security_catalog2.gz 2. Extract the Security Catalog with the following command: cd <patches_dir> gunzip security_catalog2.gz To create an HP ITRC patch mirror using the wget command, you need to do this: 1. Extract the patch URLs with the following commands: wget -P <patches_dir> -nH --cut-dirs=3 --proxy=on ftp://ftp.itrc.hp.com/hp-ux_patches/ s700_800/11.X/catalog cd <patches_dir> grep "Patch Name: \/" catalog | sed -e s/Patch Name: /ftp:\/\/ftp.itrc.hp.com/g > patches.txt wget --timestamping --proxy=on -i patches.txt 2. Download the patches with the following command: wget -P <patches_dir> -nd --mirror ftp://ftp.itrc.hp.com/hp-ux_patches/s700_800/11.X, where patches_dir is the directory where the patches are downloaded. To add HP-UX Software Assistant to the tools depot on the SD-UX server, you need to do this: 1. Go to the HP Web site to download HP-UX Software Assistant, version C.01.04 or later. 2. Download SWA to a temporary location on the SD-UX server. 3. Copy the downloaded depot file to the tools depot directory with the following command: swcopy -s /opt/sd-ux/HP-UX_11iv1_SwAssistant_C.01.04_HP-UXiv1_32_64.depot -x enforce_dependencies=false \* @<depot_dir> 4. Also add required SWA depots, depending on the architecture and operating system version of the machines available in your environment. 5. Add all the dependencies of SWA to the depot, unless all dependencies are satisfied by the target To add Perl to a software depot on the SD-UX server, you need to do this: 1. Go to the HP Web site to download the Perl product for your platform. 2. Run the following command: swcopy -s /opt/sd-ux/perl_D.5.8.8.A_HP-UX_B.11.11_32_64.depot -x enforce_dependencies=false \* @<depot_dir>, where depot_dir is the directory for the depot.
987
3. Add all the dependencies of Perl to depot, unless all dependencies are satisfied by the target.
Configuring Tivoli Provisioning Manager

Set up a file repository for the SD-UX server so that you can store the files that you want to install or run on the target computers. To do this, you need to: 1. Click Go To > IT Infrastructure > Provisioning Inventory > File Repositories. 2. Search for the HP SD-UX Server file repository and click its name on the list. 3. Click New NIC Resource. 4. Click the Network Interface tab and click New Network Interface. 5. Type a name for the network interface and the IP Address for the SD-UX Server. 6. Select the Management check box. 7. In the Subnetwork list, click the Select Value icon, then click a subnetwork.
. 8. Click Save 9. Click the Variables tab and set up the following variables: v Patches Mirror Path to the directory used to download the patches, for example, opt/sd-ux. v Patches Temp Depot to the directory where temporary SD-UX depots will be created, for example, opt/sd-ux/depots. Note: These paths are relative to the Root Path defined for the file repository in the File Repository tab. 10. Click the Credentials tab and expand SSH Server. 11. Click New Password Credential and type the user name and password for a super user that has access to the SD-UX server. 12. Click Save .
First add HP-UX Software Assistant and Perl to a software depot on the SD-UX server using the swcopy command. After that, verify that the HP-UX Software Assistant and Perl software definitions are set up properly and that they match the depot configuration from the SD-UX server. To do this, you need to complete the following: 1. Click Go To > IT Infrastructure > Software Catalog > Software Products. 2. Search for the HP-UX Software Assistant software definition and click its name on the list. 3. From the Software Installables section on the Software Definition tab, click HP-UX Software Assistant. 4. Verify that Package Path is set to the directory depot that you created using the swcopy command. If, for example, your directory depot was /opt/sd-ux/tools, then Package Path must be set to opt/sd-ux/tools, which is relative to the Root Path of the HP SD-UX Server file repository. 5. Verify that File Repository is set to HP SD-UX Server. 6. Repeat steps 2 to 5 to verify that the Perl software definition is set up properly.
Automation packages
The following automation packages are used for HP-UX patch management: v HP-UX v HP_UX_SD_Patches For information about the automation packages, search for automation package descriptions in the information center.
988
The automation packages can use both Security Patch Check and Software Assistant.
Troubleshooting SDI Windows patch management

When you run Windows patch management using scalable distribution infrastructure, there are multiple product components that handle the patch management task. To identify the source of a patch management problem, it is important to understand the components that process Windows patch management tasks using scalable distribution infrastructure. Use the information in the Process section to learn about the main steps that occur during patch management. Use the remaining sections to find out how to troubleshoot errors that occur during specific parts of the process. Note: These instructions only apply to Windows patch management when using SDI methodology. v Process v 1. Task status v 2. Publish status on page 991 v 3. Job status on page 991 v 4. Target status on page 992 v 5. Results on page 992
Process
To demonstrate how components interact, the following steps outline the component interactions during a Windows patch installation in an environment that uses the scalable distribution infrastructure. 1. The task is submitted and activity plan engine starts task execution. 2. The patch files are published to the depot. 3. The job is submitted to device manager. 4. The target computer polls device manager for the job, and runs the following items: a. The patch files are downloaded from depot. b. The patch installation runs on the computer. c. The results of the patch installation are uploaded to the provisioning server queue. 5. The discovery engine worker processes the results, picking up the results from the queue. If an error occurs during discovery: 1. Verify that all requirements for discovery were met as described in the following topics: v v v v v
Windows AIX Solaris Red Hat
Requirements for Windows on page 895 Requirements for AIX on page 918 See Requirements in the Requirements for Solaris on page 978 topic.
See Requirements in the Requirements for Red Hat Enterprise Linux 6 and 5 environments on page 933 topic.
SUSE See Requirements in the Requirements for SUSE Linux Enterprise Server 11 environments on page 956 topic. 2. If an error message with a message ID is displayed, search for the message ID in the information center or see the Tivoli Provisioning Manager ../com.ibm.support.tpm.doc/messages/ rtrbmsg_tpm.dita section under Reference for a description of the error message.
1. Task status
Check the status of the patch management task. For information about task status, see Tracking a provisioning task on page 1165.
989
1. Check for error messages that might explain the source of the problem. 2. Check the following logs for errors relating to actions triggered from the interface:
%TIO_LOGS%\j2ee\console.log %WAS_HOME%\AppServer\profiles\ctgAppSrv01\logs\MXServer\SystemOut.log %WAS_HOME%\AppServer\profiles\ctgAppSrv01\logs\MXServer\SystemErr.log
UNIX Linux Windows
$TIO_LOGS/j2ee/console.log $WAS_HOME/AppServer/profiles/ctgAppSrv01/logs/MXServer/SystemOut.log $WAS_HOME/AppServer/profiles/ctgAppSrv01/logs/MXServer/SystemErr.log
3. On the provisioning server, check the log files for the activity plan engine and the deployment engine. By default, the log level for console.log is info and the log level for trace.log is error. Change the log level to debug to obtain more troubleshooting information. For information about setting the log level, see Configuring log4j dynamically
Windows
%TIO_LOGS%
Linux
UNIX
$TIO_LOGS
trace.log
Windows
%TIO_LOGS%
Linux
UNIX
$TIO_LOGS
The following excerpts from console.log show key messages for a successful patch management task: This line indicates that the task has started: The following lines show that permissions were successfully verified on the target computer:
2010-12-01 10:20:41,484 DEBUG [Install Patch 75,816(75816) from com.ibm.tivoli.tpm.activityplan.manager.AggregateTaskDispatcher] (WorkflowAccessManager.java:106) accesscontrol.WorkflowAccessManager: checking permission (target:6064)Device.ManagerSoftware Device.ManagerSoftware on 75424 succeeded
2010-12-01 10:20:40,828 DEBUG [Activity Plan Engine] ( TpmTask.java:55) manager.TpmTask: Task execution started: Install Patch 75,816
The following lines show that the provisioning workflow was started:
2010-12-01 10:20:41,859 INFO [Install Patch 75,816(75816) from com.ibm.tivoli.tpm.infrastructure.soa.OSGiSdiTaskDispatcher] (MessageTranslatorProxy.java:302) messagetranslator.MessageTranslatorProxy: createDeploymentRequest(workflowName=MS_SOA_InstallPatchS
2010-12-01 10:20:42,953 INFO [Deployment Request 18031] (DeploymentWorker.java:559) engine.DeploymentWorker: Deployment request star Id=18031, at Wed Dec 01 10:20:42 EST 2010 2010-12-01 10:20:42,984 INFO [Deployment Request 18031] (DeploymentWorker.java:275) engine.DeploymentWorker: Executing workflow: Name=MS_SOA_InstallPatchStack, id=6335
4. If the patch installation fails, check for an error message in the Workflow execution logs. For example, select MS_SOA_InstallPatchStack Provising Workflow Status to obtain the exception detail. Check the status of the MS_SOA_InstallPatchStack provisioning workflow execution log in the web interface to determine where the error occurred. The error messages in the log can help you to identify which component is the source of the problem. 5. Open the Workflow Execution Logs view if it is not displayed. a. From the Eclipse menu, click Window > Show View > Other. b. Expand Automation Package and click Workflow Execution Logs. c. Click OK. The Workflow Execution Logs page displays the provisioning workflow run history. There is a limit of 4000 characters for provisioning workflow output. If this limit is exceeded, the output is truncated.
990
2. Publish status
For an inventory scan with software signatures, verify that the software signature was published to the depot. 1. On the provisioning server, check console.log for the following message:
2010-12-01 10:20:48,984 DEBUG [Deployment Request 18031] (FileManager.java:337) cds.FileManager: Published file C:/Program Files/IBM/tivoli/tpm/repository/wua/patchinstall.vbs with taskId 75816 to CDS depots: depot.example.com
2. Verify in the dynamic content delivery console that the file is on the depot server. In a supported web browser, type the following URL:
3. Log on with the Tivoli Provisioning Manager administrator user name and password that you specified during core components installation. The default user is maxadmin. 4. If more information is required for the depot, check the following log files on the provisioning server:
Table 174. Log files Log file trace_cdsmgr.log Message and trace information for download plans as well as general message and trace information trace_cdssec.log Message and trace information for web services authentication and authorization trace_distribution.log Message and trace information for the distribution agent Location
Windows
Linux
UNIX Windows
Linux
UNIX Windows
Linux
UNIX
3. Job status
Verify the status of the patch management job. 1. On the provisioning server, check console.log for a message to indicate that the job was submitted:
2010-12-01 10:21:06,343 INFO [Deployment Request 18031] (JobManagementServiceClient.java:542) client.JobManagementServiceClient: Submitted job to the job management server. Job id is: [129121686617127710]
2. If more information is required for device manager, check the following log files on the provisioning server.
Windows
Linux
UNIX
DMSMsgn.log
Windows
Linux
UNIX
In TraceDMSnumber.log, search for the string jdml. The default DMS polling interval is 60 minutes, so the timestamp in the log might be as much as 60 minutes after the job was submitted. The Job Description Markup Language (JDML) provides details about the job.
991
4. Target status
Check the progress of the patch management job on the target computer for the patch management task. 1. On the target computer, verify that the patch management job was received for processing. Look in CA_HOME/logs/trace-log-number.xml CA_HOME The agent installation directory: v v v
Windows HP UX AIX
Linux Solaris
/opt/tivoli/ep
/usr/tivoli/ep
number A number such as 1. The following message shows that the patch management job was received:
2010-12-01T10:24:32.373-05:00 INFO JES023I Processing job: name = [WuaPatchInstall], requestId = [9dd1cdd0fd5e11df816e0050569c2b74]
If the job was not received, check the following items: a. Verify communication with the target computer. Run the TCA_PingAgent provisioning workflow. b. If the patch management task is taking a long time to complete, one possible cause is that the target computer is not polling for jobs, so the job is never received. To fix this problem, see Jobs not reaching target computer. 2. Verify that the patch installation ran in trace-log-number.log.
2010-12-01T10:24:32.373-05:00 INFO JES023I Processing job: name = [WuaPatchInstall], requestId = [9dd1cdd0fd5e11df816e0050569c2b74]
The following line indicates that the discovery results were uploaded to the provisioning server:
2010-12-01T10:30:55.164-05:00 INFO JES043I Done executing job: [WuaPatchInstall]
3. On the target computer, check the following log files for additional information:
Windows HP UX AIX
Linux Solaris
/opt/tivoli/ep
/usr/tivoli/ep
5. Results
Verify that the discovery results were processed. On the provisioning server, check console.log for the following information: This line shows the selection of the discovery scan results, and then the processing of the results: Related concepts Patch management troubleshooting checklist Patch management problems and limitations on page 997 Related links
2010-12-01 10:30:55,203 DEBUG [Discovery engine worker 1] (DiscoveryWorker.java:81) engine.DiscoveryWorker: Processed message: id 76
Patch management troubleshooting checklist

If you have problems managing patches using Tivoli Provisioning Manager, use the following checklist to help diagnose and troubleshoot your issue.
992
Information for troubleshooting and problem diagnosis: v General issues and identifying the problem v Platform-specific issues on page 994 v Gathering information for IBM Support on page 995
General issues and identifying the problem

Try to identify the problem: v Can you identify if your problem is a patch management issue? Did you get an error message? Tivoli Provisioning Manager error message IDs are designed to provide you with some information about the source of the error. All Tivoli Provisioning Manager error message IDs consist of 10 alphanumeric characters that uniquely identify the message: A 3-character product identifier A 3-character component or subsystem identifier A 3-digit serial or message number A 1-character type code indicating the severity of the message Check the Messages for information about your specific error message. v Check the patch management log files for your platform. Log files for patch management are available as described in Log files on page 996. Checking the log files can help you to identify the cause of your problem. v Is your error listed in the patch management problems list? See Patch management problems and limitations on page 997 for a list of known patch management issues. v Are you using Tivoli Provisioning Manager automation packages? If so, check the documentation for the automation package that you are using. The automation package documentation lists some known issues. The patch management automation package documentation is available at Automation packages. v Is your hardware and software and topology supported? Check the Components section of the documentation for your platform. For example, for patch management on Windows operating systems using the scalable distribution infrastructure check Components for Windows environments using SDI on page 889. v Have you checked the prerequisites and supported configuration for your platform?
Table 177. Verifying prerequisites Platform Windows scalable distribution infrastructure Windows WSUS AIX Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 4 SUSE Linux Enterprise Server 11 SUSE Linux Enterprise Server 10 Solaris Prerequisites Requirements for Windows on page 895 Managing patches in Windows environments using the deployment engine on page 911 Requirements for AIX on page 918 Requirements for Red Hat Enterprise Linux 6 and 5 environments on page 933 Managing patches in Red Hat Enterprise Linux 4 environments on page 949 Requirements for SUSE Linux Enterprise Server 11 environments on page 956 SUSE Linux Enterprise Server 10 environments on page 971 Requirements for Solaris on page 978
Check the following issues that are common across platforms:
993
v Is your problem a patch acquisition problem? A common reason for patch acquisition problems is that variables are not configured correctly or the supported components are not set up properly. Review the patch acquisition documentation for your platform. v Is your issue a compliance scan and check issue? The patch compliance configuration is sometimes performed on the computer and on the group level. This creates inconsistencies in the scan and check results. A good practice is not to have overlapping compliance checks defined. If you do not have overlapping compliance checks defined, this improves the transparency of the scan and check results. v Are you getting false error messages? Large patch sets can result in false results. There are some known issues in the task and scalable distribution infrastructure design that can result in patches being installed, but errors displaying on the Tivoli Provisioning Manager user interface. v Did your problem occur when you were running a patch management workflow? To identify why your patch management workflow failed, you can use the web interface to see the run history of the workflow. You can also export the log files of your provisioning workflow history using the workflowLogExport command, as described in Workflow logs
Platform-specific issues
Check the list of supported features to identify what is supported for your platform Cross platform feature support on page 884. Use the information in the following table to troubleshooting common platform-specific issues:
Table 178. Common platform-specific issues Platform Windows Potential issues Is the correct version of Microsoft windows update agent installed and working? During patch scan and installation, have the correct files been downloaded to the target computers? To verify if the files have been downloaded to the target computers, check the %temp% directory on target computers or search for patch*.vbs. If the files are downloaded and scan and installation fails, check _scan_*.log on the target computers to identify where the process failed. If you are performing patch management on virtual machines, ensure that adequate resources, such as memory and CPU share, are allocated to the virtual machines. Installing multiple patches can sometimes cause corruption in Windows update cache. If this occurs, run the Microsoft cache cleanup workaround. The Microsoft cache cleanup is available from the Microsoft web site. When using the scalable distribution infrastructure for patch management, check for connectivity issues between Tivoli Provisioning Manager and the depot server and target computers. When a scalable distribution infrastructure patch installation job fails, check the target computers' log files for execution errors. Check for things such as the download plan created and run and patch installation related errors. If you are managing patches using the scalable distribution infrastructure on Windows, have you set the cabextract and WSUS environment variables at the same time? The cabextract and WSUS environment variables are mutually exclusive variables and you cannot use them together. For more information about troubleshooting the Microsoft windows platform see: v Microsoft Windows Update Agent: http://support.microsoft.com/kb/949104. v Resetting Microsoft Windows Update components: http://support.microsoft.com/kb/ 971058. v Reading the Windowsupdate.log file: http://support.microsoft.com/kb/902093.
994
Table 178. Common platform-specific issues (continued) Platform AIX Potential issues Did patch installation fail using the AIX_PATCH automation package? Patch installation using AIX_PATCH fails if you are running non-patch discovery against a target computer. If the discovery configuration is updated before installing previously generated AIX patch recommendations for the target computers, then the recommendations generated with the latest discovery configurations are installed on the target computer. The patch installation depends on the information that is stored in the discovery configuration. To resolve this issue, run the patch installation immediately after running the discovery configuration or before running any other discovery. Red Hat Enterprise Linux Have you configured the YUM repository correctly? For information about configuring the YUM repository, see Configuring the YUM repository on page 936. SUSE Linux Enterprise Server Solaris Have you configured the SMT or YUM repository correctly? For information about configuring the YUM repository, see Configuring the SMT or YUM repository on page 959. If you are managing patches for Solaris Zones, verify that your Global Zone is Solaris version 10. Your Global Zone must be Solaris version 10. If you are managing patches for Solaris Zones, are you using a HTTP proxy server? There is no support for an HTTP proxy server or Sun proxy server for the Solaris non-global zones.
Gathering information for IBM Support

If you cannot identify the source of your problem and you need to contact IBM Customer Support, you need to collect some system data before you call IBM Customer Support. Providing this required information enables IBM Customer Support to identify the source of your problem faster. Follow the instructions in the Collect Data document to collect information that you will need when you contact IBM Customer Support. Before contacting IBM Support, use the IBM ISA Lite tool to gather information about your configuration and environment. For more information, see the following documents: v IBM Support Assistant Introduction v v Collecting data with IBM Support Assistant Lite Collecting data with IBM Support Assistant
Review the following table for information that you need to provide to IBM Customer Support.
Table 179. Information required by IBM Support for some common issues Issue Patch acquisition Required information v Document your configuration, for example, "I am using Tivoli Provisioning Manager v7.2 on Red Hat Enterprise Linux, with remote windows download server which uses a proxy for internet access." v Provide a screen capture of the variables that you configured, either cabextractcommand or wsus-download-server-name. v Provide a workflow log export of the failed patch acquisition workflow.
995
Table 179. Information required by IBM Support for some common issues (continued) Issue Required information
Large patch set gives a false v Provide the full set of Common Agent Services logs. positive v Provide a screen capture of the error message in Tivoli Provisioning Manager. v Provide a copy of Program Files\tivoli\ep\runtime\agent\service.bat> CASservice.zip v Provide the C:\Windows\windowsupdate.log and Task UI C:\Windows\temp\ <date>"_patchscan_<time>.log Compliance scan and check v Provide a screen capture of the compliance configuration at Group level. v Provide a screen capture of the compliance configuration at the individual Computer level. Problems with Windows v Provide the full set of Common Agent Services logs. update assistant or v Provide the C:\Windows\windowsupdate.log contents. Windows DLL configuration v Provide a screen capture of the error message that displays in Tivoli Provisioning Manager. Problems with AIX v Provide /var/adm/ras/install_all_updates.log files from the target computers. v Provide /tmp/<ServerName>_<DEReqID>_preview from the target computers.
Log files
Log files help in diagnosing problems and recording commands.
Scalable distribution infrastructure patch acquisition

If you encounter patch management errors during patch acquisition using the scalable distribution infrastructure, check the following log file for details: v
Windows
TIO_LOGS/wsusscan.log (On the Tivoli Provisioning Manager server)
Scalable distribution infrastructure patch installation

If you encounter patch management errors during patch installation using the scalable distribution infrastructure, check the following log files for details: v v v
<systemdrive>:\Windows\windowsupdate.log <agent logs> /tmp/tpminstallupdates.log (on target computers) /tmp/tpmzypperinstallupdates.log (on target computers)
Windows patch installation

If you encounter problems during patch installation on Windows using Windows Server Update Services, check the <systemdrive>:\Windows\windowsupdate.log log file.
Scalable distribution infrastructure patch scan

If you encounter patch management errors during a patch scan using the scalable distribution infrastructure, check the following log files for details: v v v
%TEMP%\<date>__patchscan__<time>.log <agent logs> /tmp/tpmscanupdates.log (on target computers) /tmp/tpmzypperscanupdates.log (on target computers)
996
Solaris patch management log files

The following table provides information about where you can find Solaris patch management log files.
Table 180. Solaris patch management log files Description Information about applied or uninstalled patches Information about patches installed successfully Log files /var/sadm/spool/sunucLog/job_history.log /var/sadm/<patch id>/log
Patch management problems and limitations

Duplicate patch recommendations from OS Patches and Updates

You can either ignore the duplicate recommendations, or you can remove one of the compliance checks in OS Patches and Updates and then run the check again.
Symptoms
Duplicate patch recommendations are listed in the OS Patches and Updates compliance check.
Causes
If your computer has compliance checks from both OS Patches and Updates and from its provisioning group, then the patch recommendations for it will be generated twice. For example, if your computer has 20 patch recommendations because of the OS Patches and Updates compliance check being run, these issues will be listed twice in the Recommendations tab (once for each check) and a total of 40 patch recommendations will be listed in the General tab for the computer. However, if you access the Issues and Recommendations tab for a specific check, the patch recommendations will only be listed once.

You can either ignore the duplicate recommendations, or you can remove one of the compliance checks in OS Patches and Updates and then run the check again.
Windows patches are not installed

A patch that is approved on the web interface is not necessarily approved on the Microsoft Windows Server Update Services (WSUS) server.
Symptoms
In a small Windows environment, after the following tasks are performed: 1. Acquire patches 2. 3. 4. 5. Set up compliance Scan for missing patches Generate the list of recommendation for the target computers Install the patches
When scanning for missing patches again to verify the compliance results, the patches that were installed are still displayed in the recommendations list. Also, if running an inventory scan on the target computers, the result of the scan shows that patches are not installed on the target computers.
997
Causes
The provisioning server does not communicate with the Microsoft Windows Server Update Services (WSUS) server. As a result, a patch that is approved on the web interface is not necessarily approved on the WSUS server.

There are two ways that you can resolve this problem: v When you acquire the patches, make sure that you only acquire patches with an initial patch status of APPROVED. This way, you only acquire the approved patches from the WSUS server and bring them into the data model. v If you already acquired all patches, make sure that after you approve a patch from the web interface, you also to log on to the WSUS server, search for that patch that you approved and approve it on the WSUS server as well.
Parsing error when running Microsoft Updates Discovery

If this happens, restart the Microsoft patch download server, remove all files from the Tivoli Provisioning Manager host name directory, and then run Microsoft Updates Discovery again.
Symptoms
When doing Windows patch management in large environments in the configuration where UNIX or Linux is installed on the provisioning server and a Microsoft patch download server is used, errors are generated when running Microsoft Updates Discovery. The following error might be generated:
COPDEX123E A ParsingFailure exception occurred. The exception was caused by the following problem: A Parsing Failure has occurred. xmlSource is located: /opt/IBM/tivoli/tpm/repository/wua/wsusscancab/update/package.xml.

1. Restart the Microsoft patch download server. 2. Remove all files from the %SystemDrive%\<Tivoli Provisioning Manager host name> directory. 3. Run Microsoft Updates Discovery again.
Installing a technology level also installs the latest service pack

If approving the recommendation to install only the technology level on the target computer, both the technology level and the latest service pack for that technology level are installed on the target computer.
Symptoms
You are managing patches in an AIX environment. When specifying the updates to scan for, you select Latest Level for the Maintenance Strategy Model field to scan for both technology levels and service packs. After following the steps in the information center to generate the patch recommendations, two recommendations are displayed for your target computers: v the latest technology level, for example AIX_TL 5300-07 v the latest service pack, for example, AIX_TL 5300-07-02 If approving the recommendation to install only the technology level on the target computer, both the technology level and the latest service pack for that technology level are installed on the target computer.
Silent installation of interactive Windows patches fails

One or more Windows patches that require an interactive installation might fail in Windows environments that do not have the Microsoft Windows Server Update Services (WSUS) set up.
998
Symptoms
One or more Windows patches that require an interactive installation mode might fail in both the Deployment Engine (DE) and the Scalable Distribution Infrastructure (SDI) modes if the environment has been configured without the Microsoft Windows Server Update Services (WSUS) server.
Causes
Microsoft suppresses the silent installation of some of the newly released patches to ensure that system administrators are aware of the upgrade. Consequently, interactive patches, such as Windows Server 2008 R2 Service Pack 1 x64 Edition (KB976932) and Windows Internet Explorer 9 for Windows Server 2008 R2 for x64-based systems, cannot be installed in silent mode using Tivoli Provisioning Manager.

To install these patches using Tivoli Provisioning Manager, configure your environment using the Microsoft Windows Server Update Services (WSUS) server.
Replacing AIX patches

You need to clean up the data model before acquiring the patches again. If the downloaded AIX patches got corrupted or were inadvertently deleted from the data model, you need to clean up the data model and acquire the AIX patches again.
Procedure
1. Click Go To > IT Infrastructure > Software Catalog > Patches. . 2. Select the TLs, or SPs that you want to delete and click Delete 3. Click Go To > IT Infrastructure > Software Catalog > Patch Acquisition. 4. Click Refresh TL/SP Definitions to bring all available AIX patches into the data model. 5. Under Technology Levels and Service Packs, select the check boxes corresponding to the patches that you want to acquire and click Download Patches.
Patch download and distribution fails on AIX

The files that are being transferred are too large for AIX default settings. You need to change the settings before trying again.
Symptoms
The task of downloading and distributing patches fails on AIX target computers.
Causes
The problem is caused by the large size of the files that are transferred, approximately 2-3 GB, between the AIX satellite server and the provisioning server. This also occurs in large file transfers between the provisioning server and target computers. The default settings for the file size prevent large files from being transferred, and causes the patch download and distribution to fail if the files being transferred are too large.

Do the following steps: 1. On the AIX target computer, modify the /etc/security/limits file so that
fsize = -1
999
in both the default and root sections. 2. On the provisioning server, if UNIX or Linux is installed as the operating system, make sure that fsize is set as
fsize = -1
Download of large number of patches might fail on AIX

Symptoms
The task for downloading a large number of patches might fail on AIX.
Causes
Insufficient memory on the provisioning server and the SUMA server.

It is recommended you download the patches in smaller groups, for example, five patches at a time.
Technology Level 00 patches are unavailable for AIX patch discovery setup with Custom: Technology Level + Service Pack Maintenance Strategy Model
Symptoms
After an AIX patch acquisition task that includes both AIX Service Pack (SP) and Technology Level (TL) patches completes successfully, TL 00 is not displayed in the patch list. When you attempt to set up a custom patch discovery configuration (for example, an AIX Patch Discovery for AIX 7.1 for the Custom: Technology Level + Service Pack model), the TL 00 Technology Level is unavailable for selection.
Causes
The Technology Level 00 is not available as a TL on the Fix server or on the eCC (Electronic Customer Care), therefore it is not listed in the data model.

Before setting up your custom AIX patch discovery, add an Operating System Patches and Updates security check to the AIX target computer (for example, an AIX target with version 7.1 of the operating system installed), and run a compliance scan on the target. After the compliance scan completes successfully, the TL 00 is displayed in the Technology Level list for the Custom: Technology Level + Service Pack model. With the TL 00 now available, proceed with the custom AIX patch discovery setup.
Cannot scan for missing patches on AIX

Because the scan was not done on the target computer, there is no discovery associated with the target computer.
Symptoms
You have added new AIX target computers to the data model, but you have not run a scan on the target computer yet. If you install the patches from the Patch Installation page instead of the Recommendations tab for the target computer, then the scan does not run for missing patches.
Causes
Because the scan was not done on the target computer, there is no discovery associated with the target computer.
Resolving the problem 1000

Run the scan at least once for a target computer so that the scan works from the Patch Installation page as well.
Exclusive patches marked as implemented have not been installed

If you run a compliance scan and it returns a recommendation to install a number of patches and two or more of those patches are exclusive patches, no exclusive patch is installed when you approve and implement the recommendations. After you implement the recommendations successfully, all recommendations display as implemented, even though no exclusive patch has been installed.
Symptoms
If you complete a compliance scan and it returns a recommendation to install more than one exclusive patch, none of the exclusive patches are installed when you approve and implement all recommendations. However, the recommendation displays as implemented even though the patches have not been installed.
Causes
Exclusive patches require exclusive mode and therefore must be installed one at time. This issue occurs because the remediation task has run successfully, even if one or more patches have not been installed because they require an exclusive mode.

To determine if patches have been successfully installed on target computers, you need to run a compliance check after the remediation operation. You need to approve and implement the recommendations for each exclusive patch in the list of recommendations one at a time.
Patch acquisition problem in Red Hat Enterprise Linux environments using SSH protocol
You might have a problem acquiring patches using SSH protocol in Red Hat Enterprise Linux environments.
Symptoms
If you are acquiring patches in Red Hat Enterprise Linux environments using the SSH protocol, the patch acquisition process might fail. If this occurs, you might receive an error message similar to:
COPINF002E The file /usr/IBM/tivoli/tpm/repository/yum/repositories/32568/TPMREPO32570/ TPMREPO32570_headers.tar with the ID 32573 could not be published to dynamic content delivery depot servers. The error message is: CTGDEC030E The management center was unable to find potential depot servers to upload the file. The file, TPMREPO32570_headers.tar, could not be uploaded. Make sure that there is at least one active depot server available, that it has enough space to store the file, and that it is not in an unreachable or restricted zone.
Causes
This problem occurs because of a cURL limitation when you use the SSH protocol for patch acquisition in Red Hat Enterprise Linux environments. Instead of downloading just header files, cURL attempts to download the entire rpm file. If you do not have enough disk space on the depot server, the header .tar file cannot be published on the depot server. The patch acquisition process fails and you receive the error message.

To resolve the problem, increase the available disk space on the depot server to ensure that the entire rpm file can be downloaded.
1001
Patch acquisition problem in Red Hat Enterprise Linux environments using cURL with no SSL support
You might encounter a problem acquiring patches using a cURL version with no SSL support in Red Hat Enterprise Linux environments.
Symptoms
If you acquire patches in Red Hat Enterprise Linux environments using a cURL version with no SSL support, the patch acquisition process might fail with the following error message:
COPDEX123EworkflowThrownException curl: option --insecure is unknown curl: try curl --help for more information
Causes
For AIX systems, the --insecure option is available only with a cURL version with SSL support.

Ensure that you use a cURL version with SSL support for AIX systems. It is recommended this cURL version be downloaded from http://curl.haxx.se/download.html.
Patch scan problem on SUSE Linux Enterprise Server 10 SP1 and SP3
Symptoms
The patch scan on a SLES 10 target system might fail with the following key import error:
Exception: Error in creating zypper configuration file and directories: exceptions.SystemExit: 3654 zmd ZENworks Management Daemon is running. WARNING: this command will not synchronize changes. Use rug or yast2 for that. [2K /repodata/repomd.xml (file:/var/cache/zypper/TPMREPO7488) is signed with an unknown key id: 74CE60209B288F01, continue? [y/n]: Downloading metadata failed (is YUM source?) or user did not accept remote source. Aborting refresh. Service add for repository TPMREPO7488 failed. Exiting... For detail error log refer to: /tmp/tpmscanupdates.log file at target system] OutputStream: []
Causes
The time settings on the repository server and on the target system are incorrect. On the target system, the date of the certificate creation (the validity start date) is in the future, due to a wrong time setting at certificate generation on the repository server or to the setting in the past of the target system time.

Correct the time settings on the repository server at certificate creation and on the target system, and then retry the patch scan.
Patch scan on SUSE Linux Enterprise Server fails due to catalog service name change
Symptoms
Changing the SUSELinux.Catalog.Name global variable without changing the SUSELinux.Update.Server.url causes the patch scan to first attempt to delete the old catalog service, and then catalog the new service. The patch scan might fail with the following error:
RETURNCODE:1, ERROR-MESSAGE:ERROR: Requested service not found (Novell.Zenworks.Zmd.Public.IService, Novell.Zenworks.Zmd.Public, Version=1.0.0.0, Culture=neutral, PublicKeyToken=48eafe5f49a143f5). No receiver for uri e5106190_8862_4ac1_bbfd_1491a8dda8e4/4d995dec_8.rem
1002
Causes
The SLES command to delete the catalog service is sometimes inconsistent. It deletes the service, but it still fails with the preceding error.

Run the task again to create the new catalog service successfully. Alternately, you can manually clean up the old service, and then try the patch scan again.
At @ symbol not supported in user name or password for YUM repository

If you have an At (@) symbol in your user name or password for accessing the YUM repository in Red Hat Enterprise Linux or SUSE Linux Enterprise Server environments, the patch acquisition process fails. cURL does not support the @ symbol in your user name and password credentials.
Symptoms
When you begin acquiring patches using a YUM repository in Red Hat Enterprise Linux or SUSE Linux Enterprise Server environment, the patch acquisition process might fail immediately. Because the process does not start, you cannot analyze log files. A message similar to the following might be available in the console.log file:
Error : ------- std out:<tio><setvar var="ReturnCode">1</setvar></tio> <tio><setvar var="ReturnResult"> </setvar></tio> <tio><setvar var="ReturnErrorString"> curl: (6) Couldnt resolve host in.ibm.com:P0o9i8uy@9.37.253.130 4:21:20 PM: username@in.ibm.com - : 2010-04-13 17:54:53,218 DEBUG [Discovery.OnDevice(11626)] (LocalScriptletRunner.java:48) scriptlet.LocalScriptletRunner: Scriptlet execution finished. 2010-04-13 17:54:53,250 DEBUG [Discovery.OnDevice(11626)] (WorkflowExecutionMonitor.java:134) komodor.WorkflowExecutionMonitor: 0Failing workflow: LinuxPatch_Acquire_Metadata.java with exception: com.ibm.tivoli.orchestrator.de.engine.WorkflowThrownException: COPDEX123E A ExecuteCommand exception occurred. The exception was caused by the following problem: curl: (6) Couldnt resolve host in.ibm.com:P0o9i8uy@9.37.253.130 .at com.ibm.tivoli.ldo.runtime.WkfBase.throwException(WkfBase.java:11) at com.ibm.tivoli.tpm.wkf.core.Local_Execute_Command.execute(Local_Execute_Command.java:176)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:618)at com.ibm.tivoli.ldo.runtime.ServiceBase.invoke(ServiceBase.java:76)at com.ibm.tivoli.tpm.wkf.core.ServiceAccessPoint$ExecuteCommand.execute(ServiceAccessPoint$Execute \ Command.java:70 at com.ibm.

There is no solution to this problem at present. To proceed with the patch acquisition, you must specify a user name and password that do not contain the @ symbol for accessing the YUM repository.
Windows Update Agent installation failure on Windows version 7

Installation of an older version of the Windows Update Agent (WUA) might fail during software installation on Windows version 7 target computers. If you have a version of the WUA in your repository that is too old to work on Windows version 7, that version of the WUA is not installed on the Windows 7 target computers.
Symptoms
1003
Installation of a particular version of the Windows Update Agent fails during software installation on Windows 7 target computers.

The Windows Update Agent is stored in the %TIO_HOME%/repository/wua/<windowsupdateagent/ windowsupdateagent64> directory in the repository. If a version of the Windows Update Agent is in the repository at this location, that version of the WUA is installed during software installation on target computers. If the %TIO_HOME%/repository/wua/<windowsupdateagent/windowsupdateagent64> directory does not exist, Tivoli Provisioning Manager downloads the latest version of the Windows Update Agent. If you want to install a particular version of the Windows Update Agent, you need to include that particular version in the %TIO_HOME%/repository/wua/<windowsupdateagent/windowsupdateagent64 directory. You need to ensure that the version is compatible with the Windows 7 target computers. If you want to install the latest version of the Windows Update Agent, you can remove the %TIO_HOME%/repository/wua/<windowsupdateagent/windowsupdateagent64> directory from the repository. If this directory does not exist, Tivoli Provisioning Manager downloads the latest version of the WUA and that version is installed during software installation on target computers.
Reference
Publishing software to depot servers

To allow faster download and software distribution to target computers, you can publish software products, software patches, or files in a specified repository to selected depot servers at the branch office, in advance of when they are needed on the computers. The files published on depot servers can then be downloaded by the target computers.
Before you begin

Distribution files are published to a depot server using the dynamic content delivery agent. The agent must be installed on the depot server before you can publish any files. The depot feature needs to be installed on a depot before a file can be published to it. Verify that the depot is in active state before publishing a file to it. Always include a preferred upload server when a file is published for the first time. You can also define the number of concurrent activities included in each activity plan when publishing software and patches. The default value is five. Increasing the number of activities in each plan reduces the risk of creating too many threads. Before you publish a file, determine which users will download the file and their location on the network. This affects the target lists or regions to which you replicate the file. To minimize network traffic and download time, publish the file to depot servers that are near the users who need the file. Files uploaded to a depot server are stored in a directory that is specified when the depot server is installed. Depot servers can replicate the uploaded files to other depot servers to optimize the efficiency of network traffic. The computers download the published files for installation.
Publishing software products

To publish software products to depot servers:
Procedure
1. Click Go To > Deployment > Software Management > Software Product Publishing. 2. Select the Encrypt File check box if you want to enable encryption of the software installable.
1004
3. Click Select Software and select the software modules to be published, then click OK. 4. Click Select Depots and select one or more depot servers for the provisioning task, then click OK. Tip: The default path for publishing can be customized. v The default path is C:\Program Files\Tivoli\ep\runtime\agent\subagents\cds\depot\. v The relative path variable is \data. v The system creates subdirectories \files\1 under C:\Program Files\Tivoli\ep\runtime\agent\ subagents\cds\depot\data\. To publish to a specific subdirectory, for example, abcd, change the relative path. The files will be published at C:\Program Files\Tivoli\ep\runtime\agent\subagents\cds\depot\ abcd\files\1\. 5. Click Schedule to run the task now or to specify the date and time on which the provisioning task is scheduled to start. 6. Under Notification, specify notification settings for the task. 7. Click Submit.
Results
Publishing patches
To publish software patches to depot servers:
Procedure
1. Click Go To > Deployment > Patch Management > Patch Publishing. 2. Click Select Patches to select the patches that you want to publish, then click OK.
Windows To search for a particular patch, enter the patch name in the Patch field, for example KB921823. If multiple software definitions are available for that patch number, for example, Security Update for Windows Server 2003 and Security Update for Windows XP, select all the software definitions that match the patch number, and the provisioning server will publish them to the depots. 3. Click Select Depots and select one or more depot servers for the provisioning task, then click OK.
Tip: The default path for publishing can be customized. v The default path is C:\Program Files\Tivoli\ep\runtime\agent\subagents\cds\depot\. v The relative path variable is \data. v The system creates subdirectories \files\1 under C:\Program Files\Tivoli\ep\runtime\agent\ subagents\cds\depot\data\. To publish to a specific subdirectory, for example, abcd, change the relative path. The files will be published at C:\Program Files\Tivoli\ep\runtime\agent\subagents\cds\depot\ abcd\files\1\. 4. Click Schedule to run the task now or to specify the date and time on which the provisioning task is scheduled to start. 5. Click Submit.
1005
Results
Unpublishing files from depot servers

Distribution files can be unpublished from depot servers when they are no longer needed. You can unpublish software products, software patches, and files in a specified file repository from depot servers. Unpublished files are removed from all depot servers they have initially been published to.
Unpublishing software products

To unpublish software products from depot servers:
Procedure
1. Click Go To > Deployment > Software Management > Software Product Unpublishing. 2. Type a relevant name for the provisioning task. You can use this name to view the provisioning task status on the Provisioning Task Tracking page. 3. Under Select Installables, specify the software modules for the provisioning task: a. From Views, select a software view to filter the list of software products. b. The Software Products type is selected by default. The Available Software table lists all available software modules that have at least one installation file. c. Select the software installation files for the provisioning task. The Selected Installables table lists the selected files. 4. Click Schedule to run the task now or to specify the date and time on which the provisioning task is scheduled to start. 5. Click Submit.
Results
Unpublishing patches
To unpublish software patches from depot servers, follow these steps:
Procedure
1. Click Go To > Deployment > Patch Management > Patch Unpublishing. 2. Type a relevant name for the provisioning task. You can use this name to view the provisioning task status on the Provisioning Task Tracking page. 3. Under Select Installables, specify the software patch-installation file pairs for the provisioning task: a. From Views, select a software view to filter the list of software patches. b. The Software Patches type is selected by default. The Available Software table lists all available software patches that have at least one installation file. c. Select the software installation files for the provisioning task. The Selected Installables table lists the installation files selected for the provisioning task. 4. Click Schedule to run the task now or to specify the date and time on which the provisioning task is scheduled to start. 5. Click Submit.
1006
Results
Unpublishing files
Files in a specified file repository, which are not associated with any installables, can also be unpublished from depot servers. To unpublish files from depot servers, follow these steps:
Procedure
1. Click Go To > Deployment > Software Management > File Unpublishing. 2. Click Unpublish > Files. 3. Type a relevant name for the provisioning task. You can use this name to view the provisioning task status on the Provisioning Task Tracking page. 4. Under Select Files, specify the files for the provisioning task: a. Select the file repository for the files to be unpublished. b. Search for and select the files for the provisioning task. The Selected Files table lists the files selected for the provisioning task. 5. Click Schedule to run the task now or to specify the date and time on which the provisioning task is scheduled to start. 6. Click Submit.
Results
Manually defining patches

If you need to manually add a new patch, the first step is creating its software definition. The recommended way to add software patches to the software catalog is to use a supported software update system such as Microsoft Windows Server Update Services, because the provisioning server can automatically create software definitions for imported patches. Software definitions for patches include patch-specific information, such as the severity and issue date in software definitions for patches.
Procedure
1. Click Go To > IT Infrastructure > Software Catalog > Patches. 2. 3. 4. 5. 6. 7. . Click New Type the name, description, vendor, and select the locale. In the Approval Status field, select the approval status of the patch. In the Severity field, select the importance of the patch. Type the version number. Select the appropriate check boxes: v Restart application indicates that customer application must be restarted. v Can request restart indicates that the operating system must be restarted.
1007
v Patch can coexist indicates that patched servers can coexist in the same application tier as servers that have not been patched. 8. In the Software Installables section, specify the actual installation file for the software. Click New Installable to add a file. Note: Use a single installable file if you only have a single software package or software image that is associated with the software definition. You can associate multiple installable files with a software definition if you have different mechanisms for installation. For example, you can include an .msi package for computers that have the Microsoft Software Installer and a compressed file for computers that have software to extract the contents of the file. At installation time, the requirement attributes of the installation files will be compared against the information about the target computer to determine which installation file to use. a. Specify the name, version number, and description. b. In the Status list, select the appropriate status of the file. c. If you are adding the file from a file repository, click the file repository name in the File Repository list. d. In the Installable Path field, type the path where the software package is stored. The path is relative to the root directory of the file repository. For example, if the repository path is configured as /share, and the package is stored in /share/package1, then the package path is /package1. e. In the File field, type the name of the file. f. If this file is specific to a locale, select the locale. g. Click Submit. An entry is added to the list of installation files. 9. Optional: In the Provisioning Groups section, you can add the software to a provisioning group to categorize and organize your software. Click Assign to Provisioning Group and select a provisioning group. 10. Requirements and capabilities for the software can be defined in several ways and will be explained in a later step. Create your software configuration templates with the specific installation parameters to use during installation of the software. For details see Creating software configuration templates on page 714. 11. Specify requirements for the software. v Define global requirements first in the Requirements section of the software. These requirements apply for any deployment of the software, regardless of which installation file is used or which software configuration template is used to perform configuration of the software during installation. a. Click Add Requirement. b. In the Requirement Type list, select the requirement type. c. If you only want to specify a requirement type, leave the Requirement field blank. If you want to add a requirement name, select a requirement name. d. If you selected a requirement name, select one or more values for it. You must specify at least one value. To add a value, type it in the Value field, and then click Add. e. If you are creating a hosting requirement, select the Hosting check box. Use this option when the software you are defining needs to run in the context of another software application. For example, a servlet requires a standalone servlet engine or an application server with servlet support to load the servlet. The servlet engine therefore acts as a container for running the software. If the servlet requires a specific container environment, such as WebSphere Application Server, you can specify a hosting requirement for it. f. If you want the provisioning server to reject a mismatched capability but accept a missing capability, select the Accept Non Existing Capability check box. g. Click Save.
1008
v If you added more than one file to the Installables list, expand the entry for each one in the Installable list and specify file-specific requirements. For example, if you have added different installation files for different hardware or different operating systems, specify the particular requirements for each file. v If you are using multiple software configuration templates to define different ways to configure the installation, specify requirements to check for each type of deployment. For example, if you are defining a J2EE application and want to deploy it to WebSphere Application Server and WebLogic Server, the software configuration templates that you create for each type of deployment can contain requirements for the type of J2EE server. 12. Capabilities identify attributes of the software that can be used for installation requirement validation. For example, if you are creating a software definition for a Example Patch version 5, you can specify the vendor (Example) and the version number (5). After you deploy Example Patch 5, other software deployments that require Example Patch 5 can verify whether a particular computer has the patch installed. a. Click Add Capability b. Specify the capability details. 1) In the Capability Type field, select the appropriate capability type. 2) In the Name section, specify the appropriate values for each capability name. 3) Click Save. 13. Click Save .
Results
The software definition for the software patch is created.
What to do next
To install the software, you must specify the provisioning workflows required for this software patch. For information about assigning provisioning workflows, see the provisioning workflows documentation.
Installing individual patches on UNIX and Linux

After patches are approved, you can install them on the target computers where they are missing. You can install patches immediately or schedule this activity for a specified date and time. If the patches have not been distributed yet, they are distributed and installed on the target computers. If the patches have already been distributed, they are installed on the targets. During patch installation, the provisioning server checks the list of approved patches against each target and only installs the patches that are required by that target. If you want to install a patch on multiple targets in a single operation, you can select, for example: v All targets in a provisioning group, customer, or application. v All targets with a particular software product installed. v All targets that are missing a particular patch. To install individual patches:
Procedure
1. Click Go To > Deployment > Patch Management > Patch Installation. 2. To initiate a restart for the target computer, select the Reboot if required check box. 3. Click Select Patches and select the patches that you want to install. You can display patches based on Patch, Vendor, Version or you can expand Advanced Search Options for more options.
1009
4. Under Selected Targets, specify the target computers on which you want to install the patches. You can also expand Advanced Search for more options. 5. Under Scheduling, specify when you want to install the patches. 6. Under Notification, specify when and which users you want to be notified about the installation status. 7. If you want to select Recipients, click Add User and specify the user name. You can also specify an e-mail address by clicking Add E-mail. 8. If you want to select Events, click Add Event and specify the event type. 9. Click Submit.
Results
Installing individual patches on Windows

After patches are approved, you can install them on the computers where they are missing. Typically, users with the Deployment Specialist user role install patches. You can install patches immediately or schedule this activity for a specified date and time. If the patches have not been distributed yet, they are distributed and installed on the target computers. If the patches have already been distributed, they are installed on the targets. During patch installation, the provisioning server checks the list of approved patches against each target and only installs the patches that are required by that target. If you want to install a patch on multiple targets in a single operation, you can select, for example: v All targets in a provisioning group, customer, or application. v All targets with a particular software product installed. v All targets that are missing a particular patch. To install individual patches:
Procedure
1. Click Go To > Deployment > Patch Management > Patch Installation. 2. Click Select Patches and select the patches that you want to install. You can display patches based on Patch, Vendor, Version or you can expand Advanced Search Options for more options. To search for a particular patch, type the patch number in the Patch field, for example KB921823. If multiple software definitions are available for that patch number, for example, Security Update for Windows Server 2003 and Security Update for Windows XP, select all the software definitions that match the patch number. Tivoli Provisioning Manager will install the correct patch based on the operating system on the computers. 3. Under Selected Targets, specify the target computers on which you want to install the patches. You can also expand Advanced Search for more options. 4. Under Scheduling, specify when you want to install the patches. 5. Under Notification, specify when and which users you want to be notified about the installation status. 6. Click Submit.
1010
Results
You can uninstall patches on some platforms. Before uninstalling patches, you need to be certain that there are no dependencies on the patches that you are uninstalling and you need an indepth knowledge of the platform and potential issues that might arise when patches are uninstalled. Do not uninstall patches unless you are certain that the patches are no longer required and that there are no adverse effects on your target computers or environment. The following table provides information about the platforms for which you can uninstall patches.
Before you begin

Make sure that the following requirements are met: v Your user role is Deployment Specialist or equivalent. v Patches that you want to uninstall from the target computers were installed in a previous task. v For AIX only, patches that you want to uninstall were not committed during installation. Attention: You cannot use Tivoli Provisioning Manager to uninstall patches in Red Hat Enterprise Linux, SUSE Linux Enterprise Server, or HP-UX environments. Before uninstalling patches you need to be certain that there are no dependencies on the patches that you are uninstalling and you need an indepth knowledge of the platform and potential problems that might arise if you uninstall patches. Do not uninstall patches unless you are certain that the patches are no longer required and that there will be no adverse effects on your target computers or environment. On AIX, you cannot uninstall Technology Levels using this uninstallation procedure, only Service Packs. To uninstall Technology Levels, use the commands or tools that are provided by the AIX operating system. Note: On the platforms on which you can use Tivoli Provisioning Manager to uninstall patches, you can also use the reboot if required option to automatically reboot the target computers from which you uninstall patches. This option is valid for Windows, AIX, and Solaris environments. To uninstall patches from target computers:
Procedure
1. Click Go To > Deployment > Patch Management > Patch Uninstallation. 2. Click Select Patches and select the check boxes corresponding to the patches that you want to uninstall, then click OK. Tip: To search for a particular patch, type the patch number in the Patch field, for example, AIX_SP 6100-00-01. 3. Click Select > Groups and select your group of target computers, then click OK. 4. Under Scheduling, specify scheduling options if you want to schedule the task for a later time. 5. Under Notification, specify notification options if you want users to be notified about the task status. 6. Click Submit. 7. On the Provisioning Task Tracking page, click Refresh to update the task status until the task is completed.
1011
Results
The patch uninstallation task is displayed with a status of Success on the Provisioning Task Tracking page.
1012
Chapter 10. Configuring virtual servers

Virtualization is a software technology that allows multiple operating systems to run on the same host computer at the same time. Additional uses of virtualization include the quick creation of new systems for testing, training, and demonstrations. Using virtualized computers gives you savings on hardware, environmental costs, management, and administration of the server infrastructure.
An overview
A virtual server is composed of software and acts like a complete hardware system from processor to network card in a self-contained, isolated software environment, enabling the simultaneous operation of otherwise incompatible systems. A virtual server has no hardware components at all. Virtual servers are based on host platform servers. A host platform server is a physical computer that has hosting capabilities and can host many virtual servers. Virtual server technology in Tivoli Provisioning Manager allows you to run multiple operating systems concurrently on a single physical host platform server. Virtual servers are created using a virtual server template to define the resource requirements that the virtual servers need. Using virtual server templates standardizes the configuration of virtual servers.
Supported virtualization technologies

Tivoli Provisioning Manager supports the following virtualization technologies: v AIX WPARs v AIX LPARs v Kernal-based Virtual Machine (KVM) v Solaris Zones v VMware
Virtualization basics
Find out more about the virtualization process, the key terms for virtualization, who are the users are and what are the requirements that you need to verify before managing virtualization. Review the troubleshooting information and the log files names and location for this feature and also additional resources that help you complete your virtualization tasks. v Process on page 1014 v User roles on page 1014 v Requirements on page 1014 v Key terms on page 1015 v Troubleshooting on page 1015 v Log files on page 1015 v Resources on page 1016
1013
Process
It is important to understand the overall virtualization process before you start managing virtualization with Tivoli Provisioning Manager. For more information about the virtualization process, see v VMware virtualization process on page 1059 v Solaris Zones virtualization process on page 1086
User roles
You must be assigned to the appropriate user role to manage virtual servers.
Table 181. User roles Role Provisioning Administrator Description This user can perform all of the provisioning tasks and manages the data model. v Discovers computers. v Creates virtual servers and virtual server templates. v Manages virtual servers. Deployment Specialist Provisioning Configuration Librarian v Installs software on target computers or virtual servers. Discovers computers. v Knowledge of operating systems. Skills v Knowledge of the provisioning environment. v Knowledge of operating systems. v Knowledge of virtualization technologies.
Requirements
User roles and requirements on page 1060 Hardware and software requirements for Solaris Zones on page 1087 Hardware and software requirements for VMware on page 1060
1014
Key terms
host platform server A physical server that has hosting capabilities for virtual servers. hypervisor A program or a portion of Licensed Internal Code that allows multiple instances of operating systems to run simultaneously on the same hardware. Typically, it represents the server that hosts the virtual servers. For ESX, for example, the hypervisor is the actual VMWare ESX server that hosts the virtual servers. LPAR Logical partition. One or more subsets of a single IBM System p logical partition that contains hardware resources and operates as an independent system.
software stack A list of software products, organized in the required installation order. A software stack can contain individual pieces of software and other software stacks. sparse root model A root file system model for non-global Solaris zones that contains only a subset of the Solaris packages. virtual server A server that shares its resources with other servers to support applications. virtual server template The template on which a virtual server is based. The virtual server is allocated using the hardware requirements of the template. virtualization A software technology that allows multiple operating systems to run on the same processor at the same time. whole root model A root file system model for non-global zones in Solaris which contains the Solaris package installation. WPAR Workload partition. Virtualized operating system environments that are created within a single AIX 6.1 image.
Troubleshooting
v Messages v Support information about virtual servers v Contacting support
Log files
For more information on recovering from virtualization problems, refer to one of the following topics: v LPAR problems v WPAR problems v Solaris Zone problems v VMWare problems v KVM problems v VMC problems
1015
Resources
To learn more about virtualization, refer to one of the following resources: v Tutorial: Managing virtual servers and host platform servers using VMware on page 1058 v Tutorial: Managing virtual servers and host platform servers using Solaris Zones on page 1084 v Virtual server states on page 1067 v Managing virtualization with LPARs v Managing virtualization with AIX WPARs on page 1026 v Managing virtualization with KVM v Live Partition Mobility for System p server on page 1056 v Managing IBM System p virtualization with VMControl on page 1040 v For a description of a field in the web interface, press Alt+F1.
Related links Chapter 10, Configuring virtual servers, on page 1013 Requirements on page 1060 Troubleshooting virtualization management on page 1095 Tutorial: Managing virtual servers and host platform servers using VMware on page 1058 Tutorial: Managing virtual servers and host platform servers using Solaris Zones on page 1084
Managing virtualization with LPARs

This topic provides reference information about managing virtual environments using LPARs. It is meant as a quick reference for the requirements for managing virtualization. Also, it gives you at-a-glance information about the related automation package.
LPAR quick reference Logical partitions (LPARs) are a virtualized subset of the hardware resources of a physical computer. An IBM POWER servers and blades can be partitioned into multiple LPARs. Each logical partition has a separate operating system. Hardware Management Console requirements Supported Hardware Management Console models: v For IBM eServer POWER4, Hardware Management Console (HMC), Release 3 Version 2.6 or later. v For IBM eServer POWER5, Hardware Management Console (HMC), Release 4 Version 4.0 or later. v IBM POWER6 and POWER7 Hardware Management Console (HMC). You can manage virtualization on the following microprocessors using HMC: v IBM POWER4 server v IBM POWER5 server v IBM POWER6 server v IBM POWER7 server Multiple SAN disk management is supported on HMC managed pSeries servers. SAN disks can be added to LPARs through a single path or multiple paths (MPIO). Integrated Virtualization Manager requirements
1016
You can manage virtualization on the following blade servers with Integrated Virtualization Manager enabled v Power5 Blades, VIO server version: 2.1.3.10-FP-23 or later v Power6 Blades, VIO server version: 2.1.3.10-FP-23 or later v Power7 Blades, VIO server version: 2.1.3.10-FP-23 or later Setting up the environment Use the following scenario to create your environment for LPAR virtualization: 1. Add the Hardware Management Console or the Integrated Virtualization Manager (IVM) computer to the provisioning data model Specify the name of the computer (using the fully qualified host name), identify the management IP address, and the subnet mask. 2. Add credentials to the Hardware Management Console or Integrated Virtualization Manager computer Define the credential pair type of SSH and SCP on the computer. Specify the user ID, the Search Key, and optionally the password if you want to use password credentials instead of RSA credentials. RSA credentials require the public key of the provisioning user tioadmin to be added to the authorized_keys2 file of the Hardware Management Console user ID. For HMC, the default user name can be hscroot, however, any user ID with the right privileges can be used. The default user name for IVM is padmin. 3. Run IBM Hardware Management Console (HMC) Discovery or IVM Discovery The discovery identifies all host platform servers managed by a Hardware Management Console or an Integrated Virtualization Manager and all the resources on those host platform servers, any existing LPARs and the resources on the LPARs. Important: Integrated Virtualization Manager machines that you created before Tivoli Provisioning Manager Fix Pack 2 do not have associated disk data objects. You must run the Integrated Virtualization Manager Discovery in Tivoli Provisioning Manager Fix Pack 2 to populate before saving a computer. If you do not run the discovery before saving a computer, you will not be able to restore the saved images. Note: If host platform servers have already been discovered using the VMControl Discovery, after running the IBM Hardware Management Console (HMC) Discovery, the pSeries host type will automatically change from VMControl to LPAR for the host platform servers displayed under Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 4. Add hardware resources and credentials to the virtual server. Add the SSH and SCP credentials to the virtual server. This can be accomplished by running the Initial Discovery on the LPARs. Supported Activities The following table describes the types of activities supported for the LPAR virtualization technology. Important: For any of the activities below, the provisioning workflow fails if the LPAR name is not valid. The LPAR name must adhere to the following rules: v Must be 1 - 63 characters long. v Only contain letters the a through z (not case-sensitive), the numbers 0 through 9, and the hyphen (-) character. v Must begin with a letter. v Must end with a letter or a number. v The host name must be created in DNS and must have an IP address associated.
1017
Table 182. Supported virtualization activities for LPARs Activity Create LPARs Details You can create LPARs using the resources that are marked as managed on a host platform server. Use a virtual server template to create an LPAR virtual server. The virtual server template specifies the size and types of resources that you allocate to the new virtual server. Create LPARs with multiple logical volume (LV) backed disks. (Supported for HMC and IVM environments) Increase the storage capability of new pSeries LPARs by adding additional hard disk requirements to the virtual server template before you create the virtual server. Select a virtual server template and add the additional Hard Disk resources. Specify the Host Platform Quantity and the Resource Group for each hard disk requirement that you add. If you do not specify the resource group, the disk requirement will be allocated on the first available group. Also, for each new hard disk resource requirement that you do not want to be used to deploy the AIX operating system, the following parameter must be defined: v Parameter: for_os_deployment v Value: false If this parameter is not added to each hard disk requirement, the disk will be used to deploy the AIX operating system. After the hard disks are added, create the new virtual server using the virtual server template. Hard disks cannot be removed from a virtual server, and the host platform quantity (the size of the hard disk) cannot be reduced. When the virtual server is deleted, the allocated hard disks are also deleted.
1018
Table 182. Supported virtualization activities for LPARs (continued) Activity Create LPARs with multiple SAN disks (Supported for HMC environments only) Details Add multiple SAN disks to the virtual server template before you create the virtual server. To request bootable disk requirements (belonging to rootvg), select a virtual server template and add additional Hard Disk resources. You do not have to specify the Host Quantity Platform and Resource Group for SAN disks. Add the required parameters and values to each new SAN disk that you add to the virtual server template. See the virtual template called Sample Multiple MPIO Disks Virtual Server Template for an example of the parameters that are required. Required parameters for each SAN disk to deploy AIX OS 1. PVID or SerialNumber: Specify the physical volume ID or the serial number of the SAN disk. 2. MPIO_policy: A string variable that is used for the MPIO policy definition for MPIO disk requirements. There are several possible values for this parameter: v An empty string. In this case, all VIO servers defined on CEC are used for the disk mapping. v MPIO_REQUIRED. Dynamically computes the VIO servers. v MPIO_NOT_REQUIRED. Uses the first VIO server for disk mapping. v The name of the VIO server: VIOServerName v A string with a list of VIO servers, separated by a semicolon. For example, VIOServerName1;VIOServerName2:VIOServerName3 3. vtscsiDeviceNameSchema: The VTSCSI device name schema for the SAN disk. 4. resource.id: skip_TPM_resource_allocation. Optional Parameters v client_adapter_is_required. The value for this parameter is either yes or no. If the value is yes, the SAN disk adapter in the LPAR profile is set to required. If the value is no, it is set to not required. SAN disk requirements, before Tivoli Provisioning Manager 7.2 FP2, used variables. These legacy SAN disk requirements are still supported. However, the legacy SAN disk will be ignored if there are new SAN disk requirements (using parameters) on the same virtual server template. To request disks that are not for AIX operating system deployment (belonging to non-rootvg), add the parameters and values listed above, and the following parameter and values to each new SAN disk: v Parameter: for_os_deployment v Value: false
1019
Table 182. Supported virtualization activities for LPARs (continued) Activity Details When the hard disks requirements are added, create the new virtual server using the virtual server template. Hard disks cannot be removed from a virtual server, and the host platform quantity cannot be reduced. If you are using a legacy SAN disk VST to create an LPAR and install AIX, by default Tivoli Provisioning Manager will install AIX on hdisk0. If you are creating an LPAR with AIX installed on multiple disks, do not use a legacy SAN disk VST. Instead use the disk resource requirement of the VST. Keep in mind that provisioning the AIX operating system with a SAN disk will erase all of the disk's data. If you are not using a disk to provision the AIX operating system, the data on the disk is not affected by removing or provisioning the LPAR. Discovering LPARs Use the discovery configuration called IBM Hardware Management Console (HMC) Discovery or IVM Discovery to discover all the host platform servers and the LPAR virtual servers defined on the host platform servers. The information is imported into the provisioning database. A provisioning workflow validates the LPAR to be powered on or off, performs the action, and then updates the state of the LPAR. Click refresh to see this updated state in the Web interface. A provisioning workflow validates the LPAR to be rebooted, performs the action, and then updates the state of the LPAR. Click refresh to see this updated state in the Web interface. This operation takes a few minutes to complete. Increasing the hard disk size: The disk size can only be increased, it cannot be reduced. 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select the host platform server that hosts the virtual server that you want to resize the hard disk on. 3. Beside the virtual server, click the Detail Menu and select Resource Allocations. 4. In the table, find the hard disk, for example hdd0, and change the Host Platform Size to the total size that you want that hard disk. 5. Click OK. Confirm the resource allocation change. A provisioning workflow is launched to complete the disk resizing.
Powering LPARs on and off
Hardware rebooting LPARs
Increasing LV-backed disk allocation size
1020
Table 182. Supported virtualization activities for LPARs (continued) Activity Changing CPU and RAM resources Details CPU and RAM resources can be increased or decreased on LPARs. 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select the host platform server that hosts the virtual server that you want to resize the hard disk on. 3. Beside the virtual server, click the Detail Menu and select Resource Allocations. 4. In the table, find the CPU or RAM resource and change the Virtual Size and Host Platform Size to the total size that you want the resource. For an explanation of Virtual Size and Host Platform Size, see Table 2. 5. Click OK. Confirm the resource allocation change.
1021
Table 182. Supported virtualization activities for LPARs (continued) Activity Adding additional hard disks to existing LPARs Details To increase its storage capabilities, add additional hard disk resources to provisioned LPARs. The virtual disks that are added to the LPAR are logical volumes from the storage pool managed by the VIO server. MPIO disks can be added in HMC environments by adding SAN disks. You can use the add disk function to add an additional path for a mapped SAN disk via another VIO server to an LPAR. You can do this if the SAN disk is managed by multiple VIO servers and it has been mapped to the LPAR using one or more VIO servers. If you do this, no additional disk is added to the LPAR but it provides a new path from the LPAR to the SAN disk. LPARs managed using HMC 1. Beside the LPAR, click the Detail Menu select Add Resource Allocations. 2. Click Add Resource Allocation > Add Disk Resource Allocation 3. Select the disk type for the new disk, either Logical Disk or SAN Disk. 4. If you selected Logical Disk, specify the following information: a. TheHost Platform Quantity. b. The Resource Group. If you do not specify the resource group, the disk will be allocated on the first available group. 5. If you selected SAN Disk, specify the following information: a. The Physical Volume ID or the Serial Number of the SAN disk. b. The Multipath Policy. If you select the Specify the VIO servers to configure multipath policy, select the VIO servers in the section below. c. Optional. Customize the device name within the Adapter Name Schema default name. Change only the device name part of the default name, MySANdisk. The remainder of the default name will be generated automatically. Restriction: If you replace the default device name, MySANdisk, with a unique name, the new name can only be 15 characters or less. The provisioning task will fail if a longer name is used. 6. Click Submit. and
1022
Table 182. Supported virtualization activities for LPARs (continued) Activity Details LPARs managed using IVM 1. Beside the LPAR, click the Detail Menu select Add Resource Allocations. 2. Click Add Resource Allocation > Add Disk Resource Allocation 3. Type the Host Platform Quantity and select the Resource Group. If you do not specify the resource group, the disk will be allocated on the first available group. 4. Click Submit. The hard disk is added to the LPAR. Hard disks that are added to LPARs cannot be removed. If an LPAR is moved to a different host platform server, the hard disks do not move, but they will still be accessible. When LPARs are deleted, any allocated hard disks are also deleted. Saving images of LPARs (Supported for IVM and HMC) Important: Virtual machines managed byIntegrated Virtualization Manager that you created before Tivoli Provisioning Manager v7.2 Fix Pack 2 do not have disk data objects. You must run the Integrated Virtualization Manager Discovery in Tivoli Provisioning Manager v7.2 Fix Pack 2 before saving a computer. If you do not run the discovery before saving a computer, you will not be able to restore the saved images.Using the Saved Images application in the Image Library, images of LPARs, with single or multiple virtual disks, can be saved so that you can backup various states of your virtual server. When the LPAR has been deleted, you can restore it using the saved image. For HMC, multiple LV-backed and SAN disks can be saved. The LPAR must have an AIX operating system. If the LPAR contains a disk that does not belong to the rootvg, the disk will be saved but the data is not saved. So, when the image is restored with the saved image, the non-rootvg disk is restored but any data that was on the disk is lost. When the image is restored to an existing LPAR, all non-rootvg disks are deleted and then restored with empty disks with the correct size from when the image was originally saved. See Saving images on page 519 for the detailed steps to save an LPAR image. Restoring images to create LPARs If it has been deleted, you can create the LPAR again by restoring the saved image of the LPAR. All of the virtual disks that were on the LPAR when the image was saved will be on the restored LPAR. See Creating or replacing virtual servers from saved images on page 520 for the detailed steps to restore an LPAR image. and
1023
Table 182. Supported virtualization activities for LPARs (continued) Activity Restoring images to replace LPARs Details An existing LPAR can be replaced by an image of a saved LPAR. For virtual servers with multiple disks, the existing LPAR typically contains more disks than the saved image. Only the disks on the saved image will be restored.Restoring a saved image will restore its saved hardware configuration and data on root volume group. If the LPAR contains a disk that does not belong to the rootvg, the disk will be saved but the data is not saved. So, when the image is restored with the saved image, the non-rootvg disk is restored but any data that was on the disk is lost. When the image is restored to an existing LPAR, all non-rootvg disks are deleted and then restored with empty disks with the correct size from when the image was originally saved. The following scenarios are supported: v HMC: LPARs with logical disks, with SAN disks, and with a mix of both logical and SAN disks. v IVM: LPARs with logical disks. See Creating or replacing virtual servers from saved images for the detailed steps to restore an LPAR image. Deleting LPARs A provisioning workflow validates the LPAR to be deleted and then deletes it. The provisioning data model is updated to remove the LPAR and all of its related objects. Multiple LPARs can be deleted at the same time using the Provisioning Computers application. The LPARs will be removed from the provisioning data model, but will not be deleted from the host platform server. For more information, see the topic called Deleting a virtual server on page 1077. Live Partition Mobility for System p server Using Live Partition Mobility, you can migrate LPARs running the AIX operating system and their hosted applications from one physical server to another without disrupting the infrastructure services. The migration operation maintains complete system transactional integrity and transfers the entire system environment, including processor state, memory, attached virtual devices, and connected users. For more information, click here.
Virtual server templates Use a virtual server template to create an LPAR. The template specifies the types and sizes of resources that you want to allocate to the new LPAR. You can add or change the resources in a virtual server template. You can add any of the following resource types to LPARs: v CPU v Hard Disk v Memory
1024
v NIC v Generic resource When you add a new resource type, you can specify the following options: v Optional. Shared. This property indicates if the resource allocated from the host platform server must be dedicated to the new LPAR or if it can be shared with other LPARs. If a resource is not shared with other LPARs, the corresponding resource on the host platform server is decremented when an LPAR is allocated. If the resource is shared with other LPARs, the corresponding resource on the host platform server is not decremented and the same resource can be simultaneously assigned to as many LPARs as needed. Important: Resource allocations created from one resource must either be all shared or all dedicated. You cannot mix shared and dedicated host platform server resources in the same LPAR. Tip: This property must be selected if you are requesting a virtual NIC resource. v Optional. Resource Group Name. A resource group is a logical group to which resources belong. For example, if you have multiple disks and you want to allocate them together, you can add them to a resource group. v Depending on the types of resources that you add to the template, you might be asked to specify the following properties:
Table 183. Resource type list Field Host Platform Quantity Description Host Platform Quantity: The amount of the host platform server resource that is allocated to this LPAR. For example, if you want to allocate 1200 MHz of CPU resource to the virtual server, enter 1200 for the Host Platform Quantity value. The host platform server must have more than 1200 MHz of CPU resource available. For each type of resource, the quantity is measured differently and refers to the quantity on the host platform server: v Hard Disk: Gigabytes (GB). v Memory: Megabytes (MB). v User defined resource: User-defined type. v CPU: MHz. Portion of the total CPU available. v Generic resource: No specific type.
1025
Table 183. Resource type list (continued) Field Virtual Quantity Description Virtual Quantity: The amount (size) of resource that is visible and available to the new LPAR. For example, for the CPU resource type, the Virtual Quantity value depends on whether you have indicated that the resource is Shared. v If you selected Shared, the CPU resource is shared with other virtual servers allocated to the host platform server. For example, you might type a Virtual Quantity value of 100 shares of the CPU resource on the host platform server. v If the CPU resource is not Shared, the CPU resource is dedicated to this virtual server. For example, you might type a Virtual Quantity value of 2. The virtual server behaves like it has 2 available CPUs. The host platform server must have more than 2 available CPUs in order for you to allocate 2 CPUs to the virtual server. For each type, the quantity is measured differently and refers to the quantity on the virtual server: v Memory: Megabytes (MB). v NIC: Only a whole NIC can be specified but there can be multiple NICs. v CPU: The number of virtual CPUs allocated to the virtual server. v Generic resource: No specific type.
For detailed information about the supported values for virtual quantity and host platform quantity, see section 5.0 Implementation and interfaces in the p-Series-Server automation package. LPAR automation package For more detailed information about LPARs, see the p-Series-Server automation package documentation. 1. Click Go To > Administration > Provisioning > Device Drivers. 2. In the Device Drivers list, type pSeries to see all the device drivers related to LPARs. 3. Click any device driver in the list to see details about the device driver, including a list of the workflows in the device driver. 4. Click the Documentation link that appears on same line as the device driver name, but on the right side of the window, to open a new browser window. Note: If you have software to block pop-up windows, it can interfere with the display of the new window. 5. Click the Automation Package link in the top left corner of the new window to view the general documentation about the package.
Managing virtualization with AIX WPARs

This topic provides reference information about managing virtual environments using AIX WPARs. It is meant as a quick reference for the requirements for managing virtualization. Also, it gives you at-a-glance information about the related automation package.
1026
WPAR quick reference AIX workload partitions (WPARs) are virtualized operating system environments within a single instance of the AIX 7.1 or 6.1 operating system that is defined on a host computer. They have no dependencies on hardware features. WPARs provide a solution for partitioning one AIX operating instance in multiple environments. Each environment, called a partition, can host applications and isolate them from applications running within other WPARs. Supported environments and operating systems You can manage virtualization on the following microprocessors: v IBM POWER7 server with AIX 7.1 v IBM POWER6 server with AIX 7.1 v IBM POWER7 server with AIX 6.1 v IBM POWER6 server with AIX 6.1 v IBM POWER5 server with AIX 6.1 v IBM POWER4 server with AIX 6.1 Hardware requirements Verify that the following requirements are met: v Credentials are configured on the host platform server. Configure SSH and SCP credentials (user ID root) so that the provisioning server can communicate with the host platform server to perform logical management operations. v Host platform resources The CPU, NIC, and RAM resources must be defined on the host platform server. These resources must all be marked as managed. v The WPAR host name must be created in DNS and must have an IP address associated. IP addresses for WPARs and LPARs must belong to the same subnetwork. Setting up the environment Use the following scenario to create your environment for AIX WPAR virtualization: 1. Discovery Use HMC discovery and Initial discovery (for LPARs) to identify the existing computers. 2. Add SSH/SCP credentials to the host platform server. To add credentials for a WPAR host platform: v Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. v Click the Credentials tab of the provisioning server. v Click Add Credentials, and then select SSH and SCP. v Specify the Search Key, User Name (root or a user who can run the sudo command), and Password/Passphrase (depending on the Password Credential/RSA Credential and its confirmation). Note: a. This is the root password when a WPAR is created. b. If the root login is disabled for SSH, and the LPAR does not have an agent service access point (SAP), a user that can run the sudo command is required on the WPAR host platform, to be able to run the following commands without providing a password: clogin, mkwpar, lswpar, chwpar, startwpar, stopwpar, rebootwpar, syncwpar, rmwpar. For more information, see Running provisioning workflow commands using sudo.
1027
If the root login is disabled for SSH, and the LPAR has the agent SAP, then the SSH/SCP SAP with password credentials for a user that can run sudo clogin is required. 3. AIX WPAR Discovery Run the WPAR discovery on the selected managed LPARs to discover all of the existing WPARs. This discovery adds the following resources to the WPAR virtual server: v CPU v Memory v NIC c. WPAR activities The following table details the types of virtualization activities that are supported for AIX WPARs. Important: For any of the activities below, the workflow fails if the WPAR name does not conform to the following rule: v Must be 1 - 63 characters long. v Must only contain letters 'a' through 'z' (not case-sensitive), the digits '0' through '9', and the hyphen. v Must begin with a letter. v Must end with a letter or a number. v The host name must be created in DNS and must have an IP address associated.
Table 184. Supported virtualization activities for WPARs Activity Create a WPAR virtual server. Details You can create a WPAR virtual server using the resources that are marked as management on a host platform server. Use a virtual server template to create a WPAR virtual server. The virtual server template specifies the size and types of resources that you allocate to the new virtual server. Dynamic resource allocation. Increase or decrease the amount of CPU and memory shares on the running WPAR virtual server by changing the resource allocation in the provisioning Web interface. Use the discovery configuration called AIX WPAR Discovery to discover all of the WPAR virtual servers defined on host platform servers. WPAR WPAR information, including operating system and resource allocation, are imported into the provisioning database. A provisioning workflow validates the WPAR to be powered on or off, performs the action, and then updates the state of the WPAR. Refresh to see this updated state. A provisioning workflow validates the WPAR to be rebooted, performs the action, and then updates the state of the WPAR . Refresh to see this updated state. A provisioning workflow validates the WPAR to be deleted, ensures that the WPAR is powered off, and powers it off if it is not already, and then deletes it. The provisioning data model is updated to remove the WPAR and all of its related objects. A provisioning workflow synchronizes software between a global system (LPAR) and a WPAR virtual server.
Discover WPARs
Power on and power off WPARs
Reboot WPARs
Delete WPARs
Synchronize WPARs
Virtual server template
1028
Use a virtual server template to create a WPAR. The virtual server template specifies the kinds and sizes of resources that you want to allocate to the new WPAR. You can add or change the resources in a virtual server template. When you add a new resource type, you can specify the following options: v Optional. Shared. This property indicates if the resource allocated from the host platform server must be dedicated to the new WPAR or if it can be shared with other WPARs. For WPARs, this property must be selected. If a resource is not shared with other WPARs, the corresponding resource on the host platform server is decremented when a WPAR is allocated. If the resource is shared with other WPARs, the corresponding resource on the host platform server is not decremented and the same resource can be simultaneously assigned to as many WPARs as needed. v Optional. Resource Group Name. A logical group that a resource belongs to. For example, if you want to allocate multiple disks to the WPAR, you can add them to a resource group so that they can be allocated at the same time. v Depending on the types of resources that you add to the virtual server template, you might be asked to specify the following properties:
Table 185. Resource type list Field Host Platform Quantity Virtual Quantity Description Host Platform Quantity: Disregard this property. It is not used for the creation of WPARs Virtual Quantity: The amount (size) of resource that will be visible and available to the new WPAR. For example, for the CPU resource type, the Virtual Quantity value depends on whether you have indicated that the resource will be Shared. v If you selected Shared, the CPU resource will be shared with other virtual servers allocated to the host platform server. For example, you might type a Virtual Quantity value of 100 shares of the CPU resource on the host platform server. v If the CPU resource is not Shared, the CPU resource is dedicated to this virtual server. For example, you might type a Virtual Quantity value of 2. In this case, thevirtual server has two available CPUs. The host platform server must have more than two available CPUs in order for you to allocate two CPUs to the virtual server. For each type, the quantity is measured differently and refers to the quantity on the virtual server: v Memory: Megabytes (MB). v NIC: Only a whole NIC can be specified but there can be multiple NICs. v CPU: The number of virtual CPUs allocated to the virtual server. v Generic resource: No specific type.
For detailed information about the supported values for virtual quantity and host platform quantity and the variables associated with them, see the Virtual server template information in the section called Implementation and interfaces in the AIX_WPAR_Virtual_infratructure automation package. AIX WPAR automation package For more detailed information about AIX WPARs, see the automation package documentation.
1029
1. Click Go To > Administration > Provisioning > Device Drivers. 2. In the Device Drivers list, type WPAR to see all of the device drivers related to AIX WPARs. 3. Click any device driver in the list and you will see details about the device driver including a list of the workflow's in the device driver. 4. Click the Documentation link that appears on same line as the device driver name, but on the right side of the window, to open a new browser window. Note: If you have a software to block pop-up windows, it might interfere with the display of the new window. 5. Click the Automation Package link in the upper left corner of the new window to view the general documentation about the package.
Managing virtualization with KVM

This topic provides reference information about managing virtual environments using KVM. This page also gives you at-a-glance information about the related automation package.
KVM quick reference Kernel-based Virtual Machine (KVM) is a full native virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). Limited support for paravirtualization is also available for Linux and Windows guests in the form of a paravirtual network driver. KVM is currently designed to interface with the kernel via a loadable kernel module. A wide variety of guest operating systems work with KVM, including Linux, BSD, Solaris, Windows, Haiku, ReactOS and AROS Research Operating System. A patched version of KVM is able to run on Mac OS X. Note: KVM does not perform any emulation itself. Instead, a user-space program uses the /dev/kvm interface to set up a guest virtual server's address space, feed it simulated I/O and map its video display back onto the host's display. Requirements These items are required to run KVM virtualization: v Tivoli Provisioning Manager, Version 7.1.1 or later v A KVM hypervisor running on Red Hat Enterprise Linux (RHEL) 6 or RHEL 5 Update 6 For KVM requirements, see KVM hypervisor requirements. v Libvirt Supported Operating Systems for KVM deployment
Table 186. Supported Operating Systems for KVM deployment OS Redhat Enterprise Linux (RHEL) 6, and 5 Update 6 KVM Support Fully supported for deployment and capture. Host name, IP address, and networking information included in the .tcdriver file can be configured. Only support for deployment and capture. No support for configuration.
Other Linux Operating Systems (SLES)
1030
Table 186. Supported Operating Systems for KVM deployment (continued) OS Windows KVM Support Only support for deployment and capture. No support for configuration.
Supported guests A KVM hypervisor running on Red Hat Enterprise Linux (RHEL) 6 or RHEL 5 Update 6 supports the guests listed in the topic called Virtualization Support in Red Hat Enterprise Linux: http:// www.redhat.com/rhel/server/advanced/virt.html Setting up the environment (KVM-side) Before a Tivoli Provisioning Manager administrator can manage a KVM hypervisor and its virtual servers, the following tasks must be completed successfully: 1. Installing KVM Red Hat Enterprise Linux (RHEL) 6 or 5 Update 6 For RHEL 6 installation information, see the Red Hat Installation Guide at http://docs.redhat.com/ docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/index.html. For selecting general internet usage tasks: a. Select Virtualization, and click Next. b. Clear Virtualization (Xen package) and select KVM. c. (Optional) To customize the KVM installation, click Optional packages. 2. Creating a virtual server Create a new virtual server that can be discovered by Tivoli Provisioning Manager as a KVM master image. You can create a new virtual server using one of two methods: Using Virt-manager (GUI) a. To start the virtualization management tool, run the virt-manager command b. Click localhost. c. Click New and follow the step-by-step wizard. Note: Sharing a directory structure for virtual servers and master images is not supported. When specifying the master image directory to store the virtual machine, the default directory where the virtual machine is stored will be images/. Be sure to add two additional levels to the images directory to house the master image. For example, /var/lib/libvirt/images/imageDirectory1/ imageDirectory2/imageName.img. Using Virsh (command line) v For all procedures, including virtual machine creation using Virsh, refer to Chapter 24. Managing guests with Virsh in the Red Hat Enterprise Virtualization Guide. v To install Windows XP as a fully virtualized guest, refer to the Red Hat Installation Guide. 3. Create an XML data dump file for the virtual machine v Use Virsh to perform a data dump for an existing virtual machine. For the full procedure, see the Red Hat documentation: Configuring an XML dump section of the Red Hat Installation Guide. 4. (Optional) Enable the installation of the virtual server to a non-default location Note: If the Security-Enhanced Linux (SELinux) feature is enabled, ignore these steps. SELinux uses /var/lib/libvirt/images as the default location. If SELinux is disabled, perform the following steps to set a non-default directory for virtual image installation:
1031
a. To set the correct SELinux type for the KVM folder, run cmd # semanage fcontext -a -t virt_image_t "/myfolder(/.*)?". b. To change the mount point from /virtstorage and all files contained to virt_image_t (restorecon and setfiles read the files in /etc/selinux/targeted/contexts/files/), run # restorecon -R -v /myfolder. For the full procedure, refer to Chapter 11. Security for virtualization of the Red Hat Installation Guide. Managing guests using Virsh v For the full procedure, refer to Chapter 24. Managing guests with Virsh in the Red Hat Enterprise Virtualization Guide. Network Configuration You can use two methods to share network connections: Network address translation (NAT) forwarding (also know as virtual networks), characterized by: v private network, 192.168.x.x v inaccessible from outside networks v able to access outside networks securely v For the full procedure, refer to Chapter 12. Network Configuration of the Red Hat Installation Guide. Bridged networking (also known as physical device sharing), characterized by: v Public network v For the full procedure, refer to Chapter 12. Network Configuration of the Red Hat Installation Guide. Setting up the environment (Tivoli Provisioning Manager-side) 1. Discover a server that hosts a KVM hypervisor. To discover a server that hosts a KVM hypervisor, use Initial Discovery. Note: A server object that hosts a KVM installation and an OS installation must exist before you can run discovery. 2. Install a file-based boot server The file-based boot server is used to capture and deploy master disk images of virtual servers. All disk images captured by this boot server are stored in the specified data directory on the endpoint that hosts a boot server installation. There can be multiple instances of the file-based boot server. The operating system of the endpoint that hosts the file-based boot server must be Linux. For the file-based boot server to capture a master image from a KVM virtual server, the virtual server must have an operating system software installation defined. The operating system must be either Windows or Linux. The recommended way to add the OS is either by running the Network Discovery or an Inventory Scan on the virtual server. Important: Since disk images are transferred from and to a file-based boot server, host and client SAPs must be defined under the system that hosts a file-based boot server installation. For information about how to add the client SAP to a file-based boot server, click here. To install a file-based boot server: a. From the Tivoli Provisioning Manager web interface, navigate to GoTo > Deployment > OS Management > Boot Server Installation. b. In the Task field, enter a descriptive name for the file-based boot server, or leave auto-generated name. c. In the Target Computer field, select a Linux system to be used as the file-based boot server.
1032
d. In the Boot Server Type field, select File-Based. e. In the Image Directory field, specify the directory on the target computer where the disk images are to be stored. The files for each image are contained in its own subdirectory under the data directory. f. Click Submit to initiate the installation task. This task does not install any software on the target computer. Instead, it creates the boot server object and attaches a file-based boot server software installation on the target computer. A KVM image repository is created with the same name as the target computer. The data directory is stored in the repository location of the image repository. The data directory may be remote, but it would must be network mounted in that case. Note: It is possible to select the KVM computer as the target computer for the file-based boot server. This makes the file-based boot server local to the KVM host platform. You must ensure that the data directory specified does not conflict with the location where the disk images of the virtual servers reside. The virtual servers must reside in a different path from where the file-based boot server stores the master images. This is to prevent the master images from overwriting the virtual server images and vice versa. 3. Discover a KVM hypervisor The discovery task starts an inventory scan on the target computer to update the hardware and software inventory in the data model. The discovery then creates a host platform of type KVM and attaches a device model to the host platform. Finally, the virtual server discovery is started to import all the virtual servers in the KVM host platform into the data model. Once the KVM host platform is created, it is possible to start just the virtual server discovery without starting the host platform discovery using the Libvirt Virtual Hosts Discovery discovery configuration. a. From theTivoli Provisioning Manager web interface, navigate to Go To > Discovery > Provisioning Directory > Discovery Configurations. b. Locate and click on the Libvirt HostPlatform Discovery discovery configuration. c. Click Run Discovery. d. In the Selected Targets section, click Select > Computers and select the system you discovered in step 1. Click OK. e. Click Submit. Once the discovery task completes, the data model records are synchronized and you can proceed with administrative tasks. Note: When the file-based boot server is installed on the KVM server itself, the re-execution of the Libvirt Host Platform Discovery removes the boot server entry from the Software tab of the KVM host, which makes the boot server nonfunctional. To resolve this issue, manually add an entry for the File-Based Boot Server for KVM and XEN Images to the Software tab of the KVM Server. 4. Discover Libvirt master image a. From the Tivoli Provisioning Manager web interface, navigate to GoTo > Discovery > Provisioning Directory > Discovery Configurations. b. Locate and click on the Libvirt Boot Server Virtual Images Discovery discovery configuration. c. Click Run Discovery. d. In the Selected Targets section, click Select > Computers and select the system you discovered in step 1. Click OK. e. Click Submit. 5. Add an SSH SAP client to the KVM hypervisor and the file-based boot server a. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. b. In the list, click the virtual server that houses the KVM hypervisor.
1033
c. Click the Credentials tab. d. Click Add Credentials > New Service Access Point. e. Populate the following fields (in the Details tab):
In this field... Service Access Point Protocol Type Context Application Protocol Domain Port Do this... Enter the name of the SAP, for example, SSH-Client. Select Network Protocol IP from the drop-down menu. Leave as NOCONTEXT. Select Remote Shell Execution from the drop-down menu. Leave blank. Enter any non-zero value. Ports are not used for client SAPs.
f. Make sure the Host check box is NOT selected. g. Click New Password Credential to define a new password for the SAP. h. Populate the following fields:
In this field... Search Key User Name Password Confirm Password Do this... Enter Master. Enter the user name used to login to the virtual server. Enter the password used to login to the virtual server. Re-enter the password used to login to the virtual server.
i. Click the Workflows tab j. Click >> against Currently Assigned Device Driver and select Select Value. The Select Value dialog displays. k. Enter SSH Service Access Point in the field provided and click Enter. l. Click SSH Service Access Point. m. Click the Save icon. Note: Verify that the added SSH SAP client is listed on the Credentials tab of the KVM server. 6. Create Image Repository Image repositories are used to specify the location where virtual server disk images, master, and saved disk images are stored. To create an image repository: a. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Image Library > Image Repositories. b. From the Select Action drop down menu, select New KVM Repository. c. In the Repository field, enter a name for your KVM image repository. d. e. f. g. h. (Optional) In the Description field, enter a short description for your KVM image repository. (Optional) In the Available Space field, enter, in megabytes, the space available to the repository. (Optional) In the Total Space field, enter, in megabytes, the total space reserved for the repository. (Optional) In the Created By field, enter your user name. Select the following to specify the type of images to be stored in the repository:
1034
Setting Master Images Enabled
Description For master enabled images, the repository location is used to associate the repository with the boot server. The directory is the location where the images are stored. For instance and saved enabled images, a mount point is used to specify the location on the host platform where these images are stored. All saved and instance images are stored locally on the host platform. They can be stored on a local file system or be network mounted. A mount point must be created for each host platform in order to use the image repository.
Saved Images Enabled Instance Images Enabled
Note: The file-based boot server installation creates an image repository that is maser image enabled by default. It is recommended that you keep the instance images in a separate repository from the master and saved images. A separate image repository is to be created for instance images, saved image, and master images. If these are on the same server, they are to point to a different location. i. Click Submit to save the image repository. Supported Activities The following table describes the types of activities supported for KVM virtualization technology.
Table 187. Supported virtualization activities for KVM Activity Access guests from the KVM console Details Access the guests using virt-manager. For more information refer to Chapter 23. Managing guests with the Virtual Machine Manager of the Red hat Installation Guide. You can also use Virtual Network Computing (VNC) locally or remotely. For security reasons, remote access is disabled by default. You can enable remote access by setting VNC to listen on all public network interfaces (address 0.0.0.0) using the following procedures: v From virt-manager, click the Hardware tab. v Remove the default display and add a new graphic. v Check listen on all public network interface. or... v in the xml file, change the following: graphics type=vnc port=5900 autoport=yes listen=0.0.0.0 keymap=en-us/ Discover the server that hosts the KVM hypervisor Discover the KVM hypervisor See Discover a server that hosts a KVM hypervisor. See Discover the KVM hypervisor
1035
Table 187. Supported virtualization activities for KVM (continued) Activity Create a virtual server Details You can chose to create a new virtual server on a KVM hypervisor managed by the Tivoli Provisioning Manager. Before you can do this, you need a Virtual Server Template (VST) definition, which contains the resource requirements such as the amount of memory, cpu, disk space to allocate to the virtual server. The sample VST called KVM Sample VST can be used as a reference. Optionally, you can specify a software stack so that it gets installed automatically after the virtual server is created. VSTs that are associated to an image ("KVM Image <VST name>") automatically install the associated software stack even if a software stack is not selected. To create a virtual server: 1. From the Tivoli Provisioning Manager web interface, navigate to GoTo > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click a KVM host platform. 3. Click Create Virtual Server. 4. In the Virtual Server field, enter either a short host name or a fully qualified host name. 5. In the Virtual Server Template field, virtual server template. 6. In the Software Stack field, stack of an OS image. select a
select a software
7. In the Variables section, go to the target.folderpath variable and enter the directory where the virtual machine images are stored in the Value field. Do not use a directory where master images are stored. 8. Click OK to start the image deployment task.
1036
Table 187. Supported virtualization activities for KVM (continued) Activity Capture virtual server image (file-based boot server operation) Details To capture a disk image from an existing virtual server, follow these steps: 1. From the Tivoli Provisioning Manager web interface, navigate to GoTo > Deployment > OS Management > Image Capture. 2. In the Source Computer field, select a virtual server from which to capture a disk image. 3. In the Boot Server Type field, select File-Based.
4. In the Image field, enter the name for the image. 5. Click Select Boot Server, and click a file-based boot server from the list. 6. Click Submit. Upon a successful completion of the image capture task, the following data model objects are created: v Image - a Tivoli Provisioning Manager representation of a disk image captured from a source computer. v Software Stack - a collection of software resources from a source computer. v Software Stack Entries - a set of cloned software resources from a source computer. There must be at least one OS installation stack entry from a source computer. v Software Stack Template - a placeholder template attached to the software stack. v Master Image Library Entry - a master image library entry with additional information such as hypervisor, image repository, and repository relative path. Deploy virtual server image (file-based boot server operation) Important: A root password change and a network (re)configuration are supported only for RedHat RAW images in the automation package release. For all other OS distributions and image formats, such as cow, qcow, and qcow2, the root password and network configuration are ignored. To deploy a disk image to an existing virtual server perform these steps: 1. From the Tivoli Provisioning Manager web interface, navigate to GoTo > Deployment > OS Management > Image Deployment. 2. In the Selected Image section, click Select Image and, from the Select Value dialog, select the image to deploy. 3. In the Selected Targets section, click Select > Computers and select a target virtual server to which the image is deployed. 4. Click Submit to start the image deployment task.
1037
Table 187. Supported virtualization activities for KVM (continued) Activity Clone a virtual server and re-configure it Details To clone a KVM: 1. From theTivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click a KVM host platform. 3. Place a checkmark next to a chosen virtual server. 4. Click Management > Clone 5. Specify the name of the new server in the New Virtual Server field. 6. Click to select the VST on which the new virtual server is based. 7. Click OK. The new virtual server is created on the same hypervisor as the source virtual server. The disk files from the source virtual server are copied to the new virtual server. Power a virtual server from the KVM hypervisor on and off To turn a virtual server on and off from the KVM hypervisor: 1. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click a KVM host platform. 3. Place a checkmark next to a chosen virtual server. 4. Click Management. v To turn off the virtual server, go to Manage > Power Off. v To turn on the virtual server, go to Manage > Power On. Restart a virtual server from a KVM hypervisor To restart the virtual server from the KVM hypervisor: 1. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click the KVM host platform. 3. Place a checkmark next to a chosen virtual server. 4. Click Management and go to Manage > Generic Restart. Delete a virtual server from a KVM hypervisor. To delete the virtual server from the KVM hypervisor, follow this procedure: 1. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click the KVM host platform. 3. Place a checkmark next to a chosen virtual server. 4. Click Management and go to Delete.
1038
Table 187. Supported virtualization activities for KVM (continued) Activity Move a virtual server to another KVM hypervisor Details When moving a virtual server to another KVM hypervisor, the virtual server is defined and the disk files are transferred to the target hypervisor. A device.copy operation is used to transfer the disk files between the hypervisors. This operation requires that the source host platform in Tivoli Provisioning Manager contains a defined client SSH SAP. To move a virtual server to another KVM hypervisor, follow this procedure: 1. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click the KVM host platform. 3. Place a checkmark next to a chosen virtual server. 4. Click Management and go to Move. Adjust resource allocation to a virtual server For the detailed instructions on allocating resources, see the topic called Changing resource allocations on a virtual server.When you change the resource allocations of a virtual server, click OK to save your changes. Note: Administrator users will see a Save Only option for resource changes. Save Only updates the values in the provisioning database only. OK updates the provisioning database and the virtual server in the KVM hypervisor. Increasing the hard disk size: Increasing the size of the virtual disk is done on the host platform server, not the virtual server. The disk size can only be increased, it cannot be reduced. 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select the host platform server that hosts the virtual server that you want to resize the hard disk on. 3. Beside the virtual server, click the Detail Menu and select Resource Allocations. 4. In the table, find the hard disk, for example hdd0, and change the Host Platform Size. 5. Click OK. Confirm the resource allocation change. A provisioning workflow is launched. If the virtual server is running, it will be stopped before the disk is resized and then powered back on when the resize is complete. Suspend virtual server There is no Tivoli Provisioning Manager web interface action used to suspend a virtual server. To suspend a virtual server, run the workflow "Libvirt_VirtualMachine_Suspend". For more information about workflows, see Running provisioning workflows from the Web interface..
1039
Table 187. Supported virtualization activities for KVM (continued) Activity Resume virtual server Details There is no Tivoli Provisioning Manager web interface action used to resume a suspended virtual server. To resume a suspended virtual server, run the workflow "Libvirt_VirtualMachine_Resume". For more information about workflows, see Running provisioning workflows from the Web interface..
Managing IBM System p virtualization with VMControl

This topic provides reference information about managing IBM System p virtual environments using VMControl. This page also gives you at-a-glance information about the related automation package.
VMControl quick reference VMControl is a plug-in of IBM Systems Director. IBM System p virtualization and image management can now be managed using VMControl. In previous Tivoli Provisioning Manager versions, IBM System p virtualization was managed solely using Hardware Management Console (HMC) commands. Image management was done solely by directly calling the Network Installation Management (NIM) computer. These methods are still available, however, VMControl provides an alternative way to provide the virtualization and image management function. Requirements These items are required to use VMControl with Tivoli Provisioning Manager:
Table 188. Requirements Requirement Tivoli Provisioning Manager Host platform server VMControl (on IBM Systems Director) IBM Systems Director Image Hardware Management Console (HMC) Version Version 7.2 or later POWER7 CECs, POWER6, or POWER5 Version 2.3.1.2 Version 6.2.1.2 Single LPAR AIX 7.1 SP1 or AIX 6.1 or AIX 5.3 v POWER7: V7R7.1.0 or later v POWER6 and POWER5: V7R 3.5.0 or later Virtual I/O Server (VIOS) POWER firmware (POWER7 or POWER6 or POWER5) 2.1.0 or later v POWER7: firmware 7.1 or later v POWER5 and POWER6: firmware 3.5 or later
For more information about VMControl, see the section on VMControl V2.3 in the IBM Systems Director Information Center: http://publib.boulder.ibm.com/infocenter/director/v6r2x/index.jsp?topic=/ com.ibm.director.vim.helps.doc/fsd0_vim_main.html Setting up the environment
1040
Before a Tivoli Provisioning Manager administrator can manage IBM System p computers using VMControl, the following tasks must be completed: 1. Creating a VMControl computer. 2. Copying the SSL certificate from IBM Systems Director to the provisioning server. 3. Creating a service access point on the VMControl virtual server on page 1042. 4. Registering a VMControl boot server on page 1043. 5. Verifying that the VMControl boot server exists on page 1043. 6. Running the VMControl discovery on page 1043.
Creating a VMControl computer

1. 2. 3. 4. Click Go To > Deployment > Provisioning Computers. From the Select Action menu, choose Add Computer. In the Computer field, type the VMControl computer host name as it appears in the SSL certificate. (Optional) Enter the required information in the fields provided. .
5. Click Save
The computer is added to the provisioning database. This computer represents the VMControl virtual server.
Copying the SSL certificate

Use one of the following two methods to configure your IBM Systems DirectorVMControl SSL certificate: Method 1: Specify the SSL truststore file in the credential of the HTTPS SAP on the VMControl computer 1. Copy the IBM Systems Director VMControl keystore to the provisioning server. The keystore file of the VMControl virtual server is in
$DIRECTOR_HOME\\lwi\\security\\keystore\\ibmjsse2.jks
2. Specify the following items to create the credentials for the key file on the provisioning server: v Path v User name v Password v Key fingerprint of the truststore file If you use this method, you must specify the SSL key file when you create the service access point on the VMControl computer. Method 2: Import the IBM Systems Director VMControl SSL certificate to the default Java truststore file. Note: You must restart the provisioning server. 1. Copy the keystore to the provisioning server. 2. Run the following commands to extract and then import the certificate: a. Run the following command:
Windows
%TIO_HOME%\tools\setupCmdLine.cmd
UNIX
cd $TIO_HOME/tools . ./setupCmdLine.sh echo $JAVA_HOME
1041
b. Change the directories:
Windows
cd %JAVA_HOME%\jre\lib\security
UNIX
cd $JAVA_HOME/jre/lib/security
c.
UNIX
Change to the root user ID before running the keytool command:
su root
d. Ensure that the keytool command is accessible from your path. You can test this by typing keytool at the prompt. If the keytool command does not run, update the environment PATH variable with the directory that contains the keytool command. v
Windows
Tivoli Provisioning Manager Fast Start Version:
set PATH=%PATH%;"%JAVA_HOME%\bin
v Tivoli Provisioning Manager Enterprise Version:

set PATH=%PATH%;"%JAVA_HOME%\jre\bin
UNIX
export JAVA_HOME= to the value returned by echo $JAVA_HOME from the tioadmin
session export PATH=$PATH:$JAVA_HOME/jre/bin e. Run the commands to import the certificate:

keytool -export -alias lwiks -storepass ibmpassw0rd -file client.cer -keystore <ibmjsse2.jks_location>
where ibmjsse2.jks_location is the location of the file on the provisioning server.

keytool -import -v -trustcacerts -alias lwiks -file client.cer -storepass changeit -keystore cacerts
3. Start the provisioning server again.
Creating a service access point on the VMControl virtual server

To add an HTTPS SAP to the VMControl virtual server, complete the following steps: Note: For HTTPS, ensure that the SSL certificate has already been imported. For information about how to import an SSL certificate, see the topic called Importing the SSL certificate on page 1064. 1. Click Click Go To > Deployment > Provisioning Computers.. 2. In the list, locate and select the VMControl virtual server that you created. 3. Click the Credentials tab. 4. From theSelect Action menu, click Add Credentials > New Service Access Point. 5. Under the Details tab, complete the following fields: a. Service Access Point: Type the name of the new service access point. b. Protocol Type: Select Network protocol IP. c. Application Protocol: Select HTTP Secure Access. d. Port: Type the port number that is used by the IBM Systems Director API. The default port number used is 8422 e. Select Authentication. f. Click New Password Credential. g. For the Search Key, type VMC. h. Enter a User Name, and Password that match the set used for the IBM Systems Director API. Tip: It is recommended that you use root or administrator for the User Name in order to be able to discover all targets.
1042
i. Optional. In the Key Fingerprint field, type the location of the SSL key file. If you used Method 1 in the Copying the SSL certificate on page 1041 task, the Key Fingerprint must be specified. IBM Systems Director generates an SSL key file when installed. Copy this file from the IBM Systems Director directory to the Tivoli Provisioning Manager directory specified in the Key Fingerprint field. j. Confirm the passwords. v In the Password and Confirm Password fields, type the passwords for the User Name (for example, root or administrator) on the VMControl computer. v Optional. In the Enable Password and Confirm Enable Password fields, enter the password used for the SSL key file. If you used the default SSL key, the password is ibmpassw0rd. If you used Method 1 in the Copying the SSL certificate on page 1041 task, the Key Fingerprint must be specified. 6. Click Save .
Registering a VMControl boot server

1. Click Go To > Deployment > OS Management > Boot Server Installation. 2. Beside the Target Computer field, click Detail Menu VMControl virtual server that you created. > Select Value and select the
3. Beside the Boot Server Type field, click Select Value 4. Click Submit. The VMControl boot server is registered.
and choose VMControl.
Verifying that the VMControl boot server exists

1. Click Go To > Deployment > OS Management > Boot Servers.. 2. Search for your newly created VMControl boot server to verify that it exists.
Running the VMControl discovery

Run a discovery on the VMControl virtual server so that you can run VMControl workflows, and to make information from your VMControl virtual server known to the data model. Note: If host platform servers have already been discovered using the IBM Hardware Management Console (HMC) Discovery, after running the VMControl Discovery, the pSeries host type will automatically change from LPAR to VMControl for the host platform servers displayed under Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. To run discovery on the VMControl virtual server, follow the steps below: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. Find the discovery configuration called VMControl Discovery and click it. and expand the VMControl Computer Name Discovery Parameter. 3. Click Filter 4. In the Value field, type the VMControl computer name that you created. 5. Click Run Discovery. 6. From the Run Discovery screen, click Submit. 7. After the discovery process is complete, click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management to view the specifics of all discovered VMControl host platform servers.
1043
Supported VMControl activities

The following table describes the types of activities supported by VMControl.
Table 189. Activities supported by VMControl.
Activity Discovering the following objects on VMControl computers: v virtual system pools v host platform servers v virtual servers v virtual server templates Creating a virtual server. You can create a new virtual server using VMControl. Before you can do this, you need a virtual server template definition, which contains the resource requirements such as the amount of memory, CPU, and disk space to allocate to the virtual server. For more information, see the section on VMControl virtual server templates on page 1047. When you create a virtual server, a bare metal computer will be created. No image will be deployed on the computer. To create a virtual server, follow the steps below: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management.. 2. Select a VMControl host platform server. 3. Click Create Virtual Server. 4. In the Virtual Server field, type a name for the virtual server. 5. In the Virtual Server Template field, click Select Value VMControl_Power_System_Create_Server_From_Host. 6. Click OK to start the provisioning task. and select the virtual server template called Details Tivoli Provisioning Manager VMControl discovery discovers all virtual servers defined in a VMControl computer and generates two virtual server templates for each virtual appliance. For more information, see the section called Running the VMControl discovery on page 1043.
1044
Table 189. Activities supported by VMControl. (continued)

Activity Capturing a virtual server image. Details A virtual server is recognized as a capture candidate only after its basic hardware and operating system information is made known to the VMControl computer. A discovery that uses a fully qualified host name, and an operating system access request operation that uses the root login ID and password are used to prepare a virtual server for VMControl capture.This is done using the VMControl interface or using the VMControl_Request_System_Access Tivoli Provisioning Manager provisioning workflow. Before running this provisioning workflow, ensure the following items: v The root ID and password of the virtual server (capture candidate) are defined as an SSH credential of Tivoli Provisioning Manager virtual server with search key value of VMC
v The IP address of the virtual server is set for the target computer. v The computer state is running. Note: A virtual server deployed using VMControl, by default, is not a capture candidate. To capture a disk image from an existing virtual server, follow these steps: 1. Click Go To > Deployment > OS Management > Image Capture. 2. Beside Source Computer, click Select Value image. 3. Beside Boot Server Type, click Select Value 4. In the Image field, type the name for the image. 5. Click Select Boot Server, and click a file-based boot server from the list. 6. Click Submit. When the image capture task is complete, the following data model objects are created: v Image - a Tivoli Provisioning Manager representation of a disk image captured from a source computer. v Software Stack - a collection of software resources from a source computer. v Software Stack Entries - a set of cloned software resources from a source computer. There must be at least one OS installation stack entry from a source computer. v Software Stack Template - a placeholder template attached to the software stack. v Master Image Library Entry - a master image library entry with additional information such as hypervisor, image repository, and repository relative path. v Virtual server templates - two are created. One to deploy from the host computer, and one for deploying from the VSP. and choose a virtual server from which to capture an
and select VMControl.
1045

Activity Deploying an image to an existing virtual server. Details The image and the virtual server must be managed by the same VMControl computer. The deployment requires that you provide the NIC and VLAN configuration in the virtual server template. To do this: 1. Click Go To > IT Infrastructure > Image Library > Master Images. 2. Select a master image. 3. Beside Virtual Server Template , click Detail Menu and chose Go To Virtual Server Templates.
4. Add the following information to the NIC Resource Type. v Is management?(Yes or No).value - Use this parameter to set the NIC resource type as the Tivoli Provisioning Manager management interface. v product.aim_fvt_mymksysb.com.ibm.ovf.vim.2.networkport.4.ip - Use this as the IP address of the virtual server. v product.aim_fvt_mymksysb.com.ibm.ovf.vim.2.networkport.4.netmask - Use this as the netmask address of the virtual server. v product.aim_fvt_mymksysb.com.ibm.ovf.vim.2.networkport.4.gateway - Use this as the getaway address of the virtual server. 5. Add VLAN mapping information under Generic Resource Type. v virtualnetworks - The VLAN ID to which the virtual server belongs. 6. Click Save .
The target computer must satisfy all the hardware resources, such as CPU, memory, and disk that are specified in the Open Virtualization Format (OVF) of the image. The recommended requirements can be found in the virtual server template of the image that is generated during VMControl discovery. To deploy a disk image to an existing virtual server, complete these steps: 1. Click Go To > Deployment > OS Management > Image Deployment. 2. In the Selected Image section, click Select Image and, from the Select Value dialog, select the image that you want to deploy. 3. In the Selected Targets section, click Select > Computers and select a target virtual server to which the image is deployed. 4. Click Submit to start the image deployment task. Powering virtual servers on and off. To turn a virtual server on and off: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click a VMControl host platform server. 3. Place a checkmark next to the virtual server that you want to power on or off. 4. Expand Management. v To turn off the virtual server, click Manage > Power Off. v To turn on the virtual server, click Manage > Power On. Deleting virtual servers. To delete a virtual server, follow these steps: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select a VMControl host platform server. 3. Place a checkmark next to the virtual server that you want to delete. 4. Click Management > Delete. To delete multiple virtual servers from the data model at the same time, see Deleting a virtual server on page 1077.
1046

Activity Allocating resources to virtual servers. Details For the detailed instructions on allocating resources, see the topic called Changing resource allocations on a virtual server.When you change the resource allocations of a virtual server, click OK to save your changes. Note: Administrator users will see a Save Only option for resource changes. Save Only updates the values in the provisioning database only. OK updates the provisioning database and the virtual server. Customizable variables for adjusting resource allocation of a virtual server. CPU: v virtual size v hostplatform size v cpupriority.value CPU properties that can only be modified when the virtual server is stopped: v maxcpu.value v mincpu.value v maxcpushare.value v mincpushare.value v mincpu.value Memory: v hostplatform size Memory properties that can only be modified when the virtual server is stopped: v maxmem.value v minmem.value
VMControl virtual server templates

When you run VMControl discovery, two virtual server templates are generated for each virtual appliance that is discovered. One virtual server template is used to deploy the virtual server to a virtual system pool. The second virtual server template is to deploy the virtual server to a host platform server. The generated virtual server templates contain the recommended CPU, memory and disk requirements used to deploy the virtual server. The CPU requirement for the virtual server or the host platform server. The memory requirement for the host platform server can be overridden when you create the virtual server and then deploying it in one operation. When you deploy a virtual server to a host platform server, the poolstorages.value must be defined with a disk resource that belongs to the resource group calledpoolstorages, which represents either a storage pool or a volume group of the host platform server. When you deploy a virtual server to a virtual system pool, there is no need to pick the storage pool or a volume group. NIC and Generic resource requirements depend on how many virtual NICs and networks are defined for the virtual server. Note: Resource requirements are generated based on the virtual server definition. Manually adding or removing a requirement is not supported.
Virtual server template parameters

The following virtual server template parameters can be used and customized when creating a VMControl virtual server on IBM System p. Note: When Tivoli Provisioning Manager reconfiguration routines are used, only one interface is supported.
1047
Table 190. virtual server template parameters used when creating a VMControl virtual server on IBM System p.
Parameter Resource Requirement - NIC networks <empty> The VLAN ID configured in IBM System p. The possible values are found in the others resource tab of the IBM System p that have the resource group name called networks. Value (default) Description
Resource Requirement - CPU maxcpu.value <empty> The maximum number of virtual processors allowed. The possible values are found in the cpu resource tab of the IBM System p host platform server. The minimum number of processing units allowed. The possible values are found in the cpu resource tab of the IBM System p host platform server. The maximum number of virtual processors allowed. The possible values are found in the cpu resource tab of the IBM System p host platform server. The minimum number of virtual processors allowed. The possible values are found in the cpu resource tab of the IBM System p host platform server. The CPU priority ID. Possible values are: v 1 - None (capped) v 64 - Low (64) v 128 - Medium (128) v 255 - High (255) Resource Requirement - MEMORY maxmem.value 1024 The maximum memory in MB allowed. The possible values are found in the memory resource tab of the IBM System p host platform server. The minimum memory in MB allowed. The possible values are found in the memory resource tab of the IBM System p host platform server.
mincpu.value
<empty>
maxcpushare.value
<empty>
mincpushare.value
<empty>
cpupriority.value
-1
minmem.value
256
Adjusting the timeout value for a VMControl job

VMControl creates a job to complete a management action. The provisioning server monitors the job execution for a duration of a defined timeout time frame. The default timeout value for a simple job is 15 minutes. Simple jobs are tasks such as creating an empty server or changing a resource allocation. For a complicated job, such as deploying or capturing an image, the timeout value is 90 minutes. To customize the timeout value, follow these steps: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Select the VMControl computer that you have created. 3. On the Variables tab, change the timeout value, where the component is Entire System. Do not reduce the timeout value too much. If the value is too low, the provisioning server might stop monitoring the progress of the job and report a failure, even though the job is still in progress and can succeed.
Uninstalling the VMControl virtual infrastructure automation package

To uninstall the automation package, follow the steps below: 1. Delete the VMControl discovery configurations. a. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations.
1048
b. In the Discovery Configurations list, find the VMControl discovery. c. Highlight the discovery configuration by clicking the row. to remove the discovery configuration. d. Click Delete 2. At a command prompt, change the directory to TIO_HOME/tools. 3. Run the command to delete the automation package:
Windows
tc-driver-manager.cmd uninstallDriver VMControl_Virtual_Infrastructure

UNIX
tc-driver-manager.sh uninstallDriver VMControl_Virtual_Infrastructure
Managing virtualization with Hyper-V

This topic provides reference information about managing virtual environments using Hyper-V. This page also gives you at-a-glance information about the related automation package.
Hyper-V quick reference Hyper-V is a Microsoft technology that provides a virtualization platform to dynamically manage both physical and virtual resources. Using Hyper-V, you can migrate running virtual machines from one physical computer to another, and add or remove storage from a virtual machine while it is running. New with Tivoli Provisioning Manager 7.2.0.1 (7.2 Fix Pack 1), the HyperV_Virtual_Infrastructure automation package makes it possible for Hyper-V host platform servers and their virtual machines to be managed through Tivoli Provisioning Manager. Requirements The following are the requirements to use Hyper-V with Tivoli Provisioning Manager:
Table 191. Supported operating systems and technology versions for Hyper-V virtualization Requirement Tivoli Provisioning Manager System Center Virtual Machine Manager (SCVMM) Hyper-V Supported guest operating systems Supported Version Version 7.2.0.1 (7.2 Fix Pack 1) and later Windows Server 2008 R2 - Datacenter or Enterprise or Standard edition Windows Server 2008 R2 - Datacenter or Enterprise or Standard edition Versions: v Windows Server 2008 R2 - Datacenter or Enterprise and Standard edition v Windows Server 2008 - Datacenter or Enterprise and Standard edition, 32-bit and 64-bit v Windows Server 2003 - Enterprise and Standard edition, 32-bit and 64-bit Note: For Windows Server 2003, ensure that the integration service is installed on the guest operating system, to enable SCVMM to communicate with the guest operating system. See the Microsoft documentation for more details.
1049
For more information about Hyper-V, see the documentation for the HyperV_Virtual_Infrastructure automation package. Setting up the environment Before a Tivoli Provisioning Manager administrator can manage virtual servers using Hyper-V, the following tasks must be completed. Hyper-V setup On the SCVMM host, complete the following steps: 1. Enable the Hyper-V role on the Windows 2008 Server. 2. Ensure that Microsoft Active Directory is installed on the SCVMM server. All the Hyper-V hosts must belong to the same domain. 3. Install Microsoft System Center Virtual Machine Manager 2008 R2 (usually referred to as SCVMM 2008 R2 or SCVMM 4). 4. Enter the following command to update the PowerShell execution policy on the SCVMM host to RemoteSigned (or UnRestricted, if required):
Set-ExecutionPolicy RemoteSigned
Tivoli Provisioning Manager setup On Tivoli Provisioning Manager, complete the following steps: 1. Configure the RXA discovery to discover the Windows 2008 R2 server that hosts the SCVMM, using the domain account. If SCVMM is running on a virtual machine, the RXA discovery must be run against the virtual machine. 2. Run the RXA discovery and verify that the task completes successfully. 3. Run the Hyper-V SCVMM discovery. Specify the provisioning computer discovered in step 2 as a target. This task discovers the information about all the Hyper-V hosts, virtual servers, and templates that are controlled by the target SCVMM. Supported activities The following table describes the types of activities supported with the Hyper-V virtualization technology.
1050
Table 192. Supported virtualization activities for Hyper-V Activity Create a virtual server Details You can choose to create a new virtual server on a Hyper-V hypervisor managed by the Tivoli Provisioning Manager. Before you can do this, you need a virtual server template definition, which contains the resource requirements such as the amount of memory, CPU, and disk space to allocate to the virtual server. When creating a new virtual server, you must specify a virtual server template. When the virtual server template is not associated with any SCVMM template, the hardware resource definition in the virtual server template will be used to create a new, empty virtual server. When you create a virtual server, a bare metal computer will be created. No image will be deployed on the computer. To create a virtual server: 1. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click a Hyper-V host platform. 3. Click Create Virtual Server. 4. In the Virtual Server field, type a name for the virtual server. 5. In the Virtual Server Template field, virtual server template. 6. Click OK to start the provisioning task. Note: For virtualization management, the Software Stack field enables you to select the software image for deployment. But in order to install an application software, for example, the TCA stack, you must use the server provisioning application: click Go To > Deployment > Server Provisioning, and select the application by clicking the Select Software button. The Software Stack selection in both the virtualization management and the server provisioning applications can be used to select the image stack only. Create a virtual server from a SCVMM template You can create a virtual server using the resources that are marked as management on a host platform server. When creating a new virtual server, you must specify a virtual server template. When the selected virtual server template is associated with a SCVMM template, then the virtual machine is created from that SCVMM template. The template specifies the size and types of resources that you allocate to the new virtual server. select the
1051
Table 192. Supported virtualization activities for Hyper-V (continued) Activity Clone a virtual server and re-configure it Details To clone a virtual server: 1. From theTivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click a Hyper-V host platform. 3. Select a virtual server. 4. Click Management > Clone 5. Specify the name of the new server in the New Virtual Server field. 6. Click to select the virtual server template on which the new virtual server is based. 7. Click OK. The new virtual server is created on the same hypervisor as the source virtual server. The disk files from the source virtual server are copied to the new virtual server. Delete a virtual server from a Hyper-V hypervisor To delete the virtual server from the Hyper-V hypervisor, follow this procedure: 1. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click the Hyper-V host platform. 3. Select the virtual server. 4. Click Management and click Delete. Move a virtual server to another Hyper-V hypervisor When moving a virtual server to another Hyper-V hypervisor, the virtual server is defined and the disk files are transferred to the target hypervisor. A device.copy operation is used to transfer the disk files between the hypervisors. This operation requires that the source host platform in Tivoli Provisioning Manager contains a defined client SSH SAP. To move a virtual server to another Hyper-V hypervisor, follow this procedure: 1. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click the Hyper-V host platform. 3. Select the virtual server. 4. Click Management and go to Move.
1052
Table 192. Supported virtualization activities for Hyper-V (continued) Activity Power a virtual server from the Hyper-V hypervisor on and off Details To turn a virtual server on and off from the Hyper-V hypervisor: 1. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click a Hyper-V host platform. 3. Select the virtual server. 4. Click Management. v To turn off the virtual server, go to Manage > Power Off. v To turn on the virtual server, go to Manage > Power On. Restart a virtual server from a Hyper-V hypervisor To restart the virtual server from the Hyper-V hypervisor: 1. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click the Hyper-V host platform. 3. Select the virtual server. 4. Click Management and go to Manage > Generic Restart. Discover everything on the SCVMM server To run an initial discovery against the SCVMM server: 1. Create a Remote Execution and Access (RXA) Service Access Point (SAP) on the provisioning computer for SCVMM. 2. Create a credential for the SAP, which contains a user name and user password. The credential must be the Administrator built-in account of the active directory domain that SCVMM belongs to. 3. Run the initial discovery against the SCVMM server to create a provisioning computer in Tivoli Provisioning Manager data model. 4. Run the Hyper-V SCVMM Server Discovery against the SCVMM host to discover all the Hyper-V hosts and virtual servers defined on the host platform. Discover the virtual machines on the Hyper-V host platform server Use the discovery configuration called Hyper-V SCVMM discovery to discover all of the virtual servers defined on the host platform server. Hyper-V information, including operating system and resource allocation, will be imported into the provisioning database. To modify the resources of the virtual server: 1. From the Tivoli Provisioning Manager web interface, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click the Hyper-V host platform. 3. Select the detail menu <may be you can add image here> against the virtual server. 4. Click Resource Allocation.
Modify the hardware resources of the virtual server (CPU, memory, disk)
Known limitations
1053
You can use the following information to troubleshoot the HyperV_Virtual_Infrastructure automation package: Enable PowerShell to run script files By default, PowerShell has a restricted execution policy, which does not permit to run any script files. Because the automation package runs PowerShell script files on SCVMM server, this policy must be changed to RemoteSigned, as follows: 1. Open a command prompt with elevated Administration privilege. Use built-in administrator of SCVMM server machine or domain. 2. Enter the following command to change the policy. PowerShell remembers the execution policy:
PowerShell -Command Set-ExecutionPolicy RemoteSigned
Operation too slow Symptoms The operation on SCVMM is very slow. Cause Adding the SCVMM snap-in to the PowerShell file might take longer. Resolving the problem Adding the SCVMM snap-in to the PowerShell file might take longer. 1. Log in to the SCVMM server machine with built-in Administrator account of your domain. 2. From the control panel, open Internet Options. 3. Select the Advanced tab. 4. Under Security, clear the following two options: v Check for publisher's certificate revocation. v Check for server certificate revocation. 5. Click OK to close the Internet Options. Error creating a virtual machine Symptoms The creation of the virtual machine from a SCVMM template might fail with the following error message:
Tivoli Provisioning Manager is not able to access virtual server with any of IP address virtual server currenly has. No IP configuration is possible.
Cause This message is issued when Tivoli Provisioning Manager determined that the IP address needs to be configured with configuration command, but unable to access to created virtual machine with RXA. Resolving the problem Verify whether the created virtual machine: v Is connected to the virtual network accessible from Tivoli Provisioning Manager. v Can receive the IP address from the DHCP server. v Satisfies the requirements for Windows target computers. For example, the Internet Connection Firewall is enabled and blocks the TCP/IP ports required for RXA. For more information, see the Requirements for Windows target computers on page 556. Error customizing a virtual machine Symptoms The creation of the virtual machine from a SCVMM template might fail with the following error message: Cause The deployment of the virtual server failed.
Progress = 94 % Virtual Machine Manager cannot detect a heartbeat from the specified virtual machine. Eithe
1054
Resolving the problem Verify that the provided product key is valid for the corresponding operating system. Note: The failed virtual machine will be kept to investigate the cause of the failure. Remove the failed virtual machine after the troubleshooting is complete. If you do not want to retain the failed virtual server for troubleshooting purposes, set the value of the hyperv.keepvm.onerror variable to zero during the virtual server creation. For more known limitations, see the documentation for the HyperV_Virtual_Infrastructure automation package.
System p Server data flow quick reference

This topic provides reference on the data flow process with the System p Server. It explains how Tivoli Provisioning Manager and Network Installation Management manage LPAR's on the System p Server. The System p server data flow is explained in the following image:

NIM steps 1 - 3 Operating system provisioning NIM automation package
Network Installation Management (NIM)
SSH or other Tivoli Provisioning Manager supported protocol such as Tivoli Common Agent
Image and configuration data
Client data
Virtualization System p Server automation package SSH or telnet NIM step 6 NIM step 5
System p Server
LPAR1 SSH LPAR steps 1 - 4 NIM step 4 Hypervisor VIOS1 Hardware Management Console LPARn
VIOSn
1055
Managing LPARs with the System p Server automation package

1. To discover hardware resources and existing LPARs, Tivoli Provisioning Manager communicates using the Secure Shell (SSH) protocol with the Hardware Management Console. 2. After you have customized a virtual server template, create the LPAR using the virtualization management application. The required resources defined in the virtual server template are assigned to the new LPAR. 3. You can start, stop, and modify allocated resources on the LPAR using Tivoli Provisioning Manager. Allocated resources that can be modified are: v Add new logic volume-based disk to an LPAR v Resize a logic volume-based disk on an LPAR v Add MPIOed SAN disk to an LPAR v Add or remove virtual Fibre Channel adapter v Add or reduce processors or memory 4. Remove the LPAR. Note: v Tivoli Provisioning Manager has no direct communication with the Virtual I/O servers. v The HMC user account used for HMC discovery in Tivoli Provisioning Manager must have administrative privileges.
AIX provisioning process on an LPAR through NIM automation package

1. Run NIM discovery to discover images and resources. Communication between Tivoli Provisioning Manager and the NIM server can be SSH or another supported protocol such as Tivoli Common Agent. 2. You can create or remove a client entry as part of the AIX provisioning process using image installation. 3. Choose an image on the LPAR to initiate OS image installation. 4. NIM workflow automatically issues a network boot command to the LPAR HMC console. 5. The LPAR initiates the network installation by communicating with the NIM server directly. 6. The NIM workflow verifies the status of the OS installation by running the OS command on the LPAR directly through the SSH protocol or the Telnet protocol. The Service Access point defines the protocol to be used on the LPAR computer object in Tivoli Provisioning Manager.
Live Partition Mobility for System p server

This topic provides reference information about migrating LPAR partitions that are running the AIX operating system on System p servers.
What is Live Partition Mobility? Live Partition Mobility allows you to migrate LPARs running the AIX operating system and their hosted applications from one physical server to another without disrupting the infrastructure services. The migration operation maintains system transactional integrity and transfers the entire system environment, including processor state, memory, attached virtual devices, and connected users. Supported features The following Live Partition Mobility features are supported:
1056
v Inactive Live Partition Mobility (between servers that are managed by the same Hardware Management Console (HMC)) v Active Live Partition Mobility (between servers that are managed by the same HMC) v Inactive and active migration of an LPAR that has multiple SAN disks v Multiple SAN disks are supported - LPAR is moved, all disks are mapped to the target virtual I/O server and are available to the LPAR. Features not supported The following Live Partition Mobility features are NOT supported: v Remote Live Partition Mobility (the ability to migrate an LPAR between two System p servers; each managed by a separate HMC) v Live Partition Mobility using Integrated Virtualization Manager (IVM) Hardware requirements The following hardware components are required for Live Partition Mobility: v Two IBM POWER6 servers running PowerVM Enterprise Edition 1.5 or higher and controlled by the same HMC. v Virtual I/O server LPARs (at least one on each POWER6 servers). These LPARs must be configured as mover service partitions on the source and target systems. v The ability to migrate an LPAR between the two POWER6 servers. Activation entries in the view history log of the HMC console screen for both POWER6 servers must have the following enabled: 1. Advanced POWER Virtualization Enterprise Edition code 2. Inactive partition mobility capability 3. Active partition mobility capability v At least one storage area network (SAN) that provides connectivity to all of the mobile LPAR disks to the virtual I/O server LPARs on both the source and destination POWER6 servers. The mobile LPAR must access all disks to be migrated through a virtual fiber channel, or virtual SCSI, or a combination of the two devices. The logical unit numbers (LUN) used for the virtual SCSI must be zoned and masked to the virtual I/O servers on both systems. Hardware-based iSCSI connectivity can be used in addition to a SAN. SCSI reservation must be disabled. The mobile LPAR virtual disks must be mapped to LUNs and cannot be part of a storage pool or logical volume on the Virtual I/O Server The LPAR cannot have any of its virtual SCSI disks defined as logical volumes in any virtual I/O server. All virtual SCSI disks must be mapped to LUNs visible on a SAN or iSCSI. Logical host ethernet adapter (LHEA) devices are not to be configured. Software requirements The following software components are required for Live Partition Mobility: v An operating system running on the mobile LPAR must be AIX. v A virtual I/O server LPAR or an LPAR running the IBM i operating system cannot be migrated. The operating system must be at one of the following: AIX 5L Version 5.3 Technology Level 7 or later (the required level is 5300-07-01) AIX Version 6.1 or later (the required level is 6100-00-01) Creating an LPAR to be used with Live Partition Mobility To create an LPAR that can be migrated using Live Partition Mobility (map a SAN disk to a LUN), you must do the following:
1057
1. Create the environment for LPAR virtualization. 2. Set the following three variables in the Virtual Server Template (VST): Note: MPIO disks are not supported by Live Partition Mobility. The following three variables must be set for each SAN disk, where X represents the disk number.
Table 193. VST variables used for Live Partition Mobility Variable DISKX.PVID Definition Use this physical volume identifier (PVID) variable to identify your disk(s), where PVID is the disk ID property. For example, define each disk as DISK1.<PVID>, DISK2.<PVID>, and so on. Specify the vtscsi device name schema for your disk(s). A string variable that is used to define policy for MPIO disks. This variable must be set to MPIO_NOT_REQUIRED or the VIO server name.
VIO.vtscsiDeviceNameSchemaX DISKX.MPIO_policy
Migrating an LPAR using Live Partition Mobility To migrate an LPAR: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click the host platform server where the LPAR resides. 3. Select the virtual server where the LPAR resides. 4. Click Management > Move. 5. In the Move Virtual Servers dialog, specify the Target Host Platform and click OK.
Tutorial: Managing virtual servers and host platform servers using VMware
This tutorial demonstrates how to maximize your IT resources by using VMware virtual servers. VMware virtualization uses the hardware resources of a physical computer to create a virtual machine, or virtual server. The virtual server thinks and acts like a physical computer, it runs its own operating system and applications. In fact, an operating system cannot recognize any differences between a virtual server and a physical computer. A software layer resides on the host platform server and dynamically allocates hardware resources. Multiple virtual servers share hardware resources with each other but do not interfere with each other. Tivoli Provisioning Manager supports VMware Infrastructure 3 (VI3) and VMware vSphere 4.
Learning objectives
In this tutorial you will: v Learn how to deploy ESX servers. v Learn how to discover computers using the VMware discovery. v Learn how to add credentials to a computer. v Learn how to run an inventory scan and install the Tivoli Common Agent. v Learn how to add virtual servers using a virtual server template. v Learn how to power off and on, add resources to, and delete virtual servers.
1058
Prerequisites
Ensure that you meet all requirements described in Requirements on page 1060 before beginning the tutorial. Modules in this tutorial v Requirements on page 1060 v Part 1: Configuring and deploying the ESX server and the VMware VirtualCenter on page 1061 v v v v Part Part Part Part 2: 3: 4: 5: Setting up the environment on page 1064 Discovering VMware virtual servers on page 1066 Creating a virtual server on page 1071 Performing virtual server activities on page 1075
VMware virtualization process

It is important to understand the overall VMware virtualization process before you start managing virtualization. The virtualization process using VMware includes the following steps. The role required to perform each step is shown in brackets.
Deploy ESX servers and VMware VirtualCenter
Discover computers
Import SSL certificate
Select virtual server template
Define service access points
Create virtual server
Delete virtual server
Legend
Provisioning Administrator Deployment Specialist
1. Configuring and deploying the ESX server and the VMware VirtualCenter (Provisioning Administrator) This process involves creating an image of the ESX server 3.5 from the CD media using Tivoli Provisioning Manager for OS Deployment. After the image is created, you can install the image on a physical computer. After you have the ESX server created, download the VirtualCenter from the VMware Web site. You will use the VirtualCenter to manage multiple ESX servers. Note: You can manage ESX servers one by one. 2. Setting up the environment (Provisioning Administrator) This process consists of importing the SSL certificate so that the provisioning server can use the HTTPS protocol to connect to the VirtualCenter or to the ESX servers. After you have imported the SSL certificate, you must add HTTP or HTTPS service access points and corresponding credentials to ensure communication between the provisioning server and the VMware VirtualCenter server.
1059
3. Discovering computers (Provisioning Administrator) This process consists of running the VMware Virtual Center Discovery discovery configuration to discover all of the VMware clusters, ESX servers, and existing virtual servers and templates to add them to the data model. The discovery configuration identifies VMware clusters and ESX servers as host platform servers and creates a virtual server template for each discovered ESX server and VMware template. Tip: The task of discovering computers can also be performed by the deployment specialist and the provisioning configuration librarian. 4. Creating a virtual server (Provisioning Administrator) This process consists of selecting a virtual server template to create the virtual server with. You can also select a software stack to add software to the virtual server. Tip: The task of creating virtual servers can also be performed by the deployment specialist. 5. Deleting a virtual server. (Provisioning Administrator) This process consists of removing the virtual server from the host platform server and the provisioning data model.
Requirements
Before you start working with virtualization, ensure that you meet all requirements.

To complete virtualization tasks, ensure that you have the required knowledge and access rights.
Hardware and software requirements for VMware

Ensure that you are using supported hardware and software required for virtualization using VMware
v For specific hardware requirements for VMware VirtualCenter, see the VMware documentation: http://www.vmware.com/support/ v To access the virtual server targets, Tivoli Provisioning Manager uses the HTTP or HTTPS protocol to connect to the VMware VirtualCenter. v To facilitate the connection, the following configuration procedures are required: 1. Enable the VMware VirtualCenter server to accept HTTPS connections. Ensure that the HTTPS certificate is loaded onto your provisioning server. For more information, see the Importing the SSL certificate on page 1064 topic.
1060
2. Create an HTTP or HTTPS service access point (SAP) on the server object representing the VMware VirtualCenter that has just been added to the data model. For HTTPS, ensure that the SSL certificate has been imported, or change the configuration of the VirtualCenter to accept the HTTP connection. 3. Create a credential for the newly created service access point, and provide it with a user name and password. To enable the discovery of all targets, it is recommended that you use the user with Administrator priviledge on VMware VirtualCenter. For more information, see the Adding service access points and credentials to the VirtualCenter on page 1065 topic. Note: If you are using a single ESX server, complete the previous connection steps on the ESX server. Use the root user name for the ESX server when you are creating a credential for the service access point.
v VMware ESX 4.0 or ESX 3.5 v VMware VirtualCenter with 4.0 or 2.5 v VMware Tools. For downloading instructions, see the VMware documentation: http:// kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC &externalId=1014294 v An automation package called VMware_Virtual_Infrastructure.tcdriver is used for creating and managing virtual servers using a VMware ESX server and VMware VirtualCenter. This automation package is provided with Tivoli Provisioning Manager Additional details about using the VMware_Virtual_Infrastructure automation package are available in the automation package documentation. To view the documentation: 1. Click Go To > Administration > Provisioning > Device Drivers. 2. 3. 4. 5. In the Device Drivers list, type VMware to see all of the device drivers related to VMware. Click the any device driver. Click the Documentation link. Click the Automation Package link.
Part 1: Configuring and deploying the ESX server and the VMware VirtualCenter
In this part, you will learn how to configure and deploy a VMware ESX server. The ESX server is the host platform server that will host your virtual servers. You will use the VirtualCenter to manage multiple ESX servers.
Creating an unattended setup image

Use Tivoli Provisioning Manager for OS Deployment to create a unattended setup image for VMware ESX 3.5. An image is a representation of a computer program and its related data such as the kernel, file systems, libraries, and programs of the computer at a given point in time. You can deploy this image to multiple computers. Optional This step is not required if you already have an ESX Server and VirtualCenter server installed from the VMware CD image. To create the image, you must download the binary from the VMware Download Center: http://downloads.vmware.com/d/ Note: For ESX server 3.5, use the Update 2 CD image (596 MB). Creating the image from ESX server 3i U2 Installable (238 MB) will result in a failed deployment. To create an unattended setup image:
1061
1. 2. 3. 4.
Click Go To > Deployment > OS Management > Unattended Setup Image. Select Unattended setup in the first pane of the wizard and click Next. Select your operating system from the list and click Next. Follow the instructions of the wizard. Note: Do not close the browser when the image is being uploaded. If you do, the upload might be cancelled.
5. You will have to choose the computer where the material to create your unattended setup image can be found and this computer must have the web interface extension installed on it. The web interface extension is automatically installed on all Tivoli Provisioning Manager for OS Deployment servers, however, only the web interface extension on the parent server can be detected. If you have changed the parent server, or you are trying to work with a child server, you must manually install the web interface extension on the source computer before it can be detected. For information on how to do this, see Installing an uninstalling the Web interface extension. The ESX server image has been created. Now you can install the image onto the target computer.
Installing the ESX server image

Create the ESX server by deploying the image to a target computer. The BIOS startup sequence of this computer must first have network and then hard disk for this install task to complete successfully. To install the image on the computer: 1. Click Go To > Deployment > OS Management > Images. 2. 3. 4. 5. 6. Fro the Select Action menu, click Install Image. Specify a name for the image deployment task. Select the image that you want to install. Select the computer to install the image to. Choose to schedule the task or run it immediately.
7. Click Advanced. 8. Change the various settings to your own preference. 9. Click Submit. The task will be started. Monitor its progress until the task has completed. The ESX server image has now been deployed on the target computer. Now that you have created the ESX server, download the VMwareVirtualCenter; the application that manages multiple ESX servers, from the VMware Web site.
Configuring the VirtualCenter server

The VirtualCenter server helps you to manage multiple ESX servers. Ensure that you have a Windows 2003 server to install the VirtualCenter on. To configure the VirtualCenter server: 1. Navigate to the VMware Web site: http://www.vmware.com/products/vi/vc/. 2. Download the VirtualCenter server and install it on your Windows 2003 server. After you download the VirtualCenter, you can use it to manage multiple ESX servers.
1062
Now that you have the VMware infrastructure set up, you can add the ESX server host computer to the VirtualCenter. Registering the ESX server to the VirtualCenter enables you to manage the ESX server from the VMware Virtual Infrastructure Client.
Registering the ESX server to the VirtualCenter

In the Virtual Infrastructure Client Web interface, the Data Center is the top level library. You can create folders in this library. When you add, or register, an ESX server, you can add it directly to the Data Center or you can create folders and add the ESX server to specific folder. After you download the VirtualCenter, start the Virtual Infrastructure Client so that you can manage your ESX servers. The Virtual Infrastructure Client can be downloaded from the VirtualCenter Web interface. Point a Web browser to the hostname of the VirtualCenter to download the client. To 1. 2. 3. register an ESX server to the VirtualCenter: Start the Virtual Infrastructure Client. Right click on a cluster and Add Host. In the Add Host wizard, enter the following information: v Host Name: The host name of the ESX server. v User Name: The user name is always root. v Password: The password for the ESX server was defined during its installation. If you used Tivoli Provisioning Manager for OS Deployment for the installation, the password was defined in the template. v Click Next. A summary of the task is presented. Click Next. v Select a location to add the virtual servers for the host. The Add Host Wizard is different depending on where you created the host: Cluster: If you added the ESX server to a cluster, the ESX server will be directly added by default to the Data Center level. You will be asked to choose the destination resource pool. Accept the default to put the virtual servers in the root resource pool of the cluster. Data Center or folder: If you added the ESX server to a specific folder or the Data Center, you can select a location in the VirtualCenter inventory for the virtual servers of the host. v Click Next and then click Finish. The ESX server is registered to the VirtualCenter. Use the VirtualCenter to manage the ESX server and all of its virtual servers.
Enabling VMware DRS on a cluster in the VirtualCenter

If you have clusters defined in your VirtualCenter, when you create virtual servers in the provisioning database, you have the option of either adding virtual servers to a cluster, which will automatically assign the virtual servers to the host platform server that has the best resources available, or assigning virtual servers directly to a host platform server. To create virtual servers on VMware clusters in your provisioning environment, you must enable VMware DRS on the clusters in the VirtualCenter. To enable VMware DRS: 1. Log into the VirtualCenter. 2. On a cluster in the list, right-click and select Edit Settings. 3. Select Turn On VMware DRS. 4. Click OK. The VMware DRS is enabled on that cluster. Complete these steps for each cluster in your VMware VirtualCenter.
1063
Now that you have the VMware infrastructure set up, continue configuring the provisioning environment with the SSL certificate so that the provisioning server can communicate with the VMware VirtualCenter.
Part 2: Setting up the environment

In this part, you will learn how to prepare the provisioning environment for VMware virtual servers. Set up the provisioning environment to ensure the communication with the VirtualCenter and to the ESX servers.
Importing the SSL certificate

To access the virtual server targets, the provisioning server uses the HTTPS protocol to connect to the VirtualCenter. Select the option Run as administrator for all the commands that you run from %TIO_HOME%\tools. For more information about user account control in Windows 2008, see User Account Control Step-by-Step Guide.
Windows 2008
To enable the HTTPS connection, first you need to import the SSL certificate into the provisioning server. To import the SSL certificate: 1. Log on to the provisioning server as: v
Windows
: Administrator
UNIX : root v 2. Copy the certificate to the provisioning server. v ESX server: /etc/vmware/ssl/rui.crt or /etc/vmware/ssl/rui.cer
v Virtual Center server: *:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\*.crt or *:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\*.cer 3. Import the certificate: a. Change to the %TIO_HOME%\tools ( b. Source the environment: v
Windows Windows
) or $TIO_HOME/tools (
UNIX
) directory.
setupCmdLine.cmd
UNIX
In another session, log on to the provisioning server as TIOADMIN.
echo $TIO_HOME
Note down the displayed value, for example, /opt/IBM/tivoli/tpm. In the earlier session, set the $TIO_HOME:
export TIO_HOME=/opt/IBM/tivoli/tpm . ./setupCmdLine.sh echo $JAVA_HOME
Make a note of the path returned by the echo $JAVA_HOME command. c. Change directories: v
Windows
cd %JAVA_HOME%\jre\lib\security
UNIX
cd $JAVA_HOME/jre/lib/security
d. Ensure that the keytool command is accessible in your path. v

Windows
1064
Type keytool at the command prompt. If the command does not run, update the PATH environment variable with the directory that contains the keytool command.
set PATH=%JAVA_HOME%\jre\bin;%PATH%
UNIX
Linux
Update the PATH environment variable with the directory that contains the keytool command.
export PATH=$JAVA_HOME/jre/bin:$PATH
e. To import the keytool, run the following command:

keytool -import -v -trustcacerts -alias alias-name -file certificate-location -storepass changeit -keystore cacerts
where alias-name is any name. The suggested value is the host name of the VirtualCenter or ESX server. f. Ensure that the certificate has been imported. Run the following command:
keytool -list -alias alias-name -storepass changeit -keystore cacerts
where alias-name is any name. The suggested value is the host name of the VirtualCenter or ESX server. 4. Restart the provisioning server. For more information, see Starting or stopping the provisioning server on Windows or Starting or stopping the provisioning server on UNIX. The SSL for the HTTPS connection is now imported into Tivoli Provisioning Manager.
Adding service access points and credentials to the VirtualCenter

To ensure communication between the provisioning server and the VMware VirtualCenter server, you must add HTTP or HTTPS service access points and corresponding credentials. v The VirtualCenter must in the provisioning database. Add the VirtualCenter manually, if it is not in the database. 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. to add a new computer. 2. Click 3. In the Computer field, type the full host name of the VirtualCenter computer. When you navigate away from the page, save your changes and the computer will be added to the provisioning database. v For HTTPS, ensure that the SSL certificate has already been imported, or change the configuration of the target computer to accept the HTTP connection. If HTTP has been enabled, the HTTP service access point can be used. For details on how to import a SSL certificate see the previous section Importing the SSL certificate. v For the VirtualCenter server, only one VirtualCenter SSL certificate is required. Note: If you are not using the VirtualCenter to manage multiple ESX servers, an SSL certificate must be loaded for each ESX server. To add an HTTPS service access point to the VirtualCenter server, complete the following steps: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. In the list, find and select the VirtualCenter computer. 3. On the Credentials tab, click Add Credentials > New Service Access Point. 4. On the Details tab, complete the fields as follows: a. In the Service Access Point field, type the name of the new service access point. b. In the Protocol Type list, select Network protocol IP. c. In the Application Protocol list, select HTTP Secure Access. d. Enter the Port value 443
1065
e. Ensure that Authentication is selected. f. Click New Password Credential. g. Enter a User Name, for example Administrator or root, a Password, and a Search Key. h. Click Save. The host HTTP or HTTPS service access point is now created and password credentials are now set up for the host service access point that you have created on the VirtualCenter server. Now that the VMware VirtualCenter and provisioning server are configured for virtualization, you can discover the existing VMware clusters, host platform servers, and virtual servers in your environment.
Part 3: Discovering VMware virtual servers

In this part, you will learn how to discover VMware virtual servers and to perform activities on them. Using VMware to manage virtualization in the product requires ESX servers and the VMware VirtualCenter. ESX servers are the host platform servers; the computers that you can create virtual servers from. Discover the existing ESX servers in your environment using the VMware discovery configuration. After you discover existing VMware virtual servers, you can continue with other activities on them. Important: In Tivoli Provisioning Manager, each MAC address must be unique. VMware does not generate a new MAC address when cloning virtual servers or templates for virtual servers or templates that have MAC addresses assigned manually. Therefore, Tivoli Provisioning Manager does not support MAC addresses created manually for VMware virtual servers. Your discovery might fail to identify the virtual servers or templates with duplicate MAC addresses if you have MAC addresses that were created manually outside of Tivoli Provisioning Manager.
Discovering host platform servers and virtual servers

After the VMware VirtualCenter is set up and the credentials are configured, you can run a discovery against the VirtualCenter to discover the VMware clusters, host platform servers and their virtual servers. The discovery configuration also discovers the resources on the VMware clusters and host platform servers. If you already have discovered VMware virtual servers in your environment, the VMware discovery will try to reconcile the discovered virtual servers. To improve reconciliation, the provisioning server will try to use the virtual server hostname and IP address. If these parameters are not available, the VMware virtual server name will be used. In order for VMware to populate the hostname and IP address, install VMware Tools on the virtual servers. The virtual servers must also be running when you run the VMware discovery so that the hostname and IP address information can be accessed. If you have upgraded to Tivoli Provisioning Manager version 7.2 from version 7.1.1 you must run this discovery to have all the new virtualization functionality properly implemented on the VirtualCenters from your 7.1.1 environment. Complete all of the prerequisite tasks. In particular, if you want to use clusters for creating virtual servers, ensure that you have enabled VMware DRS on the cluster in the VirtualCenter. This attribute will be discovered when you run the VMware Virtual Center Discovery. To discover host platform servers and virtual servers: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. In the list, find the discovery configuration called VMware Virtual Center Discovery. All of the available host platform servers as well as their virtual servers will be discovered.
1066
Restriction: You must choose the correct discovery configuration for the target of the discovery. Do not run this discovery against an ESX server. Use the VMware HostPlatform Resource and Virtual Machine Discovery discovery configuration to discover VMware clusters, ESX servers and all of their virtual servers. Note: The following optional parameters can be used to limit the scope of the VMware Virtual Center Discovery: Discovery Level Limits the discovery to discover all data, only virtual machines, or only templates. Possible values for this parameter are All (default), Servers, or Templates. Cluster List Limits the discovery to discover data from specified clusters. Multiple values can be provided for this parameter. When the list is empty, all hosts and clusters under the virtual center are discovered. The cluster names must be in the format Data_Center_Name - Cluster_Name, which is used by Tivoli Provisioning Manager to uniquely identify clusters. Any combination of the Discovery Level and Cluster List parameters can be used to limit the scope of the discovery on the virtual center. 3. Click Run Discovery. 4. Click Select > Computers and select the VirtualCenter server. Click OK. 5. Accept the default name for the Provisioning Task, or type a new name. Click Submit. 6. In the message box that is displayed, click OK to go to the Provisioning Task Tracking page so that you can monitor the discovery task. 7. Click Refresh to update the task status until the task is completed. When the provisioning workflow completes successfully, all of the VMware clusters, host platform servers and virtual servers defined with the specified VirtualCenter are discovered and their data is imported into the provisioning data model. The VMware discovery creates a virtual server template for each ESX server that was discovered. View the virtual servers and resources of the discovered host platform server. 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. From the list, select a host platform server or a cluster. On the Host Platform tab, you will see a list outlining the relationship of the cluster or host platform server and all of the associated virtual servers. 3. Click the Hardware and Software tabs to view the resources of the host platform server. Now that you have discovered the host platform servers and virtual servers, you can continue to the next tutorial lesson and add credentials to the virtual servers. Credentials are required so that you can run an inventory scan or install the common agent on the discovered virtual servers. Alternately, you can skip these next few optional lessons and jump to Part 4 of this tutorial to create a virtual server. Virtual server states: Various states are possible for virtual servers in the provisioning database. Review the meaning of the virtual server status, and the cross-references to the technology-specific states. In the Virtualization Management application, you can view the virtual servers that are assigned to each host platform server. The Host Platform tab lists the virtual server and the Status of the virtual server.
1067
All of the states are defined in the list below. Also, most virtualization technologies have their own terms for virtual server states. See the table below to identify how the provisioning term relates to the technology-specific term. States Aborted An error has occurred during either the creation or discovery of the virtual server. The error needs to be corrected before the virtual server can be used. Configured The configuration of the virtual server has completed and is committed. Deploying The process to create a virtual server has begun, but has not yet completed. This is a temporary state, leading to Deployed. Deployed The process to create a virtual server has completed. Ready The virtual server has been created successfully. Rebooting The virtual server is in the process of loading its configured operating system and software. This is a temporary state, leading to Running. Resuming The virtual server is in the process of returning its configured operating system and software to the exact same state that it was in before the virtual server was suspended. This is a temporary state, leading to Running. Running The virtual server booted successfully and is now able to respond to commands and do work. Stopping The virtual server is in the process of ending the execution of its software applications and unloading its operating system. This is a temporary state, leading to Stopped. Stopped The virtual server has ended the execution of its software applications and unloading its operating system. Suspending The virtual server is in the process of saving the state of its running operating system and software. This is a temporary state, leading to Suspended. Suspended The virtual server that was running has been paused such that its configured operating system and software can be returned to the exact same state they were in before the virtual server was suspended. Uninstalling The virtual server is in the process of ending the execution of its software applications and unloading its operating system. This is a temporary state, leading to the removal of the virtual server. Unknown The state of the virtual server cannot be determined. For AIX WPARs, this state is also used to represent the transitional state when there is no context available to determine the states between which the WPAR is transitioning.
1068
States names by virtualization technology The standard status names and mappings for each supported virtualization technology are shown in the table below. For WPARs, the Transitional state will be mapped to the appropriate transitional state in provisioning terms. For example, if the WPAR is stopping, the state of the WPAR will be mapped to Stopping. However, when the Transitional state is discovered, then it will be mapped to Unknown because in that case the context is not known.
Table 195. State names by virtualization technology Standard Configured Deploying Deployed Ready Running Suspending Suspended Resuming Stopping Stopped Uninstalling Rebooting Aborted Unknown v Transitional v Broken v Frozen v Loaded Active Transitional Paused Transitional Transitional Defined Transitional Rebooting Rebooting Crashed No State Shutting Down Not Activated Running Powered On Suspending Suspended Resuming Stopping Powered Off Shutting down Down In shutdown Stopped Paused Transitional Starting / Open Firmware Deploying Deployed WPAR LPAR VMware Solaris Configured Incomplete Installed Ready Running Running KVM
Adding credentials to VMware virtual servers

Before you can perform activities like running an inventory scan or installing the Tivoli Common Agent, credentials must be configured on the discovered virtual servers. This task is optional. You do not need to add credentials to proceed with virtualization tasks such as adding and moving virtual servers. You do need to complete this task if you want to manage virtual servers by doing tasks such as patch deployments and software deployments. To add credentials to virtual servers, follow the steps below: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click the host platform server and then select one or multiple virtual servers to add credentials to. 3. Click Add Credentials. 4. Select the appropriate credential type for the operating system of the virtual server. For example, select RXA for Windows virtual servers or SSH and SCP for Linux virtual servers. 5. Enter the required credential information and click OK to save your changes. Now that credentials have been added to the VMware virtual servers, you can run an inventory scan and install the Tivoli Common Agent.
1069
Running an inventory scan

Run an inventory scan on the discovered virtual servers to identify the hardware and software on the computers. The virtual server must have an operating system installed before you can run an inventory scan on it. You can run the inventory scan agentless, which means that the common agents do not have to be installed on the virtual server. The common agents provide the ability to communicate with the computer without having to provide credentials. If the common agent is not installed on the virtual server, credentials must be assigned on the virtual server. Note: This is an optional task. You do not need to run an inventory scan to perform virtualization management tasks such as powering on and powering off a virtual server or moving or deleting a virtual server. Running an inventory scan directly on an ESX server is not supported. Run the inventory scan only on virtual servers. To run an inventory scan on a virtual server, follow these steps: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. In the list, click the host platform server. 3. Select a virtual server. 4. Click Management > Run Inventory Scan. When the scan successfully completes, any existing hardware and software on the virtual server will have been identified. To see the discovered resources, follow the steps below: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select a host platform server that was just discovered. On the Host Platform tab you will see all of the virtual servers allocated to the host platform server. > Go to Provisioning Computers. 3. Select a virtual server and click Detail Menu 4. On the Computer tab of the Provisioning Computers application, you can view the detail information for the virtual server. Click the Hardware and Software tabs to see the resources of the virtual server. 5. To go back to the Virtualization Management application, click Return.
Installing the Tivoli Common Agent on the virtual server

Installing the common agent on a computer is a task that is typically performed on most computers in the provisioning data model so that the provisioning server can perform software management activities on the computer. Install the Tivoli Common Agent on the VMwarevirtual server to take advantage of these software management features. The virtual server must have an operating system installed before you can install the common agent. Installing software on a VMware virtual server is the same process as installing software on any physical computer. Before you install the common agent on the virtual server, ensure that the prerequisites are met. v Default ports used on the target computer. See the topic called Tivoli Common Agent Services ports. v Requirements for common agent installation. See the topic called Requirements for common agent installation
1070
To learn more about the common agent, see the topic called Installing Tivoli Common Agent Services. Note: This is an optional task. The common agent does not need to be installed on a virtual server to be able to perform virtualization activities such as moving, deleting, or powering on and powering off the virtual server. The provisioning server uses the Tivoli Common Agent for some software management features, including software distribution and software compliance management. The common agent is a program that automatically performs some service, such as data collection. Installing the common agent on the virtual server also permits the provisioning server to access the computer without needing to know the credentials of the computer. See the Tivoli Common Agent documentation to learn more about this feature. Follow these steps to install the common agent on the virtual server. 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. In the list, click the host platform server. 3. Select the virtual server. 4. Click Management > Software > Install Common Agent. 5. Type a name for the installation task. 6. Click Submit. The Tivoli Common Agent is now installed on the virtual server. Users can now manage the virtual server without knowing its credentials and you can use the software distribution and scalable distribution infrastructure feature of the provisioning server. The common agent can also be deployed to the virtual server as part of a standalone image. For more information, see the topic called: Installing the common agent and subagents using a stand-alone installation. You have installed the common agent and run an inventory scan on the discovered virtual servers. Now, create a virtual server on the discovered host platform server.
Part 4: Creating a virtual server

In this part, you will learn how to create a virtual server. Virtual servers are created by allocating hardware resources from the host platform server; the VMware ESX server.
Creating a virtual server template

Virtual server templates are used to allocate virtual servers. A virtual server template has various requirements such as memory and hard disk size. When you specify a virtual server template, the virtual server is allocated with all the same requirements as that template, assuming that the host platform server has sufficient resources to satisfy the allocation. Cloning an existing template: Create a virtual server template by cloning an existing virtual server template. When you discovered the host platform server and virtual servers using the VMware Virtual Center Discovery, a template was created for the host platform server; the ESX server. To 1. 2. 3. create a new virtual server template, clone the VMware ESX server template: Click Go To > IT Infrastructure > Provisioning Inventory > Virtual Server Templates. Click the VMware template that you want to clone. On the Virtual Server Template tab, click Select Action > Duplicate Virtual Server Template.
1071
4. In the Virtual Server Template field, type a new name for the template. 5. Select the Virtualization Type. 6. Click Save .
The new virtual server template is created. Hardware resources can be added to the template before you create new virtual servers. When you have allocated the resources that you want to the virtual server template, use the template to create new virtual servers. Adding hardware resources to virtual server templates: Specify which hardware resources you want to add, remove or change on an existing virtual server template. After you clone an existing virtual server template, you can make changes to the resources. For example, the virtual server template that was created during the discovery might have multiple hard disks. You can remove some of the hard disks and then increase the size of the remaining hard disks. Or, to add additional storage capability of the virtual server, you can add additional hard disks. To add hardware resources to a virtual server template: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtual Server Templates. 2. Select a virtual server template in the list. 3. Click New Resource Requirement. 4. In the Resource Type field, select a resource type, for example, Hard Disk. Some other possible options are: v CD-ROM v Memory v v v v NIC CPU Fibre Channel Port Floppy Disk
v Generic resource v Hardware Platform 5. Indicate whether the requirement needs to be dedicated to the virtual server by selecting Shared. Note: v If a resource is not shared with other virtual servers, the corresponding resource on the host platform server is decremented when a virtual server is allocated. v If the resource is shared with other virtual servers, 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 needed. to see a list of the available resource 6. Optional: Select a Resource Group Name. Click Select Value groups. A resource group is a logical group to which resources belong. For example, if you have multiple disks and you want to allocate them together, you can add them to a resource group. 7. The following fields might display depending on the selection in the Resource Type list.
1072
Field Host Platform Quantity
Description Host platform quantity applies only to Hard Disk for VMware. The host platform quantity is the actual physical resource on the host platform server. For example, if you want to allocate 5 GB to the virtual server, enter 5 for the Host Platform Quantity value. The host platform server must have more than 5 GB of resource available.
Virtual Quantity
The virtual quantity specifies how many units of the physical resource will be visible and available to the new virtual server. For example, for the CPU resource type, the Virtual Quantity value depends on whether or not you have indicated that the resource will be Shared. v If you selected Shared, the CPU resource will be shared with other virtual servers allocated to the host platform server. For example, you might type a Virtual Quantity value of 100 shares of the CPU resource on the host platform server. For each type, the quantity is measured differently and refers to the quantity on the virtual server: v Memory: Megabytes (MB). v NIC: Only a whole NIC can be specified but there can be multiple NICs. v CPU: The number of virtual CPUs allocated to the virtual server. v Generic resource: No specific type.
Tip: For more information about customizable variables for virtual server templates and guest operating system ID short names, see the Troubleshooting section of the VMware_Virtual_Infrastructure automation package. 8. Click Save .
The virtual server template is updated with the new resource requirements. When the hardware resource allocation is complete and the new virtual server template is ready, you can use it to create a virtual server.
Creating virtual servers

A virtual server shares its resources with other servers. When you create the virtual server, use the virtual server template that you created in the previous task. Virtual servers are for, the most part, added in the same way that computers and host platform servers are added. The main difference is that you use a virtual server template to create a virtual server Using a virtual server template and also specifying a software stack will create a fully functional computer with an operating system. To add a virtual server: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select a host platform server. 3. From the Select Action menu, click Create Virtual Server.
1073
4. Type the name of the new virtual server. > Select Value and select the virtual 5. In the Virtual Server Template field, click Detail Menu server template that you created in the previous task. a. Optional. You can make changes to a virtual server template directly from the Create Virtual Server > Go To Virtual pop-up window. Beside the Virtual Server Template field, click Detail Menu Server Templates. This will redirect you to the Virtual Server Templates application. From the list, select the virtual server template that you want to change. For detailed information about the Resource Requirements and Variables that are required or that can be changed, see the VMware automation package documentation. When you are finished making your changes, click Save and click Return With Value to return with your changes to the Create Virtual Server pop-up window. > Select Value and select a software 6. Optional. In the Software Stack field, click Detail Menu stack that is appropriate to the creation of this virtual server. For example, if this is an empty virtual server with no operating system, select a software stack that has an operating system image included. Software stacks can be nested but the stack with an image must be installed first. Note: If you select a software stack with an operating system, the virtual server will be created with the credentials of the operating system. a. Optional. You can make changes to a software stack directly from the Create Virtual Server pop-up > ->Go To Software Stacks. This window. Beside the Software Stack field, click Detail Menu will redirect you to the Software Stacks application. From the list, select the software stack that to save your you want to change. When you are finished making your changes, click Save changes and click Return With Value to return with your changes to the Create Virtual Server pop-up window. 7. To schedule the virtual server to be created, click Schedule. Accept the default, Run Now, to create the virtual server immediately, or select Scheduled Start and then click the calendar button to choose the date and time that you want the virtual server to be created. Click OK. 8. Click OK. 9. A task is launched. At the prompt, you can choose to jump to the Provisioning Task Tracking application to monitor the task. The virtual server is now created and added to the provisioning data model. For a complete view of the host platform server, or cluster, and the assigned virtual servers, 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. From the list, select a host platform server or a cluster. On the Host Platform tab, is a list outlining the relationship of the cluster or host platform server and all of the associated virtual servers associated. 3. Click the Hardware and Software tabs to view the resources of the host platform server. Removing empty virtual servers: Configure the host platform server so that empty virtual servers are removed if they fail to be created without the intended software stack deployment. When you create a virtual server and deploy a software stack on the virtual server in the same task, if the software stack deployment fails, the empty virtual server will still be created. You can configure the host platform server so that the empty virtual server will be deleted automatically. Otherwise, you have to manually find and delete the virtual server from the Virtualization Management application.
1074
Follow these steps to configure the host platform server: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select the host platform server from the list. 3. On the Variables tab, click New Row. 4. In the following fields, specify the following information: v Variable: Type Roll_Back. v Component: Select Entire system. v Value: Type true. 5. Click Save .
Any virtual servers that are created on this host platform server without the intended software stack will be automatically deleted.
Part 5: Performing virtual server activities

Virtual servers are typically configured in the same way that physical servers are configured. You can power virtual servers on and off, add resources, and delete virtual servers when they are no longer needed.
Powering virtual servers on and off

The tasks to power virtual servers on or off are initiated by provisioning workflows provided with the VMware automation package. To be able to do management and configuration operations on virtual servers, you must stop them first. To stop, or power off, a specific virtual server: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select the host platform server with the existing virtual server. 3. Click the Management button and then click Manage > Power Off. When the provisioning task completes successfully, the virtual server is stopped, or powered off. When the virtual server is finished being configured, it needs to be started, or powered on, to be brought back online. To 1. 2. 3. start, or power on, the virtual server: Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. Select the host platform server with the existing virtual server. Click the Management button and then click Manage > Power On.
When the provisioning task completes successfully, the virtual server is started or powered on. The displayed state of the virtual server will change. Note: If necessary, refresh the page to see the change.
Adding disk resources to virtual servers

Add more disk resources to existing virtual servers to increase their storage capabilities. Before you begin Ensure that the following requirements are met before you add hard disks to the virtual server:
1075
1. VMware Tools are installed. For installation instructions, see the VMware documentation: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC &externalId=1014294 2. The target virtual server has a management IP address assigned and credentials are set. To verify these requirements, navigate to the Provisioning Computers applications and search for the virtual server. Verify the information on the Credentials tab. If the information is missing, run an Initial Discovery on the virtual server. Hard disks that are added to provisioned virtual servers, cannot be removed. When virtual servers are deleted, all hard disks that are associated with the virtual server are also deleted and removed from the provisioning database. Procedure To add additional hard disks to your virtual server, follow these steps: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select the host platform server that the virtual server is associated to. > Add Resource Allocations. 3. Beside the virtual server, click Detail Menu 4. Click Add Resource Allocation > Add Disk Resource Allocation. 5. In the Details section, specify the following required fields: v Host Platform Quantity: The size of the hard disk to be added to the virtual server. The value is specified in gigabytes (GB) and must be an integer value greater than 0. v Disk Mode: Choose one of three modes. For an explanation of the VMware disk modes, see Step 8 in the VMware documentation: http://pubs.vmware.com/vsp40_i/admin/ t_add_a_hard_disk_to_a_virtual_machine.html. v File System Type: Select the appropriate type. To add multiple disks, repeat steps 4 and 5 for each additional hard disk. 6. Click Submit. The new disks will be added to the virtual server. The provisioning database and the VMware VirtualCenter are updated with the new resources. Considerations for additional hard disks v If you move the virtual server to a new host platform server, the additional hard disks are not moved to the new host platform server, but they will still be accessible. v If you save the virtual server, by creating a saved image in the image library, the image will contain all of the additional hard disks. v When you restore a saved image of the virtual server, the restored virtual server will only contain those disks that were present when the virtual server was saved.
Changing resource allocations on virtual servers

Change the resource allocations on your virtual servers to get the most efficient use of the resources from the host platform server. You might need to change the resource allocations on your virtual server. For example, if a virtual server is consistently not using the CPU amount that it has been allocated from the host platform server, you can decrease the CPU resource allocation on the virtual server. 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select the host platform server that the virtual server is associated to. 3. Beside the virtual server, click Detail Menu > Resource Allocations.
1076
4. In the Resource Allocation window, the Hard Disk, CPU, and RAM resources can be changed. a. To increase the Hard Disk, type the new size in the Host Platform Size field. The hard disk will be increased to the new size that you type. Hard disk can only be increased, it cannot be decreased. b. To increase or decrease the CPU and RAM resources, the VMware virtual server must be stopped. For VMware vSphere 4, some operating systems do support adding CPU and RAM when the virtual server is running. For more information on the supported platforms, see the following document: http://xtravirt.com/vmware-hot-add-memorycpu-support. 5. Click OK. Note: MAXADMIN and TPDEVELOPER users will also see the Save Only option in this window. Save Only saves the changes to the provisioning server but does not update the VMware VirtualCenter. This option is typically used for testing purposes.
Moving virtual servers to a different host platform server

If host platform servers become overloaded, or if you want to consolidate and organize, virtual servers can be moved to different host platform servers. Prerequisite: A datastore shared across the ESX hosts is required to perform the moving operation. If additional hard disks have been added to the virtual server, the hard disks will not move to the host platform server, but they will still be accessible. To move a virtual server to a different host platform server, follow these steps: 1. In the Virtualization Management application, click the host platform server that currently hosts the virtual server. 2. From the list, click the check box next to the virtual server that you want to move. 3. At the bottom of the page, expand the Management button and select Move. 4. Beside Target Host Platform, click Select Value move the virtual server to. 5. Click OK. The virtual server moves to the different host platform server. To verify the change, navigate to the Virtualization Management application and look for the virtual server on the host platform server. and click on the host platform that you want to
Deleting a virtual server

When they are no longer needed, virtual servers that were allocated to a host platform server can be removed. Before deleting a virtual server, it is recommended to power it off first. Deleting virtual servers removes them from both the data model and the host platform server itself. To 1. 2. 3. 4. remove the virtual server from the host platform server and the data model, follow the steps below. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. In the list, find the host platform server that the virtual server is allocated to. On the Host Platform tab, select the virtual server that you want to delete. Click Management > Delete.
5. To schedule the virtual server to be deleted, click Schedule. Accept the default, Run Now, to delete the virtual server immediately, or select Scheduled Start and then click the calendar button to choose the date and time that you want the virtual server to be deleted. Click OK.
1077
6. Click one of the following, depending on whether you want to delete the virtual server from the provisioning data model or destroy it: v Click Delete Record to delete the virtual server from the provisioning data model. Note: Only the MAXADMIN and TPDEVELOPER users can see the Delete Record option in this window. Delete Record saves the changes to the provisioning server but does not update the VMware VirtualCenter. This option is typically used for testing purposes. v Click OK to destroy the virtual server. When the provisioning task completes successfully, the virtual server is removed from the host platform server and the provisioning data model. Deleting multiple virtual servers from the data model: Multiple virtual servers can be deleted from the data model at the same time using the Provisioning Computers application. 1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. To enable selecting multiple computers, click the Select Records checkbox at the bottom of the list of computers. 3. Select the virtual servers that you want to delete from the data model. 4. Click Select Action > Delete Computers. The virtual servers that you selected for deletion are listed. 5. Click one of the following, depending on whether you want to delete the virtual servers from the provisioning data model or destroy them: v Click Delete Record to delete the selected virtual servers from the provisioning data model. Note: Only the MAXADMIN and TPDEVELOPER users can see the Delete Record option in this window. Delete Record saves the changes to the provisioning server but does not update the VMware VirtualCenter. This option is typically used for testing purposes. v Click OK to destroy the selected virtual servers. You can also click Schedule to schedule deletion. When the provisioning task completes, the selected virtual servers are removed from the provisioning data model or destroyed, depending on the option you selected.
Tutorial: Creating virtual Fibre Channel adapters

Tivoli Provisioning Manager v7.2.0.2 provides support for NPIV on pSeries. NPIV is an industry standard technology for Fibre Channel networks. NPIV technology enables you to connect multiple LPARs to a single physical Fibre Channel adapter port. Each LPAR is identified by unique WWPNs, which means that you can connect each LPAR to independent physical storage on a SAN. Using NPIV technology, you can configure multiple LPAR virtual servers to access their own physical storage through the same physical Fibre Channel adapter. You can use Tivoli Provisioning Manager to create LPARs with virtual Fibre Channel adapters (NPIV adapters). Compared with creating a non-NPIV enabled LPAR, using Tivoli Provisioning Manager to create an NPIV-capable LPAR involves additional configuration steps. When configuring an LPAR with NPIV virtual Fibre Channel adapters, you need to configure the backend storage and a SAN switch separately, either using Tivoli Provisioning Manager preconfigured storage automation solution or manually.
1078
As well as providing you with the ability to create LPARs with virtual Fibre Channel adapters, you can also use Tivoli Provisioning Manager to add virtual Fibre Channel adapters to existing LPARs. You can discover existing NPIV resources already set up on your system. There is also an email notification feature. NPIV functionality is not supported for Linux LPARs. SAN switch and backend storage management is not supported by the pSeries automation package. Nor is NPIV configuration using IVM. This tutorial describes how to use the NPIV features in Tivoli Provisioning Manager, also known as virtual Fibre Channel adapters. It describes how the NPIV features work and covers how to create an LPAR with NPIV capability. It also describes how to add a virtual Fibre Channel adapter to an existing LPAR, how to discover NPIV resources, and how to set up email notification.
Learning objectives
In this tutorial you learn how to: v Discover NPIV resources v Create an LPAR with virtual Fibre Channel adapter v Add a virtual Fibre Channel adapter to an existing LPAR v Set up email notification to send details of LPAR creation to administrators v Delete a virtual Fibre Channel adapter
Time required
This tutorial should take approximately 90 minutes to complete. If you explore other concepts related to this tutorial, it could take longer to complete.
Skill level
Advanced. Modules in this tutorial v Requirements v Part 1 Adding virtual Fibre Channel adapters to LPARs on page 1080 v Part 2 Setting up email notification and deleting virtual Fibre Channel adapters on page 1083
Requirements
Before you begin creating LPARs with virtual Fibre Channel adapters, make sure that your system meets all of the requirements.
User roles and requirements for virtual Fibre Channel adapters

Before creating LPARs with virtual Fibre Channel adapters, ensure that you have the required knowledge and access rights as listed here.
1079
Table 196. User roles Role Provisioning Administrator Description This user can perform all of the provisioning tasks and manages the data model. v Discovers computers and devices. including NPIV resources. v Creates virtual servers, virtual server templates, and LPARs. v Manages virtual servers. Deployment Specialist Provisioning Configuration Librarian v Installs software on target computers or virtual servers. Discovers computers. v Knowledge of operating systems. Skills v Knowledge of the provisioning environment. v Knowledge of operating systems. v Knowledge of virtualization technologies.
Hardware and software requirements for creating virtual Fibre Channel adapters
To create LPARs with virtual Fibre Channel adapters, your system must meet the hardware and software requirements listed here.
The minimum hardware requirements to add virtual Fibre Channel adapters to LPARs are as follows: v Any POWER6-based system, or later. You must install a minimum System Firmware level of EL340_039 for the IBM Power 520 and Power 550, and EM340_036 for the IBM Power 560 and IBM Power 570. v A minimum of one 8 GB PCI Express Dual Port Fibre Channel Adapter (Feature Code 5735). v An NPIV-enabled SAN switch. Only the first SAN switch attached to the Fibre Channel adapter in the virtual I/O server must be NPIV-capable. Other switches in your SAN environment do not need to be NPIV-capable.
The software requirements are as follows: v HMC V7.7.1 SP2, or later. v Virtual I/O Server Version 2.1 with Fix Pack 20.1, or later. v AIX 6.1 TL2, or later; AIX 5.3 TL9, or later. v SDD 1.7.2.0 + PTF 1.7.2.2. v SDDPCM 2.2.0.0 + PTF v2.2.0.6. v SDDPCM 2.4.0.0 + PTF v2.4.0.1.
Part 1 Adding virtual Fibre Channel adapters to LPARs

You can use Tivoli Provisioning Manager v7.2 FP2 to create LPARs with virtual Fibre Channel adapters. You can also add virtual Fibre Channel adapters to previously created LPARs.
Learning objectives
After completing the lessons in this module, you will know how to do the following: v Discover NPIV resources and add them to the Data Center Model v Create LPARs with virtual Fibre Channel adapters v Add virtual Fibre Channel adapters to existing LPARs v Create a virtual server with a virtual Fibre Channel adapter
1080
Time required
This module should take approximately 60 minutes to complete.
Prerequisites
Before you begin, ensure that your system meets the minimum requirements described in Requirements on page 1079.
Discovering NPIV resources

You can discover your NPIV-enabled resources using Tivoli Provisioning Manager v7.2.0.2. The discovery identifies all of the Fibre Channel and virtual Fibre Channel adapters, if the system is NPIV-capable. To discover NPIV-enabled resources, run the IBM Hardware Management (HMC) Discovery configuration. You can set the discovery parameters and select several LPARs to run the discovery against. 1. 2. 3. 4. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. Search for and click the IBM Hardware Management Console (HMC) Discovery configuration. Set the Discovery Parameters as required and select LPARs as required. Click Run Discovery. The discovery runs as follows: v All of the virtual Fibre Channel adapters are discovered and populated as fibre-channel-adapter resources under the host platform that represents the pSeries server. v Information including the WWPNs of virtual Fibre Channel adapters on LPARs are discovered and populated as resource allocation of the LPAR virtual servers.
You have run the IBM Hardware Management Console Discovery to discover NPIV-enabled resources.
Creating an LPAR with virtual Fibre Channel adapters

To create an LPAR with NPIV capability, you use a virtual server template and add a Fibre Channel adapter resource requirement type to the virtual server template. After you have run the IBM Hardware Management (HMC) Discovery, you can create an LPAR with one or more virtual Fibre Channel adapters. To create an LPAR with virtual Fibre Channel adapters, complete the following: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtual Server Templates. and click the virtual server template that you want to use to create the NPIV-enabled LPAR. 2. Click New Resource Requirement. From the Resource Type list, click Fibre Channel Adapter. Click the Shared option. Enter 1 in the Virtual Quantity field. Leave the Host Platform Quantity field value at 0. For the Resource Group field, click the select value button and choose an NPIV Resource Group (NPIV.<vios_name>.fcsname) 8. Optional: If required, set the parameters for the Fibre Channel Adapter resource requirement, as described in the following table. The values that you specify will be saved in the Data Center Model and displayed in the Resource Allocation screen for each virtual Fibre Channel adapter. If you do not set the parameters, these values are ignored. 3. 4. 5. 6. 7.
1081
Table 197. Resource requirement parameters Property NPIV.order storage.speed Description The order to allocate the virtual Fibre Channel adapters. Adapters with a lower number are allocated first. The speed of the Fibre Channel adapter storage, for example, Medium or Fast. This is used only for email notifications to the SAN administrator, if you set up email notification. The storage size, for example, 50 GB or 100 GB. This is used only for email notifications to the SAN administrator, if you set up email notification.
storage.size
9. Repeat steps 2 to 8 to add more Fibre Channel adapter resource requirements. This is required if you configure a SAN LUN with multiple paths through dual VIO servers. For a dual VIOS configuration, create two Fibre Channel adapter resource requirements, with corresponding NPIV resource groups (NPIV.<vios1_name>.<fcs_name1>, NPIV.<vios2_name>.<fcs_name2>) 10. Save the changes. You have created an LPAR with a virtual Fibre Channel adapter. The LPAR configuration is saved in the Data Center Model and you can view in the resource allocation screen for the virtual Fibre Channel adapter.
Adding a virtual Fibre Channel adapter to an existing LPAR

You can add a virtual Fibre Channel adapter to an existing LPAR. You can use Tivoli Provisioning Manager v7.2.0.2 to add a virtual Fibre Channel adapter to an LPAR that you created previously. To add a virtual Fibre Channel adapter to an existing LPAR, complete the following: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Click a host platform and virtual server. > Add Resource Allocations. 3. Click Detail Menu 4. From the Add Resource Allocations screen, click the Add Resource Allocation button and select Add NPIV Adapter Resource Allocation. 5. From the screen that displays, select the required NPIV Resource Group (NPIV.<vios_name>.fcsName). 6. Optional: If required, set the parameters for the Fibre Channel adapter resource requirement, as listed in the following table. These parameters are used only for email notification.
Table 198. Fibre Channel adapter parameters Property name Storage Speed Description The required speed of Fibre Channel adapter storage, for example, Medium or Fast. It is used only for email notification to the SAN administrator, if you set up email notification. The required storage size, for example, 50 GB or 100 GB. It is used only for email notification to the SAN administrator, if you set up email notification.
Storage Size
7. Save the changes. You have added a NPIV resources to an existing LPAR.
1082
Creating a virtual server with virtual Fibre Channel adapters and configuring the backend storage
Create a virtual server with virtual Fibre Channel adapter. When the virtual Fibre Channel adapter has been allocated, you can configure the backend storage either manually or using Tivoli Provisioning Manager automation integration. You need to configure the backend storage manually or using the either using the Tivoli Provisioning Manager preconfigured storage automation solution. To create a virtual server with virtual Fibre Channel adapter, complete the following steps: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select a host platform and create a virtual server using the virtual server template with Fibre Channel adapter resource requirements. For information about how to create a virtual server using a virtual server template, see Creating virtual servers on page 1073. 3. When the virtual Fibre Channel adapter has been allocated, go to the Virtualization Management application. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 4. Click a host platform and virtual server. 5. Select the Fibre Channel Adapter resource allocations for the virtual server. The following properties are available for each Fibre Channel adapter resource allocation.
Table 199. Post VFC adapter allocation configuration Property Name vio.server vio.client_slot_num vio.server_slot_num vio.vfchost vio.fcs vio.wwpns Description The name of VIO server. The Fibre Channel adapter slot number for the LPAR. The Fibre Channel adapter slot number for VIO server. The virtual Fibre Channel host name. The fcs name. Two comma-separated WWPN numbers.
6. Manually configure the SAN switch using the vio.wwpns value. WWPNs are automatically generated during the virtual Fibre Channel adapter allocation. The WWPNs are displayed as the vio.wwpns property in the Resource Allocation screen for the LPAR virtual server. You have created a virtual server with virtual Fibre Channel adapter and configured the backend storage.
Part 2 Setting up email notification and deleting virtual Fibre Channel adapters
You can use Tivoli Provisioning Manager v7.2.0.2 to set up email notification for NPIV-enabled resources. You can set up email notification for administrators or others to receive emails about the status of virtual Fibre Channel adapter allocations to LPARs.
Learning objectives
After completing the lessons in this module you will know how to do the following: v Set up email notification v Delete virtual Fibre Channel adapters
Time required
This module should take approximately 30 minutes to complete.
1083
Prerequisites
Ensure that your system meets all of the requirements as described in Requirements on page 1079.
Setting up email notification for virtual Fibre Channel adapter allocation

You can set up email notification to send emails about that status of your NPIV allocations to yourself or administrators. You can use the email notification feature to send the status of newly allocated virtual Fibre Channels with WWPN addresses directly to user email accounts. You can use this email notification feature for creating a new LPAR with virtual Fibre Channel adapters and for adding a virtual Fibre Channel adapter to an existing LPAR. Emails are not sent if the LPAR is not created successfully. If you set the parameters when configuring the resource requirement, the email notification includes the following: v WWPN v Speed v Size, in gigabytes v The LPAR name and the pServer name that it belongs to To set up email notification, you define the email addresses to which you want to send the notification. To do this, add the email.addresses variable under the deployment engine component on the Hardware Management Console computer object. Set the value to the email address to which you want to send the notification. If you want to send the notification to multiple email addresses, use a comma to separate the email addresses. You have now set up email notification for virtual Fibre Channel adapter allocations.
Deleting a virtual Fibre Channel adapter from an LPAR

When you delete an LPAR virtual server, virtual Fibre Channel adapters are automatically deleted. You can also delete a virtual Fibre Channel adapter from an existing LPAR virtual server. If your LPAR is running and a virtual Fibre Channel adapter is currently being used by that LPAR, you must either shut down the LPAR or you must remove the virtual Fibre Channel adapter on the LPAR system manually using the following command:
rmdev -l <fcs_name> -R
To remove a virtual Fibre Channel adapter from the Tivoli Provisioning Manager user interface, complete the following steps: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Search for and click the host platform. 3. Choose your LPAR, click the Detail Menu button and click Resource Allocations. 4. Click the Delete button beside the virtual Fibre Channel adapter. 5. Click OK. The logical device operations HostPlatform.DeallocateVirtualResource workflow is called to remove the virtual Fibre Channel adapter from the LPAR and related configuration on the VIO server. You have deleted a virtual Fibre Channel adapter from an existing virtual server.
Tutorial: Managing virtual servers and host platform servers using Solaris Zones
This tutorial demonstrates how to maximize your IT resources by using the Solaris Zones virtualization technology.
1084
Solaris Zones virtualization is on the operating system level. The Solaris Zones technology provides a virtual operating system environment within a single instance of the Solaris 10 operating system. Each virtualized environment, called a Solaris Zone, has its own identity that is separate from the underlying hardware. Each Solaris Zone appears to be a completely separate system to applications and users. A Solaris Zone has its own users, root user, files, IP addresses, IP ports, host name, and so on. It can act like an independent computer from the application perspective. Using Solaris Zones with Tivoli Provisioning Manager, you can create and delete whole root and sparse root zones. Performing provisioning tasks is supported for whole root zones. There is limited support for performing tasks on sparse root zones. For example, you can run an inventory scan on a sparse root zone but installing the Tivoli Common Agent is not supported for sparse root zones. Whole root zones contain all of the Solaris 10 packages. Sparse root zones contain only a subset of the system packages and the required host file systems are shared as read-only. In this tutorial, any general reference to Solaris Zones will refer to whole root Zones. Note: You can install applications, for example, Websphere Application Server or Oracle Database, on sparse zones but the software configuration template must be changed first. Because the sparse zone has only a subset of the Solaris 10 operating system files, the typical install path parameters specified in the software configuration template, for example, /opt/ or /user, cannot be used. Change the software configuration template for the application to ensure that the application installation will not choose these directories on the Solaris sparse zone. Note: Tivoli Provisioning Manager software deployment does not support installation of DB2 in Solaris Zone.
Learning objectives
In this tutorial you will: v Learn how to discover computers using the initial discovery. v v v v v Learn Learn Learn Learn Learn how how how how how to to to to to discover which computers have Solaris Zones capabilities using the Solaris discovery. add credentials to a Solaris Zone. create a Solaris Zone using a virtual server template. run an inventory scan and install the Tivoli Common Agent on a Solaris Zone. power on and off, change resource allocations on, and delete Solaris Zones.
An automation package called SolarisZones_Virtual_Infrastructure can be used for creating and managing virtual servers using Solaris Zones technology. This is provided with Tivoli Provisioning Manager Additional details about using the SolarisZones_Virtual_Infrastructure automation package are available in the automation package documentation. To view the documentation: 1. 2. 3. 4. 5. Click Go To > Administration > Provisioning > Device Drivers. In the Device Drivers list, type Solaris to see all of the device drivers related to Solaris Zones. Click any of the Solaris Zone device drivers. Click the Documentation link. Click the Automation Package link.
Prerequisites
Ensure that you meet all requirements described in the Requirements on page 1087 before you begin the tutorial.
1085
Modules in this tutorial v Requirements on page 1087 v Part 1: Setting up the environment on page 1087 v Part 2: Creating a Solaris Zone on page 1089 v Part 3: Performing Solaris Zone activities on page 1093
Solaris Zones virtualization process

It is important to understand the overall virtualization process before you start managing virtualization with Tivoli Provisioning Manager. The virtualization process using the Solaris Zones technology includes the following steps. The steps are discussed in detail below the diagram, and the role required to perform each step is shown in brackets.
Select virtual server template Delete virtual server
Initial discovery
Computers
Create virtual server
Perform tasks
Deploy patches Solaris - HostPlatform and Zones Discovery Resource allocation Deploy software
Host platform server and Solaris Zones
Install TCA
Legend Provisioning Administrator Deployment Specialist
1. Discovering computers (Provisioning Administrator) This process consists of running initial discovery to discover all of the Solaris computers to add them to the data model. After the computers are found, run the Solaris discovery. This discovery configuration identifies the computers that have capabilities and marks those computers as host platform servers. Tip: The task of discovering computers can also be performed by the provisioning configuration librarian. 2. Creating the virtual server (Provisioning Administrator) This process consists of selecting a virtual server template to create the virtual server with. You can also select a software stack to add software to the virtual server. 3. Performing tasks on the Solaris Zones virtual servers (Deployment Specialist) This process consists of performing activities on the virtual servers. You can install the Tivoli Common Agent and deploy software and patches on the virtual servers.
1086
Tip: Resource allocations can only be done by the provisioning administrator. The provisioning administrator can also perform all of the other tasks on Solaris Zones. 4. Deleting a virtual server. (Provisioning Administrator) This process consists of removing the virtual server from the host platform server and the provisioning data model.
Requirements
Before you start working with virtualization using Solaris Zones, ensure that you meet all requirements.
Hardware and software requirements for Solaris Zones

Ensure that you are using supported hardware and software required for Solaris Zones virtualization
v Target computers with the Sun Solaris 10 operating system installed.
v Sun Solaris 10 operating system. Note: Only Solaris 10 or later offers for support for CPU and memory allocation. v The Sun Solaris 10 operating system requires the zoneadm and zonecfg tools. These tools are typically present by default in a standard installation of the Solaris 10 operating system. v An automation package called SolarisZones_Virtual_Infrastructure is used for creating and managing Solaris Zones virtual servers. This automation package is provided with Tivoli Provisioning Manager Additional details about using the SolarisZones_Virtual_Infrastructure automation package are available in the automation package documentation. To view the documentation: 1. Click Go To > Administration > Provisioning > Device Drivers. 2. In the Device Drivers list, type Solaris to see all of the device drivers related to Solaris Zones. 3. Click any of the Solaris Zone device drivers. 4. Click the Documentation link. 5. Click the Automation Package link.

To complete virtualization tasks, ensure that you have the required knowledge and access rights.
Part 1: Setting up the environment

In this part, you will learn how to prepare the environment for virtual servers.
1087
Discovering Solaris computers

Use the initial discovery to discover the Solaris computer that will be used as a host platform server. Ensure that your user role is Provisioning Administrator or the equivalent. Initial discovery is typically used after you install the product to discover all of the computers in your environment. This time, you will run the initial discovery to discovery the Solaris host platform server. To run the initial discovery, follow these steps: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. Search for the discovery configuration called Initial Discovery and click its name on the displayed list. 3. To specify the computers that you want to discover, click the IP Address Ranges tab. Tip: You can also specify a particular computer by typing the host name of the computer in the Host Name field on the Computers tab. 4. Click New Row. 5. In the Start and End fields, type the IP addresses of your target computers. After each set of IP addresses, click New Row. Tip: You can also specify subnetworks that you want to discover. If, for example, all the target computers that you want to discover are in a LAN, click the Subnetworks tab and specify the IP address and mask for the LAN. After specifying each subnetwork, click New Row. 6. Click the Credentials tab. 7. Click New Row. 8. Type the user ID and password. After each set of credentials, click New Row. If you specify more than one set of credentials, they will be attempted on each target computer in the order that they are listed. If the logon attempt on a target computer is successful, the computer is added to the data model. Notes: v The system will attempt to connect to each IP address using each user name and password provided until it finds a user name and password that can be used to connect successfully. This might cause user accounts to be locked out, depending on the security policy enforced on the target computers. v You might need to increase the default timeout value if you are on a slower network or you are attempting to discover slower computers. 9. 10. 11. 12. . Click Save Click Run Discovery. Type a name for the discovery task and click Submit. In the message box that is displayed, click OK to go to the Provisioning Task Tracking page so that you can monitor the discovery task. 13. Click Refresh to update the task status until the task is completed.
The discovery task is displayed with a status of Success on the Provisioning Task Tracking page and the Solaris computers that can be used as host platform servers are recorded in the details of the discovery task.
Discovering Solaris host platform servers and virtual servers

Run the discovery configuration, Solaris - HostPlatform and Zones Discovery, to identify the Solaris 10 computers that can be used as host platform servers.
1088
Run the Initial Discovery to discover all of the Solaris computers in your environment. The Solaris discovery configuration will identify the selected Solaris computers in the provisioning data model that have the capability to host Solaris Zones. All Solaris 10 computers must have this capability by default. The discovery will continue and identify any existing Solaris Zones and their resource allocation To discover the Solaris computers, follow the steps below: 1. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 2. Search for the discovery configuration called Solaris - HostPlatform and Zones Discovery and click its name on the displayed list. 3. Click Run Discovery.. 4. Click Select > Computers and select the Solaris computer that you discovered in the Initial Discovery. Click OK. 5. Type a name for the discovery task and click Submit. 6. In the message box that is displayed, click OK to go to the Provisioning Task Tracking page so that you can monitor the discovery task. 7. Click Refresh to update the task status until the task is completed. After the discovery completes successfully, the Solaris host platform servers and virtual servers are defined in the data model. To view the discovered Solaris host platform servers and virtual servers follow the steps below: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. From the list, select the discovered host platform server. You will see the list of all of the Solaris Zones allocated to the host platform server. 3. Click the Hardware and Software tabs to view the resources of the host platform server. Now that you have discovered the Solaris host platform servers, you can continue to the next tutorial lesson and create a Solaris Zone.
Part 2: Creating a Solaris Zone

Virtual servers are created by allocating hardware resources from the host platform server. A virtual server template defines the resource requirements for CPU, memory, hard disk, and the network interface card (NIC). In this part of the tutorial, you will learn how to create a Solaris Zone virtual server.
Creating a virtual server template

Use a virtual server template to specify the resource requirements and other properties of a new virtual server Virtual server templates are used to allocate virtual servers. A virtual server template has various requirements such as memory and hard disk size. When you specify a virtual server template, a virtual server is allocated with all the same requirements as that template, assuming that the host platform server has sufficient resources to satisfy the allocation. There are several methods of defining a virtual server template. You can do one of the following: v Create a virtual server template. v Clone an existing virtual server template. v Change a predefined virtual server template. In this tutorial, we will clone an existing template. To clone a virtual server template:
1089
1. 2. 3. 4.
Click Go To > IT Infrastructure > Provisioning Inventory > Virtual Server Templates. Click the existing Solaris virtual server template, SolarisZones_TEMPLATE. Click Select Action > Duplicate Virtual Server Template. Type a unique name for the new virtual server template. Note: The name of a virtual server template is not related to the name of the virtual servers you create with it.
5. Click Save
The virtual server template is successfully added. Now you can add hardware resources to the virtual server template. Adding hardware resource requirements: You can add new resources or change the hardware resources on the cloned virtual server template. To add a hardware resource requirement on the virtual server template: 1. Click New Resource Requirement. 2. In the Resource Type field, select the resource type that you want to add. The following resource types are supported for Solaris Zones: v Generic resource v CPU v Memory v NIC v Disk Partition For information about the parameters that can be defined for these resource types, see the Solaris Zones Virtual Infrastructure automation package. 3. Indicate whether the requirement needs to be dedicated to the virtual server by selecting Shared. Note: v If a resource is not shared with other virtual servers, the corresponding resource on the host platform server is decremented when a virtual server is allocated. v If the resource is shared with other virtual servers, 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 needed. to see a list of the available resource 4. Optional: Select a Resource Group Name. Click Select Value groups. A resource group is a logical group to which resources belong. For example, if you have multiple disks and you want to allocate them together, you can add them to a resource group. 5. The following fields will display depending on the selection in the Resource Type list.
Field Host Platform Quantity Description Not applicable. This is not used for the Solaris Zones virtualization technology.
1090
Field Virtual Quantity
Description The virtual quantity specifies how many units of the physical resource will be visible and available to the created Solaris Zone. For example, for the CPU resource type, the Virtual Quantity value depends on whether or not you have indicated that the resource will be Shared. v If you selected Shared, the CPU resource will be shared with other Solaris Zones allocated to the host platform server. For example, you might type a Virtual Quantity value of 100 shares of the CPU resource on the host platform server. v If the CPU resource is not Shared, the CPU resource is dedicated to this Solaris Zone. For example, you might type a Virtual Quantity value of 2. The Solaris Zone will think that it has 2 available CPUs. The host platform server must have more than 2 available CPUs in order for you to allocate 2 CPUs to the Solaris Zone. For each type, the quantity is measured differently and refers to the quantity on the virtual server: v Memory: Megabytes (MB). v NIC: Only a whole NIC can be specified but there can be multiple NICs. v CPU: The number of virtual CPUs allocated to the virtual server. v Generic resource: No specific type.
6. Click Save. The virtual server template is updated with the new requirement.
Configuring netmask and root password on virtual server templates for new Solaris Zones
You can configure the netmask setting in a virtual server template for the network interface card for a new Solaris Zone that you are creating. You can also define the root password for a Solaris Zone in a virtual server template for a new Solaris Zone. You can configure both of these features or you can configure them independently of each other. If you do not configure these parameters or if you specify incorrect information, the default values of the Solaris host platform are used. You must have a Solaris Zone virtual server template created and available. This task describes how to configure the root password and netmask using a virtual server template. You must have Perl installed on the host platform to enable encrypting of the root password. In this tutorial, you first define the root password using a Solaris Zone virtual server template. Then you configure the netmask for the Solaris Zone. Both of these configuration tasks are optional. 1. 2. 3. 4. Click Go To > IT Infrastructure > Provisioning Inventory > Virtual Server Templates. Click the Solaris virtual server template that you are using to create the new Solaris zone. Click the Variables tab. Click New Row to add a new variable: a. In the Variable field, enter the variable name for the root password, admin.password. b. For Component, select Entire system.
1091
c. In the Value field, enter your password. Use only alphabetic characters in your password. Do no use shell script sensitive characters in your password because they might not be encrypted correctly. 5. d. Click Save. The password is encrypted. Now that you have configured the root password for your new Solaris Zone, you can also configure the netmask value. Click Go To > IT Infrastructure > Provisioning Inventory > Virtual Server Templates. Click your Solaris Zone virtual server template. Click your NIC resource. Click New Row to add a new parameter for the netmask: a. Enter the name for the netmask parameter, netmask. b. Enter the netmask value that you want to specify, such as 255.0.0.0. c. Click Save. You have configured the root password and netmask for your new Solaris Zone. After the Create Virtual Server deployment request has completed, verify that you can log in to the new Solaris Zone with the password you specified. You can do this by running zlogin -C <zone_name> on the host platform, using the root password that you defined in the procedure. Alternatively, you can use remote login protocols. If you configured the netmask setting, you can verify your netmask configuration by entering ifconfig -a in a command prompt. After you have verified that the configuration is correct, you can proceed to the next lesson to create your Solaris Zone.
6. 7. 8.
Creating a Solaris Zone virtual server

A virtual server shares its resources with other servers. To add a virtual server: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select a host platform server. 3. From the Select Action menu, click Create Virtual Server. 4. Type the name of the new virtual server. 5. In the Virtual Server Template field, click Detail Menu server template that you created in the previous task. > Select Value and select the virtual
a. Optional. You can make changes to a virtual server template directly from the Create Virtual > Go Server pop-up window. Beside the Virtual Server Template field, click Detail Menu To Virtual Server Templates. This will redirect you to the Virtual Server Templates application. From the list, select the virtual server template that you want to change. For detailed information about the Resource Requirements and Variables that are required or that can be changed, see the VMware automation package documentation. When you are finished making your changes, and click Return With Value to return with your changes to the Create Virtual click Save Server pop-up window. 6. Optional. You can make changes to a virtual server template directly from the Create Virtual Server > Go To Virtual pop-up window. Beside the Virtual Server Template field, click Detail Menu Server Templates. This will redirect you to the Virtual Server Templates application. From the list, select the virtual server template that you want to change. When you are finished making your to save your changes and click Return With Value to return with your changes, click Save changes to the Create Virtual Server pop-up window. Note: For more information on Customized variables for Virtual Server template deployments see the tables at the bottom of this page.
1092
7. Optional. In the Software Stack field, click Select Value and select a software stack that is appropriate to the creation of this virtual server. For example, since the Solaris Zone virtual server is created with an operating system, select a software stack to add in addition to the operating system, such as Tivoli Common Agent. Note: If you create a virtual server using a software stack that includes the Tivoli Common Agent and the Tivoli Common Agent installation fails, the virtual server will still be created. To change this behavior so that the virtual server will be destroyed add a variable called Roll_Back on the host platform server and give the variable a value of true. 8. Optional. You can make changes to a software stack directly from the Create Virtual Server pop-up > Go To Software Stacks. This will window. Beside the Software Stack field, click Detail Menu redirect you to the Software Stacks application. From the list, select the software stack that you want to save your changes and to change. When you are finished making your changes, click Save click Return With Value to return with your changes to the Create Virtual Server pop-up window. 9. To schedule the virtual server to be created, click Schedule. Accept the default, Run Now, to create the virtual server immediately, or select Scheduled Start and then click the calendar button to choose the date and time that you want the virtual server to be created. Click OK. 10. Click OK. 11. A task is launched. At the prompt, you can choose to jump to the Provisioning Task Tracking application to monitor the task. The virtual server is now added. Now that the virtual server has been created, you can perform activities like adding credentials, installing the Tivoli Common Agent and running an inventory scan.
Part 3: Performing Solaris Zone activities

You can perform some Solaris Zones activities, like deleting and powering on and off, without credentials. Other activities require that credentials are added to the Solaris Zone.
Adding credentials to the Solaris Zone

Before you can perform activities like running an inventory scan or installing the Tivoli Common Agent, credentials must be configured on the discovered Solaris Zones. This task is optional. You do not need to add credentials to proceed with virtualization tasks such as creating and deleting Solaris Zones. You do need to complete this task if you want to manage vSolaris Zones by doing tasks like patch deployments and software deployments. To 1. 2. 3. 4. add credentials to a Solaris Zone, follow the steps below: Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. Click the host platform server and then select one or multiple Solaris Zones to add credentials to. Click Add Credentials > SSH and SCP. Enter the required credential information and then click OK to save your changes.
The credentials are now successfully added to the Solaris Zone. Now you can perform tasks on the Solaris Zones virtual server. For example, you can install the Tivoli Common Agent and run an inventory scan.
1093
Installing the Tivoli Common Agent on Solaris Zone

The provisioning server uses the Tivoli common agent for some software management features, including software distribution and software compliance management. Installing the common agent on the Solaris Zone also permits the provisioning server to access the computer without needing to know the credentials of the computer. Note: This is an optional task. The common agent does not need to be installed on a Solaris Zone to be able to perform virtualization activities like deleting, or powering on and powering off the Solaris Zone. Restriction: Installing the Tivoli Common Agent on a sparse Solaris Zone is not supported. The provisioning server uses the Tivoli Common Agent for some software management features, including software distribution and software compliance management. The common agent is a program that automatically performs some service, such as data collection. Installing the common agent on the virtual server also permits the provisioning server to access the computer without needing to know the credentials of the computer. See the Tivoli Common Agent documentation to learn more about this feature. The Tivoli Common Agent can only be installed on whole root Solaris Zones. 1. 2. 3. 4. 5. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. In the list, click the host platform server. Select the virtual server. Click Management > Software > Install Common Agent. Type a name for the installation task.
6. Click Submit. The Tivoli Common Agent is now installed on the virtual server. Users can now manage the virtual server without knowing its credentials and you can use the software distribution and scalable distribution infrastructure feature of the provisioning server.
Running an inventory scan on a Solaris Zone

Run an inventory scan on the Solaris Zone to identify the software on the computer. You can run the inventory scan agentless, which means that the common agents do not have to be installed on the virtual server. The common agents provide the ability to communicate with the computer without having to provide credentials. Note: This is an optional task. You do not need to run an inventory scan to perform virtualization management tasks such as powering on and powering off a Solaris Zone or moving or deleting a Solaris Zone. 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. In the list, click the host platform server. 3. Select a virtual server. 4. Click Management > Run Inventory Scan. To see the discovered resources, follow the steps below: 1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. 2. Select a host platform server that was just discovered. On the Host Platform tab you will see all of the virtual servers allocated to the host platform server. > Go to Provisioning Computers. 3. Select a virtual server and click Detail Menu 4. On the Computer tab of the Provisioning Computers application, you can view the detail information for the virtual server. Click the Hardware and Software tabs to see the resources of the virtual server.
1094
5. To go back to the Virtualization Management application, click Return.
Deleting a Solaris Zone

When they are no longer needed, Solaris Zones can be removed. To delete the Solaris Zone: 1. 2. 3. 4. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management. In the list, find the host platform server that the virtual server is allocated to. On the Host Platform tab, select the virtual server that you want to delete. To schedule the virtual server to be deleted, click Schedule. Accept the default, Run Now, to delete the virtual server immediately, or select Scheduled Start and then click the calendar button to choose the date and time that you want the virtual server to be deleted. Click OK. 5. Click OK to confirm that you want to delete the Solaris Zone. Note: MAXADMIN user and the TPDEVELOPER user will also see the Delete Record option in this window. Delete Record saves the changes to the provisioning server but does not update the host platform server. This option is typically used for testing purposes. The Solaris Zone is removed from both the data model and the host platform server itself.
Verifying results
Verify the virtualization information in your data model using the available predefined reports. There are a few inventory reports available that provide information about the virtual servers in your data model.
Table 201. Reports for virtualization Report description How many virtual servers are created on a specific host platform server? What servers are in the data model? What are the server details, including networking and other resource details? How many servers are installed with which operating systems? Results This report identifies the virtual servers that are installed on a specific host platform server. This report identifies all of provisioning servers in the data model. This report shows all of the information about provisioning servers. This report identifies the number of servers that are installed with each operating system.
What to do next
You can create your own custom reports for specific virtual server information. For more information on creating your own reports, see the Report Developer Guide in the Developer Guide section of the information center.
Troubleshooting virtualization management

To help you to troubleshoot problems with virtualization management, gather as much information as possible about the error. Review the following list to assess the problem.
1095
Procedure
1. Verify that all prerequisite requirements for the scenario were met, as described in the technology specific prerequisite check list: v VMware: Requirements on page 1060 v Solaris Zones: Requirements on page 1087 2. If an error message with a message ID is displayed, search for the message ID in the information center or see the Tivoli Provisioning Manager Troubleshooting Guide for a description of the error message. 3. If a provisioning task fails during the tutorial, check any error messages generated by the provisioning workflows that are part of the task. For more information, see the Viewing workflow execution status from the Web interface topic. 4. Check the log files for error messages. The following log files contain information for the scenario.
Table 202. Log files Log file General deployment engine error messages. Location
UNIX Windows Linux Solaris
Linux Solaris
Debugging By default, messages are not copied to the log files. To get more log file information, enable debugging in the log4j.prop file. For detailed steps on enabling debugging, see the document called Deployment engine logs.
UNIX Windows
$TIO_HOME/config
%TIO_HOME%\config
5. Check the Tivoli Provisioning Manager Support technotes and FAQs or the latest available fix pack readme file for information about known issues or updates to the documentation. 6. See the Log files page.
Log files
The following tables help you to recover from virtualization problems. v LPAR problems v v v v v WPAR problems on page 1097 Solaris Zone problems on page 1098 VMware problems on page 1099 KVM problems on page 1100 VMControl problems on page 1101
Note: Many of the log files mentioned in the following tables are located in the TIO_LOGS directory.
LPAR problems
Step where the problem occurs: Creating LPAR virtual servers Check errors in: v Provisioning workflow log v Tivoli Provisioning Manager console log Log files: v HostPlatform.CreateVirtualServer v %TIO_LOGS%\console.log
1096
Step where the problem occurs: Discovering LPARs
Check errors in: 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log 3. Check if the discovery output file exists
Log files: v LPAR discovery v %TIO_LOGS%\console.log v

UNIX Linux
v LPAR discovery_output_*.xml in the TEMP directory:

Windows UNIX
Linux
Powering LPARs on and off
1. Provisioning workflow log 2. Tivoli Provisioning Manager console log
v Device.PowerOn and Device.PowerOff provisioning workflow logs v v

Windows UNIX
Linux
Rebooting hardware LPARs
v Device.HardwareReboot provisioning workflow log v v

Windows UNIX
Linux
Deleting LPARs
v HostPlatform.DestroyVirtualServer provisioning workflow log v v

Windows UNIX
Linux
Performing a Multipath 1. Provisioning I/O (MPIO) workflow log 2. Tivoli Provisioning Manager console log
v pSeries_MPIO_* provisioning workflow logs v v

Windows UNIX
Linux
WPAR problems
Step where the problem occurs: Creating WPAR virtual servers Check errors in: 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log Performing dynamic resource allocation 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log Log files: v HostPlatform.CreateVirtualServer provisioning workflow log v v
Windows UNIX
Linux
v HostPlatform.ExpandResourceAllocation and HostPlatform.ReduceResourceAllocation provisioning workflow logs v v

Windows UNIX
Linux
1097
Step where the problem occurs: Discovering WPARs
Check errors in: 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log 3. Check if the discovery output file exists
Log files: v WPAR discovery provisioning workflow log v v

Windows UNIX
Linux
v aix_wpar_discovery_*.xml in the TEMP directory:

Windows UNIX
Linux
Powering on and off WPARs, rebooting WPARs
1. Provisioning workflow log 2. Tivoli Provisioning Manager console log 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log
v Device.PowerOn, Device.PowerOff and Device.HardwareReboot provisioning workflow logs v v

Windows UNIX
Linux
Deleting WPARs

Windows UNIX
Linux
Synchronizing WPARs
v VirtualServer.Synchronize provisioning workflow log v v

Windows UNIX
Linux
Solaris Zone problems

Step where the problem occurs: Creating Solaris Zone virtual servers Check errors in: 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log 3. Run command from the Solaris host platform server Performing dynamic resource allocation 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log v HostPlatform.ExpandResourceAllocation and HostPlatform.ReduceResourceAllocation provisioning workflow logs v
Windows UNIX
Log files: v HostPlatform.CreateVirtualServer provisioning workflow log v v v

Windows UNIX
Linux
Check command output or system log in: /var/adm/messages
Linux
3. Run command from v the Solaris host v platform server
1098
Step where the problem occurs: Discovering Solaris Zones
Check errors in: 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log 3. Run command from the Solaris host platform server
Log files: v Solaris zone discovery provisioning workflow log v v v

Windows UNIX
Linux
Powering on and off 1. Provisioning Solaris Zones, workflow log rebooting Solaris Zones 2. Tivoli Provisioning Manager console log

Windows UNIX
Linux
3. Run command from v the Solaris host platform server Deleting Solaris Zones 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log

Windows UNIX
Linux
3. Run command from v the Solaris host platform server
VMware problems
Step where the problem occurs: Creating VMware virtual servers Check errors in: 1. Provisioning workflow log 2. VMware console 3. Tivoli Provisioning Manager console log Performing dynamic resource allocation 1. Provisioning workflow log 2. VMware console 3. Tivoli Provisioning Manager console log v
UNIX
Log files: v HostPlatform.CreateVirtualServerprovisioning workflow log v

Windows
Linux
v HostPlatform.ExpandResourceAllocation and HostPlatform.ReduceResourceAllocation provisioning workflow logs v The vmware.log is located in the data store of each virtual server. It is accessible in the VMware console
Windows UNIX
v v
Linux
Discovering the VMware virtual infrastructure
1. Provisioning workflow log 2. VMware console 3. Tivoli Provisioning Manager console log
v VMware discovery provisioning workflow log v The vmware.log is located in the data store of each virtual server. It is accessible in the VMware console
Windows UNIX
v v
Linux
1099
Step where the problem occurs: Powering on and off, rebootingVMware virtual servers
Check errors in: 1. Provisioning workflow log 2. VMware console 3. Tivoli Provisioning Manager console log
Log files: v Device.PowerOn, Device.PowerOff and Device.HardwareReboot provisioning workflow logs v The vmware.log is located in the data store of each virtual server. It is accessible in the VMware console
Windows UNIX
v v
Linux
Deleting VMware virtual servers
1. Provisioning workflow log 2. VMware console 3. Tivoli Provisioning Manager console log
v HostPlatform.DestroyVirtualServer provisioning workflow log v The vmware.log is located in the data store of each virtual server. It is accessible in the VMware console
Windows UNIX
v v
Linux
KVM problems
Step where the problem occurs: Creating KVM virtual servers Check errors in: 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log Performing dynamic resource allocation 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log Discovering a KVM hypervisor 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log Discovering a KVM virtual server 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log Powering on and off, rebooting a KVM virtual server 1. Provisioning workflow log 2. Tivoli Provisioning Manager console log Log files: v HostPlatform.CreateVirtualServer provisioning workflow log v v
Windows UNIX
Linux
v HostPlatform.ExpandResourceAllocation and HostPlatform.ReduceResourceAllocation provisioning workflow logs v v

Windows UNIX
Linux
v KVM Discovery.Ondevice provisioning workflow log v v

Windows UNIX
Linux
v KVM Discovery.Ondevice provisioning workflow log v v

Windows UNIX
Linux

Windows UNIX
Linux
1100
Step where the problem occurs:
Check errors in:
Log files: v HostPlatform.DestroyVirtualServer provisioning workflow log v v

Windows UNIX
Deleting a KVM virtual 1. Provisioning server workflow log 2. Tivoli Provisioning Manager console log
Linux
VMControl problems
For all errors that occur during the install of the VMControl_Virtual_Infrastructure.tcdriver, refer to the following log files: Note: By default, debug messages are not copied to the log files. To get more log file information, change the setting on TIO_HOME/config/log4j.prop to: v log4j.appender.errorfile.threshold=debug v log4j.appender.consolefile.threshold=debug For more information about the log4j tool, see the topic called Configuring logs with log4j.
Step where the problem occurs Check errors in: Log files 1. v v 2. v v 3. v %TIO_HOME%\logs\tcdrivermanager\ objectDump.xml
UNIX Linux Windows Windows UNIX Windows UNIX
Installing the 1. Tivoli Provisioning VMControl automation Manager error log package 2. Tivoli Provisioning Manager console log 3. objectDump.xml
%TIO_HOME%\logs\tcdrivermanager\error.log
Linux
$TIO_HOME/logs/tcdrivermanager/
error.log
%TIO_HOME%\logs\tcdrivermanager\console.log
Linux
console.log
objectDump.xml
Virtualization problems and limitations

Cannot create a VMware virtual server using ESX server

An error occurs when you try to create a VMware virtual server using an ESX server that has run the inventory discovery.
Symptoms
An error occurs when creating a VMware virtual server using a ESX server. If an inventory discovery has been run for a ESX server and it is selected to create a virtual server, the creation workflow might fail with the following error:
1101
COPDEX040E An unexpected deployment engine exception occurred: COPCOM606E The system cannot find managed memory type hardware resource on host platform {ESX server name}.
Causes
This error occurs because the inventory discovery cannot discover the memory that is allocated to the virtualization management.

Do not run an inventory discovery against an ESX server because it will cause unexpected failures on virtualization management. If the inventory discovery is run against an ESX server, remove the server from the provisioning database and then start the VMware HostPlatform Resource and Virtual Machine discovery. The ESX server will be added to the provisioning database by VMware HostPlatform Resource and Virtual Machine discovery and it will be configured properly to manage the virtualization.
Error running the HostPlatform Resource and Virtual Machine discovery

The VMware HostPlatform Resource and Virtual Machine discovery does not work if the inventory discovery is run first.
Symptoms
For a ESX server with multiple CPUs, the VMware HostPlatform Resource and Virtual Machine discovery will not work if the inventory discovery against it has been run first. The following error is returned:
COPDEX172E The CPUResID variable is a single value variable, cannot assign an array value to it
Causes
This limitation occurs because VMware expects only one CPU resource when allocating the resource allocations to virtual servers.

Do not run the inventory discovery against a ESX server because it can cause unexpected failures on virtualization management. If the inventory discovery is run against an ESX server, remove the server from the provisioning database and then start the VMware HostPlatform Resource and Virtual Machine discovery. The ESX server will be added by the discovery and will be configured properly to manage the virtualization.
Error during LPAR creation

An error might occur during an LPAR creation because of DNS naming rules.
Symptoms
During an LPAR creation, the following error occurs:
COPCOM123E A shell command error occurred:....
Causes
1102
The error might occur because the virtual I/O server name does not conform with the DNS naming rule. Virtual server names are required to be defined in DNS and resolved to an IP address. Therefore, the name must conform to both HMC and DNS naming rules.

Change the Vitual I/O server name to conform to the following rules: v Must be between 1 and 63 characters long. v Can only contain letters 'a' through 'z' (case-insensitive), the digits '0' through '9', and the hyphen. v Must begin with a letter. v Must end with a letter or a number.
Connection error running the VMware Virtual Center Discovery

A connection error message occurs during the VMware Virtual Center Discovery. No trusted certificate is found.
Symptoms
The following error displays when running the VMware - Virtual Center Discovery:
Cannot connect to URL https://<Virtual Center IP Address>/sdk using user <user name> because:; nested exception is: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: NO trusted certificate found.
Causes
The keytool command was run in the wrong directory. It must be run in the $JAVA_HOME/jre/lib/ security directory. In this directory, you can find an existing cacerts file.

Ensure that the SSL certificate was imported to the $JAVA_HOME/jre/lib/security directory. For more details about importing the certificate. see the topic called Importing the SSL certificate on page 1064.
Installing the common agent on an AIX WPAR fails

The Tivoli Common Agent cannot be installed on a shared WPARs. Install the Tivoli Common Agent on a dedicated AIX WPAR or Solaris Zone.
Symptoms
When you try to install the Tivoli Common Agent on an AIX WPAR, the installation task fails with the error message COPDEX123E.
Causes
The Tivoli Common Agent cannot be installed on AIX WPARs. Shared or non-shared (dedicated) WPARs are determined by the value of the WPAR.privateusr variable in the virtual server template. To view the virtual server template, navigate to Go To > IT Infrastructure > Provisioning Inventory > Virtual Server Template and then select the server template that was used to create the WPAR. A value of no for the WPAR.privateusr variable means that the server template will create a shared WPAR. Installing Tivoli Common Agent to a WPAR that has been created with this setting will fail.
1103
Note: Because Tivoli Common Agent cannot be installed on any shared WPARs, this issue also applies to shared Solaris Zone. However, if the installation fails with Solaris, no error message is given.

Install Tivoli Common Agent on a dedicated AIX WPAR or Solaris Zone.
Cannot synchronize an AIX WPAR

This is a known limitation with AIX 6.1 LPARs.
Symptoms
Attempting to synchronize an AIX WPAR with its host LPAR fails with the following error message:
COPCOM123E A shell command error occurred: Exit code=70, Error stream="syncroot: ATTENTION, Root part is currently synchronized, but there are other SWVPD inconsistencies. Please execute "/usr/bin/lppchk -v" for more information. syncroot: Returns Status = FAILURE /usr/lib/wpars/wparinstcmd: 0960-231 ATTENTION: /usr/sbin/syncroot -X failed with return code 1. syncwpar: 0960-264 Error synchronizing workload partition nc117195. Return Status = FAILURE.", Output stream="***************** ************************************************************** Synchronizing workload partition nc117195 (1 of 1). **************************************************** Executing /usr/sbin/syncroot -X in workload partition nc117195. syncroot: Processing root part installation status.".
Causes
This is a known limitation with AIX 6.1 LPARs.

To work around this issue, remove any file sets from the LPAR that you do not want to install on the WPAR. From the LPAR, type the following command to remove the file sets:
swvpdmgr -p <fileset>
After the file sets have been removed, run the synchronization again.
Libvirt host platform discovery successful when virtual host discovery fails
The Libvirt host platform discovery completes successfully even though there may be failures in its virtual host discovery task. When running Libvirt host platform discovery, check the error log file for specific errors that are symptoms of a failed virtual host discovery.
Symptoms
A failed virtual host discovery might not be apparent when the Libvirt host platform discovery returns successfully. Be sure to check for the following errors to verify if virtual host discovery has failed:
Failed workflow: Core_Helper_HP_GetNativeVLAN Failed workflow: Libvirt_GetDomainDisks Failed workflow: Libvirt_VirtualMachine_Discovery_Helper Discovery code has failed to import the content of <directory of image .xml file> Exception message: An invalid string has been returned by scriptlet code. Disk information could not be retrieved for virtual machine id: <xxxx>.
1104
Failed workflow: Libvirt_Discover_VirtualMachines Virtual machines discovery completed on host platform id: <xxxx (address of virtual machine)> with errors. Failed to discover the following virtual machines: <name of virtual machine>.
Causes
It is by design that the virtual Libvirt host platform discovery returns successfully even though its virtual host discovery task fails.

The virtual host failure occurs because the virtual host image is not defined properly on the host platform. Be sure that the virtual host image and its .xml definition file are operational and available to the host platform.
Libvirt host discovery misses some virtual servers

Libvirt virtual host discovery fails to add discovered virtual servers to the Tivoli Provisioning Manager data model. This occurs because the new virtual server has the same MAC address as an existing virtual server already contained in Tivoli Provisioning Manager. The existing virtual server is then updated with the attributes of the new virtual server.
Symptoms
When running libvirt virtual host discovery, some virtual servers are not added to the Tivoli Provisioning Manager data model.
Causes
This problem occurs when the new virtual server has the same MAC address as an existing virtual server in the Tivoli Provisioning Manager data model.

If this problem occurs, be sure to verify that all virtual servers are properly functional and have a unique MAC address. Run libvirt virtual host discovery again.
The creation of a dedicated WPAR fails

The WPAR creation fails because the /usr and /opt file system sizes are too small. You can increase the sizes manually.
Symptoms
When you create a dedicated WPAR you specify the values for the /usr and /opt file system sizes in the virtual server template. The creation of the WPAR might fail with the following error message:
mkwpar: 0960-287 Error: /usr requires at least 2288096 blocks
Causes
The /usr and /opt file system sizes are too small. The sizes must be large enough to copy all of the required files from the /usr and /opt directories of the host platform server.

Increase the WPAR.size.usr or WPAR.size.opt values in the virtual server template to be equal to or greater than the number specified in the error message.
1105
The number in the error message, for example, 2288096 blocks, is displayed in 512KB blocks. When you set the WPAR.size values, convert the size to megabytes (MB). Tip: To calculate the minimum size required, divide the number in the error message by 2048. For example, if the size on the host platform server is 2288096 blocks, use the following calculation:
2,288,096 / 2,048 = 1,117MB
So, the minimum file size required for the dedicated WPAR is 1,117MB.
Discovery logs have warnings for a non-existent host platform server

A successful discovery is run, but the logs have errors about missing ESX servers.
Symptoms
Running a VMware HostPlatform Resource and Virtual Machine Discovery shows error messages in the log that refer to a host platform server that does not exist in the provisioning data model.
Causes
The discovery is working as designed. The provisioning server can discover virtual server names from the VMwareVirtualCenter even when it does not have access to those virtual servers. The discovery looks for the fully qualified domain name (FQDN). If the FQDN matches, it is possible that the name of the host platform server was changed but not all the configuration files were updated.

Verify that the fully qualified domain name of the ESX server matches what is shown in the VMware VirtualCenter when connected directly to the ESX server. If the names are different, see the VMware documentation for changing an ESX server host name http://kb.vmware.com/selfservice/microsites/ search.do?language=en_US&cmd=displayKC&externalId=1010821.
The Virtualization Management application displays very slowly

Create a variable so that the application displays more quickly.
Symptoms
The List tab in Virtualization Management application takes a long time to display.
Causes
If there are many objects, it can take some time for the application to load and display the list of host platform servers and the tree hierarchy view.

Create a variable so that only the list of host platform servers is displayed on the List tab. By default, the tree hierarchy is also displayed. After you create the variable, the tree hierarchy will be hidden so that the Virtualization Management application loads more quickly. To create the variable, follow these steps: 1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. On the Variables tab, click New Row. 3. In the Variable field, type the variable name, show-hostplatform-hierachy. 4. Expand Component and select User defined.
1106
5. In the Value field, type false. 6. Click Save .
To verify that the variable has changed the behavior of the application, navigate to the Virtualization Management application. The List tab should display more quickly and you will see only the list of host platform servers. The Host Platforms Tree View is displayed when you select a host platform server from the list.
Adding MPIO disk resources fails with error

A COPCOM123E error is displayed when users try to add an MPIO SAN hard disk to an LPAR.
Symptoms
The following error occurs when you submit the task to add MPIO hard disks to an LPAR:
COPCOM123E A shell command error occurred: Exit code=1, Error stream="", Output stream="HSCL2970 The IOServer command has The DeviceName parameter cannot exceed 15 characters in length.
Causes
The Adapter Name Schema name is too long. The default name is MySANdisk%vhostnumber%_%lparid%_ %hdnumber%. Users can customize the device name section of the name, MySANdisk. The device name section can be no longer than 15 characters. The remainder of the name is generated when the provisioning task is submitted and the workflow runs.

Shorten the device name section of the Adapter Name Schema and submit the provisioning task again.
Discovery fails because of manually created MAC addresses for VMware

In Tivoli Provisioning Manager, each MAC address must be unique. VMware does not generate a new MAC address when cloning virtual servers or templates for virtual servers that have MAC addresses assigned manually. Therefore Tivoli Provisioning Manager does not support MAC addresses created manually outside of Tivoli Provisioning Manager for VMware virtual servers or templates. If you have a virtual server or template with a manually configured MAC address, any virtual servers or templates that you create are assigned the same MAC address. Therefore, if you run a discovery, the discovery fails to identify the virtual servers or templates with duplicate MAC addresses.
Symptoms
The discovery fails to identify the virtual servers or templates with manually configured MAC addresses.
Causes
Discovery fails to identify virtual servers because they have the same MAC address.

Do not use virtual servers or templates with manually created MAC addresses.
1107
1108
Chapter 11. High availability disaster recovery

This section discusses high availability disaster recovery (HADR), which is a mechanism to ensure the functioning of a computer in the event of specific failures. High availability focuses on local site recovery in the event of hardware or software failures. Disaster recovery focuses on remote site manual restoration mechanisms in the event of massive failure at the local site. Disaster recovery focuses on allowing remote site manual restoration mechanisms in the event of massive failures at the local site. This document will describe an automated high availability solution implemented for Tivoli Provisioning Manager. The solution is based upon Tivoli System Automation for Multiplatforms. Note: Throughout this document, it is assumed the reader has basic knowledge of high availability, disaster recovery, and Tivoli Provisioning Manager principles. The high availability solution is described in the following sections:
High availability disaster recovery basics

Described here is an automated high availability solution implemented for Tivoli Provisioning Manager. The solution is based upon Tivoli System Automation for Multiplatforms. v Key terms v Resources
Key terms
Key terms High availability Pertaining to a clustered system that is re-configured when node or daemon failures occur, so that workloads can be restarted. Disaster recovery The process, policies and procedures of restoring operations critical to the resumption of business. High availability disaster recovery A disaster recovery solution that uses shared storage or replication solutions and provides data to a standby system if a partial or complete site failure occurs on a primary system.
Resources
Resources To learn more about disaster recovery, refer to one of the following resources: v High availability considerations and provisioning architecture on page 1110 v Solution constraints on page 1113 v Solution architecture on page 1116 v Solution installation and configuration on page 1120 v Disaster recovery on page 1127 v Alternative technologies on page 1129
Related links Chapter 11, High availability disaster recovery

1109
High availability considerations and provisioning architecture

This section provides an overview of the general Tivoli Provisioning Manager architecture, and then describes the product components and considerations for their data integrity and failover requirements.
Architecture overview
Review the provisioning architecture diagram in Figure 1. Note, for the solution, the Tivoli Provisioning Manager Common Agent Services, Dynamic Content Delivery, and device manager services are part of the configuration. This group of agents is often referred to as the Tivoli Provisioning Manager scalable distribution infrastructure.
Figure 7. Provisioning architecture
WebSphere Application Server profile 1

Device Manager Service Dynamic Content Delivery
MXServer
Web interface
WebSphere Application Server profile 2
Tivoli Common Agent Services
Tivoli Provisioning Manager engines
Automation task engine
Deployment engine
WSRF
Agent shell
Help
Policy engine
DMS Result server
MXServer
Provisioning database
APDE
MXServer
Tivoli Provisioning Manager web interface

The EAR file that contains the web interface for interacting with Tivoli Provisioning Manager. It contains JSPs, servlets and Java applets.
1110
The web interface status can be found by logging in to the Tivoli Provisioning Manager web interface. In the event of a failure, user operations that are in progress and have not been committed will be broken. Users might need to log in again after the web interface is restarted.
Inventory upload servlet

The inventory upload servlet (also referred to as Data Fan In) allows target computers to communicate the results of tasks that have been run through the device manager. The servlet has two operating modes. The default behavior inserts the message in a database queue to be processed later by the device manager result processor. The other operating mode is to process the results in the servlet and not queue any messages. In the event of a failure, any transactions that are in-progress and that have not been committed will be rolled back by the database. There is sufficient retry logic which will try to send the results again until it has received a confirmation from inventory upload servlet.
Device manager service

The device manager subagent is the job execution component of the scalable distribution infrastructure for Tivoli Provisioning Manager. Target computers continually poll the device manager service server to see if there are any jobs for them to run. When there is a job, the target computer downloads the information for the job, executes it, and reports back to the device manager service when it is done. The device manager service also has a clustering mechanism that can provide service for the target computers even in the event of a failure of one of the machines in the cluster. In the event of a failure, any transactions that are in progress and that have not been committed will be rolled back by the database. The retry logic will continue to attempt to contact the device manager service server based on a specified polling period.
Common Agent Services

Common Agent Services is used by Tivoli Common Agent on the target computers to check-in once a day with any new information. It is also used to update any certificates necessary to ensure secure communication for the Tivoli Provisioning Manager scalable distribution infrastructure. Common Agent Services is not integral to the majority of jobs performed by Tivoli Provisioning Manager. If there is a failure, any transactions that are in progress and that have not been committed will be rolled back by the database. Any scalable distribution infrastructure jobs in progress will not be affected by the downtime of the Common Agent Services server.
Dynamic Content Delivery

Dynamic Content Delivery is the primary mechanism for the distribution and sharing of content such as software patches and applications. It offers a tiered grid model which provides an efficient peering system for faster file distribution. The Dynamic Content Delivery component shown in Figure 1 is commonly known as the Dynamic Content Delivery Manager. The manager provides download plans to target computers. The download plans consist of depots which contain the file and a peer list that can be restricted by zones and regions. This is typically done when a set of targets are connected to the data model by a slow network connection.
Chapter 11. Configuring disaster recovery
1111
The depot shown in Figure 1 is also part of Dynamic Content Delivery. The depot is a computer that acts as a distribution point or a seed peer. The file distribution performed by Tivoli Provisioning Manager in conjunction with Dynamic Content Delivery is a two stage distribution. In the first stage, the file is published to the depots that will be involved in the distribution. In the second stage, the targets will download the file from the depots specified in the download plan and share the file with its peers. In the event of a failure of the Dynamic Content Delivery Manager, targets will not be able to get a download plan. This will prevent targets that are not already downloading the file from starting the download. Any in-progress transactions that are not committed will be rolled back by the database. Dynamic Content Delivery Manager works with WebSphere Application Server clustering to provide a scaling solution with high availability. In the event of the failure of a Dynamic Content Delivery depot, the file distribution will not be able to continue unless another depot or peer has a complete version of the file. To mitigate this risk publishing to two or more depots is recommended to maintain a high availability state for file distributions. In order to use multiple depots and ensure that file distributions are successful if there are depot failures, the distribution process must involve first publishing the file and then distributing the file to all depots. In order to enforce this two step process, the CDS_DynamicPublishEnable setting must be deselected. When this setting is not enabled, all files must be published before distribution.
Help
The help component is a prepackaged Web server which provides help documents to the Tivoli Provisioning Manager web interface The content of the help component is static and it does not process any information. In the event of a failure, restart the help. Help is also accessible through the information center which is published on the IBM Web site. The help component is considered non-critical. If it is unavailable, the Tivoli Provisioning Manager information center can be used.
Deployment engine
The deployment engine is a virtual server that is designed to run provisioning workflows. Provisioning workflows are used for specific automation tasks which cannot be done through the scalable distribution infrastructure. Provisioning workflows can also operate on target computers that do not have Tivoli Common Agent installed on them. An instance of a provisioning workflow being run against a target computer is called a deployment request. In the event of a failure, any current deployment requests will fail. This can leave the target computer in an unknown state; the deployment engine operations are not truly transaction safe. A script must be run to clean up the deployment requests that were in progress when the deployment engine failed. The script will mark the deployment requests as abandoned. When the deployment engine is restarted it will process the next set of deployment requests that are queued in the database. For more detailed information about the script, see the clean-up-deployment-requests command documentation.
WSRF engine
The WSRF/SOAP engine is the Tivoli Provisioning Manager equivalent of a command line tool. It provides interfaces for a set of operations that can also be done through the web interface In the event of a failure, any requests that are in progress but are not committed will be rolled back by the database.
1112
Automation task engine

The automation task engine, or activity plan engine, is responsible for scheduling tasks, deployment requests, and activity plans. An activity plan is a collection of tasks which depend on each other. In the event of a failure, all transactions that are in progress and that are not committed will be rolled back by the database. When the activity plan engine is restarted, it will continue with the next activity in the queue ensuring that all past due activities are processed.
Agent shell server

The agent shell server provides a telnet to bash function for the deployment engine when it is attempting to run scriptlets on target computers that are managed with Tivoli Common Agent. The agent shell server is not used for any scalable distribution infrastructure tasks. In the event of a failure, the connections will be broken and targets can be left in an inconsistent state. When the agent shell server is restarted, deployment requests must be run again.
DMS result server

The device manager service result server is a backend engine which processes the queue that the inventory upload servlet inserts into. The device manager service result server is used mainly for inventory discovery where XML files containing the current information of the target computer will be sent back to the inventory upload servlet. This is the same function that is provided when the inventory upload servlet is operating in a queue-less mode. In the event of a failure, any transactions that are in progress and that are not committed will be rolled back by the database. Because the requests are polled from a queue upon restart of the device manager service result server, it will pick up with the rolled back requests and continue processing the queue.
MX server
The MX server is the Tivoli Process Automation engine. The MX server is required in all of the Java virtual servers in order to access the database.
Solution constraints
The high availability disaster recovery (HADR) solution has a number of basic constraints that are described in this section.
Tivoli System Automation for Multiplatforms version

The automatic failover technology (often called a high availability cluster) is based upon the Tivoli System Automation for Multiplatforms product. For the described solution, the required version of Tivoli System Automation for Multiplatforms is 2.3 (PTF 2 or later is recommended). Expectations are the solution is supported for this version and later versions of Tivoli System Automation for Multiplatforms.
1113
Operating system support

Supported operating systems for automatic failover are defined as the set intersection of Tivoli Provisioning Manager supported platforms and Tivoli System Automation for Multiplatforms supported platforms.
High availability: application versusTivoli Provisioning Manager

Tivoli Provisioning Manager is a provisioning product that provides enterprise management solutions. Within this context, high availability is often interpreted as the ability of the provisioning manager to determine if applications are no longer available and the ability to manage them appropriately. Only the availability of specific Tivoli Provisioning Manager server components must be considered.
Tivoli Provisioning Manager server topology

For the described solution, the components for a single provisioning server instance are split across two servers. The two servers consist of a core Tivoli Provisioning Manager server and a dedicated database management system (DBMS) server. The LDAP server needs to be highly available as part of an enterprise LDAP solution.
Primary and secondary site considerations

The HADR implementation consists of a primary Tivoli Provisioning Manager server implementation along with a secondary, standby. By having a primary and a standby, we ensure that there will be no single point of failure. For the solution, thprimaryry and the secondary must be at the same site. A site is a geographic area where basic requirements for network configuration and shared storage are met.
Multiple data model considerations

The automated high availability solution is generally restricted to items in the data model. For example, the Dynamic Content Delivery depots can exist in branch offices and redundancy approaches are recommended to manage availability outside of the data model.
Shared storage
Shared storage is available between the primary and secondary, and is considered necessary for the described solution. With additional effort, it is possible to implement a similar solution based on replication technology. Shared storage is not an option for failover across sites, primarily because of the site definition and associated geographical constraints and the need for redundancy in the event of a total site failure.
Service IP addresses
A service IP address, also referred to as a virtual host name, is a TCP/IP host name and associated address that specify a specific computer but are not bound to a physical network card on that computer. Service IP addresses will be used in order to provide a layer of abstraction for transparent management of the failover from the primary and secondary. Note for a service IP address, uniqueness is required in the enterprise. For example, when a system at the primary site goes down, it is possible to reuse the same IP address at the secondary site. The DNS server and associated caches must be aware of the change, and each IP address must be unique on the network at any point in time. Figures 1, 2, and 3 provide a conceptual overview of the service IP address. Note the existence of physical addresses bound to each server with the service IP address capable of being associated with another computer upon failover. Any computer dependent on a service IP address (for example a Tivoli
1114
Provisioning Manager Dynamic Content Delivery depot or target computer) typically needs its associated Address Resolution Protocol cache to expire in order to properly resolve the service IP address upon failover.
Figure 8. Service IP address support (before): Switch
Router
- Service hostname - Service IP
DBMS server
Primary provisioning server
Secondary provisioning server
Managed target
- Primary hostname - Primary IP - Primary MAC
- Secondary hostname - Secondary IP - Secondary MAC
Figure 9. Service IP address support (failure): Switch
Router
DBMS server
Managed target
1115
Figure 10. Service IP address support (recovery): Switch
Router
- Service hostname - Service IP
DBMS server
Managed target
Database technology
The solution is dependent on shared storage for the DBMS containers. Therefore, the solution is supported for both DB2 and Oracle database management systems in shared storage configurations . Note the shared storage technology used must be endorsed by the database vendor as a suitable technology for storing DBMS containers. Using shared storage technology not endorsed by the database vendor has the potential to introduce database consistency or corruption issues. Replication based solutions for the DBMS typically require DBMS level support.
LDAP technology
Any Tivoli Provisioning Manager supported LDAP solution is supported. Given the customer can use an existing LDAP implementation, the LDAP implementation outside of the core HADR proposal is generally considered. Note: Tivoli System Automation for Multiplatforms provides a preplanned policy, a predefined high availability solution for LDAP.
Solution architecture
This section describes the general high availability solution. The recommended solution will meet the following criteria. v The solution will focus on failover within a single site. v The solution will use a service IP address. The service IP address will be used to permit a consistent server identity when failing over from the primary to the secondary. v Shared storage will be used to provide data integrity upon failover. This typically implies network storage (for example NFS, SAN) based upon RAID technology (for example RAID 1+0). Once again, it is important to ensure that network storage solutions are recognized as being supported by the appropriate database vendor.
1116
v The automation of the provisioning server is done by Tivoli System Automation for Multiplatforms (TSA MP). This includes starting and stopping the provisioning server environment. Furthermore Tivoli System Automation for Multiplatforms will automatically recover Tivoli Provisioning Manager after a failure (hardware or software) and restart failed components in place or failover instances to a backup server. The solution will be described in terms of the server architecture and TSA MP integration within this architecture.
Solution architecture
The solution architecture consists of a two server topology with shared storage. 1. The provisioning server (including the Tivoli Provisioning Manager engine, Common Agent Services, Dynamic Content Delivery, device manager service, and inventory upload servlet components). 2. The database server. Having a distinct database server is the recommended approach when using commodity hardware because it has the potential to dedicate more resources to the database. In addition, a 64bit database computer can be run which also has advantages. For the multi-node server case, it is also recommended to have a dedicated high bandwidth connection (1Gbps Ethernet or better) between the primary provisioning server and database servers.
1117
Tivoli System Automation for Multiplatforms
Failover
Monitor
Monitor
Monitor
Failover
Failover
LDAP
Shared storage
LDAP
Server layer Primary Secondary
DBMS
DBMS
Provisioning server
Provisioning server
Distribution layer
Depot 1
Depot 2
Target layer
Target 1
Target 2
Target 2
Figure 11. Solution architecture
Dynamic Content Delivery depots are not considered in the Tivoli System Automation for Multiplatforms high availability setup. The general high availability requirement is to have multiple depots and to ensure you publish to them to ensure redundancy. If one depot fails, the other depots can continue service and the failing depot can be restarted. For using multiple depots to ensure that file distributions are successful if there are depot failures, the high availability best practise is to have a two step process: publish the file to all depots and then distribute the file to all depots. In order to enforce this two step process, the CDS_DynamicPublishEnable setting must be deselected. When this setting is not enabled, all files must be published before distribution. To disable the CDS_DynamicPublishEnable setting:
1118
1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Variables tab and find the CDS_DynamicPublishEnable variable. 3. Expand the variable. Ensure that the Component value is Entire System. Type false in the Value field. Note: If the variable is not in the list, click New Row and add the variable. Set the Component and Value fields. 4. Click Save .
Note: In the solution, for every computer a set of n standby servers are provided for failover. Tivoli System Automation for Multiplatforms permits the designation of a set of servers for failover that can be shared by a number of applications. You do not need a strict one to one mapping of standby servers for failover. For example, three application servers can failover to a single standby. This approach offers a cost-effective way of managing high availability.
Tivoli System Automation for Multiplatforms integration

The Tivoli System Automation is used for automation, service IP address management, and system volume management. Tivoli System Automation for Multiplatforms will be used for the following functions: v Automation (monitoring/start/stop) of all components of the provisioning server. v Automation (monitoring/start/stop) of the DBMS server using Tivoli System Automation for Multiplatforms predefined policy. v Optional. Automation (monitoring/start/stop) of the LDAP server using Tivoli System Automation for Multiplatforms predefined policy. Note: The LDAP server must be highly available on its own, independent of Tivoli Provisioning Manager. Tivoli System Automation has its own predefined LDAP policy. v Service IP address management. v System volume management (subject to customer implementation requirements). This is provided by the StorageRM resources that have been designed to manage file systems, volume groups, and logical volumes. It is recommended that at a minimum Tivoli System Automation for Multiplatforms 2.3 PTF 2 be used for full StorageRM function.
Tiebreaker support
An important aspect of the Tivoli System Automation for Multiplatforms implementation is tiebreaker support. In the case of a node or network failure, the tiebreaker is required to determine one node in the cluster as leader to continue. The other nodes are not allowed to continue on their own. The tiebreaker ensures integrity by preventing the scenario where, in the event of a failure, both the primary and secondary are available at the same time (potentially causing odd behavior or corruption). The integrity of tiebreaker support is tied to the Tivoli System Automation for Multiplatforms version and associated infrastructure. For example, in version 2.3, the disk tiebreaker is limited to SCSI-2 locking for shared disks. For the network tiebreaker, the ability for a node to ping the network gateway is typically used. This requires the IP address of both nodes and the gateway to be in the same physical subnet to avoid the situation where both can reach the gateway but not each other. For more details on Tivoli System Automation for Multiplatforms implementation options and tiebreaker support, consult the reference Tivoli System Automation for Multiplatforms documentation.
1119
Solution installation and configuration

This section describes recommended installations steps, including Tivoli System Automation configuration recommendations and enabling HADR support for Provisioning Manager for OS Deployment. Note: Most of the examples will use UNIX terminology. All concepts must be directly transferable to Windows. In addition, for the purpose of our examples, two computers are used to manage the Tivoli Provisioning Manager primary and secondary servers. v bc1ha9: The Tivoli Provisioning Manager primary server. v bc1ha6: The Tivoli Provisioning Manager secondary server.
Tivoli Provisioning Manager server primary installation

The service IP address for the provisioning server must be configured for a successful installation. The following steps must be observed to manage the manual configuration of a service IP address for the provisioning server. Failing to follow these steps can lead to a non-functional Tivoli Provisioning Manager installation. To configure the service IP address, perform the following steps: 1. Select a mount point for shared storage. For example, use the mount point /opt/IBM. The following directories must be on shared storage: a. $TIO_HOME b. $TIO_LOGS c. tioadmin home d. Agent Manager home 2. Associate the required service IP address with the physical network interface card on the computer destined for the provisioning server installation. 3. Install Tivoli Provisioning Manager specifying the required service IP address as part of the Tivoli Provisioning Manager installation. All the components excluding the database management system (DBMS) clients and tivGUID must be installed to the shared storage. 4. When the installation is complete, virtualize the service IP address by using an alternate address for the physical network interface card while still associating the virtual IP address with the provisioning server. 5. In the command $TIO_HOME/help/help_start.sh, replace -host <hostname> with -host 0.0.0.0 6. In the command $TIO_HOME/help/help_end.sh, add -host 0.0.0.0 . For example:
$JAVA_HOME/bin/java \ -classpath $TIO_HOME/help/plugins/org.eclipse.help.base_3.1.0/helpbase.jar \ org.eclipse.help.standalone.Help \ -eclipsehome $TIO_HOME/help \ -command shutdown \ -host 0.0.0.0
7. Disable the Tivoli Provisioning Manager for OS Deployment automatic startup by running disable-autostart.sh. You can find the script in the following locations: v v
Windows Linux
%TIO_HOME\repository\tpmfosd\windows\disable-autostart.vbs
UNIX
$TIO_HOME/repository/tpmfosd/linux/disable-autostart.sh
Tivoli Provisioning Manager server secondary installation

During the secondary installation, the user and group creation, TivGUID installation, and database management system (DBMS) client installation are performed.
1120
Note: The following installation instructions are for UNIX systems only. On Windows systems, imaging is recommended. The following steps must be observed when installing Tivoli Provisioning Manager on the secondary: 1. User and group creation. 2. TivGUID installation 3. DBMS client installation
User and group creation

1. Ensure the shared storage used for the Tivoli Provisioning Manager installation is cross mounted to the secondary. 2. Create the tivoli and tioadmin groups. Make sure both group IDs match the group IDs from the primary provisioning server. 3. Create the tioadmin user. a. The tioadmin home directory must be available on shared storage and configured as part of installation on the primary. b. Ensure the tioadmin user ID matches the tioadmin user on the primary provisioning server. c. Add the tioadmin user to the following groups: 1) tioadmin (primary group). 2) tivoli (tivoli common log group). 3) db admin group ( either the DB2 or Oracle Database administrative group).
TivGUID installation
A GUID is a Globally Unique Identifier used for uniqueness in cross-system applications. TivGUID is an implementation of such a unique identifier used by Tivoli Provisioning Manager, and is essential to the correct operation of Tivoli Provisioning Manager. 1. Ensure that the TivGUID installation directory on the secondary computer matches the TivGUID home folder from the primary provisioning server server. For example /opt/tivoli/guid. 2. After the TivGUID installation, perform the following operations to set up both primary and secondary Tivoli Provisioning Manager computers with the same GUID: a. On the primary provisioning server, retrieve the value of the current GUID.
bc1ha9:/opt/tivoli/guid # ./tivguid Show Tivoli GUID utility - Version 1, Release 3, Level 0. (C) Copyright IBM Corporation 2002, 2004 All Rights Reserved. Guid:0b.0b.34.6c.4d.0f.11.dc.ac.03.00.09.6b.00.c5.11
b. On the secondary provisioning server, set up the same GUID value as the primary.
bc1ha6:/opt/tivoli/guid # ./tivguid -Write -guid=0b.0b.34.6c.4d.0f.11.dc.ac.03.00.09.6b.00.c5.11 Tivoli GUID utility - Version 1, Release 3, Level 0. (C) Copyright IBM Corporation 2002, 2004 All Rights Reserved. Guid:0b.0b.34.6c.4d.0f.11.dc.ac.03.00.09.6b.00.c5.11
DBMS client installation

1. Ensure that the database client installation directory on the secondary server matches the client installation on the primary provisioning server. For example, /opt/oracle/product/9ir2. 2. Ensure that the database aliases match on the primary and secondary Tivoli Provisioning Manager computers.
1121
Tivoli System Automation for Multiplatforms installation and configuration

This topic describes the base installation and configuring the resources in the automation domain and configuring the end-to-end automation adapter. Tivoli System Automation for Multiplatforms installation and configuration consists of three steps: 1. The base installation. 2. Configuring the resources in the automation domain.
The base installation

1. Install the Tivoli System Automation for Multiplatforms base component on all nodes. a. Ensure the environment variable CT_MANAGEMENT_SCOPE=2 is set for all users (for example by updating .profile). b. Ensure the installation directory is not on shared storage. In our case, given /opt/IBM is on shared storage, a local directory /opt/tsamp was created and made a soft link from /opt/IBM/tsamp to /opt/tsamp. For example:
ln -s /opt/IBM/tsamp /opt/tsamp
2. Create the first level automation domain. a. Run the preprpnode command on every node that will be part of the automation domain. For example:
preprpnode bc1ha9 bc1ha6
b. Create the automation domain. For example, a single automation domain can be created (tpm_SA_Domain) comprising of two servers (bc1ha9, bc1ha6). This command must be issued only once on any of the servers that are part of the automation domain. For example:
mkrpdomain tpm_SA_Domain bc1ha9 bc1ha6
Now, any Tivoli System Automation for Multiplatforms or RSCT command can be issued from any node in the automation domain. c. The newly created automation domain has an operational state (OpState) of offline. The operational state must be changed by issuing a startrpdomain command to bring the newly defined automation domain online. For example:
startrpdomain tpm_SA_Domain
Configuring resources in the automation domain

In this stage, define the application, the provisioning server; define the service IP address, for example 9.31.26.12; and inform Tivoli System Automation for Multiplatforms that the network adapters on the relevant nodes (bc1ha6, bc1ha9) are appropriate and equivalent for the service IP address.
Define the service IP resource

1. Create the configuration file, for example, /opt/IBM/tioadmin/tpm.resourcedef.IBM.serviceIP:
PersistentResourceAttributes:: NodeNameList={"bc1ha6", "bc1ha9"} Name="tpm_SIP" NetMask=255.255.255.240 IPAddress=9.31.26.12 ResourceType=1
2. Create the service IP resource by running the following command:

mkrsrc -f /opt/IBM/tioadmin/tpm.resourcedef.IBM.ServiceIP IBM.ServiceIP
3. Verify the resource creation by issuing an lsrsrc command. For example:
1122
bc1ha9:/usr/bin # lsrsrc -l IBM.ServiceIP Resource Persistent Attributes for IBM.ServiceIP resource 1: Name = "tpm_SIP" ResourceType = 0 AggregateResource = "0x2029 0xffff 0x33f1af4a 0x46b43e08 0x90889ef1 0x0582b800" IPAddress = "9.31.26.12" NetMask = "255.255.255.240" ProtectionMode = 1 ActivePeerDomain = "tpm_SA_Domain" NodeNameList = {"bc1ha9.tod.tpmserver.example.com"} resource 2: Name = "tpm_SIP" ResourceType = 0 AggregateResource = "0x2029 0xffff 0x33f1af4a 0x46b43e08 0x90889ef1 0x0582b800" IPAddress = "9.31.26.12" NetMask = "255.255.255.240" ProtectionMode = 1 ActivePeerDomain = "tpm_SA_Domain" NodeNameList = {"bc1ha6.tod.tpmserver.example.com"} resource 3: Name = "tpm_SIP" ResourceType = 1 AggregateResource = "0x3fff 0xffff 0x00000000 0x00000000 0x00000000 0x00000000" IPAddress = "9.31.26.12" NetMask = "255.255.255.240" ProtectionMode = 1 ActivePeerDomain = "tpm_SA_Domain" NodeNameList = {"bc1ha6.tod.tpmserver.example.com", "bc1ha9.tod.tpmserver.example.com"}
Define equivalency for the network adapters

1. When a node in the cluster has multiple network attachments, they all might not be equally suited to host the service IP resource (tpm_SIP). An equivalency definition specifies the network adapters that you can use to carry the tpm_SIP address. The following command creates a static equivalency named tpm_nieq, which contains a network adapter from each node of the cluster:
# mkequ tpm_nieq IBM.NetworkInterface:eth0:bc1ha9,eth0:bc1ha6
2. Verify the equivalency creation using the following command:

bc1ha9:/usr/bin # lsequ -e tpm_nieq Displaying Equivalency information: For Equivalency "tpm_nieq". Equivalency 1: Name = tpm_nieq MemberClass = IBM.NetworkInterface Resource:Node[Membership] = {eth0:bc1ha9.tod.tpmserver.example.com, eth0:bc1ha6.tod.tpmserver.example.com} SelectString = "" SelectFromPolicy = ANY MinimumNecessary = 1 Subscription = {} Color = 0 ActivePeerDomain = tpm_SA_Domain ConfigValidity =
Define the application resource

1. Create the script to start, stop, and monitor the primary and secondary. Note: The script and policy is available in the IBM Integrated Service Management Library. The script might need to be tailored to local standards for volume management and so on.
1123
2. Create the application resource configuration file. For example /opt/IBM/tioadmin/ tpm.resourcedef.IBM.Application. For example:
PersistentResourceAttributes:: Name="tpm" StartCommand="/usr/local/IBM/TSAMP/scripts/tpm.sh start" StopCommand="/usr/local/IBM/TSAMP/scripts/tpm.sh stop" MonitorCommand="/usr/local/IBM/TSAMP/scripts/tpm.sh status" MonitorCommandPeriod=60 MonitorCommandTimeout=60 NodeNameList={"bc1ha6","bc1ha9"} StartCommandTimeout=120 StopCommandTimeout=120 UserName="tioadmin" ResourceType=1
3. Create the application resource. For example:

#mkrsrc -f /opt/IBM/tioadmin/tpm.resourcedef.IBM.Application IBM.Application
4. Verify the resource definition. For example:

bc1ha9:/usr/bin # lsrsrc IBM.Application Resource Persistent Attributes for IBM.Application resource 1: Name = "tpm" ResourceType = 0 AggregateResource = "0x2028 0xffff 0x33f1af4a 0x46b43e08 0x7ca630e8" StartCommand = "/usr/local/IBM/TSAMP/scripts/tpm.sh StopCommand = "/usr/local/IBM/TSAMP/scripts/tpm.sh MonitorCommand = "/usr/local/IBM/TSAMP/scripts/tpm.sh MonitorCommandPeriod = 60 MonitorCommandTimeout = 60 StartCommandTimeout = 120 StopCommandTimeout = 120 UserName = "tioadmin" RunCommandsSync = 1 ProtectionMode = 0 HealthCommand = "" HealthCommandPeriod = 10 HealthCommandTimeout = 5 InstanceName = "" InstanceLocation = "" SetHealthState = 0 MovePrepareCommand = "" MoveCompleteCommand = "" MoveCancelCommand = "" CleanupList = {} ActivePeerDomain = "tpm_SA_Domain" NodeNameList = {"bc1ha9.tod.tpmserver.example.com"} resource 2: Name = "tpm" ResourceType = 0 AggregateResource = "0x2028 0xffff 0x33f1af4a 0x46b43e08 0x7ca630e8" StartCommand = "/usr/local/IBM/TSAMP/scripts/tpm.sh StopCommand = "/usr/local/IBM/TSAMP/scripts/tpm.sh MonitorCommand = "/usr/local/IBM/TSAMP/scripts/tpm.sh MonitorCommandPeriod = 60 MonitorCommandTimeout = 60 StartCommandTimeout = 120 StopCommandTimeout = 120 UserName = "tioadmin" RunCommandsSync = 1 ProtectionMode = 0 HealthCommand = "" HealthCommandPeriod = 10 HealthCommandTimeout = 5 InstanceName = ""
0x9088e07c start" stop" status"
0x9088e07c start" stop" status"
1124
InstanceLocation = "" SetHealthState = 0 MovePrepareCommand = "" MoveCompleteCommand = "" MoveCancelCommand = "" CleanupList = {} ActivePeerDomain = "tpm_SA_Domain" NodeNameList = {"bc1ha6.tod.tpmserver.example.com"} resource 3: Name = "tpm" ResourceType = 1 AggregateResource = "0x3fff 0xffff 0x00000000 0x00000000 0x00000000" StartCommand = "/usr/local/IBM/TSAMP/scripts/tpm.sh StopCommand = "/usr/local/IBM/TSAMP/scripts/tpm.sh MonitorCommand = "/usr/local/IBM/TSAMP/scripts/tpm.sh MonitorCommandPeriod = 60 MonitorCommandTimeout = 60 StartCommandTimeout = 120 StopCommandTimeout = 120 UserName = "tioadmin" RunCommandsSync = 1 ProtectionMode = 0 HealthCommand = "" HealthCommandPeriod = 10 HealthCommandTimeout = 5 InstanceName = "" InstanceLocation = "" SetHealthState = 0 MovePrepareCommand = "" MoveCompleteCommand = "" MoveCancelCommand = "" CleanupList = {} ActivePeerDomain = "tpm_SA_Domain" NodeNameList = {"bc1ha6.tod.tpmserver.example.com", "bc1ha9.tod.tpmserver.example.com"}
0x00000000 start" stop" status"
Define the resource group

1. Create a resource group named tpm_rg and add the service IP and application resources to it with the following commands:
# mkrg tpm_rg # addrgmbr -g tpm_rg IBM.Application:tpm # addrgmbr -g tpm_rg IBM.ServiceIP:tpm_SIP
2. Verify the resource group with the following command:

bc1ha9:/usr/bin # lsrg -m Displaying Member Resource information: Class:Resource:Node[ManagedResource]Mandatory MemberOf OpState WinSource Location IBM.ServiceIP:tpm_SIP True tpm_rg Offline IBM.Application:tpm True tpm_rg Offline
Create the automation policy using relationship definitions

In this configuration step, ensure that the following are complete: v The Tivoli Provisioning Manager application depends on the service IP tpm_SIP to be available. v The service IP tpm_SIP depends on the network interface equivalency tpm_nieq to be v Tivoli Provisioning Manager application depends on DB2 and Tivoli Directory Server resources. The database and LDAP resources and the resource groups are defined in the DB2 and Tivoli Directory Server predefined policies and they must be created before running the following steps.
1125
The recommended steps to achieve this follow. 1. Define the relationship between our service IP resource (tpm_SIP) and the network interface equivalency (tpm_nieq) with the following command:
# mkrel -p DependsOn -S IBM.ServiceIP:tpm_SIP -G IBM.Equivalency:tpm_nieq tpm_SIP_dependson_tpm_nieq
2. Define the relationship between Tivoli Provisioning Manager application (tpm) and the service IP (tpm_SIP) with the following command:
# mkrel -p DependsOn -S IBM.Application:tpm -G IBM.ServiceIP:tpm_SIP tpm_dependson_ip
3. Verify the relationships with the following command:

bc1ha9:/usr/bin # lsrel -l Displaying Managed Relations : Managed Relationship 1: Name Class:Resource:Node[Source] ResourceGroup[Source] Managed Relationship 2: Name Class:Resource:Node[Source] ResourceGroup[Source]
= tpm_SIP_dependson_tpm_nieq = IBM.ServiceIP:tpm_SIP = tpm_rg = tpm_dependson_ip = IBM.Application:tpm = tpm_rg
4. Create the relationship between the Tivoli Provisioning Manager application the database. The LDAP server is optional and is not part of this solution. a. Add database resource group to the Tivoli Provisioning Manager resource group.
# addrgmbr -g tpm_rg IBM.ResourceGroup:db2hadr_maxdb71-rg
b. Create the relationship between provisioning server and database resource.

# mkrel -p DependsOnAny -S IBM.Application:tpm -G IBM.Application:db2hadr_maxdb71-rs tpm_dependson_db # mkrel -p ForcedDownBy -S IBM.Application:tpm -G IBM.Application:db2hadr_maxdb71-rs tpm_forceddownby_db
Change the operational state of the resource group

1. The resource group tpm_rg is now ready to be activated. The following command will modify the operational state of the resource group and all the resources defined as its members.
# chrg -o online tpm_rg
2. The environment is now fully defined and configured. Verify the status of the resource group with the following command:
bc1ha9:/usr/bin # lsrg -g tpm_rg Displaying Resource Group information: For Resource Group "tpm_rg". Resource Group 1: Name = tpm_rg MemberLocation = Collocated Priority = 0 AllowedNode = ALL NominalState = Online ExcludedList = {} Subscription = {} Owner = Description = InfoLink = ActivePeerDomain = tpm_SA_Domain OpState = Online TopGroup = tpm_rg ConfigValidity = TopGroupNominalState = Online
The configuration is now complete.
1126
Enabling the HADR support for Provisioning Manager for OS Deployment

Tivoli Provisioning Manager supports the high availability disaster recovery (HADR) function for the Provisioning Manager for OS Deployment component. To enable HADR for Provisioning Manager for OS Deployment, perform the following steps after installing both Tivoli Provisioning Manager and Provisioning Manager for OS Deployment: 1. Edit the rembo.conf file in the/opt/IBM/tpmfos directory by adding the following line:
Interfaces serviceIP
2. In the config.csv file in the /opt/IBM/tpmfosd_files/global/rad directory, modify the host name into the service host name. 3. Load the rembo.conf file you modified by running the command:
rembo -d -v 4 -c rembo.conf -exit
4. Restart the Provisioning Manager for OS Deployment service.
Disaster recovery
This section provides a detailed description of required steps for disaster recovery. For a disaster recovery approach, a number of objects must be managed for manual recovery and restart upon failover. The required objects break down into the following categories. 1. Tivoli Provisioning Manager operational objects. 2. Tivoli Provisioning Manager maintenance objects. 3. Database objects. A detailed discussion will be given for each category. Note the management of LDAP objects are not described. LDAP solutions typically have their own replication scenarios and the solutions for the specific LDAP implementation must be referenced. Where the objects have been described, a general description of the disaster recovery steps is provided. Tivoli Provisioning Manager operational objects Tivoli Provisioning Manager operational objects involve objects with a relatively high rate of change that can change with the daily operation of Tivoli Provisioning Manager. These objects must be managed by high frequency file system replication or disk mirroring solutions. The following list contains the file system objects that need to be managed between primary and secondary sites: 1. $TIO_HOME/repository This is the local file repository. Note this is the default location and can be specified otherwise at installation. 2. $TIO_HOME/config/tcm.xml 3. $TIO_HOME/xml 4. $CYG_ROOT/home/tioadmin 5. $TIO_LOGS This is optional. It can be helpful to preserve the logs for serviceability when the provisioning server fails. If there are other file repositories created on the provisioning server the root directories of those file repositories must be replicated as well.
1127
Tivoli Provisioning Manager maintenance objects

Tivoli Provisioning Manager maintenance objects involve objects with a relatively slow rate of change that generally change with maintenance operations. Broader snapshot based approaches can be used (for example, backups, management of images using virtualization technology such as VMware). More granular and frequent methods can be used as well. This so-called maintenance replication must be done when there are any significant changes that involve restarting Tivoli Provisioning Manager or making major changes to parts of the provisioning server that are not covered by day-to-day replication. The following list contains the main situations where maintenance replication needs to be performed: 1. A new automation package has been installed. 2. A new driver of the policy engine has been installed. 3. An interim fix has been applied. 4. After the application of a fix pack.
Database objects
Database objects can be managed by supported database replication scenarios (for example, DB2 high availability disaster recovery (HADR) support) or lower level disk mirroring. The solution selected must be approved by the appropriate database vendor (DB2 or Oracle). For the DB2 scenario, some brief notes follow. 1. In general, DB2 high availability disaster recovery is our standard cross-site solution. This includes the default HADR_TIMEOUT interval (120 seconds) and near synchronous mode (which offers a combination of good performance and high availability). 2. The secondary DB2 server must be available for replication to work properly. In the event the secondary goes down, it will resynchronize with the primary after it comes back up.
Recovery steps
The following general recovery steps are considered part of a successful disaster recovery scenario. 1. Suitable provisioning server mirroring/replication/backup mechanisms are in place. 2. Failure occurs on the primary. The primary server entity is shut down. 3. Control is passed to the secondary. This consists of: a. Activation of the replicated objects. b. Preserving the provisioning server IP address wherever possible. c. Startup of Tivoli Provisioning Manager. 4. Remapping of the distribution layer. 5. Remapping of the endpoint layer. Note steps one through three are considered constant time operations. They are essentially independent of the size of the deployment. Steps four and five have the potential to be dependent on the number of distribution layer or endpoint layer objects involved. The preferred implementation needs to be to manage at the IP layer, essentially in constant time, by preserving the IP address of the primary while failing over to the secondary. An installation option is available to indicate whether the Tivoli Provisioning Manager agents must be configured using an explicit IP address or a host name for the provisioning server. In the event the agent is configured with a host name, DNS updates and cache invalidation must be sufficient for the agents to communicate with the new server. This is considered the preferred method of configuring Tivoli
1128
Provisioning Manager for a disaster recovery scenario where the server IP address might change but the host name remains fixed and appropriate DNS support is in place. Note: The server IP change feature is not supported In the case where the IP address is not preserved on failover or the DNS is unavailable, then failover will involve the reestablishment of all distribution and endpoint layer objects (essentially, reregistering and rediscovering all managed objects).
Alternative technologies
This section provides a brief guide to using alternative technologies for failover. High availability solutions typically have many common aspects. Whether the implementation is done using Tivoli System Automation for Multiplatforms, HACMP, Veritas, or Redhat Heartbeat, the general concepts of component monitoring, failover, IP management, and volume management are persistent. The solution described here is based upon service/virtual IP addresses and a script for monitoring, starting, and stopping Tivoli Provisioning Manager. It also uses Tivoli System Automation for Multiplatforms predefined policies for the database server and the LDAP server. Volume management is typically implementation-dependent. Our solution can be adapted to these technologies through some fairly straightforward customization effort. Consider the following areas for customization: v Integration of Tivoli Provisioning Manager heartbeat methods. See the script in the IBM Integrated Service Management Library. v Integration of Tivoli Provisioning Manager failover methods. This script is also available in the Integrated Service Management Library. v Service IP management. v Volume management. v Database server and LDAP server management. Replacements for the predefined policies are provided by Tivoli System Automation for Multiplatforms.
1129
1130
Chapter 12. Managing network resources

You can configure and manage certain network devices in a data center using Tivoli Provisioning Manager. The data model assets include: v Groups of servers or individual computers that can be desktops, servers or notebooks. v Network devices such as switches, routers, load balancers, and firewalls that support communication between computers and applications. v Logical assets such as subnetworks, virtual local area networks (VLANs), and ports. v Access control lists that support secure data transmission. Switches Switches are devices that provide point-to-point inter-connections between ports and can be thought of as a central component of a network. Routers Routers are devices that can route one or more protocols, such as TCP/IP, and bridge all other traffic on the network. Routers also determine the path of network traffic flow. In a Tivoli Provisioning Manager context, when you configure a router, you are enabling router capabilities at the switch level. Load balancers Load balancers divide work between two or more servers in a network. Load balancers are used to ensure that traffic and CPU usage on each server is as well-balanced as possible. You can edit the user-defined variables in a load balancer, as well as set up the network interface and routing configuration or remove it. Firewalls Firewalls are devices that you use to separate a safe internal network from the internet. In a Tivoli Provisioning Manager context, when you configure a firewall, you are enabling firewall capabilities for a router. You can view your assets in the Tivoli Provisioning Manager web interface. The following table lists how to view some of your assets.
Table 203. Viewing assets in the web interface Asset Firewalls Switches Load balancers Routers Blade servers To view in the web interface Click Go To > IT Infrastructure > Provisioning Inventory > Firewalls. Click Go To > IT Infrastructure > Provisioning Inventory > Switches. Click Go To > IT Infrastructure > Provisioning Inventory > Load Balancers. Click Go To > IT Infrastructure > Provisioning Inventory > Routers. Click Go To > IT Infrastructure > Provisioning Inventory > Blade Servers.
1131
Related tasks Subnetworks on page 1138 Trunking negotiation on page 1144 Managing switches
Managing switches
Switches provide a way for all the data model objects to connect to each other. For information to pass in and out of a switch, a logical endpoint known as a port must exist. A switch port allows you to logically connect computers to switches. Related concepts Trunking on page 1140 Chapter 12, Managing network resources, on page 1131
Adding a switch
To add a switch:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Switches. . 2. Click New 3. Type a unique name for the new switch in the Name field. 4. 5. 6. 7. If the device is in a failed state, select the Failed check box. Type the number of ports for the switch in the Port field. Click the Locale list and then select the locale. Click Save.
Results
You have finished adding your new switch. You can add ports to the switch and turn the switch on and off. A switch can be also configured to act as a router. Switches can increase performance and reduce the burden on the existing network infrastructure. A router table can be created and maintained on a router to hold a list of valid paths through which hosts can communicate with other hosts. The routing table can hold static routes and dynamic routes.
Configuring load balancer networking

The networking ability of a load balancer can be configured to provide the advantages of a switch. Configure the Networking tab options to indicate the network ability that the load balancer provides. Adding the networking information to a load balancer combines these advantages: v The integrated layer 2 or layer 3 functionality of a switch. v The high availability of a load balancer, which protects transactions in progress. To configure the network ability of a load balancer:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Load Balancers 2. Click the name of the load balancer. 3. Click the Networking tab.
1132
4. Click the New NIC Resource button. 5. Enter a name for the load balancer's NIC within the NIC field, and the MAC address of the load balancer within the MAC field. 6. Click the Network Interface tab. 7. Click the New Network Interface button. 8. Enter a name for the load balancer's network interface within the Network Interface field, and the IP address of the load balancer within the IP Address field. 9. Click the Save Load Balancer button within the toolbar.
Configuring additional resources for computers

A computer can be configured with additional resources. You can configure various resources for computers, including: BIOS information, hardware platform, keyboard, CPU, pointing device, hard disk, diskette, modem, video device, memory, fibre channel port, disk partition, and user-defined resource. You can also add a different type of resource, by adding it as a generic resource. Each of the resources that fall under the category of Other Resources, have parameters that are specific to the resource type. You can add new resource parameters as required. To add a resource, perform the following steps:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Identify and click the computer that you want to edit. 3. 4. 5. 6. 7. Click the Hardware tab. In the Hardware Resources list click the Other tab. Click New Other Resource. The Resource window is displayed. In the Resource Type list, click the type of resource that you want to add. In the Resource field, type the name of the resource.
8. In the Group field, type the name of the resource group for this resource. This name enables you to refer to multiple resources in the same resource group from workflows. 9. If you want Tivoli Provisioning Manager to have control over the resource, select the Managed. When enabled, the device to which the interface is assigned remains accessible, even after any network configuration changes are made to it. 10. If the resource can be partitioned, select the Partitionable. . 11. Click Save 12. Expand the parameter list for the resource that you created and make any other required changes.
Results
The resource appears in the Other Resource list.
Network interface IP addresses

Devices use the IP address of a network interface to communicate with the managed system or switch associated with the interface. The IP address assigned to the interface is validated against the subnetwork pair (consisting of the network address and netmask). On saving this interface, Tivoli Provisioning Manager performs a logical AND operation on the following: v Binary IP address assigned to the interface.
1133
v Binary subnet mask. If the resulting binary address is equal to the network address assigned to the subnetwork, then the assigned IP address is on the correct subnetwork that has been assigned to it. For example, assume that the subnet pair assigned to an interface had the following information:
Table 204. Example of the subnet pair Component Subnet Mask Subnet Address Decimal Address 255.255.255.240 10.1.1.16 Binary Address 11111111.11111111.11111111.11110000 00001010.00000001.00000001.00010000
A good example of an IP address assigned to the interface is the following, where, the resulting binary address is equal to the network address assigned to the subnetwork.
Table 205. Good example Component Subnet Mask IP Address Decimal Address 255.255.255.240 10.1.1.23 10.1.1.16 Binary Address 11111111.11111111.11111111.11110000 AND 00001010.00000001.00000001.00010111 00001010.00000001.00000001.00010000
A bad example of an IP address assigned to the interface is the following, where, the resulting binary address is not equal to the network address assigned to the subnetwork.
Table 206. Bad example Component Subnet Mask IP Address Decimal Address 255.255.255.240 10.1.1.13 10.1.1.0 Binary Address 11111111.11111111.11111111.11110000 AND 00001010.00000001.00000001.00001101 00001010.00000001.00000001.00000000
Adding network interface cards to computers

The network interface card provides additional networking capabilities to the computer. The purpose of adding a network interface card to the computers is to serve as a physical link to the rest of the network. To add a network interface card to a computer:
Procedure
1. 2. 3. 4. 5. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. Identify and click the computer to which you want to add a NIC. Click the Hardware tab. In the Hardware Resources list click the NIC tab. Click New NIC Resource.
6. In the NIC field, type the name of the new network interface card. 7. In the MAC field, type the media access control (MAC) address of the NIC. 8. In the Group field, type the name of the logical group to which you want to assign the resource. 9. Select the Managed check box if you want to use workflows to configure the network interface card. Workflows use this option to identify which resources they can configure. If this option is enabled, workflows can provision the resource. If this option is disabled, workflows will consider the resource unavailable for provisioning.
1134
10. Select the Management check box, for this resource to be managed by the application. If this option is enabled for a network interface card and an associated network interface for a device, the selected pair determines the main management IP address to use for communication with the device. You can only specify one management network interface card and network interface for a device. 11. Select the Failed check box, only if the device is in a Failed state. 12. Select the Netboot Enabled check box if you want to allow workflows to boot this device remotely. 13. Click Save.
Results
A new network interface card is now added.
What to do next
Next steps: Defining network interfaces for computers
Defining network interfaces for computers

A network interface is required to make a computer accessible in the system. Using the IP address you specify, other devices can address the computer properly.
Before you begin

Prerequisite: For information about forming valid IP addresses, see Network interface IP addresses on page 1133. To configure a network interface for the computer, perform the following steps:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. 2. Click the computer that you want to configure a network interface for. 3. 4. 5. 6. 7. 8. Click the Hardware tab. Expand NIC. Identify and expand the NIC to which you want to add a new interface. Click the Network Interface tab. Click New Network Interface. The Network Interface window is displayed. In the Network Interface field, type a name for the new network interface.
9. Select the Failed check box, only if the device is in a Failed state. 10. Select the Managed check box if you want to use workflows to configure the network interface card. Workflows use this option to identify which resources they can configure. If this option is enabled, workflows can provision the resource. If this option is disabled, workflows will consider the resource unavailable for provisioning. Tivoli Provisioning Manager can perform operations on the device, for example, you might have a private IP address that is not reachable from Tivoli Provisioning Manager, but Tivoli Provisioning Manager might still shut or unshut the interface. 11. Select the Management check box, if you want to use workflows to configure the interface. This interface is used by Tivoli Provisioning Manager to connect to the device. Only one interface can be marked as Management. 12. Select the Is Dynamic check box if the associated network interface has Dynamic IP address capability (DHCP) configured. In the Network Web interface there are two fields showing the management IP of the server. One is directly related to the interface, the other one is located at the top of the page. They must have the same content. When marking the Management Interface as Is Dynamic, Tivoli Provisioning Manager queries the content of the upper management IP box, which is also the content that is displayed by the first summary page of Provisioning Computers.
1135
13. In the IP Address field, type the IP address for the new network interface. 14. From the Subnetwork list select a subnet for the new network interface. 15. Click Save.
Results
The new network interface is now added to the computer.
What to do next
You can remove an existing interface on the Hardware tab of the selected computer. Expand the name of the NIC. Identify the interface to remove and click Mark Row for Delete.
Configuring the routing for a network interface

A computer with multiple NICs can be configured to act as a router. Once configured for routing, can increase performance and reduce the burden on the existing network infrastructure. Using the capabilities of Tivoli Provisioning Manager, a router table can be created and maintained on a router to hold a list of valid paths through which hosts can communicate with other hosts. The routing table can hold static routes and dynamic routes. To configure the routing for a network interface on a router:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. From the list, identify and click the computer for which you want to configure the routing. 2. 3. 4. 5. 6. Click the Hardware tab. Expand NIC, and identify the network interface that requires a new routing configuration. Click the Network Interface tab. Locate the network interface to which you want to add the routing configuration, and expand it. Under Route for, click the Maximize button at the right to expand the section.
7. Click New Route. 8. In the Destination field, choose the IP address of the destination subnet from the list. 9. Type in the IP address of the enabled router that you want to use in the Gateway field, and click Save. 10. Repeat steps 2 to 5 to define more routes for the router. If applicable, instead of defining one route after another, you can select the Apply Routing Table menu option. The Apply Routing Table dialog box is displayed. 11. In the Routing Table list, click the routing table that you want to apply to the router. 12. Select the Remove existing routes check box if you want to remove all the individual routes that have been previously configured for this device, and click Save.
Managing a load balancer

A load balancer provides large scale environments with load balancing and fault tolerance when using multiple servers to manage large numbers of devices. To add a new load balancer:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Load Balancers. The Load Balancer Inventory page displays all the load balancers that are currently available.
1136
2. 3. 4. 5. 6.
Click New . In the Load Balancer field, type a unique name for the new load balancer. From the Type list, select a driver class type for the new load balancer. Select the Failed check box if the device is in a failed state. Select the locale from the Locale list.
7. Click Save.
Results
A new load balancer is now added.
What to do next
A network interface is required to make a load balancer accessible in the system. Using the IP address you specify, other devices can address the load balancer properly. You can also assign virtual IP addresses to a load balancer. You can configure multiple servers with real IP addresses to use the virtual IP address. External requests from the Internet can be directed to the virtual IP address on the load balancer. Depending on the volume of requests received, the requests are routed to the available server. Note: If you want to remove a load balancer later, ensure that the load balancer is not connected to real IP addresses in the data model. An attempt to remove a load balancer related to real IPs will result in an error.
Configuring load balancer switch functionality

Switch functionality in a load balancer provides the advantages that both a switch and a load balancer have.
Before you begin

Add an interface to the switch. Switch functionality in a load balancer provides the advantages that both a switch and a load balancer have. Advantages common to both a switch and a load balancer: v An integrated layer 2 or layer 3 functionality of switches. v The high availability power of a load balancer to protect active transactions in progress. To configure the switch functionality of the load balancer:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Load Balancers. . 2. Click the Switch tab to display the switch configuration for the load balancer.
Configuring the load balancer as a router

A load balancer can be configured to act as a router. A router creates and maintains a table, called a routing table. The table holding a list of valid paths through which hosts can communicate with other hosts. The routing table can hold static routes and dynamic routes. To configure routing for the load balancer:
1137
Procedure
1. 2. 3. 4. Click Go To > IT Infrastructure > Provisioning Inventory > Load Balancers. Select the load balancer name that you want to configure. Select the Networking tab. Select the router check box to enable the load balancer to act as a router.
5. Select the firewall check box to enable the router to act as a firewall. 6. Click Save 7. Add a route to the interface that you want to configure. a. Choose the IP address of the destination subnet from the Destination list and then enter the gateway for the enabled router. b. Click Save. Repeat this step to define more routes for the router. 8. If applicable, instead of defining one route after another, you can click Apply Routing Table. Note: This action will invoke the IPSystem.ApplyRoutingTable logical device operation.
Subnetworks
Networks can be divided into smaller interconnected but independent subgroups, called subnetworks, that are identified by their Internet Protocol (IP) addresses. Also, a range of IP addresses that need to be blocked can be set up as a subnetwork. Addition of a subnetwork to an existing network reduces the network traffic and increases performance and security. You might divide your network into smaller subnetworks for the following reasons: v Any problems encountered in a subnetwork such as network hardware failures and software failures can be limited, and will not impact the entire network. v Makes the network more secure. v Reduces CPU usage. Related concepts Trunking on page 1140 Chapter 12, Managing network resources, on page 1131
Adding blocked IPs for a subnetwork

A range of IP addresses that need to be blocked can be set up for the subnetwork.
Before you begin

To add the blocked IP addresses for a subnetwork:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Subnetworks. In the list, identify and click the subnet that you want to add blocked IPs to. 2. Click the Blocked IP Addresses tab and enter the required information in the fields. 3. Click Save Subnetwork .
1138
Results
The blocked IP addresses are now configured for the subnetwork. You can perform the following actions after configuring a blocked IP address range on a subnetwork: v To edit blocked IPs for a subnetwork, click the Blocked IP Addresses tab and modify the IP Start Range and IP End Range fields. v To remove a blocked IP address range, click .
Note: To remove a smaller range of IP addresses from within a larger range, but to keep the ranges on either side of the change blocked, you need to alter the existing range to match one of the new ranges, then add a new range for the remaining addresses to be blocked.
Adding a new VLAN

Virtual LANs (VLANs) are a logical association of switch ports based upon a set of rules or criteria, such as Medium Access Control (MAC) addresses, protocols, network address, or multicast address. This allows devices in a network to be logically grouped together to form a single domain, without requiring physical rearrangement. VLANs are typically used to better segment and manage the network. A VLAN in a network is useful: v For security and performance related issues. v To limit traffic on the network to a specific VLAN. v To provide firewall protection for the network. To add a new VLAN to the network:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Virtual LANs. 2. Click New VLAN . The VLAN window is displayed. .
3. Complete the fields on the VLAN window and click Save VLAN
Results
You have finished adding your new VLAN. You can perform the following actions with an existing VLAN: v To change the VLAN properties, click on the VLAN you want to work with. Complete the required fields. Click .
. Before removing a VLAN, ensure that it is not related to v To remove a VLAN, click Delete VLAN any other object in the data model. VLANs are used by the entire Tivoli Provisioning Manager system. Removing a VLAN can affect more than one customer application.
Adding VLANs to switches

Switches might be configured to support a single VLAN or multiple VLANs. VLANs are typically used to better segment and manage the network. To add a VLAN to the switch:
1139
Procedure
1. 2. 3. 4. Click Go To > IT Infrastructure > Provisioning Inventory > Switches. Select the switch to which you want to add a VLAN. Go to the VLANs tab. Click New VLAN. The Create VLAN to this Switch window is displayed. To add a new VLAN, enter the required information for a new VLAN and then click Save.
Results
The VLAN is now added to the selected switch.
Trunking
A trunk connection is a link that carries VLAN information between VLAN-aware Layer 2 devices. These devices can be two switches, a switch and a router, or even a switch and an end station. The advantage of the trunk is that through one connection, many VLANs can be transported between the two switches; therefore we do not have to implement a dedicated (and costly) connection for each VLAN. Trunking can dramatically improve the performance, manageability, and reliability for applications. For example, a link is connected between the ports of two switches. If the switch ports defined on the switches are members of the same VLAN, the ports will pass any traffic only for the VLAN associated with their port connections. By default, the ports are in a non- trunk mode called an Access link. If you want the traffic to pass between multiple VLANs established on multiple switches, you will need to first establish a trunk connection between the switch ports. Note: When a VLAN is split and the trunk connection is disabled between the two switches or endpoints, a single VLAN is divided into two new VLANs, one for each of the broadcast domains. All the switches in the domains are updated with the correct VLAN ID, based on which domain it was originally in. The NIC templates however do not get updated with the new VLAN ID information after the trunking is disabled between the switches. You will need to manually update the NIC templates, with information about one of the new VLAN IDs. The main capabilities of trunking are: v Aggregating multiple switches into a single logical trunk group, supports efficient high-speed communications throughout the network. v Network congestion is decreased, by optimizing available switch resources. v Administrative workload is reduced, as the switches or devices connected using the trunk connection can be managed as a single entity rather than individually. v Trunking significantly increases data availability. For example, even if an individual switch failure occurs, the input and output can continue at a reduced bandwidth as long as at least one switch or router in the trunk group remains available. There are two main types of trunks: v Trunk between two switches. v Trunk between a switch and an workstation or a router: For example, in a network topology, a database server belongs to a database-VLAN whereas a Web server belongs to a Web-VLAN. For a client to talk at Level 2 with these two servers (without any routing device), two network interfaces are required, one configured in the database-VLAN, the other in the Web-VLAN. A trunking connection eliminates the need for two interfaces, and requires only one VLAN-aware network interface that will forward traffic from both VLANs. v Trunk between a switch and an endstation or a router: For example, in a network topology, a database server belongs to a database-VLAN whereas a Web server belongs to a Web-VLAN. For a client to talk
1140
at Level 2 with these two servers (without any routing device), two network interfaces are required, one configured in the database-VLAN, the other in the Web-VLAN. A trunking connection eliminates the need for two interfaces, and requires only one VLAN-aware network interface that will forward traffic from both VLANs. Other concepts that you must be aware of include: v Frame tagging: The mechanism used for VLAN identification is frame-tagging. Frame tagging is a way of keeping track of users and frames as they travel through the switch. Using a trunking connection, a VLAN ID is "tagged" to the MAC address of the device. When such a frame reaches the other end of the trunk, the VLAN-aware port (located on a switch that is configured to support VLAN) identifies the VLAN ID and forwards it to the appropriate VLAN. v Native VLAN: The initial VLAN to which a switch port belonged before becoming a trunking port. If the trunking port becomes an access port, in most of the cases, that port will go back to its native VLAN. Traffic coming from the initial VLAN is untagged. To avoid VLAN hopping, do not to use this VLAN for other purposes. v Protocol Endpoint: A communication point from which data can be sent or received. It represents communication points at various levels on an Open Systems Interconnection (OSI) structure. v VLAN Switch Endpoint: A protocol endpoint representing a switch port and its VLAN-specific attributes. v VLAN Endstation Endpoint: A protocol endpoint representing an endstation network port and its VLAN-specific attributes. Related tasks Subnetworks on page 1138 Trunking negotiation on page 1144 Managing switches on page 1132
Trunk encapsulation
Trunk encapsulation specifies the way in which the VLAN IDs are tagged or identified on a trunk and also defines the VLAN services that are available. There are three types of trunking encapsulations: Inter-Switch Link (ISL) Protocol A Cisco systems proprietary trunking protocol. IEEE 802.10 (DOT1Q) A Cisco proprietary method for transporting VLAN information inside standard Fiber Distributed Data Interface (FDDI) frames Negotiate the two ports will negotiate a protocol.
Trunk negotiation
Trunk negotiation is the process of determining whether two devices in a VLAN can be connected using a trunk link. The Dynamic Trunking Protocol (DTP) supports five different trunking modes: Access Forces the port into a permanent non-trunk mode. Trunk Forces the port into a permanent trunk mode and negotiates with the connected device on the other side to convert the link to trunk mode. Auto The port becomes a trunk port if the neighboring port is in a Trunk or Desirable mode. This is the default mode.
Desirable The port attempts to become a trunk port if the neighboring port is in a Trunk , Desirable or Auto mode.
1141
NoNegotiate The port becomes a trunk port but does not use DTP Note: The difference between the Auto and Desirable modes is that the former attribute indicates a static property and the port will not initiate the trunking link, if the neighbor does not initiate it. An auto linked to another auto endpoint cannot become a trunk.
Remote administration
Tivoli Provisioning Manager provides support for some technologies that use out-of-band access to remote devices, providing an alternative path to in-band network management. A network can be managed In-band and Out-band. In-band network locally manages the network. This is one of the most common ways to manage the network. The downside to this type of network management is that if the network is down, you cannot use the same network path to access the affected devices. Using Tivoli Provisioning Manager, you can configure the following assets for remote administration in your enterprise: v Power units and power outlets v Terminal servers v Blade servers
Power units and outlets

A network device can be connected to one or more power outlets, which can be plugged into separate power units. If a network device stops responding to any input or locks up, the simplest way to correct this problem is to power it off and then power it back on. Remote power management provides a way to control the power units and outlets for network devices from a remote location. To configure a power unit using Tivoli Provisioning Manager, you have to specify the power unit outlets and, for each outlet, the managed device that is connected to it. Both power units and power outlets are controlled from the Power Unit Inventory page. The management tasks that can be performed on configured power units and outlets include turning power units on or off, initializing power units, turning outlets on or off, and cycling outlets on power units. Workflows implementing specific logical management operation are initiated for these tasks. A network interface is required to make a power accessible in the system. Using the IP address you specify, other devices can address the power unit properly. If you use a serial interface card for serial connections to a power unit (for terminal communication, for example), you need to define the serial interface card for the power unit. You can then add serial ports to provide additional networking capabilities. You can also specify the routing settings to apply to network interfaces that are added to power units. After you have configured power units, you can initialize power units, cycle power on outlets, and turn outlets on or off. Before proceeding, ensure that the required workflow is assigned to appropriate logical management operation for the power unit.
Action Initializing a power unit Device operation Device.Initialize logical management operation, where Device is the name of the power unit that you want to initialize. Device.PowerOn, where Device is the name of the power unit that you want to turn on.
Turning power units on
1142
Action Turning power units off Turning power outlets on Turning power outlets off Cycling power on a power outlet
Device operation Device.PowerOff, where Device is the name of the power unit that you want to turn off. PowerUnit.TurnOutletON PowerUnit.TurnOutletOFF PowerUnit.CycleOutlet
Terminal servers
Terminal servers are hardware devices that provide network access to other devices (terminals) that have no built-in network support. Terminal servers that connect to managed network devices allow secure and remote out-of-band access to the management ports of enterprise equipment. These terminals connect to the terminal servers through TCP/IP using the RS-232/423 interface. The terminal servers in turn connect the terminals to the network (typically Ethernet) through the network interface cards (NICs). After you add a terminal server, you must add a network interface card to the terminal server is to serve as a physical link to the rest of the network. If you use a serial card for serial connections to a terminal server (for terminal communication, for example), you need to define the serial card for the terminal server. A terminal server with multiple interfaces can be configured act as a router.
Blade servers
Blade servers are systems that are used primarily to reduce space restrictions and redundancy. While blade servers appear no different than regular servers, they are physically located in their parent chassis. They must be created from the Blade Server Chassis Inventory page instead of a server inventory page because servers cannot be reassigned from one chassis to another. Blade servers are configured, for the most part, the same way traditional computers are configured. Adding a blade expands the network infrastructure but decreases deployment costs considerably. Using Tivoli Provisioning Manager, you can configure blade servers for remote administration in your enterprise. Before you can create a blade server, you need to have created a blade server chassis and the computer template that you want to use must be defined. A computer template essentially defines a set of required software that must be installed on a group of managed computers. The template is used to identify non-compliant computers that are missing software or have software that is not listed in the computer template. A network interface is required to make the blade server chassis accessible in the system. Using the IP address you specify, other devices can address the blade server properly.
Rebooting and initializing

In addition to powering devices on and off, you can reboot and initialize devices.
Initializing devices
Initializing devices resets the devices to the starting value. This value is the value before the device was configured. Initializing managed devices can be done by initiating the workflow triggered by the Device.Initialize logical management operation where Device is the name of the device that is being initialized.
1143
Rebooting
A device reboot is typically required when the device has stopped responding and you need to power it off and on again. A software reboot is typically required when the system encounters an error and cannot recover. Hardware reboot The hardware reboot is performed by initiating the workflow that implements the Device.HardwareReboot logical operation, where Device is the name of the device on which you want to perform the hardware reboot. Generic reboot The generic reboot is a combination of software and hardware reboot mechanisms, and is performed by initiating the workflow that implements the Device.Reboot logical management operation where Device is the name of the device on which you want to do a generic reboot. The following steps are taken during a generic reboot: 1. The system verifies whether a reboot_preference data center model property is defined for the device you want to reboot. This data center model property specifies which reboot method to use for that specific device. If none found, an asynchronous software reboot is initiated first. 2. If the asynchronous software reboot fails, a synchronous software reboot is attempted. 3. If the synchronous software reboot is unsuccessful, a hardware reboot is performed. Software reboot The asynchronous software reboot is initiated by the workflow that implements the Device.SoftwareRebootAsync logical management operation, where Device is the name of the computer. The synchronous software reboot is initiated by the workflow that implements the Device.SoftwareRebootSync logical operation, and a confirmation that the rebooted computer is back up and running is required. To perform a device reboot:
Trunking negotiation
Trunk negotiation is the process of determining whether two devices in a VLAN can be connected using a trunk link. The Dynamic Trunking Protocol (DTP) supports five different trunking modes. The trunk mode forces the port on the switch into a permanent trunk mode and negotiates with the connected device on the other side to convert the link to trunk mode. Related concepts Trunking on page 1140 Chapter 12, Managing network resources, on page 1131
Example: Establishing trunking connections between switches

Before you begin
There are two main types of trunks, one of which is between switches. The example below, demonstrates how to establish a trunk connection between two switches.
Procedure
1. Add two new switches named switch_1 and switch_2. Note: Switches provide a way for all the data model objects to connect with each other and pass information. For more information, refer to the section, Managing switches on page 1132. 2. Add ports to the newly created switches. Select Trunk as the trunking mode for both the switches, from the options provided in the drop-down list.
1144
Note: For information to pass in and out of a switch, a logical endpoint known as a port, needs to exist. A port allows you to logically connect two switches or servers to switches. 3. Create new VLANs with the same VLAN number. For more information on creating new VLANs, refer to the section, Adding a new VLAN on page 1139. Note: In this example, although the VLAN number defined for both switches are the same, both the VLANs will have different data model ids . They are essentially two different data model objects in Tivoli Provisioning Manager, with the same VLAN number. 4. Add the VLANs to the switches. 5. To represent the physical connection between the two switches, edit the network interface card properties of the switch. To connect both newly created switches, select switch_1 and edit the following NIC properties of the switch: v Select switch_2 from the switch list. v Enter the port number for the switch as 1. At this point the two switches are physically connected to each other, but the trunking connection is not yet established, since the ports are both in access mode. The VLANs ids have also not merged because the switches are not yet in trunking mode. To establish the trunking connection, complete the tasks below. 6. Edit the ports to the newly created switches: from the options provided in the drop down list, select a Switch Port Mode and Switch Port Encapsulation Type that result in a trunk.
Results
The switches now have trunking established and the VLAN ids of both the switches have merged, because of the trunking. To add a VLAN to a switch in trunking mode (This property is enabled, only if the switches are in trunking mode): 1. Click the Connect Switch Port to another Switch Port icon. Select the switch to which you want to add a VLAN. For example, select switch_1. 2. Click Add VLAN. From the drop-down list, select the VLAN to which this switch is associated to. 3. Click Save. 4. Repeat the same for switch_2. Note: When a VLAN is split and the trunk connection is disabled between the two switches or endpoints, a single VLAN is divided into two new VLANs, one for each of the broadcast domains. All the switches in the domains are updated with the correct VLAN ID, based on which domain it was originally in. The NIC templates, however, do not get updated with the new VLAN ID information after the trunking is disabled between the switches. You will need to manually update the NIC templates, that reference the old VLAN ID, with information about one of the new VLAN IDs.
Managing access control lists

Access control lists (ACLs) are used in routers that act as a firewall, which act as a gateway between the internal network and the Internet. ACLs provide added security to the network. To specify the access rules for a firewall, you first need to add access control lists. Ensure that you add an ACL for each network protocol configured on the router interfaces. An ACL filters the network traffic by controlling the routed packets that pass through the router interface. The router that acts as a firewall help determine what packets can be passed through or dropped through a router, depending on the access rules or the criteria specified. The ACL defines the permissions for the firewall.
1145
Access rules are access criteria specified for the ACLs. These rules help determine what packets can be passed through or dropped through a router. Refer to the links below for information about configuring access rules for an ACL. To add a new access control list:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Access Control Lists. The Inventory ACLs page lists all the currently available ACLs. . 2. Click New 3. Type the name of the new ACL, and then click Save.
Results
You have finished adding your new ACL.
Adding ACL access rules

Access rules are access criteria specified for the ACL on the firewall. A new access rule is added to provide new access criteria for the firewall To add a new access rule:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Access Control Lists. Select the ACL that you want to work with. 2. Click Add Access Rule. 3. Under Target, specify permit or deny as the type of access. 4. Specify the protocol for the access rule in the Protocol field. 5. Select the Source IP address from the drop-down list and specify the corresponding port range. 6. Select the Destination IP address from the drop-down list and specify the corresponding port range.
Results
The access rule is now added to the ACL. Notes: v The mappings for the parent ACL are checked. v The old ACL is deleted from any firewall where it was used. v The new ACL is updated on any previously used firewalls.
Enabling IP or host name addressing for the scalable distribution infrastructure

Before you begin
Note: Making some of the changes described in this topic could have a negative impact on an installation if it is not done correctly. To minimize risk, proceed in conjunction with Tivoli Customer Support. To support IP addresses, ensure the following requirements are met.
1146
v A DNS server or a hosts file must be configured to resolve the host names of managed computers with the common agent. Ensure that IP addresses configured for managed computers resolve to the same fully qualified domain name. v Depots must be configured to support IP communication in the format used by the servers and target computers in your environment. For example: If all computers are configured for IPv4 communication, the depots can be configured for IPv4 only or IPv4 and IPv6 communication. If you have a mix of IPv4 and IPv6 computers, you must configure the depot for IPv4 and IPv6 support. For more information, see IPv6 addressing on page 1148. v If you have migrated or updated Tivoli Provisioning Manager from a previous version, upgrade the common agent before performing any actions that require communication over IP or discovery of IP addresses. For agent upgrade instructions, see Upgrading the common agents on page 667. During Tivoli Provisioning Manager installation, you can choose the method that common agent uses to communicate with the agent manager. v Using the fully qualified domain name v Using an IP address You can verify the current configuration by looking at the value of the global variable SDI.Use.Hostname. A value of true means that communication with host names is configured. A value false means that IP address communication is configured. If you want to use IP addresses that are configured on managed computers, use IP addresses for communication with the common agent. There are two provisioning workflows you can use to change the communication method. One provisioning workflow configures the provisioning server and the other configures managed computers.
Procedure
1. Configure the sdi.conf file as follows: a. Login to Provisioning Manager as tioadmin. b. Browse to the $TIO_HOME/config directory. c. Create a file with name sdi.conf. d. Specify the cell name for the casprofile profile. The cell name is the same as the directory name at "$WAS_HOME/profiles/casprofile/installedApps". e. Save the file. 2. Click Go To > Administration > Provisioning > Provisioning Workflows. a. Search for the SDI_SetHostConfig provisioning workflow. b. From the Select Action menu, click Run Workflow. c. In the IpAddress field, specify the IP address of the provisioning server. d. Click Run. The provisioning workflow configures the provisioning server for communication using the IP address that you specified. Note: If you have a customized installation with scalable distribution infrastructure server components that are not on the provisioning server, manually configure the remote components with the assistance of IBM Global Technology Services. 3. Restart the provisioning server. 4. Configure managed computers. a. Create a provisioning group with all the computers where the common agent is installed. For instructions, see Creating groups on page 39.
1147
b. Create a Provisioning Task definition using the workflow SDI_Agent_SetHostConfig and the target parameter of DeviceID. For instructions see Running a provisioning task on page 1164. Note: If you change from IP address to host name, set the HostName field instead of theIpAddress field.
Results
The provisioning workflow collects the configuration of all scalable distribution infrastructure server components and sends them to managed computers to configure the common agent. The common agent is restarted for the changes to take effect. To check the status of either provisioning workflow that you ran: 1. Click Go To > Task Management > Provisioning Tasks > Provisioning Workflow Status. 2. Search for the provisioning workflow in the list. The scalable distribution infrastructure is now configured to support IP communication with managed computers that have an IP address. After host name communication is configured, the actual IP address used for communication depends on the IP address that is resolved first by the DNS server or hosts file on a managed computer. The scalable distribution infrastructure tries to resolve host names to IP addresses first.
IPv6 addressing
Currently, the dominant IP address format is IPv4. IPv6 is a revised version of the IP address format that offers several benefits over IPv4. An IPv4 address is a 32-bit numeric address written as four numbers separated by periods. For example:
1.160.10.240
An IPv6 address is a 128-bit numeric address. The full format for an IPv6 address is eight numbers separated by colons. For example:
fec0:fff:0000:0000:0000:0000:0000:1
There are alternate ways to abbreviate or represent an IPv6 address. For example an IPv6 address can be abbreviated by collapsing the contiguous fields that contain only zeros. For example, 0009:0000:0000:0000:0000:0008:0007:0006 can be written as 9::8:7:6. IPv6 is designated as the successor to IPv4 by the Internet Engineering Task Force (IETF). Details about the IPv6 addressing standard and the various formats for writing an IPv6 address are described in the IETF document RFC 4291. Key benefits of IPv6 include: More available addresses IPv4 addresses are 32 bits long; IPv6 addresses are 128 bits long. The longer address format means that more unique IP addresses are available, and more individual devices can have a unique IP address directly on the Internet instead of a private IP address within a specific network. Integrated security IPv6 includes encryption, authentication, and data integrity checks. Improved routing An IPv6 network has smaller and more efficient routing tables. The IP addressing structure is hierarchical and the IPv6 header is simplified.
1148
Autoconfiguration IPv6 includes automatic address configuration and renumbering of IP addresses in networks and subnetworks. It also provides discovery of a nearby device or router. Quality of service IPv6 provides a mechanism to prioritize types of information. A device can use the information types to take appropriate action. For example, devices that support IPv6 can prioritize IP audio information so that it arrives at the destination device without significant disruption. Tivoli Provisioning Manager provides a dual stack environment that supports communication using either IPv4 and IPv6 addressing. IPv6 adoption is not yet widespread and many software applications and devices only support IPv4 addressing, including some Tivoli Provisioning Manager software components or software that Tivoli Provisioning Manager interacts with. In addition, a dual stack environment helps organizations to move their network from IPv4 to IPv6 addressing. By default, IPv6 support is not enabled. If you want to use IPv6 support, you must enable it after installation.
IP address format compatibility

The following table shows the IP address format used for communication between Tivoli Provisioning Manager servers and managed computers, based on the configuration of computers in the environment. Communication is affected by: Operating system support The IP addressing support configured in the operating system. Software support The IP addressing support provided by the software installed on the computer.
Table 207. IP addressing compatibility
Server configuration Operating system: IPv4 Managed computer configuration Operating system: IPv4 Software: IPv4 Operating system: IPv4 Software: IPv4 or IPv6 Operating system: IPv4 or IPv6 Software: IPv6 Operating system: IPv4 or IPv6 Software: IPv4 or IPv6 IPv4 IPv4 IPv6 IPv6 No communication No communication IPv6 IPv6 IPv4 IPv4 No communication IPv4 Software: IPv4 IPv4 Operating system: IPv4 Software: IPv4 or IPv6 IPv4 Operating system: IPv4 or IPv6 Software: IPv6 No communication Operating system: IPv4 or IPv6 Software: IPv4 or IPv6 IPv4
IPv6 support in Tivoli Provisioning Manager

Specific scenarios are enabled for IPv6 in Tivoli Provisioning Manager.
IPv6 support
When IPv6 support is enabled, the environment is configured to support both IPv4 and IPv6 addresses.
1149
v If you only want to discover IPv6 addresses, you can enable IPv6 address discovery in Tivoli Provisioning Manager. v If you want to support communication using IPv6 addresses in Tivoli Provisioning Manager, the operating system on the provisioning server must be configured as dual stack to support IPv4 and IPv6 addresses. The management IP address of the provisioning server can be an IPv4 address. The provisioning server can then communicate with: A managed computer that supports IPv4 addresses only. A managed computer that supports IPv6 addresses only. A managed computer that supports both IPv4 and IPv6 addresses. A managed computer with or without the common agent. The following scenarios are supported: Using the scalable distribution infrastructure The scalable distribution infrastructure can support all communication over both IPv4 or IPv6. For the common agent to communicate using IPv6, the following requirements must be met: v The scalable distribution infrastructure must be configured to use host names for communication. v Managed computers must be configured to use DNS or hosts files to resolve host names. v The provisioning server must be configured with a host name that resolves to an IPv4 and IPv6 address. The following scenarios have been tested using the scalable distribution infrastructure: v Inventory discovery v Software distribution and software installation using the scalable distribution infrastructure v Patch management in a large Windows environment Using the deployment engine infrastructure The following scenarios in the deployment engine infrastructure are tested for IPv6 support: v Network discovery using RXA. Network discovery using SNMP does not support IPv6 addresses. v Inventory discovery v Acquiring patches with a WSUS server on page 912 v Installation of the common agent Web services You can use Web services commands to communicate with managed computers with IPv6 addresses. XML import You can use the xmlimport tool to import IPv4 and IPv6 addresses for managed devices.
Limitations
Because IPv6 support is not widespread, there are some limitations to IPv6 communication when IPv6 support is enabled in Tivoli Provisioning Manager. v Windows environments have a dependency on Cygwin to perform network operations such as ssh, ping, telnet, and ftp. Cygwin 1.7 or later is required to support IPv6 addresses. v All communication between server-side components in Tivoli Provisioning Manager uses IPv4 because the middleware installer does not support IPv6 addressing. All server configurations will use IPv4 addresses. v IP-based configuration for the scalable distribution infrastructure uses IPv4 addressing. The scalable distribution infrastructure can be configured using IP addresses or host names. To use IPv6 addressing, host names must be used to manage the common agent on managed computers.
1150
The default setting during installation is host name configuration, but this setting can be changed to IP address configuration either during installation or after installation. The default setting during installation in previous versions of Tivoli Provisioning Manager is IP address configuration. v The IPv4 and IPv6 address configured for the provisioning server must map to the same fully qualified domain name. If a DNS server is not used to resolve the host name, you can use a hosts file to resolve host names. The hosts file must contain both the IPv4 and IPv6 addresses, and both addresses must resolve to the same fully qualified domain name. v High availability and disaster recovery implementations based on a service IP require specific IPv6 support from the cluster manager. The technology used to manage the service IP requires proper management of IPv4 and IPv6 communication. v The following list summarizes main features that do not support IPv6. It is not a complete list of all IPv6 limitations. The policy engine, firewall proxy, router, and ACL management functions Tivoli Provisioning Manager for OS Deployment TADDM discovery and Microsoft Active Directory discovery. For TADDM releases before TADDM v7.2, if resources are discovered IPv6 address information is not imported, even if an IPv6 address is configured for the resources.
Enabling IPv6 in the operating system

If you want computers in your Tivoli Provisioning Manager environment to communicate with IPv6 addresses, the operating system on servers and managed computers must be configured to support IPv6 addressing. You can configure a managed computer to support IPv6 addresses only, or configure it to support both IPv4 and IPv6 addresses. The provisioning server must be configured to support both IPv4 and IPv6 so that it can communicate using both types of IP addresses. The specific steps to enable support for IPv6 depend on the operating system that is installed. Refer to your operating system documentation for details. This section describes specific configuration details that are required for Tivoli Provisioning Manager. The information in this topic refers to the operating systems supported by Tivoli Provisioning Manager.
Enabling IPv6 support on Windows

On WindowsVista the IPv6 protocol is configured and enabled by default. On earlier versions of Windows, you must enable it manually by following the steps in the operating system documentation. The following additional requirements apply to Windows computers that you want to support IPv6 addresses.
Procedure
v Cygwin 1.7 or above is required on the provisioning server. Previous versions of Cygwin do not support IPv6 addresses. v To be able to use the ping.exe utility, create an alias: alias ping=/cygdrive/c/Windows/System32/ PING.EXE . The Cygwin ping.exe utility is not supported with IPv6. By creating the alias, you point to the Windows ping.exe command. v In Windows XP, 2003 and Vista, you can control the precedence IP address formats using the prefix policy netsh command. The following commands are available. Refer to the Windows documentation for more information. Show the local policy
netsh interface ipv6 show prefixpolicy
1151
Add an entry to the table

netsh interface ipv6 add prefixpolicy
Modify an entry to the table

netsh interface ipv6 add prefixpolicy
Remove an entry from the table

netsh interface ipv6 delete prefixpolicy
v On Windows Vista and Windows 2008, privacy addresses are enabled by default. Windows generates random interface IDs for each IPv6 interface and uses them for privacy addresses. To disable privacy extensions
netsh interface ipv6 set global randomizeidentifiers=disabled
To enable privacy extensions

netsh interface ipv6 set global randomizeidentifiers=enabled
Enabling IPv6 support on Linux

On Linux, the IPv6 protocol is configured and enabled by default. If IPv6 is not enabled, refer to your operating system documentation for steps to enable it. The following considerations apply to Linux computers.
Procedure
The vsftp command supports IPv6. On SLES it is not installed by default.
Enabling IPv6 support on AIX

After you have configured IPv6 support in AIX, ensure that the following configuration is also applied:
Procedure
v To configure IPv6 stateless addresses to persist after a reboot: 1. Open /etc/rc.tcpip in a text editor 2. Uncomment and add the -A parameter to the following line:
#start /usr/sbin/autoconf6 ""
This is the same line after the changes:

start /usr/sbin/autoconf6 "" -A
3. Start the ndpd-host daemon. Uncomment the following line in the file:
start /usr/sbin/ndpd-host "$src_running"
v To change SSH to listen on IPv6: 1. Ensure that you are using the latest version of OpenSSH. 2. Open /etc/ssh/sshd_config in a text editor. 3. Uncomment the following lines:
ListenAddress 0.0.0.0 ListenAddress ::
4. Restart sshd with the following commands:

stopsrc -g ssh startsrc -g ssh
Enabling IPv6 for the provisioning server

Tivoli Provisioning Manager supports discovery of IPv6 addresses and communication over IPv6 between the provisioning server and managed computers. You can enable IPv6 support any time after product installation.
1152
Before you begin

There are two levels of IPv6 support that you can configure: Discovery of IPv6 addresses only You can configure the provisioning server to discover IPv6 addresses that are configured on computers in your IT environment. This is useful if you want to add information about IPv6 addresses to Tivoli Provisioning Manager, but you are not yet ready to implement IPv6 communication for actions performed in Tivoli Provisioning Manager. No change is required to the IP configuration of the provisioning server. If you have migrated or updated Tivoli Provisioning Manager from a previous version, you must upgrade the common agent before running discovery if you have target computers with the common agent and configured IPv6 addresses. For agent upgrade instructions, see Upgrading the common agents on page 667. Communication over IPv6 If you want the provisioning server to communicate with managed computers over IPv6, additional steps are required for the provisioning server. v The operating system on the provisioning server must be configured to support both IPv4 and IPv6 addresses so that it can communicate with over IPv4 and IPv6. For information about configuring your operating system to support both IPv4 and IPv6 addresses, refer to your operating system documentation. v If you want to assign an IPv6 management IP to the provisioning server, you must manually configure the IPv6 address in the operating system. The existing IPv4 address for the provisioning server must resolve to the same fully qualified domain name as the IPv6 management IP address.
Procedure
1. To enable IPv6 support on the provisioning server. a. Open the following configuration file in a text editor. v
UNIX
$TIO_HOME/config/system.properties
Windows %TIO_HOME%\config\system.properties v b. In the file, change the value of the ipv6-enabled parameter to true.
c. Save your changes to the file. d. Restart Tivoli Provisioning Manager. 2. To obtain IPv6 addresses for existing managed devices or new devices that have not been discovered, run network discovery. 3. If you have configured an IPv6 management IP for the provisioning server in the operating system, run network discovery against the provisioning server so that the new IPv6 address information is updated in the data model.
Results
IPv6 support is enabled. You can now discover IPv6 address information and perform actions on IPv6 addresses. For features that support IPv6 addressing, the appropriate IPv4 and IPv6 addresses are displayed for devices based on the information stored in the data model.
EUI 64 MAC addresses

Tivoli Provisioning Manager v7.2.0.2 provides support for EUI 64 MAC addresses in an IPv6 network interface. To use EUI 64 MAC addresses in Tivoli Provisioning Manager, you must have an IPv6 network interface configured. You cannot associate an EUI 64 MAC address with an IPv4 network interface.
1153
Specifying an EUI 64 MAC address

To create an EUI 64 MAC address, you must have an IPv6 network interface configured.
Before you begin Procedure

1. 2. 3. 4. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. Click the Hardware tab. Expand the Local Area Connection table to find the IPv6 network interface card. In the NIC Resource tab, specify the EUI 64 MAC address in the MAC field.
5. Click Save.
Managing storage
Although there are many storage architecture models in use today, Tivoli Provisioning Manager supports the two most common: Direct attached storage (DAS) and Storage area networks (SAN). Direct attached storage (DAS) DAS, or direct attached storage device (DASD) as it is more often referred to as, is the most common form of storage in use today. It existed before computing devices were networked together, and has made the transition into the networked environment with its client/server architecture paradigm. In this architecture, storage devices of all types are attached directly to the system through which they are accessed. While its low cost and universal compatibility can make it a good choice, limited performance, lack of robustness, and management difficulties make this a less than optimum solution. Storage area network (SAN) SAN is a dedicated, high-performance network specifically designed so that multiple computers can communicate with multiple storage devices. Typically implemented using a fibre channel network with a hub or switch controlling the data flow, a SAN will out perform a DAS solution. Designed to be reliable and scalable, a SAN can scale independently of the user network, eliminating impact on the corporate network. Highly fault tolerant with simplified, centralized management, SANs also facilitate computer consolidation, allowing any given computer to access any storage device. A fibre channel also has a higher data transfer rate than Ethernet does. Fibre channel switches (FCS) FCS, or fibre channel switches, provide a way for all the data model objects to connect to each other. For information to pass in and out of a switch, a logical endpoint known as a port must exist. A switch port allows you to logically connect computers to switches. Adding a fibre channel switch to a SAN fabric allows you to manage ports for a particular switch. Once a computer or subsystem port is physically connected with a switch port, then the computer or subsystem is connected to the fabric associated with the switch.
SAN optimization
Storage provisioning is the process of assigning storage, typically in the form of server disk drive space, in order to optimize the performance of a storage area network. SAN storage environments are complex and require many skills and a good understanding of the task being performed. Many storage arrays have limitations around the number of hosts per adapter or LUNs per adapter. Additionally, there are accepted rules around SAN zoning of not mixing UNIX and Windows hosts in the same zones. As a consequence, over a number of years, many organizations have developed policies and best practices that have been adopted to avoid misconfiguration of storage subsystems and storage networks. These ensure that environments are configured correctly and avoid problems, but the
1154
occasional human error can still occur. In addition, manual storage provisioning can introduce undesirable delays and corresponding dropoffs in service. The typical storage administrator has many demands on their time and might not be able to immediately respond to an urgent storage provisioning request. Automated storage provisioning addresses these issues by enabling best practices to be implemented using storage workflows. Workflows are reusable elements that capture expert know-how, and represent the steps that must be followed in order to carry out a particular operation. These are repeatable and help reduce the possibility for error, and allow for prompt and reliable execution, as the workflows will consistently implement the rules and policies time after time. Storage provisioning in Tivoli Provisioning Manager includes: v Automated storage provisioning for new computers v Storage reconfiguration for reusing computers v v v v An application-centric policy for configuring storage End-to-end computer deployment with predetermined storage configurations Collaboration of DASD and SAN storage through automation Storage manager function management
Storage devices and templates

In Tivoli Provisioning Manager there are storage devices and storage templates. Storage devices (area networks, subsystems, pools and manager) are collections of storage volumes, and storage templates are reusable sets of storage requirements and configurations. Storage Area Networks (SANs) A storage area network (SAN) is a network of devices that connect host systems to storage devices. SANs are used to support applications storage requirements and growth needs while improving the management and flexibility of storage units. Some typical uses for SANs are storage consolidation and capacity planning. Storage subsystems Storage subsystems are an integrated collection of fibre adapters and storage volumes (such as allocated space on a disk or a single tape cartridge) and can provide storage services to one or more computers. All storage subsystems attached to a SAN can be accessed by all clients (unless you use zoning to allow only specific clients to access specific devices). This enables data sharing among heterogeneous clients. A storage subsystem can include disks, CD-ROMs, tapes, and any required control software that provides storage services to one or more machines. It contains volumes that are either assigned to the hosts or available for assignment. A fibre adapter is like an interface card - it is meant to represent an actual physical interface card on your computer. You can use a fibre adapter (also known as a fibre channel adapter) to connect storage devices to the Storage Area Network (SAN). Once you have added a fibre adapter you need to add a fibre channel port to it. A fibre channel port is the entity on a node or switch within a storage area network that performs data communication and transfer over fibre channel connections. Storage pools A storage pool is an collection of storage volumes. Storage pools are used to group storage volumes (either related or arbitrary) together in order to make them easier to find and maintain. Since a storage pool subsystem cannot itself contain storage items directly, you must add storage volumes to it to contain items. Storage managers A storage manager manages logical volumes and file systems. Storage managers are used to
1155
allocate space on mass storage devices using a method that is more flexible than conventional partitioning schemes. They are made up of volume containers, which are in turn made up of logical and physical volumes. A logical volume is built from physical volumes through disk partitions and is used for file system creation, and a physical volume is composed of one or more disks and presented to the operating system as a single storage device. 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 provisioning workflow operation will take its input values from the currently selected template. You can add empty volume containers to your storage template, and then add logical volume settings (used for file system creation) and physical volume settings (used for storage devices) to it. When the appropriate provisioning workflow runs, volume container settings are used to create volume containers within a storage manager. You can make use of numerous data paths, providing faster and more robust data transfer. Data path settings specify how the data transfer between the computer and the storage volume is managed.
SAN and SAN fabrics

A storage area network (SAN) is a dedicated storage network that connects workstations and computers to storage devices. SAN fabric is a set of interconnected fibre channel switches in a SAN. A storage area network (SAN) is a high-speed special-purpose network (or subnetwork) that interconnects different kinds of data storage devices with associated computers on behalf of a larger network of users. A SAN provides a higher data transfer rate than an Ethernet and is more secure than one. You can add the following items to a SAN fabric: v A fibre channel switch, which enables you to manage ports for a particular switch. Once a computer or subsystem port is physically connected with a switch port, then the computer or subsystem is connected to the fabric associated with the switch. You can then add a fibre channel port to the switch - these ports are connection points for interface cards, and manage simple point-to-point connections between themselves and a fabric. v Zones. Zoning is used as method of access control for a SAN fabric, and in fibre channel environments, zoning can be used to place a barrier between different environments. This keeps ports from communicating with one another.
Fibre channel switches

Adding a fibre channel switch to a SAN fabric allows you to manage ports for a particular switch. Once a computer or subsystem port is physically connected with a switch port, then the computer or subsystem is connected to the fabric associated with the switch. To add a fibre channel switch:
Procedure
1. Click Go To > IT Infrastructure > Provisioning Inventory > Fibre Channel Switches. 2. Fill in the fields as necessary. 3. Click Save.
Results
The fibre channel switch is added to the SAN fabric and listed in the SAN fabric details page. You can now add a fibre channel port to your fibre channel switch. Fibre channel ports are connection points for interface cards.
1156
Chapter 13. Managing provisioning tasks

Tivoli Provisioning Manager automates the manual tasks of provisioning and configuring servers, operating systems, and middleware. With flexible provisioning tasks, your organization can fully automate custom procedures that might require additional configuration changes to network, storage, or virtual server resources. Provisioning tasks include tasks that are generated automatically by applications using wizards, such as discovery or compliance provisioning tasks. These provisioning tasks have specific pages where you can modify their setting definitions. In addition to these provisioning tasks definitions, you can create more general task definitions for workflows, scripts and activity plans using the Provisioning Task Definitions application. To access the Provisioning Tasks features select Go To > Task Management > Provisioning Tasks. This submenu contains three applications: Provisioning Task Definitions You can create a provisioning task definition of the following types: provisioning workflows, scripts, and activity plans. You can share a provisioning task definition with other users and submit the created provisioning task. Provisioning Task Tracking After you submit a provisioning task, you can monitor its progress or you can cancel a provisioning task that has already started. You can also run reports on the submitted provisioning tasks. Provisioning Workflow Status You can see the execution logs of each workflow of a provisioning task and stop its execution. Tivoli Provisioning Manager also helps you to implement IBM Service Management. It gives you a centralized place to run and automate the operational management tasks that are needed to respond to trouble tickets and change requests. By optimizing and automating service management processes, you help maximize business agility.
Task management basics

Find out more about task management, key terms, which users use task management, and which requirements you need to verify before creating the task. Review troubleshooting information and the log file names and locations and also additional resources that help you with managing your tasks. v User roles on page 1158 v Requirements on page 1158 v Key terms on page 1159 v Troubleshooting on page 1159 v Log files on page 1159 v Resources on page 1160
1157
User roles
You must be assigned to the appropriate user role to manage tasks.
Table 208. User roles Role Provisioning Administrator Deployment Specialist Configuration Librarian Description v Create provisioning task definitions v Submit and schedule provisioning tasks Access rights Full access to all task management functions: v Provisioning Task Definitions v Provisioning Task Tracking Full access to the following management functions:
v Track submitted provisioning tasks v Provisioning Workflow Status Compliance Analyst v Submit and schedule provisioning tasks
v Track submitted provisioning tasks v Provisioning Task Tracking v Provisioning Workflow Status
Note: The permissions are checked during the execution of provisioning workflows by the provisioning server. If you do not have the required permissions to run a specific provisioning workflow or you do not have the required permissions to work with specific data of the data model, an error message is displayed.
Requirements
User roles and requirements on page 1160 Before running a provisioning task against one or more computers with parameters that you specify, ensure you set up the following prerequisites for all computers involved by this task: v Service access points v Credentials Before creating a provisioning task which is the type activity plan, ensure you have SUN Java JRE 1.5 as a local plugin for your Web browser. If it is not found, it will be automatically installed. Before running a provisioning task which is the type activity plan against one or more computers, ensure that the related activity plan was not saved as a draft.
1158
Key terms
provisioning task An action that runs a deployment job on one or more target computers. A deployment job can include one or more job items that correspond to provisioning workflows. provisioning workflow A program that is used to manage an environment. The program consists of a sequential series of steps that are performed to accomplish a particular provisioning task. activity plan A group of activities where the execution can be scheduled, submitted, and monitored. script role A series of commands, combined in a file, that carry out a particular function when the file is run. Scripts are interpreted while they are run. A set of job responsibilities related to a service management process. Each role is implemented as a security group, which gives users with that role access to a set of applications and a start center with role-appropriate information.
Troubleshooting
v Troubleshooting task management on page 1180 v Task management messages v Support information about task management v Contacting Support
Log files
The following log files contain information for task management.
Table 209. Log file locations Log file Deployment engine logs Log description Contains diagnostic information for the deployment engine. Contains diagnostic information about the scalable distribution infrastructure jobs that are running on the target computer. Location
Windows UNIX
Linux
Target computer logs
Windows UNIX
%TCA_HOME%\logs\trace-log-0.xml
Linux
$TCA_HOME/logs/trace-
log-0.xml
Provisioning workflow logs
Contains the history of Viewing provisioning workflow logs provisioning workflows recorded in the provisioning workflow logs.
1159
Resources
To learn more about task management, refer to one of the following resources: v Provisioning tasks: provisioning workflows, scripts, and activity plans on page 1161 v Submitting and tracking provisioning tasks on page 1164 v Chapter 13, Managing provisioning tasks, on page 1157 v Retrieving provisioning task information on page 1173 v For a description of a field in the web interface, press Alt+F1.
Related links Chapter 13, Managing provisioning tasks, on page 1157 Requirements Troubleshooting task management on page 1180
Requirements
Before you start working with tasks, ensure that your system meets all of the requirements for tasks. For example, ensure that service access points and credentials are set up correctly for the provisioning tasks.

All provisioning roles can perform task management.
Table 210. User roles Role Provisioning Administrator Deployment Specialist Configuration Librarian Description v Create provisioning task definitions v Submit and schedule provisioning tasks Access rights Full access to all task management functions: v Provisioning Task Definitions v Provisioning Task Tracking Full access to the following management functions:
v Track submitted provisioning tasks v Provisioning Workflow Status Compliance Analyst v Submit and schedule provisioning tasks
v Track submitted provisioning tasks v Provisioning Task Tracking v Provisioning Workflow Status
Note: The permissions are checked during the execution of provisioning workflows by the provisioning server. If you do not have the required permissions to run a specific provisioning workflow or you do not have the required permissions to work with specific data of the data model, an error message is displayed.
Task management requirements

Before running a provisioning task against one or more computers with parameters that you specify, ensure you set up the following prerequisites for all computers involved by this task: v Service access points v Credentials Before creating a provisioning task which is the type activity plan, ensure you have SUN Java JRE 1.5 as a local plugin for your Web browser. If it is not found, it will be automatically installed. Before running a provisioning task which is the type activity plan against one or more computers, ensure that the related activity plan was not saved as a draft.
1160
Managing provisioning task definitions

You can create and submit provisioning tasks definitions to automate specific provisioning actions using the Provisioning Task Definitions application. If you run a workflow, a script or an activity plan regularly, you can create a provisioning task definition for it. You can then run it against one or more computers either once or at regular intervals. Provisioning task definitions are useful for operations that you want to perform regularly, such as collecting log files from managed computers. A script task can be used for scripts (bash, ksh, sh, or Perl) or for program files. When you run a provisioning task, you specify the parameters that you want to use and the computers that are targets of the task. You can request to be notified when a provisioning task begins, completes successfully, or ends with errors.
Provisioning tasks: provisioning workflows, scripts, and activity plans

You can define different types of provisioning tasks, depending on the action you want to perform with this task. These are the main differences among the three types of provisioning task: provisioning workflow It consists of a series of instructions that are sequentially run to accomplish a particular provisioning task. These instructions are expressed in a script-like language and can call logical management operations (LMOs) and other workflows. Parameters can be passed to workflows at run time and parameters can be looked up by the workflow when it is running allowing for modular and reusable workflows. An instruction is called a transition. Each workflow has a single compensating workflow that is run if any transition fails. Some workflows are available with the product and you can run them when you want to perform an operation on several different computers in their environment. script It is a type of provisioning task that allows you to run a script or program file on a computer. Because scripts and program files are operation system dependent, this type is used for specific computers having a specific operating system.
activity plan It consists of a group of activities that can have dependencies associated to them. These dependencies define the circumstances under which the activity is performed. The operation defined in the activity is performed by the application to which the operation belongs. When you submit tasks based on activity plans, you typically specify if you want to install, distribute, or uninstall a software product and on which target computers in your environment this task is performed.
Creating provisioning task definitions

You can create provisioning task definitions to automate specific provisioning actions by using the Provisioning Task Definitions application. A provisioning task can be based on scripts, provisioning workflows, or activity plans depending on what you want to do. To create a provisioning task definition, perform the following steps:
1161
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. 2. Click New . 3. Type the provisioning task name. 4. If you want to create a provisioning workflow task: v Select the Provisioning Workflow option. v Specify the name of an available provisioning workflow or your own provisioning workflow name. Specify the target parameter. When you run the workflow, the parameter value will be set by the target computers. The Workflow Parameters indicate the default values for the remaining provisioning workflow parameters. You can override them when running the provisioning workflow task. 5. If you want to create a script task: v Select the Script option. v v Specify the Timeout by which the script must be completed. The timeout interval begins when the task execution actually starts on the target computer and not at the task submission time. v Click New Command Option to specify the parameters with which to run the provisioning task. v Click Add Associated file to associate the script file to run on the provisioning task. Specify the necessary information, such as file repository, file path, processing command, operating system, and script file to run. 6. If you want to create an activity plan task: v Select the Activity Plan option v Specify Draft if you want to submit the activity plan later or Template if you want to run it as it is. v Define the activity plan as decribed in Creating an activity plan from the web interface 7. Click Save .
Results
The provisioning task is created and ready to be run.
Setting a concurrency level for provisioning tasks

You can define a concurrency level for all the available provisioning tasks. The concurrency level determines the maximum number of concurrent jobs that are permitted within a task. You can adjust the concurrency level to optimize deployments in your environment. You can set a concurrency level for all provisioning tasks, a specific provisioning task, or for a scheduled provisioning task. provisioning tasks. The concurrency level determines the maximum number of concurrent jobs that are permitted within a task. You can adjust the concurrency level to optimize deployments in your environment.
Before you begin

The upper limit for the default concurrency level is 1024, which represents the maximum number of concurrent activities supported within a provisioning task. To set a default concurrency level for all provisioning tasks, perform the following steps:
Procedure
1. Click Go To > Administration > Provisioning > Provisioning Global Settings.. 2. Click the Variables tab. 3. Locate the default concurrency level and change its value.
1162
Results
You have defined a default concurrency level for all the available provisioning tasks.
Setting a concurrency level for specific provisioning tasks

To set a concurrency level for a specific provisioning task instance, before the provisioning task is run, perform the following steps:
Procedure
1. 2. 3. 4. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. Locate and click the provisioning task that you want to run. From the Select Action menu, click Run Provisioning Task. In the Provisioning Workflows section of the dialog, specify a value in the Concurrency Level field.
5. After specifying the remainder of the information in the dialog, click Submit.
Results
You have defined a concurrency level for a specific provisioning task.
Setting a concurrency level for scheduled provisioning tasks

To set a concurrency level for a scheduled provisioning task instance, before the provisioning task is run, perform the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. 2. Locate and click the scheduled provisioning task for which you want to modify the concurrency level. 3. From the Select Action menu, click Change Concurrency Level. 4. In the Set Concurrency Level dialog, specify a value in the Concurrency Level field. 5. Click OK.
Results
You have defined a concurrency level for a provisioning task that is still in scheduled state.
Sharing provisioning task definitions

You can share provisioning task definitions that you created to make them available to modify or to run by other users. When you create a provisioning task definition, it is only available to you. If you want to make it available to other users, you can share it by performing the following steps:
Procedure
1. 2. 3. 4. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. In the list of provisioning tasks, find the provisioning task that you want to share and click it. From the Select Action menu, click Share Provisioning Task. Click New User. .
5. Type a user name or select a user name by clicking 6. Click Save.
1163
Results
The provisioning task definition is shared by the users you specified. They can see the shared definition in the Provisioning Task Definitions application in their login session. They can both use it and modify it.
Unsharing provisioning task definitions

You can unshare a provisioning task definition that was made available to you by other users. When you unshare a provisioning task definition, it becomes no longer available to you. You can unshare it by performing the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. 2. In the list of provisioning tasks, find the provisioning task definition that you want to unshare and click it. 3. From the Select Action menu, click Remove Shared Task.
Results
The provisioning task definition is no longer displayed in the list of your provisioning task definitions.
Viewing provisioning task history

You can view the history of all the provisioning task instances, after you opened a provisioning task definition. When you open a provisioning task definition to see its settings you can also view its history, by performing the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. 2. In the list of provisioning task definitions, find the provisioning task definition and click it. 3. Select the Show History check box. A History table is displayed with the history of all the instances of this provisioning task definition. 4. (Optional) To see additional details, click Detail Menu .
Results
You displayed the history of your provisioning task definition.
Submitting and tracking provisioning tasks

After you have created a provisioning task definition, you can submit the task and track its status. Tracking the status of a task allows you to see its progress and state. For tasks that you have scheduled and have not started yet, you can make changes where necessary. By clicking the name of a task, you can access detailed information about the task that is running, such as the name of the operator that started it, the task ID and the task status.
Running a provisioning task

You can run a provisioning task against one or more computers with parameters that you specify.
1164
Before you begin

Service access points and credentials must be set up for all target computers of your provisioning task. After you create a provisioning task definition, you can run it immediately, schedule it to run once, or set it to run at regular intervals. When you set a provisioning task to run, you specify: v The computers on which you want it to run. v The parameter values to use. v When to run it. To run a provisioning task perform the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. 2. In the list of provisioning task definition, find the provisioning task definition that you want to run and click it. 3. From the Select Action menu, click Run Provisioning Task. 4. In the Run Provisioning Task window, Targets section, click Select and select the computers on which you want to run the provisioning task. 5. In the Provisioning Workflows section, specify the concurrency level for the workflow. 6. In the Workflow Parameters section, specify the new values of the provisioning task parameters that you want to override before submitting the task. 7. In the Scheduling section, specify when you want to run the task. If you are scheduling a task, you can set in Start Window (minutes) the start time window, specified in minutes, after which the task is canceled if it could not be run. 8. In the Recipient section inside the Notification section, specify either the name of the users by clicking Add Recipient or the addresses of the users to be notified by clicking Add E-mail. 9. In the Event section inside the Notification section, you can choose to be notified about a variety of events by clicking Add Event to define the type of events that generate the notification. 10. Verify your selections and click Submit.
Results
After the submission, the provisioning task is displayed automatically in the Task page of the Provisioning Task Tracking application.
Tracking a provisioning task

Tracking the status of a provisioning tasks allows you to see its progress and state. For tasks that you have scheduled and have not started yet, you can make changes where necessary. You can monitor the progress of a provisioning task by using the Provisioning Task Tracking application. To monitor a provisioning task, perform the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. The provisioning tasks are displayed in chronological order. You can filter the provisioning task display sorting by task ID, by task names, by tasks that are in a certain state, by names of the user that started or scheduled the task, by the time the task has started or is scheduled to start, by the provisioning task type. To see the latest status of the provisioning tasks, click the Refresh page icon on the toolbar.
1165
2. To see additional details on one of the provisioning tasks, click the task name. A page with all the information about the provisioning task information is displayed. 3. You can see information about the provisioning task definition by clicking Look Up from
Definition. This Definition and the related Look Up are displayed only if the provisioning task instance has an associated task definition. To see the latest status of the provisioning task, click the on the toolbar. Refresh page icon 4. In the Provisioning Workflows section, you can expand your workflow and see in the Targets page, the list of resources on which that specific provisioning workflow is running and the provisioning workflow status. For further information on the target, you can click the target name and the related resource application is displayed. 5. If the provisioning task, that you have submitted, has multiple workflows, such as the Compliance Scan and Check provisioning task, the Provisioning Workflows table is populated with multiple entries. You can expand those entries to see the details of each workflow. In the Target tab, the Provisioning Workflow Log is populated with the deployment request ID. You can use this link to go to the Provisioning Workflow Status application and check the workflow status and the workflow log details. 6. (Optional) If you want to perform some actions on some instances of a provisioning task, from the Select Action menu, you can select one of the following actions depending on the provisioning task status: v Cancel Task. v Reschedule Task v Refresh Target List v Delete Task v Run Task Again v Run Reports
Results
You have monitored the provisioning task progress and, if needed, you have performed the appropriate actions on the task.
Keeping the target list accurate for tracking tasks

When you submit a provisioning task, the target list is calculated at submission time. You can refresh this list with the current targets, which might have changed due to dynamic provisioning groups being modified between the submission time and the execution time of the provisioning task. To manually refresh the list of targets of a provisioning task that is not running or is not in completed status, perform the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. 2. In the list of provisioning tasks, locate the provisioning task whose list of targets you want to refresh. 3. Check that the provisioning task is not running and is not in completed status and select it. 4. From the Select Action menu click Refresh Target List.
Results
You refreshed the list of targets of the selected provisioning task and kept an accurate tracking of the provisioning task on all the targets involved.
1166
Tracking provisioning tasks on specific computers

Track all provisioning tasks which are running on one or more computers within a specific time interval. You can monitor the progress of all provisioning tasks related to specific computers using a filtering option provided within the Provisioning Task Tracking application. A similar functionality is provided by the Provisioning Computers application. You can select computers in the Provisioning Computers application and move to the Provisioning Tasks Tracking application to see the tasks which have already run or will run on those computers. To display the provisioning tasks by computer, perform the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. The provisioning tasks are displayed in chronological order. 2. Click the Advanced Search filtering option. The More Search Fields panel is displayed. close to Target. The Select Value panel is displayed. 3. Click Select Value 4. Select from the list one or more computers on which you want to track the running provisioning tasks. If you do not see your computer, it means that it does not have any provisioning task associated. 5. Click OK to go back to the More Search Fields panel. 6. (Optional) Specify a time interval, setting a start date and time and an end date and time, during which the provisioning tasks you want to monitor are running. 7. (Optional) Click Revise if you want to modify your current query using one of the following options: Clear Query and Fields to clear your existing query and all its current fields. Clear All Fields to clear all the current fields of your query. Change Query to redefine the query that your search is based on. Restore Default Query to perform a search based on the default query. The default query means taking into account all the objects which are defined in the system. 8. Click Find. A list of all provisioning tasks related to the specified computers is displayed. 9. (Optional) Click the Save Query option if you intend to perform this query again. v v v v
Results
You have monitored the progress of provisioning tasks which involve a specific computer or a subset of computers of your environment. For repeating tasks, the displayed start date refers to the date when the next task execution is scheduled.
Rerunning a provisioning task

You can rerun a provisioning task without the need of changing its parameters. You can rerun a provisioning task only if it has been completely run and has one of the following status: success, failed, timeout, canceled, or canceled by condition. To rerun a provisioning task, perform the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. 2. In the list of provisioning tasks, find the provisioning task that you want to rerun and click it. 3. From the Select Action menu click Run Task Again. The Run Task Again dialog opens.
1167
4. Specify the scheduling options. You can either decide to run the provisioning task immediately or set a start date. If you are scheduling a task, you can set in Start Window (minutes) the start time window, specified in minutes, after which the task is canceled if it could not be run. 5. (Optional) Select the Run task with failed target only check box if you want to rerun the provisioning task only against the failed target computers.
Results
You submitted again the provisioning task. The newly submitted task is displayed to be monitored.
Setting a time limit for a provisioning task

You can set a time limit for a provisioning task by specifying a start time window for the task.
Before you begin

If you want to globally define a default value for the Start Window (minutes) field, you can set a default value in the Provisioning Global Settings application for the variable named task_start_window. When creating this variable, ensure that you specify User defined as its component and that you specify the default value in minutes. When you run or rerun a provisioning task you can set a start-time-window, specified in minutes in Start Window (minutes). The provisioning task should be started within this time window. If the provisioning task could not be run within the start-time-window you specified, the status of the provisioning task will be the following:
Table 211. Provisioning task status Repeating provisioning tasks Scheduled Until the scheduled task reaches the end of the scheduling time. Success After the scheduling time ends, the scheduled task completes successfully. Non-repeating provisioning tasks Timeout
To set a time limit for a provisioning task, perform the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. 2. Locate the provisioning task that you want to run or rerun and click it. 3. From the Select Action menu, click Run Task Again. 4. Specify in Start Window (minutes) the start-time-window, specified in minutes, after which the provisioning task will be canceled if it could not be performed before the time window you set. Note: The start-time-window is not supported for hour and minute options. You can only specify a value in minutes. Otherwise the start window feature will not work. Note: The Start Window (minutes) field is pre-filled with the default value you specified in the Provisioning Global Settings application. Note: If you leave the Start Window (minutes) field empty, the scheduling function does not take into account a task time limit.
1168
Restricting the access needed for rerunning a provisioning task

You can specify that the rerun action of a provisioning task can be performed by task owners only. To restrict the access needed to rerun a provisioning task to task owners only, perform the following steps:
Procedure
Click Go To > Security > Security Groups. Locate and open the security group you want to modify. Click the Applications tab. On the Applications list, click filter and under Description type Provisioning Task Tracking and press enter. 5. Double-click Provisioning Task Tracking. 6. Under Options for Provisioning Task Tracking select Run Task Again. 1. 2. 3. 4. 7. Click Select Action. 8. On the dialog, search for TPTSKOWRRUN. 9. Choose the TPTSKOWRRUN condition. . 10. Click Save 11. (Optional) Restarting the Tivoli Provisioning Manager server is recommended but not required.
Enabling automatic refresh for tracking tasks

Track all provisioning tasks within a specific automatic refresh time interval. You can automatically refresh the progress of all provisioning tasks by using a refresh time interval option provided within the Provisioning Task Tracking application. To enable this option, perform the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. 2. From the Select Action menu, select Refresh Interval. When the Provisioning Task Tracking page is loaded, the Off option is checked by default. 3. Select from the list the number of seconds you want for the refresh time interval of this page. 4. When the menu is closed, the refresh time interval is set.
Results
You have enabled an option to automatically refresh the Provisioning Task Tracking page according to the time interval set. The refresh time interval you set is maintained until you leave the Provisioning Task Tracking page. Next time you log on to the Provisioning Task Tracking application, the Refresh Interval option is set to Off again.
Displaying a graphical view of your recent provisioning tasks

Track all your recent provisioning tasks by displaying a graphical view from the start center. You can view the status of all your recently submitted provisioning tasks by displaying a graphical view provided within the Status of my recent provisioning tasks application that you can find on the start center. To display the graphical view, perform the following steps:
1169
Procedure
1. From the start center, click Graphical View on the Status of my recent provisioning tasks application. 2. Under the Status column, depending on the status of your provisioning task, one of the following numbers is displayed:
Option Status ID 0 1 2 3 4 5 6 7 8 9 10 11 12 Description Description Not started. Submitted. In progress. Suspended. Suspend pending. Resume pending. Cancel pending. Success. Timeout. Failed. Canceled. Canceled by condition. Scheduled.
Managing submitted provisioning tasks

After you have submitted or scheduled a provisioning task you can still perform some actions on it. Depending on your needs and on the provisioning task status, you can still perform the following actions on the provisioning task: v Edit a provisioning task after it has been submitted but before it starts. v Reschedule a provisioning task to change the computers on which you want to run it or its scheduling. v Stop a scheduled or in progress provisioning task that you no longer want to perform. v Remove provisioning tasks that completed successfully to track only the ones that are still in progress or that have generated errors.
Editing a provisioning task

Sometimes it is necessary to edit a provisioning task after it has been submitted but before it starts. You can edit a provisioning task that was created by a specific application, like Patch Installation or Software Installation, by using the Provisioning Task Tracking application. This is the list of provisioning tasks that you can edit when they are in scheduled state and are not running: v Patch Installation v Image Deployment v Common Agent Installation v Patch Download v Patch Unpublishing v Software Product Unpublishing v File Publishing task v Move Computers v File Unpublishing
1170
v v v v v v v
Software Installation task Software Uninstallation Software Upgrade Publishing Patches Acquire Patches Patch Distribution Install Windows Update Agent
To edit a provisioning task, perform the following steps:
Procedure
1. 2. 3. 4. Click Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. In the list of provisioning tasks, find the provisioning task that you want to edit and click it. From the Select Action menu, click Edit Task. It brings you to the original application, such as Patch Installation. You can easily add, remove, and modify the settings using the same interface with which you create the related provisioning task definition. 5. After modifying the provisioning task settings, click Submit to process the same provisioning task instance.
Results
You have modified the parameters of the provisioning task instance using the original application that created the provisioning task definition.
Rescheduling provisioning tasks

You can reschedule a provisioning task if you need to change the computers on which you want to run it or its scheduling. You can reschedule a provisioning task and change the computers on which to run it, only if it is not running and is in status deployed or scheduled. To reschedule a provisioning task, perform the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. In the list of provisioning tasks, find the provisioning task that you want to reschedule and click on it. 3. From the Select Action menu click Reschedule Task. The Reschedule Task window is displayed and you can modify the computers on which to run the provisioning task and the scheduling. For example, if you scheduled a patch installation on multiple computers and you want to add additional target computers, you can update the patch installation task before the scheduled start time for the task. 2.
Results
You rescheduled the provisioning task to run on different computers and at a different time.
Canceling in progress provisioning tasks

If you no longer want to perform a scheduled task or a task in progress, you can stop it using the cancel action.
1171
You can cancel all the scheduled or running provisioning tasks that are in one of the following status: deployed, scheduled, submitted, in-progress. Before you canceled a provisioning task, review its details to identify the computers that were already changed by the provisioning task. The action to take depends on the type of change that you made and its impact. For example, if you canceled the deployment of a patch, it is not rolled back on systems where it is already installed. If you cancel a task that is in progress, the following steps occur: 1. For target computers that have started deployment, the deployment continues. Tivoli Provisioning Manager waits for currently running workflows to finish. During this time, the status of the task is Canceling. 2. When the currently running workflows are finished, pending workflows are canceled, and Tivoli Provisioning Manager changes the task status to Canceled. To cancel a task:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. 2. In the list of provisioning tasks, find the provisioning task that you want to cancel. 3. From the Select Action menu, click Cancel Task.
Results
Any deployments for the provisioning task that are in progress are completed, and then the provisioning task is canceled.
Removing provisioning tasks

You might want to remove provisioning tasks that completed successfully so that you can track only the ones that are still in progress or generated errors. You cannot delete a scheduled or running provisioning task, whose status is deployed, scheduled, submitted or in-progress. You must cancel it first before you can delete it. To remove a provisioning task, perform the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. 2. In the list of provisioning tasks, find the provisioning task that you want to delete. 3. Check that its status is one of the following: failed, success, timeout, cancelled, cancelled by condition. 4. Click Mark for Delete . 5. If you want to remove multiple tasks at the same time, you can either select Select Records and then multiselect the tasks that you want to delete or use the available filters to find the tasks you want to delete. After you selected the provisioning tasks to be deleted, select Delete Task from the Select Action menu. 6. If you are in the Task tab, to delete the provisioning task select Delete Task from the Select Action menu. 7. If the provisioning task status is scheduled or deployed, before deleting it you must cancel it by selecting Cancel Task from the Select Action menu.
1172
Results
You deleted the provisioning tasks that you did not want to be displayed in the list.
Retrieving provisioning task information

After you have run a provisioning task, you can run a provisioning task report to retrieve current information about this task. To generate and run a provisioning task report, perform the following steps:
Procedure
1. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. 2. From the Select Action menu, click Run Reports. 3. You can choose one of the predefined reports to display how many tasks have been started on a given date and are in a specific state or what is the state of all tasks. 4. A report request page is displayed, you can run the report immediately, schedule the report to be run at specific date and time, or repeatedly for a specified interval, and send the report to a list of people.
Results
A provisioning task report that provides provisioning task state information is generated.
What to do next
You can now use this report to monitor deployment, verify compliance, troubleshoot errors, and forecast future activity.
Bookmarking a provisioning task

You can find a provisioning task definition or a provisioning task instance more easily in the future by setting a bookmark and saving it to the Bookmarks view. To bookmark a provisioning task, perform the following steps:
Procedure
1. To bookmark a provisioning task definition Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. To bookmark a provisioning task instance Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. icon next to the provisioning task description or Bookmarks at the 2. Click the Add to Bookmarks top of the List tab. 3. If you are in the Task tab, you can bookmark the current provisioning task by selecting Add to Bookmarks from the Select Action menu.
Results
You bookmarked a provisioning task that you can retrieve by clicking Bookmarks icon in the Provisioning Task Definitions or in the Provisioning Task Tracking applications. The bookmarked tasks are available by clicking the Bookmarks icon on the top of the List tab of the task management applications.
1173
Creating a group from the provisioning task results

Before you begin
Before you can create a group from the target computers, on which you ran a provisioning task, the provisioning task must be completed and in final state. To create a group using the results of a provisioning task, perform the following steps:
Procedure
1. 2. 3. 4. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Tracking. Identify and select the provisioning task to use to create a group. From the Select Action menu, click Create Group. Specify a name for the group.
5. Select one or more provisioning workflows that you want to perform on the target computers included in the group. 6. Select one or more states that the target computers must be included in the group.
Results
After the creation, the group is displayed in the List page of the Provisioning Groups application.
Provisioning tasks in IBM Service Management

Tivoli Provisioning Manager can implement higher level IBM Service Management processes or other business processes by associating provisioning tasks to tasks that are part of a work order, change, or release. A task is common to all products that use the base services. A task is the fundamental unit of work in a work order process. A provisioning task is specific to actions performed by Tivoli Provisioning Manager that are managed in the Provisioning Tasks application. The higher level process to implement a request is still governed by process managers, like Change, Release, and Service Request Manager. When you get to the stage of specifying its lower-level implementation tasks, these tasks can be classified as provisioning tasks, and an assisted workflow can be used to create the necessary provisioning tasks, convert the available information, and run the actual provisioning tasks. The steps described in this section are required to accomplish this implementation.
Enhanced integration with IBM Service Management tutorial

Tivoli Provisioning Manager 7.2 offers a set of new IBM Service Management integration features which allow you to process seamless provisioning tasks based on the service parameters, from workflow order, tasks, classification attributes and automatically execute the provisioning task in the background. After the provisioning workflow is executed, the assisted workflow will route you to the provisioning task track page in order to monitor the running status. Using the new features you can: v Integrate IBM Service Management processes with provisioning tasks. v Classify enablement for software and patch deployment and management use cases. You can specify the classification attributes during the different stages of the ISM process. v Automate work order creation from a service ticket. v Automate the job plan assignment and configure assisted workflow based on the classification programmatically.
1174
v Create assisted workflows to integrate software deployment, software management, and patch deployment. You can use Jython scripting to run software product uninstall and device ping operations, or create your own custom Jython script to call any provisioning workflows. v Enable the Automation Scripts application in Tivoli Provisioning Manager for Jython to call in provisioning tasks. Information about how to use and import samples can be found in the IBM Service Management integration tutorial. v Close the loop of service request and work order/tasks. For more information about IBM Service Management, see the TPM 7.2 Enhanced integration with IBM Service Management tutorial .
Planning Time
v Add a task with provisioning classification to a work order. In Tivoli Provisioning Manager 7.2, we provide a Job Plan template that defines a provisioning task. When running an automated route from a work order to a service ticket, the Job plan automatically associates itself to the work order. You can customize the Job Plan template from the Job Plan application UI. v Attach Provisioning assisted workflow to the task. v A change manager or change owner, or a user with a provisioning administrator role can perform process manager operations from the process manager applications. For information about change management roles, refer to the Change and Configuration Management Database (CCMDB) documentation.
Execution Time
v Claim task and run assisted workflow to create a provisioning task. v Return to the base task from the provisioning task. v Execution steps can be performed by a user with the deployment specialist role. Note: In order to run an assisted workflow, in Tivoli Provisioning Manager 7.2, you need to implement it based on a work order task that is waiting for approval. You would have to get the work order task approved and the work order task is moved to 'In Progress' state before the assisted workflow can be executed.
Requirements
The base services included in Tivoli Provisioning Manager provide the basic capability to implement provisioning tasks in higher level processes. To take advantage of the full integration, the following products are recommended: v Tivoli Application Dependency Discovery Manager (TADDM) for discovery and generation of Globally Unique Identifiers (GUIDs) v Change and Configuration Management Database (CCMDB) for change and release management v IBM Tivoli Service Request Manager to manage service requests For more information about change, release, and service request management processes, see the ISM information center at http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/index.jsp. A prerequisite to working with work orders and related objects is to do initial data configuration for base services. You must follow the instructions in the topic Initial data configuration in the Change and Configuration Management database information center.
Adding provisioning tasks to processes

Add provisioning tasks to implement specific actions at the lowest level of granularity in a process.
1175
Tasks can be created at any time during a process, as part of a work order or derived object (like change or release). When you create a work order, you typically create a sequence of tasks that is sufficient to define the overall structure of the work plan. Tasks are defined in greater detail during the Plan phase of a process. Related tasks can be grouped into activities as a way to efficiently organize the work plan. Tasks to be classified as provisioning tasks must be at the lowest level of granularity, when the activities have been broken down to a level where the task is owned by a specific person, affects a specific set of configuration items (CIs), and is implemented in a specific time window. All this refinement is done at the process manager level. To create a task, perform the following steps:
Procedure
1. Open the Plans tab in one of the following records: v The work order for which you want to create the task. Click Go To > Work Orders > Work Order Tracking. v The activity in which you want to place the task. Click Go To > Work Orders > Activities and Tasks. 2. Click New Row in the Tasks section. 3. Assign a Provisioning classification in the Classification field. Tivoli Provisioning Manager provides the following classifications: v Provisioning Task Definition Provisioning task templates which can be used to run scripts, provisioning workflows or activity plans. v Agent Installation v Software Installation v Patch Installation Additional attributes are added to the task when the classification is applied. Provisioning Task Definition ID Identifier for the provisioning task template associated with this task. Provisioning Task ID Identifier for the provisioning task instance associated with this task. These attributes are filled in when the assisted workflow runs. Alternatively, you can reuse existing provisioning tasks by filling in these IDs using the details menu for these attributes. 4. If the task involves configuration items such as sources or targets, or if it impacts one or more CIs, select the Implementation task check box. 5. Enter information into the other fields in the section as needed to define the task you are creating. 6. Click Save .
Results
The task is created. You can add tasks later to job plans, which are attached to a work order. The creation of a task on a job plan is similar to the process described above, except that it is done in the Job Plan application.
Attaching an assisted workflow

A task can have an attached assisted workflow. An assisted workflow guides you through a task and ensures that the correct process is followed.
1176
The assisted workflow can be thought of as a kind of wizard. When you perform an assisted workflow task, applications that you need to perform the task are opened in the correct order, and the applications are prepared for the performance of the task. Tivoli Provisioning Manager includes a predefined assisted workflow that you can use to automatically create a provisioning task from a task. This assisted workflow creates the necessary provisioning objects, filling in the additional attributes for the task, and converting any information in the task which can be reused in the provisioning task. This information includes: v Target configuration items (CIs) v Scheduled start date The conversion of targets CIs to data model objects depends on these objects being linked with a Globally Unique Identifier (GUID). To meet this requirement, Tivoli Application Dependency Discovery Manager (TADDM) must discover computers which are loaded into Change and Configuration Management Database (CCMDB) as Actual CIs. These Actual CIs must be promoted to Authorized CIs. On the Tivoli Provisioning Manager side, TADDM discovery must be run to create data model objects for these computers with GUIDs. When both sides have the objects with the same GUID, they are automatically linked together. This linkage can be seen in the Provisioning Computers application as well as in the Configuration Items Application. To attach the assisted workflow provided with Tivoli Provisioning Manager to a task, perform the following steps:
Procedure
1. Open the task that you want to modify. v In the work order that you created in Adding provisioning tasks to processes on page 1175, click beside the Reference WO field and select the task. Detail Menu v Click Go To > Work Orders > Activities and Tasks. Search for the task and click the name in the search results. beside the Assisted Workflow field, and click Select Value 2. In the task, click Look Up 3. In the Select Value widow, filter for TPCREATTASK and select it. 4. Specify any additional details for the task as required: .
v You can select a scheduled start for the task. If you do so, this information is converted and handled by the provisioning task. v If you have CIs that are affected by this task and are linked to data model objects, select them in the target list. 5. Save the task.
Results
The assisted workflow is attached to the task. The task planning is complete, and can be implemented using a provisioning task. At this point the task can be assigned to an specific owner and it state can be changed to approved or in progress. The assignment of owner to the task and the state of the task is part of the overall process management, and is not automated or enforced by Tivoli Provisioning Manager. In order to claim and initiate a provisioning task, the user who claims the task must belong to the MAXADMIN, TPADMIN or TPDEPLOYMENTSPECIALIST group.
Claiming and initiating a provisioning task as part of a process

A provisioning task is initiated after a task is claimed from the Start Center. Typically, a provisioning task contains an assisted workflow that takes the task owner to the appropriate provisioning application, where specific types of provisioning tasks can be performed.
1177
Typically, you run the assisted workflow only once to execute the task in a overall process. The TPCREATASK assisted workflow provides the following functionality: v Creates the necessary provisioning objects and attempts to convert the target configuration items (CIs) and scheduled start date of the base services task to the equivalent attributes on the created provisioning object. v Links the base services task with the provisioning objects by filling in the classification attributes: Provisioning Task Definition ID Provisioning Task ID v Opens the provisioning application that handles this specific classification of task. Reusing task definitions or tasks For TPTASKDEFINITION classification: v If you reuse a task definition (providing a value for TPTDEFID either from a previous run or manually filling it in), the assisted workflow will attempt to reuse the existing task definition (and any predefined workflows and default parameters included in it). v If you also include a task (by providing a value for TPTASKID), the assisted workflow will still create a task and replace this TPTASKID number, but it will attempt to reuse the targets from the original TPTASKID. If target CIs are available in the base task, these targets will take precedence and be used in the new task. For all other provisioning classifications: v If you reuse a task (by providing a value for TPTASKID), and that task is in a final state (failed, successful, cancelled, timeout), a copy of this task will be created so that its parameters can be reused. Target CIs specified in the base task override reused task targets. v Otherwise, the same task will be reused by the assisted workflow. To claim and run a provisioning task as part of a process, perform the following steps:
Procedure
1. On the Start Center in the My Tasks section, click the name of the implementation task. The Activities and Tasks application opens the task and information about the task is displayed. If this is a provisioning classified task, the TPCREATASK assisted workflow must be attached to the base services task, with TPCREATASK displayed in the Assisted Workflow field. In addition, the Start Assisted Workflow button is enabled. Alternatively, you can go directly to the Activities and Tasks application and filter the list to find the task. 2. Click Start Assisted Workflow to launch the appropriate Provisioning application which handles this classification of task. 3. Information from the original task is converted and filled in for you in the provisioning task when available. Enter any additional required fields for the task and submit the task. You can override settings converted from the original task as required, such as the scheduled start time. When the classification selected for the ISM task is TPTASKDEFINITION, the assisted workflow will open the task definitions application. In this application, task definitions can be created, and instances of these definitions can be run as tasks. First, you will need to provide additional information about this task definition (such as a workflow name and target parameter) and save it. After that, when you select to Run Task Definition, any information passed from the ISM task (that is, target CIs and schedule) will appear in the Run dialog. Note: If you select Activity Plan as the type of the task definition, you will use the Activity Plan Editor to create the task definition. Information about targets coming from the ISM task are not passed to this editor, so you will need to specify a target for the activity plan created. The target (if any) converted from the ISM task will be available when you Run Task Definition.
1178
Results
You can check the status of the provisioning task in the Provisioning Task Tracking application. It is possible to return from that provisioning task instance to the Activities and Tasks application for the equivalent task by selecting Go To Activities and Tasks from the detailed menu of the base services task field.
Setting the value of the work order number

When you are creating a new work order, the next available work order number should be the next sequence number returned by the server for the WORKORDER table.
Procedure
1. Check the Default Value for the Work Order Number: a. Click Go To > System Configuration > Platform Configuration > Database Configuration. b. Search for an object WORKORDER. c. Click the object WORKORDER, then click the Attributes tab. d. Verify the following: v The Default Value is set to &AUTOKEY&. If not, change the value to &AUTOKEY&. Click Admin mode, then click Apply Configuration Changes, turn off Admin mode after the configuration change is applied. v Autonumber is set to WORKORDERNUM. If not, write down the name and remember it for later. v If the work order number needs to be longer than 10 (including the prefix), you need to change the Length. Click Admin mode, then click Apply Configuration Changes, turn off Admin mode after the configuration change is applied. Note: The Length is Prefix + the numeric value of 1xxx. As an example, if the Prefix is ABC, and the numeric value is 1234, then the Length would be 7. 2. Set the Prefix to the Work Order Number for each of the sites. a. Click Go To > Administration > Organizations. b. List all of the Organizations, and perform the following steps for each organization: 1) Click the Organization. 2) Click Select Action > Autonumber setup > Organization Level. 3) Search for WORKORDERNUM. If the value of WORKORDERNUM was different, use that value instead. 4) Set the Prefix. The maximum length is 6 by default. If your numeric value is 4, then the Length would be 10. 3. Verify that the Work Order Number appends the Prefix. a. Log on as a user whose default site is what is configured above. b. ClickClick Go To > Work Orders > Work Order Tracking. c. Click the New Work Order icon. d. Verify that the Work Order contains the Prefix which was defined.
Results
The Work Order Number is now set.
1179
Troubleshooting task management

To help you troubleshoot problems with task management, gather as much information as possible about the error. Review the following list to assess the problem.
Procedure
1. Verify that all requirements for the scenario were met as described in Requirements on page 1160. 2. If an error message with a message ID is displayed, search for the message ID in the information center or see the Tivoli Provisioning Manager Troubleshooting Guide for a description of the error message. 3. If a provisioning task fails during the tutorial, check any error messages generated by the provisioning workflows that are part of the task. For more information, see the Viewing workflow execution status from the Web interface topic. 4. Check the log files for error messages. The following log files contain information for the scenario:
Table 212. Log file locations Log file Deployment engine logs Log description Contains diagnostic information for the deployment engine. Contains diagnostic information about the scalable distribution infrastructure jobs that are running on the target computer. Location
Windows UNIX
Linux
Target computer logs
Windows UNIX
%TCA_HOME%\logs\trace-log-0.xml
Linux
$TCA_HOME/logs/trace-
log-0.xml
Provisioning workflow logs
Contains the history of Viewing provisioning workflow logs provisioning workflows recorded in the provisioning workflow logs.
5. Check the Tivoli Provisioning Manager Support technotes and FAQs or the latest available fix pack readme file for information about known issues or updates to the documentation.
Hardware Management Console error messages appear scrambled in a non-English locale

Symptoms
Workflow error messages that result from Hardware Management Console commands in the System p server automation package are displayed scrambled in the Tivoli Provisioning Manager web interface.
Causes
The default encoding used by the Tivoli Provisioning Manager server is not UTF-8.

Verify if the Tivoli Provisioning Manager server's locale is installed with UTF-8 encoding on the Hardware Management Console server. For example, if Tivoli Provisioning Manager server's locale is ja_JP, then locale ja_JP.UTF-8 should be installed on the Hardware Management Console server. If it is not, install UTF-8 encoding on the Hardware Management Console server. Whether you have to install UTF-8 on the Hardware Management Console server or not, you need to perform the following steps:
1180
1. On the Tivoli Provisioning Manager server, add the line -Dfile.encoding=UTF-8 to the TPM.javaopt file located in the %TIO_HOME%/lwi/conf/overrides directory. 2. Restart the Tivoli Provisioning Manager server.
web interface does not refresh with new data

In some situations, you may notice that the Tivoli Provisioning Manager web interface does not refresh with new data. This is due to an outdated JDBC driver used by base services on the IBM WebSphere Application Server.
Symptoms
The Tivoli Provisioning Manager web interface does not refresh with new data. In addition the SystemOut.log file (%WAS_HOME%\logs) displays the following out of memory exception under base services:
java.lang.OutOfMemoryError at java.net.InetAddress.getLocalHost(InetAddress.java:1463) at com.ibm.db2.jcc.t4.b.k(b.java:3473) at com.ibm.db2.jcc.t4.b.Uc(b.java:2283) at com.ibm.db2.jcc.t4.b.b(b.java:716) at com.ibm.db2.jcc.t4.b.a(b.java:409) at com.ibm.db2.jcc.t4.b.<init>(b.java:345) at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:197) at java.sql.DriverManager.getConnection(DriverManager.java:572) at java.sql.DriverManager.getConnection(DriverManager.java:165) at psdi.server.DBManager.createConnection(DBManager.java:653) at psdi.server.DBManager.createUserConnection(DBManager.java:596) at psdi.server.DBManager.getConnectionDetail(DBManager.java:1293) at psdi.server.DBManager.getConnection(DBManager.java:1179) at psdi.server.AppService.getDBConnection(AppService.java:549)
The out of memory exception results because of accumulating web interface sessions / transactions during an inconsistent database connection.
Causes
The Tivoli Provisioning Manager losses connection to the database because of an outdated IBM WebSphere Application Server JDBC driver used by base services.

Upgrade the JDBC driver used by base services on the IBM WebSphere Application Server. To do this: 1. Copy db2jcc.jar from: v v
Windows %TIO_HOME%\lwi\runtime\tpm\eclipse\plugins\tpm_pmp\maximoLibs to %MAXIMO_HOME%/maximo/applications/maximo/lib
$TIO_HOME/lwi/runtime/tpm/eclipse/plugins/tpm_pmp/maximoLibs to $MAXIMO_HOME/maximo/applications/maximo/lib
UNIX
Note: For the default location of MAXIMO_HOME, click here. 2. Rebuild and redeploy the Maximo ear file by following steps 8 to 23 outlined in section 2.6 of the Tivoli Provisioning Manager 7.1.1: A DBMS Movement Solution white paper.
Provisioning tasks cannot be scheduled and submitted from web interface

This limitation is caused if the activity plan was saved as a draft which can only be done in the Activity Plan Editor.
1181
Symptoms
A provisioning task cannot be scheduled and submitted from the web interface.
Causes
The activity plan was saved as a draft, which can only be done in the Activity Plan Editor.

Use the Activity Plan Editor to save the plan as a template instead of a draft. To do this, perform the following steps in the provisioning task application: 1. Select a task with type=Activity Plan. 2. Click the Task tab. 3. At the Mark activity plan as option, click the Template radio button. 4. Click Template and then save the task. After this is done, use the following steps to run the provisioning task. 1. 2. 3. 4. Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. Click Activity Plan from the list of provisioning task definitions. From the Select Action menu, click Run Provisioning Task. Click Select to select the target computers on which you want to run the provisioning task.
5. Click Schedule to specify some scheduling options for the provisioning task. 6. Click Submit to run the provisioning task.
Cannot delete shared provisioning tasks

You cannot directly delete shared provisioning tasks that were created by other owners.
Symptoms
You cannot delete multiple provisioning tasks in the Provisioning Task Definitions application and instead receive an information message that tells you that shared provisioning tasks can only be deleted by their owners.
Causes
Shared provisioning tasks can only be deleted by their owners. If the provisioning tasks that you have selected include shared provisioning tasks created by other owners, you cannot delete them directly.

To 1. 2. 3. 4. work around this problem, perform the following steps: Click Go To > Task Management > Provisioning Tasks > Provisioning Task Definitions. From the list, identify the shared provisioning task that you cannot delete. Click the Detail tab of the shared provisioning task. From the Select Action menu, click Remove Shared Task.
This action will unshare the provisioning task for the current user, and the shared provisioning task will be removed from the current list.
1182
Provisioning tasks remain in progress after recovery

When the provisioning server is reset, tasks that are in progress will fail with a Java Virtual Machine error.
Symptoms
If the Tivoli Provisioning Manager server was interrupted in any way (for example, due to a power failure or the deployment engine being stopped) while a task is in progress, that task remains in progress even after Tivoli Provisioning Manager recovers. Any objects that the task is holding will not be released.
Causes
When the provisioning server is reset, tasks that are in progress will fail with a Java Virtual Machine error.

Run the clean-up-deployment-requests command to clean up unfinished deployment engine requests and to release any objects being held. Note: You do not need to restart the provisioning server after the command has run. Refresh the provisioning server web interface, and the unfinished task will be changed to the failed state with an appropriate message error.
SSH error occurs during task

This is a built-in SSH mechanism that prevents access from other computers that try to impersonate a known computer.
Symptoms
The following error occurs when a task is running:
>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 4c:e2:db:b3:38:de:5f:f3:54:34:47:50:33:a0:be:86. Please contact your system administrator. Add correct host key in /home/tioadmin/.ssh/known_hosts to get rid of this message. Offending key in /home/tioadmin/.ssh/known_hosts:3 RSA host key for 9.23.17.47 has changed and you have requested strict checking. Host key verification failed.
Causes
1183
This error occurs when SSH between the provisioning server and the target computer detects a change in the RSA key. For example, this might occur when a particular target computer is re-imaged, because then the SSH keys would no longer match with the keys from the provisioning server. It is a built-in SSH mechanism that prevents access from other computers that try to impersonate a known computer. This error message tells the system administrator that the target computer is no longer the same. If the system administrator determines that the computer is not an offending computer (which is the case when re-imaging) then the provisioning server provides a convenient way to solve this.

In 1. 2. 3. the Provisioning Workflows application, run the workflow called RemoveSshKey. Click Go To > Administration > Provisioning > Provisioning Workflows. In the Provisioning Workflow list, find the workflow called RemoveSshKey. Click Run
This workflow will remove the existing keys of the target computers from the provisioning server. After running this workflow, the error will not occur when the task is run again.
Install software task fails for extracted installable file

On Windows computers with Cygwin installed, use .tar archives instead of .zip archives.
Symptoms
If you do an install software task using the following steps, the task will fail: 1. Go to IT Infrastructure > Software Catalog > Software Product Import. 2. Enter the data for all of the fields. 3. Select Windows OS. 4. Select Custom Extract and Install. 5. Set the Configuration template parameter for the created software product as:
Extract command - unzip <file name> Install command - <file name> -q
6. Run the task on a Windows computer with Cygwin installed. The following message appears:
COPCOM123E A shell command error occurred: Exit code=1, Error stream="Access is denied", Output stream=""
Note: v The file will extract using the unzip command but the extracted file does not have read and run permissions. v The workflow will assign the required permissions for the extracted file.
Causes
This is caused by the coexistence of Windows and Cygwin while using the extraction utility. The extraction utility will not correctly set the permission of unpacked files when Cygwin is installed.

On Windows computers with Cygwin installed, use .tar archives instead of .zip archives.
1184
Task error after using the clean-up-deployment-requests command

If you receive this error, it means another user has already run the clean-up-deployment-requests command on the provisioning server.
Symptoms
After you run the clean-up-deployment-requests command, the following deployment task error message occurs:
COPDEX029E The system cannot continue the deployment request from a previous deployment engine JVM session.
Causes
Another user has already run the clean-up-deployment-requests command on the provisioning server.

No action is needed.
1185
1186
Chapter 14. Reports

Reports are used to retrieve current information about enterprise inventory, activity, and system compliance. Several applications have predefined reports available. Using the Report Administration feature, you can run predefined reports, customize predefined reports, import or export report definitions, and create new reports. For each of the applications, a number of predefined reports are available that you can use to review and analyze activity in your enterprise. Use these reports to identify patterns, diagnose problems, optimize and plan resource allocation, and forecast future activity. Predefined reports are available for the following applications: Provisioning Computers Reports for the provisioning computers application show current information about your enterprise inventory. The reports show compliance and patch information for computers and groups in the provisioning data model. Provisioning Groups A Provisioning Groups report shows group compliance against Sarbanes-Oxley (SOX) rules. Patch Patch reports show information about software deployments and patch deployments for each computer. Some reports identify patches that are installed on computers and other reports show the patches that are missing on computers.
Discovery Configurations Discovery reports show the last discovery scan results by target computer and discovery scan type. Provisioning Task Tracking Provisioning Task Tracking reports show the tasks that are in a specific state and show the status of all tasks. Provisioning Global Settings Provisioning Global Settings reports show information about event notification for users. Provisioning Workflows Provisioning Workflows reports show summary information about the workflows that have been run. Virtualization Management Virtualization Management reports show information about virtual servers and their host platform servers. Saving report results All reports and report results can be saved to allow you to run a report again or see past results at any time. You can run a report immediately or schedule the report to run at a later time. If you schedule the report to run at a later time, the report results are sent in a PDF file to the specified email address. Reports can only be saved in either PDF or comma-separated value (CSV) format. Saving reports in HTML format is not supported. When you save a report in CSV format, only the data contained in the top-level report is saved. The subreports within a report are not saved. Go to each subreport report and save the report in CSV format to obtain all of the information. For example, if you run a report to get server details and save the report
1187
in CSV format, only two fields are saved: server name and server ID. The other networking and resource details contained in the subreports are not saved. If you want to save hardware information or the status of the target provisioning computers, select and run these two reports directly, and then save the reports in CSV format. Tip: Viewing run reports Administrators can view the history of all reports that have run in a selected time frame. 1. Click Reports > Administration > Reporting > Report Administration. 2. Click the Report Usage report. 3. Enter the required information in the Request Page. 4. Click Submit. Note: Creating and running your own reports can affect system performance. When you are creating reports, including too many objects in the reports reduces your system performance. Use filters, if possible, to minimize the effect on system performance. For more information, see the Maximo Report Performance Guide. To access this guide, go to http://www-01.ibm.com/software/sysmgmt/products/ support/IBMMaximoAssetManagement.html and search using document reference number 1305031. You can set up a secondary database to move the workload of running reports to a second database, replicating the production database. Setting up the secondary database minimizes the performance impact on your production database. For information about how to set up a secondary database, go to http://www.ibm.com/support and search using document reference number 1304936. For more information about running reports, customizing reports, and creating new reports in BIRT (Business Intelligence and Reporting Tool), see the Report Developer Guide in the information center. You can also access useful information about reports in the following documentation, available at the IBM Support website http://www-01.ibm.com/software/sysmgmt/products/support/ IBMMaximoAssetManagement.html: v Configuring BIRT Designer 2.3.2 with V7 Products (document reference number 1390372) v V7 Reporting Feature Guide (document reference number 1305020) v Designing V7 Reports (document reference number 1305009) v Tivoli Provisioning Manager Reporting white paper (http://www-01.ibm.com/software/brandcatalog/ ismlibrary/details?catalog.label=1TW10107Y) You can access up-to-date articles and information about developing reports from the Maximo wiki https://www.ibm.com/developerworks/wikis/display/maximo/Reports. Related concepts Creating ad hoc reports on page 1196 Running reports on page 1200
Getting started with reports

Ensure proper user roles and requirements Users with the following roles can access all of the provisioning reports: v Provisioning Administrator v Deployment Specialist v Compliance Analyst v Provisioning Configuration Librarian These roles have access to run the provisioning reports by default. You can use Reporting Administration application to change the default report access setting to meet your specific requirements.
1188
Note: Only the MAXADMIN security group has the authority to give other groups access to specific reports. Generate Request Pages Before you can run a report, you need to load the necessary XML presentation files for the report request page. This is known as generating the request page for the report. You do this once for each report. The request page for a report displays selections that a user can make. A user can specify the following information: v Report parameters. v Schedule report to run. You can run the report immediately, run it at a specific date and time, or run it on a specified interval. v Send the report results to other users using email. The request page must be generated for predefined reports and newly imported reports. To generate the request pages for reports, follow these steps: 1. Click Go To > Administration > Reporting > Report Administration. 2. You can click Generate Request Pages to generate the request pages for all reports. Alternatively, if you want to generate the request page for a particular report, search for the report that you want to run. Then click on the report file name and click Generate Request Pages. When the request page has been generated, you can run the report. Note: After you have generated the request page for a report, if you change the report parameters, you must generate the request page for that report again. If you do not generate the request page again, you will see the previous report request page when you run the report. Ensure that you can receive scheduled reports If you schedule reports to be run at a later date and time, the report results will be sent to the specified email address. There are two areas that need to be defined so that you can receive report results by email: 1. SMTP mail server properties. Ensure that a valid email server is defined in the system properties. a. Click Go To > System Configuration > Platform Configuration > System Properties. b. In the Global Properties list, find the mail.smtp.host property. c. Expand the mail.smtp.host property and define a valid email server in the Global Value field. For example, na.relay.ibm.com. . d. Click Save e. Select the check box beside the Global Property that you have just changed f. Click Live Refresh Note: You cannot specify the SMTP user name and password for the SMTP server. This is a limitation for the current release. For more information about system properties, see the System Administrator Guide. 2. Email address. You must have a valid email address defined in your user profile, even if you are planning to send the reports to another user. The reports are sent from your email address. a. Click Go To > Security > Users. b. In the Users list, locate and click your user name. c. Enter a valid email address in the Primary Email field.
Chapter 14. Managing reports
1189
Remember: If you manually add an email address to a user profile, and there is a different email address configured in the LDAP server, the email address that you manually entered will be overwritten during any synchronization with the LDAP server. Contact your system administrator for more information. d. Click Save .
Running multiple reports at the same time The recommended number of reports to schedule to run at the same time is 5 or fewer. This will ensure that you receive the results for all of the scheduled reports. The value of the global setting mxe.report.birt.maxconcurrentrun specifies this recommendation. It considers that some reports might take longer to run than others, so if you schedule more than five reports to run, you might not get results for all of the reports. For example, if you schedule 10 reports to run and one of the reports takes longer to run, the other reports might complete after the scheduled time and therefore be cancelled. To view the global setting, click Go To > System Configuration > Platform Configuration > System Properties. Related tasks Reporting extended attributes on page 1202
Predefined reports
Use the predefined reports to quickly and easily retrieve information for common inquiries. There are predefined reports in several of the applications. Any of the predefined reports can be edited or copied so that you can customize the report to return specific results. Predefined reports are available for the following applications: v Provisioning Computer reports v Provisioning Groups compliance report on page 1193 v Patch reports on page 1193 v v v v v v Discovery Configuration reports on page 1194 Provisioning Task Tracking reports on page 1194 Provisioning Global Settings report on page 1195 Provisioning Workflows report on page 1195 Virtualization Management report on page 1195 Other reports on page 1196
Tip: To search for a specific predefined provisioning report, click Go To > Administration > Reporting > Report Administration. Search for the report by Report Name, Description, or Application. Related tasks Reporting extended attributes on page 1202
Provisioning Computer reports

Reports for the provisioning computer application provide information about the patch compliance or software compliance status of all the selected target computers and groups. These reports also show results for security compliance policies, for example: compliance check information about power-on passwords, antivirus, and firewalls.
1190
Predefined provisioning computer reports

Predefined reports are available for the following information:
Report File Name tp_complianceSummary.rpdesign Description Are servers compliant with their compliance checks? Report Detail This report is organized into a pie chart showing the summary of the compliance status for the compliance check defined on a group. The compliance check status include: v Compliant v Not Compliant v Unknown tp_compliance.rptdesign What is the compliance result This report displays the of all provisioning servers? compliance result of all provisioning servers. It can be filtered by compliance status and the compliance check status include: v Compliant v Not Compliant v Not Checked v Unknown tp_softwareCompliance.rptdesign What is the software compliance result of all provisioning servers? This report displays the software compliance result of all provisioning servers.
tp_ patchCompliance.rptdesign
What is the patch compliance This report displays the patch compliance results of all result of all provisioning provisioning servers. servers? Who receives compliance notifications? What is the result of the security compliance check? What servers have patches approved for installation? What patches are missing on what servers? Do Windows servers comply with the patch policy? What patches are missing on what Windows servers? What is the software configuration compliance result of all provisioning servers? This report displays the users who receive compliance event notifications. This report displays the security compliance check result. This report displays the servers that have patches approved for installation. This report displays what patches are missing on what servers. This report displays whether Windows servers comply with the patch policy. This report displays the patches that are missing on Windows servers. This report displays the compliance result for software configurations on all provisioning servers in the data model.
tp_complianceNotification.rptdesign
tp_securityCompliance.rptdesign
tp_patchApproved.rptdesign
tp_patchMissing.rptdesign
tp_patchComplianceForWindow.rptdesign
tp_patchMissingForWindows.rptdesign
tp_softwareConfigurationCompliance.rptdesign
1191
Report File Name tp_groupCompliance.rptdesign
Description
Report Detail
What provisioning groups do This report identifies the not have compliance checks? provisioning groups that do not have compliance checks. What servers do not have compliance checks? This report displays a list of all provisioning servers in the data model that do not have compliance checks. This report identifies the number of servers that are installed with each operating system. This report lists the provisioning servers This report displays a list of all provisioning servers and the hardware that is installed on them. This report identifies provisioning servers that have patches installed on them. This report identifies all of provisioning servers in the data model. This report shows all of the information about provisioning servers. This report identifies the software that is installed on each provisioning server.
tp_noComplianceCheck.rptdesign
tp_osOnServerChart.rptdesign
How many servers are installed with which operating systems? What is the status of all provisioning target computers? What hardware is on what server?
tp_endpoints.rptdesign
tp_hardware.rptdesign
tp_patches.rptdesign
What servers have what patches installed?
tp_servers.rptdesign
What servers are in the data model? What are the server details, including networking and other resource details? What software is installed on what servers?
tp_serverDetails.rptdesign
tp_software.rpt
tp_virtualServers.rptdesign
How many virtual servers are This report identifies the virtual servers that are created on a specific host installed on a specific host platform server? platform server. What patches are installed on This report displays patches what servers? that are installed on servers, listed by patch name. What common agent is This report displays agent installed on what computers? information for the Tivoli Common Agent that is installed on each provisioning server. What is the maintenance window for TCA agents? This report displays the maintenance window information for the target computers which have a maintenance window definition.
tp_patchesOnServers.rptdesign
tp_tcaOnComputers.rptdesgin
tp_maintenanceWindow.rptdesign
1192
Provisioning Groups compliance report

Predefined Sarbanes-Oxley compliance report
Tivoli Provisioning Manager provides a report, tp_SOXCompliance.rptdesign, that you can generate to determine which computers in your organization are not compliant with Sarbanes-Oxley policies. Tivoli Provisioning Manager provides an empty SOX Group as a sample group. You must install the Tivoli Common Agent for this sample group because the Tivoli Common Agent is required to run security scans. For information about other prerequisites, see the prerequisite check list. You must ensure that the prerequisites for each compliance check are met. Related information Example: Running a Sarbanes-Oxley compliance report on page 853
Patch reports
Patch reports show successful and failed deployments of software and the status of patches, which include deployments in progress, not yet started, successful, failed, and submitted.
Report File Name tp_deploymentSummaryChart.rptdesign Description What is the status of all software deployments? Report Detail This report displays the status of software deployments has been deployed within a given date range. The status includes software deployments that have succeeded, have failed, have been Canceled, have been scheduled, or that are in progress.
tp_softwareDeployment.rptdesign
What is the status of software This report displays what deployments that ran on each software deployment ran on server? specific servers and the status of the software deployment. Optionally, this report can be filtered by the target deployment status. What is the status of patch deployments? Given a date range, this report displays how many patch deployments have been deployed successfully or have failed, have been Canceled or scheduled, or are in progress. This report displays the patch deployments that ran on specific servers. Optionally, this report can be filtered by the target deployment status. This report displays all patches in the data model. This report displays the servers that have patches approved for installation. This report displays whether Windows servers comply with the patch policy.
tp_patchdeploymentSummaryChart.rptdesign
tp_patchDeployment.rptdesign
What patch deployment ran on which servers?
tp_datacenterPatches.rptdesign tp_patchApproved.rptdesign
What patches are in the data model? What servers have patches approved for installation? Do Windows servers comply with the patch policy?
tp_patchComplianceForWindows.rptdesign
1193
Report File Name tp_patchMissing.rptdesign
Description What patches are missing on what servers?
Report Detail There are two tp_patchMissing.rptdesign reports, one for the TPMSERVERS application, one for the TPSWPATCH application. These reports display what patches are missing on what servers. You might have to generate request pages for each of these reports separately. This report displays the patches that are missing on Windows servers. This report displays servers that have patches installed.
tp_patchMissingForWindows.rptdesign
What patches are missing on what Windows servers? What servers have what patches installed?
tp_patches.rptdesign tp_patchesOnServers.rptdesign
What patches are installed on This report displays patches what servers (list by patch that are installed on servers. name)? What is the patch compliance This report displays the patch result of all provisioning compliance results of all servers? provisioning servers.
tp_ patchCompliance.rptdesign
Discovery Configuration reports

This report displays what objects were last scanned by a particular discovery configuration
Report File Name tp_objectsLastScanned.rptdesign Description What objects were last scanned by what discovery configuration? Report Detail This report displays what objects were last scanned by a particular discovery configuration.
tp_objectsDiscovered.rptdesign
What objects were discovered This report displays the by what discovery objects that were discovered configuration? by a particular discovery configuration. Optionally, this report can be filtered by the object type.
Provisioning Task Tracking reports

Task tracking reports show how many tasks have been started, displays the status and task information for the provisioning task target computers and target computer.
Report File Name tp_taskSummaryChart.rptdesign Description How many tasks are in a specific state? Report Detail This report displays a stack chart that shows how many tasks have been started on a given date. It also shows the status of those tasks; if they have completed, have failed, are cancelled, are still in progress, are scheduled, and so on.
1194
Report File Name tp_taskStatus.rptdesign
Description What is the status of all tasks?
Report Detail This report displays the status of all tasks or tasks of a specified status.
tp_pauseResume.rptdesign
What are the task targets and This report displays task the maintenance windows information for the information for each target? provisioning task target computers, as well as maintenance window information for each task target computer.
Provisioning Global Settings report

This report displays the users who are subscribed to events, including which events trigger notifications.
Report File Name tp_eventsUserNotifications.rptdesign Description What users have notification to what events? Report Detail This report displays the users who are subscribed to events, including which events trigger notifications.
Provisioning Workflows report

This report displays the history of all workflow runs. It shows the start and end times of each run as well as their current execution state.
Report File Name tp_workflows.rptdesign Description What workflows have run recently? Report Detail This report displays the history of all workflow runs. It shows the start and end times of each run as well as their current execution state.
Virtualization Management report

This report identifies the virtual servers that are installed on a specific host platform server.
Report File Name tp_virtualServers.rptdesign Description Report Detail
How many virtual servers are This report identifies the created on a specific host virtual servers that are platform server? installed on a specific host platform server.
1195
Other reports
This report displays the login history of the different users on the Tivoli Provisioning Manager server.
Report File Name tp_loginTrackingDetail.rptdesign Description What is the user history on the server? Report Detail This report displays the login history of the different users on the Tivoli Provisioning Manager server: v Users who logged on v Users who logged off v Times users logged on and off v The client on which users logged on and off It identifies user information such as login ID and login name. It identifies the result of the login attempt, for example, login, logout, restart, timeout. It also identifies the time stamp and client host from which the user performed the action.
Creating ad hoc reports

You can create custom ad hoc reports using predefined report object structures and report view objects. You can access the predefined report object structures and report view objects for several but not all provisioning applications. You can create ad hoc reports, also known as query based reports, for running reports on provisioning tasks and provisioning applications. Ad hoc reports are reports that you can create yourself for your individual business needs. Ad hoc reports are easy to create and you do not need advanced skills for accessing the database or for formatting the reports. You create ad hoc reports using the Tivoli Provisioning Manager UI and predefined report object structures and report object views. You can choose a format for ad hoc reports by exporting the results to a spreadsheet or PDF document. Normally, the ad hoc reports you create are used by few users or you can create them for personalized once-off use. If you plan to use a report again, you can save its configuration so that you can access it quickly the next time that you want to run it. You can allow others to run the report by selecting the Public? option or you can keep the report for your private use. To create ad hoc reports, you use predefined provisioning report object structures and report view objects. The report object structures and report view objects provide you with an easy way to query the Tivoli Provisioning Manager database to include columns in your report. However, for performance reasons, you need to be careful that you do not join too many report view objects. Including too many report view objects can have a significant impact on performance. When you are creating ad hoc reports you can choose to create summary reports and detailed reports. When you are creating summary reports you can select fields from only one view. You can group and sort summary report results. Detailed reports provide you with the capability to select fields from more than one view. Detailed reports are dynamically organized by categories.
1196
How to create reports

To create ad hoc reports you use report object structures and report view objects. You can access the report object structures and report view objects for creating ad hoc reports, as follows: v From the Reports menu item on the Start Center. From the Reports menu, you can select each of the provisioning applications that have the ad hoc report creation feature, as follows: Reports->Provisioning Reports->Discovery Configurations Reports->Provisioning Reports->Patches Reports->Provisioning Reports->Provisioning Computers Reports->Provisioning Reports->Provisioning Groups Reports->Provisioning Reports->Provisioning Task Tracking Reports->Provisioning Reports->Virtualization Management v From the Create Reports icon in the following provisioning applications: Discovery Configurations Patches Provisioning Computers Provisioning Groups Provisioning Task Tracking Virtualization Management v From the Select Action menu within applications, you can select Run Reports->Create Report for the following provisioning applications: Discovery Configurations Patches Provisioning Computers Provisioning Groups Provisioning Task Tracking Virtualization Management For more information about how to create ad hoc reports and ad hoc reporting features, see the Maximo Ad Hoc Reporting Guide. To locate this guide, go to http://www-01.ibm.com/software/sysmgmt/ products/support/IBMMaximoAssetManagement.html and search for the document reference number 1417471.
Example: creating an ad hoc report for patch management

If you want to create an ad hoc report for patch management, complete a procedure like the following one: 1. Click Go To > IT Infrastructure > Software Catalog > Patches. 2. Click the Create Report icon. The Query Based Report screen opens. The Reports screen opens and lists the existing patch management reports. Tip: You can also open the Query Based Report screen by selecting clicking Run Reports from the Select Action menu. 3. From the Style tab, select the Summary Report option and complete the following steps: v In the Report Title field, type the name of the report that you are creating, for example, What computers comply with patches policy?. v If you want to save the report, select the Save Report option. v To enable other users to view and run the report, select the Public? option. v To close the Query Based Reports screen when the report runs, select the Close option.
1197
4. Click the Select tab and complete the following actions: a. Select the Apply the Current Query and Filter from the Application? check box if you want to run the report based on the filter or query that has been applied for the application level. Each application can have a query associated with it or it can have a current filter to limit the object entries in that application. For example, you can filter by computer name, or sometimes status. Clear this check box to query everything in the view. If you select this check box you might get unexpected results. Unexpected results can occur because conditions might be appended from the application in which you are creating the report. If you get these unexpected results, they are displayed as a Dynamic Where Clause field in the report, followed by the query applied. b. From the report object structure tree, select TPSOFTWAREPATCH. The available fields for the TPSOFTWAREPATCH report object structure appear in the Available Fields list. c. Add Device model Id to the report by clicking the associated Select Field icon. Device model Id opens in the Selected Fields list. Note: The Selected Fields list might be pre-populated with default values. You can keep these values and add others or you can remove these values and add your own. From the report object structure tree, select the COMPLIANCE_PATCH_VIEW report view object. The available fields for the COMPLIANCE_PATCH_VIEW report view object appear in the Available Fields list. Click the Select Field icon for OS_NAME and OS_VERSION. OS_NAME and OS_VERSION appear in the Selected Fields list. Click the Select Field icon for IS_COMPLIANT. It is added to the Selected Fields list. Use the Column Order and Report Label fields to define the order in which you want the fields to appear on the report. To change the order and name for a field, select the field and change the value.
d.
e. f. g.
Note: If you are not sure about the properties for particular report object structures or report view objects, you can access descriptions from the Database Configuration screen. Click Go To > System Configuration > Platform Configuration > Database Configuration. In the Object field on the Database Configuration screen, type the name of the report view object for which you want a description and press Enter. The description is displayed on the screen. 5. Click the Format tab and arrange the appearance and formatting of the report. See the Maximo documentation for information about how to format your report. 6. Click the Submit tab to specify when you want to run the report and enter the values. See the Maximo documentation for information about how to enter values in the Submit tab. 7. Click the Submit button to run the report. Related concepts Chapter 14, Reports, on page 1187 Report object structures and report view objects
Report object structures and report view objects

You can create ad hoc reports for provisioning applications and provisioning tasks using predefined report object structures and report view objects. The predefined report object structures and report view objects provide high level access to several database tables that are commonly used for creating ad hoc reports in Tivoli Provisioning Manager provisioning applications. Report object structures and report view objects enable you to create ad hoc reports without writing SQL queries to the database. You can access predefined provisioning report object structures and report view objects to create ad hoc reports in provisioning applications. When creating ad hoc reports, you access the report object structures and report view objects to define the fields and columns that you want to include in your report. Report object structures contain predefined views from which you can select when creating reports. For each provisioning application that has ad hoc report functionality, there is one report object structure.
1198
Currently, not all provisioning applications have ad hoc reporting functionality enabled and therefore not all provisioning applications have corresponding report object structures. Report view objects are predefined views from which you can query and select columns. Report view objects are nested within a report object structure and you can only access report view objects from within a report object structure. Normally, there are several report view objects available within each report object structure. For each report view object, there are several fields that you can select for inclusion in your ad hoc report. The predefined report object structures and report view objects provide you with easy access to commonly used database objects within provisioning applications. Using the report object structures and report view objects, you can create custom ad hoc reports that provide you with the specific information that you require in your reports. When you create ad hoc reports in provisioning applications, you can select report view objects and combine them with other report view objects. You can access report object structures and associated report view objects for the following provisioning applications: v Provisioning Computers v Patches v Provisioning Task Tracking v Discovery Configurations You can access the report object structures and report view objects to create ad hoc reports, as follows: v From the Reports menu item on the Start Center. From the Reports menu, you can select each of the provisioning applications that have the ad hoc report creation feature, as follows: Reports->Provisioning Reports->Discovery Configurations Reports->Provisioning Reports->Patches Reports->Provisioning Reports->Provisioning Computers Reports->Provisioning Reports->Provisioning Task Tracking v Using the Create Reports icon in the following provisioning applications: Discovery Configurations Patches Provisioning Computers Provisioning Task Tracking v From the Select Action menu within provisioning applications, you can select Run Reports->Create Report for the following provisioning applications: Discovery Configurations Patches Provisioning Computers Provisioning Task Tracking
Accessing report object structure descriptions

To access information and descriptions about report object structures, complete these steps: 1. Click Go To->Integration->Object Structures. 2. In the Object Structure field, type the name of the report object structure for which you want a description. 3. Press Enter. The description opens.
1199
Accessing report view object descriptions

To access information about report view objects, such as descriptions of tables and their attributes, you use the Database Configuration screen. For example, if you access a report view object but do not know its function, you can view a description. To view a description, you need to access the Database Configuration screen and search for descriptions and information about the particular report view objects. To search for descriptions about report view objects, complete these steps: 1. Click Go To > System Configuration > Platform Configuration > Database Configuration.. 2. In the Object field, enter the name of the report view object for which you want to view a description. 3. Press the Return key. The description for the report view object opens.
Example: creating an ad hoc report using predefined report view objects

If you want to create an ad hoc report for the patches installed on a group of target computers, complete the following steps: 1. 2. 3. 4. 5. Access the Patches provisioning applicationClick Go To > Provisioning Reports > Patches.. Click Create Report. The Query Based Reports screen opens. From the Style tab, select the Summary Report option. Click the Select tab. Select the fields that you want to include in the report from TPSOFTWAREPATCH. You must select at least one field from TPSOFTWAREPATCH report object structure. 6. Click the COMPLIANCE_PATCH_VIEW report view object and select the fields that you want to include in the report. Repeat this procedure for the other report view objects. 7. Click the Format tab and include any filters that you want to include on the report. 8. Click the Submit tab to specify your options for running the report. 9. Click Submit to run the report. Related concepts Chapter 14, Reports, on page 1187 Creating ad hoc reports on page 1196 Running reports
Running reports
You can run predefined reports and ad hoc reports. You use the same procedure to run all reports, whether they are ad hoc reports that you created or predefined reports. Before you can run any reports, you need to generate the request pages for the report.
Prerequisites
Before you can run any predefined or newly imported reports, you need to generate request pages. You do this once for any report or you can generate the request page for all reports at one time. To generate request pages for reports, complete the following: 1. Click Go to->Administration->Reporting->Report Administration. 2. You can click Generate Request Pages to generate the request pages for all reports. Alternatively, if you want to generate the request page for a particular report, search for the report that you want to run. Then click on the report file name and click Generate Request Pages.
1200
Running ad hoc or predefined reports

The process for running predefined reports and ad hoc reports that you create is the same. Before attempting to run a report, make sure that you have generated the request pages for the report, as described in the previous section. Complete the following steps to run reports: 1. From the Start Center, select Reports->Provisioning Reports and the provisioning application for which you are running a report. For example, you can select Reports->Provisioning Reports->Discovery Configurations. Tip: Alternatively, you can select the provisioning application for which you are running the report, and use Select Action->Run Reports. The Reports dialog box opens. You can also select Reports->Provisioning Reports and select the application for which you want to run a report, for example, Reports->Provisioning Reports->Patches. 2. From the On Demand Reports tab, click the report that you want to run. The Request Page opens, from which you can specify parameters, scheduling, and export options for the report that you are running: v Use the Parameters section to specify the scope of the report. Click the Select Value icon to select the items that you want to include in the report. v In the Schedule section of the screen, select an option to specify when you want to run the report. If you want to run the report immediately, select the option for Immediate. If you choose to schedule the report, you need to type your e-mail address to receive the report by e-mail. You can specify the file type in which you want to receive the report, for example, as a spreadsheet. Note: You can get quick access to the Request Page for some reports by clicking the report name from the Favorite Reports section of the Start Center. However, the report that you want to run must be available from the Favorite Reports list in the Start Center. To add a report to the Favorite Reports list in the Start Center, click the associated Edit Portlet icon. The Report List Setup screen opens, from which you can add reports to the list. 3. In the Parameters section of the screen, click the Select Value icon. The Select Value screen opens. 4. In the Schedule section of the screen, select one of the options, depending on when you want to run the report. 5. In the Email section of the screen, you can use the Select Value icon to enter an e-mail address. You can also type a subject and comments and you can select the PDF or XLS option to export the file to PDF or spreadsheet format. 6. Click Submit. Note: If you cannot see a list of predefined reports in the Favorite Reports list in the Start Center, or if you cannot view one or more reports in the list, you might not have application level or report level security to view and run the report. For information about how to change the security settings, see the Security section of this guide and the IBM Maximo Asset Management V7 Reporting Feature Guide.
Example: running a discovery configuration report

Suppose you want to run a discovery configuration report. 1. Click Go To > Provisioning Reports > Discovery Configurations.. Note: For the Discovery Configurations provisioning application, the Favorite Reports section is not available. Therefore, you cannot select the discovery report that you want to run directly from the Favorite Reports section of the Discovery Configurations application. 2. From the Select Action menu, click Run Reports. The Reports dialog box opens and lists the available reports for the Discovery Configurations application. 3. Select the report that you want to run, for example, What computers were last scanned?. The Request Page screen opens.
1201
4. Click the Submit tab and specify the options for running the report. 5. Click the Submit button to run the report. The report runs. Related concepts Chapter 14, Reports, on page 1187 Report object structures and report view objects on page 1198
Reporting extended attributes

This sections suggests ways to report extended attributes Extended attributes, which are added by the user, can be reported in two ways: using the Properties table, or using the authorized configuration items. Related concepts Predefined reports on page 1190 Getting started with reports on page 1188
Extended attributes in the Properties table

To display user-extended attributes in reports using the Properties table, you need to do the following:
Procedure
1. Create a separate report that lists out all, or selected, extended attributes of a specified object. 2. Change a predefined report, for example, change the How many servers are in the data model? report to link to the separate report and pass the ID of the server to the separate report.
Example
The query of this report is shown below:
select from where and ; property, property_value object_properties_view dcm_object_id = ? property in (extended attribute name 1, extended attribute name 2, ...)
If you can impose a naming convention on the name of extended attributes, for example, always starting the naming with extended_, the report query can be simplified. With this simplified query, this report can be used to list all the extended attributes of any object.
select from where and ; property, property_value object_properties_view dcm_object_id = ? property like 'extended_
If you want to use extended attributes to group predefined reports, first copy the predefined reports and then change the SQL statement to join with the object_properties_view and select the properties that you want. Use the Business Intelligence and Reporting Tools (BIRT) report designer to add the extended attributes to the report and group on the extended attributes.
1202
Extended attributes in the authorized configuration item

The predefined Configuration Item (CI) Details report lists all the attributes, relationships, and so on, of all of configuration items. To list extended attributes using configuration items, do one of the following steps:
Procedure
1. Use the Configuration Item Details report to see all the extended attributes of all Configuration Items 2. Copy the Configuration Item Details report and change it to add a report parameter that accepts a Global Unique Identifier (GUID) string, and change an applicable predefined report to link to this changed report.
Example
For the second option, the SQL statement of the Configuration Item Details report needs to be changed as shown below:
select ci.status, ci.assetnum, ci.cinum, ci.description, longdescription.ldtext, ci.location, ci.itemnum, ci.assetlocsiteid, ci.assetlocorgid, ci.itemsetid, ci.service, ci.servicegroup, ci.classstructureid, ci.actcinum, ci.cilocation from ci, left outer join actci, on ci.actcinum = actci.cinum LEFT OUTER JOIN longdescription ON longdescription.ldownertable = CI and longdescription.ldownercol = DESCRIPTION where actci.guid=? ;
If you want to use extended attributes to group predefined reports, copy the predefined reports and change the SQL statement to join with following tables to select the Configuration Item attributes that you want: v actci on GUID v ci table on actcinum v cispec on cinum Also, use the BIRT report designer to add the extended attributes to the report and group on the extended attributes.
Business value key performance indicators

Tivoli Provisioning Manager provides key performance indicators (KPIs) for provisioning tasks. You can access these KPIs from the Start Center. The KPIs are displayed in a business value reports KPI that displays in a graph. You can customize the business value reports KPI for Start Centers for provisioning roles by adding or removing predefined provisioning KPIs. The KPIs also contain links to related reports, where relevant.
1203
Tivoli Provisioning Manager provides key performance indicators for the following: v Successful automation tasks (any provisioning task, per target computer) v Successful patch deployments v Successful software deployments v Successful servers provisioned (includes virtual servers created using Create Virtual Server and includes servers built by installing an operating system, for example, bare metal installations using Tivoli Provisioning Manager for Operating System Deployment) For software and patch deployments, the KPIs indicate the number of successful deployments per target computer. So if you completed a patch management task on 20 target computers, the KPI would display as 20 successful deployments.
Updating the Start Center

After installing Tivoli Provisioning Manager v7.2.0.1, you must update the Provisioning Administrator Start Center to load the KPIs. Note that after you update the Start Center, you cannot revert it to its prior state. If you have a customized Start Center, updating the Start Center overwrites the custom Start Center and you lose the custom Start Center. To avoid losing your custom Start Center, you can create a separate user account for updating the Start Center and viewing the KPIs. Alternatively, you can merge your customized template into the new template that you update with the KPIs. Complete the following steps to update the Start Center:
Procedure
1. Log on to the Tivoli Provisioning Manager web user interface. 2. Click the tab for the Provisioning Administrator. 3. Click Update Start Center. Note: You can only load the graph for the KPIs for the Provisioning Administrator Start Center. For each of the other provisioning roles, you manually add the graph for the KPIs. 4. Click Yes to confirm.
Results
The KPIs are loaded in the Start Center for the provisioning administrator and you can begin using them. You can refresh the data for any KPI by clicking Update. For any other provisioning role, you can manually add the graph for the KPIs.
Configuring the KPIs

You can customize the graphs for the KPIs that display in the Start Center for each of the provisioning roles, choosing the KPIs that you want to include in the Start Centers. You can add or remove business value KPIs for each of the provisioning roles. You can customize your KPI as follows:
Procedure
1. From the Start Center, click the provisioning role for which you want to add KPIs, for example, Deployment Specialist. 2. Add the business value KPI for the Deployment Specialist, as follows: a. Click Change Content/Layout. b. From the Right Column section, click Select Content.
1204
c. Click KPI Graph. d. Click OK. You return to the Start Center and the graph with the KPIs is displayed. 3. Click Edit Portlet to open the configuration screen, from which you can configure the KPIs. 4. Make changes to the KPI, as required: v To change the display name of the KPI, enter the name in the Display Name field. v To remove a task from the KPI list, click the Delete icon. v To add new tasks to the KPI list, click Select KPIs. From the dialog box that displays, search for and click the KPI that you want to include in the list. You can add any KPI to any role. v Click OK. 5. Click Finished.
Results
The KPIs that you want to include are displayed in the Start Center. Repeat this procedure for each of the other provisioning roles, as required.
Troubleshooting and Reporting problems

This section provides information about troubleshooting and describes how to recover from reporting problems. For information about how to enable logging for reporting, see the Maximo Report Logging Features guide. To access this guide, go to http://www-947.ibm.com/support/entry/portal/Overview/Software/ Tivoli/Maximo_Asset_Management and search for the document reference number 1423974.
Corrupted text when importing non-English CSV reports to Excel

CSV files are written in UTF-8 format, which is not currently supported in CSV format in Excel.
Symptoms
Reports that are exported to Comma Separated Values (CSV) file format can then be imported to spreadsheet applications, such as Microsoft Excel. When trying to import non-English CSV reports into Excel , the text becomes garbled.
Causes
CSV files are written in UTF-8 format (abbreviation for Universal Transformation Format). UTF-8 converts 16-bit unicode characters into 8-bit ASCII characters. Microsoft Excel does not currently support UTF-8 in CSV format.

CSV files are written in UTF-8 format to support multiple language scripts in a single report. CSV files can be imported into spreadsheet applications, but can also be imported into the database using custom applications. The following procedures are solutions that have been tested for various languages. In addition to these solutions, there are operating system and Excel requirements that must be met in order for the characters to be displayed properly. User response: Solution 1: 1. Open the <Report_name>.csv file in Notepad, and then save it as Unicode. Rename the file to <Report_name>_unicode.csv. 2. Open the <Report_name>_unicode.csv file in Excel. The Text Import Wizard is displayed: a. In the first step, select Delimited and ensure that all other options are clear.
1205
b. In the second step, clear Tab and select Comma. c. Click Finish before going to step 3. After performing the steps described previously, the CSV report can be opened in Excel with all characters displayed properly. Solution 2: 1. Open the <Report_name>.csv file in Notepad, and then save it as ANSI, renaming it to <Report_name>_ansi.csv. 2. Open the<Report_name>_ansi.csv file in Excel. The characters are properly displayed. Solution 3:You can convert the CSV file from UTF-8 to native encoding using a code conversion tool. You can use the native2ascii command line utility that is provided with the Java JDK toolkit. The tool can be found in the %WAS_HOME%/AppServer/java/bin directory. 1. Open a command prompt window, and change directories until you reach the location of the native2ascii tool. Alternatively, you can set the value of Path, the system variable for the operating system, to include the location of the Java JDK toolkit. 2. Enter the following command:
native2ascii -encoding UTF-8 <Report_name>.csv | native2ascii -reverse -encoding <Language_code> > <Report_name>_output.csv
where<Language_code> is the locale code for the language that you are interested in. For example, GB2312 is the code for simplified Chinese. 3. Open the <Report_name>_output.csv file in Excel. All characters are properly displayed. Instead of running the previous command more than once for converting more CSV files, you might want to create a script file that uses the command in step 2 and specifies the names of all the CSV files that require conversion. You can run the script to convert all the required files at once. In addition to the solutions described previously, the following operating system and Excel requirements must be met before the characters are displayed properly: Operating system requirements Try matching the language of the imported CSV report with the operating system language. For example, for Japanese, try importing the file on a computer that is running a Japanese operating system. If you cannot meet this requirement, set the user locale of your system to the language of your choice, so that you can use the standard settings for that language. To do this, perform the following steps: 1. Click Start > Settings > Control Panel, and then open Regional Options. 2. On the General tab, change the user locale to the language you are interested in. 3. Click OK. Excel requirements You can set the Microsoft Office language settings to the language of your choice by performing the following steps: 1. Click Start > Programs > Microsoft Office Tools > Microsoft Office XP Language Settings 2. On the Enabled Languages tab, set the Default version of Microsoft Office to the language of your choice. 3. Ensure that the language that interests you is on the Enabled languages list: a. In the Available languages list, click the language that interests you. b. Click Add to add the selected language to the Enabled languages list. c. Click OK.
1206
Garbled text displayed when exporting reports into CSV

The CSV report files use the UTF-8 encoding. When opening those reports with some commonly used applications, such as Microsoft Excel, non-readable characters appear.
Symptoms
Unknown characters appear when generating a report that contains double-byte characters (for example, Cyrillic, Chinese, or Japanese characters) after exporting the report as CSV file.
Causes
Some applications do not support UTF-8 encoding or open CSV files (that use UTF-8) using ASCII encoding, which results in garbled text being displayed.

Use an application that supports UTF-8 encoding, such as Notepad. Alternatively, open the CSV report using Microsoft Excel 2003. To open the report result file: 1. After the download is completed, change the file extension to .txt. Ignore the prompted warning. 2. Open the text file in Microsoft Excel 2003. 3. In the Text Import Wizard select Delimited in Original Data type, then select Unicode UTF-8 in File origin. 4. Click Next. 5. Specify the comma character as the file delimiter. 6. Click Finish. You can also change your Web browser language preferences to see the language display correctly. 1. In Internet Explorer, click Tools > Internet Options. 2. Click Languages > Add. 3. In the list, select the language that you want to add and click OK. 4. In the Language field, select the new language and click Move Up. Click OK and then close the Web browser. 5. Open the Web browser and log on to Tivoli Provisioning Manager. The new language will now be displayed in your Web browser.
Missing information when reports are saved in CSV format

Other result fields for a report are created in sub-reports under the top-level report. To see the report information in more detail, these sub-reports must also be saved in CSV format.
Symptoms
When you run a report that provides detailed information, only some of the results are printed in the exported report in Common Separated Value (CSV) format. For example, if you run the report called tp_serverDetails.rptdesign to see server details (including networking and other resource details) the exported CSV formatted report results only provide the server name and server ID details.
Causes
The other result fields for a report are created in sub-reports under the top-level report. In this example, the hardware resource and networking details are provided in the sub-reports.
1207
Error when importing reports

This error message is incorrect and can be disregarded.
Symptoms
Using the importreports.cmd command to import a report results in the error Unable to locate tools.jar.
Causes
An extra library is referenced in the environment script.

Disregard this error message. The importing of the report completes successfully even though you receive this error.
Microsoft Internet Explorer 7 hangs when viewing multiple report results

There is a memory leak in Microsoft Internet Explorer version 7 that will eventually cause it to hang if viewing many report results. Close and reopen the browser occasionally to avoid this.
Symptoms
Microsoft Internet Explorer version 7 hangs if you are using the Web browser to view multiple report results.
Causes
There is a memory leak in Microsoft Internet Explorer version 7. The memory usage of the iexplore.exe file grows even after you have closed the report results.

Close Microsoft Internet Explorer Internet Explorer version 7 occasionally if you are viewing many report results (to free up the leaked memory), or use Microsoft Internet Explorer version 6.
Cannot open report after generating request pages

The request pages did not generate properly if you cannot open the report. Check the log files and resolve any problems before generating the request pages again.
Symptoms
When you click Generate Request Pages, the action seems to perform correctly but you cannot open the report.
Causes
The request pages did not generate properly.

Check the SystemOut.log and SystemErr.log files on the MXServer. Resolve any database connection or other problems for the reports and then generate the request pages again.
1208
The logs are located in the following locations: SystemOut.log

Windows UNIX
:%WAS_HOME%\profiles\ctgAppSrv01\logs\MXServer
Linux
: $WAS_HOME/profiles/ctgAppSrv01/logs/MXServer
SystemErr.log
Windows UNIX
:%WAS_HOME%\logs\server1
Linux
: $WAS_HOME/logs/server1
Exported ad hoc report PDF file does not open

If you export the current page of a multi-page ad hoc report to PDF, the PDF file might be created incorrectly. When this occurs, the PDF file does not open and appears corrupted or as an unknown file type.
Symptoms
If you export the current page of an ad hoc report to PDF, the PDF file is corrupted and does not open.
Causes
When you generate an ad hoc report, the report that is created can span several pages. If you are not on the first page of the report when you attempt to export the report, and if the Current Page option is selected, the exported file might be corrupted. The page breaks in the report cause an invalid PDF file to be created.

To resolve the problem, export the entire report to PDF, rather than just the current page. To do this: v Navigate to the first page of the report. v Select Export Report and choose PDF as the export format. v Click All pages.
1209
1210
Chapter 15. Integrating with other IBM products

This section provides information for configuring integration with other IBM products. Additional integration scenarios are available in the Tivoli Provisioning Manager wiki
Configuring single sign-on with Tivoli Monitoring

Single sign-on (SSO) is the ability of a user to log on once and access multiple applications without having to log on to each application separately. It is multiserver session-based authentication that allows Web users to log on once to WebSphere Application Server, and then access any other WebSphere Application Server (in the same DNS domain) that are enabled for single sign-on without having to log in again.
Before you begin

Single sign-on requires configuration changes on both the Tivoli Provisioning Manager server and the Tivoli Monitoring server. Before you begin the configuration, ensure that both products are installed at the required version levels: v Tivoli Monitoring Version 6.2.2 v Tivoli Provisioning Manager Version 7.2 If you want the ability to start Tivoli Provisioning Manager from another product, such as Tivoli Monitoring, you must configure single sign-on. The following instructions are for configuring integration with Tivoli Monitoring 6.2.2.
Procedure
1. Check the directory server registry that you are using with Tivoli Provisioning Manager for the user wasadmin. If the user wasadmin exists in the LDAP registry, you must assign a different user as the application server administrator for Tivoli Provisioning Manager and then remove the wasadmin user. The wasadmin user name is in one of the Tivoli Monitoring repositories. If you do not remove wasadmin from your LDAP registry, you will have two wasadmin users when you configure Tivoli Monitoring to use the Tivoli Provisioning Manager LDAP server, and you will not able to access the Tivoli Enterprise Portal Server extended services (TEPS/e). To configure a new user as the Tivoli Provisioning Manager application server administrator and remove the existing wasadmin user: a. Log into the WebSphere Application Server console:
(http://host_name:port/admin)
Replace host_name with the host name of the Tivoli Provisioning Manager server and port with the port number for the console. The default port number is 9060. b. Click Security > Secure administration, applications, and infrastructure. c. Select the federated repository in Available realm definitions, and click Configure. d. Change the Primary administrative user name to another existing user in the directory server. For example, maxadmin. e. Click OK and then click Save to save the changes. You might be prompted to enter the password for the new administrator. f. Stop and restart WebSphere Application Server. You can do this by stopping and restarting Tivoli Provisioning Manager. g. Delete the wasadmin from LDAP registry with the following command
1211
ldapdelete -D "cn=root" -w "password" "cn=wasadmin,ou=users,ou=SWG,o=IBM,c=US"
2. The application server administrator for the agent manager must have the same user name and password as the application server administrator for Tivoli Provisioning Manager. If you changed the application server administrator in step 1, you must also change the application server administrator for the agent manager. a. Log on to the console for the agent manager profile with the existing administrator name and password. Use the user name and password for the original Tivoli Provisioning Manager server. b. Click Users and Groups > Manage Users. c. Search for the user name that you configured as the new Tivoli Provisioning Manager application server administrator. If the user does not exist, create the user. 1) Click Create. 2) Enter the user information. Specify the same user name and password that you configured for the new Tivoli Provisioning Manager application server administrator in step 1. 3) Save your changes. d. Click Security > Secure administration, applications and infrastructure. e. Select the federated repository in Available realm definitions, and click Configure. f. Change the Primary administrative user name to the new application server administrator user name. g. Click OK and then click Save to save the changes. You might be prompted to enter the password for the new administrator. h. In a command window, change to the agent manager profile directory. The default location is: WAS_HOME/profiles/casprofile/bin i. Stop and restart the agent manager profile with the following commands:
stopserver server1 -user old_user_name -password old_password startserver server1
UNIX Windows
./stopServer.sh server1 -user old_user_name -password old_password ./startServer.sh server1
old_user_name The original application server administrator user name for the agent manager profile. old_password The password for the specified user name. 3. Configure Tivoli Provisioning Manager for single sign-on. Detailed steps are available in the Tivoli Monitoring documentation. http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/ com.ibm.itm.doc_6.2.1/auth_cfg_ds_isclite.htm#auth_cfg_ds_isclite The following steps describe the high level configuration process: a. Enable the TEPS/e console and log on to the console by following the instructions in "Starting the TEPS/e administration console" at the previous link. Open the console in your browser with the following URL:
http://localhost:15205/ibm/console.
b. Click Security > Secure administration, applications, and infrastructure > Select Federated repositories > Configure > Manage repositories. c. Add a new repository. For the new LDAP repository, copy the values configured for the Tivoli Provisioning Manager LDAP repository in the Tivoli Provisioning Manager application server console. Note: To replicate the Tivoli Provisioning Manager LDAP configuration settings: 1) Log on to the Tivoli Provisioning Manager application server.
1212
d. e. f.
g. h.
2) Click Security > Secure administration, applications, and infrastructure. Select Federated repositories > Configure > Manage repositories. 3) Click the Tivoli Provisioning Manager repository identifier. 4) Copy the values in the configuration tab to the newly created LDAP repository on the TEPS/e console. Click OK and save the changes. Click Security > Secure administration, applications, and infrastructure > Select Federated repositories > Configure > Add base entry to realm. Select the new LDAP repository that you created and provide the distinguished name of the base entry. The default distinguished name is ou=SWG,o=IBM,c=US . Use the same value that is configured in the Tivoli Provisioning Manager application server console. Save the changes. Use the same realm name in the WebSphere Application Server federated repositories configuration of both Tivoli Monitoring and Tivoli Provisioning Manager. The Tivoli Provisioning Manager federated repositories configuration uses the ISMRealm realm name by default. To update the Tivoli Monitoring federated repositories configuration: 1) Click Security > Secure administration, applications, and infrastructure > Select Federated repositories > Configure. 2) Change the realm name to ISMRealm. Apply and save the configuration.
i. Click Security > Secure administration, applications, and infrastructure > Web Security > Single Sign-On (SSO). j. Enable the single sign-on and enter the domain name. For example, mydivision.mycompany.com. You must configure the same value in this field and in the next step in the Tivoli Provisioning Manager application server console. k. Save and restart the TEPS/e server. 4. Create a user in Tivoli Provisioning Manager LDAP registry. For detailed instructions on how to map a user, see: http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/topic/com.ibm.itm.doc_6.2.1/ auth_mapping.htm#auth_mapping 5. Configure Tivoli Provisioning Manager for single sign-on. a. Log on to Tivoli Provisioning Manager application server console. b. Click Security > Secure administration, applications, and infrastructure > Web Security > Single Sign-On (SSO). c. Enable the single sign-on and enter the domain name that you specified for Tivoli Enterprise Portal. d. Save the changes. e. Stop and restart WebSphere Application Server. You can do this by stopping and restarting Tivoli Provisioning Manager. 6. Export the LTPA keys from the Tivoli Provisioning Manager server. a. Log on to the Tivoli Provisioning Manager application server console. b. Click Security > Secure administration, applications, and infrastructure > Authentication mechanisms and expiration. c. Export the LTPA key. 7. Import the LTPA keys into the Tivoli Monitoring server. a. Copy the exported Tivoli Provisioning Manager LTPA key to the Tivoli Monitoring server. b. Start the TEPS/e administration console. c. Click Security > Secure administration, applications, and infrastructure > Authentication mechanisms and expiration. d. Import the LTPA key. e. Restart the Tivoli Enterprise Portal Server (TEPS) and the Tivoli Monitoring server.
Chapter 15. Integrating with IBM products
1213
8. On the Tivoli Monitoring server, go to Tivoli Enterprise Monitoring Services > Tivoli Enterprise Portal Browser. Right-click and then click Advanced > Edit variables. a. Double-click cnp.cookie.domain and enter the domain that you specified earlier. For example, mydivision.mycompany.com. Select the In Use check box and then click OK. b. Change the TEP Server Host name to the fully qualified host name. For example, tepserver.domainname Perform the same steps for the Tivoli Enterprise Portal desktop. Restart the Tivoli Enterprise Portal Server (TEPS) and the Tivoli Monitoring server. 9. To configure a link to a specific Tivoli Provisioning Manager object, you specify a URL with the Tivoli Provisioning Manager object ID and the name of the Tivoli Provisioning Manager application. If the Tivoli Provisioning Manager server name is not resolved with full domain name in Tivoli Enterprise Portal (the full domain name is visible in Tivoli Enterprise Portal), you must modify the URL in a browser view of Tivoli Enterprise Portal to use the same domain name that you configured earlier. Note: If the Tivoli Provisioning Manager server name is already resolved with full domain name in Tivoli Enterprise Portal, make sure that you use same domain name everywhere while configuring SSO. a. In the Tivoli Enterprise Portal navigation tree, click TPM server > Tivoli Provisioning Manager > Task > Task Details Workspace > properties > Browser view. b. Select Use Provided Location and replace DomainName with the correct domain name.
https://$TPMServer$.DomainName:9443/maximo/ui/?event=loadapp&value=tptask&uniqueid=$TPMTaskID$
c. Save the changes.
Results
Single sign-on is now configured.
Configuring integration with IBM Tivoli Storage Productivity Center

If you are using Tivoli Storage Productivity Center, you can configure integration with Tivoli Provisioning Manager for viewing a selected computer.
Before you begin

To configure the integration, you must make configuration changes on both the Tivoli Storage Productivity Center server and the Tivoli Provisioning Manager server. Ensure that the following requirements are met: v Tivoli Storage Productivity Center is installed. The following versions are supported: Version 3.3.2, Fix Pack 1 Version 4.1, Fix Pack 2 v Tivoli Provisioning Manager Version 7.2.0.2 is installed. v The Tivoli Storage Productivity Center automation package called IBMTPC.tcdriver must be installed. It is installed during Tivoli Provisioning Manager installation. v Java Web Start must be installed on the computer where you want to will be logging on to the Tivoli Provisioning Manager Web interface. Java Web Start is required to start the Tivoli Storage Productivity Center console. It is included with the Sun Java runtime environment. For details about downloading and installing Java Web Start, see http://java.sun.com/javase/technologies/desktop/javawebstart/ If you try to launch Tivoli Storage Productivity Center when Java Web Start is not installed, an error message is displayed and includes a link to download Java Web Start. v To perform configuration, you need the Tivoli Storage Productivity Center host name, IP address, port number, and user name and password.
1214
Note: Tivoli Storage Productivity Center Version 3.3.2, Fix Pack 1 does not support single sign-on. The first time that you launch a Tivoli Storage Productivity Center console instance, you must specify the user name and password. Required roles: To view in a Tivoli Provisioning Manager computer in Tivoli Storage Productivity Center, your user account in each product must be associated with a role that has appropriate permissions. Tivoli Provisioning Manager Any role. Tivoli Storage Productivity Center Any of the following roles: v Superuser v Productivity Center Administrator v Data Operator v Data Administrator When the integration is configured, you can select a computer in Tivoli Provisioning Manager and then view details about the computer in Tivoli Storage Productivity Center.
Procedure
1. If you are using Tivoli Storage Productivity Center Version 4.1 Fix Pack 2, configure the product for single sign-on. a. Open the Tivoli Integrated Portal in a Web browser:
http://tpc_hostname:16310
where tpc_hostname is the host name of the computer where Tivoli Storage Productivity Center is installed. b. Log on as a user with administrative privileges. c. Click Security > Secure administration, applications, and infrastructure > Web Security > Single Sign-On. Verify that single sign-on is enabled and a valid domain name is configured. d. Click Security > Secure administration, applications, and infrastructure > Authentication mechanisms and expiration. e. In 1) 2) 3) the Cross-cell single sign-on section, enter the following information: Enter and confirm a Tivoli Integrated Portal key file password of your choice. Enter a Tivoli Integrated Portal name of your choice. Click Export Keys.
f. Log out of the Tivoli Integrated Portal. 2. If you are using Tivoli Storage Productivity Center Version 4.1 Fix Pack 2, configure Tivoli Provisioning Manager for single sign-on. a. On the provisioning server, log on to the WebSphere Application Server administrative console.
http://host_name:port/admin
Replace host_name with the host name of the provisioning server and port with the port number for the console. The default port number is 9060. b. Log on as a user with administrative privileges. c. Click Security > Secure administration, applications, and infrastructure > Web Security > Single Sign-On. Verify that single sign-on is enabled and that the domain name matches the one you used to configure single sign-on for Tivoli Storage Productivity Center.
1215
d. Verify that the same LDAP relam name is configured for both Tivoli Provisioning Manager and Tivoli Storage Productivity Center. 1) Click Security > Secure administration, applications, and infrastructure. 2) Under Account Repository, click Configure. 3) Under General Properties verify the Realm name. e. Click Security > Secure administration, applications, and infrastructure > Authentication mechanisms and expiration. f. In the Cross-cell single sign-on section, enter the following information: 1) Enter and confirm the Tivoli Integrated Portal key file password. 2) Enter theTivoli Integrated Portal key file name. 3) Click Import Keys. g. Log out of the WebSphere Application Server administrative console. h. Restart Tivoli Provisioning Manager. 3. Define the Tivoli Storage Productivity Center server in Tivoli Provisioning Manager by running the provisioning workflow TPC_DefineTPCServer.wkf. You must perform these steps for each Tivoli Storage Productivity Center that you want to add to Tivoli Provisioning Manager. a. Click Go To > Administration > Provisioning > Provisioning Workflows. b. Search for TPC_DefineTPCServer in the list. c. From the Select Action menu, click Run. d. Select the provisioning workflow . e. Provide the following parameters and then click Run. hostname The host name of Tivoli Storage Productivity Center Server. ipaddress The IP address to use for communication with the Tivoli Storage Productivity Center Server. portnum The port number to connect to the Tivoli Storage Productivity Center Device server. The default is 9550. username The user name that has Superuser privileges on the Tivoli Storage Productivity Center server. password The password to match the provided user name. The provisioning workflow defines a new Tivoli Storage Productivity Center server as data model object in Tivoli Provisioning Manager and the server is added to the TPC Servers group. It stores the user name and password in a new service access point (SAP). The SAP is used by the Tivoli Storage Productivity Center discovery for communicating with the Tivoli Storage Productivity Center server. The default device server HTTPS port (9551) and data server port (9549) are stored as variables of the Tivoli Storage Productivity Center server object. 4. Ensure that Tivoli Storage Productivity Center is running so that it can be discovered. 5. Run TPC discovery to populate the Tivoli Storage Productivity Center data, such as storage subsystems, storage pools, fabrics, and managed computers, in Tivoli Provisioning Manager. To run TPC Discovery: a. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. b. In the list of discovery configurations, click TPC Discovery. c. Click Run Discovery. d. Select the Tivoli Provisioning Manager as the target server of the discovery and then click Submit.
1216
Each managed computer that TPC Discovery adds to Tivoli Provisioning Manager has a property called ManagedByTPCServer associated with it. The value of this property is be the IP address of the Tivoli Storage Productivity Center management server. When launching the Tivoli Storage Productivity Center console from the Tivoli Provisioning Manager, the value of ManagedByTPCServer is used to find the Tivoli Storage Productivity Center server that manages the selected computer. If the message "An unexpected deployment error occurred" is displayed, verify that Tivoli Storage Productivity Center is running and then try the discovery again. 6. If Tivoli Storage Productivity Center device sever and data server are not using the default ports (9551 and 9549 respectively) you must modify the variables that define the ports. These ports are used in the URL that launches the Tivoli Storage Productivity Center console. a. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. If you have Provisioning Configuration Librarian authority, you can also launch the Provisioning Computers application directly from the Favorite applications portlet in the Start Center. b. Search for the host name of the Tivoli Storage Productivity Center, and then click the computer in the list. c. Click the Variables tab. d. Update the values for the DeviceServerHTTPSPort and DataServerPort variables with the correct values for the HTTPS device server port and data server port. The link to the Tivoli Storage Productivity Center console from this computer is now configured. 7. To view storage details for a selected computer in the Tivoli Storage Productivity Center console, perform the following steps: a. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. If you have Provisioning Configuration Librarian authority, you can also launch the Provisioning Computers application directly from the Favorite applications portlet in the Start Center. b. Search for the computer that you want to view and then click its name in the list. The computer must be a computer that is managed by Tivoli Storage Productivity Center. Computers that are managed by Tivoli Storage Productivity Center have a ManagedByTPCServer variable defined on the Variables tab of the computer. The variable identifies the Tivoli Storage Productivity Center server that manages the computer. c. From the Select Action menu, click Select > Open Storage Management Server Console. Note: The Open Storage Management Server Console action is only visible for computers managed by managed by the Tivoli Storage Productivity Center server (computers that have the ManagedByTPCServer variable). The process to launch the Tivoli Storage Productivity Center console starts. The URL to launch the console is created using the computer host name and the values for the variables ManagedByTPCServer (Tivoli Storage Productivity Center server name), DeviceServerHTTPSPort (device server port), and DataServerPort (data server port). The following steps occur to launch the console: a. The Tivoli Storage Productivity Center console is started with Java Web Start. b. Java Web Start connects to the Tivoli Storage Productivity Center device server. c. Java Web Start downloads the SSL certificate and displays a message that asks if you want to accept and trust the device server Web site. d. To continue, click OK to accept and trust the Web site. The Web browser downloads TSRMgui.jar to start the console. e. If you are prompted to log on, specify the user name and password that you configured in step 3 on page 1216. The first time you launch a Tivoli Storage Productivity Center Version 3.3.2 session, you must log on. If you launch the same console instance again, you are not prompted to log on. Note: Tivoli Storage Productivity Center launch in context does not support single sign-on. Tivoli Storage Productivity Center credentials must be provided to log into Tivoli Storage Productivity
1217
Center when you launch it from Tivoli Provisioning Manager for the first time. You can find out more information about which role you can use to log on: Required Roles The console is displayed with the storage information for the selected computer. Note: If the computer record was deleted from Tivoli Storage Productivity Center, a blank page is displayed. This is a known limitation of Tivoli Storage Productivity Center.
Launching Tivoli Provisioning Manager from other products

If you want to create a link to a specific Tivoli Provisioning Manager application. Tivoli Provisioning Manager provides support to link to a specific object. Launching an application for any object Tivoli Provisioning Manager has generic application tpdcmfind for linking to the any object except those managed by the Provisioning Task Tracking and Provisioning Workflow Status applications. The tpdcmfind application determines the type of the object and redirects to the specific application that manages the object. Launching objects for Provisioning Task Tracking and Provisioning Workflow Status applications For these applications, you must specify the application name and the object in the launch URL. v For linking to the Provisioning Task Tracking application, use the application name tptask v For linking to the Provisioning Workflow Status application, use the application name tpwfstat There are several link formats that you can use.
Procedure
v To display a specific object, you can launch Tivoli Provisioning Manager object ID. Use the following format: For a secure HTTP connection:
https://host_name:port/maximo/ui/?event=loadapp&value=application_name&uniqueid=object_id
For a regular HTTP connection:

http://host_name:port/maximo/maximo/ui/?event=loadapp&value=application_name&uniqueid=object_id
host_name The Tivoli Provisioning Manager is installed. application_name The name of application to launch. For provisioning task and activity plan objects managed by Provisioning Task Tracking, use the application name tptask For provisioning workflow objects managed by Provisioning Workflow Status, use the application name tpwfstat For all other objects, use the application name tpdcmfind dcm_object_id The object ID in the data model of the object that you want to display. You must specify a valid application name and a valid object that is managed by the application. The following example shows the URL to display an object with the ID 3293:
https://tpmserver.example.com:9443/maximo/ui/?event=loadapp&value=tpdcmfind&uniqueid=3293
The link displays the main tab of the specified object. v To display a set of objects based on specific attribute values, you can launch Tivoli Provisioning Manager using a primary Maximo business object attribute name and value pairs in the format:
1218
For a secure HTTP connection:

https://host_name:port/maximo/ui/?event=loadapp&value=application_name&additionalevent=useqbe&additionaleventvalue =attribute_name=attribute_value,attribute_name=attribute_value

http://host_name:port/maximo/ui/?event=loadapp&value=application_name&additionalevent=useqbe&additionaleventvalue =attribute_name=attribute_value,attribute_name=attribute_value
host_name The Tivoli Provisioning Manager is installed. application_name The name of application to launch. For provisioning task and activity plan objects managed by Provisioning Task Tracking, use the application name tptask For provisioning workflow objects managed by Provisioning Workflow Status, use the application name tpwfstat For all other objects, use the application name tpdcmfind, but you can only provide the search criteria on persistent attributes of the Maximo business object TPDCMOBJECT. If you want to provide search criteria on attributes other than the Maximo business object TPDCMOBJECT or you want to list out only specific type of objects then you must use the specific application which must have the type of object you are searching for as primary Maximo business object. For information about the relationship between data model objects and the corresponding applications, see Data model object to application mapping on page 1221. attribute_name Name of the persistent attribute of the primary Maximo business object of the application. attribute_value The value of the attribute You must specify a valid application name and valid attribute names and values that are managed by the application. The following example shows the URL to display all objects with the name sun-fire-280-1:
https://tpmserver.example.com:9443/maximo/ui/login?event=loadapp&value=tpdcmfind&additionalevent =useqbe&additionaleventvalue=Name=sun-fire-280-1
This URL redirects to the List tab of the specified application and lists objects that meet the specified attribute values. To list specific a type of the object, you must use the specific application name. For example, to list all computers with the name sun-fire-280-1, the Provisioning Computers (tpservers) application is included in the URL because that application manages computer objects.
https://tpmserver.example.com:9443/maximo/ui/login?event=loadapp&value=tpservers&additionalevent =useqbe&additionaleventvalue=Name=sun-fire-280-1
This example shows how to list all the software products from specific vendor. In this situation, TPDCMOBJECT does not have VENDOR as a persistent attribute, so you cannot use the tpdcmfind application. Instead, you must use specify the tpsoftware application that manages software objects.
https://tpmserver.example.com:9443/maximo/ui/login?event=loadapp&value=tpsoftware&additionalevent =useqbe&additionaleventvalue=VENDOR=IBM
v To display a set of objects, you can also launch Tivoli Provisioning Managerby providing a SQL query in the URL: For a secure HTTP connection:
https://host_name:port/maximo/ui/?event=loadapp&value=application_name &additionalevent=sqlwhere&additionaleventvalue=sqlWhereClause

http://host_name:port/maximo/ui/?event=loadapp&value=application_name &additionalevent=sqlwhere&additionaleventvalue=sqlWhereClause
1219
host_name The Tivoli Provisioning Manager is installed. application_name The name of application to launch. For provisioning task and activity plan objects managed by Provisioning Task Tracking, use the application name tptask For provisioning workflow objects managed by Provisioning Workflow Status, use the application name tpwfstat For all other objects, use the application name tpdcmfind, but you can only provide the search criteria on persistent attributes of the Maximo business object TPDCMOBJECT. If you want to provide search criteria on attributes other than the Maximo business object TPDCMOBJECT or you want to list out only specific type of objects then you must use the specific application which must have the type of object you are searching for as primary Maximo business object. For information about the relationship between data model objects and the corresponding applications, see Data model object to application mapping on page 1221. sqlWhereClause A SQL expression that uses a standard SQL where clause. You must specify a valid application name and SQL query. The following example shows the URL to display all computers with name sun-fire-280-1 in the Computer application:
https://tpmserver.example.com:9443/maximo/ui/login?event=loadapp&value=tpservers&additionalevent =sqlwhere&additionaleventvalue=Name=sun-fire-280-1
This URL redirects to the List tab of the specified application and lists objects that meet the specified SQL expression. v To launch to an application in portlet mode so that the Go To menu and other menus on the header bar are not accessible, add the parameter &portalmode=true. The following examples show this parameter:
https://tpmserver.example.com:9443/maximo/ui/login?event=loadapp&value=tpdcmfind&additionalevent =useqbe&additionaleventvalue=Name=sun-fire-280-1&portalmode=true https://localhost:9443/maximo/ui/?event=loadapp&value=tpdcmfind&uniqueid=1058&portalmode=true
Results
When you launch the Tivoli Provisioning Manager web interface using the previous URLs, you will be prompted for user credentials. You must supply credentials with the appropriate privileges for the application you are launching.
Creating and using change windows

You can specify a time period when configuration items can be out of service so that changes can be made to them. Users who administer computers can then view the change window so that they are aware of when changes are permitted.
Before you begin

The ability to see a change window associated with Tivoli Provisioning Manager managed computers is only available if you used Tivoli Provisioning Manager to discovery the computers with Tivoli Application Dependency Discovery Manager as the discovery technology. When the computers are discovered, a globally unique identifer (GUID) is used to link the Tivoli Provisioning Manager data model object that represents the computer with the corresponding configuration item that represents the computer in Change and Configuration Management Database. Tivoli Provisioning Manager does not enforce a change window.
1220
Procedure
1. Click Go To > Change > Change Window. 2. Add a change window. For instructions see the Change and Configuration Management Database information center. 3. After the change window is configured, perform the following steps to view the change window from a managed computer: a. Click Go To > Deployment > Provisioning Computers. b. Search for the computer you want to view and then click its name in the search results. c. Next to Configuration Item, click computer. d. Next to Change Window, click to view the corresponding configuration item for this to view the change window.
Results
The change window is displayed.
Data model object to application mapping

For setting up linking to an application using a URL, use the table to identify the application associated with a data model object.
Table 213. data model object APPLICATION CLUSTER COMPUTER SWITCH LOAD_BALANCER SPARE_POOL SUBNETWORK VLAN CUSTOMER DEVICE_MODEL FILE_REPOSITORY POWER_UNIT BOOT_SERVER SAN TERMINALSERVER SOFTWARE_STACK BLADE_ADMIN_SERVER ACL SOFTWARE_PATCH DISCOVERY UnknownIpDevice VIRTUAL_SERVER_TEMPLATE Description Application Application tier Computer Switch Load balancer Resource pool Subnetwork Virtual LAN Customer Device driver File repository Power unit Boot server Storage Area Network Terminal server Software stack Blade chassis server Access control list Software patch Discovery types Unknown IP device Virtual server template Application name TPAPPL TPCLUSTER TPSERVERS TPSWITCHS TPLDBAL TPRESPOOL TPSUBNETS TPVLANS TPCUST TPDEVMOD TPFILEREP TPPOWERU TPBOOTSRV TPSAN TPTERMSRV TPSTACK TPBLADE TPACL TPSWPATCH TPDISC TPUNKRSRC TPVST
1221
Table 213. (continued) data model object VOLUME_MANAGER STORAGE_ALLOCATION_POOL SAN_FRAME SERVER_TEMPLATE SOFTWARE_MODULE IMAGE CLUSTER_DOMAIN STORAGE_TEMPLATE SOFTWARE_RESOURCE SOFTWARE_INSTALLATION SOFTWARE_INSTANCE SOFTWARE_CONFIGURATION SOFTWARE_APPLICATION_DATA GROUP COMPUTER_GROUP DCD_MANAGEMENT_CENTER Description Volume manager Storage allocation pool Storage Subsystem Computer template Software definition Image Cluster domain Storage template Software resource Software installation Software instance Software configuration Software application Data Group Computer Group Object that represents the dynamic content delivery management center Application name TPSTGMGR TPSTPOOL TPSTSUBST TPCMPTMPL TPSOFTWARE TPIMAGE TPCLSTDMN TPSTGTMPL TPSWRES TPSWRES TPSWRES TPSWRES TPSWRES TPGROUP TPGROUP TPDCD
Example: Adding attribute information manually

This topic provides information about adding attributes that are input by the user and not obtained on the environment. For example, the physical location of a server, owner or custodian of a server, or telephone number of the owner.
Before you begin

Before you can perform the steps in this example, you must follow the procedures for extending the CCMDB model covered in Chapter 4.2: Extending the model in IBM Tivoli CCMDB Implementation Recommendations. When the data model linking is in place, the Tivoli Provisioning Manager Web interface can be modified to include these added attributes from the linked configuration items. You can use the following guides for reference while you are performing these steps: v Application Developer's Guide. General information about the web interface v System Administrator Guide. Information about database configuration. First, you must add the new property to the application Web interface, then you need to add a new property to the application itself:
Procedure
1. For this extension mechanism to work a valid configuration item (CI) must be linked to the business object. For example, the TPSERVER object has a Global Unique Identifier (GUID) attribute which enables the linking to exist between the TPSERVER and the CI. When this link is established a relationship named CI must exist and point to a valid CI instance. A business object defines an object in Tivoli Provisioning Manager. So, for a computer that is the TPSERVER business object. For a SWITCH, it is the TPSWITCH business object.
1222
2. Add a new attribute following the steps described detailed in section 4.2.2 of the IBM Tivoli CCMDB Implementation Recommendations document. The new attribute, to store the name of the owner, must be named, for example, OWNERNM (using the Attribute field) and have a Data Type of ALN. 3. Add a new relationship to the CI object: a. Go to the Database Configuration application ( Go to > System Configuration > Platform Configuration > Database Configuration ) and filter on the TPSERVER object. b. Click the Relationships tab, then click New Row. c. In the Relationship field, type CISPECOWNERNM d. In the Where Clause field, type refobjectid=:ciid and ASSETATTRID=OWNERNM, where OWNERNM is the attribute name you assigned in step 2. e. In the Child Object field, type CISPEC. f. In the Remarks field, type Owner Name Relationship. For more information, see the Application Developer's Guide 4. You must determine which application needs to be changed. In this case it is the TPSERVERS application which is based on the TPSERVER business object. Go to the Application Designer (Go to > System Configuration > Platform Configuration > Application Designer) and search for the TPSERVERS application using the Find. 5. Select TPSERVERS, then click the Workspace tab, then the Computer tab. 6. Using the Control Palette, create a text entry field where you expect to see the owner details. For more information about the Control Palette, see the Application Developer's Guide. 7. Right-click the new text box and click Properties, then in the Attribute field, type CI.CISPECOWNERNM.ALNVALUE. to save your changes. 8. Click 9. Configure the database. For more information, see Database Configuration in the System Administrator's Guide. 10. If you configured the database using Admin Mode, you must restart Tivoli Provisioning Manager for the changes to take effect.
Results
You are now done adding the new attribute. The next time you use the application there will be a field where you can enter or modify the last update time information.
What to do next
This attribute is editable on all objects where the configuration item has the new attribute. For configuration items that do not yet have it, you navigate to the configuration item application and add the new attribute to be editable on the TPSERVERS application.
Example: Adding discovered type information

This example contains information about obtaining attributes from a target computer during the discovery or execution of Tivoli Provisioning Manager workflows. Sample attributes are the last time an operating system was updated at a router or if a Solaris target computer is in a global or local zone.
Before you begin

You can use the following guides for reference while you are performing these steps: v Application Developer's Guide. General information about the web interface
1223
v System Administrator Guide. Information about database configuration. Regardless of what variables you are obtaining, the same capabilities for modifying object properties are available in the Variables tab for your target computers. The following example provides information about how to access more visualization and editing capabilities than are available on the Variables tab. The general steps involved in accessing more capabilities are:
Procedure
1. First, you must use the database configuration application to add a relationship to the TPDCMOBJECTPROPERTY business object. The relationship must be named <KEY_NAME>_REL and must have a where clause as follows: DCM_OBJECT_ID = :ID and COMPONENT_ID = 7 and KEY_NAME = <KEY_NAME>. 2. Define a non-persistent attribute in the business object for this new field. The attribute must be defined as same as TPDCMOBJECTPROPERTY.VALUE and the attribute must be named <KEY_NAME>. You must add the class name com.ibm.tivoli.tpm.maximo.fieldvalidators.FldPropertyExtender to the attribute. 3. Because you changed the database configuration, you must to run the configdb command . This operation requires a shutdown and restart of Tivoli Provisioning Manager. For more information about configdb, refer to the System administrator guide. 4. Use the application designer to add the new field to your application. The attribute is <KEY_NAME>. The FldPropertyExtender class handles the creation of the DcmObjectProperty entry when a new value is entered and the Mbo is saved. This property also appears in the Variables tab for the object.
Results
You are now done adding the new attribute. The next time you use the application there will be a field where you can enter or modify the last update time information.
Example
You want to add a new property LAST_UPDATE_TIME to all server objects. To perform this action, (so that the last update time might be referenced in workflows), you want to be able to edit the DcmObjectProperty in the Web interface directly and not always use the Variables tab. This property can also be populated by a custom discovery workflow: 1. You first need to determine what object this property needs to be related to. In this case it is the TPSERVER object. So navigate to the Database Configuration application by clicking Go to > System Configuration > Platform Configuration > Database Configuration and search for the TPSERVER object. 2. Click the Relationships tab, then the New Row button. 3. In the Relationship field, type LAST_UPDATE_TIME_REL. 4. In the Child Object field, type TPDCMOBJECTPROPERTY. 5. In the Where Clause field, type DM_OBJECT_ID = :ID and COMPONENT_ID = 7 and KEY_NAME = 'LAST_UPDATE_TIME. Note: 7 is the ID for the user-defined component. There are several components IDs that could be used such as 0 which is used for the entire system. Also, if the key_name is unique across all components for the particular object ID, then KEY_NAME is not required in the WHERE clause. to save your changes. 6. In the Remarks field, type Last Update Time relationship and click 7. You are now going to create a non-persistent attribute. Click the Attributes tab, then click New Row 8. In the Attribute field, type LAST_UPDATE_TIME. 9. In the Title field, type Last Update Time. 10. In the Description field, type Last Update Time.
1224
11. In the Class field, type com.ibm.tivoli.tpm.maximo.fieldvalidators.FldPropertyExtender. 12. In the Same as Object field, type TPDCMOBJECTPROPERTY. 13. In the Same as Attribute field, type VALUE. 14. 15. 16. to save this change. Click The status of the TPSERVER object is now To Be Changed, which requires the configdb command to be run. See the System Administrator Guide for details Now you need to determine which application needs to be changed. In this case it is the TPSERVERS application which is based on the TPSERVER business object. Go to the Application Designer (Go to > System Configuration > Platform Configuration > Application Designer) and search for the TPSERVERS application using the Find field. Select TPSERVERS, then click the Workspace tab, then the Computer tab. Using the Control Palette, create a text entry field where you would like to see the last update time details. For more information about the Control Palette, see the Application Developer's Guide. Right-click the new text box and click Properties. In the Attribute field, type LAST_UPDATE_TIME. to save your changes.
17. 18. 19. 20.
21. Click
What to do next
This new DcmObjectProperty could then be used in any workflow using the DCM Query language.
<INSERT SAMPLE WF CODE HERE!> Get the Property Value (See the Get_DCM_Property WF) Property_Value = DCMQuery(/dcmobject[@id=$DCM_Object_ID]/property[@componentid=7 AND @key=$Property_Name]/@value) Set the Property Value (See the Set_DCM_Property WF) var propertyID = DCMQuery(/property[@key=$Property_Name AND @componentid=$Component_Id AND @dcmobjectid=$DCM_Object_ID]) if Jython(not propertyID) then DCMInsert parent = DCMQuery(/dcmobject[@id=$DCM_Object_ID]) <<EOI <property component="$componentName" name="$Property_Name" value="$Property_Value" description="$Property_Description" /> EOI #-else DCMUpdate parent = DCMQuery(/property[@id=$propertyID]) <<EOU <property component="$componentName" name="$Property_Name" value="$Property_Value" description="$Property_Description" /> EOU #-endif
Managing events with Tivoli Enterprise Console

An event is a significant change in the state of a system resource, network resource, or network application. An event can be generated for a problem, for the resolution of a problem, or for the successful completion of an operation. Tivoli Enterprise Console is a rule-based event management application that enables you to centralize the collection and processing of events from different sources. If you have purchased this product and installed it in your enterprise environment, you can:
1225
v Set up Tivoli Provisioning Manager to send workflow failure events to Tivoli Enterprise Console. Sending these events enables you to centralize management of provisioning workflow failure errors, as well as errors from other management systems in your enterprise environment. v Configure Tivoli Enterprise Console to run SOAP commands. In Tivoli Provisioning Manager, you can create rules to associate an event with a SOAP script. For example, you can set up a rule to change a server status to failed when Tivoli Enterprise Console receives a server failure event. When Tivoli Provisioning Manager sends an event to Tivoli Enterprise Console, it includes the following information in the event: v Name of the provisioning workflow v Deployment request ID v Error number v First 32 characters of the error message v IP address of the Tivoli Provisioning Manager server as the source of the error v logical management operation that failed v First four parameters passed to the provisioning workflow v Date and time of the error If a child provisioning workflow in a hierarchical provisioning workflow fails, an event is only sent for the parent provisioning workflow. If Tivoli Provisioning Manager cannot connect to the Tivoli Enterprise Console server, all exceptions are captured and a message is recorded in the message log to indicate the error.
Example of provisioning workflow failure event

1~613~1~1078513589(Mar 05 13:06:29 2004) ### EVENT ### TIO_WORKFLOW_EXCEPTION;source=9.41.21.113; workflow_request_id=11860;second_param eter_name="DeviceID";workflow_name="test1"; workflow_exception="COPDEX040E An unexpected deploym";logical_operation_name="Software.Install"; first_parameter_value ="121212";second_parameter_value="1212";first_parameter_name="SoftwareID"; workflow_exception_message="Error Code = COPDEX040Eunexpecte";END ### END EVENT ### PROCESSED
Customizing attributes for TEC events

Dynamic information in a TEC event results in more specific error reporting. A simple edit to the file, $TIO_HOME/config/tec-event-customer-info.xml, allows you to modify the fully qualified host name and Java class attributes. Replacing this information helps to process SOAP commands that can be issued back to the provisioning server as a recovery action. Attribute values are completely changeablethey merely depend on what attributes you would like to add to the TEC event.
Table 214. Setting dynamic attribute values
Static information <customized-info> <name>fqhostname</name> <value>FULL_HOST_NAME</value> </customized-info> Dynamic information <customized-class> <class_name>com.ibm.tivoli.orchestrator.tec.DummyTecEventExtension</class_name> </customized-class>
Implement the interface for the Java class from the relevant provisioning workflow error. Only replace the class name. Note: All modifications must be made by IT support or service team members.
Event logging when event transmission fails

There are two log files that record information about Tivoli Enterprise Console events when event transmission fails: Tivoli Enterprise Console cache and Tivoli Provisioning Manager log file.
1226
Tivoli Enterprise Console cache If you enable the Tivoli Enterprise Console cache, the cache stores events when communication with the event server or IBM Tivoli Enterprise Console gateway fails. The name and location of this file is defined in the tivoli.send.conf configuration file that you use to configure the Tivoli Provisioning Manager server to send events. If BufferEvents=YES, the parameters to look for are BufferEvents and BufEvtPath for the location of buffered events. Tivoli Provisioning Manager log file The console.log file stores all event logs for the Web interface including messages, traces, and debugging information. It records information about failures in sending events to Tivoli Enterprise Console. The default location for this log file is: v
Windows
%TIO_LOGS%\j2ee v
UNIX
or
Linux
$TIO_LOGS/j2ee
Configuring Tivoli Provisioning Manager to send events

Tivoli Enterprise Console is a rule-based event management application that enables you to centralize the collection and processing of events from different sources. You must properly configure both the Tivoli Provisioning Manager server and the IBM Tivoli Enterprise Console server before you can enable the transmission of workflow failure events to Tivoli Enterprise Console. When Tivoli Provisioning Manager sends an event to Tivoli Enterprise Console, it includes the various information in the event such as the workflow name, deployment request ID, and error number. To use Tivoli Provisioning Manager with Tivoli Enterprise Console, you must edit a configuration file to specify where to send workflow failure events. To modify settings in the Tivoli Enterprise Console configuration file:
Procedure
1. Switch to the %TIO_HOME%\config directory, where %TIO_HOME% is the Tivoli Provisioning Manager installation directory. 2. Open the tivoli.send.conf file in a text editor. 3. Edit the parameters as described in the file. For integration with Tivoli Provisioning Manager, ensure that you check the following settings: ServerPort (Windows only) If Tivoli Enterprise Console is running on a Windows server, the ServerPort setting is the port number on which the Tivoli Enterprise Console server is listening for events. Look for this line in the configuration file:
ServerPort=5529
The default value is port 5529. Verify that the port setting is correct and uncomment the line. BufEvtPath BufEvtPath must specify the path name of the file which will contain cached Tivoli Enterprise Console events if the Tivoli Enterprise Console server is shut off.
1227
Server Location Server Location specifies the host name of the server on which the Server Location server resides. This is set to the Tivoli Provisioning Manager server by default, and must be changed if the Tivoli Enterprise Console server is on a different server. For more information about activating and filtering the cache, refer to the Tivoli Enterprise Console Event Integration Facility Reference. This guide is available in theTivoli Enterprise Console information center.
Results
You have now modified the configuration file to enable caching of workflow events, and set a path file name for the cache file.
What to do next
Next, you must configure Tivoli Enterprise Console to receive workflow events.
Setting up Tivoli Enterprise Console

If you are using Tivoli Enterprise Console, you can set up rules for performing actions in response to events. You can use this capability to run workflows in response to specified events. Each rule that you create can point to a script with the SOAP commands for performing the required task in Tivoli Provisioning Manager. For example, you can set up a rule that changes the status of a server to failed in response to a server failure event. To set up the Tivoli Enterprise Console server and Tivoli Provisioning Manager server:
Procedure
1. Set up the Tivoli Enterprise Console server so that it can run SOAP commands remotely. For details about running SOAP commands from another server, see the Reference section of the information center. 2. Create an .sh or .cmd script to perform actions that you want to occur in response to an event. The script must contain each SOAP command that you want to run. 3. Create a rule in Tivoli Enterprise Console to start the script that you created. The rule defines the event and corresponding value that starts the script. For example, you can identify a specific device state or threshold value to automatically trigger the script. For details about creating a rule, refer to the Tivoli Enterprise Console documentation. You can obtain the documentation from the Tivoli software information center.
Configuring Tivoli Enterprise Console to receive workflow events

In Tivoli Enterprise Console, rule bases define information that is required to automatically process events. To enable Tivoli Enterprise Console to process workflow failure events, you must load a rule base that contains the event class definition for Tivoli Provisioning Manager workflow events. Tivoli Provisioning Manager includes the required event class file, tio_workflow_exception.baroc. You can create a rule base specifically for the Tivoli Provisioning Manager event class, or you can add the Tivoli Provisioning Manager event class to an existing rule base. For more information about rule bases, refer to the Tivoli Enterprise Console Rule Developer's Guide. You can obtain the documentation from the Tivoli software information center.
1228
Note: The Tivoli Enterprise Console server must be at the 3.9.1 (Fix Pack 1) product level to properly manage events. To load the event class:
Procedure
1. Copy the event class file from the Tivoli Provisioning Manager server to the Tivoli Enterprise Console server. The file is named tio_workflow_exception.baroc and is located in the %TIO_HOME%\config directory. 2. From the command line on the Tivoli Enterprise Console server, create a rule base, or identify an existing rule base that you want to use. v To create a rule base with the name tioRuleBase, type wrb -crtrb tioRuleBase. v To view a list of existing rule bases, type wrb -lsrb. 3. Import the event class into the rule base. Type wrb -imprbclass path/tio_workflow_exception.baroc rulebase where path is the full path to the event class file. rulebase is the name of the rule base. 4. Compile the rule base. Type wrb -comprules rulebase. 5. Load the rule base. Type wrb -loadrb rulebase. 6. Restart the Tivoli Enterprise Console server.
Results
You have copied the workflow event class definition to Tivoli Enterprise Console, imported it into the appropriate rule base, and then loaded the rule base.
Enabling and disabling the transmission of workflow failure events

After you have configured the Tivoli Provisioning Manager and Tivoli Enterprise Console servers, you can enable or disable the transmission of events when a workflow fails. To enable or disable the transmission of workflow failure events:
Procedure
1. Click Go To > Administration > Provisioning > Provisioning Global Settings. 2. Click the Variables tab. 3. Add a variable to integrate Tivoli Enterprise Console. a. In the Key field, type Send TEC Events on workflow failures for the variable name. b. In the Component, click Deployment engine. c. In the Value field, type true to enable the transmission of events, or type false to disable the transmission of events.
Results
You have now enabled or disabled the transmission of workflow failure events.
Automating tasks using process workflows

New with Tivoli Provisioning Manager 7.2.0.2 (Fix Pack 2) IF00001, the runbook automation integration ensures an easy task automation using out-of-the-box, customizable process workflows.
1229
The runbook automation enables you to initiate provisioning tasks through process workflows from a Maximo instance. The Maximo instance can be either remote or on the same server as Tivoli Provisioning Manager. The remote instance is recommended, as it minimizes dependencies and decouples the provisioning engine from the process engine. The integration with Tivoli Provisioning Manager is ensured through the web services. The runbook automation integration provided with Tivoli Provisioning Manager is designed to address workflow development challenges such as: v Java programming or Jython scripting skills required to integrate with Tivoli Provisioning Manager from the process workflow. v Very difficult maintenance and debugging of Java code or Jython scripts. v Packaging of the custom Java code required to redeploy the maximo.ear file. v Support for a local Tivoli Provisioning Manager instance only. Support for a remote instance requires new action classes. v Manual and error-prone mapping of Tivoli Provisioning Manager parameters to the ISM process specification attributes. To address these challenges, the runbook automation provides: v Efficient, consistent, and fast management of manual and automated process through process workflows. v Out-of-the-box process workflows to demonstrate the top-down ISM integration from service catalog to the automation tasks in Tivoli Provisioning Manager. v A library of best-practice provisioning workflows and scripts to add to the overall ISM process. No Java or Jython code is required. v Automation of repetitive tasks associated with the IT operation process, by providing reusable action libraries that can be shared between processes. v An end-to-end solution that seamlessly integrates service ticket opening, management of service requests, work order setup, process workflow implementation and execution, and verification of successful provisioning. The following diagram illustrates the high-level architecture of the runbook integration provided with Tivoli Provisioning Manager 7.2.0.2 IF00001:
1230
Tivoli Process Automation Engine
Tivoli Service Request Manager
Tivoli Process Automation Engine applications Tivoli Provisioning Manager runbook automation adapter - Process Manager Product package
Web services
Deployment Engine
- Exchange data - Map data center model objects Call provisioning workflows
Data center model database
Runbook automation
Managed end points
...
See the related links to learn more about the runbook automation process, the required user roles and requirements, and the available tasks. Related reference User roles and requirements on page 1238 Software requirements on page 1239
Runbook automation basics

Find out more about the runbook automation process, the key terms and examples, and the main user roles that participate in the runbook automation. Review the troubleshooting information for this feature and additional resources that help you to complete your runbook automation tasks. v Process on page 1232 v v v v v v User roles on page 1232 Requirements on page 1233 Key terms on page 1234 Troubleshooting on page 1234 Log files on page 1234 Resources on page 1235
1231
Process
Process A typical automation process using process workflows is depicted in the following diagram:
1. Installing the runbook automation adapter package
2. Configuring the runbook automation adapter
3. Generating artifacts
Legend
Provisioning Administrator Workflow Designer Change Manager
4. Building process workflows
5. Running process workflows
To initiate the Default_Device_Copy_File provisioning workflow from a process workflow, and copy a file to a target computer, complete the following steps: 1. Generate the ISM process artifacts. 2. Build a process workflow that includes the provisioning task Device_Copy_file. 3. Run the process workflow from the work order. 4. Verify that the execution of the process workflow completes successfully.
User roles
User roles
1232
Table 215. User roles Role Provisioning Administrator (Tivoli Provisioning Manager) Description v Installs the Tivoli Provisioning Manager client PMP on a remote Maximo instance. v Configures the ISM instance to point to the Tivoli Provisioning Manager 7.2.0.2-IF00001 instance. v Runs the cron task to synchronize the data model objects from the Tivoli Provisioning Manager instance. Skills v Knowledge of Tivoli Provisioning Manager provisioning workflows and provisioning tasks v Knowledge of provisioning workflow parameters and configuration details
v Generates the ISM process artifacts from Tivoli Provisioning Manager custom provisioning workflows (if required) Workflow Designer (Maximo) v Builds process workflows (using the Tivoli Provisioning Manager-provided process and action libraries) v Knowledge of Tivoli Provisioning Manager provisioning workflows generated artifacts and usage v Familiarity with process workflows, workflow designer, and process flow customization
Work Order Change Manager or Process Operator (Maximo)
v Familiarity with service catalog, configuration, and process v Assigns the Tivoli Provisioning workflow execution Manager-generated classification to the work order. v Knowledge of operational side of provisioning tasks v Sets the specification attribute values in the work order v Executes the process workflow against the work order v Verifies the successful completion of the provisioning tasks
v Creates work orders
Requirements
Requirements v Software requirements on page 1239
1233
Key terms
Key terms activity plan Activities are actions performed on a set of targets at specified times. automation package An installation unit that consists of the scripts, provisioning workflows, documentation and Java files for a particular device or software package. provisioning workflow A provisioning workflow represents the real implementation of a specific IT process. Provisioning workflows interact with related components to provide automated provisioning. process workflow The structured sequence of provisioning tasks that are used to implement a specific change, release, or other process, including both automatic and manual routing and tracking of records for approval and other tasks. The process workflows represent the real implementation of the runbook integration of Tivoli Provisioning Manager and Maximo. SOAP SOAP is a specification for the exchange of structured information in a decentralized, distributed environment. Certain Tivoli Provisioning Manager internal properties and methods are available using SOAP commands.
software package A software package contains a description of the actions that need to be executed on the target system. Depending on the software package format, the software package can also contain the files and resources necessary to perform the actions. web services 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. work order A record that contains information about work that must be performed for an asset, location, configuration item, and so on.
Troubleshooting
Troubleshooting v Troubleshooting the runbook automation on page 1249 v Runbook automation problems and limitations on page 1250 v Troubleshooting provisioning workflows
Log files
Log files v Runbook automation log files on page 1249 v Viewing provisioning workflow logs v ../com.ibm.support.tpm.doc/logs/rtrblog_workflowlog.dita
1234
Resources
Resources To learn more about runbook automation, refer to one of the following resources: v Automating tasks using process workflows on page 1229 v Runbook automation process v ITNCMIntegration automation package
Related links Automating tasks using process workflows on page 1229 Runbook automation process Troubleshooting the runbook automation on page 1249
Runbook automation process

The runbook automation process includes installation, configuration, and troubleshooting procedures. Prerequisites Before proceeding with the runbook automation, ensure that the requirements are met and you have the appropriate user roles to perform the runbook tasks. See Requirements on page 1238. The runbook automation process includes: 1. Installing the runbook automation adapter PMP package on page 1240 2. Configuring the Tivoli Provisioning Manager runbook automation adapter on page 1241 3. Generating process workflow artifacts on page 1245 4. Building process workflows on page 1247 5. Running process workflows on page 1248 See the related links for more information about the requirements, user roles, and access permissions required to perform runbook automation tasks. To troubleshoot runbook automation problems, see Troubleshooting the runbook automation on page 1249. The following scenarios provide more implementation details for the runbook automation. v Scenario 1: Creating a virtual machine v Scenario 2: Getting a new customer started on page 1237 For a sample implementation, see the documentation for the ITNCMIntegration automation package.
Scenario 1: Creating a virtual machine

The following business process diagram illustrates a runbook automation scenario for a virtual machine (VM) creation:
1235
Start
Request Approval
Stop Workflow
Number of Existing Servers <5
Build Server from Template
Stop Workflow
Help Desk Manager Approval
Server Build Team
Update Server with Software (Including Patches)
Certify Server and Notify User
End
The runbook automation scenario for the virtual machine (VM) creation includes the following steps: v A request for a virtual machine is submitted. It must be approved before it is processed further. v After the request is approved, it is sent to the server build team to: Build the server. Install the additional software, including patches. Note: : These steps can be performed in one automated step, or they can be independent steps ). leveraging different tools ( Certify that the server is ready. v The record exits the New virtual machine (VM) order process. v If the request follows a standard template (with less than five existing servers), it can be approved by the Purchase Approver and routed to the server build team. The following user roles can participate in this scenario:
Table 216. Runbook user roles for the virtual machine creation scenario Role Server Administrator Patch Administrator Application Administrator Description Sets up the server using a standard installation. Scans for and applies the patches required by the company policy. Installs additional applications. Works with the License Administrator to get the required licenses.
License Administrator Works with the Application Administrator to get the appropriate licenses.
1236
Scenario 2: Getting a new customer started

The following business process diagram illustrates the getting started scenario:
Assign IP Address Space(s) and VLANs
Start
Infrastructure Manager
Network Group Subprocess for New Customer
Agreement Signed?
Server Group Subprocess for New Customer
Stop Workflow
Close Agreement Pending
Create Work Suborder
Create VM Subprocess
The runbook automation scenario for getting a new customer started includes the following steps: v A new agreement for server hosting is signed by the customer. A request for a virtual machine is submitted. The agreement must be signed before the request is processed further. v A request for the assignment of a VLAN and an IP address range to this customers machines is sent to an Infrastructure Manager. v The VLAN and the IP address range are assigned to the customer by the Infrastructure Manager. ) v The assigned VLAN is sent to the network group to: ( Add the VLAN to the network switches and to the router. Create the default gateway and DNS records v A request is sent to the server group to add the VLAN to the hypervisor virtual switch. ( v The process described in the Scenario 1: Creating a virtual machine on page 1235 is called ( verify the basic network connectivity from the customer VLAN. The following user roles can participate in this scenario: ) ), to
1237
Table 217. Runbook user roles for the getting started scenario Role Infrastructure Manager Network Administrator Server Administrator Server Administrator Patch Administrator Application Administrator Description Manages the assignment of VLANs and IP address ranges. Configures switches, routers, and DNS servers. Configures virtual switches on the hypervisor. Sets up the server using a standard installation. Scans for and applies the patches required by the company policy. Installs additional applications. Works with the License Administrator to get the required licenses.
License Administrator Works with the Application Administrator to get the appropriate licenses.
Related tasks Installing the runbook automation adapter PMP package on page 1240 Configuring the Tivoli Provisioning Manager runbook automation adapter on page 1241 Generating process workflow artifacts on page 1245 Building process workflows on page 1247 Running process workflows on page 1248 Troubleshooting the runbook automation on page 1249 Related reference User roles and requirements Software requirements on page 1239
Requirements
Before you start working with the Runbook automation, ensure that you meet all requirements.

To perform runbook process automation tasks, ensure that you have the required knowledge and access rights to perform your role.
Table 218. User roles Role Provisioning Administrator (Tivoli Provisioning Manager) Description v Installs the Tivoli Provisioning Manager client PMP on a remote Maximo instance. v Configures the ISM instance to point to the Tivoli Provisioning Manager 7.2.0.2-IF00001 instance. v Runs the cron task to synchronize the data model objects from the Tivoli Provisioning Manager instance. Skills v Knowledge of Tivoli Provisioning Manager provisioning workflows and provisioning tasks v Knowledge of provisioning workflow parameters and configuration details
v Generates the ISM process artifacts from Tivoli Provisioning Manager custom provisioning workflows (if required)
1238
Table 218. User roles (continued) Role Workflow Designer (Maximo) Description v Builds process workflows (using the Tivoli Provisioning Manager-provided process and action libraries) Skills v Knowledge of Tivoli Provisioning Manager provisioning workflows generated artifacts and usage v Familiarity with process workflows, workflow designer, and process flow customization
Work Order Change Manager or Process Operator (Maximo)
v Familiarity with service catalog, configuration, and process v Assigns the Tivoli Provisioning workflow execution Manager-generated classification to the work order. v Knowledge of operational side of provisioning tasks v Sets the specification attribute values in the work order v Executes the process workflow against the work order v Verifies the successful completion of the provisioning tasks
v Creates work orders
Related concepts Automating tasks using process workflows on page 1229 Runbook automation process on page 1235
Ensure that you are using the supported software at the required levels for the runbook automation.
Software requirements for runbook automation

To perform runbook automation tasks, ensure that the following requirements are met. On the provisioning server v Tivoli Provisioning Manager version 7.2.0.2 (Fix Pack 2) IF00001 v Maximo Base Services version 7.1.1.8 v Maximo Base Services 7.1.1.8 hotfix installed v (Optional) CCMDB version 7.1.1.8 On the remote ISM system v Maximo version 7.1.1.8 v IBM Tivoli Service Request Manager version 7.2.1 v Runbook (Advanced Workflow Components) version 7.2.1 (installed with Service Request Manager 7.2.1) v The Tivoli Provisioning Manager runbook automation adapter PMP package installed. See Installing the runbook automation adapter PMP package on page 1240. v (Optional) CCMDB version 7.1.1.8
1239
Related concepts Automating tasks using process workflows on page 1229 Runbook automation process on page 1235
Customizing the length of the ACTION attribute

In the Maximo database, the default length of the ACTION attribute is set to 30 chars. To accommodate action names that include longer provisioning workflow names, you can customize this length to a higher value, for example, 200.
Before you begin

Before proceeding with customizing the length of the ACTION attribute, ensure that you have made a backup of the database. To customize the length of the ACTION attribute:
Procedure
1. Click Go To > System Configuration > Platform Configuration > Database Configuration. 2. On the List tab, search for the ACTION object, and click its name. 3. Click the Attributes tab of the ACTION object, then select the ACTION attribute. 4. Update the Length value to 200 (recommended). 5. Click Save to save the change and apply the setting.
Results
You have finished customizing the length of the ACTION attribute to accommodate longer action names.
What to do next
After you have customized the length of the ACTION attribute, ensure that you update the change in the database, by completing the following refresh steps on the Maximo administrative workstation: 1. Go to <WAS_HOME>\AppServer\profiles\ctgAppSrv01\bin. 2. Enter the command: stopServer MXServer -username <wasadminuser> -password <wasadminuser_password> 3. Go to c:\IBM\SMP\maximo\tools\maximo. 4. Enter the command: dropbackup 5. Enter the command: configdb 6. Go to <WAS_HOME>\AppServer\profiles\ctgAppSrv01\bin. 7. Enter the command: startServer MXServer Next: Installing the runbook automation adapter PMP package
Installing the runbook automation adapter PMP package

The provisioning administrator installs and configures the Tivoli Provisioning Manager runbook automation adapter PMP on the IBM Tivoli Service Request Manager instance.
Before you begin

Before proceeding with the runbook automation adapter installation: v Ensure that your ISM system meets the Software requirements on page 1239.
1240
v Perform the attribute customization procedure described in the Customizing the length of the ACTION attribute on page 1240 topic. v Ensure that you have a system or database backup. The runbook automation adapter PMP can be installed either on the remote IBM Tivoli Service Request Manager instance or on the same location where both Tivoli Provisioning Manager and IBM Tivoli Service Request Manager are running on the same instance. The process to install the runbook automation adapter PMP package uses the tpm_rbadptr_pmp_7.2.0.zip PSI installable. To install the runbook automation adapter PMP:
Procedure
1. Download the runbook automation adapter PMP from https://www-304.ibm.com/support/ docview.wss?uid=swg24030496 to your IBM Tivoli Service Request Manager administrative workstation. 2. Run the following file: MAXIMO_HOME\bin\solutionInstallerGUI.bat (.sh for UNIX). 3. Select to install the tpm_rbadptr_pmp_7.2.0.zip PMP package. 4. Follow the wizard instructions for license agreement and middleware credentials. 5. Review the installation options, then click OK to install the package.
What to do next
After the PMP installation is complete, a one-time setup (initial configuration) is required, to ensure that the Service Request Manager client and the runbook instance can work with Tivoli Provisioning Manager 7.2.0.2-IF00001 through the web services. See Configuring the Tivoli Provisioning Manager runbook automation adapter. Related concepts Runbook automation process on page 1235
Configuring the Tivoli Provisioning Manager runbook automation adapter

After the installation of the Tivoli Provisioning Manager runbook automation adapter is complete, a number of configuration procedures are required to set up the runbook automation adapter to communicate with Maximo through the web services. This initial configuration is required only once. To perform the initial configuration procedures, log on as a provisioning administrator to the administrative workstation of the Maximo instance. The configuration procedures include: v Activating escalation on page 1242 v (Optional) Setting up the logging level on page 1242 v Enabling logging for custom scripts on page 1242 v Setting up the web service end point on page 1243 v Activating the cron task on page 1243
1241
Related concepts Runbook automation process on page 1235 Related information Changing end point location requires database objects removal on page 1252
Activating escalation
The escalation condition is used to retrieve the status of the provisioning workflows from the Tivoli Provisioning Manager server. By default, escalation is checked every 30 seconds, but can be customized. When you activate the escalation, you ensure that the status of the provisioning workflows can be retrieved from the provisioning server. To activate the escalation, as a provisioning administrator:
Procedure
1. Click Go To > System Configuration > Platform Configuration > Escalations. 2. On the Escalation tab, search for the TPA_ACTIONS escalation. 3. Click Select Action > Activate/Deactivate Escalation. 4. Click Save to save the change and apply the setting.
Results
Escalation is now activated, which enables you to retrieve the status of the provisioning workflows from the provisioning server.
(Optional) Setting up the logging level

As a workflow designer, if you want to be able to troubleshoot any runbook automation adapter problems, you must set the logging level to DEBUG. By default, it is set to ERROR. Setting the logging level to DEBUG ensures that you can identify and retrieve troubleshooting information from runbook automation adapter log files. To set up the logging level for troubleshooting purposes:
Procedure
1. Click Go To > System Configuration > Platform Configuration > Logging. 2. In the Logger list, change the log level for the TPA logger from ERROR (default) to DEBUG. to save the change. 3. Click Save 4. Click Select Action > Apply Settings to apply the changes.
Results
The logging level is now set to DEBUG, which enables you to access log information to use for runbook automation adapter troubleshooting purposes.
Enabling logging for custom scripts

To be able to view useful logging information about your provisioning workflows on the Workflow Designer (Advanced) page, you must enable the logging for custom scripts. Logging information such as the provisioning task ID, action details, etc. is not provided by default, and the corresponding fields are empty on the Worfklow Designer (Advanced) page. To enable the logging for custom scripts:
1242
Procedure
1. Click Go To > System Configuration > Platform Configuration > System Properties. 2. Under Global Properties, search for rba. 3. In the list, select the rba.log.enableCustomScriptLogging property. The details for the selected property are displayed under Global Properties Details. 4. Set the Global Value of the rba.log.enableCustomScriptLogging property to 1. to save the change. 5. Click Save 6. Click the check box to select the property name. 7. Click Select Action > Live Refresh to apply the property update.
Results
The logging is now enabled for custom scripts.
Setting up the web service end point

You must also set up the web service client to point to your Tivoli Provisioning Manager SOAP server on which all the provisioning tasks in your process workflows are run. Once set up, the process workflows can run automation provisioning tasks remotely. To set up the web service end point:
Procedure
1. Click Go To > Integration > End Points. 2. On the End Points page, search for the name of the end point, TPMWSEP, and select it. 3. Under Properties for End Point, update the properties with the following information: v HOSTNAME: Enter the host name of the web service end point. For example, vm-tpm-s218.tpmserver.example.com. v USERNAME: Type the Maximo administrative user name, for example, maxadmin. v PASSWORD: Type the maxadmin password. Its encrypted value is displayed as you type. v PROTOCOL: Set to HTTPS. If set to another value or left unspecified, HTTP is used. Note: If the protocol is set to HTTPS, see Configuring HTTPS on page 1244 for more information about setting up the certificate. v UI_PORT: Set the port number for the Tivoli Provisioning Manager web interface, for example, 9443. v WS_PORT: Set the port number for the web services to the secure port, for example, 8777. 4. Click Save End Point .
Results
You have finished setting up the web services end point.
Activating the cron task

The cron task is used as a data model (DCM) object synchronization tool. When you activate the cron task, it synchronizes the DCMObjects data between Tivoli Provisioning Manager and the Maximo data model. The cron task copies the subset contents of the table (DCMObject ID, object type, GUID, object name, etc.) from the provisioning server to the Service Request Manager machine. By default, the cron task is run once an hour, but its schedule can be customized as required.
1243
To activate the cron task:
Procedure
1. Click Go To > System Configuration > Platform Configuration > Cron Task Setup. 2. On the Cron Task tab, search for the cron task you want to activate, TPADBSYNCCRONTASK. 3. Select the Active check box for the cron task. 4. Click Save to save the change and apply the setting.
Results
Once activated, the cron task synchronizes the data model objects between Tivoli Provisioning Manager and Maximo. You have now finished configuring the Tivoli Provisioning Manager runbook automation adapter to communicate with Maximo through the web services.
What to do next
Generating process workflow artifacts on page 1245
Configuring HTTPS
The communication initiated from IBM Tivoli Service Request Manager to Tivoli Provisioning Manager can be configured to use SSL. The following configuration steps are provided for server authentication only. First, the Service Request Manager truststore must be identified for server authentication. Before the certificate can be imported into the truststore, you must identify the virtual host and the port that are used by the Service Request Manager. Identifying the virtual host: To identify the virtual host: Procedure 1. Log on to the WebSphere administrative console in Service Request Manager. 2. Click Applications > Enterprise Applications > MAXIMO. 3. Click Virtual hosts to display the virtual hosts used by the Maximo application. 4. Note down the name of the virtual host, maximo_host. Identifying the ports for the virtual host: The virtual host name that you have just identified is required for the following port identification procedure. To identify the ports for the virtual host: Procedure 1. Log on to the WebSphere administrative console in Service Request Manager. 2. 3. 4. 5. Click Environment > Virtual Hosts. Select the virtual host identified earlier, maximo_host. Click Host Aliases. A table displays the virtual hosts and the corresponding ports. Note down the port numbers.
1244
Results Identifying the truststore and importing the certificate: To identify the truststore and import the certificate into the truststore: Procedure 1. Log on to the WebSphere administrative console in Service Request Manager. 2. Click Servers > Application servers > MXServer > Ports. 3. Select the port to be used, for example, 9443. 4. Click View associated transports next to the 9443 port. The SSL Enabled status for the selected port must be Enabled. 5. Click WCInboundDefaultSecure. 6. SSL configuration (Centrally managed) is specified under SSL inbound channel (SSL 2). Click SSL inbound channel (SSL 2). 7. Click View centrally managed SSL tree. 8. Under Inbound, click the link for ctgCell01(CellDefaultSSLSetting,null). 9. Click Key stores and certificates. The truststore in use is identified as CellDefaultTrustStore. 10. Click CellDefaultTrustStore > Click Signer certificates. 11. Click Retrieve from port. 12. Fill in the following information to retrieve the certificate from the Tivoli Provisioning Manager server: v Host: The provisioning server host name. v Port: The SOAP SSL port for the provisioning server, for example, 8778. v Alias: Enter tpmuicert. Note: If port 8778 is not enabled on the SOAP server, you can try specifying 9443, which is the web interface port of the provisioning server. Both ports use the same certificate for the SSL communication, for example, tpmuicert. 13. Click Retrieve signer information. On the Configuration page, retrieved signer information such as Serial number, Issued to, Issued by, Fingerprint (SHA digest), and Validity period is displayed. 14. Click Apply, then click Save. The certificate is imported. 15. Synchronize the deployment managers repository with the nodes repository: a. Click System administration > Nodes. b. Select ctgNode01, then click Full Resynchronize. A confirmation for the successful synchronization of the two repositories is displayed. The certificate is now successfully imported into the truststore. 16. Restart the Service Request Manager. Results You have finished configuring HTTPS to ensure secure communication between Tivoli Provisioning Manager and IBM Tivoli Service Request Manager.
Generating process workflow artifacts

As a prerequisite to building your own process workflow, as a provisioning administrator, you must first generate all the required artifacts and provisioning workflow actions.
1245
Before you begin

Before proceeding with the artifact generation, ensure that: v The Tivoli Provisioning Manager runbook adapter is already installed and configured to enable communication with Maximo through the web services. Artifacts include elements that are required for the specified provisioning workflows, such as classification, specifications, attributes, domain, actions in the action libraries, Jython script, etc. The generated actions are defined by the selected provisioning workflows. After logging in to the Maximo instance with the runbook adapter installed with Maximo administrator privileges (maxadmin), you can use the Process Artifact Generator application to generate the required artifacts for your process workflow. To generate the process workflow artifacts:
Procedure
1. Click Go To > Integration > Provisioning > Process Artifact Generator. The Process Artifact Generator application is displayed. 2. Click Select Workflows. The Select Provisioning Workflows dialog is displayed. 3. On the Select Provisioning Workflows dialog, select one or more provisioning workflow names, then click OK. You can repeat this step to add more provisioning workflows to the list. To remove any workflow from the list, click Remove on the corresponding row. 4. If required, you can set up the configuration parameters for the selected provisioning workflows. For each parameter, the following options can be used: v Default Value: Enabled when DCMObjectLookup is not selected. Type in a value for your parameter, or use the default value. This value will be populated in the attribute value of the work order. v Description: (Optional) The parameter description. If provided, the description is displayed in the attribute value in the work order. v DCMObjectLookup: This option is to find a DCMObject ID by name, it is selected by default. Note: If a workflow parameter is a DCMObject ID that identifies a computer, a switch, a group, a software product, a software stack, a software module, a server group, a virtual server template, or a discovery, it is recommended that you select the DCMObjectLookup check box. This enables the artifact generator tool to generate the mapping, which allows you to select the existing data model objects when you specify the process attributes during the process workflow runtime. v Optional Parameter: It specifies whether the parameter is optional. The corresponding attribute description in the work order is marked accordingly. 5. In the Classification Name field, a unique classification name is already provided. You must replace it with a classification name that follows your companys naming conventions (for example, TPM\ACME.VMREQUEST). This classification name will be used later, associated with the work order, to map the process attributes in the provisioning workflow. 6. Click Generate. 7. Check all the messages that are returned, and ensure that the artifact generation completes without errors.
Results
This generates all the artifacts and actions for the selected provisioning workflows, one action per workflow. For example, if you selected one workflow, one action is generated. If you selected ten workflows, ten actions are generated.
1246
Next: Building process workflows Related concepts Runbook automation process on page 1235
Building process workflows

After all the required artifacts and actions are generated for the selected workflows, you can start building your process workflow.
Before you begin

Ensure that you have already generated all the artifacts and provisioning workflows that are required to build the process workflow. See Generating process workflow artifacts on page 1245. You need at least two nodes to develop a process workflow. To build a process workflow:
Procedure
1. On the Process Management Requester screen, click Go To > System Configuration > Platform Configuration > Workflow Designer (Advanced). beside Select Action. 2. On the Workflow Designer (Advanced) page, click New Process 3. In the Process text box, type the name of the process workflow that you want to build. In the Object list, WORKORDER is the default object type. The bottom half of the Canvas tab displays the Launch on Demand Details for the process workflow to be built. The nodes that comprise your process workflow are represented graphically, with a Start node at the beginning of the process workflow, and a Validation node at the end. 4. Click the Connection icon on the Launch on Demand Details and link the nodes in the process workflow. 5. Double-click a connector to set up its action properties on the Action Properties dialog: > Select Value a. Next to Action, click Detail Menu b. On the Select Value dialog, select the action name. .
> Classification. c. Back on the Action Properties dialog, click Detail Menu d. On the Classification Search dialog, the action categories are listed, including the provisioning action categories for Software, Hardware, Virtualization, etc. Select the action category you want to work with, to add the corresponding provisioning action to the process workflow. e. Click OK. 6. Double-click any node to set up its properties on the corresponding Node Properties dialog. For example, you can: a. Edit the title of the start node on the Start Node Properties dialog, then click OK. b. Check the status and verify the progress of a task execution before it is complete on the Task Node Properties dialog. For doing that, under Role ID, click New Row, and then type in the Role ID. For Application, click Select Value c. Click OK. and select the application.
to save your process workflow. 7. Click Save Process 8. Click Action > Validate Process to validate the process workflow. 9. Click Action > Enable Process to enable the exection of the process workflow that you have just built and validated. 10. Click Action > Activate Process to activate the process workflow.
1247
Results
You have finished validating, enabling, and activating your process workflow. Next: Running process workflows Related concepts Runbook automation process on page 1235
Running process workflows

You can now run the process workflow that you have just built, saved, and validated.
Before you begin

To be able to run a process workflow, ensure that it is already validated and enabled. See Building process workflows on page 1247. To run the process workflow:
Procedure
1. Create a work order, or select one that has been created before. To create a new work order: a. Click Go To > Work Orders > Work Order Tracking. beside Select Action. b. On the Work Order Tracking page, click New Work Order c. In the Work Order box, type a name for the new work order. Optionally, you can add a description for it. next to Classification, then click Classify. The Classify dialog is d. Click Detail Menu displayed. Select a TPM classification for the new work order, then click OK. 2. e. Click Save to save your work order. On the Work Order Tracking page, click the Specifications tab. It displays a list of generated specifications, which is automatically populated with all the workflow attributes that you have set up earlier. Click Action > Workflow > Route Workflow. On the Start Workflow dialog, under Process, select the process workflow you want to run, then click OK. Click Action > Workflow > View Workflow Map. The View Workflow dialog is displayed. The View Workflow dialog provides a graphical representation of the steps in the workflow execution and their status.
3. 4. 5.
Results
When the workflow execution completes successfully, it is marked as such on the Workflow Administration page. On the Logs tab, you can now see the TPM_TASK_ID and TPM_TASK_URL information. Copy the URL and paste it in a web browser to review the status of the provisioning workflow. When the workflow execution fails at one step, the failure is displayed on the View Workflow page. You have to move away from the View Workflow page and then reopen it to refresh the status of the workflow execution steps.
1248
Related concepts Runbook automation process on page 1235
Troubleshooting the runbook automation

To help you troubleshoot runbook automation problems, gather as much information as possible about the error. Review the following list to assess the problem.
Procedure
1. Verify that all requirements for the scenario were met as described in Requirements on page 1238. 2. If an error message with a message ID is displayed, search for the message ID in the information center or see the Tivoli Provisioning Manager Troubleshooting Guide for a description of the error message. 3. If a provisioning task fails during the tutorial, check any error messages generated by the provisioning workflows that are part of the task. For more information, see the Viewing workflow execution status from the Web interface topic. 4. Check the log files for error messages. The following log files contain information for the scenario:
Table 219. Log file locations Log files Runbook automation logs Provisioning workflow logs Description Location
Contain diagnostic information for Runbook automation log files the runbook automation. Contain the history of Viewing provisioning workflow logs provisioning workflows recorded in the provisioning workflow logs.
5. Check the Tivoli Provisioning Manager Support technotes and FAQs or the latest available fix pack readme file for information about known issues or updates to the documentation. Related concepts Runbook automation process on page 1235 Runbook automation problems and limitations on page 1250 Related reference Runbook automation log files
Runbook automation log files

The following runbook log files contain diagnostic information for the runbook automation. Two types of log files are available on the Maximo server: Maximo log To access it: 1. In the Maximo logging application, click Go To > System Configuration > Platform Configuration > Logging. 2. Filter for tpa, and check the Log level. The output log files can be found under the WebSphere profile. For example, C:\ibm\WebSphere\AppServer\profiles\ctgAppSrv01\logs\MXServer\*.* Runbook log To access it: 1. In the System Properties application, click Go To > System Configuration > Platform Configuration > System Properties.
1249
2. Set the value of rba.log.enableCustomScriptLogging to 1, to enable logging within the Workflow Administration Advanced application. For each work order execution, the following information is available on the Log tab of the Workflow Administration Advanced application: v A link to the Task Tracking page on the provisioning server web interface. Open the URL in a web browser to review the workflow log. v The provisioning task ID. If a workflow implementation changes without a change in signature, action libraries must not be generated. If a workflow signature is changed, and actions still use the old signature, the deployment engine generates an error as the provisioning workflow fails. Related concepts Runbook automation problems and limitations Related tasks Troubleshooting the runbook automation on page 1249
Runbook automation problems and limitations

This section provides troubleshooting guidance and information about known problems and limitations. Related tasks Troubleshooting the runbook automation on page 1249 Related reference Runbook automation log files on page 1249 Error generating artifacts using default ACTION attribute length: Symptoms When you try generating artifacts without having customized the length of the ACTION attribute as described in the Configuring the Tivoli Provisioning Manager runbook automation adapter on page 1241 topic, the following error occurs:
BMXAA4049E - The value specified TP_SOFTWAREINSTANCE.REMOVEINSTANCE exceeds the maximum field length.
Causes In the Maximo database, the length of the ACTION attribute is set to 200 characters. To accommodate action names that include longer provisioning workflow names, you must customize this length to a higher value. Resolving the problem Customize the length of the ACTION attribute as follows and then try the artifact generation again. 1. Click Go To > System Configuration > Platform Configuration > Database Configuration. 2. On the List tab, search for the ACTION object, and click its name. 3. Click the Attributes tab of the ACTION object, then select the ACTION attribute. 4. Update the Length value to 200 (recommended). to save the change and apply the setting. 5. Click Save 6. In the Maximo administrative workspace, go to <WAS_HOME>\AppServer\profiles\ctgAppSrv01\bin. 7. Enter the command: stopServer MXServer -username <wasadminuser> -password <wasadminuser_password>
1250
8. 9. 10. 11. 12.
Go to c:\IBM\SMP\maximo\tools\maximo. Enter the command: dropbackup Enter the command: configdb Go to <WAS_HOME>\AppServer\profiles\ctgAppSrv01\bin. Enter the command: startServer MXServer
Parameters passed incorrectly from Service Request Manager to Tivoli Provisioning Manager: Symptoms If the working directory is a required parameter for a provisioning workflow, when a path using backslash signs is provided (for example, C:\dir1\dir2) the provisioning workflow fails on the provisioning server with the following error:
BMXAA4407E: A nested exception caused the workflow process to fail.
Causes Parameters are incorrectly passed from the Service Request Manager to Tivoli Provisioning Manager, meaning that backslash signs (\) are not accepted in Windows paths. Resolving the problem Instead of using the single backslash sign (\) as a directory separator in Windows paths, use either a double backslash sign (\\) or a forward slash sign (/). For example, instead of c:\dir1\dir2, use either c:\\dir1\\dir2 or c:/dir1/dir2. Insufficient memory for database synchronization: Symptoms During the database synchronization, the following error might be encountered in the SystemOut.log file:
BMXAA6359E - A runtime error for TPADBSYNCCRONTASK.TPADBSYNCCRONTASK1:null occurred.
Causes This is caused by an insufficient memory allocation in the WebSphere setting. Resolving the problem Increase the memory allocation as follows: 1. 2. 3. 4. Log on to the WebSphere administrative console in Service Request Manager. Click Servers > Application servers > MXServer. Expand Java and Process Management, then go to Process Definition, and Java Virtual Machine. Update the value of the Initial Heap Size to 1024, and the value of the Maximum Heap Size to 2048.
to save the changes. 5. Click OK, then click Save 6. Restart the IBM Tivoli Service Request Manager and WAS. Note: You must not only restart the Service Request Manager by restarting the MXServer, but rather restart the MXServer as well as the Node and Manager. For doing that, enter the following commands: v
Windows
1251
%WAS_HOME%\profiles\ctgDmgr01\bin\startManager.bat %WAS_HOME%\profiles\ctgAppSrv01\bin\startNode.bat %WAS_HOME%\profiles\ctgAppSrv01\bin\startServer.bat MXServer
UNIX
Linux
%WAS_HOME%/profiles/ctgDmgr01/bin/startManager.sh %WAS_HOME%/profiles/ctgAppSrv01/bin/startNode.sh %WAS_HOME%/profiles/ctgAppSrv01/bin/startServer.sh MXServer
Changing end point location requires database objects removal: Symptoms When the end point is changed to a new location, the existing objects in the database table are no longer valid. Resolving the problem Manually remove the content of the database table, to update the database objects for the new end point location. 1. Stop the TPADBSYNCCRONTASK cron task, as follows: a. Click Go To > System Configuration > Platform Configuration > Cron Task Setup. b. Search for TPADBSYNCCRONTASK, then select the cron task. to save the changes. c. Clear the Active check box to stop the cron task, then click Save d. Check the entries in the History tab frequently. When STOP is displayed and no error message occurs, the cron task is stopped successfully. Note: You might need to exit the page and then return to it to refresh the history entries. 2. Once the TPADBSYNCCRONTASK cron task is successfully stopped, open a database command prompt and run the following:
delete from tpadbsyncts delete from tpadcmobject
3. Start the TPADBSYNCCRONTASK cron task, as follows: a. Click Go To > System Configuration > Platform Configuration > Cron Task Setup. b. Search for TPADBSYNCCRONTASK, then select the cron task. to save the changes. c. Select Active to start the cron task, then click Save d. Check the entries in the History tab frequently. When START is displayed and no error message occurs, the cron task is started successfully. Note: You might need to exit the page and then return to it to refresh the history entries. Related tasks Configuring the Tivoli Provisioning Manager runbook automation adapter on page 1241 Installation of multiple PMP packages might fail: Symptoms A database error similar to the following might be encountered when you try installing more than one runbook automation adapter PMP:
com.ibm.db2.jcc.am.SqlSyntaxErrorException: "SHOWINTOPO" is not valid in the context where it is used.. SQLCODE=-206, SQLSTATE=42703, DRIVER=3.59.81
Causes
1252
In an ISM environment, multiple PMP packages might be installed, which could modify some database schema. This, in turn, could lead to an installation failure similar to this one. Resolving the problem Before proceeding with the PMP installation, ensure that you have a system or database backup. Contact IBM support for a workaround to this issue. For example, an update to the PMP content might be required to avoid the database error. DCMObjectLookup does not return new objects from Tivoli Provisioning Manager: Symptoms The data model objects are not found on the Service Request Manager. Causes The cron task that is used to synchronize the data model objects between Tivoli Provisioning Manager and Service Request Manager has not been activated, or the timer has not expired. Resolving the problem By default, the cron task runs once an hour, but the schedule can be customized as required. Ensure that the activation timer has not run out, or activate the cron task manually. To activate the cron task: 1. Click Go To > System Configuration > Platform Configuration > Cron Task Setup. 2. On the Cron Task tab, search for TPADBSYNCCRONTASK. 3. Select the Active check box for the cron task. 4. Click Save to save the change and apply the setting.
Process Artifact Generator

Classification Name Enter the classification name for the work order association. Select Provisioning Workflows Click this button to select one or more provisioning workflows. The Select Provisioning Workflows dialog is displayed. Provisioning Workflows Lists the names of the provisioning workflows that you selected for artifact generation. Provisioning Workflow Specifies the name of the provisioning workflow. Description Provides a description for the provisioning workflow. Category Specifies the category for the provisioning workflow. Configuration Lists configuration parameters that you can set up for the selected provisioning workflows. v Parameter name: Specifies the name of the parameter. v Default Value: Enabled when the Data Model Object Lookup is not selected. Type in a value for your parameter, or use the default value. This value will be populated in the attribute value of the work order. v Description: (Optional) The parameter description. If provided, the description is displayed in the attribute value in the work order.
1253
v Data Model Object Lookup: Finds a data model object ID by name. The value found in the DCMObject table is mapped to a specific DCMObject ID. If this option is not selected, you can type in a value for your parameter, or use the default one. v Optional Parameter: Specifies whether the parameter is optional. The corresponding attribute description in the work order is marked accordingly. Generate Click this button to generate all the artifacts and actions for the selected provisioning workflows, one action per workflow.
Select Provisioning Workflows

Enter the search criteria to retrieve provisioning workflows. You can use % as a wildcard character for your search. Filter Searches for provisioning workflow names that match a specified string of text. To see a filter field, click the Filter button, then enter your search string and click Enter. If you do not enter anything in the Filter field, and click Enter, all the provisioning workflow are listed. To filter using different criteria, clear the filter fields. Provisioning Workflows Lists the provisioning workflows available for the artifact generation.
Select Value
Enter the search criteria to retrieve the categories for the provisioning workflows. You can use % as a wildcard character for your search. Filter Searches for provisioning workflow category names that match a specified string of text. To see a filter field, click the Filter button, then enter your search string and click Enter. If you do not enter anything in the Filter field, and click Enter, all the categories are listed. To filter using different criteria, clear the filter fields. Provisioning Workflow Category Lists the available categories for the provisioning workflows.
1254
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.
1255
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758
U.S.A.
Such information may be available, subject to appropriate terms and conditions, including in some cases payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample programs.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at www.ibm.com/legal/copytrade.shtml. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
1256
ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. UNIX is a registered trademark of The Open Group in the United States and other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Other product and service names may be trademarks of IBM or other companies.
Notices
1257
1258
Index Numerics
20006 error for software package block 796 administrative console troubleshooting 799 administrative domains adding clusters 737 subdomains 737 cells and nodes 734 defining 736 overview 733 removing clusters 737 requirements 736 WebSphere Application Server clusters 734 administrative workstation changing the database table 192 administrator toolkit 689 agent manager administering and configuring 684 Authorization.xml file sample 684 AuthXMLAddUser command 685 cleaning up the database 689 components 682 configuring in WebSphere Application Server 108 default ports 675 duplicate agent registration 681 in SDI diagram 18 log files WebSphere Application Server run time 799 managing registration 675 recovery of agents 681 recovery service 683 registry configuration 680 size 680 removing expired agents 674 replacing certificates 687 resource manager registration properties 684 resource manager registration user 685 sample Authorization.xml file 684 server overview 682 TCP/IP ports 631 toolkit 681 troubleshooting cannot communicate with Tivoli Common Agent 786 installation fails with embedded WebSphere Application Server 802 agent recovery service HTTP connection 683 unsecured connection to agents 683 agent registration password 678 agentTrust.jks file 679 AIX approving compliance recommendations 925 creating system profiles 306 AIX (continued) LPARs 1016 NIM discovery 505 patch management approved patches 923 aquiring 922 considerations 884 customizing the scanning model 923 day-to-day tasks 922 discovering satellite server 920 discovering targets 920 distributing patches 926 grouping target computers 921 installing 926 missing patches 924 prerequisites for servers 918 process 914 requirements 918 setting up compliance 923 supported platforms 914 testing 922 tutorial 917 uninstalling 627 verifying compliance results 926 prerequisites for target computers 919 troubleshooting cannot scan for patches 1000 download of large number of patches fails 1000 installing technology level also installs service pack patches 998 patch download and distribution failure 999 replacing corrupted or deleted patches 999 Technology Level (TL) patches unavailable for AIX discovery setup 1000 VMControl 1040 WPARs 1027 ancestors master image versions 509 Anyplace Kiosk 381, 492 applications getting started 1 mapping to data model objects 1221 opening 30 architecture for provisioning components 14 attributes adding after integration with other products 1222 audit records 111 Authorization.xml file resource manager registration properties 684 sample 684
A
access rights overview 132 security groups 138 access rules adding and removing 1145 ACLs adding, editing, and removing rules 1146 activity plans as a provisioning task 1161 ad hoc reports 1198 adapters 10/100 EtherLink PCI Management Adapter by 3Com 382, 493 10/100 EtherLink Server Adapter by 3Com 382, 493 Ethernet Daughter Card 382, 493 IBM 10/100 EtherJet miniPCI adapter with 56K modem by 3Com 382, 493 IBM 10/100 EtherJet PCI Adapter with Alert on LAN 2 382, 493 IBM 10/100 EtherJet PCI Adapter with Wake on LAN1 382, 493 IBM 10/100 EtherJet PCI Management Adapter 382, 493 IBM 10/100 EtherJet Secure Management Adapter 382, 493 IBM 10/100 EtherJetminiPCI adapter with 56K modem (Intel current card) 382, 492 IBM 10/100 Ethernet Server Adapter 382, 492 IBM NetXtreme 1000 T Dual Port Ethernet Adapter 382, 493 IBM NetXtreme 1000 T Ethernet Adapter 382, 493 IEEE 1394/LAN Combo Card 383, 493 Intel Gigabit Copper (82543) PRO 1000 XT 383, 493 Intel Gigabit Copper (82544) PRO 1000 XT 383, 493 Intel PRO/100 SP Mobile Combo adapter 382, 492 Intel PRO/100S Desktop Adapter 382, 493 Intel PRO/100S Low Profile Desktop Adapter 382, 493 On board Ethernet Adapter for ThinkPad R30 383, 493 adding a virtual Fibre Channel adapter to an LPAR 1082
1259
boot servers (continued) AuthXMLAddUser command OS Deployment configuration 354, changing passwords 464 encryption key 686 VMControl 1040 resource manager registration 684 branch office automated hardware discovery 443 distributing software 584 automation software package creation 751 compliance 24 Brocade 20 Port FC switch module 384, deployment engine 20 494 deployment infrastructure 17 building device discovery 21 runbook process workflows 1247 life cycles 20 bundles managing operating systems 23 deployment and management 631 automation packages AIX_WPAR_Virtual_infratructure 1027 for regions, zones, depot servers 822 HyperV_Virtual_Infrastructure 1049 p-Series-Server 1016 cache size Solaris Sun Update Connection client and depot 608 Enterprise 984 calendar files 615 SolarisZones_Virtual_Infrastructure 1085 capabilities for software 699 VMControl_Virtual_Infrastructure 1040 capture virtual images 431 VMware_Virtual_Infrastructure 1060 CD/DVD automation packages email creating notification 38 using a wizard 275, 402 using command line 278, 405 CDS data source 107 CellBlades 295 backend storage for NPIV 1083 cells backups WebSphere Application Server 734 creating saved images 519 certificates images 392 agent manager base services creating 687 troubleshooting regenerating security broken link 64 certificates 687 broken link for shortcut 64 common agent 688 binding rules expired or revoked 683 automatic 347, 460 importing to the web interface 100 tutorial 347 change windows 1220 BIOS settings and updates 317 changePassword blade servers maximo user and database configuring remotely 1142 password 96 defined 45 checklist LPARs 1016 scalable distribution BladeCenter infrastructure 756 2-Port Fibre Channel Switch support 756 Module 384, 494 child server 6-pt Fibre Channel Switch creating 284, 415 Module 384, 494 promoting 285, 416 Advanced Management Module Cisco (AMM) 384, 494 Fiber Switch Module 384, 494 compatibility list 380, 490 Gigabit Ethernet Switch module 384, Copper Pass-Thru Module 384, 494 494 Gigabit Ethernet Expansion CIT Card 384, 494 changing installation path 633 HS20 Fibre Channel Expansion creating custom inventory Card 384, 494 extension 193 HS20 Fibre Channel Expansion Card including custom inventory extension Short Form Factor 384, 494 data 194 Optical Pass-Thru Module 384, 494 manual uninstallation 673 PCI Expansion unit (PEU) 384, 495 storing additional inventory data 191 related products 379, 490 testing custom inventory BMXAA0024E 122 extension 193 BMXAA3813E 125 wscanfs command 190 boot module TPMconfig.xml file 191 parameters 355, 466 clean-up-deployment-requests command boot servers COPDEX029E error 1185 KVM 1030 client cache size 608
clones 269 cluster domains adding new clusters 726 building using a template 724 creating new 723 resource relationships 731 device drivers associating 726 associating with resources 730 high availability 722 logical management operations 733 managing resources in groups 731 nodes adding 728 configuring 728 configuring automatically 726 deprovisioning 728 editing properties 728 node details 731 starting and stopping 728 overview 722 resources associating device drivers 730 creating and removing relationships 731 starting 730 software configuration templates 724 starting and stopping 731 status 728 types 722 WebSphere Application Server 734 clusters administrative domains associating to 737 removing from 737 CMS Java native library 131 key database 131 commands AuthXMLAddUser changing passwords 684 changing the password encyption key 686 creating users 685 EncryptAMProps 686 Tivoli Common Agent collecting diagnostic info 764 installation failure when using copy or put 772 list 766 troubleshooting error using clean-up-deploymentrequests 1185 error when running versionInfo 69 wscanfs 190 TPMconfig.xml file 191 common agent custom RHEL 6 installation 931 common agents changing default installation path 654 changing default port number 652 cleaning up the data model after the manual uninstallation 673
1260
common agents (continued) configuration template parameters 633 customizing 654 default ports 675 discovering after installation 645 discovery and health status report 575 error state records 680 inactive agents 681 installing cleaning up 673 DBCS 774 from the web interface 640 install-path variable 654 InstallStatus 645 on all target computers 570 overview 541, 635 requirements 547, 550, 552, 554 return codes 645 up-level over existing level 780 using DVD 641 using sudo 774 IP address 1146 prerequisites 547, 550, 552, 554 recovering unregistered agents 681 registering duplicates 681 with agent manager 675 removing old agents from the registry 681 software package blocks 581 replacing certificates 688 requirements for software deployments 546 running as a local administrator user 656 as LOCAL_SYSTEM 656 software stack 633 starting and stopping 652 status checkpoints 631 toolkit InstallStatus 650 runtime logs 650 UnInstallStatus 650 troubleshooting list of problems 763 return codes 645 uninstalling from individual computers 669 from provisioning groups 669 manual 670 manually 673 software 581 UnInstallStatus 645 when regular uninstallation fails 673 unregistered agents 681 upgrading InstallStatus 645 stand-alone procedure 668 supported versions 667 using a provisioning workflow 667 with the deployment engine infrastructure 667
common agents (continued) with the scalable distribution infrastructure 667 Common Inventory Technology installation removing 170 setting the path 164 compliance approviing recommendations Solaris 983 approving recommendations AIX 925 Red Hat Enterprise Linux 945 SUSE Linux Enterprise Server 967 defining multiple-rule security compliance check 854 in managing system life cycle 20 overview 24, 827 prerequisite checklist 838 process 833 reference 869 reports 1191 requirements 835 restricting software example 855 security roles 835 supported endpoints and platforms 838 the basics 828 troubleshooting check settings cannot be modified 866 checks are duplicated when computer is part of a group 865 checks are duplicated when computer is part of multiple groups 864 inventory scan will not run 865 list of known issues 858 no recommendation after system logging check 866 recovering from cocmpliance problems 867 remediation task cannot be run 864 Windows check does not recognize firewall 866 tutorial 844 user-defined compliance check example 856 verifying results Red Hat Enterprise Linux 948 SUSE Linux Enterprise Server 970 Windows 909 Compliance Analyst reports 1188 compliance checks creating for Windows 845 exporting for all computers and groups 841 for selected computers or groups 840 tools 839 for software 847 for software configuration templates 848 importing for all computers and groups 842
compliance checks (continued) importing (continued) for selected computers or groups 841 to different target computers 843 tools 839 overview 845 running 850 scheduling 851 security overview 869 using a model 846 composite images creating 511 prerequisites 511 computers adding a network interface card 1134 and removing 48 resources and parameters 1133 to application tiers and resource pools 54 checking health 47 configuring network interface 1135 discovering attributes 1223 finding inactive computers 228 object IDs 37 installing targets 23 Lenovo ThinkCentre ASI 381, 492 Lenovo ThinkCentre SSO 381, 492 Lenovo ThinkPad R52 381, 492 managing group members 42 remotely 49 targets 23 networking and IP addresses 1133 patching targets 25 rebooting 50 registering with Sun Update Connection 985 turning off and on 50 types of servers 45 viewing groups 42 viewing in Tivoli Storage Productivity Center 1214 conditional user interface cross-site scripting 144 preventing cross-site scripting 95 SQL injection attacks 144 Configuration Librarian creating saved images 519 image library 501 configuration template editing 654 configuring HTTPS 1244 runbook automation adapter 1241, 1253 console.log virtualization problems 1096 consumable size 66 COPCOM123E cannot execute commands in Cygwin 66 simple software product installation 625
Index
1261
COPCOM123Etroubleshooting adding MPIO hard disk fails 1107 COPCOM132E special characters in user names 123 COPCOM618E 255 COPDEX029E 1185 COPDEX123E 1002 cannot create virtual server 525 COPDEX172E 1102 COPINF002E 1001 COPINF050E software distribution fails on HP-UX 791 COPSWD087E synchronizing entries 505 CPU on virtual server templates 1072 credentials adding to virtual images 430 cross-site scripting 144 CTGDEC030E 1001 custom inventory extension creating 193 including data 194 testing 193 custom scan configuring the SMT or YUM repository 965 patches AIX 923 Red Hat Enterprise Linux 941 SUSE Linux Enterprise Server 964 YUM scan discovery 943 custom user registry LDAP 113 customizing length of Action attribute 1240 Cygwin cannot execute commands 66
D
data model objects mapping to applications 1221 database tables changing 192 DB2 103 configuring MXServer for SSL DB2 communication 106 configuring SSL 104, 111 database lock time-out 793 DB2 Control Center 192 dcm.xml for SSL DB2 connection 109 how to get a database report 181 managing compliance 874 remediation on 874 DB2COMM configuring SSL for DB2 104 registry variable 110 dcm.xml file 109 deleting virtual servers 1077 deleting virtual Fibre Channel adapters 1084 deploying software troubleshooting 756
deployment engine definition 20 OS Deployment 265, 392 overview of deployment 17 deployment engines managing multiple WinPE deployment engines 289, 420 Deployment Specialist distributing software 583 image library 501 reports 1188 virtualization 1060, 1087 deployments setting up by cloning images 269 virtual images 432 depot servers adding 819 automation package for managing large numbers of 822 creating Red Hat Enterprise Linux patch 939 Windows patch 901 data directory 820 default polling interval 542, 655 installing 540, 599 migrating published files 820 predeploying files 543, 1004 predeploying software patches 544, 1005 predeploying software products 544, 1004 publishing files 543, 1004 publishing software package blocks 578 publishing software patches 544, 1005 publishing software products 544, 1004 removing 821 troubleshooting software distribution issue 796 software product publish operation 808 undeploying files 545, 546, 1006, 1007 undeploying patches 545, 1006 undeploying software products 545, 1006 unpublishing files 545, 546, 1006, 1007 unpublishing software patches 545, 1006 unpublishing software products 545, 1006 uploading files 543, 1004 uploading software patches 544, 1005 uploading software products 544, 1004 viewing 819 depots cache size 608 failing distributions deleting 792 recreating 792
depots (continued) publishing SUSE patches 968 removing stacks 821 troubleshooting 792 device manager federated agents configuring the subagents manually 596, 598 with the federator automatically 597 with the federator manually 592 uninstalling 599 device manager service authentication 823 changing polling intervals and runtime values 662 deployment options 823 federated agents 823 federator 822 in scalable distribution infrastructure diagram 18 installing verification 666 job processing and results 824 timing explanation 663 log files console 666 installation, migration, and removal 666 logging and tracing 663 monitored by administrator 666 overriding the default job expiry interval 825 periodic connectivity 824 security 823 subagents 822 troubleshooting scalable distribution infrastructure 751, 989 timeout error for file distribution 789 using the console 665 DeviceName adding MPIO hard disk fails 1107 DHCP configuring for OS Deployment server 297, 424 for OS Deployment option 43 299, 426 option 60 298, 425 requirements 296, 423 directories default values 56 discovering NPIV resources 1081 discovery agent manager discovery 195 AIX workload partitions 200 AIX WPAR Discovery 1027 basic information 146 business applications defining 235 mapping 239 overriding rules 236 collecting information 233 common agent process 645 configuration file 174
1262
discovery (continued) consolidation rules different discovery configurations 229 different software installations 230 creating using wizard 231 creating report 569 custom composite applications mapping 210 database configuration details 214 discovering targets 568 finding computer attributes 1223 generate book 225 Hyper-V SCVMM Server Discovery 1049 hypervisors 439 identifying resources 227 in managing system life cycle 20 inventory KVM operating systems 507, 512 inventory discovery using the inventory extension 188 inventory extensions defining custom 184 importing the reports 188 running the reports 189 setting up the environment 175 inventory scans creating the custom tables in the data model 187 creating the inventory extensions 188 creating the pre script files 186 creating the properties files 188 customizing the CIT configuration file 186 library adapter process diagram 223 recent versions 224 Libvirts Virtual Hosts Discovery 1030 MAC address adding 226 mapping software 210 Microsoft Active Directory discovery running 196 Microsoft updates running 198 Network Address Translation support enabling 227 network discovery customizing 231 discovering environment 231 overview 154 performing 155 specifying a group 158 using RSA credentials 157 operating systems 195, 208 OS Deployment servers 296 overview 21, 145 PCI devices 202 process 150 provisioning groups 195 reports 1194 requirements 152
discovery (continued) rerunning the task 233 running the Tivoli Provisioning Manager Inventory Discovery scan 580 RXA discovery running 155 security roles 153 SNMP using 159 software requirements 153 Solaris target computers 979 Solaris zones 199 TADDM discovery business applications 234 computer extended attributes 207 creating the discovery 237 defining SAPs for computers 208, 836 hardware and software 205 overview 203 running 207 verifying results 238 viewing business applications 238 tracking progress 233 troubleshooting cannot associate software resources with software definitions 794 deadlock problems 250 deployment engine exception 254 discovery of Linux on zSeries 247 dual computer information after installation 251 errors for host platform servers 1106 failure on AIX WPAR target computers 255 HostPlatform Resource and Virtual Machine discovery error 1102 incorrect locale on Linux 250 incorrect value for cpu.type in data model 246 Initial Discovery provides limited information 245 inventory scan fails 247 IPv6 addresses on Windows XP 253 Libvert discovery misses virtual servers 1105 Libvirt host platform fails 1104 no hardware report information 246 only displays short names 246 recovering from problems 244 TADDM discovery failure 256 Windows Vista 251 wrong recommendation generated by password security check 868 tutorial 230 types 153 unknown resources 233 verifying computers and groups 228 resources 227 virtual centers 200 virtual servers 201
discovery (continued) VMControl 1040 VMware HostPlatform Resource and Virtual Machine Discovery 1066 VMware Virtual Center Discovery 1066 web logic configuration details 221 WebSphere Application Server discovery configuriation 219 software instances 203 without common agent 162 DiscoveryUploadUrl maintenance windows 613 disk space requirements for common agent registry 680 distributing software prerequisites 635 scalable distribution infrastructure setup 538, 589 using 584 target computers 547 distribution infrastructure adding a software package block to the software catalog 577 automated setup of the device manager federated agents 597 configuring subagents to communicate with the federated agent 596, 598 configuring the federated agent with the federator 592, 593 creating a software signature 577 deploying software 576 depot servers 817 distributing software package blocks 578 federated agents restarting after a reboot 598 installing manual installation of JRE 1.5 591 setting up the scalable distribution infrastructure 538, 589 software package blocks on targets 579 the device manager federated agent 538, 589 inventory and deployment reports 581 manual setup of the device manager distribution elements 593 publishing software package blocks 578 removing software 581 stopping the federated agent 598 uninstalling the device manager federated agents 599 uninstalling the federated agent 598 unpublishing the software 581 upgrading software package blocks on targets 579 validating the software installation 580 DMS_SYSTEM_JOB_PRIORITY maintenance windows 613 DMXAA0026E 129
Index
1263
documentation tip for reordering the information center 34 types of help 32 updates 1, 9 What's new 1 driver 337 DRS enablement on VMware cluster 1063 Dual Channel LSI Ultra320 SCSI controller 383, 494 dynamic content delivery accessing the administration console 820 authentication 816 automation package 822 cache size client 608 default 655 depot 608 deplot servers verifying published files 658 depot servers adding 819 installing 540, 599 managing 817 removing 821 disabling peering 815 distributing software 543, 545, 1004, 1006 downloading files bulk data 810 peering 815 sharing 815 dual stack of IPv4 and IPv6 816 log files configuration of properties 658 maintenance windows 613 management center 813 peering enabling and disabling 815 enabling on dual stack of IPv4 and IPv6 816 peer-to-peer file sharing 815 publishing files to depot servers 543, 544, 1004, 1005 regions 818 managing 818 removing 818 security 816 software distribution 810 trimming data 814 troubleshooting cannot reinstall depots after removal 805 depot information 804 depot stack not removed on uninstall 807 Dynamic Depot Selection (DDS) algorithm 657 incorrect used space value on depot 807 management center 809 overview 804 silent installation of management center fails 806
dynamic content delivery (continued) unpublishing files from depot servers 545, 546, 1006, 1007 uploading files to depot servers 543, 544, 1004, 1005 zones 818 adding 818 dynamic groups creating 39 definition 78 types for security groups 143
everyday tasks getting started 37 expired agents removing 674 export virtual images 434
F
FAQs 55 FAStT EXP500 Storage Expansion Unit 382, 492 FDCC COPCOM618E error 255 Fibre Channel adapter resource requirement 1081 fibre channel switches 1156 file access module parameters 356, 467 file distribution troubleshooting device manager timeout is low 789 dual stack 789 fails when deleting and recreating 792 file repositories adding files 604 adding network interface cards 603 creating YUM or SMT on SUSE 959 for patch download 604 overview 602 file system requirements for target systems 283, 414 file transfer operations maintenance windows 613 filter searching tables and using wildcards 30 FIPS PKCS12 92 upgrading JDBC 103 firewall component overview 739 connecting through unidirectional firewall 747 through unidirectional firewall with additional network 748 enabling support for common agent 742 example 1 747 example 2 748 generating the keystore 742 setting up the gateway manager 742 starting the components 742 firewalls networking overview 1131 fix 9 Flash archives 311 form base authentication configuring 99 enabling the Applications tab 93 frequently asked questions 55
E
electronic signatures auditing 111 email disable password notification 125 report notifications 1188 email notification 38 email notification for NPIV 1078, 1084 EMAILTYPE translation errors non-English install 72 Emulex 4Gb SFF Fibre Channel Expansion Card 384, 494 EncryptAMProps command 686 endpoint distributing software package blocks 578 patch scan Windows 788 properties file 682 enhancements 1 enterprise discovering resources 21 life cycle management 20 patching 25 software distribution 23 error messages clean-up-deployment-requests command 1185 database lock timeout 70 default insert site configuration 72 deploying SPB 797 GUID installation fails 769 locale incorrectly displayed in English 71 old download plans 797 provisioning workflows shell command error 796 Tivoli Common Agent fails if already installed 775 installation failure on Red Hat 5 771 upload server time out 792 eServer 325 380, 490 eServer 326 380, 490 ESX server creating an unattended setup image 1061 creating on a target 1062 error creating a virtual server 1101 managed by VirtualCenter 1062 registering 1063 Ethernet adapters OS Deployment 382, 492
1264
G
gateway manager 742 generate request page reports 1188 generating process artifacts 1246 getting started everyday tasks 37 the basics 10 global agent configuration 570 global variable AM.Discovery.Thread.Count 250 DiscoveryConcurrencyLevel 250 golden master capturing images 315 groups creating 39 GSKit configuring SSL for DB2 104 key manager troubleshooting 131
H
hard disk adding to virtual server templates 1072 hard disks adding 1075 to existing virtual servers 1075 to LPARs 1016 adding multiple 1016 moving virtual servers 1077 hardware adding resources Solaris Zones virtual server templates 1090 VMware virtual server templates 1072 administering remotely 1142 OS Deployment compatability list 379, 490 creating configuration images 317 creating configurations 322 creating environments 318 requirements for target systems 281, 412 working with configurations 317 Hardware abstraction layer (HAL) 339, 452 hardware and software requirements for NPIV 1080 hardware discovery 164 hypervisor and virtual servers 443 Hardware Management Console for VMControl 1040 troubleshooting errors appear scrambled 1180 health 47 heartbeat function 682 high availability disaster recovery alternative technologies 1129 architecture overview 1110 cluster domains 722 configuring 1120 installing 1120
high availability disaster recovery (continued) introduction 1109 primary installation 1120 secondary installation 1121 solution architecture 1116 solution architecture diagram 1117 solution constraints 1113 steps for disaster recovery 1127 the basics 1109 Tivoli Provisioning Manager for OS Deployment 1127 Tivoli System Automation for Multiplatforms installation 1122 integration 1119 HMAC-SHA1 keyed-hashing 686 HMC see Hardware Management Console 1016 host platform servers definition 1013 discovering 441 Solaris 1089 VMware 1066 initial discovery for Solaris 1088 KVM 1030 moving LPARs 1016 virtual servers 1077 troubleshooting application opens too slowly 1106 discovery errors 1106 Libvert discovery fails 1104 HostPlatform Resource and Virtual Machine discovery error 1102 HotFix creating 334, 448 HP-UX patch management considerations 884 reference 985 Tivoli Common Agent cannot register 776 troubleshooting software distribution fails 791 HTTP SAP 1065 HTTP server port for agent recovery 683 Hyper-V 1049 hypervisors discovering 441 KVM 1030 requirements VMWare 4.0 408
I
IBM AIX NIM Discovery synchronizing images 505 IBM HTTP Server managing compliance 877 IBM System p booting in OS Deployment 294 VMControl 1040 IBM Systems Director VMControl 1040
IBM TotalStorage DS4100 382, 492 DS4300 382, 492 DS4400 382, 492 DS4500 382, 492 FAStT100 382, 492 FAStT600 382, 492 FAStT700 382, 492 FAStT900 382, 492 iKeyman utility 679 image library basics 498 composite images prerequisites 511 importing OVF master images 513 overview 497 OVF master images 525 prerequisites 501 provisioning administrator 501 publishing images 520 saved images overview 517 synchronizing entries 497 terminology 498 troubleshooting 522 KVM virtual server cannot be deleted 526 user roles 501 image monitor 392 image properties associating with images 327 customizing 327 image repositories synchronizing entries 304, 430 image repository creating 502 KVM 1030 synchronizing 505 synchronizing entries 505 image respository troubleshooting refused connection error 525 images bindings 324 drivers 324 exporting to OVF 446 installing 461 OS Deployment capturing golden master 315 creating unattended setup 304 deployment process 269, 398 editing properties 323 installing 349 Linux on Intel 307 Linux on PowerPC 308 managing 259 managing operating systems 268 preparing the source computer 312 software modules for 332 Solaris 308 synchronization 304, 430 Windows 305 point-in-time snapshot 316 replication 434 requirements for operating system 270 Index
1265
images (continued) saving LPARs 1016 software modules for 447 types for operating systems 272 importing inventory extension reports after installation 182 setting up parameters for importing inventory extension reports 182 installation agent manager fails with embedded WebSphere Application Server 802 common agents 541, 635, 640, 645 and subagents 641 registration request rejected by agent manager 787 creating image 641 device manager verification 666 directories 56 dynamic content delivery silent installation of management center fails 806 GUID fails on Windows 769 images 461 incorrect information with Tivoli Common Agent 784 resource manager SSLHandshakeException error 773 Tivoli Common Agent fails if already installed 775 fails on Solaris 770 fails on Solaris SPARC target computers 770 fails when using copy or put commands 772 fails with invalid password 775 failure on AIX WPAR 1103 failure on Red Hat 5 771 files deleted on restart 776 installation fails 768, 772, 774 on Security-Enhanced Linux 768 SSLHandshakeException error 773 troubleshooting 767 agent manager 767 error after installing 7.2 on Windows 65 virtual images 461 Web interface extension on a hypervisor 442 rbagent 428 installing RHEL 6 with optional packages 931 runbook automation adapter PMP 1240 Tivoli Common Agent installation fails 769 instance images creating a repository 502 definition 498 viewing 508, 514 instance level security restriction 131 Integrated Virtualization Manager 1016
integration Tivoli Storage Productivity Center 1214 with other products 1211 with Tivoli Monitoring 1211 Intel Copper Switch Module 384, 495 IntelliStation M Pro 381, 491 interim fix 9 Internet Explorer hangs when viewing multiple report results 1208 non-English information center displayed in English 66 intial discovery Solaris host platform servers 1088 inventory configuring networking devices 1131 inventory discovery software 169 Inventory discovery SDI environment setting global variables 163 inventory extensions creating custom data output files 178 custom table 176 inventory extention 181 pre and post scripts 177 properties file 179 the environment 175 custom report 184 customized 175 environment set up 183 running 183 IP addresses adding blocked IPs for a subnet 1138 enabling for SDI 1146 IPv6 for the provisioning server 1153 examples 1133 not displayed on web interface 257 IPv4 comparing to IPv6 1148 file distribution error 789 troubleshooting updgrading common agent or depot 763 IPV4 dynamtic content delivery 816 IPv6 benefits 1148 cannot discover addresses on Windows XP 253 dual stack network 1148 enabling for SDI 1146 in the operating system 1151 enabling on the provisioning server 1153 limitations 1149 management IP 1153 supported scenarios 1149 IPV6 dynamtic content delivery 816 IVM 1016
J
JDBC upgrading 103
K
key management utility 679 key performance indicators 1204 keyed-hashing algorithm, HMAC-SHA1 686 keys encryption 686 keystore 742 error importing 130 KVM adding a mount point 502 creating a repository 502 for OS Deployment 410 importing OVF master images 513 resizing disks 1030 resource allocations 1030 synchronizing images 505 troubleshooting cannot be deleted from the agent 526 refused connection error 525 virtual server states 1067
L
language pack creating 333, 448 languages Latin supported for user names 128 last known status 45 LDAP accessing 119 attribute 119 failed login limit 94 group management 113 overview 113 sample information 115 Tivoli Directory server sample 115 user management 113 library adapter 223 Libvirt discovery misses virtual servers 1105 host platform discovery fails 1104 Virtual Hosts Discovery 1030 Linux images creating unattended 307 creating unattended on PowerPC 308 KVM 1030 troubleshooting cannot import software signature 794 common agent cannot read GUID on startup 784 common agent installation fails 768 common agent installation fails on Red Hat 5 771 discovery of zSeries 247
1266
Linux (continued) troubleshooting (continued) no compliance recommendation after system logigng check 866 problems on System z 247 provisioning server does not start 68 wrong locale discovered 250 load balancers adding and editing 1136 configuring routing 1137 switch functionality 1137 description 1131 networking 1132 locales cannot log on to Turkish computer 60 error messages incorrectly displayed in English 71 Linux incorrect discovery 250 system variables and attributes 36 Web interface displays English on non-English information center 66 log files agent manager WebSphere Application Server run time 799 device manager 664 console 666 installation, migration, and removal 666 lightweight 667 monitored by administrator 666 trace logs 663 dynamic content delivery configuration of properties 658 for Tivoli Enterprise Console 1227 image library 522 Remote Execution and Access (RXA) enabling 803 setting up default cleanup 658 Tivoli Common Agent collecting from target computer 765 list 765 troubleshooting inventory discovery 244 UNIX file system capacity exceeded 70 virtual servers 1095 WebSphere Application Server 664 when generating request pages 1208 logging off changing the automatic setting 32 the provisioning server 28 logging on cannot access Web Interface 60 cannot change password 61 cannot see Start Center 63 problems with Turkish locale 60 reports on users 1196 the provisioning server 28 troubleshooting 60
logical management operations cluster domains 733 login lockout for resource manager 685 LPAR troubleshooting adding MPIO hard disk fails 1107 LPARs Integrated Virtualization Manager 1016 troubleshooting cannot synchronize with WPAR 1104 recovering from problems 1096 VIO servers 1016 virtual server states 1067 VMControl 1040 LPARS creating multi-disk LPARs 1016 moving to host platforms 1016 resizing disks 1016 resource allocations 1016 LSI 1068 controller 383, 494 LSI MegaRAID IDEal RAID controller 383, 494 LSI MegaRAID SAS 8408E controller 383, 494 LSI-SAS RAID controllers 383, 494
M
machine types 4347 380, 491 4362 380, 491 4363 380, 491 4364 380, 491 4365 380, 491 4800-722 381, 492 4800-723 382, 492 4800-743 381, 492 4800-782 381, 492 4810-33H 381, 492 4836-132 381, 492 4838-137 381, 492 4838-520 382, 492 4838-720 382, 492 4840-544 381, 492 4846-565 381, 492 4851-5x4 381, 492 6625 381, 491 7971 380, 490 7972 380, 490 7973 381, 491 7977 381, 491 7978 381, 491 7979 381, 491 7981 380, 490 7984 381, 491 7985 381, 491 7996 380, 490 8480 380, 490 8482 380, 490 8485 380, 490 8486 380, 490 8647 380, 491 8648 380, 491 8649 380, 491
machine types (continued) 8670 380, 491 8671 380, 491 8673 380, 491 8676 380, 491 8685 380, 491 8832 380, 490 8835 380, 490 8836 380, 491 8837 380, 491 8839 380, 490 8840 380, 491 8841 380, 491 8843 380, 490 8848 380, 490 8849 380, 491 8850 380, 490 8853 380, 490 8863 380, 491 8864 381, 491 8865 380, 491 8866 381, 491 8870 380, 491 8872 380, 491 8877 381, 491 8878 381, 491 8886 380, 490 9229 381, 491 maintenance operations creating reports 617 pause/resume functionality 613 maintenance windows configuration 613 defining 613 parameters 613 planning 687 reporting 617 scalable distribution infrastructure 613 syntax 615 VCALENDAR Properties 615 VEVENT Properties 615 management center database performance 814 trimming data 814 Management Information Format see MIF 190 manually created MAC addresses 1107 master images capturing 507 composite images 512 creating a repository 502 creating versions 509 definition 498 deploying create a new computer 508 on an existing computer 510 importing OVF packages 513 KVM 1030 overview 504 publishing composite images 520 single images 520 synchronizing 505 troubleshooting create virtual server 525 Index
1267
master images (continued) troubleshooting (continued) OVF images 525 VMControl 1040 VMware troubleshooting 524 MAXADMIN creating a duplicate user 90 security 79 Maximo changing the user password 96 creating users 85 Maximo administrator user 131 maximo.properties 96 error after update 131 Microsoft Software Installer (MSI) 335, 449 Microsoft Active Directory new security group not displayed 123 PKCS12 92 running discovery 196 troubleshooting installation of Tivoli Common Agent fails 249 inventory scan fails 247 no hardware report information 246 only displays short names 246 verifying discovered resources 228 Microsoft Internet Explorer importing the certificate 95 Microsoft Updates Discovery troubleshooting fails on UNIX and AIX 249 Windows parsing error 998 MIF output 190 mount points adding to image repository 502 Mozilla Firefox importing certificates 95 MPIO 1016 adding hard disk fails 1107 multiple images 392 multiple server architecture replication manual 358, 469 scheduling 358, 468 MXServer configuring for SSL DB2 communication 106 myoutput.mif 190 Myrinet Cluster Expansion Card for BladeCenter 384, 494
network boot (continued) overview 273, 400 parameters 356, 467 USB drive command lines 276, 403 wizard 274, 401 without PXE 274, 401 network share module reference 357, 468 networking adding MAC address on discovered computers 226 configuring subnetworks 1138 IP addresses and examples 1133 linking a computer 1136 new in fixpack 1 NIC on virtual server templates 1072 NICs adding to file repositoriesfile repositories 603 hostname override 631 managing multiples 631 nodes cluster domains 728 WebSphere Application Server 734 Nortel Copper L2/L3 Switch Module 384, 494 Fibre L2/L3 Switch Module 384, 494 Network Layer 2-7 GbE Switch Module for BladeCenter 384, 495 not found DCM object 1253 provisioning workflow 1253 notification 35 NPIV requirements 1079 NPIV-enabled LPAR 1081 NPIV-enabled LPARs 1078
O
object ID finding 30, 37 object structures 1196 OEM installation 645 Open Services Gateway Initiative 630 operating system management basics 261 target system requirements 281 tutorial 301 operating systems deploying reference 351 discovering 208 in managing system life cycle 20 managing 23, 259 overview 259 prerequisites for managing 279 requirements for software deployment 546 requirements for target systems 282, 412 support for compliance 838 Oracle Database compliance managing 874 parameters for TADDM 836
Oracle Database (continued) compliance (continued) running recommendations 874 error messages upload server time out 792 OS bootable media devices CD/DVD command lines 278, 405 wizard 275, 402 USB drive command lines 276, 403 wizard 274, 401 OS configuration parameters modifying 360, 470 OS configurations binding 347, 459 OS Deployment deployment process 269, 398 managing multiple WinPE deployment engines 289, 420 operating system management process 268 server files backup 350 unattended setup image for ESX server 1061 OS deployment server command lines keeping confidential 345, 458 components 265, 392 replicating 358, 468 OS Deployment server CellBlades 295 configuring DHCP 297, 424 upgrading 352 OS Deployment servers system requirements 280, 411 OS Deployments virtual images replicating 445 OS management 407 OSGi branch office overview 584 bundles 630 OVF exporting an image 446 images 434 virtual images 434 importing composite master images 513 virtual images 436 master images 525
P
page Provisioning Task Tracking 55 refresh 55 return to previous 55 parameters base parameters 354, 464 file access module 356, 467 paravirtualization 1030 partitions browing files 331 changing layout 331
N
NAT server IP address change 784 netmask Solaris Zones 1091 network boot CD/DVD command lines 278, 405 wizard 275, 402 configuring for Solaris 293
1268
passwords adding to virtual images 430 agent registration 678 disable email notification 125 encryption key, changing 686 troubleshooting @ symbol is not supported 1003 cannot change the user password 124 patch management acquiring Windows patches offline 893 AIX approving recommendations 925 aquiring patches 922 commit feature 884 configuration 915 customizing the scanning model 923 day-to-day tasks 922 discovering targets 920 grouping target computers 921 installing 926 supported versions 914 testing 922 verifying compliance results 926 creating zones, regions, and depot servers 901 cross platform support 884 customizing the scanning model 965 deploying patches 1004 deploying patches and upgrades 25 discovering target computers 898 HP-UX 985 in managing system life cycle 20 installing patches individually UNIX and Linux 609, 1009 Windows 609, 1010 manually defining patches 707, 1007 offline patch acquisition through SDI 893 overview 877 process AIX 914 Red Hat Enterprise Linux 929 Solaris 975 SUSE Linux Enterprise Server 953 Windows 887 proxy server platform considerations 884 Red Hat Enterprise Linux approving compliance recommendations 945 approving in the data model 942 configuration 931 creating YUM repository 936 creating zones, regions, depot servers 939 day-to-day tasks 941 distributing patches 946 grouping target computers 935 installing patches 947 proxy server 938 publishing to depots 945 required software 940 supported platforms 928, 949 testing 942
patch management (continued) Red Hat Enterprise Linux (continued) verifying compliance results 948 reports 1193 Solaris add Sun Update Connection to data model 980 configuration 976 day-to-day tasks 981 installing patches 983 registering computers with Sun Update Connection 985 Sun Update Connection automation package 984 supported environments 974 verifying compliance results 983 SUSE creating YUM or SMT repositories 1089 SUSE Linux Enterprise Server approving compliance recommendations 967 approving patches 965 configuration 955 creating regions, zones, depot servers 961 day-to-day tasks 963 discovering and grouping targets 958 distributing patches 969 installing patches 970 installing software on targets 963 managing patches 971 proxy server 960 publishing patches to depots 968 supported platforms 952 testing patches 965 tutorial 955 verifying compliance results 970 the basics 877 troubleshooting checklist 993 duplicate patch recommendations 997 exclusive patches not installed 1001 patches not aquired if Red Hat Enterprise Linux has no SSL 1002 RHEL using SSH 1001 WUA install fails on Windows 7 1003 tutorial AIX 917 Red Hat Enterprise Linux 5 932 Red Hat Enterprise Linux 6 932 Solaris 977 Windows 895 uninstalling support by platform 884 using the MS_Patch_Offline_For_SDI automation package 893 Windows approving patches 906 aquiring patches 904 compliance recommendations 908 configuration 889
patch management (continued) Windows (continued) creating patch server 899 distributing patches 908 installing patches 909 process 887 required software on targets 903 requirements 896 testing 906 turn off automatic updates 905 verifying compliance 909 Windows Server Update Services 911 patch scan SDI 788 patches configuring file repositoriesfile repositories 604 deploying with SDI 702 path variables 56 pause/resume functionality configuration 613 implementation 613 maintenance operations 613 maintenance windows 613 parameters 613 reporting 617 syntax rules 615 peer domain cluster domains 722 peer-to-peer file sharing dual stack of IPv4 and IPv6 816 permissions adding to security groups 83 provisioning workflow 83 PKCS12 92 point-in-time snapshot capturing 316 polling intervals default 542, 655 device manager service 662 portlets cannot create graph with data model objects 67 ports 80 and 9513 682 8442 1040 9443 100 9510 652 agent manager 631 common agents 631 TCP/IP 631 POWER resource allocations 1016 VMControl 1040 power units and outlets 1142 PowerVM creating a repository 502 synchronizing images 505 prerequisites common agents 547, 550, 552, 554 installation media 566 Oracle 836 software deployments for AIX targets 546 for HP-UX targets 546 Index
1269
prerequisites (continued) software deployments (continued) for RedHat Linux targets 546 for Solaris targets 546 for SUSE targets 546 target computers AIX 562 HP-UX 565 RedHat Linux 560 SLES 561 Solaris 563 Windows 546, 556 WebSphere Application Server 836 private key 809 process workflows generating artifacts 1246 properties agent manager 679 impact from password changes 679 registration 684 provisining groups troubleshooting all objects listed 129 Provisioning Administrator discovery 146 image library 501 reports 1188 virtualization 1060, 1087 provisioning applications access control 84, 88 in managing system life cycle 20 provisioning computers displaying quickly the general page 55 quick server provisioning 52 running quick discovery 51 Provisioning Configuration Librarian discovery 146 reports 1188 provisioning groups adding and removing members 41 adding resources 40 AIX target computers for patch 921 combining queries 43 creating 569 creating data restrictions 45 definition 38 deleting 40 grouping together 44 members 42 nesting 41 reports 1193 running compliance checks 850 running quick discovery 42 scheduling and running compliance recommendations 852 scheduling compliance checks 851 security issues 44 security purposes 44 setting security constraints 44 troubleshooting can be changed without permission 121 types 143 uninstalling common agents 669 viewing 42
provisioning server does not start on Linux 68 does not start on Windows 68 logging on and off 28 troubleshooting cannot register target computers in firewall 777 Java Virtual Machine error 1183 SSH error 1183 provisioning settings reports 1195 provisioning task troubleshooting refused connection error 525 Provisioning Task Tracking 55 provisioning tasks adding to processes 1176 attaching an assisted workflow 1177 benefits 1157 bookmarking 1173 canceling 1172 claiming and initiating for a process 1178 creating 1161 creating a group from results 1174 creating a report 1173 deleting 1172 displaying a graphical view 1169 editing 1170 enabling automatic refresh 1169 integration with IBM Service Management 1174 key concepts 1157 managing definitions 1161 managing submitted tasks 1170 overview 1157 provisioning workflows and activity plans 1161 refreshing the target list 1166 reports 1194 requirements 1160 requirements for 1160 rerunning 1167 rescheduling 1171 restricting access 1169 running 1165 security roles 1160 setting a concurrency level for all 1162 setting a time limit 1168 sharing with users 1163 submitting and tracking 1164 tracking progress 1165 troubleshooting cannot be scheduled and submitted 1182 cannot delete 1182 HMC errors appear scrambled 1180 unsharing 1164 viewing by target computer 1167 viewing history 1164 provisioning workflows and provisioning tasks and activity plans 1161 and the deployment engine 20 as a provisioning task 1161
provisioning workflows (continued) deploying 20 enabling event transmissions 1229 permissions for security groups 87 receiving events 1228 report 1195 sending events 1225 sending provisoning server events 1227 starting from Tivoli Enterprise Console 1228 TCA_DeleteServerFromAMAndDCM 689 troubleshooting incorrect info during Tivoli Common Agent installation 784 proxy server patch management considerations 884 for Windows 900 Red Hat Enterprise Linux 938 pSeries creating multi-disk LPARs 1016 increasing virtual disk size 1030 virtual server template 505 publishing images individual 520 PXE booting without 274, 401 rogue servers 350 security breach 350
Q
Qlogic 4Gb SFF 383, 494 4Gb Std 383, 494 iSCSI Expansion Card for BladeCenter 384, 494 QLogic 4Gb Fibre Channel Switch Module 384, 494 quick server provisioning physical server 52 virtual server 52
R
RAID configuration 317 ramdisk creating from a bootable diskette 344, 457 WinPE2 288, 419 rbagent installing 442 reboot notification setting up on targets 610 Red Hat Enterprise Linux compliance results 948 patch management approved patches scan 944 approving compliance recommendations 945 approving patches 942 considerations 884 creating YUM repository 936
1270
Red Hat Enterprise Linux (continued) patch management (continued) creating zones, regions, depot servers 939 customizing the scanning model 943 day-to-day tasks 941 distributing 946 grouping target computers 935 installing 947 overview 929 prerequisites for server 934 prerequisites for target computers 935 process 929 proxy server 938 publishing to depots 945 required skills 933 required software 940 requirements 933 scalable distribution infrastructure 935 setting up compliance 943 supported platforms 928 supported platforms for RHEL 4 949 testing patches 942 tutorial 932 verifying compliance results 948 YUM Scan discovery configuration 943, 965 troubleshooting patches not aquired 1002 SSH 1001 Red Hat Linux custom installation for common agent support 931 RedHat KVM 1030 reference computer 312 reference image 310 refresh page 55 regions adding 818 automation package for managing large numbers of 822 creating for RHEL patching 939 creating for Windows patching 901 removing and changing 818 registration duplicate 681 password 678 reregistering 681 resource manager users 685 registry overview 682 retention period 680 size estimate 680 remediation actioning 852 on DB2 874 on IBM HTTP Server 877 on Oracle database 874 on WebSphere Application Server 875 scheduling and running 852 task overview 851
Remote Execution and Access (RXA) cannot connect with UNIX target computers 804 enabling logging 803 enabling on Windows target computers 803 troubleshooting 803 replication image 434 manual 358, 469 overview 284, 414 schedule 358, 468 server status 359, 469 reports ad hoc running 1200 attributes 1202 collecting discovered information 233 creating ad hoc report 1198 for compliance 1191 for discovery 1194 for patch management 1193 for provisioning global settings 1195 for provisioning groups 1193 for provisioning task tracking 1194 for provisioning workflow 1195 for virtualization management 1195 generate request page 1188 generating deployment reports 581 generating inventory reports 581 getting started 1188 listing custom reports 184 missing information when saved in CSV format 1207 object structures 1198 overview 1187 predefined 1187, 1190 for users logging on 1196 running 1200 prerequisites 1188 report view descriptions 1198 troubleshooting 1205 ad hoc report PDF file does not open 1209 corrupted text 1205 garbled text when saved to CSV format 1207 Microsoft Internet Explorer hangs 1208 user roles 1188 virtual servers 1095 requirements compliance 835 software dependencies 695 target systems 281 requirements for virtual Fibre Channel adapters 1079 reset interval 686 resource allocations KVM 1030 LPARs 1016 VMware 1076 resource manager attacks 685 changing registration password 684
resource manager (continued) changing the registration password 684 creating users 685 definition 630 installation SSLHandshakeException error 773 registration fails because of agentTrust.jks file 779 registration properties changes 684 resource members associating to administrative domains 737 resource pools adding computers 54 resources adding to computers 1133 adding to virtual server templates 1072 creating a group 39 creating dynamic groups 39 creating static groups 39 management overview 13 return codes for common agent installation 645 roles mapping 115 OS management 279 user roles 279 runbook automation 1238 virtual image management 406 user roles 406 rollback feature disabling 718 enabling 718 overview 717 removing backup software package blocks 719 setting a global variable 718 root password for Solaris Zones 1091 routers networking overview 1131 RSA credentials 809 runbook activating cron task 1241, 1253 activating escalation 1241 automating tasks using process workflows 1230 automation process 1235 building process workflows 1247 configuring HTTPS for secure communication 1244 configuring the runbook automation adapter 1241, 1253 customizing length of Action attribute 1240 installation of automation adapter PMP 1240 log files 1249 problems and limitations 1250 reference information 1231 running process workflows 1248 setting up logging level 1241
Index
1271
runbook (continued) setting up web service end point 1241, 1253 software requirements 1239 troubleshooting 1250, 1251, 1252 user roles 1238 Runbook hardware requirements 1238 requirements 1238 software requirements 1238 running runbook process workflows 1248 RXA for SCVMM server 1049 RXA discovery 155
S
SAN LPARs 1016 SAN and SAN fabrics 1156 SAN disks adding disk resources fails 1107 Sarbanes-Oxley reporting 853 SAS 2-port CFFv daughter card 383, 494 SAS Expander Switch Module 383, 494 saved images creating 519 creating a repository 502 creating a virtual server 520 definition 498 LPARs 1016 multi-disk virtual servers 1075 overview 517 publishing 520 troubleshooting KVM virtual server cannot be deleted 526 TCA_pingAgent fails 526 scalability cluster domains 722 deployment infrastructure overview 17 scalable distribution infrastructure 18 components 535 maintenance on target compouters 613 tutorial 567 scalable distribution infrastructure access rights 547 creating the infrastructure 572 deploying software 529 diagram 18 enabling IP addresses 1146 overview components 535 process 533 overview of deployment 17 requirements 546 Scalable Distribution Infrastructure tutorial managing Windows patches 895 scan.period maintenance windows 613 screensaver compliance checks 869 SCVMM server 1049
SDI patch scan Windows 788 see scalable distribution infrastructure 529 trace log 788 searching and filtering 30 tables 55 Secure Sockets Layer (SSL) protocol 682 security 350 avoiding vulnerability issues 350 certificates 128 certificates for common agent 675 configuration tasks 89 creating custom groups 85 creating duplicate MAXADMIN 90 creating security groups 84 data model object finder maximo 88 duplicate agent registration 681 dynamic content delivery 808 everyday tasks 89 groups duplicate records 122 Favorite applications 126, 127 LDAP 113 logs 119 MAXADMIN logon 126 network 351 overview 75 provisioning server cannot register target computers in firewall 777 PXE breach 350 Tivoli Common Agent error during registration 778 troubleshooting all objects are listed in group 129 cannot change passwords in web interface 124 CMS Java native library 131 error importing to keystore 130 error updating maximo.properties 131 only Latin supported for user names 128 provisioning groups can be changed 121 removing users 129 special characters in user names 123 user adding task to plan 122 user not logged off after session expires 62 user not logged off on timeout 123 users and groups are not synchronized 127 tutorial using LDAP 80 using Maximo 85 WebSphere Application Server changing data source password 657
security groups accessing applications Maximo 88 provisioning server 84 adding permissions Maximo security groups 87 provisioning security groups 83 adding users Maximo security groups 86 provisioning security groups 81 assigning permissions Maximo security groups 86 provisioning security groups 82 assigning provisioning workflow permissions 87 creating for the provisioning server 81 in Maximo 86 IBM Service Management compatibility 79 managing 102 overview 132 predefined 135 publishing images 520 types 143 security manager definition 78 security roles compliance 835 for discovery 153 task management 1160 server replication overview 358, 468 ServeRAID controllers 383, 493 ServerGuide 338, 451 service access points adding credentials to the VirtualCenter 1065 adding to virtual images 430 common agent 638 for VMware VirtualCenter 1065 KVM 1030 removing the default service access point 673 service access points Remote Access and Execution (RXA) 638 VMControl 1040 services agent manager service 682 agent recovery service 683 signing off provisioning server 28 signing on integrating single sign-on with Tivoli Monitoring 1211 silent installation creating installation image 641 Single Channel LSI Ultra320 SCSI controller 383, 494 single sign-on definition 144 integrating with Tivoli Monitoring 1211 SLES troubleshooting create virtual server 525
1272
SMT repsitory creating on SUSE Linux Enterprise Server 959 SMTP reports 1188 SOAP deployment engine 20 starting from Tivoli Enterprise Console 1228 software adding configuration options 716 capabilities 699 concepts 691 configuration 701 deploying products 607 discovery requirements 153 distributing 576, 582, 605 distributing files 602 distributing patches 601 distributing products 583, 635, 637 distributing software stacks 601 in managing system life cycle 20 installing 576, 582 installing patches 610 UNIX and Linux 609, 1009 Windows 609, 1010 installing products 607 installing stacks 611 model 692 overriding default interval for distribution 605 prerequisite check global 637 local 637 publishing 576 requirements for runbook automation 1239 troubleshooting publishing fails 791 uninstalling software products 626 software stacks 628 software catalog adding items manually 704 software definitions ways to add software 702 software configuration adjusting parameters 849 software configuration templates adding 716 changing 716 compliance checks 848 configuring cluster domains 724 copy from a software definition 717 copying 716 creating 714 definition 699 removing 716 types 699 using to build cluster domains 724 software deployment basic information 529 operating system requirements 546 software distribution access rights 547 canceling 606 configuring target computers 837
software distribution (continued) failure when filtered by group 790 infrastructures 18, 535 jobs not cancelled 793, 795 overview 582 process overview 23 reference information log files 809 through scalable distribution infrastructure 529 troubleshooting 795, 806 fails on HP-UX 791 installation fails for extracted file 1184 user roles 547 software installation adding 719 software model storing 692 terminology 692 software module custom actions 341, 454 software modules binding to targets 347, 459 creating for images 344, 457 custom actions 340, 453 deleting 673 driver 337 for images 332, 447 for unattended deployment 343, 456 pkgadd 336 RPM 336, 450 scheduling 346, 458 Solaris 336 software modulessoftware module creating a ramdisk 344, 457 software package blocks associating with software module 577 distributing to depot server 578 importing from the web interface 703 installing large blocks 608 large size client cache size 608 depot cache size 608 publishing to depot server 578 removing from depot server 581 saving to the local file repository 577 temporary directory 607 time out value 580 unpublishing 581 upgrading on targets 579 validating installation 581 Software Package Editor configuring 576 overview 751 software packages after installation process 607 overwritten by installation 790 REMOVE_SPB_AFTER_PROCESS parameter 607 removed from temporary directory 607 software patches distributing before installation 601
software products defining 622 deploying with the scalable distribution infrastructure 702 distribution overview 618 distribution requirements 620 importing 702 installing 624 manually defining 705 troubleshooting installation 625 software resources adding child 720 types of 689 updating the data model 721 upgrading 722 software resourcessoftware installations adding to software installations 719 software signatures adding custom defined 170 using command line 172 creating 173, 577 refresh custom 171 troubleshooting out of memory when querying 795 software stacks adding 712 definition 709 dependencies 715 display-cloned-stacks variable 714 duplicating 714, 719 Solaris configuring for OS deployment 293 creating unattended setup image 311 Flash archives 293 images creating unattended 308 installation server 292 OS deployments 292 patch management add Sun Update Connection to data model 980 approved patches scan 981 approviing recommendations 983 components 976 considerations 884 day-to-day tasks 981 discovering target computers 979 discovery 979 installing patches 983 missing patches scan 982 prerequisites for servers 979 prerequisites for target computers 979 process 975 required skills 978 requirements 978 supported platforms 974 tutorial 977 uninstalling 627 verifying compliance results 983 Sun Update Connection adding to the data model 980 managing patches 984 registering computers with 985 Index
1273
Solaris Zones adding credentials 1093 hardware resources 1089 automation package 1085 creating 1092 defining root password and netmask 1091 deleting 1095 initial discovery 1088 installing Tivoli Common Agent 1094 patch management supported environments 974 tutorial 977 process overview 1086 running an inventory scan 1094 troubleshooting 1096 tutorial 1085 virtual server states 1067 SOX reporting 853 SQL injection attacks 144 SSH importing OVF master images 513 troubleshooting Red Hat Enterprise Linux 1001 SSL configuring device manager service 108 for DB2 104 for FIPS compliance 103 MXServer for SSL DB2 communication 106 SSL-only 110 configuring DB2 client 111 dcm.xml for DB2 connection 109 profile for web interface port 100 troubleshooting RHEL patch issue 1002 upgrading JDBC for FIPS 103 VMControl 1040 Start Center multiple 29 not visible for new user 63 opening applications 30 overview 29 portlets create 55 Start Center, Updating 1204 static groups adding and removing members 41 creating 39 definition 78 types for security groups 143 status heartbeat function 682 of computers 45 updated reports 682 storage architecture 1154 devices and templates 1155 provisioning 1154 storage template problems with German symbols 66 storing images 392
subnetworks configuring 1138 Subscription Management Tool see SMT 959 subtask 35 Sun Update Connection adding to the data model 980 Enterprise application 984 registering computers 985 Solaris environments 975 Solaris tutorial 977 support tables BladeCenter-related products 383, 494 Ethernet adapters 382, 492 Lenovo mobile and desktop computers 381, 492 LSI RAID controllers 383, 494 SurePOS 382, 492 SUSE Linux Enterprise Server patch management approving compliance recommendations 967 approving patches 965 checklist 956 components 955 considerations 884 creating regions, zones, depot servers 961 creating SMT or YUM repository 959 day-to-day tasks 963 distributing patches 969 installing patches 970 installing software on targets 963 overview 971 prerequisites for servers 957 process 953 proxy server 960 publishing patches to depots 968 requirements environments 956 requirements for servers 957 requirements for target computers 957 skills required 956 supported platforms 952 target computer requirements 957 testing patches 965 troubleshooting scans 1002 tutorial 955 verifying compliance results 970 version 11 environments 953 SUSE Linux Enterprise ServerSUSE Linux Enterprise Server environments patch management approved patches scan 966 missing patches scan 967 switches adding and removing 1132 to a SAN 1156 to VLANs 1139 configuring 1131 creating trunk connections 1144 synchronizing image library 505
synchronizing (continued) images OS Deployment 304, 430 troubleshooting refused connection error 525 system life cycle 20 system profiles creating for VMWare 309 creating unattended AIX 306 system settings configuring 32 System x3105 380, 491 System x3200 380, 491 System x3250 380, 491 System x3400 381, 491 System x3455 381, 491 System x3500 381, 491 System x3550 381, 491 System x3650 381, 491 System x3655 381, 491 System x3755 381, 491 System x3800 381, 491 System x3850 381, 491 System x3950 381, 491
T
tables searching 55 TADDM business application considerations 234 defining business applications 234 SAPs 208, 836 running discovery 238 supported versions 205 troubleshooting discovery displays wrong version 253 tutorial 234 verifying discovered results 238 viewing business applications 238 target computers assigning the WOL device driver 738 changing the default polling interval 542, 655 common agent prerequisites AIX 562 HP-UX 565 Red Hat Linux 560 SLES 561 Solaris 563 Windows 556 configuring for software distribution 547, 837 configuring the default peering cache 655 distributing software package blocks 578 overriding 739 overriding the default WOL port 739 patch management AIX prerequisites 919 discovering targets 898 RedHat Linux prerequisites 935
1274
target computers (continued) patch management (continued) Solaris prerequisites 979 SUSE prerequisites 957 Windows prerequisites 897 PowerPC specifics on AIX 294 specifics on Linux 294 scalable distribution infrastructure 535 setting up restart notification 610 setting up the Wake on LAN (WOL) 738 turning on 738 upgrading software package blocks 579 using the Wake on LAN (WOL) 738 targets refreshing for task tracking 1166 task status 35 tasks automating using process workflows 1230 see provisioning tasks 1157 TCA common agent template parameters 633 TCA_pingAgent fails 526 TCP/IP ports for common agent and agent manager 631 temporary directory override 607 terminal servers configuring remotely 1143 definition 45 timeout software package blocks 580 VMControl 1040 TivGUID manual uninstallation 672 Tivoli Common Agent benefits 628 collecting diagnostic information 764 HP-UX cannot register 776 in scalable distribution infrastructure diagram 18 installing fails because of duplicated GUID 769 no tpm_default.xml file 773, 774 on Solaris Zones 1094 on VMware 1066 SSLHandshakeException error 773 IP address change on NAT server 784 subagents overview 631 standalone procedure 668 troubleshooting cannot be installed using Microsoft Active Directory 249 cannot communicate with agent manager 786
Tivoli Common Agent (continued) troubleshooting (continued) cannot read GUID on startup 784 collecting logs from target computer 765 computer name not updated after upgrade 780 data model not updated after uninstalling 783 fails when uninstalled manually 782 failure on AIX WPAR 1103 files deleted on restart after install 776 install fails on Solaris because of locale 770 install fails on Solaris SPARC target computers 770 install fails when using copy or put commands 772 install fails with invalid password 775 install failure on Red Hat 5 771 installing on Security-Enhanced Linux 768 no tpm_default.xml file 768, 772 registration fails because of agentTrust.jks file 779 registration request rejected by agent manager 787 renewing certificates 779 reregistering 779 security error during registration 778 TCA_PingAgent workflow hangs 785 truncated endpoint.properties file 778 uninstalling manually 781 troubleshoting fails if already installed 775 Tivoli Enterprise Console configuring to receive workflow events 1228 to send workflow events 1227 log files 1227 provisioning workflow events transmissions 1229 sending workflow failure events to 1225 starting workflows from 1228 Tivoli Monitoring integration with Tivoli Provisioning Manager 1211 Tivoli Provisioning Manager cannot import XML 71 error when primary server is disabled 67 launching from other products 1218 published task files saving on different depot server 806 security user not logged off after session expires 62 Tivoli Provisioning Manager for Images image types 399 obtaining build packages 439
Tivoli Provisioning Manager for Images (continued) overview 391 upgrading 439 upgrading from OS Deployment server 265 upgrading to a later version 462 virtual image management tasks 430 Tivoli Provisioning Manager for OS Deployment downloading 396 obtaining 396 upgrading 397 Tivoli Provisioning Manager Inventory Discovery 580 Tivoli Provisioning Manager Inventory Scan 574 Tivoli Storage Productivity Center viewing computers in 1214 Tivoli System Automation for Multiplatforms high availability disaster recovery installation 1122 integrating with the provisioning server 1119 toolkits administrators 689 agent registration tools 681 runtime logs 650 tools hypervisor 392 TPADMIN defined 135 publishing images 520 TPCOMPLIANCEANALYST 135 TPCONFIGURATIONLIBRARIAN 135 TPDEPLOYMENTSPECIALIST 135 TPDEVELOPER 135 TPMconfig.xml file wscanfs command 191 TPMEmailHelper 38 TPwebSERVICEUSER 135 trace log SDI 788 Transaction.properties 108 Transport Layer Security protocol 92 troubleshooting administrative console 799 agent manager installation 767 aids 59 auditing 69 basics 10 changing end point location 1252 common agent authentication errors 783 collecting diagnostic information 764 DBCS 774 installation 767 service access point 786 up-level over existing level 780 updgrading 763 upgrade failure 779 using sudo 774 verifying the running state 764 common problems 65 Index
1275
troubleshooting (continued) compliance 858 configdb 69 COPCOM123E cannot execute commands in Cygwin 66 depot updgrading 763 device manager jobs 751 diagnosing errors 59 discovery Windows 2003 and Windows XP 64-bit 252 dynamic content delivery 804 for logging off 59 image library 522 installing agent manager 767 insufficient memory for database synchronization 1251 IP addresses and host names 257 log files image library 522 server logs 863 Tivoli Common Agent 765 verifying 761, 863 log off 59 log on 59 logging on 60 passing TSRM parameters to the provisioning server 1251 patch scan fails with key import error 1002 patch scans on SLES 1002 patch scans on SLES 10 SP 1002 PMP installation 1252 process workflows length 1250 provisioning tasks 1180 reports 1205 garbled text when exporting to CSV format 1207 importing non-English CSV reports to Excel 1205 importreports.cmd error 1208 Microsoft Internet Explorer hangs 1208 runbook automation 1249, 1250, 1251, 1252 runbook automation logs 1249 runbook automation problems and limitations 1250 runbook automation tasks 1249 RXA connecting to the target 767 searching object selection not displayed after searching for other objects 67 server logs 761, 996 simple software product installation 625 software provisioning 760, 761 task management 1180 troubleshooting information for logging on 59 verifying log files 996
troubleshooting (continued) virtual servers discovery errors for host platform servers 1106 error creating a VMware virtual server 1101 failure on AIX WPAR 1103 overview 1095 synchronize WPARs with AIX LPAR 1104 VMware problems 1096 WPAR dedicated creation fails 1105 Windows Server Update Services 798 WSUS patch management 798 truststore file re-encrypting 679 tutorials discovery 230 getting started 27 listed 26 managing compliance 844 managing user access 80 patch management AIX 917 Red Hat Enterprise Linux 5 932 Solaris 977 Windows using SDI 895 replicating business applications from TADDM 234 security using LDAP 80 using Maximo 85 TADDM 234
U
unattended deployments setting up 271 unattended image troubleshooting 296 uninstalling CIT 670 common agent 670 common agents 669, 673 patches 1011 TivGUID 672 Tivoli Common Agent data model not updated 783 fails when done manually 782 manual 781 truncated endpoint.properties file 778 web interface extension 428 UNIX log files file system capacity exceeded 70 troubleshooting failure with Microsoft Update discovery 249 RXA does not connect to target 804 unknown resources ignoring 161 managing 160 overview 160
unknown resources (continued) reactivating 161 rediscovering 161 unpublishing images 520 updates documentation 1, 9 updating new features 1 Updating the Start Center 1204 upgrading common agents registration request rejected by agent manager 787 using scalable distribution infrastructure 667 software resources 722 to Tivoli Provisioning Manager for Images 439 troubleshooting agent or depot 763 upgradingcommon agent common agent deployment engine 667 USB drive network boot command lines 276, 403 wizard 274, 401 user access 75 tutorials 80 user datagram protocol (UDP) 742 user interface accessing 144 user roles for compliance 828 for software deployment 547 for software distribution 547 image library 501 patch management AIX 918 Red Hat Enterprise Linux 933 Solaris 978 SUSE Linux Enterprise Server 956 Windows 896 reports 1188 users adding to security groups 81 Maximo 86 cannot be removed using the web interface 129 create 55 creating in Maximo 86 using LDAP 81 creating duplicate MAXADMIN 90 managing overview 102 with LDAP 113 resource manager registration 685 troubleshooting not logged off on timeout 123 unlocking 686
V
variables configuring for tool integration 36
1276
variables (continued) system 34 versionInfo command error running on Windows 64-bit 69 versions creating master images 509 determining for common agent 764 VIO server LPARs 1016 virsh for KVM 1030 virt-manager for KVM 1030 virtual center discovery running 200 virtual Fibre Channel adapters 1078 virtual Fibre Channel adapters email notification 1084 virtual Fibre Channel adapters for LPARs 1080 virtual image management basics 387 hypervisor requirements 407 target system requirements 412 tutorial 437 virtual images adding credentials 430 capturing 443 deploying 432 discovering 443 editing properties 443 exporting 434 importing 436 installing 461 managing 387 overview 387 prerequisites 406 reference 462 replicating 443 streamlining management of 391 synchronization 304, 430 tasks 430 types 399 virtual machines see virtual servers 1073 virtual server templates adding multiple hard disks 1016 cloning 1071 configuring a netmask 1091 creating 1071 Solaris Zones 1089 Hyper-V 1049 VMControl 1040 VMware 1071 virtual server with virtual Fibre Channel 1083 virtual servers adding hard disks 1075 AIX LPARs 1016, 1056 creating using composite images 514 using saved images 519 deleting multiple 1077 discovering 441 Hyper-V 1049 KVM 1030 LPARs 1016 allocating resources 1016 overview 1013
virtual servers (continued) pSeries 1016 reports 1095 restoring or replacing 519 Solaris Zones activities 1066 adding credentials 1093 creating 1092 deleting 1095 discovering host platform servers 1089 installing Tivoli Common Agent 1094 intial discovery 1088 performing activities 1093 states 1067 Tivoli Common Agent installing on VMware 1066 troubleshooting adding MPIO hard disk fails 1107 cannot create from ESX server 1101 discovery errors 247 errors for host platform servers 1106 Libvirt discovery misses virtual servers 1105 Libvirt host platform discovery fails 1104 List tab opens too slowly 1106 removing if created without a software stack 53, 1074 VMControl 1040 VMware adding credentials to virtual servers 1069 adding credentials to VirtualCenter 1065 adding hard disks 1075 creating 1073 creating an image for ESX server 1061 creating the ESX server 1062 deleting 1077 discovering host platform servers 1077 discovering virtual servers 1066 enabling DRS on a cluster 1063 enabling HTTPS connection 1064 importing SSL certificate 1064 installing Tivoli Common Agent 1066 inventory scan 1070 powering on and off 1075 registering the ESX server 1063 WPARs 1027 VirtualCenter configuring 1062 enabling DRS on a VMware cluster 1063 virtualization error messages 1095 hardware and software requirements Solaris Zones 1087 VMware 1060 Hyper-V 1049 KVM 1030
virtualization (continued) logs 1096 LPARs 1016, 1056 overview 1013 prerequisites Solaris Zones 1087 VMware 1060 reports 1095, 1195 Tivoli Provisioning Manager for Images 265 troubleshooting 1095 List tab opens too slowly 1106 tutorial Solaris Zones 1085 VMware 1058 user roles 1060, 1087 VMControl 1040 WPARs 1027 VLANs adding switches 1132 to a network 1139 networking overview 1131 trunking 1140 vm see virtual servers 1073 VMC see VMControl 1040 VMControl 1040 synchronizing images 505 VMDK and VDDK 446 VMFS synchronizing images 505 VMMSync users and groups are not synchronized 127 VMMSYNC cron task does not run 120 does not synchronize information 120 synchronizing groups and users 82 LDAP 114 VMware activities 1066 add hard disk resources 1075 adding credentials to the VirtualCenter 1065 adding credentials to virtual servers 1069 adding disks 1075 changing resources 1076 configuring the VirtualCenter 1062 creating a repository 502 creating virtual server templates 1071 creating virtual servers 1073 deleting virtual servers 1077 download center 1061 enabling DRS on a cluster 1063 enabling HTTPS connection 1064 ESX servers deploying 1061 installing the server image 1062 managing with VirtualCenter 1062 registering 1063 Index
1277
VMware (continued) ESX servers (continued) unattended setup image 1061 importing OVF master images 513 importing the SSL certificate 1064 installing Tivoli Common Agent 1070 master images troubleshooting 524 moving virtual servers 1077 OS Deployments prerequisites 295, 423 problems 1096 process overview 1059 resizing disks 1076 troubleshooting cannot create using ESX server 1102 create from SLES 10 525 discovery errors for host platform servers 1106 tutorial 1058 virtual server states 1067 VMDK 446 VMWare 3.5 408 VMWare 4.0 configuration 408 requirements 408 VMware VirtualCenter Discovery error running vmware vi3 1103 synchronizing images 505 vst see virtual server templates 1071
W
WAIK 286, 417 Wake on LAN (WOL) assigning the WOL device driver to targets 738 overriding the default port 739 using 738 wasadmin user 98 Web Administration Tool changing user passwords 124 web browser importing the certificate for Internet Explorer 7 95 web interface configuring the List view 34 error 64 getting started 27 identifying the virtual host 100 locale non-English information center displayed in English 66 parameters 354, 465 port 9443 100 setting up your environment 26 troubleshooting cannot run remediation task 864 does not refresh 1181 SSL security warnings 124 Web interface 407 web interface extension deployment database 265, 392 installation 428
web interface extension (continued) installing 384, 429 installing on a hypervisor 442 web server discovery 215 hostname 576 port number 576 WebSphere Application Server adding resource members 737 administrative console troubleshooting 799 administrative domains 734 changing the data source password 657 compliance managing 875 parameters 837 running recommendations 875 TADDM parameter 837 configuring agent manager for 108 discovering software 203 discovery configuration 219 importing a certificate 100 installing with settings from another installation 612 trace logs 664 troubleshooting agent manager installation fails 802 cannot run backup tool 802 configuration generates incorrect information 869 What's new 1 wildcards using for table filtering 30 WIM 310 Windows See also WinPE2 images creating unattended 305 patch management acquiring patches 904 approval group 906 approved patches scan 906 approving patches 906 compliance recommendations 908 configuring patch server 899 considerations 884 distributing patches 908 installing patches 909 managing 911 required skills 896 requirements 896 requirements for servers 897 requirements for target computers 897 scanning for missing patches 907 supported configurations 889 supported platforms 886 testing patches 906 verifying compliance 909 Preinstallation Environment 2WinPE2 287, 418 Sysprep 2000 315 2003 314 2008 312
Windows (continued) Sysprep (continued) Vista 313 XP 314 troubleshooting discovery on 2003 and Windows XP 64-bit 252 error after installing version 7.2 65 FDCC 255 interactive patches not installed in silent mode 798, 999 Microsoft Updates Discovery parsing error 998 patches are not installed 997 provisioning server does not start 68 Windows Update Agent install fails 1003 tutorial patch management 895 Windows Server Update Services 798 Windows Update Agent install fails on Windows 7 1003 WinPE managing multiple deployment engines 289, 420 WinPE2 deployment engine 286, 287, 417, 418 hardware environments 286, 417 ramdisk 286, 417 creation 288, 419 wizards discovering resources 21 WPARs overview 1027 troubleshooting cannot synchronize with AIX LPAR 1104 dedicated creation fails 1105 network discovery fails 255 recovering from problems 1096 virtual server states 1067 wscanfs command configuring TPMconfig.xml file 191 previewing MIF output 190 WUA install fails on Windows 7 1003
X
xSeries 100 380, 490 205 380, 490 206 380, 490 206m 380, 490 225 380, 491 226 380, 491 235 380, 491 236 380, 491 255 380, 491 260 380, 491 305 380, 491 306 380, 491 306m 380, 491 335 380, 491 336 380, 491
1278
xSeries 345 346 366 445 460
(continued) 380, 491 380, 491 380, 491 380, 491 380, 491
Y
Yellow dog Updater Modified see YUM 959 YUM repository @ symbol is not supported for users or passwords 1003 Red Hat Enterprise Linux for patch 936 selection 943, 965 YUM repsitory creating on SUSE Linux Enterprise Server 959
Z
zones adding 818 adding to a SAN 1156 automation package for managing large numbers of 822 creating for RHEL patching 939 creating for Windows patching 901 modifying 818
Index
1279
1280
Printed in USA

TPM User Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TPM User Guide

Uploaded by

Copyright:

Available Formats

Provisioning Manager

Provisioning User Guide

Provisioning User Guide

Chapter 3. Discovering IT resources

Chapter 2. Controlling user access

. 203 . 203 . 223 . 226 . 227 . 227

Copyright IBM Corp. 2003, 2011

227 229 230 230 231 233 234

354 357 360 379 384

Chapter 5. Managing virtual images

234 237 238 239 244 245

Chapter 4. Deploying operating systems. . . . . . . . . . . . . . 259

IBM Tivoli Provisioning Manager Version 7.2.0.2 User Guide

Chapter 6. Managing images in the image library . . . . . . . . . . . 497

Chapter 7. Deploying software . . . . 529

. 760 . 761 763 . 809 . 809 . 810 . 822

Chapter 8. Checking compliance . . . 827

. 609 . 609 . 611

. 839 . 840 . 841 . 841 . 842 . . . . 843 844 845 851

Chapter 10. Configuring virtual servers . . . . . . . . . . . . . 1013

Chapter 9. Deploying patches . . . . 877

IBM Tivoli Provisioning Manager Version 7.2.0.2 User Guide

1086 1087 1087 1089 1093 1095 1095 1096 1101

Chapter 11. High availability disaster recovery . . . . . . . . . . . . . 1109

Chapter 13. Managing provisioning tasks . . . . . . . . . . . . . . 1157

. 1119 . 1120 . 1120 . 1120 . 1122 . 1127 . 1127 . 1129

. 1161 . 1161 . . . . . . . 1162 1163 1164 1164 1164 1164 1165

Chapter 12. Managing network resources . . . . . . . . . . . . 1131

. 1174 1174 . 1175 . 1176 . 1177 1179 . 1180

. 1180 1181 . 1181 . 1182 . 1183 . 1183 . 1184 . 1185

Chapter 15. Integrating with other IBM products . . . . . . . . . . . 1211

Chapter 14. Reports . . . . . . . . 1187

Notices . . . . . . . . . . . . . 1255 Index . . . . . . . . . . . . . . 1259

IBM Tivoli Provisioning Manager Version 7.2.0.2 User Guide

What's new in this version

Tivoli Provisioning Manager 7.2.0.2

Copyright IBM Corp. 2003, 2011

Feature Runbook automation

Resources Automating tasks using process workflows on page 1229

Managing virtualization with LPARs on page 1016

IBM Tivoli Provisioning Manager Version 7.2.0.2 User Guide

Resources Developer basics

IBM Integrated Service Management Library

Tivoli Common Agent

Tivoli Provisioning Manager 7.2.0.1

IBM Tivoli Provisioning Manager Version 7.2.0.2 User Guide

Resources Developer basics

IBM Integrated Service Management Library

Installing and configuring APDE

SOAP services Troubleshooting

Demos Tivoli Provisioning Manager Publications Welcome page

Tivoli Provisioning Manager 7.2

IBM Tivoli Provisioning Manager Version 7.2.0.2 User Guide

Feature Integration with IBM Service Management Managing software packages

Feature Scalable distribution infrastructure

Server management Serviceability

Task management and user interface

IBM Tivoli Provisioning Manager Version 7.2.0.2 User Guide

v Ability to customize provisioning workflows with extension point LDOs.

Information center updates

Automating tasks using process workflows on page 1229

Table 1. Information center updates (continued)