Tivoli Software Distribution User™S Guide

Home , Software distribution, Tivoli Software

Tivoli® Software Distribution User’s Guide Ve r s i o n 4 .1

Tivoli® Software Distribution User’s Guide Ve r s i o n 4 .1 Tivoli Software Distribution User’s Guide, Version 4.1

Copyright Notice © Copyright IBM Corporation 2000, 2001. All rights reserved. May only be used pursuant to a Tivoli Systems Software License Agreement, an IBM Software License Agreement, or Addendum for Tivoli Products to IBM Customer or License Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of IBM Corporation. IBM Corporation grants you limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry the IBM Corporation copyright notice. No other rights under copyright are granted without prior written permission of IBM Corporation. The document is not intended for production and is furnished “as is” without warranty of any kind. All warranties on this document are hereby disclaimed, including the warranties of merchantability and fitness for a particular purpose. U.S. Government Users Restricted Rights—Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corporation.

Trademarks IBM, Tivoli, the Tivoli logo, AIX, AS/400, DB2, OS/2, OS/400, Tivoli Enterprise, and TME are trademarks or registered trademarks of International Business Machines Corporation or Tivoli Systems Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Other company, product, and service names may be trademarks or service marks of others. Refer to “Notices” on page xix for additional notices. Contents Notices ...... xix Preface ...... xxiii Who Should Read This Guide ...... xxiii Prerequisite and Related Documents ...... xxiii What This Guide Contains ...... xxiv Conventions Used in This Guide ...... xxvii Online Help ...... xxviii Tivoli Software Distribution Icons ...... xxviii Accessing Publications Online ...... xxix Ordering Publications ...... xxx Providing Feedback about Publications ...... xxx Contacting Customer Support...... xxx Chapter 1. Overview of Tivoli Software Distribution..... 1 Coexistence with Previous Product Versions ...... 1 New Features in Version 4.1 ...... 2 Overview of Tivoli Software Distribution Highlights ...... 5 The Tivoli Software Distribution Environment ...... 11 Source Host ...... 12 Distribution Targets ...... 12 Software Packages...... 13 Object-Related Actions ...... 13 System Actions ...... 14 Program Actions ...... 15 Nested Software Packages ...... 16 Software Package Editor ...... 17

Tivoli Software Distribution User’s Guide iii Software Package Formats...... 17 Software Package (.sp) File ...... 18 Software Package Definition (.spd) File ...... 18 Software Package Block (.spb) ...... 18 Software Package Object ...... 19 Choosing a Software Package Format ...... 19 Tivoli Desktop Operations ...... 20 Change Management Operations ...... 20 Depot Management Operations ...... 21 Data Movement Operations ...... 21 Security...... 22 Chapter 2. Planning and Installing Tivoli Software Distribution ...... 23 Before You Start ...... 24 Tivoli Software Distribution Components...... 25 Tivoli Server Components ...... 25 Managed Node Components ...... 27 Endpoint Components ...... 29 Components in the Software Distribution Environment...... 31 Installing Tivoli Software Distribution Components ...... 32 Installation Mechanisms...... 33 Installing Tivoli Software Distribution with Tivoli Software Installation Service ...... 34 Installing Tivoli Software Distribution with the Tivoli Desktop...... 35 Installing Tivoli Software Distribution Using the winstall Command 36 Creating RIM Objects and Database Tables for Activity Planner or CCM...... 37 Creating Database Tables and Queries ...... 37 Creating RIM Objects ...... 38

iv Version 4.1 Installing the Tivoli Software Distribution Java Endpoint Package Editor ...... 39 Installation Options ...... 40 Installation Procedure ...... 41 Installing the Tivoli Software Distribution Pristine Tool ...... 44 Finishing Off...... 44 Upgrading from Tivoli Software Distribution 4.0 ...... 45 Upgrading Tivoli Software Distribution, Version 4.0 with the Tivoli Software Installation Service ...... 45 Upgrading Tivoli Software Distribution, Version 4.0 from the Tivoli Desktop...... 46 Upgrading Tivoli Software Distribution, Version 4.0 Using the wpatch Command...... 46 Removing Tivoli Software Distribution ...... 47 Uninstalling Tivoli Software Distribution Endpoints ...... 49 Uninstalling the NetWare Gateway...... 50 Enabling Language Support ...... 51 Language Support for Endpoint Components ...... 52 Chapter 3. Creating a Software Package...... 53 Launching the Software Package Editor ...... 53 Launching the Software Package Editor on Endpoints ...... 54 Launching the Software Package Editor on Managed Nodes...... 55 The Software Package Editor Window ...... 56 Creating the Appsample Software Package...... 58 Naming the Appsample Software Package ...... 60 Checking Disk Space...... 62 Adding Directories and Files ...... 65 Adding Windows Platform Actions to a Generic Container...... 71 Adding Windows Operating System Directories and Files ...... 73

Tivoli Software Distribution User’s Guide v Adding Windows Registry Objects...... 79 Adding Windows Shell Objects ...... 85 Adding Windows Profile Objects ...... 90 Adding Windows NT Services ...... 95 Adding OS/2 Platform Actions to a Generic Container ...... 97 Adding OS/2 Desktop Objects ...... 98 Adding OS/2 Profile Objects ...... 104 Adding Text File Objects...... 108 Adding an Execute Program Action ...... 116 Adding the Restart Action ...... 119 The Appsample Software Package ...... 120 Changing the Order of Objects in the Software Package...... 122 Setting Software Package-level Properties ...... 122 General Properties ...... 124 The Dependency Editor ...... 125 Server Options...... 127 Setting Server Options...... 128 Setting Advanced Server Options ...... 129 Log File Properties ...... 136 Description ...... 138 Copyright ...... 139 Variable List ...... 140 Nested Packages ...... 141 Editing Software Package Properties ...... 143 Program Actions in the Software Package Editor ...... 144 The Execute CID Program Action ...... 145 The InstallShield Program Action...... 146 The Microsoft Setup Program Action ...... 149 Remove Actions ...... 150

vi Version 4.1 Saving the Software Package ...... 151 Chapter 4. Using Tivoli Software Distribution on OS/400 ...... 155 Defining Software Packages with OS/400 Objects ...... 156 The OS/400 Native and Integrated File Systems...... 158 Using the OS/400 Software Package Editor ...... 159 Launching the OS/400 Software Package Editor...... 159 Adding OS/400 Libraries and Objects ...... 161 Adding OS/400 Objects ...... 164 Removing OS/400 Libraries...... 166 Removing OS/400 Objects...... 166 Adding OS/400 Licensed Programs ...... 167 Removing OS/400 Licensed Programs ...... 170 Changing an OS/400 Sysval...... 171 Using Non-OS/400-Specific Functions ...... 172 Adding Non-Native Objects to the OS/400 Native File System...... 172 Running an OS/400 Executable Program ...... 175 The Data Moving Service in an OS/400 Environment ...... 178 Chapter 5. Embedding MSI Installation Packages in a Software Package ...... 181 Benefits of Embedding MSI Packages ...... 182 Creating a Software Package That Embeds an MSI Installation Package 183 Using the Wizard to Embed an MSI Package ...... 184 Using Dialogs to Embed or Edit an MSI Package ...... 189 Making an MSI Installation Conditional...... 197 Chapter 6. How Does AutoPack Work? ...... 201 AutoPack Components...... 202

Tivoli Software Distribution User’s Guide vii AutoPack Configuration File ...... 204 Customizing the Configuration File ...... 209 Notes for Certain User Scenarios ...... 210 Dealing with Shared Objects ...... 212 Autopack.ini Default for Windows NT 4.0 and Windows 2000 ...... 213 Autopack.ini Default for Windows 98 ...... 214 Autopack.ini Default for UNIX Systems ...... 216 Chapter 7. Generating a Software Package Using AutoPack ...... 217 Running AutoPack...... 218 Creating the First Snapshot ...... 221 The Manual Installation Option ...... 229 Resuming the Second Snapshot ...... 231 The Automatic Installation Option ...... 235 Chapter 8. Using the PDF Importer Tool ...... 239 The Package Definition File...... 239 PDF Section ...... 240 Package Definition Section ...... 240 SetupVariation Setup Section ...... 240 Setup Package for Inventory Section ...... 240 FileIndex Section...... 240 Mapping the PDF to a Software Package ...... 241 Using the PDF Importer Tool...... 243 Sample Package Definition File ...... 247 NAVWNT.PDF ...... 247 Chapter 9. Understanding the Distribution Environment...... 251

viii Version 4.1 Introducing NoonTide ...... 253 Network Architecture...... 254 Subnet 1 ...... 256 Subnet 2 ...... 256 Subnet 3 ...... 257 Subnet 4 ...... 257 Subnet 5 ...... 258 Subnet 6 ...... 258 Subnet 7 ...... 258 Creating a Repeater Hierarchy ...... 258 Configuring Repeater Sites ...... 262 Setting Repeater Parameters...... 264 Step 1: List the Current Settings of the Repeaters’ Parameters 265 Step 2: Determine the Disk Space Requirements of the Applications to be Distributed ...... 269 Step 3: Check that the Electron and Pescado Sites Have the Required Disk Space and Memory ...... 269 Step 4: Set Electron’s Repeater Parameters...... 271 Step 5: Set Pescado’s Repeater Parameters...... 272 Step 6: Verify that the Repeater Parameters are Set Correctly 272 Step 7: Restart the Repeater...... 273 Using Repeater Depots ...... 273 Chapter 10. The Distribution Process...... 277 Creating a Tivoli Software Distribution Profile...... 278 Setting the Profile Subscribers ...... 282 Importing a Software Package into the Tivoli Environment...... 285 Creating a New Software Package and Importing it into a Software Package Profile ...... 285

Tivoli Software Distribution User’s Guide ix Importing an Existing Software Package into a Software Package Profile...... 286 Deleting a Software Package Profile ...... 290 Software Package Properties ...... 290 Calculating the Size of a Software Package ...... 292 Converting a Software Package ...... 293 Not-built to Built...... 294 Built to Not-built...... 295 Exporting a Software Package ...... 295 Change Management Operations ...... 297 Software Package States ...... 297 Executing Change Management Operations ...... 298 Install Operation ...... 299 Remove Operation...... 318 Undo Operation...... 320 Accept Operation...... 322 Commit Operation ...... 323 Verify Operation ...... 326 Distributing Nested Software Packages ...... 327 Things to Consider ...... 328 Nested Package Distribution Scenario ...... 330 Chapter 11. Tivoli Software Distribution Web Interface ...... 333 Basic Tivoli Software Distribution Web Interface Functions ...... 334 Enabling Basic Tivoli Software Distribution Web Interface Functions 335 Creating a Tivoli Administrator for Web Interface ...... 336 Configuring Policy Regions ...... 340 Software Package Properties ...... 341 Configuring Tivoli Software Distribution Web Interface ...... 342 x Version 4.1 Setting the Policy Region Attribute ...... 343 Setting the Software Package Object Attribute ...... 344 Using the Basic Tivoli Software Distribution Web Interface ...... 345 Notifying Users about Web Interface ...... 348 Enhanced Tivoli Software Distribution Web Interface Functions ...... 353 Enabling Tivoli Software Distribution Web Interface ...... 355 Creating the WebUI and WebUI-Restr1 Administrators...... 356 Configuring Policy Regions ...... 357 Software Package Properties ...... 358 Defining Software Categories...... 359 Managing the Web Server ...... 360 Using the Enhanced Tivoli Software Distribution Web Interface ..... 360 Using the Web Interface ...... 364 Managing the Local Machine from the Tivoli Software Distribution Web Interface ...... 373 Chapter 12. Integrating the Tivoli Inventory Database 375 The Configuration Repository ...... 376 The Query Facility ...... 377 Updating the Repository ...... 377 Upgrading from Tivoli Inventory, Version 3.6.x or Later...... 380 Upgrading a DB2 Database ...... 381 Upgrading a SQL Server Database...... 382 Upgrading an Oracle Database...... 382 Upgrading a Sybase Database ...... 383 Upgrading an Informix Database ...... 383 Enabling the Historical Database and Change Management Status Features 384 Disabling the Historical Database and Change Management Status Features ...... 385 Creating the SWDIST_QUERIES Query Library ...... 386

Tivoli Software Distribution User’s Guide xi Running a Query ...... 388 Desktop...... 389 Command Line ...... 391 Modifying SWDISTDATA_QUERY...... 392 Desktop...... 392 Command Line ...... 396 Chapter 13. Integrating the Tivoli Enterprise Console 397 Installation ...... 398 The tecad_sd.conf File...... 402 Tivoli Software Distribution Classes ...... 405 Chapter 14. Creating and Executing Activity Plans with Activity Planner ...... 407 Using the Activity Planner ...... 407 Launching the Activity Planner GUIs ...... 411 Activity Planner Roles ...... 411 Types of Activities...... 413 Defining an Activity ...... 414 Assigning Targets to an Activity ...... 417 Specifying a List of Target Names ...... 418 Specifying a File Name Containing a List of Targets ...... 419 Specifying an Inventory Subscriber as a Target ...... 419 Specifying Query Library Subscribers as Targets ...... 420 Using Variables to Specify Targets ...... 420 Specifying a Profile Manager...... 421 Conditioning the Execution of Activities ...... 423 Sorting Activities in Order of Execution...... 425 Scheduling When to Execute an Activity ...... 426

xii Version 4.1 Defining the Final Activity ...... 428 Defining the Properties of the Activity Plan ...... 429 Scheduling the Activity Plan ...... 430 Scheduling Plans to Execute within a Time Interval ...... 430 Scheduling Activity Plans to Run Periodically ...... 432 Defining the Targets of an Activity Plan...... 435 Defining Variables ...... 436 Saving the Activity Plan ...... 437 Removing Activity Plans or Activities ...... 438 Submitting and Monitoring Activity Plans ...... 439 Activity Plan Status ...... 440 Submitting an Activity Plan ...... 441 Pausing, Resuming, Canceling, and Restarting an Activity ...... 444 Launching the Distribution Status Console ...... 444 Updating the Status of an Activity Plan ...... 445 Deleting Submitted Activity Plans ...... 446 Cleaning Up the Database ...... 446 Chapter 15. Change Configuration Management ...... 449 Reference Models ...... 450 Subscribers ...... 452 Web Subscribers ...... 452 Reference Model Example ...... 453 Before You Start ...... 456 Using CCM...... 456 Creating the Reference Model Structure ...... 457 Adding Elements to a Reference Model ...... 459 Adding an SWD Element ...... 459 Adding an Inventory Element ...... 462

Tivoli Software Distribution User’s Guide xiii Assigning Subscribers to a Reference Model ...... 464 Assigning a CSV Subscriber ...... 465 Assigning a Profile Manager Subscriber...... 467 Assigning a Static Subscriber...... 468 Assigning an Inventory Subscriber ...... 469 Assigning Query Library Subscribers ...... 470 Saving a Reference Model in XML Format ...... 472 Modifying a Reference Model ...... 473 CCM and Activity Plans ...... 475 Previewing an Activity Plan...... 475 Submitting an Activity Plan ...... 476 Creating CCM Reports ...... 478 Chapter 16. Data Moving Service ...... 481 Configuring the Data Moving Service ...... 482 Data Moving Scenarios ...... 483 Sending Data to Multiple Destinations ...... 483 Data Retrieval from Multiple Origins...... 484 Deleting a File on Multiple Systems ...... 485 The Command Line Interface...... 486 Using Pre- and Post-Processing Scripts ...... 487 Example ...... 489 Chapter 17. Pristine Installations...... 491 Overview ...... 491 Typical Network Environment ...... 492 Pristine Preparation Site...... 493 Code Server ...... 493 Dedicated Pristine Gateway ...... 494 Prerequisites ...... 494

xiv Version 4.1 Code Server Prerequisites ...... 494 Pristine Tool Prerequisites ...... 495 System Diskette Creation Prerequisites...... 496 Pristine System Prerequisites ...... 497 Dedicated Pristine Gateway Prerequisites ...... 497 Installing the Pristine Tool ...... 497 Windows Steps ...... 498 Pristine Installation Scenario ...... 498 Step 1: Planning ...... 499 Code Server Objects ...... 499 Code Server Object Configurations ...... 499 Step 2: Creating and Maintaining Code Server Objects...... 500 Creating a New Code Server Object...... 501 Editing a Code Server Object...... 506 Deleting a Code Server Object...... 506 Step 3: Creating and Maintaining Code Server Object Configurations 507 Customizing the Operating System Response File ...... 507 Customizing the Tivoli Management Agent Response File ..... 510 Adding Device Drivers ...... 510 Partitioning the Client Hard Disk ...... 512 Defining a Reference Model ...... 513 Adding Configuration-Specific Information ...... 513 Step 4: Preparing a System Diskette...... 513 Step 5: Creating a Pristine Boot Diskette ...... 516 Step 6: Running a Pristine Installation ...... 518 Pristine Installation Procedure ...... 518 OS/2 Steps ...... 520 Pristine Installation Scenario ...... 520 Step 1: Planning ...... 521

Tivoli Software Distribution User’s Guide xv Code Server Objects ...... 521 Code Server Object Configurations ...... 522 Step 2: Creating and Maintaining a Code Server Object ...... 523 Creating a New Code Server Object...... 523 Editing a Code Server Object...... 525 Deleting a Code Server Object...... 526 Step 3: Adding System Files to Code Server Objects ...... 526 THINSRV...... 527 Configuring MPTS for Non-standard Network Adapters ...... 528 GETREXX ...... 528 Step 4: Creating and Maintaining Code Server Object Configurations 529 Customizing the Operating System Response File ...... 529 Customizing the Additional Required Software Response Files 531 Adding Device Drivers ...... 531 Partitioning the Client Hard Disk ...... 531 Defining a Reference Model ...... 532 Adding Configuration-specific Information...... 532 Step 5: Preparing the System Diskettes ...... 532 SEDISK...... 532 Adding the LAN CID Utility ...... 534 Step 6: Creating Pristine Boot Diskettes...... 534 Step 7: Running a Pristine Installation ...... 536 Pristine Installation Procedure ...... 536 Chapter 18. Upgrading Windows NT 4.0 Workstation to Windows 2000 Professional ...... 539 Environment Configuration ...... 539 Creating a Response File ...... 540 Copying the Files That You Need to Perform the Migration to the Tivoli Server ...... 541

xvi Version 4.1 Copying the Windows 2000 Professional Files to the Image Server ...... 542 Customizing the inst_w2000.spd Software Package Definition File ...... 543 Creating the Software Package on the Tivoli Server ...... 544 Subscribing the Endpoints to the Upgrades Profile Manager ...... 545 Distributing the Software Package to the Tivoli Software Distribution Endpoints ...... 545 Using the check_OS^1.0.spd to Verify the Upgrade ...... 546 Chapter 19. Upgrading Windows NT 4.0 with Service Pack5 or6 ...... 549 Environment Configuration ...... 549 Downloading the ntspx.spd Definition File to the Tivoli Server ...... 550 Copying the Service Pack Files to the Image Server...... 551 Customizing the ntspx.spd Software Package Definition File ...... 552 Creating the Software Package on the Tivoli Server ...... 554 Subscribing the Endpoints to the Upgrades Profile Manager ...... 554 Distributing the Software Package to the Tivoli Software Distribution Endpoints ...... 555 Appendix A. Authorization Roles...... 557 Setting Up Tivoli Software Distribution Profiles...... 557 Defining and Deleting Profiles...... 558 Performing Operations...... 559 Performing Activity Planner Operations ...... 559 Performing CCM Operations ...... 562 Performing Web Interface Operations...... 563 Glossary ...... 565 Index ...... 587

Tivoli Software Distribution User’s Guide xvii xviii Version 4.1 Notices

References in this publication to Tivoli Systems or IBM products, programs, or services do not imply that they will be available in all countries in which Tivoli Systems or IBM operates. Any reference to these products, programs, or services is not intended to imply that only Tivoli Systems or IBM products, programs, or services can be used. Subject to valid intellectual property or other legally protectable right of Tivoli Systems or IBM, any functionally equivalent product, program, or service can be used instead of the referenced product, program, or service. The evaluation and verification of operation in conjunction with other products, except those expressly designated by Tivoli Systems or IBM, are the responsibility of the user. Tivoli Systems or IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, New York 10504-1785, U.S.A.

Use of Apache Software

This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

The use of Apache software is regulated by the following license:

The Apache Software License, Version 1.1

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Tivoli Software Distribution User’s Guide xix 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: “This product includes software developed by the Apache Software Foundation (http://www.apache.org/).” Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names “Xerces” and “Apache Software Foundation” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected]. 5. Products derived from this software may not be called “Apache”, nor may “Apache” appear in their name, without prior written permission of the Apache Software Foundation.

THIS SOFTWARE IS PROVIDED “AS IS” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation and was

ISO 9001 Certification

This product was developed using an ISO 9001 certified quality system.

Certification has been awarded by Bureau Veritas Quality International (BVQI) (Certification No. BVQI - 92086/A).

BVQI is a world leader in quality certification and is currently recognized by more than 20 accreditation bodies.

Tivoli Software Distribution User’s Guide xxi xxii Version 4.1 Preface

® Tivoli Software Distribution provides a means of managing and distributing software across a multiplatform network. For distributions that encompass wide area networks (WANs), Tivoli Software Distribution has a built-in, WAN-smart capability that reduces internetwork traffic and ensures an efficient distribution.

This guide explains the concepts and procedures necessary for you to effectively use Tivoli Software Distribution to distribute software over local area networks (LANs) and WANs.

Who Should Read This Guide This guide is intended for system administrators who perform software package preparation and deployment operations. Users of this guide should have some knowledge of the following:

® ¶ The UNIX and PC platforms ¶ Shell programming ¶ Concepts such as directories, files, and symbolic links ¶ Operating systems running on target machines to which software is distributed

Prerequisite and Related Documents To use the information in this guide, you should be familiar with the following manuals: ¶ Tivoli Software Distribution Reference Manual Provides detailed information about managing and distributing software from the command line interface (CLI), including information about editing software package definition files. ¶ Tivoli Management Framework User’s Guide, Tivoli Enterprise™ Installation Guide, Tivoli Management Framework Planning for

Tivoli Software Distribution User’s Guide xxiii Preface

Deployment Guide, Tivoli Management Framework Maintenance and Troubleshooting Guide, and Tivoli Management Framework Reference Manual Provide detailed information and procedures to manage the Tivoli environment from the Tivoli desktop or the CLI, including information about configuring, maintaining, and troubleshooting your Tivoli installation. ¶ Tivoli Inventory User’s Guide Provides detailed information about managing hardware and software using Tivoli Inventory. ¶ Tivoli Enterprise Console User’s Guide and Tivoli Enterprise Console Adapters Guide Provides detailed information about integrating network, systems, database, and application management with Tivoli Enterprise Console.

What This Guide Contains Tivoli Software Distribution User’s Guide contains the following sections: ¶ Chapter 1, “Overview of Tivoli Software Distribution” on page 1 Provides an introduction to the application by describing the Tivoli Software Distribution features, platform-specific options, profile management, Tivoli Software Distribution terminology, and security. ¶ Chapter 2, “Planning and Installing Tivoli Software Distribution” on page 23 Describes how to install Tivoli Software Distribution using different installation mechanisms. ¶ Chapter 3, “Creating a Software Package” on page 53 Using the Appsample scenario, describes the steps required to create a software package using the Java™-based Software Package Editor graphical user interface (GUI), including setting software package properties and adding software package actions.

xxiv Version 4.1 Preface

¶ Chapter 4, “Using Tivoli Software Distribution on OS/400” on page 155 This chapter describes the Tivoli Software Distribution features that are specific for OS/400® operating systems. ¶ Chapter 5, “Embedding MSI Installation Packages in a Software Package” on page 181 ® Explains how to embed a Microsoft Software Installer (MSI) package in a Tivoli Software Distribution software package. ¶ Chapter 6, “How Does AutoPack Work?” on page 201 Introduces the underlying concepts of AutoPack technology, including the preparation machine, AutoPack system components, the configuration file, customizing the configuration file to suit particular workstation configurations, the snapshot, the differencing phase, and what AutoPack does to support shared objects. ¶ Chapter 7, “Generating a Software Package Using AutoPack” on page 217 Describes the steps required to create a software package using AutoPack from the Software Package Editor window. Using the AutoPack Guided Process, a software package is created that installs the Tivoli desktop application. ¶ Chapter 8, “Using the PDF Importer Tool” on page 239 Describes the steps necessary to import a Microsoft Systems Management Server (SMS) package definition file (PDF) using the Importer Tool, and map its contents to a Tivoli Software Distribution software package. ¶ Chapter 9, “Understanding the Distribution Environment” on page 251 Introduces a Tivoli management region scenario to illustrate how to configure a network topology. This chapter provides steps for setting up a distribution environment that uses endpoint gateways, repeaters, and repeater depots. ¶ Chapter 10, “The Distribution Process” on page 277

Tivoli Software Distribution User’s Guide xxv Preface

Describes setting up the Tivoli Software Distribution environment, including defining profile managers within a policy region and associating target machines with software package profiles. Describes Tivoli desktop functions such as using the build and unbuild function, using the import and export functions, and performing change management operations. ¶ Chapter 11, “Tivoli Software Distribution Web Interface” on page 333 The enhanced Tivoli Software Distribution Web Interface enables Web users on UNIX and Microsoft® endpoints to download, install, subscribe to, and verify software packages; access and subscribe to reference models for endpoint synchronization; and manage locally installed software packages using a Web-enabled browser. ¶ Chapter 12, “Integrating the Tivoli Inventory Database” on page 375 Provides a conceptual overview of the Tivoli Management Framework query facility and the Tivoli Inventory configuration repository. This chapter also describes how to enable the Tivoli Software Distribution historical database and change management status features and how to access information from the configuration repository. ¶ Chapter 13, “Integrating the Tivoli Enterprise Console” on page 397 Explains how to install and enable the Tivoli Enterprise Console integration product. This chapter also provides a description of the Tivoli Software Distribution event configuration file and event classes. ¶ Chapter 14, “Creating and Executing Activity Plans with Activity Planner” on page 407 The Activity Planner feature enables you to schedule the execution of a group of activities, submit them to be executed, and monitor and control them. Activities are single operations that are performed on a set of targets at specified times. Operations can include Tivoli Software Distribution, Version 4.1 operations or Tivoli Management Framework tasks

xxvi Version 4.1 Preface

¶ Chapter 15, “Change Configuration Management” on page 449 Change Configuration Management (CCM) help you to manage different, frequent software changes to different groups of workstations. It keeps track of software already installed to help you decide which workstations need a certain version of software, and provides a scalable and flexible way of specifying the required hardware and software machine configuration. It then applies the changes to update the machine to the new configuration ¶ Chapter 16, “Data Moving Service” on page 481 The Data Moving Service integrates data movement capabilities into the software package distribution process. ¶ Chapter 17, “Pristine Installations” on page 491 The Pristine feature provides support for installing new operating systems on Pristine machines, and then maintaining the new computers on the network. ¶ Chapter 18, “Upgrading Windows NT 4.0 Workstation to Windows 2000 Professional” on page 539 Describes how to upgrade Microsoft® Windows NT® Version 4.0 Workstation to Windows® 2000 Professional. ¶ Chapter 19, “Upgrading Windows NT 4.0 with Service Pack 5 or 6” on page 549 Describes how to upgrade Windows NT Version 4.0 to Windows NT Version 4.0 with Service Pack 5.0 or Service Pack 6.0. ¶ Appendix A, “Authorization Roles” on page 557 Describes the roles required to perform Tivoli Software Distribution Version 4.0 tasks.

Conventions Used in This Guide The guide uses several typeface conventions for special terms and actions. These conventions have the following meaning: Bold Lowercase or mixed-case commands, command options in a syntax statement, the names of objects

Tivoli Software Distribution User’s Guide xxvii Preface

in procedures that you type, select, click, or press, or any other information that you must use literally appear like this,inbold. Italics Variables, new terms, and words and phrases that are emphasized appear like this,initalics. Monospace Code examples, output, and system messages appear like this,inamonospace font.

References in this guide to other documents, in the Tivoli Software Distribution library or other libraries, do not carry version numbers, unless a specific down-level version is referenced. The latest version is assumed in all such references.

Online Help Tivoli Software Distribution, Version 4.1 provides contextual online help. To display help information you can do one of the following: ¶ Select the Help button at the bottom of a dialog to see a description and the accepted values of the elements contained in the dialog. ¶ From an open dialog, press F1 to see an explanation of that dialog. ¶ Select Help from the Help pull-down menu to open the help browser and display the table of contents.

Tivoli Software Distribution Icons The following icons represent the Tivoli Software Distribution profile resource displayed on the Tivoli desktop in different formats:

Icon for software package profile icon in built format.

xxviii Version 4.1 Preface

Icon for software package profile icon in not-built format.

Icon for empty software package profile.

Software package profile resources are created in the context of a profile manager and are distributed to subscribing systems or profile managers managed in the Tivoli environment.

Accessing Publications Online The Tivoli Customer Support Web site (http://www.tivoli.com/support/) offers a guide to support services (the Customer Support Handbook); frequently asked questions (FAQs); and technical information, including release notes, user’s guides, redbooks, and white papers. You can access Tivoli publications online at http://www.tivoli.com/support/documents/. The documentation for some products is available in PDF and HTML formats. Translated documents are also available for some products.

To access most of the documentation, you need an ID and a password. To obtain an ID for use on the support Web site, go to http://www.tivoli.com/support/getting/.

Resellers should refer to http://www.tivoli.com/support/smb/index.html for more information about obtaining Tivoli technical documentation and support.

Business Partners should refer to “Ordering Publications” on page xxx for more information about obtaining Tivoli technical documentation.

Tivoli Software Distribution User’s Guide xxix Preface Ordering Publications Order Tivoli publications online at http://www.tivoli.com/support/Prodman/html/pub_order.html or by calling one of the following telephone numbers: ¶ U.S. customers: (800) 879-2755 ¶ Canadian customers: (800) 426-4968

Providing Feedback about Publications We are very interested in hearing about your experience with Tivoli products and documentation, and we welcome your suggestions for improvements. If you have comments or suggestions about our products and documentation, contact us in one of the following ways: ¶ Send e-mail to [email protected]. ¶ Fill out our customer feedback survey at http://www.tivoli.com/support/survey/.

Contacting Customer Support The Tivoli Customer Support Handbook at http://www.tivoli.com/support/handbook/ provides information about all aspects of Tivoli Customer Support, including the following: ¶ Registration and eligibility. ¶ How to contact support, depending on the severity of your problem. ¶ Telephone numbers and e-mail addresses, depending on the country you are in. ¶ What information you should gather before contacting support.

xxx Version 4.1 otaeDistribution Software .Oeve fTivoli of Overview 1. 1 Overview of Tivoli Software Distribution

With Tivoli Software Distribution, you can install, configure, and update software on networked systems from a single source system, thereby eliminating the task of manually updating software on numerous systems.

You can create and distribute desktop and client/server applications, manage the software life cycle, automate system inventories, and monitor system and configuration changes.

Tivoli Software Distribution can quickly and reliably deploy software across multiplatform networks, which can include UNIX, NetWare, Windows, OS/400, and OS/2® systems at remote sites. Refer to the Tivoli Software Distribution Release Notes for details about supported platforms for this product.

Coexistence with Previous Product Versions Tivoli Software Distribution, Version 4.1 is an upgrade to Version 4.0. Neither product is an upgrade to Tivoli Software Distribution, Version 3.6.x or Version 3.1.x, or NetView DM/2, Version 2.1.

Tivoli Software Distribution, Version 4.1 can be installed as an upgrade of Version 4.0, or as a fresh installation, if Version 4.0 is not already installed on the same system. Both Version 4.1 and Version 4.0 can coexist in a network (not on the same machine) with

Tivoli Software Distribution User’s Guide 1 Highlights

each other and with other versions of Tivoli Software Distribution (3.6.x, 3.1.x) and NetView DM/2, to provide backward compatibility and a flexible migration path for existing customers.

For customers running Tivoli Software Distribution, Versions 3.1.3, 3.1.4, 3.1.5, and NetView DM/2, Version 2.1 a tool is available to help you migrate to the current version of Tivoli Software Distribution. This tool is available as a PTF; refer to Tivoli Software Distribution Release Notes for details.

If you are a new customer and plan to use either Tivoli Plus modules or a Tivoli Application Management product, you must also install Tivoli Software Distribution, Version 3.6.2.

The wfptosp migration command has been provided to assist you in migrating TME 10 Software Distribution Version 3.6 (or later) file packages to Tivoli Software Distribution, Version 4.1 software packages. No migration is necessary for Version 4.0 software packages. They can co-exist with Version 4.1 software packages in the Version 4.1 environment. Refer to the Tivoli Software Distribution Reference Manual for more information about the wfptosp command.

New Features in Version 4.1 This section lists the new and changed functions of Tivoli Software Distribution: ¶ Version checks You can define a software package as versionable and specify whether it is a refresh package or a patch. Refreshes are not installed if a later version of the package is already installed. Patches are not installed unless the version to which the patch applies is already installed. ¶ Dependency You can define an expression that makes the installation or removal of a software package dependent on meeting hardware and software prerequisites.

2 Version 4.1 Highlights otaeDistribution Software .Oeve fTivoli of Overview 1. ¶ Byte-level differencing With byte-level differencing, you create and distribute delta packages for installation, thereby significantly reduce network traffic. A delta package is created from the differences this technology detects between the software package to be installed (version package), and the base package already installed on the target system, and only the delta package is distributed. The delta package is typically smaller than either the version package or the base package. The changes contained in the delta package are applied to the base package thereby upgrading it to the new version. For a detailed explanation of how byte level differencing works, see the Tivoli Software Distribution Reference Manual. ¶ Data movement This is a feature that provides commands to distribute, retrieve, and delete files from machines in a Tivoli Management environment. It supports ASCII/EBCDIC conversion and code page translation for text files. ¶ Pristine Operating System Install This tool provides the capability to make an unattended installation of operating systems (Windows 98 Second Edition, Windows NT 4.0 Workstation and Windows 2000 Professional; OS/2 4.0 and OS/2 4.5) on a system with no operating system installed (even with unpartioned hard disks) or on a system that is to be completely reformatted. The installation process includes assigning the pristine system to a Tivoli gateway, and optionally initiating a Change Configuration Management process. ¶ Windows 2000 Microsoft Installer Provides the capability to use Tivoli Software Distribution to create a software package that embeds a Microsoft Software Installer (MSI) package. Both Microsoft Installer products and patches are supported. ¶ Mobile support This feature enhances the capability to deliver software to mobile users. By means of mobile support, end-users can decide

Tivoli Software Distribution User’s Guide 3 Highlights

which distributions to download or reject. While downloads are in progress, users can also pause and resume them. ¶ Activity Planner Activity Planner enables you to schedule the execution of a group of activities, submit them to be executed, and monitor and control them. Activities are single operations that are performed on a set of targets at specified times. Operations can include Tivoli Software Distribution, Version 4.1 operations or Tivoli Management Framework tasks. ¶ Change Configuration Management (CCM) CCM provides the capability of managing an environment by defining a reference model in which you specify the combination of software packages that satisfies the business needs for a set of workstation users within an enterprise. It helps you to bring the configuration of these machines from their current state to the specified target state. It also includes support for package versioning, software dependencies (pre-requisites, co-requisites, and ex-requisites), hardware dependencies and endpoint logins. ¶ Enhanced Tivoli Software Distribution Web Interface This interface enables Web users on UNIX and Windows endpoints to download, install, subscribe to, and verify software packages; access and subscribe to reference models for endpoint synchronization; and manage locally installed software packages and the local software package block repository. ¶ OS/400 endpoint support The OS/400 endpoint support extends the capabilities of Tivoli Software Distribution to managing software packages for OS/400 target systems. Tivoli Software Distribution includes an OS/400 Software Package Editor (SPE). You use the SPE on an NT system, which has a TCP/IP connection to an OS/400 system that is used as a software package preparation site. You can build software packages that include OS/400 objects, such as libraries, objects, and licensed programs, and changes to OS/400 system values. In addition, a software package for an OS/400 system can include standard actions to add non-OS/400 files and directories to an OS/400 system and to execute user programs on

4 Version 4.1 Highlights otaeDistribution Software .Oeve fTivoli of Overview 1. an OS/400 system. The data moving service supports movement of files between OS/400 endpoints and Tivoli Software Distribution Source Hosts. ¶ Install from CD and file server Enables you to specify that the software package to be installed is to be retrieved from a file server or a CD-ROM rather than on the source host.

Overview of Tivoli Software Distribution Highlights Tivoli Software Distribution provides a centralized software-management system with which administrators can use software packages to install and configure new applications, update existing software with newer versions, and synchronize software on distributed systems. The new features that Tivoli Software Distribution, Version 4.1 makes available to you, enhance all the features that are retained from Tivoli Software Distribution, Version 4.0, the highlights of which are as follows: ¶ Remote distribution and scalability: a centralized point of control for automated software distribution across heterogeneous network computing environments. ¶ Software package preparation facility: the Software Package Editor provides several ways for you to create and edit a software package. It supplies the following features: v Unified software package Tivoli Software Distribution makes use of a simplified single content packaging format called the software package. All of the techniques used to create software packages are based on this single file format. Therefore, a software package created using AutoPack is identical to a package created manually using the Software Package Editor, and both can be edited using any of the available techniques explained in this chapter. v Variables Variables can be used to express any attribute value of type string contained in the software package, making a software

Tivoli Software Distribution User’s Guide 5 Highlights

package more generic for use on different target systems. For example, it is not necessary to create several software packages for different platforms. You can substitute the platform-specific information with variables and use the same software package for distribution to multiplatform networks. Refer to the Tivoli Software Distribution Reference Manual for more details on using variables in the software package. v Conditions You set conditions on the actions contained in a software package or on the entire software package. Using conditions, you define the circumstances under which an action is executed. For example, you can specify which actions are to be executed on Windows 98 target systems and which are to be executed only on Windows NT. This feature expands upon the flexibility of software packages. v Third-party and native installation support Common third-party packaging formats are supported. Existing content prepared in these native formats, and the associated installation utilities and response files, can be packaged within the software package. Alternatively, they can be referred to as external files if they are already accessible by the target systems such as the following: – Microsoft Setup – InstallShield – Configuration, installation, and distribution (CID) programs ¶ Automatic software package generation: AutoPack automatically generates a software package by employing scanning and differencing technology, and comparing two successive “snapshots” of a preparation machine. ¶ Import application definition files of a different format: the PDF importer tool leads you through the process of importing a Microsoft package definition file (PDF) and converting it into a software package.

6 Version 4.1 Highlights otaeDistribution Software .Oeve fTivoli of Overview 1. ¶ Tools for creating InstallShield and Microsoft Setup program objects that can be added to the software package. ¶ Support for file packages of previous product releases. File packages and the new software package format can co-exist within the same profile manager as different resource types. ¶ A migration tool to convert file package objects and file package definition files to software package objects and software package definition files. The keywords contained in file packages created with a previous product release are mapped to software package stanzas, attributes, and commands. Refer to the Tivoli Software Distribution Reference Manual for more information about migration procedures. ¶ Software package distributions and operations: using the Tivoli desktop, you can perform change management operations to fully automate the distribution and installation of software. Support features include the following: v Automatic undo You can perform an undo operation on the software package so that, in the event of a fatal error during the installation process, the undo operation is triggered automatically and returns the system to its state prior to the execution of the last installation or removal operation. This means that any files added by the installation that did not exist before the distribution are removed. Files that existed before the distribution and were removed are added back. Files that existed prior to the distribution and were replaced, are restored to the previous copy. This is also true for any additions, deletions, or changes made to configuration or system information such as registry changes, .INI file entries, folders, and shortcuts. v Verification of installed software packages You can perform a verify operation of a software package to verify that the target objects have been successfully installed on the target system. v Locked file support

Tivoli Software Distribution User’s Guide 7 Highlights

If a locked file is encountered during a distribution, normally it cannot be updated. Distributing the software package in transactional mode enables you to take advantage of the locked file support feature, which permits the updating of locked files by specifying that the target system is to be restarted at the time of installation or at the next regular system start up. v Renaming if locked This function obviates the need to reboot a workstation immediately after a distribution when a locked file is encountered. A copy of the file is made and renamed. v Shared object support Because many applications use the same resources, such as files, directories, and registry entries, these shared objects must be identified in the software package. Using a shared attribute, for example, on files and directories, you can share files and directories among multiple applications. If a software package is designed to remove an application from a target system, and one of the objects contained in the software package is identified as a shared resource, the object is removed when the last application using this resource is removed. If a shared resource in a software package is found to exist on the target, the latest version of the resource is used. v File version support You can set different properties on objects in the software package to manage their behavior. For example, if an object contained in a software package already exists on the target system, you can configure the object properties so that Tivoli Software Distribution replaces the existing copy only if the creation date of the copy is earlier than the file or directory contained in the software package. v Source and repair functionality The repair functionality reduces network congestion. It identifies which source and target objects have been modified or corrupted since the last successful installation of a

8 Version 4.1 Highlights otaeDistribution Software .Oeve fTivoli of Overview 1. software package, and rebuild the software package with only these objects rather than installing the entire package again. ¶ A more complete distribution engine: Tivoli Software Distribution performs distributions of large amounts of data to multiple target systems. It relies on the multiplexed distribution (MDist 2) service, which it uses to simultaneously distribute large amounts of data to targets in an enterprise. The benefits include the following: v Asynchronous delivery The MDist 2 service submits distributions and, using a graphical user interface or commands, you can immediately check the status of each distribution on each target system without waiting until the distribution has completed for all targets. v Assured delivery MDist 2 distributions are cached in local files on each repeater. If a connection to a receiver cannot be established or is broken, the distribution is maintained in the cache until the connection is re-established and the distribution can be delivered. This feature includes the ability to resume distributions after network errors caused by machine restarts or power failures. v Checkpoint restart When a distribution is interrupted due to a network failure, machine restart, or power failure, the distribution is automatically resumed from the point where the interruption occurred, if due to a network error, rather than resending the entire distribution from the source host. If the interruption is due to a power failure or machine restart, the distribution is resumed from the last successful checkpoint before the interruption. However, a distribution that you terminate restarts from the beginning. Paused distributions exploit the checkpoint restart feature. The checkpoint restart feature is a Tivoli Software Distribution default. Refer to the Tivoli Software Distribution Reference Manual for more information about checkpoint restart.

Tivoli Software Distribution User’s Guide 9 Highlights

v Distribution control You can use MDist 2 to access and control data distributions initiated by different applications. The graphical user interface (GUI) displays a list of all completed and pending distributions and their status on each endpoint (waiting, successful, failed, in progress, paused, interrupted, unavailable, cancelled, or expired). v Pending distribution queues MDist 2 distributions can have three priority levels: low, medium, or high. Priority levels determine the order in which distributions are handled by repeaters. Distributions with higher priority levels are handled before ones with lower priority. Distributions with the same priority level are handled in the order in which they are received by a repeater. MDist 2 also allows a maximum number of available connections to be specified for each priority level. A distribution with a given priority level uses the number of connections reserved for its priority level plus any connections allocated for lower priority levels. v Depoting A depot is a directory on the repeater site that enables you to temporarily or permanently store data segments (that is Software packages) associated with software package distributions. This enables software distributions to be stored on nodes closer to the targets. You can push software packages from the depot, rather than from the source host, to target systems associated with that depot.

These features enable you to perform rapid and optimal software distributions. For more information about the MDist 2 service, refer to the Tivoli Management Framework Planning for Deployment Guide. ¶ Operating system upgrades: Tivoli Software Distribution supports operating system upgrades for the Windows operating system family.

10 Version 4.1 Highlights otaeDistribution Software .Oeve fTivoli of Overview 1. ¶ Application configuration: by installing software packages, you can perform actions such as changing the registry, adding desktop icons, adding statements to system files, and creating folders and shortcuts. Tivoli Software Distribution eliminates the need to create scripts and programs to configure an application. You can package the required action in the software package. ¶ Integration with other Tivoli applications: the following list describes Tivoli Software Distribution’s integration with other applications and services: v You can use Tivoli Inventory and the Tivoli Management Framework query facility to query a configuration repository to determine the appropriate targets of a distribution.This facility also enables you to track information about software distributions and the change management status of software packages on target systems. v Using the Tivoli Management Framework Scheduler, you can schedule jobs at a future time, repeat scheduled jobs indefinitely, or repeat them a specified number of times. v Through integration with the Tivoli Enterprise Console, Tivoli Software Distribution sends events to the event console for all distribution operations. ¶ Network and system optimization: GUI-based management for ease of use, coupled with a powerful command line interface (CLI) and advanced text-based options.

The Tivoli Software Distribution Environment When you install Tivoli Software Distribution, you add a profile type, the software package, to the Tivoli environment. You can then manage the software package within the Tivoli Management Framework. Software packages are imported into the Tivoli environment and are associated with profiles. Software package profiles contain references to data, and instructions about how the data is to be distributed. All references to data are resolved at distribution time.

Tivoli Software Distribution User’s Guide 11 Tivoli Software Distribution Environment

Policy regions, profile managers, and profiles are mechanisms provided by the Tivoli Management Framework to help organize resources hierarchically. You use this hierarchy to associate software packages with target machines. As with other Tivoli profile-based applications, Tivoli Software Distribution functions in the context of a profile manager. Software packages are created in a profile manager, which contains profiles and links subscribers to profiles. Source Host The source host is the system on which the files contained in the software package block are obtained, where the software package block is stored, and where the files referenced in the software package and software package definition file are located. Any UNIX, OS/2, Windows NT, and Windows 2000 system in your Tivoli environment can be a source host after Tivoli Management Framework and Tivoli Software Distribution are installed.

The effects of distributing a Tivoli Software Distribution profile distribution are different than those of other Tivoli profiles. For example, when you distribute a software package profile, you execute actions such as adding files and directories from the source host to the target, removing files and directories from the target, checking disk space on the target, and adding Windows registry keys. For more information about profiles and profile managers, refer to the Tivoli Management Framework Planning for Deployment Guide. Distribution Targets Tivoli Software Distribution, Version 4.1 enables you to distribute software packages to subscribers. A subscriber is an endpoint or a profile manager that is the target of the distribution. In the Tivoli environment, an endpoint is a Tivoli client that receives Tivoli operations. Only endpoints can be targets of distributions. Managed nodes are no longer supported as targets. The Tivoli Management Framework endpoint agent must be installed on managed nodes to become possible targets of a software distribution. Each endpoint is assigned to an endpoint gateway, which provides all communication services between a group of endpoints and the rest of the Tivoli environment. The gateway includes the multiplexed distribution

12 Version 4.1 Tivoli Software Distribution Environment otaeDistribution Software .Oeve fTivoli of Overview 1. (MDist 2) function, enabling this gateway to act as the fanout point for distributions to many endpoints. Refer to the Tivoli Management Framework Planning for Deployment Guide for detailed information about how endpoints and gateways can be configured and used in the Tivoli environment.

Tivoli Software Distribution, Version 4.1 supports mobile endpoints.This enables mobile computer users to view a queue of all the distributions pending for their machine and control when and in what order they will receive their distributions. Refer to the Tivoli Management Framework Planning for Deployment Guide for more information about configuring mobile endpoints.

Software Packages A software package contains a collection of actions to be performed on a workstation. After you create a software package and catalog it at the Tivoli Software Distribution server, you can use change management operations to manage how the package actions are to be executed. The software packaging facility, the Software Package Editor, provides several ways for you to create and edit software packages. It organizes actions into three categories: add and remove object-related actions, system actions, and program actions. Object-Related Actions The add and remove object actions drive the engine to add the specified object to the system or to remove it from the system. Objects can be files, directories, registry keys, registry values, and so on. The types of add and remove actions and their objects include: ¶ Text file objects v Lines v Command lines v Tokens ¶ File system objects v Files v Directories v File system links ¶ OS/400 objects

Tivoli Software Distribution User’s Guide 13 Tivoli Software Distribution Environment

v OS/400 libraries v OS/400 objects v OS/400 licensed programs ¶ Windows registry objects v Keys v Values ¶ Windows shell objects v Folders v Links ¶ Windows profile objects v Sections v Items ¶ OS/2 desktop objects v Generic objects v Folders v Programs v Shadows ¶ OS/2 profile objects v Profiles v Items ¶ Windows NT services System Actions These actions include the following: ¶ Check disk space. Include this check in your software package to be sure there is sufficient disk space on the target machine. ¶ Restart. Insert this action in your software package if a computer or operating system restart is necessary with the installation of an application. ¶ OS/400 system value. Use this action to change OS/400 system values (SYSVAL).

14 Version 4.1 Tivoli Software Distribution Environment otaeDistribution Software .Oeve fTivoli of Overview 1. Program Actions Program actions involve the execution of generic programs or the use of third-party packaging utilities on a target system. They include the following: ¶ Execute Program ¶ Execute CID Program ¶ InstallShield Program ¶ Microsoft Setup Program ¶ Install MSI Product Program ¶ Install MSI Patch Program

You can further organize and define actions in the software package as follows: ¶ By using conditions, you can define the circumstances under which an action should be executed. For example, you can set a condition on the Add Directory action specifying that this action can be executed only on Windows 98 target systems. You can set conditions on individual objects, or on the entire software package. ¶ You can use a generic container to group actions together that must satisfy the same condition so that change management operations can be executed on the actions as a group. You can include this container in the software package and nest other containers and actions inside it. ¶ To make software packages more generic for use on target workstations with different configurations and operating systems, you can use several types of variables. Refer to the Tivoli Software Distribution Reference Manual for more information about using variables in the software package.

A software package can also be created by defining its contents in a text file known as the software package definition (SPD) file. You create a software package in this file format using the Software

Tivoli Software Distribution User’s Guide 15 Tivoli Software Distribution Environment

Package Editor graphical user interface, manually by using a text editor, or by exporting an existing software package and modifying it.

You can also use the CLI to create and manage software packages. Refer to the Tivoli Software Distribution Reference Manual for more information about using software package definition files and CLI commands. Nested Software Packages By adding a software package as an entry to another software package, you can create a nested software package. The software package that contains the nested software package is the primary package. You specify nested software packages when you create the primary package, or you can nest them using the drag-and-drop method from the Tivoli desktop. When Software Distribution distributes a software package that contains nested software packages, it also distributes the nested software packages. Nested packages are executed in the order in which they are listed in the primary package. By default, the nested software packages are processed after the primary software package. There is no limit to the number of levels of nested software packages contained in the primary package. In addition, you can nest software packages that belong to different Tivoli management regions.

When software packages are nested in a primary package, the change management operations performed on the primary software package are also performed on the nested software packages. The nested software packages inherit most of the properties from the primary package. For example, nested software packages inherit the default change management operation, operation mode, and distribution targets of the primary package. However, there are certain properties specified in the nested software package that condition the primary software package. For example, if the committable option is specified in the nested software package, the primary software package must be installed in transactional mode. If the undoable option is specified in the nested software package, the primary software package must be installed in undoable mode.

16 Version 4.1 Tivoli Software Distribution Environment otaeDistribution Software .Oeve fTivoli of Overview 1. For instructions on nesting software packages, see “Nested Packages” on page 141. For information about distributing nested software packages, see “Distributing Nested Software Packages” on page 327.

Software Package Editor The Software Package Editor is a graphical interface for creating and customizing a software package. It can be installed on any of your available managed nodes and endpoints except NetWare endpoints. The Software Package Editor displays a graphical tree view of the software package and its contents. You organize the actions that are contained in the package in the order in which they are to be executed on the target system. There are several techniques available to create software packages from the Software Package Editor window: ¶ Create a new software package. ¶ Open existing software packages and modify them to create new ones. ¶ Use AutoPack to automatically generate a software package using differencing technology. ¶ Use the PDF importer tool to map specific information from a Microsoft PDF to a software package. ¶ Use the Install MSI Product tool to map information from an MSI file to a software package.

See “Creating a Software Package” on page 53for more information about using the Software Package Editor.

Software Package Formats Regardless of the method used to create a software package, the output can be saved in any of the following formats: ¶ Software package file (.sp) ¶ Software package definition file (.spd)

Tivoli Software Distribution User’s Guide 17 Software Package Formats

¶ Software package block (.spb)

A software package can be opened in the Software Package Editor regardless of the format. You can then choose to resave it in any of the other file types available. For more information about software package definition parameters, keywords, and formats, refer to the Tivoli Software Distribution Reference Manual. Software Package (.sp) File A software package saved in this format is the zipped format of an .spd file. It contains only a description of the actions to be performed on the target system and not the files and resources necessary to execute the actions. The files and resources reside on the source host. The software package file format is the default format used by the Software Package Editor. Because the software package in this format is only a description of the software package, it is in the not-built format. Software Package Definition (.spd) File The software package definition file is the text version of a software package. An .spd file contains only a description of the objects contained in the package, that is, a sequential list of actions to be executed on the target system and not the actual objects or resources themselves. It consists of a sequence of stanzas, each of which describes an action to be executed. Using a text editor, you can modify an .spd file by manipulating the stanzas, then reopen the file in the Software Package Editor and save it in another format. For example, the .spd file for Microsoft Office 2000 is very long. In the software package file format it is compressed to a much smaller size. A software package in this format is in the not-built format. Software Package Block (.spb) A software package block bundles all the resources necessary to execute the actions contained in the software package into a standard zipped format. At distribution time, the resources do not need to be collected from the source host; they are already contained in the software package block.

18 Version 4.1 Software Package Formats otaeDistribution Software .Oeve fTivoli of Overview 1. However, the software package block must reside on the source host. When the software package block is distributed to an endpoint, it is not stored on the endpoint, but is unzipped in the target directory. By unpacking the zipped file immediately, there is no need for additional disk space on the endpoint for the .spb file. A software package that contains all its resources is in the built format. The maximum size of a software package block is 2 GB. Software Package Object A software package object is a software package in either the built (.spb) or not-built (.sp, .spd) format that has been imported into the Tivoli environment. If the software package is in the not-built format, the data to be distributed resides on the source host and is resolved at distribution time. If the software package is in the built format, the software package block must reside on the source host. The software package is catalogued at the Tivoli Software Distribution server as a software package object in the Tivoli database. Choosing a Software Package Format If you have created a software package using the Software Package Editor on an endpoint or on a managed node, you must choose one of the following software package formats: ¶ The built format (a software package block, using the files on the local machine) ¶ The not-built format (a software package file or software package definition file)

Each format has its advantages. For example, if you maintain the software package in the not-built format, you can revise the software package until the moment of distribution. The consolidation of the actions with the files and resources does not occur until distribution, and the most current files on the source host are used to build the package. Also, because a software package in the not-built format does not contain the files and resources to be distributed, it occupies a smaller amount of disk space than a software package block.

Tivoli Software Distribution User’s Guide 19 Software Package Formats

Alternatively, if you build the software package to create a software package block, you ensure that the data in the software package remains static between distributions at different times.

Tivoli Desktop Operations Policy regions, profile managers, and profiles are mechanisms provided by the Tivoli desktop to help organize resources hierarchically. You will ultimately use this hierarchy to associate software packages with target systems. Profiles are the resources that are distributed. From the Tivoli desktop, you import a software package into the Tivoli environment by associating it to a Tivoli Software Distribution profile contained in a profile manager. Right-click the software package profile to display a pop-up menu containing a list of tasks you can perform on software packages, such as calculating software package size, converting the software package to different formats, exporting the software package to the .spd file format, and editing the software package by launching the Software Package Editor. From the pop-up menu, you can also select change management operations such as install, remove, undo, accept, commit, and verify. The interface drives the execution of all the operations supported by the server CLI. See “The Distribution Process” on page 277 for information about the Tivoli desktop and its functions.

Change Management Operations You can use change management operations on software package objects to fully automate the distribution and installation of software. You can launch operations from any managed node where the necessary components are installed. After you create a software package and catalog it at the Tivoli Software Distribution server, you can use the following operations to manage how package actions are executed. Tivoli Software Distribution performs the following change management operations: Install Performs the actions needed to install a software package. Remove Uninstalls a software package.

20 Version 4.1 Tivoli Desktop Operations otaeDistribution Software .Oeve fTivoli of Overview 1. Undo Returns the system to its previous state prior to the last install or remove operation. Accept Deletes the backup package, so the previous operation can no longer be undone. Commit Causes all the updates performed in the preparation phase to take effect. Verify Verifies the consistency of the software package and the object on the target system. If the verify operation fails, the software package is placed in an error state.

These Tivoli Software Distribution operations can be executed in different modes. See “Change Management Operations” on page 297 for more information about change management operations and modes.

Depot Management Operations A repeater depot is a data repository that allows you to temporarily or permanently store distribution data. Storing data in depots reduces network traffic for frequently distributed datasets. Depots are also beneficial when you need to resume a distribution that was interrupted by unavailable nodes or network failures. Instead of resending the entire distribution from the source host, MDist 2 sends only the undelivered portion. Tivoli Software Distribution, Version 4.1 provides two commands to manage repeater depots: Load Loads a software package on a repeater depot. Unload Unloads a software package from a repeater depot.

Data Movement Operations Tivoli Software Distribution, Version 4.1 provides the following commands to distribute, retrieve, and delete files from machines in a Tivoli Management environment:

Tivoli Software Distribution User’s Guide 21 Tivoli Desktop Operations

Send Transfers a file from a Tivoli source host to a set of specified Tivoli endpoint in your Tivoli environment. Retrieve Transfers a file from each specified Tivoli endpoints to a Tivoli source host. Delete Deletes a specified file from one or more endpoints.

Security Tivoli Software Distribution uses Tivoli authorization roles to ensure secure and authorized use of the application. To perform an operation within Tivoli Software Distribution, you must have the required authorization role for the task. In general, the roles in the context of Tivoli Software Distribution are as follows:

Role Operations super Install and remove an application; perform operations listed for senior, admin, and user senior Create, delete, and clone software packages; edit software package properties; import software package definitions; perform operations listed for admin and user admin Subscribe resources to a profile manager, schedule and perform software package distributions, remove software packages from subscribers, perform operations listed for user user View software packages, export software package definitions install-product Install Tivoli Software Distribution

See “Authorization Roles” on page 557 for a complete list of Tivoli Software Distribution operations and their corresponding roles.

Tivoli Software Distribution enables you to perform policy validation for all aspects of software packages. For more information about policy, refer to the Tivoli Software Distribution Reference Manual.

22 Version 4.1 2

Planning and Installing Tivoli Installing and Planning 2. Software Distribution

The Tivoli Software Distribution application adds software distribution capabilities to the Tivoli environment. This chapter provides the following: ¶ A list of tasks and checks that you must perform before you start the installation of or upgrade to Tivoli Software Distribution 4.1.See “Before You Start” on page 24. ¶ Information about the components that are included in Tivoli Software Distribution, Version 4.1 and the type of system on which each component must be installed. See “Tivoli Software Distribution Components” on page 25. ¶ Instructions for planning your Tivoli Software Distribution environment and installing the application using different installation mechanisms. See “Installing Tivoli Software Distribution Components” on page 32. ¶ Instructions for upgrading from Tivoli Software Distribution, Version 4.0 using different installation mechanisms. See “Upgrading from Tivoli Software Distribution 4.0” on page 45. ¶ Instructions for removing Tivoli Software Distribution, Version 4.1. See “Removing Tivoli Software Distribution” on page 47.

See the release notes for system requirements for all Tivoli Software Distribution products.

Tivoli Software Distribution User’s Guide 23 Before You Start Before you start to install or upgrade to Tivoli Software Distribution 4.1, do the following: ¶ Back up the Tivoli databases for all the machines in the Tivoli management region. Creating backups will enable you to return to the state of the object database before installation if, for some reason, you encounter a problem while installing the product. To create a backup of the Tivoli server and clients, select Backup from the Desktop menu or use the wbkupdb command. Refer to the Tivoli Management Framework Reference Guide for information about the wbkupdb command. ¶ Ensure that the server, managed nodes, and endpoints, on which you intend to install components of Tivoli Software Distribution, Version 4.1, comply with the hardware and software prerequisites for the product. Information about the prerequisites and about compatible software versions of other products is included in the Release Notes for Tivoli Software Distribution, Version 4.1. ¶ Read the section “Tivoli Software Distribution Components” on page 25 and decide which of the components you will install on which systems.

Note: Several of the components are dependent on other components. The descriptions in this section explain these dependencies. For example, you cannot install the Web User Interface unless both Activity Planner and Change Configuration Management (CCM) are installed; you cannot install CCM unless the Historical Database component is installed, the historical database feature is enabled, and the Activity Planner is installed. ¶ Ensure that you have the required Java components installed for the Software Distribution you have decided to install. Table 1 on page 25 shows the Java Components available in the Tivoli Management Framework 3.7.1 and their usage in Tivoli Software Distribution, Version 4.1.

24 Version 4.1 Table 1. Tivoli Management Framework Java Components Java Component APM CCM WebUI SP Web UI Editor Depot Java for Tivoli 3.7 UU UU Tivoli Java Client Framework 3.7 UU U Swing for Tivoli 3.7.1 UU U JavaHelp for Tivoli 3.7.1 UU U Tivoli MDist2 GUI Tivoli Java RDBMS Interface UU Installing and Planning 2. (JRIM) 3.7

Tivoli Software Distribution Components Tivoli Software Distribution includes components that must be installed on the following different types of machine in the Software Distribution environment: ¶ Tivoli management region server (Tivoli server) ¶ Managed node ¶ Endpoint Refer to the Tivoli Software Distribution Release Notes for more detailed information about the prerequisites required for the installation of the following components. Tivoli Server Components The following components must be installed on a Tivoli server: Tivoli Software Distribution Server, Version 4.1 Installs the Tivoli Software Distribution server component. This component includes source host capability. Tivoli Software Distribution Historical Database, Version 4.1 Installs and enables the Historical Database and Change Management Status features that automatically update the Tivoli Inventory configuration repository with information about Software Distribution operations that have been performed in your Tivoli environment.

Tivoli Software Distribution User’s Guide 25 Tivoli Software Distribution Components

You must have the Tivoli Inventory product installed prior to installing this component. See “Integrating the Tivoli Inventory Database” on page 375 for in-depth information about using this feature to access information from the configuration repository. Tivoli Software Distribution TEC Integration, Version 4.1 Installs the files that enable Tivoli Software Distribution to send events to the Tivoli Enterprise Console® event server (event server) when a Tivoli Software Distribution operation is performed. You must install this integration product on each event server in your Tivoli management region. Before installing this component, you must do the following: ¶ Install Version 3.6.2 or later of the Tivoli Enterprise Console and the Tivoli Enterprise Console server. ¶ Create a Tivoli Enterprise Console event console so that you can use the swdistecsrvr_inst.sh script to install the Tivoli Software Distribution event classes to the event server. The script enables Tivoli Software Distribution to send events to the event server.

See “Integrating the Tivoli Enterprise Console” on page 397 for in-depth information about configuring and using this product. Tivoli Software Distribution Activity Planner Server, Version 4.1 Installs the server component of Activity Planner. Before you install this component, you must install the Tivoli Software Distribution Server, Version 4.1. To use Activity Planner, you must also create a Relational Database Management System (RDBMS) Interface Module (RIM) object and database tables on managed nodes. You can optionally install the Activity Planner GUIs on managed nodes. Activity Planner actions can also be run using the command line. Tivoli Software Distribution Change Configuration Manager, Version 4.1 Installs the server component of the Change Configuration Manager (CCM). Before you install this component, you

26 Version 4.1 Tivoli Software Distribution Components

must install the Activity Planner and Historical Database feature. To use CCM, you must also install the CCM GUIs on managed nodes, and create a RIM object and database tables on the managed nodes. Tivoli Software Distribution Server WEB User Interface, Version 4.1 This component installs the Apache Web Server, the Sun Java Servlet APIs, the Apache JServ module, a Java Virtual Machine to run Java Servlets, Tivoli Software Distribution Java Servlets, and the Java Client Framework package to access the Tivoli environment from Java Servlets. To use the Installing and Planning 2. Web Interface you must first install the Activity Planner and CCM features and ensure that the Tivoli Software Distribution Historical Database, Version 4.1 component is installed and is enabled. Managed Node Components The following components must be installed on managed nodes: Tivoli Software Distribution Gateway, Version 4.1 Installs the files that enable an endpoint gateway to recognize Software Distribution methods, download the methods to endpoints, and execute the methods on these clients to perform the requested Software Distribution operation. Install this product on all managed nodes that are configured as endpoint gateways or which you plan to configure as endpoint gateways. Tivoli Software Distribution Source Host, Version 4.1 The source host is the system on which the files referenced in the software package are located and obtained to build the software package into the software package block format. The software package block is also stored on the source host. The Tivoli server functions as the default source host. However, if you want additional source hosts in your environment, install this product component on a managed nodes where you will run Tivoli Software Distribution commands from the command line. To operate as a source

Tivoli Software Distribution User’s Guide 27 Tivoli Software Distribution Components

host, a manage node must fulfill the following requirements in addition to the installation of the source host component: ¶ It must either be a gateway or configured as a stand-alone repeater. You can use the Framework wrpt command to configure the managed node as a repeater. ¶ It must have sufficient disk space to store the software package blocks and the files referenced in the software packages.

Note: This component is not supported on NetWare. managed nodes Tivoli Software Distribution Software Package Editor, Version 4.1 Installs the files that enable the Tivoli desktop to launch the Java-based Software Package Editor on a managed node so that you can create new software packages or modify existing software packages and import them into the Tivoli environment. The Tivoli Software Distribution Source Host component must be previously installed on the managed node. Notes: 1. The Tivoli Software Distribution Software Package Editor component is not supported on OS/2 and NetWare managed nodes. 2. On managed nodes where the Tivoli Software Distribution Software Package Editor is installed, some of the functionality of the Software Package Editor GUI is disabled. Tivoli Software Distribution Activity Planner GUIs (only for managed nodes), Version 4.1 Installs the Activity Planner GUIs on managed nodes. Before you can use Activity Planner, you must create a RIM object and database tables on the managed nodes.

28 Version 4.1 Tivoli Software Distribution Components

Note: This component is not supported on OS/2 and NetWare managed nodes. Tivoli Software Distribution Change Configuration Manager GUI, Version 4.1 Installs the Change Configuration Manager (CCM) GUIs on managed nodes. Before you can use CCM, you must create a RIM object and database tables on the managed nodes.

Note: This component is not supported on OS/2 and NetWare managed nodes. Installing and Planning 2. Tivoli Software Distribution Server WEB User Interface Depot, Version 4.1 Install this component on all managed nodes that function as depots from which you can download software from the Web. This component requires the installation of the Tivoli Management Framework, Version 3.7.1 and the Tivoli Management Framework Java Components. Notes: 1. This component is not supported on OS/2 and NetWare managed nodes. 2. It is not necessary to install this component on the server because it is already included in the Tivoli Software Distribution Server component. Endpoint Components The following components must be installed on endpoints: Tivoli Software Distribution Java Endpoint Package Editor This component consists of a series of platform-specific software packages that can be installed on all endpoint-supported platforms using the Tivoli Software Distribution, Version 4.1 product. This component enables you to use the Software Package Editor in stand-alone mode on the endpoint to create software packages and test them by installing them locally using the command line on the disconnected target. You can submit disconnected commands by clicking the SWDIS ENV icon placed on your desktop

Tivoli Software Distribution User’s Guide 29 Tivoli Software Distribution Components

after the installation of this component. You can also use The Software Package Editor from the Tivoli desktop on the endpoint to modify software packages and import them into the Tivoli environment. If the Tivoli Software Distribution Software Package Editor is already installed on a managed node and the managed node is also an endpoint, do not install the Tivoli Software Distribution Java Endpoint Package Editor component. You should not install the Tivoli Software Distribution Software Package Editor and the Tivoli Software Distribution Java Endpoint Package Editor on the same machine. For information about installing this component, see “Installing the Tivoli Software Distribution Java Endpoint Package Editor” on page 39. Tivoli Software Distribution Pristine Tool This component consists of an OS/2 and a Windows platform-specific software package that can be installed using the Tivoli Software Distribution, Version 4.1 product. This tool provides support for remotely installing new operating systems and software on pristine computers. For information about installing this component, see “Installing the Tivoli Software Distribution Pristine Tool” on page 44.

30 Version 4.1 Tivoli Software Distribution Components

Components in the Software Distribution Environment The relationship between all of the Tivoli Software Distribution components are shown in the following figure:

Tivoli management region server Managed node/Source host

Tivoli Software Distribution Server Tivoli Software Distribution Source Host

Tivoli Software Distribution Installing and Planning 2. Managed node Java Package Editor Gateway/Repeater depot

Tivoli Software Distribution Gateway

endpoint endpoint endpoint

Tivoli Software Distribution Java Endpoint Package Editor

Notes: 1. The Tivoli server automatically serves as a source host. Therefore, you do not need to install the Tivoli Software Distribution Source Host component on the Tivoli server. However, you must install the Tivoli Software Distribution Source Host component on other managed nodes that you want to serve as source hosts. 2. The Tivoli server cannot function as a Tivoli Software Distribution gateway unless you install the Tivoli Software Distribution Gateway component on it.

Tivoli Software Distribution User’s Guide 31 Installing Tivoli Software Distribution Products Installing Tivoli Software Distribution Components To successfully install Tivoli Software Distribution for the first time, you must complete the following tasks: 1. Ensure Tivoli Management Framework 3.7.1 is installed 2. Install Tivoli Software Distribution Server, Version 4.1 3. Tivoli Software Distribution Gateway, Version 4.1 4. Depending on the deployment plan you have created, you can install the following optional Tivoli Software Distribution components: ¶ Tivoli Software Distribution Source Host, Version 4.1 ¶ Tivoli Software Distribution Software Package Editor, Version 4.1 ¶ Tivoli Software Distribution TEC Integration, Version 4.1 ¶ Tivoli Software Distribution Historical Database, Version 4.1 ¶ Tivoli Software Distribution Activity Planner Server, Version 4.1. ¶ Tivoli Software Distribution Activity Planner GUIs (only for managed nodes), Version 4.1. ¶ Tivoli Software Distribution Server Change Configuration Manager, Version 4.1 ¶ Tivoli Software Distribution Change Configuration Manager GUI, Version 4.1 ¶ Tivoli Software Distribution Server WEB User Interface, Version 4.1 ¶ Tivoli Software Distribution Server WEB User Interface Depot Component, Version 4.1 ¶ Tivoli Software Distribution Java Endpoint Package Editor ¶ Tivoli Software Distribution Pristine Tool, Version 4.1

32 Version 4.1 Installing Tivoli Software Distribution Products

Notes: 1. Before you can start the installation of CCM, the Activity Planner must be completely installed and the related configuration tasks completed, and the Historical Database component must be installed and the historical database feature enabled. 2. If you are installing the Activity Planner or Change Configuration Manager features, there are additional

configuration tasks that you must complete before the features Installing and Planning 2. can be used. See “Creating RIM Objects and Database Tables for Activity Planner or CCM” on page 37. Installation Mechanisms You can install the server and managed node components of Tivoli Software Distribution using any of the following different installation mechanisms. ¶ Tivoli Software Installation Service. See “Installing Tivoli Software Distribution with Tivoli Software Installation Service” on page 34. ¶ Tivoli desktop. See “Installing Tivoli Software Distribution with the Tivoli Desktop” on page 35. ¶ The Tivoli Management Framework commands winstall or wpatch. See “Installing Tivoli Software Distribution Using the winstall Command” on page 36.

The endpoint components, Tivoli Software Distribution Java Endpoint Package Editor and Tivoli Software Distribution Pristine Tool are distributed to endpoints as software package blocks. See “Installing the Tivoli Software Distribution Java Endpoint Package Editor” on page 39.

The table that follows shows the index file names, component names, and product tags that are used in the different installation mechanisms to identify the components to be installed.

Tivoli Software Distribution User’s Guide 33 Installing Tivoli Software Distribution Products

Index File Component Name Product Tag SWDISSRV Tivoli Software Distribution Server, Version 4.1 swdissrv_4.1 SWDISGW Tivoli Software Distribution Gateway, Version 4.1 swdisgw SWDISSH Tivoli Software Distribution Source Host, Version 4.1 swdissh SWDISJPS Tivoli Software Distribution Software Package Editor, swdisjps Version 4.1 SWDISTEC Tivoli Software Distribution TEC Integration, Version swdistec 4.1 SWDISDB Tivoli Software Distribution Historical Database, swdisdb Version 4.1 SWDAPM Tivoli Software Distribution Activity Planner Server, swdapm Version 4.1 SWDAPMMN Tivoli Software Distribution Activity Planner GUIs, swdapmmn Version 4.1 SWDISWEB Tivoli Software Distribution Server WEB User swdisweb Interface, Version 4.1 SWDWEBD Tivoli Software Distribution Server WEB User Interface swdwebd Depot Component, Version 4.1 SWDCCM Tivoli Software Distribution Change Configuration swdccm Manager, Version 4.1 SWDCCMUI Tivoli Software Distribution Change Configuration swdccmui Manager GUI, Version 4.1

¶ The index file is used for installing the component using the winstall and wpatch commands. ¶ The component name is used for installing the component from either the Tivoli desktop or SIS console. ¶ The product tag is used for uninstalling the component using the wuninst command. Installing Tivoli Software Distribution with Tivoli Software Installation Service The Tivoli Software Installation Service can install multiple Tivoli products on multiple systems in parallel. This Java-based product

34 Version 4.1 Installing Tivoli Software Distribution Products

can, therefore, install more products on more systems in much less time than the Tivoli Management Framework installation facility.

The basic procedure for using Tivoli Software Installation Service to install the components of Tivoli Software Distribution is as follows: 1. Import the product images into the Tivoli Software Installation Service Depot. 2. Select the components to be installed.

3. Select the machines where each component is to be installed. Installing and Planning 2. 4. Click Install. For detailed information about using Tivoli Software Installation Service to install the components, refer to the Tivoli Enterprise Installation Guide, Version 3.7. Installing Tivoli Software Distribution with the Tivoli Desktop You can also install Tivoli Software Distribution products from the desktop. The basic procedure for using the Tivoli desktop to install components of Tivoli Software Distribution is as follows: 1. From the Desktop menu, select Install→Install Product. 2. Select the media and component. 3. Select the machines on which to install the component. 4. Click Install.

The following table provides the context and authorization role required for this task:

Activity Context Required Role Install Tivoli Software Tivoli environment super or Distribution products install-product

For detailed information about using the Tivoli desktop to install the components, refer to the Tivoli Enterprise Installation Guide, Version 3.7.

Tivoli Software Distribution User’s Guide 35 Installing Tivoli Software Distribution Products

Installing Tivoli Software Distribution Using the winstall Command When you install the Tivoli Software Distribution components using the winstall command, you specify the location of the files to be installed, the index file of the component you want to install, and the machine or machines on which the component is to be installed.

Note: If you do not specify a machine when using the winstall command, the components will be installed on all managed nodes.

See the table “Installation Mechanisms” on page 33 for a list of components and their associated index file names.

The following examples illustrate the use of winstall to install components on a Tivoli server or on managed nodes. ¶ To install the Tivoli Software Distribution Server component on the Tivoli server jupiter from a CD-ROM image, enter the following command: winstall –c \root\images\cdrom -i SWDISSRV.IND jupiter

where: -c \root\images\cdrom Specifies the path to the CD-ROM image. -i SWDISSRV.IND Specifies the product index file to install. ¶ To install the Tivoli Software Distribution Gateway component on managed nodes juno and diana from a CD-ROM image, enter the following command: winstall –c \root\images\cdrom -i SWDISGW.IND juno diana

For detailed information about the winstall command, refer to the Tivoli Management Framework Reference Guide.

36 Version 4.1 Installing Tivoli Software Distribution Products

Creating RIM Objects and Database Tables for Activity Planner or CCM The Activity Planner and Change Configuration Management (CCM) features each need a RIM object and database tables. Before you can create these items, your system must comply with the following prerequisites: ¶ Tivoli Management Framework 3.7.1 must be installed. ¶ The following Java components must be installed on managed nodes where the Activity Planner or CCM GUI is installed: Installing and Planning 2. v Tivoli Java Client Framework 3.7 v Java for Tivoli 3.7 v Tivoli Java RDBMS Interface Module (JRIM) 3.7 v Java Help for Tivoli 3.7.1 v Swing for Tivoli 3.7.1 ¶ Tivoli Inventory, Version 3.6.2 or later must be installed. ¶ Tivoli Software Distribution Server, Version 4.1, component must be installed.

Note: The Activity Planner must be installed, the Historical Database component must be installed, and the historical database feature must be enabled before you can install and configure CCM.

To create the required objects, perform the following steps: 1. Install and configure the relational database management system (RDBMS). 2. Create database tables required and sample queries on the RIM host. 3. Create a RIM object.

Creating Database Tables and Queries Installing the server component of Activity Planner or CCM causes the following scripts to be written to the

Tivoli Software Distribution User’s Guide 37 Installing Tivoli Software Distribution Products

$BINDIR/TME/SWDIS/SCRIPTS directory, where $BINDIR represents the system variable that contains the path of the installation directory of the product. ¶ For Activity Planner v plans_vendor_admin.sql v plans_vendor_schema.sql ¶ For CCM v ccm_vendor_admin.sql v ccm_vendor_schema.sql where vendor is the name of the supported database vendor, for example DB2®, Oracle, or Sybase.

You create tables in the database by executing the plans_vendor_schema.sql or ccm_vendor_schema.sql script.

The admin.sql scripts are sample structured query language (SQL) scripts that can be used as templates. Modify the script to comply with your environment. The default database names are planner and ccm and the database user names are planner and tivoli.

Creating RIM Objects To create the RIM object, you must use the wcrtrim command, as follows: wcrtrim -v -h -d -u -H -s

where: -v Identifies the vendor of the RDBMS you are using. For example, DB2, Oracle, Sybase. -h Identifies the managed node where the RIM host will reside. -d Specifies the name of the database to which the RIM object will connect. For example, planner or ccm.

38 Version 4.1 Installing Tivoli Software Distribution Products

-u Specifies the name of the database user. The default user name for Activity Planner is planner. The default user name for CCM is tivoli. -H Specifies the fully qualified path to the database home directory. Generally, this is an environment variable created during the installation of the database. For example, the default home path for DB2 databases is set by the DB2DIR environmental variable. .Pann n Installing and Planning 2. -s Specifies the database server ID that enables the RIM host to connect to the RDBMS. Generally, this is an environment variable. For example, for DB2 databases, the DB2COMM environment variable should be set to tcpip. Specifies the name of the created RIM object. The names must be specified as follows: ¶ planner (Activity Planner) ¶ ccm (CCM) Installing the Tivoli Software Distribution Java Endpoint Package Editor This section documents the procedure to install the Tivoli Software Distribution, Version 4.1 software package blocks that contain the Tivoli Software Distribution Java Endpoint Package Editor component. This component installs the Software Package Editor GUI and the disconnected command line. For information about installing the language support pack for this component, see “Language Support for Endpoint Components” on page 52.

The product CD-ROM includes the path \package\prepsite which contains the following file names for the platform-specific software package blocks: SWDISEP_AIX.spb The software package for the AIX® platform.

Tivoli Software Distribution User’s Guide 39 Installing Tivoli Software Distribution Products

SWDISEP_HP.spb The software package for the HP-UX platform. SWDISEP_NT.spb The software package for the Windows NT and Windows 2000 platform. SWDISEP_WIN95.spb The software package for the Windows 98 platform. SWDISEP_NW.spb The software package for the NetWare platform. Enables the disconnected command line only. SWDISEP_OS2.spb The software package for the OS/2 platform. SWDISEP_SOLARIS.spb The software package for the Solaris platform. SWDISEP_NTAS400.spb The software package to be used, on an Windows NT platform, for creating OS/400 software packages. The Windows NT system to which this package is distributed must have a TCP/IP connection to an OS/400 preparation site where the software package SWDISEP_400PS.spb is installed. SWDISEP_400PS.spb The software package for the OS/400 preparation site.

Installation Options The following table lists installation options that can be specified when you install the Tivoli Software Distribution Java Endpoint Package Editor. This component is a software package block installed from the Tivoli desktop using change management operations on endpoints. See “Change Management Operations” on page 297 for more information about executing change management operations.

40 Version 4.1 Installing Tivoli Software Distribution Products

GUI Field Name CLI Attribute Description Default Variable Name target_dir From the Tivoli desktop, you can use the Default Variables dialog to override the default value of the target_dir variable so that, when the software package is installed on an endpoint, you can define a location other than the product directory. The default value of the target_dir variable is product_dir/speditor and is stored in .Pann n Installing and Planning 2. the swdis.ini file. See “Default Variables” on page 312 for more details about the Default Variables dialog. Default Variable Name package_type This attribute has two possible values: ALL or CLI. The default value is ALL. The ALL value installs the component with both the Software Package Editor capability and the disconnected command line interface capability. Change the value to CLI to install the component with only the disconnected command line capability.

Installation Procedure To install the software package blocks, perform the following steps: 1. After you have installed the Tivoli Software Distribution, Version 4.1 server, Tivoli Software Distribution, Version 4.1 gateways, and Tivoli endpoints, open the Tivoli desktop. 2. Create a software package profile. 3. Insert the Tivoli Software Distribution, Version 4.1 CD-ROM in the machine to which you want to import the software package block. 4. Right-click the created profile. A pop-up menu displays. 5. Select Import. The Import dialog displays. 6. In the Location of Input File group box, select one of the following from the drop-down list:

Tivoli Software Distribution User’s Guide 41 Installing Tivoli Software Distribution Products

¶ Managed Node, if the machine specified in Step 3 is a managed node. ¶ Endpoint, if the machine specified in Step 3 is an endpoint. If you select Endpoint, enter the name of the endpoint in the Endpoint Name text box. 7. Click the browse (...) button. The Select Input File dialog displays. 8. Select the machine on which you inserted the CD-ROM. If it is a managed node, select the name from the Hosts list. 9. On the product CD-ROM, locate in the \package\prepsite path, the required platform-specific software package block that installs the Tivoli Software Distribution Java Endpoint Package Editor component. 10. Select the software package block to import. 11. In the Location of Source Host group box, leave the Build check box selected. Enter the source host name and the software package block path in the Source Host Name and in the SPB Path text boxes, respectively. 12. Click Import & Close to import the software package block and return to the Profile Manager dialog. 13. Right-click the imported software package. A pop-up menu displays. 14. Select Install. The Install Software Package dialog displays. 15. In the Available Subscribers list, select the endpoint on which you want to install the package. 16. Click Install & Close to begin installing the software package to the selected subscribers. The dialog is not dismissed until the operation has been submitted.

After the package is installed, the speditor_dir key is created in the swdis.ini file. The path where the package is installed is: \

42 Version 4.1 Installing Tivoli Software Distribution Products

where represents the operating system type whose value can be any one of the following values in the Interpreter Type column:

Operating System Interpreter Type Windows NT, Windows 2000 w32-ix86 Windows 98 win95 OS/2 os2-ix86 Solaris solaris2 .Pann n Installing and Planning 2. HP-UX hpux10 AIX aix4-r1 NetWare nw4

Additional Notes for OS/2 Installation Procedure The SWDISEP_OS2.spb software package block cannot be installed on the file allocation table (FAT) partition of an OS/2 target system. To install the SWDISEP_OS2.spb on an OS/2 target system, verify that the path of the product_dir variable specified in the swdis.ini file is located on a high-performance file system (HPFS)-partitioned disk. If it is not located on an HPFS-partitioned disk, perform the following steps: 1. From the Tivoli desktop, right-click the software package block to install. 2. Select Install from the pop-up menu. The Install Software Package dialog is displayed. 3. From the Advanced Options menu item, select Default Variables. The Default Variables dialog is displayed. 4. In the Default Variable list, select target_dir=$(product_dir)\speditor. 5. Substitute $(product_dir) with a path located on an HPFS-partitioned disk. For example, if your D: disk is HPFS-partitioned, you can specify: target_dir=d:\sw\speditor

Tivoli Software Distribution User’s Guide 43 Installing Tivoli Software Distribution Products

Installing the Tivoli Software Distribution Pristine Tool This section documents the procedure to install the Tivoli Software Distribution, Version 4.1software package blocks that contain the Tivoli Software Distribution Pristine Tool component. This component installs the Pristine Tool GUI. For information about installing the language support pack for this component, see “Language Support for Endpoint Components” on page 52.

The product CD-ROM includes the path \package\pristine which contains the following file names for the platform-specific software package blocks: Pristine_NT.spb The software package block for the Windows platform. It is valid for Windows NT 4.0, Windows 2000, and Windows 98 Second Edition. To install the software package block on an endpoint, follow steps 1 through 16 in the section, “Installation Procedure” on page 41, substituting the input file with the Pristine_NT.spb software package block. Pristine_OS2.spb The software package block for the OS/2 platform. It is valid for OS/2 4.0 and OS/2 4.5. To install the software package block on an OS/2 endpoint, follow steps 1 through 16 in the section, “Installation Procedure” on page 41 and the steps in the section, “Additional Notes for OS/2 Installation Procedure” on page 43, substituting the target_dir variable with the following: target_dir=$(product_dir)\pristine Finishing Off After installing Tivoli Software Distribution, update the managed resource types of policy regions in which you want to create software packages. Also, update the notice group subscriptions of any administrators who will receive Tivoli Software Distribution notices. Refer to the Tivoli Management Framework Planning for Deployment Guide for instructions about changing managed resource types and on assigning administrator’s properties.

44 Version 4.1 Upgrading from Software Distribution 4.0 Upgrading from Tivoli Software Distribution 4.0 You can upgrade the Tivoli server and managed node components from Tivoli Software Distribution, Version 4.0, to Tivoli Software Distribution, Version 4.1, using any one of the following mechanisms: ¶ Tivoli Software Installation Service ¶ Tivoli desktop ¶ The Tivoli Management Framework wpatch command Installing and Planning 2. Notes: 1. Before upgrading to Tivoli Software Distribution, Version 4.1, using any of the methods, ensure that you have installed the Framework 3.7.1 patch. 2. When upgrading to the new Tivoli Software Package Editor component, be aware that you must install the Framework 3.7.1 Java components. This version of the Software Package Editor does not include its own Java components. See Table 1 on page 25 for details of the Framework Java components.

The following table provides the context and authorization role required for this task:

Activity Required Role Upgrade Tivoli Software Distribution super or install-product

Note: To upgrade the Tivoli Software Distribution Java Endpoint Package Editor, Version 4.0 to Version 4.1, remove the Version 4.0 component before installing the Tivoli Software Distribution Java Endpoint Package Editor, Version 4.1 component. Upgrading Tivoli Software Distribution, Version 4.0 with the Tivoli Software Installation Service The basic procedure for using the Tivoli Software Installation Service to upgrade the components of Tivoli Software Distribution is as follows:

Tivoli Software Distribution User’s Guide 45 Upgrading from Software Distribution 4.0

1. Import the product images into the Software Installation Service Depot. 2. Select the components to be installed. 3. Select the machines where each component is to be installed. 4. Click Install. For detailed information on using the Tivoli Software Installation Service to upgrade the components, refer to the Tivoli Enterprise Installation Guide. Upgrading Tivoli Software Distribution, Version 4.0 from the Tivoli Desktop The basic procedure for using the Tivoli desktop to upgrade components of Tivoli Software Distribution is as follows: 1. From the Desktop menu, select Install→Install Patch. 2. Select the media and component. 3. Select which machines to install the component. 4. Click the Install button. For detailed information on using the Tivoli desktop to install the components, refer to the Tivoli Enterprise Installation Guide. Upgrading Tivoli Software Distribution, Version 4.0 Using the wpatch Command The following are examples of using the wpatch command to upgrade the components of Tivoli Software Distribution. See the table “Installation Mechanisms” on page 33 for a list of components and their associated index file names. The index file name is used in the wpatch command. ¶ To install the Tivoli Software Distribution Server component on the Tivoli server jupiter from a CD-ROM image, enter the following command: wpatch –c \root\images\upgrade -i SWDISSRV.IND jupiter

where:

46 Version 4.1 Upgrading from Software Distribution 4.0

-c \root\images\upgrade Specifies the path to the CD-ROM image. -i SWDISSRV.IND Specifies the product installation index file to which the patch is installed. jupiter Specifies the managed node on which the patch is installed. .Pann n Installing and Planning 2. Note: If you do not specify a managed node, the patch is installed on all managed nodes where the base product is currently installed in the Tivoli management region.

For detailed information on the wpatch command, refer to the Tivoli Management Framework Reference Guide.

Removing Tivoli Software Distribution Tivoli Management Framework provides a command line utility to remove Tivoli applications from a specified node or from the entire Tivoli management region. The wuninst command is a wrapper script that invokes product-specific uninstall scripts.

Using the wuninst command with an application-specific product tag, you can remove Tivoli Software Distribution products from any machine in your environment or from the Tivoli management region. See the table “Installation Mechanisms” on page 33 for a list of the Tivoli registered product tags for Tivoli Software Distribution components.

Note: When uninstalling Tivoli Software Distribution components, uninstall the Tivoli Software Distribution Server (swdissrv_4.1) component last.

The following examples demonstrate removal operations that you can use to uninstall Tivoli Software Distribution or its components from your Tivoli management region environment. See the Tivoli

Tivoli Software Distribution User’s Guide 47 Removing Tivoli Software Distribution

Management Framework Reference Guide for more information about command line syntax and usage for the wuninst command.

To view the usage statement for Tivoli Software Distribution, enter the following at the command line without any arguments: wuninst

To remove Tivoli Software Distribution from the entire Tivoli management region in which jupiter is the Tivoli server, enter the following command. Note that if the node is the Tivoli server, Tivoli Software Distribution will be removed from the Tivoli server and from all managed nodes on which Tivoli Software Distribution is installed. wuninst swdissrv_4.1 jupiter -rmfiles

where: swdissrv_4.1 Specifies the registered product tag for the Tivoli Software Distribution Server component. –rmfiles Specifies that all local database objects and all the associated files are removed even if they are shared files. The default behavior without the –rmfiles option is to only remove the database entries for the specified node. If the node is the Tivoli server, this option removes all database objects.

Note: You can also uninstall Tivoli Software Distribution locally on each machine in your Tivoli management region by using the scripts located on the machine in the $BINDIR\TME\SWDIS\SCRIPTS directory. Each of the components listed in the table “Installation Mechanisms” on page 33 has a corresponding script that can be used to uninstall each component from a machine in your Tivoli management region.

For example, to uninstall the Tivoli Software Distribution Gateway component (swdisgw) and the Tivoli Software

48 Version 4.1 Removing Tivoli Software Distribution

Distribution Java Endpoint Package Editor (swdisjps) from the managed node juno, complete the following steps: 1. Configure the Tivoli system environment variables using the setup_env.sh file. Refer to the Tivoli Enterprise Installation Guide for details. 2. In the $BINDIR\TME\SWDIS\SCRIPTS directory on the managed node, locate the scripts related to the Tivoli Software Distribution Gateway component (swdisgw) and

the Tivoli Software Distribution Java Endpoint Package Installing and Planning 2. Editor (swdisjps) component. 3. Run the scripts locally on the managed node juno, specifying the following command. Since this command is a bash script that must be run in the bash environment, precede the command with the string sh, as follows: sh scriptname -rmfiles where: scriptname Specifies the script found in the $BINDIR\TME\SWDIS\SCRIPTS directory on the june manage node that corresponds to a Tivoli Software Distribution component listed in the table “Installation Mechanisms” on page 33. –rmfiles Specifies that all local database objects and all the associated files are removed even if they are shared files. Uninstalling Tivoli Software Distribution Endpoints When uninstalling a Tivoli Software Distribution endpoint, the following steps must be performed manually: 1. The following directories still exist after uninstalling the endpoint: drive:\Product_Dir\swdis. Delete them from the appropriate drive manually.

Tivoli Software Distribution User’s Guide 49 Removing Tivoli Software Distribution

2. Remove the swdis.ini and swdis.bak files from the SystemDir directory. On UNIX platforms, these files are located in /etc/Tivoli 3. From the Windows registry, delete the SwdisUsrPrf.Endpoint_label keyword from the following path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ CurrentVersion\Run. For more information about uninstalling endpoints, refer to the Tivoli Enterprise Installation Guide. Uninstalling the NetWare Gateway Installing Tivoli Software Distribution, Version 4.1 creates and populates a list of files and directories on the NetWare gateway. To uninstall Tivoli Software Distribution from the NetWare gateway, you must delete the files manually. However, do not delete the directories, because they may be used by other Tivoli Management Framework applications.

To uninstall Tivoli Software Distribution from a NetWare gateway, perform the following steps. In this example, the installation directory on the NetWare gateway is SYS:\TIVOLI. 1. From the $BINDIR/TME/SWDIS/SCRIPTS directory on the Tivoli server, run the swdisNW_uninst.sh script to remove Tivoli products installed in the Tivoli management region from the Tivoli object database. Since this command is a bash script that must be run in the bash environment, precede the command with the string sh, as follows: sh swdisNW_unist.sh 2. Delete all spd_eng files contained in the subdirectories of the installation directory, for example: sys:\Tivoli\bin\lcf_bundle.40\aix4-rl\bin\TME\SWDIS\SPDE \spd_eng 3. Delete all files in the installation directory that match the following pattern: libe*.* 4. Delete the following files (displayed in bold typeface):

50 Version 4.1 Removing Tivoli Software Distribution

sys:\Tivoli\bin\lcf_bundle.40\INSTALLED\SWDISGW_LCFNEW sys:\Tivoli\bin\lcf_bundle.40\lib\nw4\resinit.nlm sys:\Tivoli\bin\lcf_bundle.40\lib\os2-ix86\resinit.exe sys:\Tivoli\bin\lcf_bundle.40\lib\w32-ix86\resinit.exe sys:\Tivoli\bin\lcf_bundle.40\lib\w32-ix86\wdusrprf.exe sys:\Tivoli\bin\lcf_bundle.40\lib\win95\resinit.exe sys:\Tivoli\bin\lcf_bundle.40\lib\os400\resinit sys:\Tivoli\bin\lcf_bundle.40\lib\os400\wdbldspb

Enabling Language Support

Tivoli Software Distribution, Version 4.1 is translated into the Installing and Planning 2. following languages: ¶ Brazilian Portuguese ¶ Chinese (Simplified) ¶ Chinese (Traditional) ¶ French ¶ German ¶ Italian ¶ Japanese ¶ Korean ¶ Spanish

After you have installed the Tivoli Software Distribution, Version 4.1 components listed in the section “Installation Mechanisms” on page 33 , you can enable the supported languages by installing the appropriate language support pack located on the product CD-ROM in the \images\l10n\cdrom path. Installation of the language packages is optional. You can also install multiple language support packs for a single product. Remember, to get full language enablement you must install the Tivoli Management Framework language support pack as well as the language support pack for Tivoli Software Distribution, Version 4.1. If you are installing the language support pack using the Install Product dialog, the following dialog box

Tivoli Software Distribution User’s Guide 51 Enabling Language Support

shows the list of language support packs available:

Language Support for Endpoint Components The product CD-ROM includes language support packs in the path \package\l10n, in the form of a software package block, for the following endpoint components: Tivoli Software Distribution Pristine Tool Install the PRISTINE_l10n.spb software package block. Tivoli Software Distribution Java Endpoint Package Editor Install the SDGui_l10n.spb software package block.

To install either or both of these software package blocks, follow the same procedure outlined in steps 1 through 16 “Installation Procedure” on page 41, substituting the input file with the appropriate software package block.

52 Version 4.1 3 Creating a Software Package

The Software Package Editor is the Tivoli Software Distribution software packaging facility. It is a Java-based graphical user interface (GUI) used to create and customize a software package. The Software Package Editor window displays a graphical tree view of the software package and its contents.

Launching the Software Package Editor You can use the Software Package Editor on either endpoints or

managed nodes. On endpoints, you install the Tivoli Software Software a Creating 3. Distribution Java Endpoint Package Editor component and all the functionality of the Software Package Editor is enabled. This

component enables you to create and customize software packages. Package On managed nodes, you install the Tivoli Software Distribution Software Package Editor component and some of the functionality of the Software Package Editor is disabled. You use this component primarily for customizing pre-existing software packages. Notes: 1. Before launching the Software Package Editor on a UNIX system, enable host access to the X server by entering the xhost + command. 2. Performance of the Software Package Editor can be degraded if remote drives that were not accessible when the Software Package Editor was launched have been mapped to the machine.

Tivoli Software Distribution User’s Guide 53 Launching the Software Package Editor

3. If you are using the Software Package Editor on a Windows 98 platform, a DOS window appears minimized in the task bar when you open or save a software package in SPD or SPB format. Do not close this window as this will close the entire application. Launching the Software Package Editor on Endpoints To launch the Software Package Editor from an endpoint on a Windows or OS/2 system, double-click the icon labelled Software Package Editor on your desktop. On a Windows system, you can also launch the Software Package Editor by selecting the entry in the Start→Programs menu. The Software Package Editor main window displays.

On the same endpoint, if you also have the Tivoli desktop installed, you can also launch the editor as described in the following section. Both methods access the same component with the full Software Package Editor functions for creating and customizing software packages.

Note: To successfully launch the Software Package Editor on an endpoint from the Tivoli desktop, the endpoint name and the

54 Version 4.1 Launching the Software Package Editor

hostname must be identical and in the same case. You can, however, launch the Software Package Editor from the Software Package Editor icon on your desktop. Launching the Software Package Editor on Managed Nodes Some of the functions of the Software Package Editor GUI installed on managed nodes are disabled. The following list details those options that are not available: ¶ The AutoPack menu ¶ The Tools menu ¶ The browse (...) buttons. If you edit a software package on a managed node that is not the source host of the software package, you cannot access the source host files by clicking the browse button.

Note: The Tivoli Software Distribution Software Package Editor is not available on OS/2 and NetWare managed nodes.

If you are launching the Software Package Editor from an empty software package profile, the Create Software Package dialog is Software a Creating 3. displayed first, before the Software Package Editor main window. Package

Enter the source host name and click Set & Close. The Software Package Editor main window is displayed. If you are launching the Software Package Editor from a software package profile containing

Tivoli Software Distribution User’s Guide 55 Launching the Software Package Editor

a software package in either the built or not-built format, the Software Package Editor main window is displayed.

You can view the contents of a software package in the built format, but you cannot edit and save the changes. To edit a software package block using the Software Package Editor, perform the following steps: 1. Convert the software package block to a software package. 2. Edit the software package using the Software Package Editor. 3. Save the changes and select File→Return from the Software Package Editor menu. 4. Convert the software package back to a software package block.

If you use this procedure on a system from which the original source files are not accessible, you must convert the software package block using the Unbuild option. This option saves the source files to a staging directory on the local system, so that the software package block can be rebuilt without access to the original directory. See “Converting a Software Package” on page 293 for more information.

The Software Package Editor Window Software package preparation begins at the Software Package Editor window. The window displays a graphical tree view of the software package and its contents. The left pane displays the software package icon. Any actions added to the software package are nested directly below the package icon in hierarchical form.

You organize the actions contained in the package in the order in which they are to be executed on the target system. Use the up and down arrow buttons to the right of the toolbar to rearrange the order of the objects in the right pane. The right pane displays the objects contained in the selected object in the left pane. The tabbed toolbar displays additional actions and objects that can be added to the selected item in the tree view. An exclamation mark (!) in the right pane indicates that a condition exists on that particular action.

56 Version 4.1 The Software Package Editor Window

A software package contains a number of actions to be executed on a target machine. These actions can be divided into the following categories: ¶ The add object and remove object actions drive the engine to add the specified object to the system or to remove it from the system. ¶ System actions, such as checking disk space, and restarting the target machine. ¶ Program actions, such as executing a user-defined program; configuration, installation, and distribution (CID) program; InstallShield program; or Microsoft Setup program.

You may have the task of solely preparing software packages and, therefore, are not involved in the distribution process. In this case, you can work from a standalone packaging facility.

To create a software package, you can use any of the following methods while working in the Software Package Editor main window. ¶ After launching the Software Package Editor, create a new Software a Creating 3. software package in the Software Package Editor main window. ¶ Select Open from the File menu to open an existing software package (.sp), software package definition (.spd) file or software Package package block (.spb). Edit the software package and save it with another name so that both the original software package and the edited software package can be used for distribution. You can also choose to save the software package in a different file format (.sp, .spd, .spb). See “Saving the Software Package” on page 151 for more information about software package formats. ¶ Select the AutoPack menu to automatically generate a software package comparing two successive snapshots of a preparation machine’s system. ¶ Select Importer→PDF from the Tools menu to import a Microsoft Package Definition File (PDF) and map its contents to a software package.

Tivoli Software Distribution User’s Guide 57 The Software Package Editor Window

¶ Select Importer→Install MSI Product from the Tools menu to import a Microsoft Software Installer (MSI) file and map its contents to a software package. ¶ Select Program Builder from the Tools menu and choose one of the native installation options: InstallShield or MSSetup. These tools guide you in creating actions in the software package that execute third-party native install programs.

Tivoli Software Distribution, Version 4.1, makes use of a simplified single-content packaging format called the software package. All of the techniques used to create software packages are based on this single file format. Therefore, a software package created using AutoPack is identical to a package created manually using the Software Package Editor, and both can be edited in the same way.

Creating the Appsample Software Package In this section, you will create a sample software package called Appsample on a Windows NT system. The Appsample software package consists of typical actions that take place when installing an application on a workstation.

Windows and OS/2 operating system actions are organized in two separate generic containers. Generic containers are used to group actions together that must satisfy the same condition. You add actions to the software package in the order in which they should be executed.

The first action in the sample software package is the Check disk space action. This action is executed before all other actions because the execution of the other actions depends on whether there is sufficient disk space on the target machine. If the space requirements are met, the distribution proceeds. If the space requirements are not met, the distribution does not take place and an error event is logged and the administrator is notified.

In this scenario, you will add the following actions to create the Appsample software package:

58 Version 4.1 Creating the Appsample Software Package

1. Check disk space. 2. Add all files contained in a directory called Appsample. 3. Create a generic container to house various Windows platform-related actions, such as the following: a. Add two system .dll files, one of which is a shared file. b. Add a new Windows registry key and value for Windows NT and Windows 98 target systems. c. Add a new Windows shell folder containing a shortcut on the Windows desktop. d. Make changes to a Windows profile by modifying an .ini file. e. Add a Windows NT service action. 4. Create a generic container to house various OS/2-related actions, such as the following: a. Create a folder on the desktop containing a program and a shadow. b. Create an OS/2 profile object which adds an item containing

a new section and key by modifying an .ini file. Software a Creating 3. c. Add a line of text, two tokens, and a device to the config.sys file. Package 5. Create an Execute program object whose purpose is to create a log file at the end of the install operation to store information such as a timestamp or version number. 6. Add a restart action that restarts the target system after the install operation of the software package is complete. These items represent the changes that take place or the actions that are executed on the target machine when the software package is distributed.

Some actions require conditions to be set on the execution of the action. For example, certain actions are executed on only particular operating systems. The same software package can have certain actions that are executed on only Windows 98 systems and other

Tivoli Software Distribution User’s Guide 59 Creating the Appsample Software Package

actions that are executed on only Windows NT systems. A condition governs whether an action will be executed or whether it will be skipped for a specific target system. The following sample scenario illustrates how to apply these conditions using the Software Package Editor. Naming the Appsample Software Package When you launch the Software Package Editor, it displays an empty software package icon whose default name is Noname. Begin by naming the software package Appsample.

The name of the software package is a property of the software package. You can replace Noname by clicking it and typing Appsample over it, or you can complete the following steps: 1. Right-click the software package icon to display a pop-up menu, then select Properties. –OR– Select the software package icon, then click the Properties icon from the left toolbar. (To view the name of an icon in the Software Package Editor GUI, hover the mouse pointer over the icon for a few seconds.) –OR– Select the software package icon, then from the menu click Edit→Properties.

60 Version 4.1 Naming the Software Package

The Package Properties dialog is displayed.

2. Specify the name of the software package in the Package name

text box of the General properties page. This name is displayed Software a Creating 3. beside the software package icon in the Software Package Editor window. For the purpose of this scenario, enter Appsample in

the Package name text box. Package 3. Leave 1.0, the default value, in the Package version text box. 4. In the Title text box, enter a short description of the package. The remaining tabs in the Package Properties dialog are described in “Setting Software Package-level Properties” on page 122. 5. Click OK to return to the Software Package Editor window. 6. Save the software package. You can use the package name as the file name or use a different name. 7. To begin adding actions to the Appsample software package, you can perform one of the following actions: a. Click Edit→Insert to select one of the categories of actions.

Tivoli Software Distribution User’s Guide 61 Naming the Software Package

–OR– b. Select the appropriate category from the tabbed toolbar and select an icon associated with the tab. –OR– c. Right-click the software package icon in the left pane then select Insert and the appropriate category from the pop-up menu. Checking Disk Space The necessary disk space required is a parameter of the software package. You can use this action to check the disk space on the endpoint. If the space requirements are met, the distribution proceeds. If the space requirements are not met, the distribution does not occur, and an error event is logged and the administrator is notified.

Complete the following steps to add the check disk space action to the Appsample software package: 1. Select the System action tab from the tabbed toolbar, then click the Check disk space icon. The Check Disk Space Properties

62 Version 4.1 Checking Disk Space

dialog is displayed.

2. In the Drive text box, specify the drive to be checked. 3. Enter the disk space requirement in the Volume text box, specifying the appropriate units of measure. Software a Creating 3. 4. Click Add to add the action to the list. You can add more than

one check disk space action to the same list. To remove a check Package disk space action from the list, select it then click Remove.

Tivoli Software Distribution User’s Guide 63 Checking Disk Space

5. Click Condition to display the Condition Editor dialog.

In this dialog, you can apply a restriction to the execution of the check disk space action by defining the circumstances under which the action should be executed. Conditions can be applied as follows: ¶ On individual actions and objects contained in the software package ¶ On the entire software package (package level) For example, to limit the execution of the check disk space action to Windows NT systems only, specify the following expression in the Condition Editor dialog: $(os_name) == Windows_NT. Click OK to apply the condition to the action and to return to the Check Disk Space Properties dialog. See “Setting Software Package-level Properties” on page 122 for information about setting conditions at the package level. Refer to “Built-in Variables” in the Tivoli Software Distribution Reference Manual for a table containing descriptions and accepted values for built-in variables.

64 Version 4.1 Checking Disk Space

6. Click OK to return to the Software Package Editor window. The package contains the check disk space action displayed in the right pane. .Cetn Software a Creating 3. Adding Directories and Files Use the add directory object action to add directories, files, and links

and to set file system object attributes related to the target operating Package system. In this scenario, you will add an action that adds all files contained in a directory called Appsample to the software package.

Begin by adding an add directory action to the Appsample software package: 1. Select the Appsample software package icon in the left pane. 2. Select the Add object tab from the right toolbar and click the Directory icon.

Tivoli Software Distribution User’s Guide 65 Adding Directories and Files

The Add Directory Properties dialog is displayed:

3. Enter the following information in the Source group box: a. In the Location text, box enter c:\Appsample or click browse (...) to display a file system browser dialog. b. In the Name text box, enter * to specify that all files contained in the Appsample directory are to be added to the package. The files are installed with their original name into the target directory at installation time.

Note: When you specify the name of a source or target file, file and directory names may contain wildcard (pattern-matching) characters. The supported wildcard characters include (*), which matches any string, and (?), which matches any single character. For more information about specifying file and directory names with pattern-matching characters, refer to the Tivoli Software Distribution Reference Manual. 4. In the Destination group box, you find the same information you entered in the Source group box. The destination represents where the specified directory is created on the target system. Delete c:\Appsample in the Location text box and use a

66 Version 4.1 Adding Directories and Files

variable to render this operation more generic for use on different operating systems. Right double-click the Location text box to display the Variable List Editor. .Cetn Software a Creating 3.

5. Define a new variable and associate a default value with it.

a. In the Name text box, enter target_dir. Package b. In the Value text box, enter $(system_drive)\Appsample. c. Click Set to add the new variable and its value to the list. You can reuse this variable anywhere in your software package. To modify the variable, update it in the Variable List Editor and it will change all occurrences in the software package. Refer to the Tivoli Software Distribution Reference Manual for more detailed information about using variables. 6. Click OK to return to the Add directory properties dialog. The source name is repeated in the destination Name text box. The files are installed with their original name into the target directory at installation time.

Tivoli Software Distribution User’s Guide 67 Adding Directories and Files

7. Set the check boxes in the Add Directory Properties dialog: ¶ The Stop on failure check box is selected by default. Leave it selected to discontinue the distribution of the software package if a failure occurs during the execution of the action. ¶ Select the Replace if target is newer check box to replace a target object even if the target object is newer than the source object. On Windows platforms, to determine which file is newer, Tivoli Software Distribution evaluates the version of the file. If the version of the target file is newer than the source file, the target file is replaced. If the version is not set, or on platforms other than Windows, Tivoli Software Distribution evaluates the modification time. If the modification time of the target object is more recent than the source object, the target object is replaced. File version support is available if the source host is a Windows machine or if the software package containing the file in question has been built on a Windows machine and imported in the software package block (built) format. ¶ The Replace if existing check box is selected by default. Leave it selected to replace an object that already exists on the target. ¶ Select the Remove if modified check box to flag this object for a subsequent remove operation. During a remove operation of the same software package, the flag indicates to remove the object even if the target object has been modified since the last install operation. ¶ Select the Add check box to create the directory if it does not already exist on the target system.

68 Version 4.1 Adding Directories and Files

8. Click Advanced to specify platform-specific file system attributes.

9. Leave the Create directories check box selected to create directories if they do not already exist on the target system. If

you know that the directory already exists, clear this check box Software a Creating 3. so that during an install the directory is not created and during an undo operation the directory is not removed. Package 10. Leave the Remove empty directories check box selected to remove empty directories when performing a subsequent remove operation of this software package. 11. Select the Descend directories check box to add the entire directory tree to the software package. If it is not selected, only the files listed below the top-level directory are added. 12. Select the Rename if locked check box to temporarily rename files that are in use by another application. For Windows platforms, during an install an attempt is made to replace or rename the file under the same directory as the locked file and the distribution completes successfully without having to wait for a reboot of the system. The temporary file is removed

Tivoli Software Distribution User’s Guide 69 Adding Directories and Files

during the next system reboot. During a remove operation, the locked file is removed during the next system reboot. For OS/2 systems, only .exe and .dll files are supported. The locked file is closed so that it can be replaced with the file bundled in the software package. During a remove operation, the locked file is closed so that it can be removed from the target system. If the file cannot be renamed or replaced, the distribution fails. 13. Click OK to confirm the file system object properties selected. For more information about the file system attributes in this dialog, refer to the online help documentation or the Tivoli Software Distribution Reference Manual. 14. Click OK to add this action to the software package. Select the software package icon in Software Package Editor window to display the Add directory object action.

70 Version 4.1 Adding Windows Platform Actions to a Generic Container

Adding Windows Platform Actions to a Generic Container The following actions to be added to the Appsample software package are all Windows platform-related actions. You can group related actions together in a generic container and set a condition on the entire container that governs the execution of the contained actions.

Complete the following steps to add a generic container to the software package that contains Windows platform-related actions. 1. Select the Appsample software package icon in the left pane of the Software Package Editor window. 2. Click Container on the tabbed toolbar and select the Generic container icon. The Generic Container Properties dialog is displayed. .Cetn Software a Creating 3. Package 3. In the Name text box, enter a descriptive string such as Windows platform actions. Before you add this container to the software package, you must set a condition on the entire

Tivoli Software Distribution User’s Guide 71 Adding Windows Platform Actions to a Generic Container

container. Click Condition to display the Condition Editor.

4. Enter the following expression to satisfy all Windows actions that will be added to this container: $(os_name) LIKE ‘Win*’ then click OK. Click OK to add the generic container to the software package.

72 Version 4.1 Adding Windows Platform Actions to a Generic Container .Cetn Software a Creating 3.

An exclamation mark in the right pane indicates that a condition

has been set on the generic container. Package

Adding Windows Operating System Directories and Files Next, you will add an action that adds two system .dll files found on the source machine. One of the files is a shared file. Because many applications use the same resources, shared files and directories must be identified in the software package to prevent them from being removed when an application is removed. If a shared resource in a software package is found to exist on the target, the default is to maintain the latest version of the shared resource. 1. Select the Windows platform actions icon in the left pane, then click Add object→Directory from the right toolbar. The Add

Tivoli Software Distribution User’s Guide 73 Adding Windows Directories and Files

Directory Properties dialog is displayed.

2. In the Source group box, enter the parent directory c:\winnt in the Location text box. Enter the subdirectory system32 in the Name text box. 3. In the Destination group box, right double-click the Location text box to display the Variable List Editor dialog. Select the $(system_dir) variable to represent the directory where the file will be installed on the target machine. Click OK. 4. Click OK to add the add directory action to the software package. The Software Package Editor displays the add directory action contained in the Windows platform actions generic container.

74 Version 4.1 Adding Windows Directories and Files .Cetn Software a Creating 3.

5. Specify the file to be added to the target system by nesting an

Add file action in the add directory action. Select the Add Package directory action in the left pane, then select the File icon from the Add object tab on the toolbar. The Add File Properties

Tivoli Software Distribution User’s Guide 75 Adding Windows Directories and Files

dialog is displayed.

6. In the source group box, enter App32.dll in the Name text box. 7. To flag this file as a shared file, click Advanced and select the Is shared check box from the General page of the Add File System Objects Properties - Advanced dialog. 8. Click OK to add the add file action to the software package. When you select the add directory action in the left pane, the add file action is displayed in the right pane of the Software Package Editor main window.

76 Version 4.1 Adding Windows Directories and Files .Cetn Software a Creating 3.

9. Add a second .dll file to the same directory. You can either

repeat the same process and select the Add file icon from the Package Add object tab on the toolbar, or you can use the following timesaving procedure: a. Right-click the add file action just added in the right pane, then select Copy from the pop-up menu. b. Right-click system32, the add directory action, in the left pane, then select Paste. An identical add file action is added to the add directory action. c. Select the second add file action and select the Properties icon from the left toolbar.

Tivoli Software Distribution User’s Guide 77 Adding Windows Directories and Files

The Add File Properties dialog is displayed.

You can also add more than one file or directory at the same time by right-clicking the Add directory action and selecting Insert→Multiple file/directory. A file system browser is displayed. Select any number of files and directories and click Add. Click OK to add the add file and directory actions to the software package. 10. Change the file name from App32.dll to Apprun32.dll. Click Advanced, then deselect the Is shared check box, as this is not a shared file. 11. Click OK to add the second file to the add directory action, then select it to display the files in the right pane.

78 Version 4.1 Adding Windows Registry Objects .Cetn Software a Creating 3.

Adding Windows Registry Objects

In more recent Windows versions, such as Windows 98, Windows Package NT, and Windows 2000, .ini files have been replaced by the Windows registry to store configuration information regarding the user, the hardware, and the programs installed. Many applications continue to use .ini files for backward compatibility. Windows operating systems refer to the registry during operation.

The Appsample software package scenario demonstrates modifying settings in the system registry. For the purpose of this example, information regarding the installation directory for the Appsample application will be stored using the Windows registry action.

Complete the following steps to add Windows registry objects to the software package:

Tivoli Software Distribution User’s Guide 79 Adding Windows Registry Objects

1. Select the Windows platform actions generic container icon in the left pane of the Software Package Editor window. 2. From the Add object tab on the toolbar, click the Windows registry key icon. The Add Windows Registry Key Properties dialog is displayed.

3. Select HKEY_LOCAL_MACHINE in the Hive drop-down list. 4. Specify the Parent Key and the Key. Enter SOFTWARE\Tivoli in the Parent key text box and enter Appsample in the Key text box. 5. Select the Override permissions check box to temporarily override access permissions for adding or removing protected registry keys and values. Access permissions are restored after the operation is completed. 6. A condition must be applied to this particular action. System registry changes are applicable only to Windows 98, Windows NT 4.0, or Windows 2000 machines. Click Condition in the upper right corner of the dialog to display the Condition Editor

80 Version 4.1 Adding Windows Registry Objects

dialog.

7. Enter the following expression to satisfy the restriction: ($(os_name) == Windows_95 OR $(os_name) == Windows_NT). Click Check to verify that the expression is

valid. Click OK to set the condition on the object. Software a Creating 3. 8. Click OK to add the Windows registry object to the software

package. The Software Package Editor displays the Windows Package registry key.

Tivoli Software Distribution User’s Guide 81 Adding Windows Registry Objects

9. To add a subkey to the Appsample Windows registry key, select the Appsample Windows registry key icon. From the tabbed toolbar, click the Windows registry key icon from the Add object tab. The Add Windows Registry Key Properties dialog is

82 Version 4.1 Adding Windows Registry Objects

displayed.

10. Enter 1.0 as the subkey name in the Key text box. 11. Click OK to add the subkey to the Appsample key. 12. To assign a value to the subkey, select the 1.0 subkey, then select Value from the Add object tab. The Add Windows Registry Value Properties dialog is displayed. .Cetn Software a Creating 3. Package

13. Enter InstallationDirectory in the Name box. 14. From the Type drop-down list, select the appropriate type of value (String, Binary, DWORD, Multistring, or Expand String). Select Expand String from the drop-down list.

Tivoli Software Distribution User’s Guide 83 Adding Windows Registry Objects

15. To enter the value in the Data text box, click Edit. The Data editor dialog is displayed. Use the same variable defined in “Adding Directories and Files” on page 65 by right double-clicking the Value text box. Select the $(target_dir) variable from the Variable List Editor dialog and click OK to save the data and return to the Data editor dialog. To add this value to the Data text box, click OK. To modify this value, click Edit. 16. In the Position drop-down list, specify where the new value should be placed in the system registry. Select Replace to substitute the value on the target system. 17. Leave the Replace if existing check box selected to replace the value if it already exists in the system registry. 18. Click OK to display the Software Package Editor window and view the value added to the key.

84 Version 4.1 Adding Windows Shell Objects .Cetn Software a Creating 3.

Adding Windows Shell Objects

Adding Windows shell objects involves creating folders and links to Package programs. You can use this action to configure a target machine’s desktop.

Complete the following steps to create a shortcut or link to the Appsample application in a new folder, Tivoli Appsample, located on the desktop. 1. From the Software Package Editor window, select the Windows platform actions generic container icon. 2. From the Add object tab on the toolbar, select the Windows shell folder icon. The Add Windows Shell Folder Properties

Tivoli Software Distribution User’s Guide 85 Adding Windows Shell Objects

dialog is displayed.

3. Use a built-in variable to specify the location of the folder. Right double-click the Location text box to display the Variable List Editor dialog. 4. Select the $(all_users_shell_desktop) variable and click OK to place the variable in the Location text box. 5. Enter Tivoli Appsample in the Folder text box. This will be the name of the folder on the target system. 6. In the Folder type group box, select Common if the folder and all its contained commands are common to all users. Select Personal, to specify that the folder and its contents apply to the logged-on user only and to install them at the next user logon by the user profile update program. 7. Select the Add check box to create the new folder if it does not already exist on the target system. 8. Before you add the folder to the software package, you must set a condition on this particular action. Windows shell objects apply only to Windows 98, Windows NT 4.0, and Windows 2000. Therefore, click Condition in the upper right corner of the Add Windows Shell Folder Properties dialog to display the

86 Version 4.1 Adding Windows Shell Objects

Condition Editor dialog.

9. Enter the following expression in the dialog: ($(os_name) == Windows_NT OR $(os_name) == Windows_95) AND $(os_release) > 3. Click OK to set the condition on the

Windows shell folder. Software a Creating 3. 10. Click OK to add the Windows shell folder to the software

package. Package

Tivoli Software Distribution User’s Guide 87 Adding Windows Shell Objects

11. Add a link to the Windows shell folder. Select the Tivoli Appsample folder icon in the left pane of the Software Package Editor window, then click the Link icon from the Add object tab on the toolbar. The Add Windows Shell Link Properties

88 Version 4.1 Adding Windows Shell Objects

dialog is displayed.

12. In the Display name text box, enter Appsample 1.0 as the name contained in the new folder, Tivoli Appsample, on the desktop. 13. In the Command text box, indicate the full path to the executable file that launches the application. Specify part of the path using the variable defined in “Adding Directories and Files” on page 65. Right double-click the Command text box to display the Variable List Editor dialog. Select the $(target_dir)

variable, then click OK to insert the variable in the Command Software a Creating 3. name text box. Complete the full path to the command as follows: $(target_dir)\Appsample\bin\Appsample.exe Package 14. Click OK to add the link to the folder and return to the Software Package Editor window.

Tivoli Software Distribution User’s Guide 89 Adding Windows Profile Objects

Adding Windows Profile Objects You can use the Windows profile objects to update Windows .ini files. Windows .ini files store configuration and default settings, such as the computer’s hardware, or environment preferences such as fonts and background color. You update .ini files by manipulating sections that contain values associated to keys. In the following example, you create a new section containing an installation directory key.

Complete the following steps to add Windows profile objects to the software package. 1. Select the Windows platform actions generic container icon. 2. From the Add object tab on the tabbed toolbar, click the Windows profile icon. The Add Windows Profile Properties

90 Version 4.1 Adding Windows Profile Objects

dialog is displayed.

3. Enter the full path to the appsample.ini file in the File name text box. Use a built-in variable to specify part of the pathname by right double-clicking the File name text box. Select the $(system_root) variable and click OK to add the variable to the text box. Complete the file name entry as follows: $(system_root)\appsample.ini. 4. Set a condition on this action to restrict its execution to Windows NT targets only. Click Condition in the upper right corner of the dialog to display the Condition Editor. .Cetn Software a Creating 3. Package

5. Enter the following condition: $(os_name) == Windows_NT. Click OK to set the condition and return to the Add Windows Profile Properties dialog.

Tivoli Software Distribution User’s Guide 91 Adding Windows Profile Objects

6. Click OK to add the Windows profile to the software package.

7. To add a new section to the appsample.ini file, select the Windows profile icon and click the Section icon from the Add object tab on the toolbar. The Add Windows Profile Section

92 Version 4.1 Adding Windows Profile Objects

Properties dialog is displayed.

8. In the Section name text box, enter 1.0 as the name of the section. Click OK to add the section to the Windows profile. .Cetn Software a Creating 3. Package

Tivoli Software Distribution User’s Guide 93 Adding Windows Profile Objects

9. To add items to the section, select the 1.0 section icon, then select the Item icon from the Add object tab on the tabbed toolbar. The Add Windows Profile Item Properties dialog is displayed.

10. In the Key text box, enter InstallationDirectory as the key contained in the section. 11. Enter the $(target_dir) variable defined in “Adding Directories and Files” on page 65 in the Value text box, which represents the value associated with the key. 12. Leave the Duplicate check box selected to update the value of the key if it should already exist on the target system. 13. Click OK to add the key to the software package.

94 Version 4.1 Adding Windows NT Services .Cetn Software a Creating 3.

Adding Windows NT Services

The Windows NT service action can either install or remove a Package service from a Windows NT target operating system. To install the Tivoli Appsample Service on the target system, complete the following steps: 1. Select the Windows platform actions generic container icon in the Software Package Editor window. 2. From the Add object tab on the tabbed toolbar, click the Windows NT service icon. The Add Windows NT Service

Tivoli Software Distribution User’s Guide 95 Adding Windows NT Services

Properties dialog is displayed.

3. Enter the name of the service to be installed on the target system. In the Name text box, enter TivoliAppsample. 4. In the Path text box, enter the path to the service. Use the variable defined in “Adding Directories and Files” on page 65 to express part of the pathname. Right double-click the Path text box. The Variable List Editor dialog is displayed. Select the target_dir variable from the list, then click OK to enter the variable in the Path text box. Complete the pathname as follows: $(target_dir)\bin\AppSrv.exe. 5. In the Display name text box, enter Tivoli Appsample Service. Click OK to add the Windows NT service action to the software package. The Software Package Editor window displays the action in the right pane.

96 Version 4.1 Adding OS/2 Actions to a Generic Container .Cetn Software a Creating 3.

Adding OS/2 Platform Actions to a Generic Container

You can group OS/2 platform-related actions together in a generic Package container and set a condition on the entire container that governs the execution of all of the contained actions. You created a similar container for Windows-related actions in “Adding Windows Platform Actions to a Generic Container” on page 71. 1. Select the Appsample software package icon in the left pane of the Software Package Editor. 2. Click Container on the tabbed toolbar and select the Generic container icon. The Generic Container Properties dialog is displayed. 3. Enter OS/2 platform actions in the Name text box.

Tivoli Software Distribution User’s Guide 97 Adding OS/2 Actions to a Generic Container

4. Click Condition and set the following condition on the generic container using the Condition Editor: $(os_name) == ‘OS/2’. Click OK. 5. Click OK to add the OS/2 platform actions generic container to the software package. The Software Package Editor window displays the empty container.

Adding OS/2 Desktop Objects OS/2 desktop folders function much like containers that are used to organize objects, programs, documents, and other folders. The folders on the desktop represent the directories in the file system.

To add a folder to the desktop containing a program and a shadow, complete the following steps:

98 Version 4.1 Adding OS/2 Desktop Objects

1. Select the OS/2 platform actions icon. Select the OS/2 desktop folder icon from the Add object tab on the tabbed toolbar. The Add OS/2 Desktop Folder Properties dialog is displayed.

2. Right double-click the Location text box to express the location of the folder using a built-in variable. Select the $(os2_desktop) variable from the Variable List Editor, then click OK.

3. Enter Tivoli Appsample in the Title text box. Software a Creating 3. 4. Enter in the OID text box. 5. Click OK to add the OS/2 folder action to the software Package package.

Tivoli Software Distribution User’s Guide 99 Adding OS/2 Desktop Objects

6. To add a program to the folder, select the Tivoli Appsample OS/2 folder in the left pane and select the Program icon from the Add object tabbed toolbar. The Add OS/2 Desktop Program

100 Version 4.1 Adding OS/2 Desktop Objects

Properties dialog is displayed.

7. In the Command text box, enter the path to the program. Express part of the path using the variable defined in “Adding Directories and Files” on page 65 so that the entry is $(target_dir)\bin\Appsample.exe.

8. Enter Appsample as the title of the program. Software a Creating 3. 9. In the Working directory text box, enter the working directory

of the program. Enter $(target_dir)\bin. Package 10. Click OK to add the program action to the OS/2 folder action.

Tivoli Software Distribution User’s Guide 101 Adding OS/2 Desktop Objects

11. To add a shadow object to the OS/2 folder, select the Tivoli Appsample icon in the left pane. From the Add Object tab on the toolbar, select Shadow. The Add OS/2 Desktop Shadow

102 Version 4.1 Adding OS/2 Desktop Objects

Properties dialog is displayed.

12. This particular shadowed object does not have an associated object identification (OID); therefore, select the Title radio button and complete the Location and Title text boxes. a. In the Location text box, use the variable, $(target_dir) defined in “Adding Directories and Files” on page 65. .Cetn Software a Creating 3. b. In the Title text box, enter README.TXT for the title of the shadowed object. Package 13. Click OK to add the shadowed object to the OS/2 folder. The Software Package Editor displays the shadowed object action.

Tivoli Software Distribution User’s Guide 103 Adding OS/2 Profile Objects

Adding OS/2 Profile Objects You can use OS/2 profile objects to update .ini files that contain configuration information. In the following example, you add a new item containing installation information to the Appsample.ini file.

Complete the following steps to add OS/2 profile objects to the software package. 1. Select the OS/2 platform actions generic container icon.

104 Version 4.1 Adding OS/2 Profile Objects

2. From the Add object tab, click the OS/2 profile icon. The Add OS/2 Profile Properties dialog is displayed.

3. Enter the path to the .ini file in the File name text box. Use the $(system_root) variable to express a portion of the pathname by right double-clicking the text box. Select the variable and click OK. Complete the entry to read $(system_root)\appsample.ini. Click OK to add the OS/2 profile to the software package. The Software Package Editor displays the OS/2 profile action. .Cetn Software a Creating 3. Package

Tivoli Software Distribution User’s Guide 105 Adding OS/2 Profile Objects

4. To add an item to the OS/2 profile, select the OS/2 profile icon in the left pane. From the Add object tab, select the Item icon.

106 Version 4.1 Adding OS/2 Profile Objects

The Add OS/2 Profile Item Properties dialog is displayed.

5. Enter 1.0 in the Section text box. 6. Enter InstallationDirectory as the key name in the Key text box. 7. In the Value text box, use the variable $(target_dir), defined in .Cetn Software a Creating 3. “Adding Directories and Files” on page 65. 8. Use the String default value selected in the Type group box. The key value, InstallationDirectory, is a string-type value. Package 9. Select Replace from the Position drop-down list to replace the item in the appsample.ini file. 10. Click OK to add the item to the OS/2 profile. The Software Package Editor displays the OS/2 profile item.

Tivoli Software Distribution User’s Guide 107 Adding Text File Objects

Adding Text File Objects Adding text file objects to a target system enables you to manipulate any type of text file, including DOS configuration files such as autoexec.bat and config.sys, by adding lines, command lines, or tokens to the file. The following example illustrates how to modify the config.sys file on an OS/2 target machine by adding a text line to the file, adding a token to the SET PATH and LIBPATH keys, and adding a command line to the file.

Complete the following steps to add text file objects to the software package: 1. Select the OS/2 platform actions icon in the left pane, then from the Add object tab, click the Text file icon on the toolbar.

108 Version 4.1 Adding Text File Objects

The Add Text File Properties dialog is displayed.

2. Express part of the file name using a built-in variable. Right double-click the File name text box and select the $(system_drive) variable from the Variable List Editor dialog. Click OK to add the variable to the text box, then complete the file name as follows: $(system_drive)\config.sys. 3. Click OK to add the text file object to the software package. The Software Package Editor window displays the text file object contained in the software package. .Cetn Software a Creating 3. Package

Tivoli Software Distribution User’s Guide 109 Adding Text File Objects

4. To add a text line to the config.sys file, select the text file icon in the left pane, then select the Line icon from the Add Object tab on the toolbar. The Add Text File Line Properties dialog is displayed.

110 Version 4.1 Adding Text File Objects

5. In the Text text box enter the following line of text to be added to the config.sys file: REM - BEGIN TIVOLI APPSAMPLE SECTION. 6. Indicate that the line should be placed at the end of the text file by selecting End from the Position drop-down list. 7. Click OK to add the text line action to the text file object. The Software Package Editor displays the text file line action. .Cetn Software a Creating 3. Package

8. To add a token to the text file, select the text file icon in the left pane, then select the Token icon from the Add Object tab on the toolbar. The Add Text File Token Properties dialog is

Tivoli Software Distribution User’s Guide 111 Adding Text File Objects

displayed.

9. In the Text text box, specify the token value to be added to the SET PATH key. Use the variable $(target_dir), defined in “Adding Directories and Files” on page 65, then complete the entry in the Text text box to read $(target_dir)\bin. 10. In the Key text box, enter SET PATH. This value instructs the operating system to include $(target_dir)\bin in its search. A semicolon is automatically inserted before this value. 11. Use the End default value in the Position box to specify that the token will be inserted at the end of the corresponding line of the config.sys file. 12. Click OK to add the token action to the software package. The Software Package Editor displays the add token action.

112 Version 4.1 Adding Text File Objects .Cetn Software a Creating 3.

13. Add a second token that adds a directory to the LIBPATH key.

The OS/2 target operating system will include the directory in Package its search when loading dynamic link libraries. Select the text file object in the left pane, then select the Token icon from the Add object tab on the toolbar. The Add Text File Properties dialog is displayed. 14. In the Text text box, enter $(target_dir)\dll. In the Key text box, enter LIBPATH. Use the End default value in the Position box and click OK to add the second token to the text file. The Software Package Editor displays the two tokens in the right pane.

Tivoli Software Distribution User’s Guide 113 Adding Text File Objects

15. Next, add a driver to the DEVICE command. Select the text file icon in the left pane and select the Command line icon from the Add object tab on the toolbar. The Add Text File Command

114 Version 4.1 Adding Text File Objects

Line Properties dialog is displayed.

16. In the Text text box, enter DEVICE=$(target_dir)\sys\Appsamp.sys, which is the line of text to be added to the config.sys file that contains the path to the driver file. Use the $(target_dir) variable defined in “Adding Directories and Files” on page 65 to express part of the

text. Software a Creating 3. 17. In the Key text box, enter the file name of the driver file. Enter Appsamp.sys in the text box. Package 18. In the Command text box, enter DEVICE. 19. In the Position box, use the End default value to add this command to the end of the config.sys file. 20. Click OK to add the command line action to the text line action. The Software Package Editor displays the command line action.

Tivoli Software Distribution User’s Guide 115 Adding an Execute Program Action

Adding an Execute Program Action You can specify user-defined executable programs to be executed during particular change management operations. Tivoli Software Distribution returns standard error and standard output to the log file. This example adds a user program action that, when executed, creates a log file at the end of the install operation. For more information about change management operations, see “Change Management Operations” on page 297.

To add an execute program action, complete the following steps. 1. Select the Appsample software package icon in the left pane and click the Program tab.

116 Version 4.1 Adding an Execute Program Action

2. Select the Execute program icon to display the Execute Program Properties dialog. .Cetn Software a Creating 3.

3. In this dialog, configure the software package to execute the user Package program log_aft.exe after the install operation is complete. In the Name text box, enter a program name. If you do not specify a name, the default value is the file name entered in the Path text box. 4. With the Install tab selected, enter the pathname to the executable file in the Path text box. Use the $(temp_dir) built-in variable to express a portion of the path name. Right double-click the Path text box and select the $(temp_dir) variable from the Variable List Editor dialog. Click OK to add the variable to the Path text box. Complete the pathname as follows: $(temp_dir)\log_aft.exe.

Tivoli Software Distribution User’s Guide 117 Adding an Execute Program Action

5. Select Bootable to manage programs that can execute a reboot. Specify the maximum number of times the program must be re-executed after it reboots in the Retry text box. 6. In the Corequisite Files box, click Add to specify one or more files or directories that must be downloaded together with the program during execution. After execution, these files are deleted. 7. The exit code settings control the execution of the subsequent action in the software package. In the Exit Code box, the range of program completion codes are specified as a minimum and maximum value in hexadecimal format. The minimum and maximum values can range from 0 to 65535 (0x0, 0xffff). For a SUCCESS exit code, the default is 0. To set the minimum and maximum range, click the text box in the Min or Max column and type a valid hexadecimal value. To set an exit code, click the text box in the Exit Code column and select an option from the scrolling list. To add an exit code to the list, click Add. Ensure the minimum and maximum range is set to an available interval between 0 and 65535. Refer to the execute user program action in the Tivoli Software Distribution Reference Manual for information about the various exit codes that can be returned and their effect on program operations. 8. Click OK to add the execute program action to the software package. The Software Package Editor displays the program action.

118 Version 4.1 Adding the Restart Action .Cetn Software a Creating 3.

Adding the Restart Action

To complete the Appsample software package, add a restart action as Package the final action in the package. Software package actions are executed sequentially, in the order displayed in the Software Package Editor window. In this example, add a restart action that will restart the target computer after the install operation of the software package is complete. For more information about change management operations, see “Change Management Operations” on page 297.

Complete the following steps to add the restart action. 1. Select the Appsample software package icon in the left pane. Click the System action tab from the right toolbar, then click the

Tivoli Software Distribution User’s Guide 119 Adding the Restart Action

Restart icon. The Restart Properties dialog is displayed.

2. The restart action is executed in relation to three change management operations: install, remove and undo. In the Restart Properties dialog, you can select an option in one of the operation group boxes or select options from all three group boxes. For example, in the Restart during install box, you select None so that the target system is not restarted during an install operation. You select After to perform the restart after the execution of the last action contained in the software package. You select Immediately to perform the restart action immediately. The remaining sequential actions contained in the software package are executed after the restart action is complete. Keep the default selection and click OK to return to the Restart Properties dialog. 3. Click OK to add the restart action to the software package.

The Appsample software package scenario is complete. The Appsample Software Package The complete Appsample software package includes the following actions and objects: 1. Check disk space 2. File system objects 3. Windows generic container

120 Version 4.1 Adding the Restart Action

¶ Windows registry objects ¶ Windows shell objects ¶ Windows profile objects ¶ Windows NT service action 4. OS/2 generic container ¶ OS/2 desktop object ¶ OS/2 profile object 5. Execute program 6. Restart action .Cetn Software a Creating 3. Package

Before distributing the software package, you can use the disconnected command line interface to test the package by building it and installing it locally. Use the wdlssp command to produce a list of software packages installed an endpoint, together with the version and change management status of each software package. Refer to the Tivoli Software Distribution Reference Manual for more information about disconnected command line interface commands and software package change management states.

Tivoli Software Distribution User’s Guide 121 Changing the Order of Objects in the Package Changing the Order of Objects in the Software Package You can control the order in which the actions contained in a software package are executed during the distribution to the target system. To rearrange the order of the actions to be executed, select the action in the right pane and use the up and down arrows to the right of the right pane.

It may be necessary to use the up and down arrows when adding a new action to an existing software package. The new action is automatically added to the bottom of the sequential list of actions in the Software Package Editor and, therefore, will be the last action to be executed on the target system. Use the arrows to move the action to the appropriate point of execution.

Setting Software Package-level Properties To set package-level properties, use the Software Package Editor or the command line. From the Software Package Editor window, select the software package icon in the left pane and select Properties from the Edit menu or toolbar, or right-click to display a pop-up menu. For instructions on setting software package properties from the command line, refer to the Tivoli Software Distribution Reference Manual. Software package properties define the following information about the software package to be distributed: ¶ General options, including the name, version, versioning and package types, dependency rules, creation time, and modification time of the software package. ¶ The source host from which the source files and directories are distributed. ¶ Programs to be run before or after the build operation for different target platforms. ¶ Server execution modes, default operations, and operation modes.

122 Version 4.1 Setting Software Package-level Properties

¶ Log information and notification behavior about the software package distribution and platform-specific options to handle user and group ownership of files on the UNIX platform. ¶ Built-in and user defined variables.

To display the Package Properties dialog, right-click the software package icon in the left pane of the Software Package Editor window, then select Properties from the pop-up menu. A dialog containing the following tabs is displayed: ¶ General ¶ Server options ¶ Log file ¶ Description ¶ Copyright ¶ Variable list ¶ Nested packages

Notice the Condition button in the upper right-hand corner of the .Cetn Software a Creating 3. dialog. The Condition button in the Package Properties dialog enables you to set a condition at the package level. Package-level

conditions are considered before lower-level conditions. If a Package package-level condition is not met, the package is not installed and an error message is sent. If the package-level condition is met, but a lower-level condition is not met, the package will install successfully except for those objects whose conditions were not met. Refer to the Tivoli Software Distribution Reference Manual for more detailed information about using conditions. Click OK to return to the Software Package Editor window.

Tivoli Software Distribution User’s Guide 123 Setting Software Package-level Properties

General Properties On the General page, specify unique information that defines and identifies the software package.

1. Enter a unique name in the Package name text box. 2. In the Package version text box, enter the version string. The version string can contain up to 16 alphanumeric characters and can be separated into substrings using dots (.). The dots are included in the total length of the string. Refer to the Tivoli Software Distribution Reference Manual for more information about software package name and version syntax. 3. Select a Versioning Type. SWD turns version checking on. None turns version checking off. 4. If you selected SWD for the Versioning Type, you must select a Package Type which determines the method of version checking, as follows: Refresh The package cannot be installed if a later version of the package is already present on the target.

124 Version 4.1 Setting Software Package-level Properties

Patch The package cannot be installed if the product installed on the target does not have the same base version as the patch to be applied.

See “Software Package Version Checking” in the “Editing the SPD File” chapter of the Tivoli Software Distribution Reference Manual. 5. If you want to define hardware and software prerequisites for the software package, click Dependency. See “The Dependency Editor” on page 125. 6. Enter a title for the package in the Title text box. The title is a longer name associated with the package and is used mainly for display purposes. Tivoli Software Distribution Web Interface displays this text in the Description column of the Web Interface. See “Tivoli Software Distribution Web Interface” on page 333 to view how the Tivoli Software Distribution Web Interface uses the information entered in this text box. 7. Select the History reset check box to erase the software history of all software packages already installed on the endpoint, if the package is installed successfully. Software a Creating 3. 8. Leave the Stop on failure check box selected to stop the

distribution to a target if the execution of an action fails. (The Package distribution continues for other targets.) If you do not select this box, errors are logged as specified in the Log file page of the Package Properties dialog, and the distribution continues, if possible. Creation time and Modification time assist in identifying the software package.

The Dependency Editor Using the Dependency Editor, you can create an expression that defines prerequisites for executing install, remove, and undo actions defined in the software package. You can build a complex expression that includes any number of Hardware-discovered variables and multiple occurrences of the $(installed_software) variable. See

Tivoli Software Distribution User’s Guide 125 Setting Software Package-level Properties

“Defining Dependency and Conditions” in the “Editing the SPD File” chapter of the Tivoli Software Distribution Reference Manual.

To build a dependency expression, perform the following steps: 1. Define a variable. To define Hardware-discovered variable, enter the names of the Hardware-discovered table and of the field within the table in the Table and Field text boxes, then click Add. To define a $(installed_software) variable, click Add Installed Software The variable you specified appears in the expression box at the top of the dialog. 2. Click one of the operators shown in the lower section of the dialog. 3. Click in the expression box and enter a constant. You add the boolean constants, True and False, to the expression, by clicking the appropriate button in the lower section of the dialog.

126 Version 4.1 Setting Software Package-level Properties

4. If you want to define a complex expression, click AND, OR, AND and NOT,orOR and NOT, then add another variable, operator, and constant.

Note: You can check the syntax of the expression, by clicking Check. 5. When the expression defines all the software and hardware prerequisites you want to include, click OK to return to the Package Properties dialog. Server Options On the Server options page, set the source host and program options. See “Software Package Properties” on page 290 for more information about server-related properties. .Cetn Software a Creating 3. Package

Tivoli Software Distribution User’s Guide 127 Setting Software Package-level Properties

Setting Server Options To set the server options, select the Server options tab from the Package Properties dialog. The following dialog is displayed:

1. In the Name text box, specify the source host machine on which the source files referenced in the software package reside. 2. In the SPB path text box, specify the complete path where the software package block resides. 3. In the Stage area text box, specify the complete path to the stage area, which is the working directory of the distribution server. This directory is created during the distribution and erased after the distribution is complete. 4. In the Before build group box, specify any programs to be run on the source host machine before the building of the package

128 Version 4.1 Setting Software Package-level Properties

takes place. The program is executed on the source host prior to the install operation on the target machine. In the After build group box, specify any programs to run on the source host after the build has taken place. For example, if some files required to perform the build are located on a remote drive, use a before build program to mount the remote drive before the build takes place. a. Enter the path and file name in the Program name text box. b. Enter files that the program requires input from, during execution, in the Input file name text box. c. Set the user identification under which to run the before and after programs in the UID text box. d. In the Environment text box, specify the environment variables for the programs specified in the Before build or After build group boxes. e. Select the Skip distribution check box to skip distributing the software package to a subscriber if the Before build program fails and returns a non-zero exit code.

Setting Advanced Server Options Software a Creating 3. Click the Advanced button on the Server options page to display the Server options - Advanced dialog. Package

Tivoli Software Distribution User’s Guide 129 Setting Software Package-level Properties

In this dialog, set default values for software package properties related to change management operations and operation modes. For more information regarding change management operations and operation modes, see “Change Management Operations” on page 297. 1. Default operation mode Select the default operation mode of the software package: Committable ¶ Select Yes to install the software package in transactional mode. ¶ If you select No, the software package cannot be installed in transactional mode. ¶ Select Optional to allow the end-user to decide whether the software package is installed in transactional mode. Undoable

130 Version 4.1 Setting Software Package-level Properties

¶ If you select Yes, the software package must be installed in undoable mode. ¶ If you select No, the software package cannot be installed in undoable mode. ¶ Select Optional to allow the end-user to decide whether the software package is installed in undoable mode. Transactional Transactional mode installs the file in a staging area during the preparation phase and then moves the file from the staging area to the production area during the commit phase. ¶ Select No if you do not want the system to return itself to a consistent state after an operation, even if the operation fails. ¶ Select Yes to request the system to either remain in a consistent state after an operation or, if at least one action does not succeed, to abort the operation and return to its initial state. .Cetn Software a Creating 3. ¶ Select Only if necessary to request the system to execute an operation only if it detects that it cannot

proceed because of an error, such as a locked file. Package ¶ Select Auto commit to request the system to automatically commit a pending operation. Undoable When you are not sure of the results of an operation, select undoable mode, which allows you to return the system to its previous state with a successive undo operation. ¶ Select No to disable the ability to undo an operation. ¶ Select Yes to allow the ability to return the system to its previous state using a backup package.

Tivoli Software Distribution User’s Guide 131 Setting Software Package-level Properties

¶ Select If possible to request the system to continue an operation even if the process to acquire backup copies fails. ¶ If you select Transactional, the operation is performed in two phases: the preparation phase and the commit phase, as in transactional mode. However, during the preparation phase, disk space is reserved for backup copies in the staging area, which minimizes the risk of failure due to insufficient disk space during the commit phase. During the commit phase, the staging area is freed up and all the updates done in the preparation phase take effect. ¶ Select Auto accept to have the system automatically accept an undoable operation. Reboot The reboot options are enabled when the Commit change management operation is selected in the Default operation group box. Reboot options are not valid on UNIX systems. ¶ Select No to execute the commit operation without a machine reboot. This option increases the possibility of errors due to possible locked resources. ¶ Select Yes to execute the commit phase the next time the machine is rebooted by the user. ¶ Select Only if necessary to execute the commit phase with a machine reboot only if necessary. For example, if locked files are found, an auto reboot will be performed. ¶ Select Auto reboot to execute the commit phase with a reboot when only the operating system is running and all other applications are closed. This option prepares the system to complete the operation when the Tivoli Software Distribution agent automatically runs the reboot operation. 2. Extended Attributes

132 Version 4.1 Setting Software Package-level Properties

Select one or any combination of the following options: No check on source host Deselect this check box to perform a check on whether the managed node and the file contents exist when the object is imported as a software package. Move SPO removing host Leave this check box selected to move the software package to the lost-n-found collection if the log host or source host of the software package has removed. Refer to the Tivoli Software Distribution Reference Manual for more information about the lost-n-found collection. No check on remove When this check box is selected, during the removal of a software package, all objects included in the software package are located and removed, regardless of the status of the software package. 3. Default server mode Set the default server mode. These options control which files in the software package are distributed. Select one of the following

mutually exclusive options. Software a Creating 3. All Installs all files and directories in the software package.

Source Package Installs only those objects that have a modification time on the source that is later than the time of the last install. Repair Installs only the following: ¶ The source objects that since the time of the last successful installation have been corrupted, modified, or are not present on the target, to make the target objects consistent with the source objects ¶ The objects and actions on the target that have been changed or corrupted since the time of the last successful installation

Tivoli Software Distribution User’s Guide 133 Setting Software Package-level Properties

The software package is re-built and installed on the target. The repair option applies only to software packages in the following operational states: ¶ Target machines on which the software package has already been installed and committed (IC) ¶ Target machines on which the software package has been installed and committed, but the software package is in error (IC---E) Refer to the Tivoli Software Distribution Reference Manual for more information about software package operational states.

Select one of the following mutually exclusive options: No checks No checks are performed. Checks Verifies that the installation can be executed before the installation is attempted (requires Tivoli Inventory to be installed). Force Forces the operation regardless of the change management state of the software package on the target. For example, even if the software package may already be installed, the execution of the operation is forced. Ignore Performs the installation only on targets that have been successfully checked (requires Tivoli Inventory to be installed). Preview Returns to the log file on the server a list of actions that would be executed if you were to perform an install operation. The software package is not actually installed. 4. Default operation Select one of the following mutually exclusive options. Install Performs the actions listed in the software package.

134 Version 4.1 Setting Software Package-level Properties

Remove Uninstalls a software package. Undo Returns the system to its previous state, prior to the last install or remove operation. Accept Deletes the backup package, so the previous operation can no longer be undone. Commit Causes all the updates performed in the preparation phase to take effect. Verify Verifies the consistency of the software package and the object on the target system. If the verify operation fails, the software package is placed in an error state. Lenient distribution Select this check box to allow distributions and removals to subscribers even if they are not specified in the profile manager of the software package.

Change management operations and operation modes are explained in more detail in the Tivoli Software Distribution Software a Creating 3. Reference Manual.

5. Web view mode Package By means of a Web browser, software package blocks can be made available for installation. Select one of the following options: Hidden The software package is not accessible from the Web user interface. Subscriber The software package is accessible only to subscribers assigned to the software package profile in the current profile manager. Public The software package is accessible to all, without limitations.

Tivoli Software Distribution User’s Guide 135 Setting Software Package-level Properties

For more information about these software package properties, see “Tivoli Software Distribution Web Interface” on page 333. Log File Properties Use the following options to configure information logging on the managed node selected as the log server. Tivoli Software Distribution can issue a report of the success or failure of the software package operation using e-mail, the notice group, or a log file. However, specific information about errors encountered during an operation is available only in the log file.

It is recommended that you always specify a log file. Tivoli Software Distribution creates the log file on the Tivoli management region server (Tivoli server). You can create it on a managed node or target by setting the information in this dialog. It is created by default with the name package-name^package-version.log in the path $BINDIR/../SWDIS/WORK.

136 Version 4.1 Setting Software Package-level Properties

1. In the Path text box, specify the desired directory for the log file on the target. If the directory does not already exist, it is created. The name of the log file is in the format package-name^package- version.log (such as, Office97^1.0.log). By default, Tivoli Software Distribution overwrites the log file for each distribution of the software package. 2. Select the Notice to software distribution group check box in the Log information options group box to have Tivoli Software Distribution post a notice to the group when a software package operation is performed. The notice includes an indication of success or failure of the operation for each target. You must subscribe to the Tivoli Software Distribution notice group to view the notices. 3. Type an e-mail address in the e-mail to text box to have Tivoli Software Distribution send e-mail, including an indication of success or failure of the operation for each target, to the specified address when a software package operation is performed. You can specify multiple e-mail addresses by separating each domain name with a comma. The e-mail path and the alias must be valid on the Tivoli server of the Tivoli management region in which the software package Software a Creating 3. was created. Refer to the Tivoli Management Framework Planning for Deployment Guide for more information about configuring e-mail in your Tivoli management region Package environment. 4. In the Log to host text box, type the name of the managed node on which you want the log file to be located. The log host must be a managed node. If you do not specify a host, the Tivoli server is the default. Indicate the complete path to the log file in the Path text box, or click browse (...) to browse the local file system. 5. Set the UNIX file mode of the generated log file in the Mode text box. 6. Set the UNIX user identification number in the UID text box.

Tivoli Software Distribution User’s Guide 137 Setting Software Package-level Properties

7. Click UNIX attr. to display the Package Properties - UNIX Attributes dialog.

You can specify log file permissions for UNIX target machines in the Package Properties - UNIX Attributes dialog. a. To set the ownership for a particular group, enter the numeric group identification in the Group UID text box. The group identification is a number that corresponds to a specific group name. The default permissions for groups are Read and Execute. b. To set the ownership for a particular user, enter the numeric user identification (UID) in the User UID text box. The user identification is a number that uniquely identifies a user to the system. The defaults for users are selected in the Owner group box: Read, Write, and Execute. c. Specify log file permissions for other types of users in the Others group box. The default does not support any type of file permission. Description Select the Description tab from the Package Properties dialog. You can enter a more detailed description of the software package on this page. If the software package is going to be made available from the Tivoli Software Distribution Web Interface, the text should be entered in HTML format; otherwise, plain text is acceptable. The Web Interface uses the information displayed in this dialog to give a more detailed description of the software package block being

138 Version 4.1 Setting Software Package-level Properties

installed. Click browse (...) to browse the file system and import an existing file into this dialog. See “Tivoli Software Distribution Web Interface” on page 333 for more information about how the Web Interface uses this information. .Cetn Software a Creating 3.

Copyright Package Select the Copyright tab and enter copyright information in the text box. This information, like the description, is used to help you

Tivoli Software Distribution User’s Guide 139 Setting Software Package-level Properties

identify software packages.

Variable List The Variable list page contains all the built-in variables supported by Tivoli Software Distribution. From this page you can also create variables.

140 Version 4.1 Setting Software Package-level Properties .Cetn Software a Creating 3.

To create a variable on the Variable list page, enter a variable name in the Name text box, assign it a value in the Value text box, then Package select Add.

Check the Save default variables check box to make the default variables persistent for future use. The default variables are saved as user variables and are added to the swdis.var file on the target system during the software package installation, so that the same variables can be used for installing upgrades or additional software package features. Refer to the Tivoli Software Distribution Reference Manual for more detailed information about using variables. Nested Packages Select the Nested packages tab to specify existing software packages within the current software package. The current software package is called the primary software package and the packages

Tivoli Software Distribution User’s Guide 141 Setting Software Package-level Properties

specified within it are called nested software packages.

To nest software packages in the primary software package, perform the following steps: 1. Double-click the text box in the Package name column and type the name of the first nested software package. Nested software packages and the primary package must have the same source host but can reside in different policy regions. 2. Double-click the text box in the Package version column and type the version of the nested software package. The version can be one to three numerical strings separated by a period (.). There is no limit to the number of digits you can specify in each string. 3. Specify additional nested software packages by clicking Add.At distribution time, the nested software packages are executed in the order in which they are listed in this dialog. You can also specify the primary package itself in this list.

The order of execution is determined by the position of the software packages specified in the list. For example, if the primary package is

142 Version 4.1 Setting Software Package-level Properties

specified in the third position in the list, the first two nested packages are installed before the primary package. If the primary package is not present in the list, it is installed before all nested software packages. You can also nest software packages using the Tivoli desktop. Drag-and-drop a software package icon from the Profile Manager dialog onto another to nest a software package. See “Distributing Nested Software Packages” on page 327 for more information about the distribution behavior of primary software packages containing nested software packages.

Editing Software Package Properties You can modify a software package by selecting Properties from the Edit menu or toolbar, or by using the right mouse button to display a pop-up menu. You can edit the properties set on the following: ¶ The entire software package ¶ The individual objects contained in the package

To set or edit properties of the entire software package, select the software package icon in the left pane of the Software Package

Editor window, then select Properties to display the dialogs outlined Software a Creating 3. in “Setting Software Package-level Properties” on page 122.

To edit the properties of an object contained in the software package, Package select the object in the right or left pane, then select Properties to reopen the properties dialog.

The following procedure describes how to modify the link properties contained in the Add Windows shell folder action contained in the Appsample software package. 1. Select the Tivoli Appsample Windows shell folder icon in the left pane of the Software Package Editor window, then right-click Link under the Object type column in the right pane. A pop-up menu is displayed.

Tivoli Software Distribution User’s Guide 143 Editing Software Package Properties

2. Select Properties to reopen the Add Windows Shell Link Properties dialog displayed at step 11 on page 88. 3. Make any necessary changes, then select OK to confirm the changes.

Note: After modifying properties of an object, the Software Package Editor Java interface does not always refresh to display the changes. Save the software package and reopen it to display the correct information.

Program Actions in the Software Package Editor In addition to the actions that you added to the Appsample software package, the Software Package Editor supports the addition of a number of program actions which execute the following types of programs on the target systems:

144 Version 4.1 Other Software Package Actions

¶ IBM Configuration, Installation, and Distribution (CID) programs. See “The Execute CID Program Action”. ¶ Installation of a program using the InstallShield program. See “The InstallShield Program Action” on page 146. ¶ Installation of a program using the Microsoft Setup program. See “The Microsoft Setup Program Action” on page 149. ¶ Installation of a program using the Microsoft Software Installer (MSI) program. See “Embedding MSI Installation Packages in a Software Package” on page 181.

Refer to the online help documentation for a more detailed explanation of these dialogs. The Execute CID Program Action The IBM configuration, installation, and distribution (CID) architecture provides for the remote, unattended installation and configuration of OS/2 applications that use the OS/2 Software Installer. The OS/2 Software Installer response file (.rsp file) is used as the input.

Select the Program tab and click the Execute CID Program icon Software a Creating 3. from the toolbar. The Execute CID Program Properties dialog is Package

Tivoli Software Distribution User’s Guide 145 Other Software Package Actions

displayed.

The InstallShield Program Action The InstallShield program action enables you to create a program object that runs installations of applications that use the InstallShield installation program. You can use this program action to install an application whose installable files are located on a network drive. Tivoli Software Distribution uses the application’s native installation (InstallShield) to perform a redirected installation. For example, to install the Tivoli desktop application whose installable files are located on a network drive, perform the following steps: 1. Set the software packages properties at the package level. a. Right-click the software package icon in the left pane and select Properties from the pop-up menu. b. On the General page, enter the software package name and version and a descriptive title.

146 Version 4.1 Other Software Package Actions

c. Click Condition on the Software Package Properties dialog in the upper right corner of the dialog. Enter the following expression in the dialog: os_name LIKE ‘Win*’, then click OK. d. Select the Variable list tab. Enter net_dir in the Name text box and the path to the installation images \\aquarius\images\desktop in the Value text box, then click Set. e. Click OK to save the software package property settings and close the dialog. 2. Select the Program tab, then click the InstallShield program icon from the toolbar. The InstallShield Program Properties dialog is displayed. .Cetn Software a Creating 3. Package

a. In the Name text box, enter Tivoli desktop installation.

Tivoli Software Distribution User’s Guide 147 Other Software Package Actions

b. In the Path text box, use the net_dir variable to define part of the path to the setup executable. Right double-click the Path text box to display the Variable List Editor dialog. Select the net_dir variable, then click OK to enter the variable in the text box. Complete the entry in the Path text box to read as follows: $(net_dir)\setup.exe. 3. Click Advanced to set the response and log files. The InstallShield Program Properties – Advanced dialog is displayed.

a. In the Response file text box, enter the InstallShield response file $(net_dir)\setup.iss. b. In the Log file text box, enter the pathname of the InstallShield log file. Use the $(system_drive) variable to express part of the path by entering the following: $(system_drive)\tmp\install.log. c. Leave the Silent check box selected to perform an unattended installation. d. Click OK to save the values and return to the InstallShield Program Properties dialog. 4. Click OK to add the InstallShield program action to the software package. 5. Save the software package in the .spd format. You can proceed with the distribution and installation of the software package by importing it into a software package profile from the Tivoli desktop on the Tivoli server. See “The Distribution Process” on page 277 for more information about creating profiles and importing and distributing software packages.

148 Version 4.1 Other Software Package Actions

The Software Package Editor also provides the InstallShield tool to guide you through the creation of an InstallShield program object. To launch the InstallShield tool, select Tools→Program Builder→InstallShield from the menu bar. Refer to the online help about this tool for more information. The Microsoft Setup Program Action The Microsoft Setup program action enables you to create a program object that runs installations of Windows applications that use the Microsoft Setup installer.

Select the Program tab, then click the MS Setup program icon from the toolbar. The Microsoft Setup Program Properties dialog is displayed. .Cetn Software a Creating 3. Package

The Software Package Editor also provides an MSSetup tool to guide you through the creation of an MSSetup program object. To launch the MSSetup tool, select Tools→Program Builder→MSSetup from the menu bar.

Tivoli Software Distribution User’s Guide 149 Remove Actions Remove Actions A typical installation process, in addition to adding objects such as files, directories, registry entries, and shell folders, must also remove some objects. Every object-related action described in this chapter that adds an object to a target machine also has a corresponding remove object-related action. For example, to uninstall an application that is not equipped with an uninstall utility, you can add a series of remove actions to the software package to remove the folders, files, directories and registry entries related to the installation of the application.

Click the Remove object tab from the toolbar to display the possible remove actions. For example, to remove a value assigned to a Windows registry key, complete the following steps: 1. Select the Windows registry key icon to display the Remove Windows Registry Key Properties dialog.

2. Enter the Hive, Parent Key, Key, and Class. 3. Select the Remove check box if you want Tivoli Software Distribution to remove the Windows registry key containing the value. 4. Click OK to add the Remove Windows registry key action to the software package. 5. Right-click the Remove Windows registry key action and select Insert→Value. The Remove Windows Registry Value Properties

150 Version 4.1 Remove Actions

dialog is displayed.

6. Enter the name of the value to be removed, then click OK.

Saving the Software Package The Appsample software package created in the Software Package Editor displays only a description of the objects contained in the package. That is, it contains a sequential list of actions to be executed on the target machine and not the objects or resources themselves such as files and programs to be executed. Actions require resources to be executed. When the actions are consolidated with the actual resources (files, directories, registry keys, and so on), the software package is considered to be in a built format (.spb). Software a Creating 3.

A software package that consists solely of a description of the actions and objects contained in the package and not the objects or Package resources themselves, is considered to be in a not-built format (.sp, .spd). To consolidate the actions with the resources into a zipped file, you save the software package as a software package block, selecting .spb as the file type. The software package, in this format, is in the built format.

To create a software package block, complete the following steps:

Tivoli Software Distribution User’s Guide 151 Saving the Software Package

1. Select Save as from the File menu. The Save dialog is displayed.

2. Select the appropriate directory, then enter a file name in the File name text box. The file name can be different from the package name. 3. In the Files of type list, select Software Package Block (.spb), then click Save. Saving the software package in this format performs a local build of the software package. All source files must reside on the local machine for the build to be performed successfully. Depending on the size of the package, this operation may take several minutes. Upon completion of the build operation, Software Distribution asks if you would like to reload the package in the Software Package Editor main window. The procedure to reload the software package can take several minutes if the software package contains an add directory action with the Descend directories option selected. When the software package is reloaded, the structure may be different because Software Distribution must add the entire directory tree to the software package by creating the related actions (add directory, add file). For more information about the Descend directories option, see step 11 on page 69. Note the other two formats available. You can also save the Appsample software package as a software package file by selecting Software Package (.sp) from the Files of type list.

152 Version 4.1 Saving the Software Package

4. To transform the software package file or software package block into a software package definition file, open the file in the Software Package Editor, then save it in software package definition format by selecting this option from the Files of type drop-down list. This procedure transforms the software package into text file format. The text file consists of a sequence of stanzas, each of which describes the actions contained in the software package.

You can use the .spd file as the basis to create a new software package or to edit an existing one. Refer to the Tivoli Software Distribution Reference Manual for more information about editing the .spd file.

The .spd file is the text version of the information that the

Software Package Editor tree view displays. Using a text editor, Software a Creating 3. you can view the .spd file, modify it, and then reopen it in the Software Package Editor and save it in another format. To view

the Appsample software package in the software package Package definition file format (Appsample.spd), refer to the .spd file examples in the Tivoli Software Distribution Reference Manual. To import a software package definition file into the Tivoli Management Framework environment, see “Importing a Software Package into the Tivoli Environment” on page 285.

Tivoli Software Distribution User’s Guide 153 Saving the Software Package

154 Version 4.1 .Sfwr Distribution Software 4. nOS/400 on 4 Using Tivoli Software Distribution on OS/400

This chapter provides a summary of the Tivoli Software Distribution features that are specific for OS/400 operating systems. It includes the following information: ¶ An overview of the Software Distribution features that are available for OS/400 systems. See “Defining Software Packages with OS/400 Objects” on page 156. ¶ An overview of the file systems used on OS/400 systems. This section includes guidelines on how to define file locations on the OS/400 native system and the Integrated File System (IFS). See “The OS/400 Native and Integrated File Systems” on page 158. ¶ Instructions for adding OS/400-specific objects to a software package using the OS/400 Software Package Editor (SPE). See “Defining Software Packages with OS/400 Objects” on page 156. ¶ Information about adding objects to an OS/400 native file system using the standard Software Distribution Add Directory and Add File actions. See “Adding Non-Native Objects to the OS/400 Native File System” on page 172. ¶ Information about using the standard Software Distribution Execute User Program action to run programs on an OS/400 system. See “Running an OS/400 Executable Program” on page 175.

Tivoli Software Distribution User’s Guide 155 Using Tivoli Software Distribution on OS/400

¶ OS/400-specific information about the Software Distribution Data Moving Service which enables you to move data in both OS/400 native file systems and IFS. See “The Data Moving Service in an OS/400 Environment” on page 178. Notes: 1. The disconnected command line interface, available for other systems, is not available for managing software packages on OS/400 machines. 2. AutoPack technology is not available from the OS/400 Software Package Editor.

Defining Software Packages with OS/400 Objects Tivoli Software Distribution 4.1 includes a Software Package Editor (SPE) for OS/400 systems. This is a Java-based GUI that you use to create and customize software packages for distribution to OS/400 systems.

You install and use the Java-based OS/400 Software Package Editor on an NT machine that has a TCP/IP connection to an OS/400 machine that is used to as a preparation site for software packages. Installation and use of the SPE requires the installation of the following SPB files: ¶ SWDISEP_NTAS400.spb on the NT machine ¶ SWDISEP_400PS.spb on the OS/400 machine

See “Installing the Tivoli Software Distribution Java Endpoint Package Editor” on page 39.

You define and save software packages on the NT machine, but you select the objects that are to be included in the package from the file system of the OS/400 machine. The software packages created in this way can be imported to the TMR in the same way as other software packages.

The OS/400 SPE uses the Integrated File System (IFS) to browse for files to be included in the software package. This allows you to use

156 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4.

the standard SPE actions, for example, Add Directory and Add File,

when defining the OS/400 software package. The OS/400 SPE also OS/400 on includes additional actions that allow you to include OS/400 native objects and programs in the software package. See “The OS/400 Native and Integrated File Systems” on page 158 for an explanation of how file locations are defined using the OS/400 native system and the IFS.

The OS/400 SPE allows you to perform the following specific OS/400 tasks: ¶ Add and remove OS/400 libraries and objects. ¶ Add and remove OS/400 licensed programs. ¶ Change OS/400 system values.

For instructions on performing these tasks, see “Using the OS/400 Software Package Editor” on page 159.

In addition, you can use many standard features of the SPE, as follows: ¶ Distribute directories and files. ¶ Distribute text files that are ASCII encoded on the source host and that could be translated in EBCDIC on the OS/400 target. ¶ Execute programs on the target.

The use of the SPE to perform these tasks is described in “Creating a Software Package” on page 53. “Adding Non-Native Objects to the OS/400 Native File System” on page 172 and “Running an OS/400 Executable Program” on page 175 provide examples of how to define the destinations of software package objects on OS/400 native file systems.

If you are using IFS, the objects can be edited and managed in the same way as UNIX objects. This means that you can add files, directories, and links to achieve the same results as you would in a UNIX environment.

Tivoli Software Distribution User’s Guide 157 Using Tivoli Software Distribution on OS/400

The software packages should be stored on the system database in the built (.spb) format. You should not save packages in an unbuilt format as they cannot be built later. You can then upload such packages, through a gateway, to the Tivoli management region server, which routes the packages to target OS/400 systems.

Note: When you build a software package that contains an add action that refers to a native OS/400 object, a *SAVF file containing the source object is created on the OS/400 preparation site and added to the software package block file. For this reason, Software Distribution manages all the OS/400 native objects that can be saved in, and restored from a *SAVF file, including licensed programs.

The OS/400 Native and Integrated File Systems The OS/400 file system is an integrated database containing objects instead of files. The integrated file system provides you with a typical hierarchical file system interface that is analogous to a UNIX system.

A QSH shell interface supports the standard pathname syntax for files and directories that are offered by UNIX shell systems. The native file system can also be referred to in a UNIX-like path name convention using the IFS. For example, it is possible to refer to the QGPL library with: /QSYS.LIB/QGPL.LIB

To a default printer output queue QGPL/QPRINT with: /QSYS.LIB/QGPL.LIB/QPRINT.OUTQ

Native objects are generally mapped into: /QSYS.LIB /.LIB/.

The object type is identified by a . name suffix. IFS maps physical files with members into directories; therefore a physical file member is referred to thus: /QSYS.LIB/.LIB/.FILE/.MBR

158 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4.

Navigating the IFS by means of the SPE FileChooser graphical user

interface (GUI), you can install, remove, and manage software OS/400 on packages containing UNIX objects on an OS/400 system.

Using the OS/400 Software Package Editor The software allows you to perform change-management operations on OS/400 systems and to manage how software package actions are executed on an OS/400.

The OS/400 SPE is based on the standard Tivoli Software Package Editor. Therefore, operations that you can perform from either the standard SPE or the OS/400 SPE are not repeated in this section. For information about these common operations, see “Creating a Software Package” on page 53.

This section describes how you use the OS/400 SPE to perform the following software package operations from an NT preparation site: ¶ Add an OS/400 library ¶ Add an OS/400 object ¶ Remove an OS/400 library ¶ Remove an OS/400 object ¶ Add an OS/400 licensed program ¶ Remove an OS/400 licensed program ¶ Change an OS/400 system value Launching the OS/400 Software Package Editor Start the OS/400 Software Package Editor logon, as follows: 1. Double-click the Software Package Editor OS400 icon on your desktop.

Tivoli Software Distribution User’s Guide 159 Using Tivoli Software Distribution on OS/400

The OS400 Logon dialog is displayed.

2. Type the OS/400 host machine name, user ID, and password for the machine to which you want to connect. 3. Click OK to return to the Software Package Editor main window.

Notes: a. At the preparation site, your user ID should have *ALLOBJ authority on the AS/400®. b. Before you use the OS/400 Software Package Editor, perform the following actions on the AS/400 preparation site machine: ¶ Make sure that all host server daemons have been started. See command strhostsvr *all.

160 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4.

¶ Install the OS/400 Preparation Site software provided

with the software package block “SWDISEP_400PS”. OS/400 on c. The build of a package runs in a job under the specified user profile. Adding OS/400 Libraries and Objects You use the Add OS/400 Library and Add OS/400 Object commands to specify the OS/400 objects that are to be installed on the target systems. An OS/400 Object can only be added within a library, therefore, even if the library already exists on the target system, you must specify it in the software package, and then specify the objects within that library that are to be added on the target system.

You can specify which objects from the library are to be included, as follows: ¶ All objects in the library are to be included. ¶ Only objects that have changed since a specified reference data and time are to be included. ¶ Selected objects, specified using the Add OS/400 Object command, are to be included.

To add an OS/400 library to a target system, perform the following steps: 1. In the Software Package Editor window, select the Add object tab.

Tivoli Software Distribution User’s Guide 161 Using Tivoli Software Distribution on OS/400

2. Select the OS400 Library icon. The Add OS400 Library Properties dialog is displayed.

3. In the source Location text box, type the location of the parent library where the library to be added is located or use the browse (...) button to locate the library. The path cannot contain wildcards. The location you specify is duplicated in the destination Location text box. 4. In the source Name text box, type the name of the library to be added. You can use wildcards in this text box. This name is duplicated in the destination Name text box. 5. In the destination Location text box, specify the location of the OS/400 parent library to which the package is to be added, or use the browse (...) button to locate the library. 6. In the destination Name text box, type the name of the library to which you want the package to be added, or use the browse (...) button to locate the library. 7. If you do not want to add all library objects, clear the Descend check box. This is the default.

162 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4.

8. If you want to add all library objects, or changed objects, select

the Descend check box and then define the library contents you OS/400 on want added to the software package. You do this by selecting one of the following option buttons: All Objects Selecting this option button adds all the objects that the library contains. Changed Objects Only Selecting this option button adds only the objects that were changed after a specified reference date and time. 9. If you selected the Changed Objects Only option button, you must specify the reference date and time in the Reference Date and Reference Time text boxes. The format for the time must be HH:MM:SS. Though the separator can change according to the setting of the QTIMSEP system value, which supports the following separators: ¶ Colon (:) ¶ Period (.) ¶ Comma (,) ¶ Blank 10. From the Replace Options drop-down list, select the appropriate replace option, as follows: ALL All the objects contained in the library are added to the target system. This is the default. NEW Only objects that do not already exist in the target library are added to the target system. OLD Only objects that already exist in the target library are added to the target system to replace the old ones. 11. In the Target Release text box, type the release of the target OS/400 system. The target release can be specified as follows: *CURRENT This indicates the current release.

Tivoli Software Distribution User’s Guide 163 Using Tivoli Software Distribution on OS/400

*PRV This indicates the previous release with modification level 0. VxRyMz Where x is a valid version number, y is a valid release number and z is a valid modification level.

Note: If the AS/400 endpoint is not consistent with this value, the object is not installed. 12. Define on which machine the selected library objects are to be collected at execution time, in either of the following ways: ¶ On the OS/400 preparation machine when the package is created: clear the Remote check box. This is the default. This creates a *SAVF. ¶ On the target machine at execution time: select the Remote check box. This does not create a *SAVF. 13. To insert a condition check, click the Condition button and make your selections in the Condition Editor dialog displayed. 14. Click OK to activate the operation. Adding OS/400 Objects If you did not select the Descend check box in the Add OS/400 Library dialog, you must use the Add OS/400 Object action to add individual OS/400 objects to the OS/400 library that you have added. Each Add object has a green plus sign (+) in its icon. To add an OS/400 object to a library, perform the following steps: 1. In the left pane of the Software Package Editor window, select the OS/400 library object to want to add the object to.

164 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4.

2. In the Add object tabbed page, click the OS400 Object icon.

The Add OS400 Object Properties dialog is displayed. OS/400 on

3. In the source Location text box, specify the path name of the library that contains the object to be added to the software package. The path cannot contain wildcards. This path name is duplicated in the destination Location text box. 4. In the source Name text box, specify of the name of the library object to be added. You can use wildcards in this name. 5. In the destination Location text box, specify the destination path name of the library to which the object is to be added. 6. In the destination Name text box, specify the name of the object to be added. 7. Specify where the object is to be collected, as follows: ¶ Select the Remote check box if you want the object to be collected on the target machine at run time. ¶ Clear the Remote check box if you want the object to be collected on the OS/400 preparation machine when the package is created. 8. If you want to insert a condition check, click the Condition button and make your selections in the Condition Editor dialog. 9. Click OK to activate the operation.

Tivoli Software Distribution User’s Guide 165 Using Tivoli Software Distribution on OS/400

Removing OS/400 Libraries To remove a library from a target OS/400 machine, perform the following steps: 1. In the Software Package Editor window, select the Remove object tab. 2. Select the OS400 Library icon. The Remove OS400 Library Properties dialog is displayed.

3. In the Location text box, specify the location of the parent library of the OS/400 library to be removed. 4. In the Name text box, specify the name of the library you want to remove. 5. If you want to remove the library and its contents from the target system, select the Descend check box. Clear this check box if you want to remove an empty library from the target system. Cleared is the default. 6. If you want to insert a condition check, click the Condition button and make your selections in the Condition Editor dialog displayed. 7. Click OK to activate the operation. Removing OS/400 Objects The Remove OS/400 Object action enables you to remove individual objects from a library. Each remove object has a red minus sign (-) in its icon. To remove an OS/400 object, perform the following steps:

166 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4.

1. In the left pane of the Software Package Editor window, select

the OS/400 library from which you want to remove the object. OS/400 on 2. In the Remove Object page, select Remove object. The Remove OS400 Object Properties dialog is displayed.

3. In the Location text box, specify the location of the OS/400 library containing the object to be removed, if the location is not already shown. 4. In the Name text box, specify the name of the OS/400 object to be removed. 5. If you want to insert a condition check, click the Condition button and make your selections in the Condition Editor dialog displayed. 6. Click OK to activate the operation. Adding OS/400 Licensed Programs Using the Add OS/400 Licensed Program action, you can add an action to a software package to install a licensed program on an OS/400 system. The following options are available for retrieving the licensed program to be installed: ¶ From an existing LICPGM. This is a local operation where you provide the ID of the licensed program already installed at the preparation site. At build time, the program is retrieved from the source machine, saved in a *SAVF, and included in the package. At install time, the program is installed on the target machine. ¶ From a device. This is a remote operation where you specify the device, for example, a CD-ROM, from which the program will

Tivoli Software Distribution User’s Guide 167 Using Tivoli Software Distribution on OS/400

be installed. At build time, no *SAVF is included in the package. At install time, the program is installed on the target system from the specified device. ¶ From an existing save file. This is a remote operation where you specify the path name of the *SAVF that to be used to install the program at installation time. At build time, no *SAVF is included in the package, but at install time, the program is installed on the target system from the specified *SAVF file.

To add an OS/400 licensed program, perform the following steps: 1. In the Software Package Editor window, select the Add object tab. 2. Select the OS400 Licensed Program icon. The Add OS400 Licensed Program Properties dialog is displayed.

3. In the text boxes, type the required information about the licensed program, as follows: Name Type the alphanumeric code of the licensed program to be installed, in the OS/400 format (5763XD1).

168 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4.

Option

Type the name of the optional parts for the specified OS/400 on licensed program. The default is *BASE. Language Type the language option of the specified licensed program. The default is *PRIMARY. Release Type the release of the licensed program to be installed. This is not necessary if the specified product contains only one release.

The default is *ONLY. Target Release Type the release of the target OS/400 system. The default is *CURRENT. 4. From the Type drop-down list, specify the object type to be restored, as follows: *ALL Installs both the licensed program and the language components. This is the default. *PGM Installs only the program. You use this type, for example, if you have upgraded the program but not the language component. *LNG Installs only the language component. You use this type, for example, if you are adding a new language to a previously installed licensed program. 5. If the device containing the licensed program to be added is already located on the target machine, select the Remote check box and locate the program in either one of the following ways: ¶ Specify in the Savf text box the SAVF in which the licensed program is located. Use the format /QSYS.LIB/MYLIB.LIB/SAVF.FILE. ¶ Specify in the Device text box the device name on which the program is located, for example, the optional device name.

Tivoli Software Distribution User’s Guide 169 Using Tivoli Software Distribution on OS/400

6. If you want to insert a condition check, click the Condition button and make your selections in the Condition Editor dialog displayed. 7. Click OK to activate the operation. Removing OS/400 Licensed Programs The Remove OS/400 Licensed Program action enables you to specify the ID of the program to be removed from the target system. At install time, the specified program is removed from the target system.

To remove an OS/400 licensed program, perform the following steps: 1. In the Software Package Editor window, select the Remove object tab. 2. Select the OS400 Licensed Program icon. The OS400 Licensed Program Properties dialog is displayed.

3. In the text boxes, type the required information about the licensed program to be removed, as follows: Name Type the alphanumeric code of the licensed program to be removed, in the OS/400 format (5763XD1). Option Type the name of the installation option for the specified licensed program. The default is *BASE.

170 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4.

Language

Type the language option of the specified licensed OS/400 on program. The default is *PRIMARY. Release Type the release of the licensed program to be removed. This is not necessary if the specified product contains only one release. The default is *ONLY. 4. If you want to insert a condition check, click the Condition button and make your selections in the Condition Editor dialog displayed. 5. Click OK to activate the operation. Changing an OS/400 Sysval The Set OS/400 System value action enables you to specify a new value for an OS/400 SYSVAL name/value pair.

To change a system value, perform the following steps: 1. In the OS/400 Software Package Editor window, select the System action tab. 2. Select the Set OS400 system value icon. The OS400 System Value Properties dialog is displayed.

3. In the Name text box, type the name of the system value to be changed. 4. In the Value text box, type the new value of the system value you specified. For more information about OS/400 system values, refer to OS/400 Work Management, SC41-5306.

Tivoli Software Distribution User’s Guide 171 Using Tivoli Software Distribution on OS/400

5. If you want to insert a condition check, click the Condition button and make your selections in the Condition Editor dialog displayed. 6. Click OK to save the information and close the dialog.

Using Non-OS/400-Specific Functions In addition to the OS/400 specific functions, you can use standard functions of the SPE when you are defining a software package for distribution to an OS/400 system, as follows: ¶ The Add Directory and Add File functions, to add a non-native file, for example from a Unix system, to an OS/400 system. See “Adding Non-Native Objects to the OS/400 Native File System”. ¶ The Execute User Program action, to run a program, for example, a C, CL, REXX, exec, or batch job script. See “Running an OS/400 Executable Program” on page 175.

The purpose of this section is to clarify how to specify the destination paths for files in an OS/400 native file system. Examples are provided that show the stanzas that define the add directory, add file, and execute user program actions in the SPD file.

Note: If the destination file system is OS/400 IFS, files are specified in the same way as for a Unix file system. Adding Non-Native Objects to the OS/400 Native File System You can use the SPE to add objects in a software package that will add non-native objects to an OS/400 file system. In this way, you can take files from a non-OS/400 file system, for example Windows or Unix, and add them to the OS/400 native file system as physical files or file members.

You add the objects to the software package using the Add Directory and Add File actions included in the standard SPE. See “Adding Directories and Files” on page 65.

172 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4.

To add a directory or file to an OS/400 native file system, you

specify an OS/400 native physical file as the destination path. At OS/400 on installation time, Software Distribution adds the file to the native physical file as a file plus member, or as an additional member of an existing file. Notes: 1. If the target physical file already exists on the target system, it maintains its attribute, for example, PF_DTA. If the physical file does not exist on the target system, a new physical file is created with attribute PF_SRC (Source Physical File). 2. When adding members to a physical file, ensure that the maximum number of members (MAXMBRS) and the file size (SIZE) are sufficient to accept the new members. 3. You cannot add a group of files with the same name and different extensions. OS/400 does not use extensions to differentiate between files. OS/400 extensions are assigned to the files when they are added to the file system and the original extensions are lost. This means that files with the same name will overwrite each other. 4. When adding an object to an OS/400 target system, the last modified date is set to the current date. However, the date used to determine whether the object should be added is the last modified date on the source system. When specifying an OS/400 file system path, use the convention described in the section “The OS/400 Native and Integrated File Systems” on page 158. For example, to add files of directory /usr/sd41/source to library mylib.lib, use the following: ... add directory location = “/usr/sd41” name = “source” destination = “/QSYS.LIB/MYLIB.LIB” add=y descend_dirs = y translate = y end ...

Tivoli Software Distribution User’s Guide 173 Using Tivoli Software Distribution on OS/400

At installation time, these actions add the files (collected at build time on a Windows or UNIX source host) as files of the library MYLIB.LIB. Each file contains a member that has the name on the physical file (/QSYS.LIB/MYLIB.LIB/FILE_1.FILE/FILE_1.MEMBER). By default, the files are created as OS/400 source physical files (PF_SRC).

To add files FILE1.DAT and FILE2.DAT to an existing OS/400 physical file, use the following: ... add directory location = “/usr/sd41” name = “source” destination = “/QSYS.LIB/MYLIB.LIB/DATA.FILE” add=y descend_dirs = n file name = “FILE1.DAT” destination = “FILE1.MBR” translate = y end file name = “FILE2.DAT” destination = “FILE2.MBR” translate = y end end end ...

At installation time, this commands adds the FILE1.DAT and FILE2.DAT (collected at build time on a Windows or UNIX source host) as members of an existing OS/400 physical file (/QSYS.LIB/MYLIB.LIB/DATA.FILE/FILE1.MBR ... FILE2.MBR).

In the example, the translate attribute is set to y. This enables translation from ASCII to EBCDIC and code page translation. Translation is performed before the file is added to the OS/400 physical file.

174 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4. Running an OS/400 Executable Program

You can use the SPE to add an Execute User Program action to a OS/400 on software package that includes an OS/400 program, such as C, CL, REXX, an exec, or batch job script. At installation time, Software Distribution runs the program on OS/400 subscribers.

Note: If the program to be executed is not already on the target machine, you can install it by using the add OS400 object action. An example definition for an installation of an OS/400 program followed by its execution is given at the end of this section.

The locations of the user program to be executed, its output and error files are specified in the path, output_file, and error_file attributes of the execute_user_program stanza. When specifying a path, use the convention described in the section “The OS/400 Native and Integrated File Systems” on page 158.

For example, the following stanza adds an action to execute the CL program outmsg: ...... execute_user_program name = “outmsg” transactional = n

during_install

exit codes success = 0,0 failure = 1,65535 end

path = “\qsys.lib\mylib.lib\outmsg.pgm” arguments = “first second” timeout = -1 unix_user_id = 0 unix_group_id = 0 user_input_required = n output_file = “\qsys.lib\mylib.lib\output.file\output.mbr” error_file = “\qsys.lib\mylib.lib\output.file\error.mbr”

Tivoli Software Distribution User’s Guide 175 Using Tivoli Software Distribution on OS/400

output_file_append = y error_file_append = y end ......

At installation time, this action runs the program located at /QSYS.LIB/MYLIB.LIB/OUTMSG.PGM. Program output and error files are created on the OS/400 target system as members of /QSYS.LIB/MYLIB.LIB/OUTPUT.FILE/ERROR.MBR...OUTPUT.MBR.

The following example runs the CL post program that uses the corequisite FILE.DAT file...... execute_user_program transactional = n

during_install

exit codes success = 0,0 failure = 1,65535 end

path = “\qsys.lib\mylib.lib\post.pgm”

corequisite_files

file name = “\usr\sd41\target\file.dat destination = “\usr\sd41\target\file.dat translate = y end end ......

At build time, this command adds the corequisite file FILE.DAT (collected at build time on a Windows or UNIX source host) to the package.

At installation time, this package runs the program located at /QSYS.LIB/MYLIB.LIB/POST.PGM, and uses the corequisite file included in the package.

176 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4.

In the example, the translate attribute for the corequisite file is set to

y. This enables translation from ASCII to EBCDIC and vice versa or OS/400 on code page translation. Translation is performed before the file is added to the OS/400 target.

The following example runs the native C program myprog. This program is included in the software package. As the example shows, the program is added to the OS/400 file system using the Add OS/400 Library and Add OS/400 Object actions. Therefore, the software package that contains these stanzas must be defined using the OS/400 SPE connected to an OS/400 preparation machine. This is not necessary for the non-native objects shown in the other examples...... add os400_lib location = “\qsys.lib” name = “mylib.lib” destination = “\qsys.lib\mylib.lib” descend = n remote = n

os400_obj name = “myprog.pgm” destination = “myprog.pgm” target_release = “*CURRENT*” remote = n replace_option = “*ALL” end end execute_user_program” name = “myprogram” transactional = n

during_install

exit_codes success = 0,0 failure = 1,65535 end

path = ”\qsys.lib\mylib.lib\myprog.pgm” end end ......

Tivoli Software Distribution User’s Guide 177 Using Tivoli Software Distribution on OS/400

At build time, this command adds the program MYPROG.PGM collected on the OS/400 preparation site) to the package.

At installation time, this package adds the program MYPROG.PGM to /QSYS.LIB/MYLIB.LIB and executes it.

The Data Moving Service in an OS/400 Environment The Software Distribution Data Moving Service is available to send, retrieve, and delete files in an OS/400 environment. A full description of the Data Moving Service is given in “Data Moving Service” on page 481.

The purpose of this section is to provide some examples of data moving commands used in the OS/400 environment. These demonstrate the different conventions for specifying file locations that are used in the OS/400 environment. See “The OS/400 Native and Integrated File Systems” on page 158.

Note: Notice the use of the codepage translation option (–c)inthe examples that follow. Using this argument results in the file that is sent being translated to EBCDIC codepage before it is written to the OS/400 destination location or to ASCII if it retrieved from an OS/400 location.

The following example moves the file “data.dat” from a Windows or Unix source host to the OS/400 IFS and runs a post-processing program on the target system. The command specified here is identical to the command that would be used to take the same actions in a Unix file system. wspmvdata -c -s @lab15124 -P sp:/usr/sd41/source -t @lab16007-os400 -P tp:/usr/sd41/target -r tpost:/usr/sd41/scripts/post.sh data.dat

At installation time, this command copies the file, data.dat from the source host to the location on the target system identified by the IFS path /usr/sd41/target.

After file has been installed, the post-processing program located at /usr/sd41/scripts/post.sh runs on the target machine.

178 Version 4.1 Using Tivoli Software Distribution on OS/400 .Sfwr Distribution Software 4.

In the following example, the file data.dat is sent from a Windows or

Unix source host to an OS/400 physical file. A post-processing OS/400 on program runs on the target system. wspmvdata -c -s @lab16016 -P sp:c:/usr/sd41/source -t @lab16006-os4 -P tp:/qsys.lib/mylib.lib/data.file -r tpost:/qsys.lib/mylib.lib/post.pgm data.dat

At installation time, this command collects the file data.dat from the source host and adds it to the library MYLIB.LIB as member of the physical file DATA.FILE.

After file has been installed, the post-processing program located at /QSYS.LIB/MYLIB.LIB/POST.PGM runs on the target machine.

In the following example, the file data.dat is sent from a Windows or Unix source host to an OS/400 library. wspmvdata -c -s @lab16016 -P sp:c:/usr/sd41/source -t @lab16006-os4 -P tp:/qsys.lib/mylib.lib -r data.dat

At installation time, this command collects the file data.dat from the source host and adds it to the library MYLIB.LIB as a physical file (DATA.FILE). The file will contain one member with the same name (DATA.MBR). The file is created by default as an OS/400 source physical file (PF-SRC).

In the following example, mymember.mbr, which is a member of the physical file todelete.FILE, is deleted. wspmvdata -d -t @lab16006-os4 -P tp:/qsys.lib/mylib.lib/ todelete.FILE mymember.mbr

Note: You cannot use the Data Moving Service to delete OS/400 physical files. Only file members can be deleted.

Tivoli Software Distribution User’s Guide 179 Using Tivoli Software Distribution on OS/400

180 Version 4.1 5 Embedding MSI Installation

Packages in a Software Package MSI Embedding 5. Packages This section explains how to use Tivoli Software Distribution to create a software package that embeds a Microsoft Software Installer (MSI) package. In the Windows environment, an MSI package is managed using the Microsoft Windows Installer. The Microsoft Windows Installer is an installation and configuration service contained in the Microsoft Windows 2000 operating system. It is also provided in a service pack to the Windows 98 and Windows NT 4.0 operating systems.

If you are using a Windows 98, or Windows NT 4.0, ensure that you have the appropriate executable installed as follows: ¶ For Windows 98, the executable is instmsia.exe. ¶ For Windows NT 4.0, the executable is instmsiw.exe. The executables can be located on the Microsoft product CD or refer to the relative Microsoft documentation.

An MSI package contains all the information that the Microsoft Windows Installer requires to install or uninstall software products. Usually, each MSI package is composed of the following: ¶ A .msi file containing the installation database ¶ Internal, external, or cabinet files required for the installation of the MSI package

Tivoli Software Distribution User’s Guide 181 Embedding MSI Installation Packages

For detailed information about the Microsoft Windows Installer and related options, refer to the Microsoft Platform SDK documentation.

Benefits of Embedding MSI Packages Using Tivoli Software Distribution, you can create and then deploy a software package that contains an MSI package. Distributing the MSI package using Software Distribution has several benefits. For example, you can do the following: ¶ Deploy the software package to a large number of target systems without user interaction, thereby avoiding the complexity of a preliminary deployment to network file servers. ¶ Optimize the use of the network using the MDist 2 feature. MDist2 performs the automatic depoting of the software package data to the MDist2 repeaters. ¶ Store information at a central repository regarding the status of the deployed package for each system on the network. ¶ Execute a native MSI installation on a target system. ¶ Use the Verify operation to identify any problems with the installation. The Verify operation for MSI packages reports the following conditions: v That the product is not in a valid Install state. v That features have not been installed with the state specified in the software package. v That components are missing.

Note: The Verify operation for MSI packages does not identify situations where a later version of a component has been overwritten by the installation. ¶ Use the Repair installation option to repair corrupted elements of a product that is already installed. When you define the MSI software package object using the Install MSI Product dialog, you can select a Reinstall Mode that determines the type of repair to be made.

182 Version 4.1 Embedding MSI Installation Packages Creating a Software Package That Embeds an MSI Installation Package A software package object for an MSI installation defines the following: ¶ The MSI file that is to be used for the installation of the product on the target. If this file is present on the system where you are creating the software package, you can read information required for creating the software package object directly from the MSI file.

¶ The location of product images to be used in the installation. MSI Embedding 5.

If the product images are not located on a drive that can be Packages accessed by the target systems, they must be included in the software package distribution and then stored in a local directory on the target systems. This is called a Bundled Installation.

Note: Bundled installations require a large amount of disk space to be free on the target. This is because they create an image of the product to be installed in a specified directory on the target system. These images can be retained or deleted after the MSI installation is complete.

If the location of the product images is accessible from the target systems, the software package needs only to contain the path where they can be accessed. This is called a Redirected Installation. ¶ Logging options. ¶ Reinstall options, to be used if the package is applied in repair mode. ¶ Instructions for installation or non-installation of individual product features. ¶ Windows installer properties.

The Software package editor supports the following methods of creating software package objects that embed an MSI installation package:

Tivoli Software Distribution User’s Guide 183 Embedding MSI Installation Packages

¶ Using a wizard, which takes input from a specified MSI file. With this method, many of the parameters are taken directly from the MSI file. This method cannot be used to install patches. ¶ Using a series of dialogs to specify values for the parameters needed for the installation. This method can be used if the MSI file is not present on the machine where the Software Package Definition file is being edited. These dialogs can also be used to edit objects created using the wizard, so that default values set in the MSI file can be changed.

You can attach conditions to MSI software package objects, in the same way as you can for other types of object.

Note: If you are using the Software Package Editor on a Windows 98 platform, a DOS window appears minimized in the task bar when you open or save a software package in SPD or SPB format. Do not close this window as this will close the entire application. Using the Wizard to Embed an MSI Package You can use this method if you have access to the MSI file for the product you want to include in the software package.

Note: The wizard cannot be used to create objects for installing patches. Use the Install MSI Patch dialog.

The wizard prompts for the MSI file and reads it to set most of the parameters required to define the install_msi_package stanza in the software package distribution file.

To create a software package object using the Install MSI Product wizard, complete the following steps:

184 Version 4.1 Embedding MSI Installation Packages

1. From the menu bar on the Software Package Editor GUI, select Tools→Importer→Install MSI Product. .EbdigMSI Embedding 5. Packages

The wizard starts and displays the Welcome panel. This panel lists the panels included in the wizard.

As you move the mouse over any of the listed items, a short explanation appears.

Tivoli Software Distribution User’s Guide 185 Embedding MSI Installation Packages

2. Click Next to advance to the MSI file panel.

3. Enter the name of the MSI file for the product you want to install or click the browse button and navigate to select the file. 4. Click Next to advance to the Application Information panel.

5. Type the path for the Destination folder for the installation, if you know it. Otherwise, do one of the following: ¶ Select a value from the drop-down list of paths that use defined variables.

186 Version 4.1 Embedding MSI Installation Packages

¶ Click the browse button and navigate to select the folder.

The value you enter here is assigned to the INSTALLDIR property. It is the folder on the target system where the product is to be installed. 6. Click Next to advance to the Target and Source panel. On this panel, you identify the location of the product images to be used in the MSI installation. .EbdigMSI Embedding 5. Packages

7. If the product images are in a directory that is accessible from the target systems, specify that location in the Target Image Path text box and select the Redirected Installation check box. 8. If the product images are in a directory that is not accessible from the target systems, you must do the following: ¶ Specify the current location of the product images in the Source Image Path text box. At distribution time, the images are retrieved from this directory and distributed to the target systems as part of the software package. ¶ In the Target Image Path text box, specify the location on the target system where the product images can be stored, when they are extracted from the software package. This is

Tivoli Software Distribution User’s Guide 187 Embedding MSI Installation Packages

the directory from which the MSI installation process retrieves the product images during installation. ¶ You can select the Keep Images check box, if you want to save the images in the Target Image Path location when installation is complete. 9. Select the Available to All Users check box, if the installed product is to be available to all users of the target systems. If this check box is cleared, the product is only available to the user who is logged on at installation time. 10. Click Next to advance to the Product Features panel. This panel shows an expandable tree, which lists any product features that can be installed with the MSI product. The wizard obtains these details from the MSI file that you specified.

11. To change the action to be taken for a feature do the following: a. In the expanded tree, select the feature you want to change and right-click to display a context menu of available actions. b. Select the action you require.

The icon associated with the selected action appears beside the feature in the tree.

188 Version 4.1 Embedding MSI Installation Packages

12. Click Finish to confirm all your selections and create the software package object. Using Dialogs to Embed or Edit an MSI Package If you do not have the MSI file on the system where you are defining and building your software distribution package file, you can use a set of dialogs that guide your through inputting the details you need to define the install_msi_product or install_msi_patch stanzas.

Actions that open the Install MSI Product and Install MSI Patch

dialogs are available from the Programs tab of the Software MSI Embedding 5. Package Editor GUI. Packages Note: You can also use these dialogs to edit the parameters of existing software package objects that define MSI packages, including objects created using the Install MSI Product wizard.

To open an object for editing, double-click it.

To define an MSI package using the dialogs, complete the following steps:

Tivoli Software Distribution User’s Guide 189 Embedding MSI Installation Packages

1. On the toolbar of the Software Package Editor window, click the Program tab to display the program action icons.

2. Click the Install MSI Product icon. The Install MSI Product dialog opens.

Note: The other MSI icon is the Install MSI Patch icon. The product and patch dialogs are very similar. The patch dialogs do not include a panel for installable features or a configuration option. One set of instructions is given to cover both.

190 Version 4.1 Embedding MSI Installation Packages .EbdigMSI Embedding 5. Packages

3. Select Install Product to install a new product or new product version, or Configure Product to make changes to an already installed product, then click the General tab. If you selected Install Product, the Install MSI Product dialog appears.

4. Complete the information on the panel as follows:

Tivoli Software Distribution User’s Guide 191 Embedding MSI Installation Packages

a. In the MSI file text box, specify the MSI file where the product installation information is defined. b. If the product images are in a directory that is accessible from the target systems, specify that location in the Target Image Path text box and select the Redirected Installation check box. c. If the product images are in a directory that is not accessible from the target systems, you must do the following: ¶ Specify the current location of the product images in the Source Image Path text box. At distribution time, the images are retrieved from this directory and distributed to the target systems as part of the software package. ¶ In the Target Image Path text box, specify the location on the target system where the product images can be stored, when they are extracted from the software package. This is the directory from which the MSI installation process retrieves the product images during installation. ¶ You can select the Keep Images check box, if you want to save the images in the Target Image Path location when installation is complete. d. Select Available to All Users to make the product available to all users on the target systems. If you clear this check box, the product is only available to the users who are logged on to the target systems at installation time. 5. If you selected the Configure Product option, you are prompted to supply the details of the product you want to configure and the path where it is installed on the target

192 Version 4.1 Embedding MSI Installation Packages

systems. .EbdigMSI Embedding 5. Packages

6. Click the Reinstall Mode tab to select the types of components to be reinstalled if the software package runs with the Repair installation option specified.

Tivoli Software Distribution User’s Guide 193 Embedding MSI Installation Packages

7. Click the Log Mode tab.

8. Disable logging by selecting the Disabled check box or define the logging options as follows: a. Specify the directory where the MSI log is to be stored. You can enter the path in the Log Path text box or click the Browse button to navigate to the directory. b. Select the Log Modes by selecting or clearing check boxes.

Note: The log modes shown on the screen are standard SDK log modes. For more details, see the Microsoft Platform SDK documentation. c. If you want to report the MSI log entries in the Software Distribution log, select Report Log.

194 Version 4.1 Embedding MSI Installation Packages

9. Click the Properties tab to assign values to any Windows Installer properties that are required for the installation. .EbdigMSI Embedding 5. Packages

10. To add a property, do the following: a. Select an appropriate Windows Installer property from the drop-down list and click Add. The property appears in the lower text box. b. Click in text box and assign a value to the property. For example, TARGETDIR=C:\properties. 11. To remove a property, select the property in the text box and click Remove.

Tivoli Software Distribution User’s Guide 195 Embedding MSI Installation Packages

12. If the product has additional features that can be installed, click the Features tab.

13. For each feature you want to add, enter the feature name in the upper box and click Add. The feature is added to the expandable tree. The default action, to install the feature on the hard drive, is set. If you want to change this action, select the feature and right-click. The list of available actions appears, and you can select the one you want. 14. To delete a feature, select it and click Remove. 15. To change the default setting for the user interface level during installation, click the UI level tab. The default setting is “none”, that is, a silent installation.

Note: Changing the GUI level has no effect unless the installation is completed in disconnected mode. All other

196 Version 4.1 Embedding MSI Installation Packages

installations are silent. .EbdigMSI Embedding 5. Packages

16. When you are satisfied with the settings, click OK to create the software package object. Making an MSI Installation Conditional Like other types of software package object, embedded MSI packages can be made conditional. You can attach one or more conditions to an object, so that at distribution time, the object is only executed if the conditions are met.

You define conditions using the Condition Editor, which you can access from the Install MSI Product and Install MSI Patch dialogs. This means that if you are creating the object using the dialogs, you can define any conditions during creation.

If you create an object using the wizard, you must add conditions after creation, by opening the object for editing. You can open an object for editing by double-clicking it.

To define conditions for an MSI package object, complete the following steps: 1. With the object open in the Install MSI Product or Install MSI Patch dialog, click the Condition button in the upper right

Tivoli Software Distribution User’s Guide 197 Embedding MSI Installation Packages

corner of the dialog.

The Condition Editor window opens.

2. Define an expression by selecting a variable from the list and an operator from the panel and then entering a value. For example, select the variable os_name and the operator == and enter the value “Windows NT”, to construct the expression

198 Version 4.1 Embedding MSI Installation Packages

os_name==“Windows NT” .EbdigMSI Embedding 5. Packages

3. Click OK to return to the Install MSI Product or Install MSI Patch dialog., then click OK again to confirm the change to the object.

Tivoli Software Distribution User’s Guide 199 Embedding MSI Installation Packages

200 Version 4.1 6 How Does AutoPack Work?

This chapter introduces the concepts of AutoPack technology.

AutoPack technology is based upon automated detection of both file and system changes that take place during the installation of an application, and packaging those changes within a single software package for distribution to target systems, thus minimizing a system administrator’s effort in preparing software for network distribution.

You can use the AutoPack technology by selecting AutoPack from

the Software Package Editor menu or by using the autopack AutoPack Does How 6. command from the command line. For more information about the autopack command, refer to the Tivoli Software Distribution Reference Manual. Work?

AutoPack automatically generates a software package by comparing two successive “snapshots” of a preparation machine. A preparation machine is any Windows, OS/2, or UNIX, refer to the Tivoli Software Distribution Release Notes for details about supported platforms, on which the Tivoli Software Distribution Java Endpoint Package Editor component is installed.

It is recommended that you use a preparation machine with few or no other applications installed. Because AutoPack relies on differencing technology that detects file and system configurations, using a simple system will avoid file contention. If other applications are installed on the preparation machine before you create the software package, AutoPack might include unwanted data and

Tivoli Software Distribution User’s Guide 201 How Does AutoPack Work?

system files, or exclude vital system files from the software package. It also helps avoid problems associated with shared objects among different applications.

It is recommended that you create a software package on the same operating system as the target machine. Doing this avoids file contention that can result between different operating systems. For example, if you are installing Netscape Navigator on Windows 98 and Windows NT systems, create a software package on each platform.

Note: Because AutoPack technology automatically detects both file and system changes that take place during the installation of an application, applications that are hardware dependent can create problems. For example, some graphics applications are dependent on monitor type. During the installation of these types of applications, hardware settings are memorized that will cause incompatibility with targets that have different settings than those of the preparation machine.

Before you create a software package using AutoPack, it is important to understand how AutoPack works so that you can customize it to satisfy workstations running different operating systems.

AutoPack Components AutoPack enables you to create software packages for distribution to target machines without having to write configuration programs or perform additional installation tasks. It automatically determines the files to be distributed to the target machine and also handles changes to system components such as registry changes, desktop icons, and programs listed on the Start menu. Consider some of the changes that take place on system components when an application is installed on a Windows 98 system: ¶ A set of files is copied to a target directory. ¶ Entries are added to the Windows Registry. ¶ .ini files are created and modified.

202 Version 4.1 AutoPack Components

¶ Statements are added to the system files (config.sys, autoexec.bat). ¶ Folders and shortcuts are added to the Windows desktop.

AutoPack takes a snapshot of the state of these components before the installation of an application and another after the installation is complete, and then uses differencing technology to identify the changes that have taken place in the state of these components. The differencing phase is the process by which the first and second snapshots are examined and compared. For each difference found, the related action is generated and added to the software package. For example, assume that the c:\winnt\system32\myapp.dll file has been added to the system. The addition of this file is detected during the differencing phase and an action is generated to add this file to the software package. System components vary depending on the operating system. The following table illustrates various components monitored by AutoPack, their corresponding managed objects, and the platforms that support each component.

Component Managed Objects Supported Platforms File system Files, directories, All symbolic links (for AutoPack Does How 6. UNIX platforms) Text files Lines, tokens, and All

commands Work? Windows profiles (.ini) Sections, items Windows Windows registry Keys, values Windows NT 4.0, Windows 2000 Windows 98 Windows shell Folders, shortcuts Windows NT 4.0, Windows 2000 Windows 98 OS/2 profiles Items OS/2 4.0, 4.5 OS/2 desktop Generic objects, OS/2 4.0, 4.5 folders, programs, shadows

Tivoli Software Distribution User’s Guide 203 AutoPack Components

Component Managed Objects Supported Platforms OS/2 system files Items OS/2 4.x and later (OS2.ini and OS2SYS.ini) Windows NT services Services Windows NT 4.0, Windows 2000

AutoPack Configuration File This section describes the structure of the AutoPack configuration file autopack.ini for Windows systems, and provides a typical autopack.ini file for UNIX systems. AutoPack uses the configuration file to establish which objects of a given component should be monitored and which objects should be ignored during the differencing phase. AutoPack stores the configuration file in the working directory. The end of this chapter includes the default autopack.ini configuration files for Windows NT 4.0, Windows 2000, Windows 98, and UNIX systems.

The autopack.ini file has the same structure as a Windows .ini file. It contains a general section and an include and exclude section for each system component. See the table on page 203 for a list of system components and the objects they manage. The include sections list the objects in the related component that must be monitored during the snapshot, while the exclude sections list a subset of the objects in the include section that must be ignored during the differencing phase. For example, you can specify an entire directory structure in the include section, but can exclude specific files contained in this directory by specifying them in the exclude section. If a difference is found in an object listed in the exclude list, the action related to this object will not be included in the software package.

Note: It is important that the include sections of the autopack.ini file do not change between the First Snapshot and the Second Snapshot.

The autopack.ini file is composed of the following sections:

204 Version 4.1 AutoPack Configuration File

¶ The General Section. The General section contains the path for the working directory. The default working directory is the autopack directory located under the product directory, for example, c:\swdis\autopack. You can change this default, but the autopack.ini file must be located in the working directory. The following represents the syntax of the general section: [General] WorkingDir =

For UNIX systems, the working directory is dir_endpoint/swdis/autopack, where dir_endpoint represents the directory on the endpoint. ¶ FileSystem Sections. Use the FileSystem sections to manage the monitoring of file system objects. In the include section, specify the drives that you want to scan. For Windows and OS/2 platforms, the $(system_drive) is always monitored even if you do not add it to the include section. In the exclude section, specify the directories or files that should be ignored during the differencing phase. You can use wildcards in this section. For example, to list all files in the temp directory in the FileSystem Exclude section, use c:\temp\*.* in the list. Refer to the Tivoli Software Distribution Reference Manual for more information AutoPack Does How 6. about specifying file and directory names with wildcards. The following is the syntax for the include and exclude sections for

this component: Work? [FileSystem Include] ...

[FileSystem Exclude] ...

For UNIX systems, you monitor the root (/) or the home drive ($(home)).

Tivoli Software Distribution User’s Guide 205 AutoPack Configuration File

Notes: 1. Under the FileSystem Exclude section, exclude the directory containing the Tivoli code. 2. The root is monitored by default. Exclude monitoring the root if the files being installed do not affect the root Monitoring the root can affect performance, especially on very large systems. See the “Autopack.ini Default for UNIX Systems” on page 216 for a sample UNIX autopack configuration file. ¶ TextFiles Sections. Use these sections to manage the monitoring of text file objects. List the text files to be monitored in the include section, and text files to be ignored during the differencing phase in the exclude section. You can use wildcards in both of these sections. [TextFiles Include] ...

[TextFiles Exclude] ...

When AutoPack monitors a file as a text file object, it detects changes that have taken place inside the file, then generates an action in the software package to apply only those changes to the target machine. This differs from monitoring files as file system objects because, when AutoPack monitors file system objects, the entire file is replaced on the target system. To illustrate this, consider monitoring changes to the config.sys file. Monitoring this file as a text file object enables you to replicate only changes to the file, such as adding new lines or deleting lines from the file. Monitoring the file as a file system object results in the entire config.sys file being added to the package and distributed to the target machine.

206 Version 4.1 AutoPack Configuration File

¶ WinProfiles Sections. Use these sections to manage the monitoring of Windows profiles such as .ini files. In the include section, specify the files you want to monitor. In the exclude section, specify files that must be ignored during the differencing phase. Wildcards can be used in both sections. [WinProfiles Include] ...

[WinProfiles Exclude] ...

Monitor .ini files as WinProfile objects if you want to detect only the changes that take place inside an .ini file. Monitor them as file system objects if you want the entire file packed into the software package for distribution to the target machine. ¶ WinRegistry Sections. Use these sections to manage the

monitoring of Windows Registry paths. Specify registry paths to AutoPack Does How 6. monitor in the include sections and specify registry paths to be ignored during the differencing phase. Wildcards are not

permitted in registry paths. Work? [WinRegistry Include] ...

[WinRegistry Exclude] ... ¶ OS2Profiles Sections. Use these sections to monitor OS/2 profiles or .ini files except for the OS2.ini and OS2SYS.ini files. These files are treated as OS2SystemFiles objects. Unlike Windows profiles, OS/2 profiles are binary files. Specify profile

Tivoli Software Distribution User’s Guide 207 AutoPack Configuration File

files you want to monitor in the include section, and specify profile files that must be ignored during the differencing phase in the exclude section. Wildcards can be used in both of these sections. [OS2Profiles Include] ...

[OS2Profiles Exclude] ...

Monitor .ini files as OS2Profile objects if you want to detect only the changes that take place inside an .ini file. Monitor them as file system objects if you want the entire file packed into the software package for distribution to the target machine. ¶ OS2SystemFiles Sections. The include section of this component contains the OS2.ini and OS2SYS.ini files. Do not modify this section. However, you can modify the exclude section to specify sections of .ini files that must be ignored during the differencing phase. For example, these files contain information about objects on the desktop that are unrelated to the target machine. Exclude those sections containing information about desktop objects by adding them to the exclude section. The following is the syntax for the exclude section: [OS2SystemFiles Include] c:\os2\os2.ini c:\os2\os2sys.ini

[OS2SystemFiles Exclude] ... ¶ OS2Desktop Sections. The include section of this component contains a list of desktop folders to be monitored. Each folder

208 Version 4.1 AutoPack Configuration File

can be specified by using either the full path name or by using its object ID. Do not modify the exclude section. Wildcards are not permitted in these sections. The following syntax illustrates how desktop folders are specified: [OS2Desktop Include] ... Customizing the Configuration File AutoPack creates the configuration file the first time it runs. Each section contains defaults based on the workstation configuration. These defaults are set to satisfy the most widely detected operating systems on workstations. For example, because most installation procedures modify the same registry keys, the WinRegistry Include section is set to monitor the following registry paths: HKEY_LOCAL_MACHINE\SOFTWARE HKEY_CURRENT_USER HKEY_USERS\.Default HKEY_LOCAL_MACHINE\System\CurrentControlSet

You can add an object to its related exclude section to ignore any changes in that object and avoid including this change in the AutoPack Does How 6. software package, or you can add an object to its related include section to monitor any changes in that object and include those changes in the software package. Work?

The WinRegistry Exclude section contains registry keys that do not need to be monitored. These are keys that have no part in the installation of software and should not be included in the software package. For example, the following registry path is excluded: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib

This registry path is used for statistical information regarding the machine and changes constantly independent of the installation of an application.

The WinProfiles Exclude section contains files that do not need to be monitored. For example, the winit.ini file is listed in this section by

Tivoli Software Distribution User’s Guide 209 AutoPack Configuration File

default. This file contains information regarding files that should be deleted after restarting the system and have nothing to do with the installation of an application.

The file system drive to be monitored is configured for Windows systems by default. You may need to edit the autopack.ini file several times if the default settings are not applicable to your system components. For UNIX systems, you may need to personalize the FileSystem Include section. To minimize monitoring time, you can specify a subset of file systems rather than indicating the root to avoid monitoring every file system on the target system.

Notes for Certain User Scenarios There are certain user scenarios which require customizing the autopack.ini file to achieve a successful installation of the software package generated using AutoPack. The following points describe known scenarios which require some user intervention: 1. When the differencing phase is launched from the Software Package Editor, the process hangs if the software package being created contains a large number of objects. To avoid this problem, replace ″ -mx50m ″ with ″ -mx100m ″ in the required file: ¶ On Windows NT and Windows 2000 platforms: the speditor.bat file. ¶ On Windows 98 platforms: the swspe_95.bat file. 2. The FileSystem Exclude section must be customized if you run the following scenario: ¶ Create a software package using autopack for the Microsoft Office 2000 or Netscape 4.7 applications on a Windows 98 system. ¶ Install the software package specifying the undo option. In this particular scenario, the installation will complete successfully only if the following files are inserted in the FileSystem Exclude section:

210 Version 4.1 AutoPack Configuration File

C:\Windows\Cookies\index.dat C:\Windows\History\index.dat C:\Windows\Temporary Internet Files\index.dat 3. For distributions that update Windows system files, which could be locked in read or write, it is advisable to perform the installation in undoable-in-transactional mode. In such a case, a backup copy of the locked files is made during the commit phase. 4. When you create a software package using AutoPack that installs the Norton AntiVirus product on a Windows 2000 endpoint, the distribution fails if the following registry key is included in the software package: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ServiceCurrent

For a successful distribution, add the registry key to the WinRegistry Exclude section. 5. When you create a software package using AutoPack for either the installation of NetWare Client 5 software, or the McAfee anti-virus software, and install it on a Windows NT endpoint, the distribution fails. If you create a software package using

AutoPack for software that modifies the system network AutoPack Does How 6. configuration of a machine or that installs drivers, you must modify the autopack.ini file before running the differencing phase as follows: Work? a. Delete the following line from the RegistryExclude section: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

Note: It is not recommended that you permanently delete this line from the autopack.ini file because it could cause problems when installing other programs. b. In the General section, set the OverrideRegistryPermissions options to y (yes) as follows: OverrideRegistryPermissions=y 6. The OverrideRegistryPermissions option must be set to y (yes) if you are running any of the following user scenarios:

Tivoli Software Distribution User’s Guide 211 AutoPack Configuration File

¶ Create a software package using AutoPack for the DB2 client software and install the software package on a Windows NT or Windows 2000 endpoint. ¶ Create a software package using AutoPack for the Exceed 6.1 software and install the software package on a Windows 2000 endpoint. ¶ Create a software package using AutoPack for Microsoft Office 2000 software and install the software package on a Windows 2000 endpoint. Alternatively, add the following entry in the WinRegistry Exclude section of the autopack.ini file: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ ServiceCurrent 7. Create a software package using AutoPack for Microsoft Office 2000 software. If you perform an undoable installation of the software package on either a Windows NT or Windows 2000 endpoint, you must increase the amount of virtual memory to at least 300 MB. 8. When you create a software package using AutoPack that installs Microsoft Office 2000 software on a Windows NT endpoint, the distribution fails because of a locked file. For a successful distribution, add the following file to the FileSystem Exclude section: C:\WINNT\Schedlog.txt Dealing with Shared Objects The preparation machine should have only a minimum set of applications installed: the operating system and AutoPack. Besides preventing file contention, this helps avoid problems associated with shared objects.

Many Windows applications share objects such as files and registry entries. To avoid reinstalling objects that have already been installed by an application on a workstation, Microsoft suggest using a reference counter stored in the following registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ CurrentVersion\SharedDLLS

212 Version 4.1 AutoPack Configuration File

Not all applications use this registry path to store their reference counters. Apple QuickTime, for example, stores shared files under the following registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Apple\QuickTime32\CurrentVersion \SharedFiles

Other applications do not use reference counters.

Consider the case of a file and registry entry common to both an application already installed on the preparation machine, and an application to be installed between the first and second snapshot. As already mentioned, shared objects will not be reinstalled. Therefore, during the differencing phase, AutoPack includes the shared file and registry entry as part of the software package. The file and registry entry were present before the installation and no changes occurred to these files after the installation. No commands are generated to add this file and registry entry.

AutoPack can minimize the problems associated with shared objects by monitoring reference counters. Autopack.ini Default for Windows NT 4.0 and Windows 2000 AutoPack Does How 6. [General] ComputeCRC=n

VerifyCRC=n Work? CompressionMethod=stored OverrideRegistryPermissions=n ReplaceIfNewer=n RemoveIfModified=n ReplaceIfExisting=y WorkingDir=C:\Program Files\Tivoli\swdis\autopack [FileSystem Include] C:\ [TextFiles Include] c:\autoexec.bat c:\config.sys [WinProfiles Include] C:\WINNT\*.ini [WinRegistry Include] HKEY_LOCAL_MACHINE\SOFTWARE HKEY_CURRENT_USER HKEY_USERS\.Default HKEY_LOCAL_MACHINE\System\CurrentControlSet

Tivoli Software Distribution User’s Guide 213 AutoPack Configuration File

[FileSystem Exclude] C:\TEMP\*.* C:\Program Files\Tivoli\swdis\*.* C:\WINNT\swdis.* C:\WINNT\*.grp c:\boot.ini *\win386.swp *\pagefile.sys C:\WINNT\*.ini c:\autoexec.bat c:\config.sys ??\recycler\*.* ??\recycled\*.* C:\WINNT\System32\config\*.* *.lnk C:\*\ntuser.dat.log C:\*\ntuser.dat [TextFiles Exclude] [WinProfiles Exclude] C:\WINNT\progman.ini C:\WINNT\wininit.ini C:\WINNT\swdis.ini [WinRegistry Exclude] HKEY_LOCAL_MACHINE\SAM HKEY_LOCAL_MACHINE\System\Clone HKEY_LOCAL_MACHINE\SOFTWARE\Program Groups HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion \SharedDLLs HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion \Explorer HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion \Reliability HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control \Session Manager [WinShell Exclude] ??\recycler\*.* ??\recycled\*.* C:\WINNT\System32\config\* C:\TEMP\*.* Autopack.ini Default for Windows 98 [General] WorkingDir=C:\Program Files\Tivoli\swdis\1\autopack [FileSystem Include] C:\ [TextFiles Include] c:\autoexec.bat

214 Version 4.1 AutoPack Configuration File

c:\config.sys [TextFiles Exclude] [WinProfiles Include] C:\WINDOWS\*.ini [WinProfiles Exclude] C:\WINDOWS\progman.ini C:\WINDOWS\wininit.ini C:\WINDOWS\swdis.ini [FileSystem Exclude] C:\WINDOWS\TEMP\*.* C:\Program Files\Tivoli\swdis\1\*.* C:\WINDOWS\swdis.* C:\WINDOWS\*.grp c:\boot.ini *\win386.swp *\pagefile.sys C:\WINDOWS\*.ini c:\autoexec.bat c:\config.sys ??\recycler\*.* ??\recycled\*.* C:\WINDOWS\SYSTEM\config\*.* *.lnk C:\WINDOWS\APPLOG\*.* C:\WINDOWS\SchedLgU.Txt C:\WINDOWS\DEBUG\*.* C:\WINDOWS\system.dat

C:\WINDOWS\user.dat AutoPack Does How 6. C:\WINDOWS\*.pwl [WinRegistry Include] HKEY_LOCAL_MACHINE\SOFTWARE HKEY_CURRENT_USER HKEY_USERS\.Default Work? HKEY_LOCAL_MACHINE\System\CurrentControlSet [WinRegistry Exclude] HKEY_LOCAL_MACHINE\SAM HKEY_LOCAL_MACHINE\System\Clone HKEY_LOCAL_MACHINE\SOFTWARE\Program Groups HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ CurrentVersion\SharedDLLs HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\Perflib HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Explorer HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ CurrentVersion\Reliability HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Session Manager\PendingFileRenameOperations

Tivoli Software Distribution User’s Guide 215 AutoPack Configuration File

Autopack.ini Default for UNIX Systems [General] WorkingDir=/usr/sd40/swdis/autopack [FileSystem Include] / [TextFiles Include]

216 Version 4.1 akg sn AutoPack Using Package .Gnrtn Software a Generating 7. 7 Generating a Software Package Using AutoPack

AutoPack automatically generates a software package by reproducing the results of an installation on a preparation machine. In this chapter, the AutoPack guided process is used to create a software package that replicates the installation of the Tivoli desktop by performing the following tasks: ¶ Scanning drives on the preparation machine where software will be installed to create a first snapshot, or preinstallation snapshot, of the drive and system configurations. (It is important that the preparation machine have few or no other applications installed. The machine must also be of the same operating system type as the target PC.) ¶ Bundling the file and system changes that result from installing software on the preparation machine for distribution to target machines. ¶ Taking a second snapshot, or post-installation snapshot, of the preparation machine drive and identifying the installed files and system changes. ¶ Creating a software package based on the difference between the first and second snapshots.

AutoPack technology is integrated into the Software Package Editor. From the Software Package Editor window, you can choose to launch either the Guided Process, which guides you through the

Tivoli Software Distribution User’s Guide 217 Generating a Software Package Using AutoPack

AutoPack process step-by-step from start to finish, or you can launch each step separately if you need to customize the preparation machine between steps.

To launch the Guided Process, select AutoPack→Guided Process from the menu bar.

To launch each sequential step, select AutoPack from the menu bar and choose one of the following items: ¶ First Snapshot ¶ Second Snapshot ¶ Differencing Refer to this chapter and the online help for more detailed information about these dialogs. Notes: 1. This procedure can be executed locally on a disconnected machine using the command line interface. Refer to the autopack command in the Tivoli Software Distribution Reference Manual. 2. You cannot use AutoPack to create software packages that perform operating system upgrades and installation.

Running AutoPack Use a Windows NT 4.0 PC as the preparation machine to create the Tivoli desktop software package for Windows NT 4.0 targets. Run AutoPack on the same operating system as the target system. Only Windows NT 4.0 procedures are described in this chapter. 1. Verify that the preparation machine has few or no applications installed. To list the applications installed on a Windows NT 4.0 PC, double-click the Add/Remove Programs icon from the Windows NT Control Panel. A dialog similar to the following is

218 Version 4.1 akg sn AutoPack Using Package Running AutoPack Software a Generating 7.

displayed:

You might also want to refer to the Windows NT Start→Programs menu, because not all application installations add an entry to the Windows NT Add/Remove Programs group.

In this example, only Tivoli applications are installed on this machine.

Tivoli Software Distribution User’s Guide 219 Running AutoPack

2. To launch the AutoPack guided process, select AutoPack→Guided Process from the menu bar in the Software Package Editor window.

The AutoPack Guided process provides an easy-to-use graphical user interface (GUI) that guides you step-by-step through the creation of a software package. An introductory dialog is

220 Version 4.1 akg sn AutoPack Using Package Running AutoPack Software a Generating 7.

displayed.

3. Click Next to proceed with the first snapshot.

Creating the First Snapshot The first snapshot is a preliminary snapshot of the preparation machine drive and system configuration before the installation of the Tivoli desktop application. AutoPack scans the specified drive and store the current configuration information and directory structure in the working directory.

Tivoli Software Distribution User’s Guide 221 Creating the First Snapshot

1. Begin the process of creating the first snapshot by completing the General Options dialog.

This dialog corresponds to the General section of the autopack.ini file, as this is where the working directory is specified. See “AutoPack Configuration File” on page 204 for more information about the autopack.ini file.

In the Working directory text box, specify the directory name where you want to temporarily store the results of the snapshots. This directory contains the output files of the first and second snapshots. The default is \autopack. The default value is located in the \swdis.ini file if you are working in a Windows or OS/2 environment, or in the etc\Tivoli\swdis.ini file if you are working in a UNIX environment. You can change the default by modifying the autopack.ini file. 2. In the Drives to monitor scrolling list, specify the drives that you want to monitor during the first and second snapshots. You can specify more than one drive. The default is your system drive. 3. Leave the Customize system monitoring check box selected to specify objects to monitor or exclude during the differencing

222 Version 4.1 akg sn AutoPack Using Package Creating the First Snapshot Software a Generating 7.

phase, such as text files, registry entries, or .ini files. If AutoPack detects any differences in the objects that you specify to monitor, the related action is included in the software package. AutoPack ignores any differences found in the objects you specify to exclude during the differencing phase. Click Next to display the Text Files to Include dialog. If you do not select this check box, AutoPack proceeds to the Software Installation Options dialog found in step 10 on page 228.

In the Text Files to Include dialog, indicate the files that you want to monitor during the differencing phase. This dialog corresponds to the Text Files section of the autopack.ini file explained on page 206. The Text Files section on page 206 also explains the difference between monitoring files as text file objects as opposed to file system objects. The Text Files to Include dialog lists some files that AutoPack monitors by default. These files are usually operating system files. It is recommended that you do not remove the files listed here. You can, however, add text files to be monitored by clicking Add files or delete other files from the list by selecting Remove.

Tivoli Software Distribution User’s Guide 223 Creating the First Snapshot

Note: The default files to include and exclude are different for each supported platform. Windows, OS/2, and UNIX list different default files to include and exclude. 4. Click Next to display the Text Files to Exclude dialog.

In this dialog, indicate the files that must be ignored during the differencing phase. You can, for example, exclude a subset of the objects specified in the corresponding include dialog. If any differences are found in these objects during the differencing phase, their related actions are excluded from the software package.

224 Version 4.1 akg sn AutoPack Using Package Creating the First Snapshot Software a Generating 7.

5. Click Next to display the Registry Entries to Include dialog.

In this dialog, you can specify registry paths that you want to monitor during the differencing phase. Click Add to add new entries to the list or click Remove to remove selected entries from the list. This dialog corresponds to the WinRegistry section of the autopack.ini file explained on page 207. 6. Click Next to display the Registry Entries to Exclude dialog.

Tivoli Software Distribution User’s Guide 225 Creating the First Snapshot

Specify registry paths to ignore during the differencing phase. In this dialog, add entries that contain information that is not used for the installation of the application. For example, the following entry is already in the exclude dialog by default because it contains performance information of the target system that is not applicable to the installation of the application: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows NT\CurrentVersion\Perflib 7. Click Add to add new entries to the exclude list, or click Remove to remove selected entries from the list. 8. Click Next to display the Win Profiles to Include dialog.

The listed .ini file is a default setting monitored by AutoPack. This dialog corresponds to the WinProfiles section of the autopack.ini file explained on page 206. Add files that you want to monitor during the differencing phase by clicking Add files. Remove a selected file from the list by clicking Remove. Click

226 Version 4.1 akg sn AutoPack Using Package Creating the First Snapshot Software a Generating 7.

Next to display the Win Profiles to Exclude dialog.

Specify .ini files to ignore during the differencing phase. Click Add files to add new files to the default list, or click Remove to remove selected files from the list. 9. Click Next to display the System Files to Exclude dialog.

This dialog contains a list of files and directories that are excluded by default. Add any files or directories that you want to ignore during the differencing phase. If differences are found

Tivoli Software Distribution User’s Guide 227 Creating the First Snapshot

in these files or directories during the differencing phase, they are excluded from the software package. This dialog corresponds to the FileSystem section of the autopack.ini file explained on page 205.

Note: You must include the following directories in the System Files to Exclude list: ¶ The directory where you installed the endpoint. The default is C:\Program Files\LCF. ¶ The directory where you installed the server. The default is C:\Tivoli. 10. Click Next. The Software Installation Options dialog is displayed.

In this dialog, you can choose from two installation options: ¶ Manual installation ¶ Automatic installation The following sections describe these installation options.

228 Version 4.1 akg sn AutoPack Using Package The Manual Installation Option Software a Generating 7. The Manual Installation Option You can install the Tivoli desktop software manually by selecting Manual Installation from the Software Installation Options dialog. The manual installation option interrupts the AutoPack Guided Process to allow you to install the software. You choose when to resume with the second snapshot by relaunching the AutoPack Guided Process. 1. Select Next on the Software Installation Options dialog to display the Software Package Properties dialog.

2. Replace the default software package name MyPackage with TivoliDesktop. 3. Leave the default value 1.0 in the Version text box. 4. Select the appropriate check boxes: Verify CRC When this option is selected, when checking the identity of the source and target files, Tivoli Software Distribution compares their cyclic redundancy check (CRC) values. Use this option together with Replace if existing to verify if an existing file must be replaced.

Tivoli Software Distribution User’s Guide 229 The Manual Installation Option

Compute CRC When this option is selected, after the installation of a file, Tivoli Software Distribution compares the CRC of the file installed on the target machine with the corresponding file in the package to check whether the file was corrupted during distribution or installation. Replace if existing This option specifies to replace an object that already exists on the target. It is selected by default. Remove if modified This option specifies to remove the object even if the target object has been modified. Override Registry Permissions If this option is selected, access permissions for adding or removing protected registry keys and values are temporarily overridden, then restored after the operation is completed. 5. Click Next to display a dialog listing the steps to be performed.

Because you selected manual installation, the steps to be performed are the first snapshot and the manual installation. The

230 Version 4.1 akg sn AutoPack Using Package The Manual Installation Option Software a Generating 7.

remaining steps are executed after you have fully installed the Tivoli desktop software and relaunched the AutoPack guided process. 6. Select Finish to launch the execution of the first snapshot.

7. When the first operation is completed, AutoPack exits from the AutoPack Guided Process and prompts you to begin the manual installation.

8. Install the Tivoli desktop software as you would normally. Regardless of how you run the executable, be sure to close all applications. 9. When the installation is complete, you can resume the second snapshot. Resuming the Second Snapshot After you have installed the software, resume the second snapshot and the creation of the software package. 1. Select AutoPack→Guided Process from the menu bar of the Software Package Editor window.

Tivoli Software Distribution User’s Guide 231 Resuming the Second Snapshot

An introductory dialog is displayed.

2. Click Next and AutoPack displays a message that asks if you would like to resume with a previously initiated AutoPack process, or if you want to ignore the previous installation and start a new AutoPack process.

3. Click Next. AutoPack displays the software package properties specified before the first snapshot was performed. You can edit

232 Version 4.1 akg sn AutoPack Using Package Resuming the Second Snapshot Software a Generating 7.

this information if necessary.

4. Click Next. AutoPack displays the remaining operations to be performed.

Tivoli Software Distribution User’s Guide 233 Resuming the Second Snapshot

5. Click Finish to begin creating the second snapshot.

6. At the completion of the final operation, the Tivoli desktop software package and its contents are displayed in the Software Package Editor window.

You can use the Software Package Editor tools to customize the package properties. See “Editing Software Package Properties” on page 143 for details on modifying software package properties. See “Saving the Software Package” on page 151 for details on saving the package in different formats.

234 Version 4.1 akg sn AutoPack Using Package Resuming the Second Snapshot Software a Generating 7.

Before building the software package, check the AutoPack result in the Software Package Editor and remove any unwanted objects. After you have built the software package, you can test it using the disconnected command line interface (CLI) commands. Refer to the Tivoli Software Distribution Reference Manual for more information about disconnected CLI commands.

The Automatic Installation Option Using the AutoPack Guided Process, you can select either Automatic Installation or Manual Installation to install the application. When you choose the automatic installation option, the installation executable specified is launched during the guided process, and AutoPack automatically resumes with the second snapshot after the installation is complete. Using the automatic installation option, you can install only a single application; that is, you can specify only one executable.

Note: Using the AutoPack Guided Process, the automatic installation option does not function properly with certain applications, such as Tivoli applications and WinZip software. AutoPack is unable to detect when the installation is complete. The first snapshot is created correctly and the setup executable of the application is launched automatically. However, AutoPack erroneously starts the second snapshot before the installation is complete, which creates an incorrect differencing result. In this case, use the manual installation option to install the software. 1. In the Command text box of the Software Installation Options dialog, enter the drive and path to the application’s installation

Tivoli Software Distribution User’s Guide 235 The Automatic Installation Option

setup program.

2. Click Next to display the Software Package Properties dialog. The rest of the procedure is similar to the manual installation option.

Complete the Software Package Properties dialog. See page 229 for more information about this dialog. 3. Click Next. A list of operations to be executed is displayed.

236 Version 4.1 akg sn AutoPack Using Package The Automatic Installation Option Software a Generating 7.

Note: Some installations recommend that you close active applications before proceeding with the installation. Select the Close the Software Package Editor check box to close the Software Package Editor before beginning the automatic installation. Doing this maximizes use of resources. Upon completion of the installation procedure, you can resume with the second snapshot by launching the Software Package Editor and selecting AutoPack→Guided Process. AutoPack reminds you that a previous AutoPack procedure has not been completed and asks if you would like to resume the procedure. 4. Click Finish and AutoPack begins to execute each operation, adding a check mark to the left of each operation upon its

Tivoli Software Distribution User’s Guide 237 The Automatic Installation Option

completion.

When the automatic installation is run, the application’s setup program is executed and the software is installed.

Upon completion of the automatic installation process, AutoPack automatically resumes with the second snapshot. During the automatic installation, you may be prompted to install the application. AutoPack will resume with the second snapshot at the end of the installation.

At the completion of the final operation, the Software Package Editor window displays the software package generated by AutoPack. You can use the Software Package Editor to customize it. See “Editing Software Package Properties” on page 143 for information about modifying the properties of the software package. See “Saving the Software Package” on page 151 for information about saving the software package in different software package formats.

238 Version 4.1 8

Using the PDF Importer Tool Importer PDF the Using 8.

A Microsoft Systems Management Server (SMS) package definition file (PDF) is a text file that contains configuration information that is structured much like a standard initialization file (.INI file) and is Tool used to configure or install an application. It contains predefined workstation, sharing, and inventory property settings. Using the PDF Importer Tool from the Software Package Editor window, Tivoli Software Distribution takes a PDF as input and maps the data contained in the file to specific software package properties. The result is a software package displayed in the Software Package Editor window consisting of a generic container containing an add directory action and a sequence of execute programs. For example, the distribution of this software package can be used to configure and install an application. See “Using the PDF Importer Tool” on page 243 to follow how the PDF Importer is used to configure the installation options of the Norton AntiVirus product.

The Package Definition File The image directory of the PDF is the directory structure that contains all the files required to support the installation or removal options in the PDF. The importer tool uses the directory structure in creating the software package. The following are required sections in aPDF: ¶ [PDF] ¶ [Package Definition] ¶ [SetupVariation Setup]

Tivoli Software Distribution User’s Guide 239 Using the PDF Importer

¶ [Setup Package for Inventory] ¶ [FileIndex] PDF Section The PDF section identifies the file as a package definition file. Tivoli Software Distribution checks this section to verify that it supports the version of the PDF format used by the file. Package Definition Section The Package Definition section defines the overall software package properties. This section contains information such as the version of the product, comment settings, a list of setup variations supported by the package, and the access permissions of the packages created with the PDF. SetupVariation Setup Section This section defines the setup variations specified in the Package Definition section. Setup variations specify package commands and supported platforms. Setup Package for Inventory Section The Setup Package for Inventory section defines the inventory properties of the package. The inventory properties are used to identify a package by searching for a set of files that you specify in the package’s inventory properties. For each file, you specify the attributes used to detect the file (such as file date, file size, cyclic redundancy check (CRC) value, and so on). FileIndex Section The PDF must have a key that defines each file specified in the Setup Package for Inventory section. Each file corresponds to a key that defines the attributes of the file.

240 Version 4.1 Using the PDF Importer Mapping the PDF to a Software Package The following illustrates how the PDF Importer Tool takes a package definition file as input and maps specific information to software package objects to create a software package. The PDF importing process involves identifying the PDF file and customizing the following information: ¶ The PDF name ¶ The image and target package directories: .UigtePFImporter PDF the Using 8. v You can compress the entire directory structure in the software package before it is distributed to the target systems. –OR–

v You can mount the package directory as a shared directory Tool during the installation process. The installation program takes input files from a remote source. ¶ Properties of the software package that correspond to the Package Definition section of the PDF, such as the product, version, comment, and copyright. ¶ Setup variations supported by the package, for example, compact, typical, and complete. ¶ A package command for each setup variation selected.

The following tables represent PDF sections containing keys that are directly mapped to software package objects by the PDF Importer Tool. Those keys not included in the tables are not mapped by the tool.

PDF Section PDF Key Software Package Comments attribute or action [PDF] Version Tivoli Software Distribution verifies that it supports the PDF version.

Tivoli Software Distribution User’s Guide 241 Using the PDF Importer

PDF Section PDF Key Software Package Comments attribute or action [Package Definition] Product, Version Together, these keys become the name of the generic container Comment Software package description Setup Variations Software package The default variables $(setup_variations) variable is created at the end of the import process. Its value is the default setup variation selected. CommandLine Execute program Break down the during install and command line into execute program program path and arguments arguments. UserInputRequired Execute program The value for this during install, item specifies advanced properties whether this package option command requires user interaction to complete the command. SynchronousSystem Execute program Indicates that the ExitRequired during install, program will cause a bootable option system reboot. SupportedPlatforms Software package The supported conditions platform list is mapped as a condition in the software package.

See “Adding an Execute Program Action” on page 116 for more information about the execute program action.

242 Version 4.1 Using the PDF Importer Using the PDF Importer Tool The following scenario illustrates how to import definitions from a PDF file, NAVWNT.PDF, to produce a software package. The PDF file used in this example is part of the Norton AntiVirus product from SYMANTEC™1. You can view the package definition file, “NAVWNT.PDF” on page 247, and see how its sections relate to the dialogs of the PDF Importer Tool. 1. To launch the PDF Importer Tool, select Tools→Importer→PDF

from the menu of the Software Package Editor window. Importer PDF the Using 8. Tool

2. In the PDF Name text box, enter the path to the NAVWNT.PDF file. 3. Perform one of the following actions: ¶ Select the Redirected installation check box to indicate that the files required for the installation of the AntiVirus application are located in a remote network path. If the file images are located on a remote disk, you can mount the remote disk or create an execute program action that mounts the remote disk using the following command:

1. Use of the Norton AntiVirus product requires a license from Symantec Corporation. For more information about the Norton AntiVirus product, refer to the SYMANTEC Web site: http://www.symantec.com. Norton AntiVirus and SYMANTEC are trademarks of Symantec Corporation.

Tivoli Software Distribution User’s Guide 243 Using the PDF Importer

net use remote_disk \\path_name

-OR- ¶ Do not select this option if the files required for the installation of the AntiVirus application are located in a local path. For this scenario, do not select this check box. 4. In the Image path text box, enter the directory structure that contains all the files required to support the installation of the Norton AntiVirus application. The directory tree specified is bundled in the software package as an add file system object. 5. In the Target image path text box, enter the directory from where the installation executable is launched on the target system. If you selected the Redirected installation option in step 3, you would need to specify the remote disk that you mounted or that you entered in the execute program action. 6. Click Next to display the Package Definition dialog.

The importer tool extracts the information contained in this dialog from the Package Definition section of the NAVWNT.PDF file.

244 Version 4.1 Using the PDF Importer

7. Click Next to display the setup options defined in the NAVWNT.PDF file. .UigtePFImporter PDF the Using 8. Tool

A setup dialog is displayed for each setup variation contained in the PDF. Therefore, in the case of the NAVWNT.PDF file, a setup dialog is displayed for the Complete, Deinstall, and Manual setup options. See the text format of the NAVWNT.PDF file on page 247 to view the setup variation sections.

Use these panels to customize package commands and arguments. Make any necessary changes so that the information in these panels reflects the target system environment. Click Next to display the successive setup panels.

Tivoli Software Distribution User’s Guide 245 Using the PDF Importer

8. After the last setup panel, the Default setup variation panel is displayed.

This panel displays the list of setup variations supported by the NAVWNT.PDF file. Select one of the options as the default setup to be used when this software package is installed. The selected default setup variation becomes the value of the $(setup_variations) variable that is created at the end of the import process. 9. Click Finish to complete the importation process. A software package is displayed in the Software Package Editor window. The software package consists of a generic container that contains an add directory action and a series of execute programs. The add directory action contains the directory structure, as specified in the image path that contains all the files

246 Version 4.1 Using the PDF Importer

required to support the installation. .UigtePFImporter PDF the Using 8. Tool

For each setup variation contained in the PDF, a corresponding execute program is generated. However, when you distribute this software package, only the execute program for the default setup variation is executed. A condition which satisfies the value of the default setup variation is set on this execute program action.You can change the default setup variation even after the import process is complete by changing the value of the $(setup_variations) variable in the Variable list editor or using the command line.

Sample Package Definition File The following is the text of the NAVWNT.PDF file. The PDF Importer Tool extracts information from this file to create a software package. NAVWNT.PDF [PDF] Version=1.0

[Complete Setup]

Tivoli Software Distribution User’s Guide 247 Using the PDF Importer

CommandLine=setup.exe -s -sms -mnavwnt.mif CommandName=Complete UserInputRequired=FALSE SupportedPlatforms=Windows NT 4.0 (x86, axp)

[Deinstall Setup] CommandLine=\%systemroot%\\IsUninst.exe -f”c:\Program Files\Navnt\navnt.isu” -c”c:\Program Files\Navnt\NAVINSTNT.DLL”-a CommandName=Deinstall UserInputRequired=TRUE SupportedPlatforms=Windows NT 4.0 (x86)

[Manual Setup] CommandLine=setup.exe CommandName=Manual UserInputRequired=TRUE SupportedPlatforms=Windows NT 4.0 (x86, axp) SynchronousSystemExitRequired=TRUE

[Package Definition] Product=NAVNT Version=5.0 Comment=Norton AntiVirus 5.0 for Windows NT SetupVariations=Complete, Deinstall, Manual ErrorCodes=Yes Company=Symantec Corporation ImportDirectory=. SetupDirectory=. Environments=Windows NT 4.0 (x86) Capabilities=Local Setup, Iimport ;TelephoneSupportNumber= RebootAfterInstall=No RebootAfterDeInstall=No

[SMS Import Commands] cmd 1=

[Setup Package for Inventory] InventoryThisPackage=TRUE Detection Rule Part 1=file 1

[file 1] FILE=NAVWNT.EXE COLLECT=FALSE Checksum= CRC= DATE= SIZE= TIME=

248 Version 4.1 Using the PDF Importer

BYTE= WORD= LONG= TOKEN 1= TOKEN 2= TOKEN 3= TOKEN 4= .UigtePFImporter PDF the Using 8. Tool

Tivoli Software Distribution User’s Guide 249 Using the PDF Importer

250 Version 4.1 9 Understanding the Distribution Environment

When you install Tivoli Software Distribution, you can immediately start creating software packages and distributing software. However, some planning at this point will lead to a more efficient and manageable distribution environment. In particular, you should consider the following questions: ¶ What types of software do you want to distribute and how much

disk space does each require? Environment Distribution ¶ Will certain types of network connections slow down a the Understanding 9. distribution (such as slow WAN connections)? ¶ How can you configure the network and Tivoli repeaters to efficiently distribute multiple software packages? ¶ Can you use the established relationships between machines to help distribute software (such as endpoints connected to a server through a Tivoli gateway)? ¶ Are other Tivoli applications available to ease distribution efforts?

This chapter addresses these questions by presenting an example scenario involving NoonTide Enterprises. NoonTide Enterprises is a fictitious company with some of the network complexities that face today’s businesses. This scenario describes the step-by-step procedure for configuring a distribution environment. It includes the following steps:

Tivoli Software Distribution User’s Guide 251 ¶ Assessing the network topology and available departmental resources. ¶ Determining the hierarchy of repeaters that best suits the actual network topology exploiting the multiplexed distribution service for improved performance. ¶ Creating the necessary repeaters, their range of managed node clients, and parameters. For a repeater gateway, its endpoints are automatically multiplexed by the gateway when they are assigned to the gateway. You can also configure a managed node with the MDist 2 service to create a standalone repeater site. ¶ Tuning and configuring repeaters as depots to store MDist 2 distribution data in order to reduce network traffic for frequently distributed data sets.

You can also configure the distribution manager by creating a RIM database and a RIM object in order to monitor and control distributions. The distribution manager stores status information about a distribution in the database tables. There is one distribution manager for each Tivoli management region that keeps track of all the distributions started in it. If the distribution spans multiple Tivoli management regions, all status information is stored in the distribution manager in the initiating Tivoli management region and no status information is stored in the interconnected Tivoli management regions.

Additional tuning is required for the roaming endpoints feature. Refer to the Tivoli Management Framework Planning for Deployment Guide for more information about the roaming endpoint feature.

For the purpose of this scenario, we assume that you are the senior system administrator at NoonTide. The senior authorization role is required to perform the procedures described in this scenario.

252 Version 4.1 Introducing NoonTide Introducing NoonTide NoonTide Enterprises develops, markets, and sells electronic products to an international market. Their principal departments include Engineering, Support, Marketing, Administration, and Sales. NoonTide has installed and uses Tivoli Management Framework and several Tivoli applications to manage a distributed network that is divided into seven subnets, four in the corporate office and three in regional offices. Each department is represented by a policy region, which is created to model the management and organizational structure of a network computing environment, as well as to enforce common policies between related departments. In NoonTide’s Tivoli management region environment, each policy region houses each department’s resources such as subregions, managed nodes, endpoints, and profile managers.

The following policy regions exist on the administrator’s desktop. itiuinEnvironment Distribution .Udrtnigthe Understanding 9.

For example, the Engineering policy region represents the Engineering department. The Engineering policy region contains a

Tivoli Software Distribution User’s Guide 253 Introducing NoonTide

UNIX managed node gateway, called big, that serves endpoints. The Engineering policy region also contains the Product, Research, and Test subpolicy regions that group and control access to resources for these three components of the Engineering department.

NoonTide also organizes its environment according to administration tasks. The System Monitors and Tivoli Software Distribution policy regions contain Tivoli Distributed Monitoring and Tivoli Software Distribution subregions, jobs, and tasks. The pescado-region policy region is the default policy region that is created when the Tivoli management region server (Tivoli server) is installed. The name of the default policy region is taken from the name of the machine that is hosting the Tivoli server (pescado).

Network Architecture Understanding and planning NoonTide’s network topology is essential to configuring its distribution environment. NoonTide has seven subnets—four in the corporate office and three in regional offices. Subnets are connected either by Ethernet connections, which have bandwidths of 100 Mbps (megabits per second), or by T1 lines, which have bandwidths of 1 Mbps.

Each subnet contains a UNIX or an NT managed node gateway that connects to the Tivoli server. Endpoint gateways are installed on managed nodes in subnets that have endpoint clients. To distribute a software package profile to a managed node or gateway, you must install the endpoint service on it first.

Note: Only endpoints can be targets of distributions. Managed nodes are no longer supported as targets with this release.

A repeater can be part of a gateway (gateway repeater) or it can be created as a standalone repeater on a managed node that does not have a gateway on it (standalone repeater). Standalone repeaters can distribute only to other repeaters, while gateway repeaters can also distribute to their endpoints (targets). The repeater manager maintains information about the Tivoli network configuration,

254 Version 4.1 Network Architecture

including target clients and repeater sites. See “Configuring Repeater Sites” on page 262 for more information about configuring repeaters.

The endpoint manager controls and configures gateways and endpoints, assigns endpoints to gateways, and maintains the endpoint list. The endpoint manager is available from the Tivoli desktop. For information about the endpoint manager, endpoint gateways, and managed resources, refer to the Tivoli Management Framework Planning for Deployment Guide.

The following diagram illustrates NoonTide’s network topology.

Subnet 3 Subnet 4 Subnet 5 Subnet 6 Subnet 7

oak big pearl diamond lapis Environment Distribution .Udrtnigthe Understanding 9. Tivoli management region server

rainbow pescado electron alloy dollar odin

Subnet 1 Subnet 2

Ethernet connection T1 connection

lolo

Tivoli Software Distribution User’s Guide 255 Network Architecture Subnet 1 Subnet 1 includes machines that are connected by LAN to the Tivoli server, pescado, in the corporate office. Subnet 1 includes machines in the NoonTide Operations, NoonTide Administration, and Marketing departments.

NoonTide Operations odin (Solaris managed node gateway) balder (Solaris) thor (Solaris) loki (Solaris)

NoonTide Administration rainbow (AIX managed node gateway) green (Windows 98) red (Windows 98) blue (Windows 2000) orange (Windows 2000) yellow (Windows 2000) violet (Windows NT)

NoonTide Marketing dollar (AIX managed node gateway) peso (Windows 98) shilling (Windows 98) franc (Windows 2000) pound (Windows 98) drachma (Windows 98) rupee (Windows 2000) dinar (Windows 200) yen (Windows NT) lira (Windows 2000)

Subnet 2 Subnet 2 is located in the corporate office and is connected by a T1 connection to pescado. It includes machines in the HQ Sales department.

NoonTide Sales (Corporate) electron (Windows NT 4.0 managed node) silver (Windows 98) gold (Windows 98) platinum (OS/2)

256 Version 4.1 Network Architecture

NoonTide Sales (Corporate) alloy (Windows NT 4.0 managed node gateway)

Subnet 3 Subnet 3 is located in the corporate office and is connected by an Ethernet connection to pescado. It includes machines in the NoonTide Support department.

NoonTide Sales (Corporate) oak (AIX managed node gateway) maple (AIX) cedar (Solaris) walnut (HP-UX) mahogany (HP-UX) elm (HP-UX)

Subnet 4 Subnet 4 includes machines in the Engineering department. This

subnet is located in the corporate office and is connected by an Environment Distribution

Ethernet connection to pescado. the Understanding 9.

NoonTide Engineering big (HP-UX managed node gateway) brie (Solaris) philly (Windows NT) camembert (HP-UX) cottage (Windows 98) ricotta (AIX) american (Solaris) parmesan (AIX) jack (HP-UX) bleu (HP-UX) provolone (AIX) edam (HP-UX) gouda (AIX) gruyere (AIX) swiss (HP-UX) stilton (HP-UX) cheddar (HP-UX)

Tivoli Software Distribution User’s Guide 257 Network Architecture Subnet 5 Subnet 5 includes machines in the West Coast Sales department and is located in a regional office. It is connected by a T1 line to electron.

NoonTide Sales (West Coast) pearl (Windows 2000 managed node gateway) agate (Windows 98) coral (Windows 2000)

Subnet 6 Subnet 6 includes machines in the Central Sales department and is located in a regional office. It is connected by a T1 line to electron.

NoonTide Sales (Central) diamond (NT 4.0 managed node gateway) emerald (Windows 98) ruby (Windows 2000)

Subnet 7 Subnet 7 includes machines in the East Coast Sales department and is located in a regional office. It is connected by a T1 line to electron.

NoonTide Sales (East Coast) lapis (NT 4.0 managed node gateway) opal (Windows 98) sapphire (Windows 2000)

Creating a Repeater Hierarchy NoonTide Enterprises has configured its network environment to optimize use of Tivoli’s Multiplexed Distribution (MDist 2) service. Every repeater (gateway or standalone) contains both an MDist 1 repeater and an MDist 2 repeater. However, Tivoli Software Distribution, Version 4.1 uses MDist 2 only. MDist 2 enables you to perform asynchronous distributions of large amounts of data to

258 Version 4.1 Creating a Repeater Hierarchy

multiple targets in an enterprise. The MDist 2 service maximizes NoonTide’s data throughput by performing the following operations: Parallel distribution Enabling parallel distribution to hosts on the same subnet. Using this feature, the data flows from the source host pescado through the dollar and rainbow gateway repeaters and down to the endpoints, if both the Marketing and Administration departments need this application. This feature results in a distribution that can be faster than sending copies of the software in serial to each machine. Spreading the distribution load across networks Spreading the distribution load across networks. Spreading the distribution load across a network tree limits resource contention that can arise when one server is responsible for distributing to many client machines. Sending single copies of the data across slower links The repeaters redistribute the single copies in parallel to other hosts on the far side of the slow connection. This distribution is a more effective use of the network than

sending a copy of the software across the network gateway Environment Distribution for each remote target. For example, pescado can efficiently the Understanding 9. distribute to pearl, diamond, and lapis using electron as a repeater site. Using repeater depots Enabling repeaters to temporarily or permanently store distribution data at an intermediate fan-out point called a repeater depot. A repeater depot has the built-in MDist 2 capability of permanently or temporarily storing data segments. A repeater configured as a permanent depot maintains the data in the repeater depot even after the distribution has completed. A repeater depot also enables you to store software distributions on nodes closer to the targets. For example, the diamond gateway, which has repeater depot functionality, can start a distribution to software packages from its repeater depot to the target systems associated with it, rather than from the source host.

Tivoli Software Distribution User’s Guide 259 Creating a Repeater Hierarchy

Caching distributions Caching distributions, which enables the checkpoint restart functionality. If a distribution failure occurs for one target, the fan-out point continues to distribute to the other targets. The interrupted distribution automatically resumes from where it left off using the data from the repeater depot, rather than beginning all over again from the origin of the distribution data.

By default, the Tivoli server pescado serves as the repeater distribution server for all the targets in the Tivoli management region. Pescado is also the source host and therefore also a repeater. The source host machine must be a repeater. Endpoint gateways are automatically configured to act as MDist 2 repeaters for distributing information to their endpoints. The NoonTide network includes endpoint gateways at odin, big, pearl, diamond, and lapis. NoonTide has configured the rainbow and dollar gateways to serve as additional MDist 2 repeaters. The network also includes electron, a standalone repeater with the MDist 2 function.

The following diagram shows NoonTide’s repeater hierarchy. The arrows represent the distribution flow.The distribution flow would be different if the source host was not located on the pescado Tivoli server but on a separate managed node. In this case, the distribution flow would originate at the source host.

260 Version 4.1 Creating a Repeater Hierarchy itiuinEnvironment Distribution .Udrtnigthe Understanding 9.

As in the case of the NoonTide network, one repeater site is often not enough to handle heavy network traffic and large software distributions. To determine the number of additional repeaters needed in any given environment, use the following guidelines: ¶ If the network has slow network links, designate one managed node on each side of the network link to be a repeater with a local copy of the Tivoli binaries. ¶ If the range (the managed node clients that receive data from the repeater site) of a repeater site contains too many clients in multiple subnets, add a repeater site for each subnet.

Tivoli Software Distribution User’s Guide 261 Creating a Repeater Hierarchy

In addition to determining the number of repeaters, you will also need to determine which of the MDist 2 repeaters are to be configured as permanent depots. Any repeater can be configured to be a depot. The placement of the repeater depots depends on where you need depot storage facilities in your Tivoli environment. It is recommended that you place depots on the other side of slow network links, like WANs, to enable quicker distributions. You must also consider the disk space required for the storage of distributions, especially if entire distributions are stored after they complete. You need to calculate the size of the distribution and select a system with the required disk space.

Before you begin a distribution, you can verify the repeater route or distribution path by using the wrpt command with the –q argument. Refer to the Tivoli Management Framework Reference Manual for more information about the wrpt command syntax and arguments.

The remainder of this chapter describes how to determine whether additional repeaters are needed, how to configure the parameters for each repeater, and how to configure a repeater as a depot. Refer to the Tivoli Management Framework Planning for Deployment Guide to determine repeater and repeater depot environments and settings that will work best in your environment. In addition, the Tivoli Management Framework Planning for Deployment Guide provides information about configuring endpoint gateways on managed nodes that serve endpoints. Configuring Repeater Sites As NoonTide’s senior system administrator, you must complete each of the following steps to determine whether more repeater sites are necessary and, if so, how to configure them: 1. Determine which machines are defined as repeaters by typing the wrpt command from the command line of any managed node in the Tivoli management region. For example, when you first install Tivoli Management Framework on the pescado server, wrpt gives the following output: pescado [1] wd []

262 Version 4.1 Configuring Repeater Sites

After you configure NoonTide’s environment, run wrpt to list the default repeater on pescado, all endpoint gateways, and each managed node that is configured with a repeater. 2. List the machines in the range of the pescado repeater. Enter the following odadmin command from the command line of any managed node in the Tivoli management region to list the clients of the pescado repeater: odadmin odlist

The output of this command is as follows:

Region Disp Flags Port IP address Hostname(s) 2012560680 1 ct- 94 146.84.1.38 pescado,pescado.noontide.com 2 ct- 94 127.64.1.1 odin,odin.noontide.com 3 ct- 94 127.64.8.1 rainbow,rainbow.noontide.com 4 ct- 94 127.64.9.1 dollar,dollar.noontide.com 5 ct- 94 127.64.2.1 electron,electron.noontide.com 6 ct- 94 127.64.3.1 oak,oak.noontide.com 7 ct- 94 127.64.4.1 big,big.noontide.com

8 ct- 94 127.64.5.1 pearl,pearl.noontide.com Environment Distribution .Udrtnigthe Understanding 9. 9 ct- 94 127.64.6.1 diamond,diamond.noontide.com 10 ct- 94 127.64.7.1 lapis,lapis.noontide.com 11 ct- 94 127.64.2.2 alloy, alloy.noontide.com

This list contains the names and IP addresses of managed nodes in each subnet shown in “Network Architecture” on page 254. Endpoints are not listed because they do not have the full Tivoli Management Framework (oservs). Endpoints rely on managed nodes for communication with the Tivoli server. 3. Create a repeater site on all managed nodes that serve as standalone repeaters in the repeater hierarchy. Endpoint gateways are automatically configured as repeater points for their client endpoints. To create a standalone repeater, use the wrpt command as follows: wrpt –n repeater_name range=value

Tivoli Software Distribution User’s Guide 263 Configuring Repeater Sites

In the NoonTide environment, enter the following command to make electron a standalone repeater that serves the pearl, diamond, and lapis gateway repeaters: wrpt –n electron range=8-10

Refer to the Tivoli Management Framework User’s Guide for more information about creating a standalone repeater. 4. Use the wrpt command to verify that repeater sites are configured correctly. The output for NoonTide’s configuration follows: pescado [1] -wd- [] odin [2] --- [] rainbow [3]] --- [] dollar [4]] --- [] electron [5] --- [8, 9, 10] oak [6] --- [] big [7] --- [] pearl [8] --- [] diamond [9] --- [] lapis [10] --- [] alloy [11] --- []

The electron repeater lists the host numbers of the machines it serves as their range.

In NoonTide’s environment, pescado distributes software package A to its endpoint clients, which are managed by the rainbow, odin, dollar, oak, big, and electron gateways. The electron repeater distributes software package A to the pearl, diamond, and lapis gateways. Finally, pearl, diamond, and lapis distribute the software package to their endpoints. Each repeater and endpoint gateway distributes software package A in parallel to its endpoint clients. Refer to the Tivoli Management Framework Reference Manual for more information about the wrpt and odadmin commands. Setting Repeater Parameters Now that you have created standalone repeater and endpoint gateway repeater sites for NoonTide’s network, you must configure each of them to efficiently handle software distributions. Use the wmdist command to configure MDist 2 repeater parameters and manage distributions for both standalone repeaters and gateway repeaters.

264 Version 4.1 Setting Repeater Parameters

Refer to the Tivoli Management Framework Reference Manual for more information about the syntax and arguments of the wmdist command.

You configure each repeater and endpoint gateway in the NoonTide network in accordance with the amount of available memory, disk space, and network bandwidth, and the number and bandwidth capacity of the repeater’s targets.

The following procedure configures the electron (a Windows NT machine) and pescado (a Solaris machine) repeaters by performing the following steps: 1. “Step 1: List the Current Settings of the Repeaters’ Parameters”. 2. “Step 2: Determine the Disk Space Requirements of the Applications to be Distributed” on page 269. 3. “Step 3: Check that the Electron and Pescado Sites Have the Required Disk Space and Memory” on page 269. 4. “Step 4: Set Electron’s Repeater Parameters” on page 271.

5. “Step 5: Set Pescado’s Repeater Parameters.” on page 272. Environment Distribution 6. “Step 6: Verify that the Repeater Parameters are Set Correctly” the Understanding 9. on page 272. 7. “Step 7: Restart the Repeater” on page 273.

Step 1: List the Current Settings of the Repeaters’ Parameters Enter the following wmdist command: wmdist -s electron wmdist -s pescado

The following is the default output of this command for the electron repeater. The default output for the pescado repeater is the same, except that the default repeater directory for a UNIX repeater is /var/tmp/. repeater_id: 2012560680.5.7 rpt_dir: $DBDIR/tmp/ permanent_storage: TRUE

Tivoli Software Distribution User’s Guide 265 Setting Repeater Parameters

max_sessions_high: 5 max_sessions_medium: 10 max_sessions_low: 40 disk_max: 500 (MB) mem_max: 64 (MB) send_timeout: 300 (secs) execute_timeout: 600 (secs) notify_interval: 30 (mins) conn_retry_interval: 900 (secs) retry_ep_cutoff: 7200 (secs) net_load: 500 (KB/sec) packet_size: 16 (KB) target_net_load: 0 (KB/sec) debug_level: 3 debug_delay: 0

where: rpt_dir=pathname Specifies the repeater’s main directory. It is also the parent directory that is used to hold the depot directory and the states directory. The depot directory contains all the segments stored in the database and must have enough free space to hold the value of disk_max. The states directory contains the database that holds the persistent state of the repeater’s queue. permanent_storage=TRUE|FALSE Configures the repeater to be a depot. If TRUE, the depot retains segments marked for permanent storage by applications after their distribution finishes. If FALSE, a distribution’s segments are deleted after the repeater finishes sending the distribution to all its targets. max_sessions_high=number Specifies the maximum number of concurrent connections that a repeater opens for high-priority distributions. These connections are shared among all active distributions. If the repeater runs out of high-priority connections, it tries to use a medium-priority connection. max_sessions_medium=number Specifies the maximum number of concurrent connections that a repeater opens for medium-priority distributions. These

266 Version 4.1 Setting Repeater Parameters

connections are shared among all active distributions. If the repeater runs out of medium-priority connections, it tries to use a low-priority connection. max_sessions_low=number Specifies the maximum number of concurrent connections that a repeater opens for low-priority distributions. This number must be one or greater. These connections are shared among all active distributions. If the repeater runs out of low-priority connections, it waits for an open connection to complete before opening additional connections. disk_max=max_size_MB Specifies the amount of disk space allocated to the repeater depot. Units are in megabytes (MB). If the disk_max number equals zero, no limit is enforced. This number cannot exceed the size of the disk. Every distribution flowing through a repeater is stored at least temporarily in the depot. The depot must be large enough to hold the largest distribution that you expect to distribute. mem_max=max_size_MB

Specifies the amount of memory used to buffer data being Environment Distribution sent to targets. This buffer improves performance by the Understanding 9. reducing the number of disk accesses to the depot. The memory is shared among all active distributions. Units are in MB. send_timeout=seconds Specifies the timeout used to detect a network or target failure while sending data. A target is allowed send_timeout seconds to receive each packet on the network. If a timeout occurs, the distribution remains in the repeater’s queue and a retry occurs in conn_retry_interval seconds. Refer to the Tivoli Software Distribution Reference Manual for more information about how Tivoli Software Distribution sets timeout values for a distribution. execute_timeout=seconds Specifies the time an endpoint method has to return results after it has received all of a distribution’s data. Tivoli

Tivoli Software Distribution User’s Guide 267 Setting Repeater Parameters

Software Distribution may be running scripts after receiving data but before returning results to the repeater. Units are in seconds. Refer to the Tivoli Software Distribution Reference Manual for information about overwriting this parameter setting by using the execute_timeout attribute. notify_interval=minutes Specifies the time interval (in minutes) between successive status reports. As targets finish, their results are buffered by the repeater. When the notify_interval (in minutes) has elapsed or all of the targets of this distribution have finished, the results are flushed. The results are sent to the application using MDist 2 and updated in the MDist 2 database. Refer to the Tivoli Software Distribution Reference Manual for information about overwriting this parameter setting using the notify_interval attribute. conn_retry_interval=seconds Specifies the time (in seconds) that must elapse before unavailable or interrupted targets are retried. retry_ep_cutoff=seconds Specifies the amount of plan time (in seconds) that a repeater retries an unavailable or interrupted endpoint. Unavailable or interrupted repeaters are retried until the distribution’s deadline has been reached. net_load=KB_per_second Specifies the maximum amount of network bandwidth the repeater is allowed to use. Units are in kilobytes per second. This allocation is shared among all active distributions. Used with target_netload. packet_size=number Specifies the number of bytes written to the network during each send. target_netload=KB_per_seconds Specifies the maximum amount of network bandwidth that can be sent to an individual target. Units are in kilobytes per second. The default value of 0 disables this check. Used with net_load.

268 Version 4.1 Setting Repeater Parameters

Some of these parameters can be overwritten for a particular distribution by specifying them in the distribution options at distribution time. For more information about repeater parameters, refer to the Tivoli Management Framework User’s Guide and the Tivoli Management Framework Reference Manual.

Step 2: Determine the Disk Space Requirements of the Applications to be Distributed Determine the disk space requirements of the applications to be distributed by referring to the installation guides for the applications.

In this scenario assume that the installation media and some of the application files of the software to be distributed are distributed in the software package. The installation media requires 180 MB and the application requires about 25 MB. Thus, assume the largest software package will be 210 MB, considering the overhead of the configuration programs and the software package.

Step 3: Check that the Electron and Pescado Sites Have the Required Disk Space and Memory Check that the electron and pescado sites have the required disk

space and memory in the directory represented by rpt_dir. Environment Distribution .Udrtnigthe Understanding 9. Note: You must be logged in as Administrator to perform the steps to determine disk space and memory allocations. 1. Check for available disk space on electron (a Windows NT machine) by clicking Start→Programs→Administrative Tools→Disk Administrator.

Tivoli Software Distribution User’s Guide 269 Setting Repeater Parameters

The C:\ drive has 388 MB of free disk space and the D:\ drive has 1484 MB of free disk space. 2. Check for available memory on electron by clicking Start→Programs→Administrative Tools→Windows NT Diagnostics. 3. Select the Memory tab to display the following window:

About 148 MB (152,016) of memory are available. 4. Check for available memory on pescado (a Solaris machine), and locate a file system with free space that can be used to buffer distributions. (Commands used for finding available memory vary by operating system.) To check the amount of RAM installed on the machine, enter the prtconf | grep “Memory size” command. Note that this command returns the total amount of memory installed, not just the free memory. The output is: Memory size: 512 Megabytes

Finally, to check the disk partitions for available space, use the df –k command. The output is:

270 Version 4.1 Setting Repeater Parameters

Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/rootvol 246463 182254 39569 82% / /dev/vx/dsk/usr 249991 184582 40419 82% / /proc 0 0 0 0 /usr fd 0 0 0 0% /proc /dev/vx/dsk/rootdg/vol06 983020 586911 29780 66% /var swap 602632 68332 534300 11% /tmp

Because the /tmp file system uses a portion of swap space it is not a good choice to use as a repeater. The /var file system is the best choice for this system because it has the largest free space and it does not use swap space.

Step 4: Set Electron’s Repeater Parameters The send_timeout parameter is not reconfigured in this example. The slowest system on the network is a Pentium with 32 MB of RAM. The default send_timeout is 300 seconds, which is sufficient for this system’s configuration. 1. Set the mem_max and disk_max parameters. For performance reasons, do not set mem_max higher than the available RAM. The memory cache reduces disk access to improve performance. itiuinEnvironment Distribution

If mem_max is larger than available memory, it causes the data the Understanding 9. to be swapped to disk and the performance gain will be lost. To avoid the possibility of a failed distribution, set the disk_max parameter to the majority of the hard drive space available on the repeater. For example, the electron repeater has 148 MB of available physical memory and 1.5 GB of free space on the D: partition of its hard drive. The following command sets the mem_max parameter to 100 (so as not to reserve all the available memory for the repeater cache) and the disk_max parameter to 1000. wmdist -s electron mem_max=100 disk_max=1000 2. Set the rpt_dir parameter to be on a partition with at least the specified disk_max value of free space. In this case, specify the repeater main directory for the electron repeater on the D: partition, under D:\tivoli\rptdir: wmdist -s electron rpt_dir=D:\tivoli\rptdir

Tivoli Software Distribution User’s Guide 271 Setting Repeater Parameters

You can use a backslash (\) in the directory path if you enter this command from electron. If you enter this command from a UNIX managed node, you must qualify the backslash with another backslash or use a forward slash (/) as follows: D:/tivoli/rptdir

Step 5: Set Pescado’s Repeater Parameters. Set pescado’s repeater parameters. 1. Pescado’s physical memory is 512 MB. If pescado is used for tasks in addition to acting as a repeater, set this parameter to use a smaller portion of the resources. wmdist -s pescado mem_max=128 2. Set the rpt_dir and disk_max parameters. The /var file system has available disk space and files should be buffered in the /var/tmp directory. Of the 297 MB available on /var, the repeater will be limited to use 230 MB to ensure that it does not use all of the file system’s space. Set the parameters as follows: wmdist -s pescado rpt_dir=/var/tmp disk_max=230

Note: For network connections with different bandwidths, the repeater parameter values must be scaled proportionally.

Step 6: Verify that the Repeater Parameters are Set Correctly Verify that the repeater parameters are set correctly using the wmdist –s command for each repeater. The output for the electron repeater is as follows: repeater_id: 2012560680.5.7 rpt_dir: D:\tivoli\rptdir permanent_storage: TRUE max_sessions_high: 5 max_sessions_medium: 10 max_sessions_low: 40 disk_max: 1000 (MB) mem_max: 100 (MB) send_timeout: 300 (secs) execute_timeout: 600 (secs) notify_interval: 30 (mins) conn_retry_interval: 900 (sec) retry_ep_cutoff: 7200 (secs)

272 Version 4.1 Setting Repeater Parameters

net_load: 500 (KB/sec) packet_size: 16 (KB) target_netload: 0 (KB/sec) debug_level: 3 debug_delay: 0

The output for the pescado repeater is: repeater_id: 2012560680.1.357 rpt_dir: /var/tmp/ permanent_storage: TRUE max_sessions_high: 5 max_sessions_medium: 10 max_sessions_low: 40 disk_max: 230 (MB) mem_max: 128 (MB) send_timeout: 300 (secs) execute_timeout: 600 (secs) notify_interval: 30 (mins) conn_retry_interval: 900 (sec) retry_ep_cutoff: 7200 (secs) net_load: 500 (KB/sec) packet_size: 16 (KB) target_netload: 0 (KB/sec) debug_level: 3 debug_delay: 0

Step 7: Restart the Repeater Environment Distribution To stop and restart a specific gateway and its repeater, enter the the Understanding 9. following command: wgateway gateway_name restart

Standalone repeaters restart after 20 minutes of inactivity. You can wait until the repeater restarts or enter the following command: odadmin reexec dispatcher_number Using Repeater Depots Unlike repeaters, repeater depots are able to store an entire distribution and resume a distribution that has been halted by unavailable nodes or network failures. When you have configured a repeater as a repeater depot, you can submit distributions with repeater depots as the targets. Data, or distribution segments, can be temporarily or permanently stored on the depot depending on the settings of the repeater’s parameters. You can use the wldsp command to load a software package on a repeater depot or the

Tivoli Software Distribution User’s Guide 273 Using Repeater Depots

wuldsp command to unload a software package from a repeater depot. Refer to the Tivoli Software Distribution Reference Manual for more information about the commands. A temporary depot works like a permanent depot except that it deletes the segments associated with a distribution when the distribution is completed. It is recommended that you use depots at the end of slow, unreliable network links. However, do not use depots for extremely large distributions or data that changes frequently.

The following scenario shows how to configure the lapis repeater as a repeater depot, load a software package on the depot, install a software package from the depot, list the entries on the depot, and remove a software package from a depot. 1. Configure the lapis repeater to be a repeater depot. It needs enough space for all of the active distributions, plus space for all distributions that will be permanently stored on the repeater depot. To configure the lapis repeater to be a repeater depot, use the wmdist command and set the permanent_storage parameter to true as follows: wmdist -s lapis permanent_storage=TRUE 2. Load the mypackage software package on the lapis repeater depot. To load the software package, use the wldsp command as follows: wldsp @mypackage lapis

If the software package contains nested software packages on the depot, use the wldsp command to load the primary software package. This automatically loads the nested software packages that it contains. In this case, a multi-segment distribution is submitted to MDist 2 where each segment contains a different package. 3. Perform an installation of the mypackage software package from the lapis repeater depot using the winstsp command as follows: winstsp -l from_depot @mypackage @sapphire

274 Version 4.1 Using Repeater Depots

If you have configured an RDBMS Interface Module (RIM) database, you can use the wmdist command together with the –e, –l, and –i arguments to monitor and control the distribution. 4. List the entries on the lapis repeater depot and information related to each entry. This includes the ID, version, size, percentage completed, and last modification time. To list the entries, use the wdepot command with the –l argument as follows: wdepot lapis list -l 5. Remove the mypackage software package from the lapis depot. Use the wuldsp command as follows: wuldsp @mypackage lapis 6. Delete all entries in the depot. Use the purge argument as follows: wdepot lapis purge

You will be prompted for confirmation before the depot is purged. itiuinEnvironment Distribution .Udrtnigthe Understanding 9.

Tivoli Software Distribution User’s Guide 275 Using Repeater Depots

276 Version 4.1 0 h Distribution The 10. 10 Process The Distribution Process

This chapter describes how you prepare software packages for distribution in the Tivoli environment. From the Tivoli desktop, you can define software packages, associate them with target machines, and distribute them to those machines, in parallel, in the same or different Tivoli management regions.

You use the Tivoli desktop to import software packages into the Tivoli environment, in which you can perform Tivoli Software Distribution operations. The desktop supports all the operations that you can perform from the command line interface (CLI). For information about commands, refer to the Tivoli Software Distribution Reference Manual.

To perform Tivoli Software Distribution tasks, you must have appropriate authorization. For more information about authorization, See “Authorization Roles” on page 557.

This chapter provides instructions for: ¶ Creating profiles within a profile manager, and importing software packages into that profile, and for setting profile subscribers (the profile managers and endpoints) for the profile manager in which the profiles reside. See “Creating a Tivoli Software Distribution Profile” on page 278. ¶ Preparing the software package for distribution within the Tivoli environment. See“Importing a Software Package into the Tivoli Environment” on page 285.

Tivoli Software Distribution User’s Guide 277 The Distribution Process

¶ Defining the properties of a software package using either the Software Package Editor or the command line. See “Software Package Properties” on page 290. ¶ Calculating the size of newly created software packages and for recalculating them if they have changed since their creation. See “Calculating the Size of a Software Package” on page 292. ¶ Converting the software package file format from software package to software package block, and vice versa. See “Converting a Software Package” on page 293. ¶ Exporting a software package object into text file (.spd) format to produce the software package definition file. This definition file can be modified and imported into a software package or software package block. See “Exporting a Software Package” on page 295. ¶ Using change management operations on software package objects. See “Change Management Operations” on page 297.

Creating a Tivoli Software Distribution Profile You create a Tivoli Software Distribution profile within a profile manager that has been defined in a policy region. You then import software packages into Tivoli Software Distribution profiles. How you do this is exemplified in the following scenario, in which you create a Tivoli Software Distribution profile from the Tivoli desktop and import the Appsample software package.

In this scenario, the distribution environment comprises the following: ¶ An administrator: Root_msecchi-region ¶ A policy region: msecchi-region ¶ A managed node: msecchi ¶ A profile manager that contains several software distribution profiles: PM1

278 Version 4.1 Creating a Tivoli Software Distribution Profile 0 h Distribution The 10. To determine the administrator’s name that was defined for the root user ID when Tivoli Management Framework was installed on the server, double click on the Administrators icon. Process

1. Double-click the msecchi-region icon to display the contents of the policy region.

Tivoli Software Distribution User’s Guide 279 Creating a Tivoli Software Distribution Profile

2. In the Policy Region: msecchi-region dialog, select Create → ProfileManager to create a profile manager in which the Appsample software package profile will reside. The Create Profile Manager dialog is displayed.

3. In the Name/Icon Label text box, type PM2. 4. Select the Dataless Endpoint Mode check box to enable the profile manager to distribute software package profiles to endpoints.

Note: If you do not select the Dataless Endpoint Mode check box, the system is in database mode. This enables distribution of software package profiles to any profile manager that has endpoints as subscribers. For more information about dataless and database modes, refer to the Tivoli Management Framework Planning for Deployment Guide. 5. Click Create & Close to return to the Policy Region: msecchi-region dialog. This now shows the PM2 profile manager. 6. To create a profile in the PM2 profile manager, double-click the PM2 icon to open the Profile Manager dialog. 7. Select Create → Profile to display the Create Profile dialog. In this dialog you create a software package profile for the

280 Version 4.1 Creating a Tivoli Software Distribution Profile 0 h Distribution The 10. APPsample software package. Process

8. In the Name/Icon Label text box, type the Appsample^1.0 profile name.

Note: The string that represents the software package name and version must be formed so that the name is separated from the version by one of the following characters: ¶ Caret (^) ¶ Dot (.) Refer to the Tivoli Software Distribution Reference Manual for more information about software package name and version syntax. 9. Click Create & Close to create the new profile and return to the Profile Manager dialog. An icon representing the newly created software package profile, Appsample^1.0, is displayed in the PM2 profile manager. The format of the software package profile

Tivoli Software Distribution User’s Guide 281 Creating a Tivoli Software Distribution Profile

at this point is empty.

Setting the Profile Subscribers Before you can perform a profile operation, you must set the subscribers (the profile managers and endpoints to which the profile manager distributes) for the profile manager in which the profile resides.

Note: The target on which you perform the distribution of a software package cannot be a managed node. It must be an endpoint.

Software packages install successfully only on endpoints; however, file packages and AutoPacks can include managed nodes as

282 Version 4.1 Creating a Tivoli Software Distribution Profile 0 h Distribution The 10. subscribers. This limitation may govern how you organize your profile managers. Keep your profile managers homogeneous where possible: avoid mixing software packages with Version 3.6.x file Process packages or AutoPacks in the same profile manager.

When performing an install change management operation you can select subscribers from those already available in that particular profile manager. However, when you select Profile Manager → Distribute from the Profile Manager dialog menu, you distribute to all subscribers identified in that profile manager, and you cannot selectively choose them for each type of package in the profile manager.

In the following scenario you add two endpoints as the subscribers to the PM2 profile manager. 1. From the Profile Manager dialog, select the Appsample^1.0 profile. 2. Select Profile Manager → Subscribers to display the Subscribers dialog:

3. To move a subscriber to the Current Subscribers list, select one or more subscribers from the Available to become Subscribers

Tivoli Software Distribution User’s Guide 283 Creating a Tivoli Software Distribution Profile

list, then click the left arrow button. By default, all subscribers in the profile manager are displayed in the Available to become Subscribers list. To remove a subscriber, select one or more subscribers from the Current Subscribers list and click the right arrow button to move them to the Available to become Subscribers list. 4. Move the PM1 (Profile Manager) subscriber to the Current Subscribers list, then click Set Subscriptions & Close. The PM1 subscriber is added to the PM2 Profile Manager dialog.

284 Version 4.1 Importing a Software Package into the Tivoli Environment 0 h Distribution The 10. Importing a Software Package into the Tivoli

Environment Process Before you can use a software package profile to distribute a software package to a target system, you must import the software package into the Tivoli environment where it is cataloged as a software package object in the Tivoli object database. The software package profile is only a definition of the information that each profile item includes. The profile items must be populated with the database objects to be distributed. You can import an existing software package located on either an endpoint or managed node into the software package profile, or you can create a new software package within the software package profile. Creating a New Software Package and Importing it into a Software Package Profile To create a new software package and import it into a software package profile, ensure that the Tivoli Software Distribution Software Package Editor component is installed and perform the following steps: 1. Create a software package profile as defined in “Creating a Tivoli Software Distribution Profile” on page 278. 2. Right-click the software package profile icon from the Profile Manager dialog, then select Properties from the pop-up menu. The Software Package Properties dialog is displayed. 3. Click Launch Software Package Editor to display the Create Software Package dialog. Type the source host name. 4. Click Set & Close to close the dialog and launch the Software Package Editor. The Software Package Editor main window is displayed. 5. Create the software package using the Software Package Editor as explained in “Creating a Software Package” on page 53. 6. Save the software package and return to the software package profile in the Profile Manager dialog. Check that the software package has been imported into the software package profile.

Tivoli Software Distribution User’s Guide 285 Importing a Software Package into the Tivoli Environment

Importing an Existing Software Package into a Software Package Profile Existing software packages can be imported in a built format (.spb) or in a not-built format (.sp). Before it is built, a software package contains only a description of the objects contained in the package, that is, a sequential list of actions to be executed on the target system and not the actual resources themselves, such as files and programs. The resources reside on the source host. A software package in the built format already contains all the objects and resources required by the actions in a zipped file format.

In this scenario, the Appsample^1.0 profile is populated with the Appsample software package, which is in the not-built format.

286 Version 4.1 Importing a Software Package into the Tivoli Environment 0 h Distribution The 10. 1. Right-click the Appsample^1.0 profile from the Profile Manager dialog, then select Import from the pop-up menu. Process

Tivoli Software Distribution User’s Guide 287 Importing a Software Package into the Tivoli Environment

The Import dialog imports a software package file into a software package profile.

2. In the Location of Input File group box, specify the machine type from the drop-down list. The options are Managed Node and Endpoint. If you select Endpoint, type the name of the endpoint in the Endpoint Name text box and then click the ellipsis (...) button. 3. Select Managed Node from the Machine Type drop-down list, then type msecchi in the Managed Node Name text box. 4. Click the ellipsis (...) button to display the Select Input File dialog. The dialog displays the file system hierarchy for the msecchi managed node. The file you select in this browser dialog is the file that is imported into the Appsample^1.0 software package profile. 5. Trace the path to the Appsample.sp file in the Directories and Files boxes. Click Set File & Close to return to the Import dialog. 6. You can import the software package either in the built format or in the not-built format.

288 Version 4.1 Importing a Software Package into the Tivoli Environment 0 h Distribution The 10. To import the Appsample software package in the not-built format, perform the following steps: Process a. Deselect the Build check box in the Location of Source Host group box. b. In the Source Host Name text box, type the name of the source host. The package is built at distribution time and the resources referenced in the software package are collected from the specified source host. Ensure that, when a package is being built at distribution time or imported to the built format, the source host component is installed on the source host. If not an error occurs.

—OR—

To import the Appsample software package in the built format, perform the following steps: a. Select the Build check box. b. Type the SPB path in the SPB Path text box. If the input file is a software package or software package definition file, it is imported into a software package block. If the input file is a software package block, it is copied from the managed node or endpoint specified in the Location of Input File group box to the specified software package block path on the source host.

Note: Always select the Build check box when importing a software package block.

Selecting the Build check box enables the Overwrite check box. Select Overwrite to overwrite the software package block should it already exist on the source host.

In this scenario, deselect the Build check box. 7. In the Source Host Name text box, type the source host from which the files in the software package block are to be obtained, if it is not already defined in the input file.

Tivoli Software Distribution User’s Guide 289 Importing a Software Package into the Tivoli Environment

Note: The source host can be any of the available managed nodes on which the Tivoli Software Distribution source host component is installed. 8. Click Import & Close. The software package profile icon in the Profile Manager dialog is now in the not-built format. Deleting a Software Package Profile When you delete a software package profile, it is removed from the Tivoli database and its icon is removed from the profile manager. Deleting a profile does not delete the source files or directories or the distributed files or directories on the subscribers.

Note: If you delete a software package for which you have scheduled a distribution, you must delete the job from the scheduler. Deleting a profile does not automatically delete the job. Refer to the Tivoli Management Framework Planning for Deployment Guide for more information about using the scheduler.

To remove previously distributed software packages from target systems, you perform a Remove change management operation. See “Remove Operation” on page 318 for more information about removing a software package.

Software Package Properties Software package properties can be defined in the following ways: ¶ Using the Software Package Editor. ¶ Using the wsetspop, wsetspgs, and wsetspat commands from the command line (excluding the Package Type and Versioning Type properties). ¶ Exporting a software package to the software package definition file format, modifying the properties, and re-importing the file back to the software package format. To view the properties of the Appsample software package profile from the Tivoli desktop, perform the following steps:

290 Version 4.1 Software Package Properties 0 h Distribution The 10. 1. Right-click the Appsample^1.0 software package profile icon in the Profile Manager dialog, then select Properties. The Software Package Properties dialog is displayed from which you can view Process the properties set for the software package.

2. Click Launch Software Package Editor to display the Software Package Editor. From the editor, you can do the following: ¶ View the contents of a software package ¶ Create a software package from scratch ¶ Edit software packages that are not in the not-built format For information about editing software packages that are in the built format and the options that are available when the Software Package Editor is launched from the Software Package Properties dialog, see “Launching the Software Package Editor on Managed Nodes” on page 55. 3. To view information on software packages nested in the Appsample^1.0 software package, click Nested Software Packages. See “Distributing Nested Software Packages” on page 327 for more information about distributing software packages that contain nested packages.

Tivoli Software Distribution User’s Guide 291 Software Package Properties

4. Click Advanced to display the Advanced Properties dialog.

The properties displayed in the Software Package Properties and Advanced Properties dialogs are explained in “Setting Software Package-level Properties” on page 122.

Calculating the Size of a Software Package Calculate the size of a software package at the source host to determine the total size of the files it contains. Use this option to recalculate the size if you have made changes to the package since its creation.

To calculate the size of the Appsample software package in the built format, perform the following steps: 1. Right-click the software package profile from the Profile Manager dialog, and select Calculate Size from the pop-up

292 Version 4.1 Calculating the Size of a Software Package 0 h Distribution The 10. menu. The Calculate Software Package Size dialog is displayed. Process

The Calculate Software Package Size dialog displays the name of the software package and its profile manager. If the size of the software package had already been calculated, it displays the last recorded calculation. 2. Click Calculate Size to recalculate the size of the currently selected software package (in bytes). Note that if a package contains only actions, that is, the package is in the not-built format, its size is calculated as zero. When calculating the size of nested software packages, the size is calculated as the sum of the size of the primary package plus the size of the nested packages. The size can be calculated successfully only if the primary package and nested packages have been imported into the Tivoli environment and cataloged as software package objects in the Tivoli object database.

Converting a Software Package The convert operation is used to transform the software package file format from software package to software package block, or from software package block to software package. You can use this operation to convert only software package objects that already exist in the object database. In other words, the software package objects must have been imported into the Tivoli environment.

Tivoli Software Distribution User’s Guide 293 Converting a Software Package

Note: The size of a software package block cannot exceed 2 GB. You can exceed this limit by nesting software packages. Each segment or package cannot exceed 2 GB.

A software package contains only a description of the objects contained in the package. That is, it contains a sequential list of actions to be executed on the target machine and not the actual objects or resources themselves, such as files or programs, which are located on the source host. A software package block is in a zipped file format and bundles the actions with the resources. All the resources must be located on the selected source host, otherwise, the operation fails. Not-built to Built To convert the Appsample software package (not-built) to a software package block (built), perform the following steps: 1. Right-click the Appsample^1.0 software package in the Profile Manager dialog, then select Convert from the pop-up menu. The Convert Software Package dialog is displayed.

2. In the SPB Path text box, type the path and file name for the software package block on the source host. The source host is the managed node defined when the package is imported. 3. Select the Overwrite check box to overwrite the software package block if it already exists on the source host. This option is valid only if the target format is a software package block. 4. Click Convert & Close to convert the software package into a software package block on the source host.

294 Version 4.1 Converting a Software Package 0 h Distribution The 10. Built to Not-built

To convert the Appsample software package block (built) to a Process software package (non-built), perform the following steps: 1. Right-click the software package block and select Convert. The software package block is stored on the source host defined at the time of import and the Convert Software Package dialog is displayed.

2. Select the Unbuild check box if you want to save the contents of the software package to a staging directory. 3. If you selected the Unbuild check box, click Unbuild Directory and navigate to the directory where you want to store the contents of the software package when it is unbuilt. 4. Click Convert & Close. The software package is converted to a non-built format. If you selected the Unbuild check box, the contents are saved to the Unbuild Directory and the source paths in the software package are updated so that they point to the Unbuild Directory. Otherwise, the software package block is converted to a software package and the source paths remain unchanged.

Exporting a Software Package The Export dialog enables you to export a software package object into text file format. This text file is the software package definition file. It consists of a sequence of stanzas, each of which describes an action to be executed. Using a text editor, you can view the .spd file, modify it, and use the Import function to import the revised .spd file

Tivoli Software Distribution User’s Guide 295 Exporting a Software Package

into a software package or software package block. Refer to the Tivoli Software Distribution Reference Manual for more information about the .spd file format.

To export a software package object to the .spd format and then reimport it, perform the following steps. 1. Right-click the Appsample^1.0 software package profile, then select Export from the pop-up menu.

2. Specify the name of the managed node to which the file should be exported in the Managed Node Name text box. 3. In the Path text box, specify the full pathname of the file on the managed node to which the software package is to be exported. To export to a remote managed node, you must specify its fully qualified path. 4. Select the Overwrite check box to overwrite an existing .spd file. 5. Click Export & Close to export the software package to the .spd file format. 6. Open and edit the software package definition file using a text editor. You can view software package definition files in the Tivoli Software Distribution Reference Manual. 7. Follow the instructions in “Importing a Software Package into the Tivoli Environment” on page 285 to import the .spd file to either a built or not-built software package.

296 Version 4.1 Change Management Operations 0 h Distribution The 10. Change Management Operations

This section describes the following change management operations Process that you can perform on software package objects. These options fully automate the distributing and installing of software, and are as follows: ¶ Install ¶ Remove ¶ Undo ¶ Accept ¶ Commit ¶ Verify

For more information about the operations and dialogs described in this section, refer to the corresponding Tivoli Software Distribution server command, which can be run from the command line of the server, in the Tivoli Software Distribution Reference Manual. Software Package States Each of the change management operations is performed in three steps: Check Test that the operation can be performed to reduce the risk of failure during the execution phase. Execute Perform the operation only if the check is successful. Cleanup Resources acquired during the execute phase are deleted.

Depending on the state of a software package, not all operations can be performed on it. The operational state of a software package can be determined in the following ways: ¶ Open the Tivoli Software Distribution log file located in the path specified in the software package properties log path.

Tivoli Software Distribution User’s Guide 297 Change Management Operations

¶ Install the disconnected command line on the endpoint and run the wdlssp command. ¶ Install Tivoli Inventory and the Tivoli Software Distribution Historical Database component and run the CM_STATUS_QUERY. The change management state of a software package is displayed as a five-character state string in the log file. For example, a software package with the IC---state is a package that has been installed and committed. Refer to the Tivoli Software Distribution Reference Manual for more detailed information about software package states.

The state of a software package is determined by the following: ¶ The nature of the last operation performed (install or remove). ¶ The state of the last operation performed (prepared or committed). ¶ The state of the backup package (undoable state). ¶ Whether a reboot is required to complete the operation. ¶ An additional flag that indicates an error condition or that the status is in the process of being changed. Executing Change Management Operations To display the change management operations that can be performed on the software package, right-click the Appsample^1.0 software

298 Version 4.1 Change Management Operations 0 h Distribution The 10. package in the Profile Manager dialog to display a pop-up menu. Process

From this menu, you can view software package properties, calculate the size of the software package, convert the software package into a software package block, export software packages, and perform change management operations on software packages.

Install Operation The install operation performs the actions contained in the software package. The actions executed by the install operation depend on the nature of the action. For example, while the install operation of the add file action copies a file to the target file system, the install operation of the remove registry key action removes a registry key from the target system Windows registry.

Tivoli Software Distribution User’s Guide 299 Change Management Operations

1. Select Install from the Appsample^1.0 software package pop-up menu to display the Install Software Package dialog.

2. To upgrade an installed package, using byte-level differencing, select the Delta Install check box and type the name and version of the package to be upgraded in the Base Package text box. Tivoli Software Distribution uses the files contained in the delta package to reconstruct each version file starting from the base file already installed on the target and applying to it the corresponding delta file contained in the delta package. If any of the installed files to be reconstructed are not found on the target, or have been modified, or are read-only the delta

300 Version 4.1 Change Management Operations 0 h Distribution The 10. installation fails. To apply the delta installation the base and the version packages must have the same nested structure. Byte-level differencing uses dependency checking to verify if Process the base package has been installed on the target. The base package must be in the IC or ICU state. If you clear the Dependency check box, no checks are done on the base package. For a detailed explanation of how byte-level differencing works, refer to the Tivoli Software Distribution Reference Manual. If you perform a delta installation, you cannot install the software package in source or repair mode. 3. In the Label text box, specify the name of the software package, for example, Appsample^1.0. The default is the software package name, but you can specify any text in this text box. 4. Specify the order in which distributions are handled by repeaters in the Priority Level group box. The default value is Medium. 5. In the Changes group box, click one of the following: All Installs all the files in the software package. Source Installs only those source host files that have been modified since the last successful distribution to the target system. Repair Installs the following: ¶ The source objects that since the time of the last successful installation have been corrupted, modified, or are not present on the target. This makes the target objects consistent with the source objects. ¶ The objects and actions on the target that have been changed or corrupted since the time of the last successful installation.

Tivoli Software Distribution User’s Guide 301 Change Management Operations

The software package is re-built containing only the objects needed to perform the repair and, therefore, is smaller than the original software package, and is installed on the target. The repair option applies only to software packages in the following operational states: ¶ Target machines on which the software package has already been installed and committed (IC) ¶ Target machines on which the software package has been installed and committed, but the software package is in error (IC---E)

Note: The repair option also supports software package blocks, but not when the From Depot check box is selected. See step 8 on page 303 for information about the From Depot option. Refer to the Tivoli Software Distribution Reference Manual for more information about software package operational states. 6. In the Checks group box, click one of the following: No Checks Excludes all options in this box. Checks Verifies whether the installation can be executed before the installation is attempted. (Tivoli Inventory must be installed.) Force Forces the operation regardless of the state of the software package on the target system. If the package is versionable, the version checks are made on the target even when this option is selected. If the version checks fail, the installation fails. Refer to the Tivoli Software Distribution Reference Manual for more information about software package version checking. Ignore Proceeds with the operation only on target systems that have been successfully checked. If not specified, the operation does not proceed if the operation is not

302 Version 4.1 Change Management Operations 0 h Distribution The 10. consistent with the software package. For example, if you are performing an install operation and the software package is already installed, the operation does not Process proceed. (Tivoli Inventory must be installed.) Preview Returns to the log file on the server a list of actions that would be executed if you performed an install. The software package is not actually installed. This attribute can be used in conjunction with the repair or source options. A check is performed on the target and the list of files to be repaired or a list of source files that have been modified is returned to the log file. 7. Deselect the Disposable check box to keep the data associated with a distribution (depot segment) at the repeater after all target systems have received the distribution. Select the Disposable check box to remove the data associated with a distribution from the repeater once the distribution has finished (either all endpoints have completed or the distribution has exceeded its life span). Repeater depots that have been configured to accept permanent distributions will remove the distribution if the Disposable options is selected. For more information about configuring repeater depots to accept permanent distributions, see “Setting Repeater Parameters” on page 264.

Note: If the object of the distribution is a software package in the not-built format and not a software package block, this option is disabled and the data is deleted after the software package is distributed and not stored on the depot. 8. Select the From Depot check box to specify that the software package to be installed resides on the repeater depot rather than on the source host. See “Creating a Repeater Hierarchy” on page 258 for more information about depots. This option does not apply to software packages in the not-built format.

Tivoli Software Distribution User’s Guide 303 Change Management Operations

Note: If you select this check box, you cannot select either the From the Fileserver or the From CD check box. 9. Select the From Fileserver check box to specify that the software package to be installed is to be retrieved from a file server rather than on the source host. File servers must be configured if this option is used. This option does not apply to software packages in the not-built format. 10. Select the From CD check box to specify that the software package to be installed is to be retrieved from a CD rather than on the source host. This option does not apply to software packages in the not-built format. 11. To move a subscriber to the Install Software Package On list, select one or more subscribers from the Available Subscribers list, then click the left arrow. By default, all subscribers in the profile manager are displayed in the Available Subscribers list. To remove a subscriber, select one or more subscribers from the Install Software Package On list and click the right arrow to move them to the Available Subscribers list. If the Available Subscribers list contains a profile manager, a plus sign (+) appears in front of its name. You can double-click a profile manager name to expand it and display the Tivoli endpoints it contains and the other profile managers that subscribe to it. You can then select any of the subscribers and add them to the Install Software Package On list. If you select a profile manager name in the Available Subscribers list, you must deselect it before double-clicking it. The name of an expanded profile manager has a dash (–)in front of it in the Available Subscribers list. To compress an expanded profile manager entry, double-click the profile manager name. Click Expand All or Compress All to expand or compress all profile managers in the Available Subscribers list. 12. If you have Tivoli Inventory installed, you can select subscribers by scanning the available Tivoli endpoints for certain criteria defined by a query in a query library. Click

304 Version 4.1 Change Management Operations 0 h Distribution The 10. Query to display the Execute a Query dialog. Process

In this dialog, you can use the Tivoli configuration repository to define a list of distribution targets for a profile manager that contains a software package. It lists the available query libraries that were created using the Tivoli Management Framework. Select a query library from the Query Libraries scrolling list, then click Execute to run the query on the Tivoli configuration repository and return the names of the endpoints that meet the criteria. This list automatically populates the Install Software Package On list. Refer to the Tivoli Management Framework Planning for Deployment Guide for more information about creating and using queries. Click Close to return to the Install Software Package dialog. 13. Select the Dependency check box to apply any software and hardware dependencies defined for the software package. 14. Click Schedule to schedule operations at a future time. See “Creating and Executing Activity Plans with Activity Planner” on page 407 for information about a scheduling facility that enables you to manage a group of operations as a single operation from a single machine in the network. Tivoli Software

Tivoli Software Distribution User’s Guide 305 Change Management Operations

Distribution displays the Add Scheduled Job dialog.

The Add Scheduled Job dialog can be used to schedule jobs for the following operations: ¶ Install ¶ Remove ¶ Accept ¶ Commit

306 Version 4.1 Change Management Operations 0 h Distribution The 10. ¶ Undo

Tivoli Software Distribution automatically retries an unavailable Process target for the length of its distribution lifetime, without waiting until the distribution to all other targets is complete.

Note: When performing a distribution of a software package profile using either the Distribute option from the Profile Manager menu or the drag-and-drop method, the scheduler’s retry options do not function.

You can also set retry options by selecting Set Retry/Cancel/Restriction Options from the Add Scheduled Job dialog. The Set Retry/Cancel/Restriction Options dialog is displayed.

When the time set in the Retry Options group box arrives, any targets that experienced a failed distribution prior to this time are retried. Any ongoing distributions, or distributions that have been cancelled are not resubmitted.

Tivoli Software Distribution User’s Guide 307 Change Management Operations

Conversely, if a repeat is scheduled in the Repeat The Job group box, the distribution is repeated for all targets, including those that were previously unavailable and are currently being retried by the MDist 2 service. The result is two instances of the same distribution to the same target at the same time. To avoid this situation, set the lifetime of the distribution shorter than the repeat interval. See Timeout Settings in “Default Variables” on page 312 for more information about setting the lifetime of a distribution.

If Checks, Ignore, or Force is selected in the Checks group box from the operation dialogs that support the scheduling function, the check requested is performed when the scheduled time arrives and the job is executed. If retry or repeat, or both, are selected for a job, the checks are performed before the execution of the selection. Checks are not performed immediately for scheduled distributions because the state of the software package for a target could change before the scheduled time arrives.

Refer to the Tivoli Management Framework Planning for Deployment Guide for more information about creating tasks and jobs and using drag-and-drop to schedule a job.

Click Close to close the Add Scheduled Job dialog and return to the Install Software Package dialog. 15. To replace all values in this dialog with the default values for this operation click Reset. 16. From the Advanced Options pull-down menu, select the options you require. The following options are available: ¶ Install Operation Modes (See “Install Operation Modes” on page 309) ¶ Default Variables (See “Default Variables” on page 312) ¶ Distribution Settings (See “Distribution Settings” on page 313) ¶ Mobile Settings (See “Mobile Settings” on page 315)

308 Version 4.1 Change Management Operations 0 h Distribution The 10. 17. When you have finished setting options from the Advanced Options menu, install the software package to the selected subscribers by clicking Install & Close. The dialog is not Process dismissed until the operation has been submitted. You can view the status of the distribution using the Distribution Status Console or from the command line using the wmdist command. Refer to the Tivoli Management Framework User’s Guide for more detailed information.

Install Operation Modes Selecting Operation Modes from the Advanced Options pull-down menu enables you to specify additional options to be used when executing an install operation.

The options available in this dialog depend on the selections you make. For example, selecting Yes in the Transactional Options group box enables the Auto-Commit check box in the Automatic Operations group box, which was previously grayed out. Selecting the Auto-Commit check box enables the Reboot Options that were previously grayed out. Reboot options are not valid on UNIX systems. The install operation supports the following execution options: ¶ Transactional Options

Tivoli Software Distribution User’s Guide 309 Change Management Operations

No Not-transactional: This option does not provide the capability of returning the system to its initial state if the operation fails unless you have also selected the Yes option in the Undoable Options group box. If disk space is consumed before the distribution has completed, the distribution fails and some files are left on the target system. Use this option only if you are sure the operation will complete successfully. Yes Transactional: The execution of the operation is split into two phases: the preparation phase and the commit phase. During the preparation phase, each action in the package prepares the conditions for the successful execution of the requested operation, which reduces the risk of failure during the commit phase. If the preparation phase completes normally, in the case of an install, the files are installed in the staging area. At this point the commit phase begins, where the updates take effect, that is, files are moved from the staging area to the production area. If the preparation phase fails, the system is returned to its original state. For example, this option is useful if there are locked files or if there is not enough disk space. It avoids interrupting a distribution in mid-stream and leaving partial distributions (files) on the target system. If necessary Preferably not-transactional: Requests the system to not execute the operation in transactional mode if it detects that it cannot proceed because of temporary errors that could disappear during the commit phase. For example, it is useful to perform an operation with this two phase (preparation and commit phase) approach when resources are locked or not available in the preparation phase but then become available in the commit phase. ¶ Undoable Options No Not-undoable: A backup package is not created and therefore the undo of an operation is not possible.

310 Version 4.1 Change Management Operations 0 h Distribution The 10. Yes Undoable: Requests the ability to return the system to its previous state; creates a backup package. Process Note: This option is recommended for software packages that install system files, because the operation can then be rolled back (undone) without damaging the system. If possible Preferably-undoable: Attempts to create a backup package, but continues with the normal installation if the process to acquire backup copies fails. Transactional Undoable-in-transactional: Requests the system to reserve the necessary disk space for backup copies in the staging area during the preparation phase, which minimizes the risk of failure due to insufficient disk space during the commit phase. During the commit phase, the staging area is freed up and all the updates done in the preparation phase take effect. Use this option to execute a backup copy during the commit phase. ¶ Reboot Options No Not-in-a-reboot: Auto-commit without a reboot. Executes the commit operation without a machine reboot. This option increases the possibility of errors due to possible locked resources. Yes In-a-reboot: Auto-commit with a user reboot. Executes the commit phase the next time the machine is rebooted by the user. If necessary Executes the commit phase with a machine reboot only if necessary. For example, if locked files are found, an auto reboot will be performed. Automatic Auto-reboot: Executes the commit phase with a reboot when only the operating system is running and all other applications are closed. This option prepares the system

Tivoli Software Distribution User’s Guide 311 Change Management Operations

to complete the operation when the Tivoli Software Distribution agent automatically runs the reboot operation. ¶ Automatic Operations Auto-Commit Requests the system to automatically commit a pending operation. Auto-Accept Requests the system to automatically accept an undoable operation.

Click Set to save the options you selected, or click Set & Close to save the options and return to the Install Software Package dialog.

Default Variables Using this dialog, you can temporarily override the value of default variables formerly defined either in the Software Package Editor or in a Software Package Definition (SPD) file for a specific distribution. See “Creating a Software Package” on page 53 for more information about setting variables from the Software Package Editor.

Refer to the Tivoli Software Distribution Reference Manual for a list and description of Tivoli Software Distribution built-in variables.

You open this dialog by selecting Default Variables from the Advanced Options pull-down menu in the Install Software Package

312 Version 4.1 Change Management Operations 0 h Distribution The 10. dialog. Process

1. To change the value of a variable, type the name of the default variable for which you want to change the value in the Variable Name text box. In the Variable Value text box, type the new value to be assigned to the variable. 2. Using the Default Variables List group box, you can also add or remove variables to be used during the execution of an operation. 3. Click Set to save the variables you specified, or click Set & Close to save the variables and return to the Install Software Package dialog.

Distribution Settings Using this dialog, you can define rules for dealing with non-availability of targets. These rules include server-level and client-level timeout parameters that enable you to specify a time interval after which either the server or client interrupts a distribution. Setting timeout parameters can avoid suspended distributions.

Tivoli Software Distribution User’s Guide 313 Change Management Operations

You open this dialog by selecting Distribution Settings from the Advanced Options pull-down menu in the Install Software Package dialog.

1. Select the Wake on Lan EP check box if the distribution is to automatically trigger a reboot on targets that are not available at distribution time. 2. Select the Roaming EP check box if the distribution is to be transferred from the gateway where it is queued to the gateway where a mobile endpoint, which is a target to the distribution, has connected. If you clear this check box, the distribution remains queued at the original gateway until the mobile endpoint connects to it again or the distribution times out. 3. Type the date and time on which the distribution expires. The distribution fails for any targets that have not received the distribution before the specified date and time. 4. Specify a Notification Interval. The default is 1800 seconds (30 minutes).

314 Version 4.1 Change Management Operations 0 h Distribution The 10. This controls the interval with which each repeater bundles up the completed results and returns them to the application and distribution manager. Process The value specified here overrides the value previously set using the wmdist -s command. See “Setting Repeater Parameters” on page 264 for more information. 5. Specify a Send Timeout period. The default is 300 seconds (five minutes). Send Timeout refers to the length of time a repeater will wait for a target to receive a block of data. This timeout is used to detect network or endpoint failures. The value specified here overrides the value previously set using the wmdist -s command. 6. Specify a Execution Timeout period. The default is 300 seconds (five minutes). Execution Timeout refers to the length of time a repeater will wait for Tivoli Software Distribution to return the result of a distribution after all the data has been sent. This timeout is used to detect network, endpoint, or script failures, for example, a script that is running in an infinite loop. The value specified here overrides the value previously set using the wmdist -s command. 7. Click Set to save the settings you specified, or click Set & Close to save the settings and return to the Install Software Package dialog.

Mobile Settings Using this dialog, you can define rules for distributing software packages to mobile targets. Using the mobile settings you can do the following: ¶ Determine whether mobile users can defer accepting a software package and for how long. ¶ Determine whether to reject a software package. ¶ Specify a date by which the distribution must be completed or fail. ¶ Define a sequence of messages to be sent on specified dates to alert the mobile users to the presence of the software package.

Tivoli Software Distribution User’s Guide 315 Change Management Operations

You open this dialog by selecting Mobile Settings from the Advanced Options pull-down menu in the Install Software Package dialog.

1. Select the Enabled Disconnected Install check box to allow installation of the package in disconnected mode. Selecting this option enables the mobile endpoint to download the software packages to the local depot and execute the Software Distribution operation later. If you do not select the option, you must apply software packages when you download them.

316 Version 4.1 Change Management Operations 0 h Distribution The 10. 2. In the Distribution Note text box, type text to be sent with the distribution, or use one of the following options to import predefined text: Process ¶ Click Add note from file to navigate to a file where a pre-defined message is stored. ¶ Click Add note from SPO to use the software package description in the distribution note. 3. Select a Distribution Mode. Optional If you select this mode, the mobile user has the option to defer or reject the installation indefinitely. Mandatory If you select this mode, you must specify a Mandatory date by which the installation must be performed. The mobile user can defer installation up to this date. Hidden If you select this mode, the mobile user is not given the option of deferring the installation. The installation is performed as soon as the user connects to a gateway. 4. If you selected Mandatory mode, you must specify a date and time by which the installation must be performed. You can also choose to clear the Force check box. The force option has the following effect: Selected The mandatory installation is automatically started as soon as the mobile user connects and if the mandatory date is reached. This is the default. Cleared The mobile user has the choice of not starting the mandatory installation. However, the user will not be able to perform any other operations until the mandatory installation has been performed.

Tivoli Software Distribution User’s Guide 317 Change Management Operations

5. Unless you selected the Hidden distribution mode, you can specify an escalate date and time, when a message is to be sent to mobile users alerting them that there an outstanding installation to perform. If you specify a date, you must also provide a corresponding message. You can type the message in the text box, or click Add from file to navigate to a file where a predefined message is stored. You can define up to ten escalate dates and messages. 6. Click Set to save the settings you specified, or click Set & Close to save the settings and return to the Install Software Package dialog.

To perform an install operation from the command line, see the winstsp command in the Tivoli Software Distribution Reference Manual.

Remove Operation The remove operation uninstalls the software package; that is, it performs the opposite action of the install operation. The remove operation does not return the system to its state prior to the last executed operation (see “Undo Operation” on page 320). The actions performed by the remove operation depend on the nature of the action. Add object-related actions are reversed. For example, while the remove operation on the add file action removes a file from the file system, the remove operation of the add registry key action removes a registry key from the Windows registry. However, the remove operation on a remove object-action does nothing. The behavior of remove operations on program and system actions is defined in the program and system action properties.

318 Version 4.1 Change Management Operations 0 h Distribution The 10. Select Remove from the Appsample^1.0 software package pop-up menu to display the Remove Software Package dialog. Process

See “Install Operation” on page 299 for an explanation of the contents of the Remove Software Package dialog.

Remove Operation Modes Selecting Operation Modes from the Advanced Options menu enables you to specify additional options to be used when

Tivoli Software Distribution User’s Guide 319 Change Management Operations

performing a remove operation.

The remove operation supports the same options as the install operation. See “Install Operation Modes” on page 309 for definitions of these options.

Note: Do not select the Transactional radio button in the Undoable Options group box if you are removing a software package that has installed system files. Use the undo operation instead.

To perform a remove operation from the command line, see the wremovsp command in the Tivoli Software Distribution Reference Manual.

Undo Operation The undo operation returns the system to its state prior to the execution of the previous operation. This operation is used for objects for which the previous operation was submitted in undoable or in transactional mode to roll back the system to its original state. Files added by the installation that did not exist prior to the distribution are removed. If the files existed prior to the distribution and were removed, they are added back. If they existed prior to the distribution and were replaced, the previous copy is restored. Additions, deletions, or changes made to configuration or system

320 Version 4.1 Change Management Operations 0 h Distribution The 10. information (registry changes, .ini file entries, folders, shortcuts, and so on) are reset to their original state. However, this operation is valid only for the last attempted installation, not for prior Process installations. In the event of fatal errors during the installation process, this operation is triggered automatically.

Select Undo from the Appsample^1.0 software package pop-up menu to display the Undo Software Package dialog.

See “Install Operation” on page 299 for an explanation of the contents of the Undo Software Package dialog.

Undo Operation Modes Selecting Operation Modes from the Advanced Options menu enables you to specify additional options to be used when executing

Tivoli Software Distribution User’s Guide 321 Change Management Operations

an undo operation.

The undo operation supports the following operation mode options: ¶ Not-transactional ¶ Transactional ¶ Preferably not-transactional ¶ Auto-commit

See “Install Operation Modes” on page 309 for definitions of these options.

To perform an undo operation from the command line, see the wundosp command in the Tivoli Software Distribution Reference Manual.

Accept Operation The accept operation discards the resources needed to undo the previous operation. The accept operation, which frees up system resources, should be performed only when you are certain that you will not need to undo the previous operation. After running an accept operation, the previous operation is no longer undoable.

322 Version 4.1 Change Management Operations 0 h Distribution The 10. Select Accept from the Appsample^1.0 software package pop-up menu to display the Accept Software Package dialog. Process

See “Install Operation” on page 299 for an explanation of the contents of the Accept Software Package dialog.

To perform an accept operation from the command line, see the waccptsp command in the Tivoli Software Distribution Reference Manual.

Commit Operation The commit operation causes all the updates established in the preparation phase to take effect.

Tivoli Software Distribution User’s Guide 323 Change Management Operations

Select Commit from the Appsample^1.0 software package pop-up menu to display the Commit Software Package dialog.

See “Install Operation” on page 299 for an explanation of the contents of the Commit Software Package dialog.

Commit Operation Modes Selecting on Operation Modes from the Advanced Options menu enables you to specify additional options to be used when executing

324 Version 4.1 Change Management Operations 0 h Distribution The 10. a commit operation. Process

The commit operation supports the following execution options: No Not-in-a-reboot: Executes the commit operation without a potentially unnecessary machine reboot. However, this option increases the possibility of errors due to locked resources. Yes In-a-reboot: Executes the commit operation with a reboot when only the operating system is running. This option prepares the system to complete the commit phase the next time the machine is rebooted by the user. If necessary Reboot-only-if-necessary: Executes the commit operation with a reboot only if files are locked on the target at the time of distribution. Automatic Auto-reboot: Same as the Yes option, but the reboot operation is automatically run by the Tivoli Software Distribution agent.

To perform a commit operation from the command line, see the wcmmtsp command in the Tivoli Software Distribution Reference Manual.

Tivoli Software Distribution User’s Guide 325 Change Management Operations

Verify Operation The verify operation verifies the consistency of an installed software package and the objects on the target system. A verify operation checks that the changes that occurred during the last operation are intact. If this operation fails, the software package is placed in an error state. The actions performed by the verify operation depend on the nature of the action. For example, while the verify operation of the add file action verifies that the copied file still exists, the verify operation of the add registry key action verifies that the registry key is still in the Windows registry.

Select Verify from the Appsample^1.0 software package pop-up menu to display the Verify Software Package dialog.

See “Install Operation” on page 299 for an explanation of the contents of the Verify Software Package dialog.

To perform a verify operation from the command line, see the wversp command in the Tivoli Software Distribution Reference Manual.

326 Version 4.1 Distributing Nested Software Packages 0 h Distribution The 10. Distributing Nested Software Packages

The distribution behavior of a software package containing nested Process software packages varies depending on the following factors: ¶ The type of change management operation submitted on the primary package ¶ The change management status of the primary and nested software packages ¶ The installation options set in the primary and nested software packages

When Tivoli Software Distribution change management operations are performed on a primary package, the operation is also performed on the nested software packages. The following is the behavior of a primary software package containing nested software packages for each change management operation: Install The install operation installs the primary software package and its nested software packages in the order specified during the package creation. Even if the Stop on failure option is not selected in the primary package, if the installation of a nested software package fails, the installation of the primary package fails also. Recovery actions may be performed, depending on the installation options specified in the software package. For example, if the install operation was submitted in undoable mode, the target system is returned to its state prior to the installation failure. Remove Submitting a remove operation on a primary software package that contains nested software packages removes the packages in the reverse order in which they were originally installed. Undo The undo operation is performed on the primary package and nested software packages in the reverse order in which they were originally installed. The undo operation is successful if the operation on the primary package completes successfully,

Tivoli Software Distribution User’s Guide 327 Distributing Nested Software Packages

and the operation on each of the nested software packages completes successfully. The undo operation fails if the primary software package or one of its nested software packages were not originally installed in transactional mode. Accept The accept operation is performed on the primary software package and its nested software packages in the order specified at creation time. If one or more software packages are in error, they are ignored during the accept operation. The accept operation completes successfully only if the primary software package and its nested software packages are in a not-undoable state. Commit The commit operation is performed on the primary software package and its nested software packages in the order specified at creation time. The commit operation completes successfully when the primary package and its nested packages are installed in a committed state. Verify The verify operation is performed on the primary software package and on its nested software packages in the order specified at creation time.

For more information about change management operations, see “Change Management Operations” on page 297. See “Nested Packages” on page 141 for more information about specifying the order of execution of the primary package and nested software packages. Things to Consider Before implementing nested software packages, consider the following: ¶ Nested software packages are built independently from the primary software package. ¶ Nested software packages are imported into the Tivoli environment individually. If one or more nested software packages is not in the object database and an operation has been

328 Version 4.1 Distributing Nested Software Packages 0 h Distribution The 10. submitted on the primary package, the operation is unsuccessful and an error message for each missing package is displayed. Process ¶ The source host for all packages must be the same. ¶ Nested software packages can reside in different policy regions, but the user performing an operation on a primary package containing nested software packages must have the proper authorization role. ¶ The repair operation is performed only on the primary software package. No changes are performed during this operation. ¶ No checks are performed on the nested software packages when the primary package is imported into the object database. All checks are performed when a change management operation is submitted on the primary package. For this reason, no checks are performed when a software package is removed from the object database or renamed. ¶ Submitting operations in a disconnected target mode does not have any effect on nested software packages. Use only server commands. ¶ Utilizing the MDist 2 functionality, each software package is considered a segment. When distributing or loading a primary package containing two nested software packages, the distribution uses three distinct segments: one for the primary package, one for the first nested software package, and one for the second nested software package.

Tivoli Software Distribution User’s Guide 329 Distributing Nested Software Packages

Nested Package Distribution Scenario Consider the software package structure illustrated by the following figure:

Software Packages B, C and D are nested in Software Package A. The order of execution of the software packages is the order specified during the creation of the primary software package. In this scenario, the primary software package has been specified to be executed first and the nested packages follow. The following is the order of execution of the software packages: 1. Software Package A 2. Software Package B 3. Software Package C 4. Software Package D Assume that the following settings are specified in Software Package A (primary software package): ¶ Default change management operation: install ¶ Default change management operation mode: undoable ¶ Stop on failure option is not selected (stop_on_failure = no)

330 Version 4.1 Distributing Nested Software Packages 0 h Distribution The 10. The default change management operation and operation mode set in the primary package override the defaults specified in the nested software packages. When an install operation is submitted on the Process primary package, the following steps are performed: 1. Software package status information is retrieved from the inventory database for Software Packages A, B, C and D. Result: successful validation. 2. Install operation executed on Software Package A. Result: installed successfully. 3. Install operation executed on Software Package B. Result: installed successfully. 4. Install operation executed on Software Package C. Result: failure. 5. An undo operation is executed on Software Package A. The log reports that the rollback has been performed successfully. 6. An undo operation is executed on Software Package B. The log reports that the rollback has been performed successfully. 7. An undo operation is executed on Software Package C. The log reports that a rollback has been performed successfully. 8. Software Package D is not executed. No log is generated. Although the Stop on failure option was not selected (stop_on_failure = no) in the primary package, the install operation is interrupted and recovery operations are performed. The related reports containing the results of the operation are sent in accordance with the log information options specified in each of the software packages. However, the log for the primary software package also contains the results of the operations for the nested software packages. Because the nested software packages were returned to their original state, a report is not transmitted back to the server.

When an installation completes successfully, and the Historical Database and Change Management Status features are enabled, the configuration repository is updated with the information related to the primary software package and the nested software packages.

Tivoli Software Distribution User’s Guide 331 332 Version 4.1 11 Tivoli Software Distribution Web Interface Interface Web Tivoli 11.

The Web Interface provided with Tivoli Software Distribution, Version 4.1 is in the following forms, both of which support endpoints with UNIX and Windows supported platforms: ¶ Basic functions ¶ Enhanced functions

Note: In this chapter, references to a software package, imply a software package block (built format).

When you install the Tivoli Software Distribution Server, Version 4.1 component, you can use the basic functions of the Tivoli Software Distribution Web Interface, that is, download and install of software packages. When you additionally install the Tivoli Software Distribution Web User Interface Server, Version 4.1 component and the Tivoli Software Distribution Web Interface Depot, Version 4.1, the following enhanced functions are available to you: ¶ Download ¶ Install ¶ Uninstall ¶ Subscribe to software packages ¶ Unsubscribe software packages

Tivoli Software Distribution User’s Guide 333 Tivoli Software Distribution Web Interface

¶ Verify software packages ¶ Subscribe to reference models ¶ Unsubscribe reference models ¶ Synchronize reference models to endpoints ¶ Manage locally installed software packages It is strongly recommended that you use the enhanced functions. To do that, go directly to the section called “Enhanced Tivoli Software Distribution Web Interface Functions” on page 353. See “Planning and Installing Tivoli Software Distribution” on page 23 for more information about installing the enhanced Tivoli Software Distribution Web User Interface components.

Basic Tivoli Software Distribution Web Interface Functions The basic functions of Tivoli Software Distribution Web Interface enables endpoints to do the following: ¶ Selectively install new software applications and data, or update existing software. ¶ Download software packages that were not received at a prior distribution time.

With Tivoli Software Distribution Web Interface, Web users connect to the server, obtain a current list of available Tivoli Software Distribution software package profiles, and retrieve necessary software packages at their convenience.

Web users can install software package blocks using any of the following industry standard Java-enabled Internet browsers: ¶ Netscape Navigator ¶ Microsoft Internet Explorer

Note: Ensure that the Java and Java Script options are enabled in your browser. Packages can be marked for public access or they can be made

334 Version 4.1 Tivoli Software Distribution Web Interface

visible to all target computers in a subscribing profile manager. Web users are able to access packages after authentication according to their Tivoli role. Packages marked for public access can be accessed without authentication. In both cases, Web users are given access to a Web page displaying the available packages. Web users can install these packages by clicking them, which activates a Java applet.

The installation takes place in a disconnected mode, and data is transferred through the available HTTP connection. Package installation status is reported to the Tivoli server at the next Tivoli Software Distribution operation on the target computer, as for other Interface Web Tivoli 11. disconnected operations. Using the enhanced Web Interface change management status is reported immediately.

Not only does this capability free administrators from performing repeated profile distributions to ensure that each endpoint client receives the software, it also provides endpoints access to information or software upgrades between scheduled distributions.

With Tivoli Software Distribution Web Interface, the browser communicates directly with the server oserv, which forwards the request to the Tivoli HTTP daemon (HTTPd). The HTTPd processes the client request and outputs information, in HTML format, about available Tivoli Software Distribution profiles. This information is then displayed on the client browser. For more information about the HTTPd and network communications, refer to the Tivoli Management Framework Planning for Deployment Guide. Enabling Basic Tivoli Software Distribution Web Interface Functions Enabling the basic Tivoli Software Distribution Web Interface functions on an endpoint involves the following steps: ¶ Setting up preliminary Tivoli Software Distribution Web Interface files on the endpoint. Tivoli Management Framework installs these files when a client machine is configured as an endpoint. ¶ Installing support for a Tivoli Software Distribution Web Interface authentication realm. Tivoli Software Distribution

Tivoli Software Distribution User’s Guide 335 Activating Tivoli Software Distribution Web Interface

enables this support when you install Tivoli Software Distribution server on the Tivoli management server (Tivoli server). ¶ Activating user access to Tivoli Software Distribution Web Interface by assigning a Web Interface administration role to a Tivoli administrator. To activate public access, it is recommended that you assign a public Web Interface administrator. You must use the following user ID: v nobody (for UNIX machines, except HP-UX) v tmersrvd (for Windows NT machines and HP-UX). This user ID must be assigned to the user roles on the Tivoli server and the public policy regions.

Creating a Tivoli Administrator for Web Interface To grant Web users network privileges to access Tivoli Software Distribution Web Interface, you must create a Tivoli administrator and add the SD_Web_User role. Enabling access privileges allows Web users to securely connect to the Tivoli server and download Tivoli Software Distribution software package profiles.

After you have installed the Tivoli Software Distribution server, you can use either the Tivoli desktop or the command line to create the Tivoli administrator for Web Interface. When you create this administrator, Tivoli Management Framework sets up an administrator object with access to the Tivoli Software Distribution Web Interface and enables you to add login names to grant access to authorized users. Note that you can specify login access by individual user identifications (UID) or by a common UID that you have set up for a group of users. In either case, you must have a valid set of UIDs for your environment.

The following procedure briefly demonstrates how to create a Tivoli administrator specifically for Tivoli Software Distribution Web Interface. It also shows how to initialize a list of authorized users for this Tivoli administrator. See the Tivoli Management Framework

336 Version 4.1 Creating a Tivoli Administrator for Web Interface

User’s Guide for more information about creating and using Tivoli administrators in your Tivoli management region environment.

The following table provides the authorization roles required to perform this task:

Operation Context Role Create and add users Administrators senior to the Web Interface resource administration role 1 ioiWbInterface Web Tivoli 11.

Desktop Use the following steps to create the Tivoli Software Distribution Web Interface administration role: 1. Create a Tivoli administrator for Tivoli Software Distribution Web Interface. a. Select Create Administrator from the Administrator icon pop-up menu to display the Create Administrator dialog. b. Enter the name of the administration role in the Administrator Name/Icon Label text box. c. Enter a user login name (not a numeric user ID) in the User Login Name text box. The user login name must be a valid login name. To create a public administrator, set the user login name to nobody (UNIX machines, except HP-UX), or tmersrvd (Windows NT machines and HP-UX). d. Enter the administrator’s group name (not a numeric group ID) in the Group Name text box. 2. Set the TMR roles for the administrator that you created in step 1: a. Click Set TMR Roles to display the Set TMR Roles dialog. b. Select the SD_Web_User role from the Available Roles scrolling list, then click the left arrow. This role is moved from the Available Roles scrolling list to the Current Roles scrolling list.

Tivoli Software Distribution User’s Guide 337 Creating a Tivoli Administrator for Web Interface

–OR– Double-click SD_Web_User in the Available Roles scrolling list to automatically move it to the Current Roles scrolling list. c. Click Set & Close to accept your changes and return to the Create Administrator dialog.

Note: Tivoli automatically authorizes all users who are assigned the senior, super, user, and admin roles access to Tivoli Software Distribution Web Interface. For example, if you have assigned psmith with the user role, do not add this user name in the Set Login Names dialog—psmith will be able to access Web Interface from any system with a valid login. 3. Set the login names for users who will be able to access Tivoli Software Distribution Web Interface: a. Click Set Logins. The Set Login Names dialog is displayed. b. To add a login name, enter the user’s login name in the Add Login Name text box, then press the Enter key.

Note: The login name must be a valid user ID in your environment. It is recommended that all login names be qualified for a specific machine. This helps ensure the security and integrity of your distributed system by limiting the locations from which a desktop or command line interface (CLI) command may be initiated.

The new login name is added to the Current Login Names scrolling list. c. If you want to add more than one login, repeat this step for each login that you want to add. d. Click Set & Close to accept your changes and return to the Create Administrator dialog.

338 Version 4.1 Creating a Tivoli Administrator for Web Interface

4. Set the resource role for the administrator that you created in step 1 on page 337: a. Click Set Resource Roles to display the Set Resource Roles dialog. b. In the Resources list box, select the policy region containing the software package to be made available from the Tivoli Software Distribution Web Interface. c. Select the SD_Web_User role from the Available Roles

scrolling list, then click the left arrow. This role is moved Interface Web Tivoli 11. from the Available Roles scrolling list to the Current Roles scrolling list. –OR– Double-click SD_Web_User in the Available Roles scrolling list to automatically move it to the Current Roles scrolling list. Repeat this procedure for each policy region that contains software packages to be made available from the Tivoli Software Distribution Web Interface. d. Click Set & Close to accept your changes and return to the Create Administrator dialog.

Note: In the case of interconnected Tivoli management regions, the system administrator has full control over what Web users of one region are permitted to see in the other region. For example, Web users on Region-A can see the public resources of interconnected Region-B if the administrator of Region-A, with login nobody@hostname (or tmersrvd@hostname), has been assigned the Resource role of SD_Web_User for those policy regions of Region-B that are to be made visible to Web users of Region-A and vice versa.

Command Line To use the wcrtadmin command to create a Tivoli administrator specifically for Tivoli Software Distribution Web Interface, enter the following command: wcrtadmin -l adent -l jchen -l mgarza -l wwarren \ -r @distinguished:SDWebUI,SD_Web_User UserLink

Tivoli Software Distribution User’s Guide 339 Creating a Tivoli Administrator for Web Interface

where: –l adent –l jchen –l mgarza –l wwarren Sets up a Tivoli login for each user specified. The login parameter must be a valid login name—not a numeric user ID. –r @distinguished:SDWebUI,SD_Web_User UserLink Specifies the Web Interface for Tivoli Software Distribution administration role. Enter this parameter exactly as shown to ensure that the authorization is set correctly.

To add login names to the Tivoli Software Distribution Web Interface administrator after creating it, enter the following command: wsetadmin -l tford -l ngupta UserLink

where: –l tford –l ngupta Adds the specified logins UserLink Specifies the name of the Tivoli administrator whose properties you want to change

See the Tivoli Management Framework Reference Manual for information about wcrtadmin and wsetadmin command syntax and usage. Rather than entering each new login name individually through the Tivoli dialog or with the wsetadmin command, you may want to create a script to automate this process.

Configuring Policy Regions The administrator must define profile managers using appropriate names that are displayed as software categories in the Tivoli Software Distribution Web Interface. The administrator has control over the content of the Tivoli Software Distribution Web Interface display. It is recommended that you keep the Tivoli Management Framework environment separate from the Tivoli Software Distribution Web Interface environment by using different policy regions for each environment.

340 Version 4.1 Creating a Tivoli Administrator for Web Interface

The displayed list is empty until an action is enforced on the policy regions. See “Setting the Policy Region Attribute” on page 343.

Policy regions can be the following types: Public No authentication is required to view the content of these regions, although the administrator does need to add the SD_Web_User TMR role to the nobody user login name. Restricted Only users with access rights to restricted regions can view the content of restricted policy regions. Interface Web Tivoli 11. Hidden This is the default. The content of the Hidden policy region is not accessible through the Tivoli Software Distribution Web Interface when the Hidden attribute is set.

Software Package Properties To define the availability of a software package through the Tivoli Software Distribution Web Interface, set the web_view_mode attribute to one of the following values: Public The software package can be installed on the endpoint whether or not the endpoint is subscribed. Subscriber The software package can be installed on the endpoint only if the endpoint is subscribed to the profile manager in which the software package is defined. Hidden This is the default option. A software package is not displayed when the attribute is set to Hidden.

The user is presented with a list of software packages for which a complete image file exists. A complete image file is a package built in the software package block format. See step 5 on page 135 for more information about setting the Web view mode from the Package Properties dialog.

Tivoli Software Distribution User’s Guide 341 Creating a Tivoli Administrator for Web Interface

Notes: 1. Only software packages in the built format can be made available through the Tivoli Software Distribution Web Interface. 2. Software packages that contain nested software packages cannot be made available through the Tivoli Software Distribution Web Interface. Configuring Tivoli Software Distribution Web Interface The administrator must perform the following procedure to correctly configure the Tivoli Software Distribution Web Interface: 1. Decide which policy regions are to be Public or Restricted. 2. Define profile managers in the policy regions. It is important to choose sensible, understandable names for the profile managers, as these names are visible to subscribers. 3. Enable policy regions and their contents for viewing, either by public or restricted subscription. Use the CLI to set and view the policy region access type attribute and also the software package object attribute. For more information about using the CLI to set attributes, refer to the following sections: ¶ “Setting the Policy Region Attribute” on page 343 ¶ “Setting the Software Package Object Attribute” on page 344

Note: It is recommended that Tivoli Software Distribution Web Interface be used to provide software upgrades to existing installed packages, and also to provide small utility packages. Depending on the size of the software package block and connection speed, the transfer of files from the server to the endpoint can potentially be slow. 4. Set the access level for the software package. The default value is Hidden. It is recommended that you initially leave the access level to Hidden while you verify whether the package is built successfully. When the package has been built, set the level to Subscriber or Public accordingly.

342 Version 4.1 Configuring Tivoli Software Distribution Web Interface

A login ID and password must be associated with the Tivoli server and policy regions involved if the access level is set to Restricted.

Setting the Policy Region Attribute Use the wwebrset command to set the policy region access type attribute. The following table provides the authorization roles required to perform this task:

Operation Context Role

Set the policy region Policy region senior Interface Web Tivoli 11. access type attribute

To use the wwebrset command to set the policy region access type attribute, enter the following command. Since this command is a bash script that must be run in the bash environment, precede the command with the string sh: wwebrset regionname accesstype

where: regionname Is the name of the policy region for which the access type attribute is to be set accesstype Is one of the following: ¶ Public ¶ Restricted ¶ Hidden

To use the wwebrget command to view the policy region access type attribute, enter the following command. Since this command is a bash script that must be run in the bash environment, precede the command with the string sh: wwebrget regionname

where:

Tivoli Software Distribution User’s Guide 343 Configuring Tivoli Software Distribution Web Interface

regionname Is the name of the policy region for which you want to view the access type attribute.

The system displays the access type that is currently set for the specified policy region, for example: Access type for PolicyRegion test-region is: "Public"

Setting the Software Package Object Attribute Use the wsetspat command to set the software package object attribute. The following table provides the authorization roles required to perform this task:

Operation Context Role Set the software Software package senior package object profile attribute

To use the wsetspat command to set the software package object attribute, enter the following command. wsetspat -v web_view_mode @spname

where: -v web_view_mode Specifies the value of the web_view_mode attribute, which specifies the access permissions for the software package. The following are the possible values: ¶ public ¶ subscriber ¶ hidden (the default) The web_view_mode attribute can also be set using default policy methods. Refer to the Tivoli Software Distribution Reference Manual for more information about default policy methods. spname Is the name of the software package for which you want to set the software package object attribute.

344 Version 4.1 Configuring Tivoli Software Distribution Web Interface

To retrieve the value of the web_view_mode attribute, use the wgetspat -v @spname command. See the Tivoli Software Distribution Reference Manual for the command syntax and arguments of the wsetspat and wgetspat commands.

You can customize the web_view_mode attribute using the default policy methods explained in the Tivoli Software Distribution Reference Manual. Using the Basic Tivoli Software Distribution Web

Interface Interface Web Tivoli 11. After you have created the administrator for Tivoli Software Distribution Web Interface, authorized (or public) Web users can view and download new or updated Tivoli Software Distribution profiles. Each time new software package profiles are available to Web users, you must instruct them to connect to Tivoli Software Distribution Web Interface.

Web users connect to the Tivoli Software Distribution Web Interface by opening the X:\etc\Tivoli\en_US\userlink.htm file with a Web browser to display the primary UserLink for Tivoli access page.

Tivoli Software Distribution User’s Guide 345 Using Tivoli Software Distribution Web Interface

Note: This illustration shows the English version of the UserLink for Tivoli access page. When instructing users to launch the userlink.htm page, ensure that they are asked to open the correct language-specific file. In this case, including the en_US directory in the pathname launches the English version. Opening the X:\etc\Tivoli\jp_JP\userlink.htm file starts the Japanese version, and so on. See “Enabling Language Support” on page 51 for a current listing of supported languages for this release.

Click UserLink for Tivoli to load information for all UserLink interfaces to Tivoli applications that are installed on the client system.

346 Version 4.1 Using Tivoli Software Distribution Web Interface 1 ioiWbInterface Web Tivoli 11.

Tivoli Software Distribution Web Interface is available by clicking either the Public Software Distribution Web Interface or Restricted Software Distribution Basic Interface link. Clicking one of these links loads the Tivoli Software Distribution Web Interface.

Tivoli Software Distribution User’s Guide 347 Using Tivoli Software Distribution Web Interface

When a Web user selects the restricted link, the browser authenticates the login name and password, and if successful, queries the server and generates a list of both the restricted and public profile managers (software categories). If the Web user selects the Public link, no authentication is performed and a list of public software categories is displayed. The Web user can then install any of the available profiles in the selected software category.

Notifying Users about Web Interface Instruct Web users to complete the following steps to connect to and use Tivoli Software Distribution Web Interface: 1. Connect to Tivoli Software Distribution Web Interface by opening the X:\etc\Tivoli\en_US\userlink.htm file with a Web browser. The primary access page is displayed.

348 Version 4.1 Using Tivoli Software Distribution Web Interface

If you have not already bookmarked the Tivoli Software Distribution Web Interface Web page, create a bookmark so that you can easily and directly access it. 2. Select the public or restricted link to open the secondary access page. This page provides an interface to all Tivoli applications that you are authorized to use. If you select the restricted link, you must log on using your user name and password. Enter your user name and password in the text boxes. If you are unsure about or need to verify your user

name and password, contact your system administrator. Interface Web Tivoli 11. The Tivoli Software Distribution Web Interface Web page is displayed if Tivoli Software Distribution Web Interface successfully connects to the network. 3. Select one of the categories from the Software Category list in the left pane. The list of available software packages for the selected category is listed in the right pane.

Tivoli Software Distribution User’s Guide 349 Using Tivoli Software Distribution Web Interface

The following properties are listed for each software package: Software Package The name of the software package, as defined during its creation. Version The version of the software package available for you to download. Size The size of the software package in bytes. This information is available to the Tivoli Software Distribution Web Interface browser if your system administrator performed an operation to calculate software package size when creating it. Contact your system administrator if this information is not available. Description A description of each software package available for you

350 Version 4.1 Using Tivoli Software Distribution Web Interface

to download. This corresponds to the text entered in the Title text box illustrated on page 125.

An icon is displayed to the left of the software package name. The icon can be either of the following: ¶ An icon with a red slash mark indicates that the software package is not installed on your computer. ¶ An icon with a green check mark indicates that the software package is installed on your computer. It is still possible to download the package, but it will overwrite the current Interface Web Tivoli 11. installation. 4. Select the software package that you want to download by clicking either the icon or the software package link in the software package column. If you click the icon, a message is displayed that asks if you are sure you want to install. Click OK to install, or Cancel to stop the installation. If you click the software package name, a window is displayed that contains details of the software package such as, the size of the package, the estimated download time for the speed of the connection, and a detailed description of the software package.

To download the selected software package, click Install.

Tivoli Software Distribution User’s Guide 351 Using Tivoli Software Distribution Web Interface

The Tivoli Software Distribution Web Interface browser displays the Install Java applet and proceeds with the download and installation of the selected package.

The Install Java applet dialog displays the ongoing status of the installation, then indicates whether the installation completes successfully.

352 Version 4.1 Enhanced Web Interface Functions Enhanced Tivoli Software Distribution Web Interface Functions When you install the Tivoli Software Distribution Web Interface, Version 4.1 on the Tivoli server, the enhanced Web Interface functions are enabled. This interface enables endpoints to do the following: ¶ List all software packages available and selectively download new software applications and data, or update existing software.

¶ Download software packages that were not received at a prior Interface Web Tivoli 11. distribution time. ¶ Install, uninstall, and verify software packages. ¶ If you install the Tivoli Software Distribution Server WEB User Interface Depot Component, you can choose the depot closest to the endpoint’s location to minimize download time. ¶ Receive notifications when software updates are available. ¶ View locally installed software packages. ¶ Manage locally installed software packages using verify and uninstall options. ¶ Select a reference model and install software and data to synchronize the endpoint with the configuration defined in the selected model. ¶ Subscribe to models and receive notices when updates are available. ¶ Immediate update of change management status on the Tivoli server.

Web users can access the Web Interface using any of the following industry standard Java-enabled Internet browsers: ¶ Microsoft Internet Explorer, Version 4.x ¶ Microsoft Internet Explorer, Version 5.x ¶ Netscape Navigator, Version 4.6 or later

Tivoli Software Distribution User’s Guide 353 Enhanced Web Interface Functions

Note: Ensure that the Java and Java Script options are enabled in your browser. Web users are given access to a Web page containing a hierarchical list of software categories that correspond to profile managers. Selecting a profile manager (category) displays a list of available software packages. Packages can be marked for public access or they can be made visible to only target computers subscribed to the profile manager. Web users are able to access packages after authentication according to their Tivoli role. Packages marked for public access can be accessed without authentication.

The installation takes place in a connected or disconnected mode and data is transferred through the available HTTP connection. In connected mode, the Tivoli server is immediately updated with the change management status. In disconnected mode, the change management status is reported to the Tivoli server on the next successive connection to the Web interface or at the next Tivoli Software Distribution operation on the target computer, as for other disconnected operations.

With the enhanced Tivoli Software Distribution Web Interface, the list of software categories and associated software packages is generated by a Java servlet. The browser communicates directly with the Tivoli server oserv, which forwards the request to the Apache HTTPd Web server. The Apache Web server accepts requests from browsers like Netscape and Internet Explorer and then generates dynamic HTML pages and displays the information in the client browser.

You can use the enhanced Tivoli Software Distribution Web Interface not only to install, uninstall, verify, and subscribe to software packages, but also to manage locally installed software packages. Even when no connection is available, with a web browser, you can open the disconmain.htm file located in the LCF directory on the local machine, and perform any of the following operations: ¶ List software packages installed locally. ¶ Manage the local software package blocks repository. ¶ Verify that installed software packages are in the correct state.

354 Version 4.1 Enhanced Web Interface Functions

Enabling Tivoli Software Distribution Web Interface The following section outlines how an environment can be configured to enable Tivoli Software Distribution Web Interface on an endpoint. ¶ Install the Tivoli Software Distribution Server WEB User Interface, Version 4.1 component on the Tivoli server and the Tivoli Software Distribution Server WEB User Interface Depot Component, Version 4.1 on managed nodes to exploit the depot selection capability, as explained in “Planning and Installing Tivoli Software Distribution” on page 23. Interface Web Tivoli 11. ¶ With the installation of the Web Interface, the swd_apm_admin administrator is automatically assigned the SD_Web_Server role. This administrator is automatically created when you install the Activity Planner, a prerequisite to the Web Interface. The SD_Web_Server role enables the methods necessary to retrieve all the information needed to generate dynamic html pages and also to enable access to the port and depot settings. ¶ Assign the SDhttpd_Control role to those users who should have the authority to start and stop the Apache Web server and to perform commands that set the port and depot locations. The root administrator already has this role assigned. ¶ Create an administrator, for example, with the name WebUI, and set the logins to include nobody (for UNIX) or to tmersrvd (for Windows NT and HP-UX) to give users access to public software categories. Edit the TMR roles of the WebUI administrator to include the SD_Web_User role. Edit the Resource roles of the WebUI administrator to include the SD_Web_User role for the policy regions to be made public and that contain software packages that should be made available from the Web interface. ¶ Create an administrator, for example, with the name WebUI-Restr1, and set the login name to an existing user recognized by the operating system. Edit the TMR roles to include the SD_Web_User role and edit the Resource roles to include the SD_Web_User role to allow the user access to the restricted policy regions.

Tivoli Software Distribution User’s Guide 355 Enhanced Web Interface Functions

¶ Set the policy region attribute. ¶ Set the software package object attribute (web_view_mode) for software packages. ¶ Define software category names by setting the SDWebUI_displayname attribute. ¶ Define the depot location information

The following table outlines the configuration of the Web Interface environment.

Administrator TMR Roles Resource Roles Login name root SDhttpd_Control swd_apm_admin SD_Web_Server tivapm WebUI SD_Web_User SD_Web_User (Public nobody or tmersrvd policy regions) WebUI-Restr1 SD_Web_User SD_Web_User (Restricted userid policy regions)

Creating the WebUI and WebUI-Restr1 Administrators The procedure for creating administrator is explained in step 1 of the section “Creating a Tivoli Administrator for Web Interface” on page 336.

Assigning TMR Roles to the WebUI and WebUI-Restr1 Administrators Use the following steps to set the TMR roles for both the WebUI and WebUI-Restr1 administrators to include the SD_Web_User role. 1. From the Create Administrator dialog, click Set TMR Roles to display the Set TMR Roles dialog. 2. Double-click the SD_Web_User role in the Available Roles scrolling list to automatically move it to the Current Roles scrolling list. 3. Click Set & Close to accept the changes and return to the Create Administrator dialog.

356 Version 4.1 Enhanced Web Interface Functions

Assigning Resource Roles to the WebUI and WebUI-Restr1 Administrators Use the following steps to set the Resource roles for both the WebUI and WebUI-Restr1 administrators to include the SD_Web_User role. 1. From the Create Administrator dialog, click Set Resource Roles to display the Set Resource Roles dialog. 2. In the Resources list box, select the policy region containing the software package to be made available from the Tivoli Software Distribution Web Interface. 1 ioiWbInterface Web Tivoli 11. 3. Select the SD_Web_User role from the Available Roles scrolling list, then click the left arrow. This role is moved from the Available Roles scrolling list to the Current Roles scrolling list. 4. Click Set & Close to accept your changes and return to the Create Administrator dialog.

Configuring Policy Regions Policy regions are containers for managed resources such as profile managers. The administrator defines profile managers in the policy region and defines the policy region access type which determines how the information is made available on the Web interface.

Policy regions can be the following types: Public No access rights are required to view the content of these regions. Restricted Only users with access rights to restricted regions can view the content of restricted policy regions. Hidden This is the default. The content of the Hidden policy region is not accessible through the Tivoli Software Distribution Web Interface when the Hidden attribute is set.

The administrator must decide which policy regions are to be Public or Restricted. The procedure for defining the policy region attribute is explained in “Setting the Policy Region Attribute” on page 343.

Tivoli Software Distribution User’s Guide 357 Enhanced Web Interface Functions

For each profile manager defined in a policy region, a corresponding software category is displayed in the Web Interface. The Tivoli Software Distribution Web Interface displays a hierarchical list of software categories that contain software packages that have been made available by the administrator. Software categories correspond to profile managers. The administrator can assign category names different from the profile manager name by setting the SDWebUI_displayname attribute. If this attribute is not set, the web interface displays the profile manager name as the software category name. See “Defining Software Categories” on page 359 for more information about setting and retrieving the software category name.

Software categories are displayed in a hierarchical structure. The administrator determines the hierarchical structure when defining profile managers in the same policy region and the associated subscribers. Each profile manager appears as a root category in the hierarchical structure. Profile managers that have other profile managers defined as subscribers, appear as an expandable category. A small icon beside each software category name indicates whether the software category is expandable. A triangle-shaped icon marks expandable software categories. Categories that do not contain other categories are marked by a diamond-shaped icon. Click the triangle-shaped icon to expand or collapse a category. Selecting a category name displays a list of available software packages.

Software Package Properties To define the access level for a software package, set the web_view_mode attribute to one of the following values: Public The software package can be installed on the endpoint whether or not the endpoint is a subscriber. Subscriber The software package can be installed on the endpoint only if the endpoint is subscribed to the profile manager in which the software package is defined. Hidden This is the default option. A software package is not displayed when the attribute is set to Hidden.

358 Version 4.1 Enhanced Web Interface Functions

The procedure for defining the software package object attribute, web_view_mode, is explained in “Setting the Software Package Object Attribute” on page 344.

Defining Software Categories The name of the software category displayed in the tree is the profile manager name defined by the administrator unless the SDWebUI_displayname attribute has been set. You set the software category name using the wwebprfset command.

The following table provides the authorization role required to Interface Web Tivoli 11. perform this task:

Operation Context Role Set the Administrator resource senior SDWebUI_displayname attribute

To use the wwebprfset command to assign a name to a software category other than the associated profile name, enter the following command. wwebprfset profile_manager SDWebUI_displayname

where: profile_manager The name of the profile manager. SDWebUI_displayname The software category name to be displayed. in the Web interface.

To retrieve the value of the SDWebUI_displayname attribute, use the wwebprfget profile_manager command. The value of this attribute is displayed in the software category hierarchical structure if it has been set.

The following table outlines the roles required to perform Tivoli Software Distribution Web Interface tasks:

Tivoli Software Distribution User’s Guide 359 Enhanced Web Interface Functions

Task Context Role Starting and stopping the Web Administrator resource senior, super, or server SDhttpd_Control Retrieving and setting the port number Retrieving and setting users or groups of users Retrieving and setting the depot location Creating administrators and Administrator resource senior adding users Setting the policy region Policy region senior attribute Setting the web_view_mode Software package profile senior attribute Setting the Administrator resource senior SDWebUI_displayname attribute

Managing the Web Server Only administrators that have been assigned the SDhttpd_Control role have the necessary authorization to manage the Apache Web server. The administrator manages the Web server using the wsdhttpd command.

Refer to the Tivoli Software Distribution Reference Manual for more information about the wsdhttpd command and syntax. Using the Enhanced Tivoli Software Distribution Web Interface After you have created the Web access administrator for Tivoli Software Distribution Web Interface, authorized or public Web users can view and download new or updated software packages and models to which they are subscribed. If a Web user has subscribed to a specific software package or model, each time an update becomes available, the Web user is automatically notified.

360 Version 4.1 Enhanced Web Interface Functions

Web users connect to the Tivoli Software Distribution Web Interface by opening the X:\etc\Tivoli\en_US\userlink.htm file with a Web browser to display the primary UserLink for Tivoli access page. 1 ioiWbInterface Web Tivoli 11.

Click the UserLink for Tivoli link to load information for all UserLink interfaces to Tivoli applications that are installed on the client system.

Tivoli Software Distribution User’s Guide 361 Enhanced Web Interface Functions

Note: If you have installed the enhanced Tivoli Software Distribution Web Interface, Version 4.1, the basic Web Interface is not longer accessible from the UserLink for Tivoli page.

The enhanced Tivoli Software Distribution Web Interface is available by clicking the Enhanced Tivoli Software Distribution Web Interface, Version 4.1 link.

362 Version 4.1 Enhanced Web Interface Functions 1 ioiWbInterface Web Tivoli 11.

This page shows a Web user what updates of software packages and reference models, to which that user is subscribed, have become available since the user last connected to the Web Interface. When you access this page for the first time, you are prompted for a confirmation of the installation of the command line which enables you to perform disconnected commands.

The Web user can select either the Public or Restricted link from the navigation bar to view a list of available software packages that correspond to the Public or Restricted policy regions that the administrator has configured. When a Web user selects the restricted link, the browser authenticates the login name and password, and if successful, queries the server and generates a list of both the restricted and public profile managers (software categories). If the Web user selects the Public link, no authentication is performed and

Tivoli Software Distribution User’s Guide 363 Enhanced Web Interface Functions

a list of public software categories is displayed. The Web user can then select one of the software categories to display the available software packages.

Using the Web Interface With Tivoli Software Distribution Web Interface, Version 4.1, you can perform several tasks that automate the management of software on a local machine, with or without a network connection. Through the Web Interface, you can do the following: ¶ Display a list of software categories containing software packages ¶ Install, uninstall, download, or verify a software package ¶ Subscribe to specific software packages and be automatically notified when an update is made available ¶ View and manage locally installed software packages by verifying and removing them

Downloading, Installing, and Subscribing to Software Packages Instruct Web users to complete the following steps to connect to and use Tivoli Software Distribution Web Interface to download and install software packages, and subscribe the local endpoint to future updates of the software packages: 1. Connect to Tivoli Software Distribution Web Interface by opening the X:\etc\Tivoli\en_US\userlink.htm file with a Web browser. The primary access page is displayed. 2. Create a bookmark for the Tivoli Software Distribution Web Interface Web page to gain ready access to it from now on. 3. Select the UserLink for Tivoli link to display the secondary access page. 4. Select the Tivoli Software Distribution Version 4.1 Web Interface link to display the Web Interface. Each time the Web user connects to the Web Interface, the Updates page is displayed that notifies the user of any updates to software packages and models to which the Web user is subscribed, and

364 Version 4.1 Enhanced Web Interface Functions

has not yet installed. The Web user can access a list of updates at any time by clicking the Updates link. Notes: a. When a new version of a software package becomes available it overwrites the old version. Installing a new version overwrites the previous version if already installed. b. When you subscribe to a reference model, it is only displayed in the Updates page when a subsequent update

occurs. Interface Web Tivoli 11. 5. Select the appropriate navigation bar link to view the software packages available to you, as follows: ¶ Public, if you want to view list of public software categories. ¶ Restricted, if you want to view an authenticated list of software categories. This requires your user ID and password. If you are unsure about or need to verify your user name and password, contact your system administrator. 6. From the expandable list of software categories listed in the left pane of the Web page displayed, select the category you require. The right pane displays a list of available software packages in the right pane for the selected category.

Tivoli Software Distribution User’s Guide 365 Enhanced Web Interface Functions

Icons to the left of the software package name in the table indicate the following: ¶ With a red slash: software package not installed on your system. ¶ With a green check mark: software package already installed on your system. 7. Select the check boxes adjacent to the software packages you want to install, and do one of the following: ¶ Click Save copy to download the software package to the local machine for installing it at a later time. ¶ Click Install & Save copy to do the download and install in one step.

366 Version 4.1 Enhanced Web Interface Functions

¶ To see details about a software package before installing it, click its name. The Software Package Details dialog, which contains this information, is displayed. 8. Click Install to proceed with the installation. The Depot List dialog for the first-selected software package is displayed. 1 ioiWbInterface Web Tivoli 11.

9. From the Depot List dialog, do one of the following: ¶ For the first-selected software package, click OK to confirm the recommended depot selected. ¶ From the option buttons below, select your required depot and click OK. The Web Interface prompts you to decide whether to use the same selected depot for other software packages, if you have selected them for installation. 10. To select a different depot, click No to display the Depot List dialog and make the selection you require. 11. Click Subscribe to subscribe the local endpoint to the selected software packages. Each time the endpoint connects to the Tivoli Software Distribution Web Interface, a check is performed and you are automatically notified if a new version of the same software package has been made available by the

Tivoli Software Distribution User’s Guide 367 Enhanced Web Interface Functions

Administrator. If you reload this page after subscribing to a software package, the software package no longer appears. Click the Subscribed link from the navigation bar to view the software packages to which you are subscribed.

Note: When you subscribe to a software package, and a new version becomes available, installing the new version overwrites the previous version. 12. To view the ongoing status of the operations selected, click Operations Console. The Tivoli Software Distribution Web Interface browser displays the Pending Operations dialog which displays a queue of the operations to be performed. 13. Click Start to begin executing the list of pending operations. The lower pane displays the downloading and installation status of the selected software packages.

Note: If you are using Netscape Navigator, two Java Security dialogs are displayed consecutively asking for approval to grant extra privileges for using the Install Java applet to download and install the selected software package. Click Grant in both cases. The privileges persist until

368 Version 4.1 Enhanced Web Interface Functions

the browser is closed. 1 ioiWbInterface Web Tivoli 11.

From the Pending Operations dialog, you can do the following at any time: ¶ Stop the operation and resume it at a later time ¶ Change the order of execution of the pending operation ¶ Delete a pending operation

Uninstalling a Software Package To uninstall a software package (an installed software package is identified by an icon with a green check mark) perform the following steps from the Tivoli Software Distribution Web Interface: 1. Select the associated check box and click Uninstall. 2. To view the progress of the operation, click Operations Console.

Verifying an Installed Software Package To verify the consistency of a software package already installed locally with the same package available on the Web Interface, perform the following steps from the Tivoli software Distribution Web Interface:

Tivoli Software Distribution User’s Guide 369 Enhanced Web Interface Functions

1. Select the associated check box and click Verify. 2. To view the progress and outcome of the operation, click Operations Console.

Accessing Reference Models From the Tivoli Software Distribution Web Interface, you can subscribe endpoints to reference models, and synchronize the endpoint with defined reference models, as follows: 1. From the navigation bar, select Models. A list of available reference models is displayed in the left pane. An icon against the model name shows whether the endpoint is currently subscribed to it.

Note: Each time you connect to the Tivoli Software Distribution Web Interface, you are notified of any updates to models to which the endpoint is subscribed. 2. In the left pane, select the required reference model. A list of related configuration elements is displayed in the right pane.

370 Version 4.1 Enhanced Web Interface Functions 1 ioiWbInterface Web Tivoli 11.

3. Select Subscribe to subscribe to the selected reference model. Reloading the Models Web page removes the subscribed model from the list of models. Select the Subscribed link from the navigation bar to perform other operations on the subscribed model. 4. Select Synchronize to synchronize the local machine with the reference model definition. A check is performed on the software installed on the local machine and the Depot List dialog displays the operations required to synchronize the local machine with the

Tivoli Software Distribution User’s Guide 371 Enhanced Web Interface Functions

model definition.

5. Click OK to proceed with the synchronization. For more information about change configuration models and how to configure Web subscribers, see “Change Configuration Management” on page 449.

Managing Subscriptions to Software Packages and Reference Models From the Tivoli Software Distribution Web Interface, you can manage subscriptions to software packages and reference models as follows: 1. From the navigation bar, select Subscription.

372 Version 4.1 Enhanced Web Interface Functions 1 ioiWbInterface Web Tivoli 11.

The Web page displays an overview of all software packages and models to which you are subscribed. 2. Select the check boxes of the software packages and models you want to unsubscribe from and for which you want to discontinue notification of updates. 3. Click each Unsubscribe button, as necessary.

Managing the Local Machine from the Tivoli Software Distribution Web Interface In the local machine pages of the Tivoli Software Distribution Web Interface, you can perform software package management operations on the local endpoint, as follows:

Tivoli Software Distribution User’s Guide 373 Enhanced Web Interface Functions

1. From the navigation bar, select Local. A local Web page is displayed.

2. In the left pane, select the link for the operation you want: ¶ Installed Software Packages. The right pane enables you to reinstall, uninstall, and verify locally installed software packages. ¶ Local Depot. The right pane lists software package blocks stored at the local depot, and enables you to perform install, uninstall, and verify operations. ¶ Verify. The right pane enables you to verify that software installed using Tivoli Software Distribution is in the correct state. The tasks that you can perform are outlined on each page.

374 Version 4.1 12 Integrating the Tivoli Inventory Database

Tivoli Inventory is able to scan the machines in your Tivoli management region and gather hardware and software information that it stores in a database called the configuration repository. Tivoli Software Distribution provides two features that automatically update information stored in the Tivoli Inventory configuration repository: Historical database This feature stores the following information: 2 nertn h Tivoli the Integrating 12.

¶ Distribution operations performed on target systems, Database Inventory including the type of operation, the mode, the time it occurred, the result, and the distribution ID ¶ Software names and versions that have been distributed Change management status This feature stores the following information ¶ Names and versions of software packages ¶ Time of the last successful operation ¶ Last known change management state of a software package on a target system ¶ Software packages loaded in depots ¶ Software packages and reference models to which users have subscribed

Tivoli Software Distribution User’s Guide 375 These features store information about Tivoli Software Distribution, Version 4.0 and 4.1 software packages and Tivoli Software Distribution Version 3.6.x file packages, AutoPacks, and file package blocks (fpblocks) that have been installed on or removed from Tivoli clients.

Using the Tivoli Management Framework query facility, you can retrieve information from the configuration repository concerning successful or failed Tivoli Software Distribution operations that have occurred in your Tivoli management region, and the change management status of a particular software package on a specific target. These two features eliminate the need to write scripts to periodically update the configuration repository when software is distributed or removed in your Tivoli environment.

This chapter provides a brief conceptual overview of the Tivoli Management Framework query facility and the configuration repository that Tivoli Software Distribution shares with Tivoli Inventory, Version 3.6.2. It also describes how to enable the Tivoli Software Distribution historical database and change management status features and how to access information from the configuration repository. To use these features, you must have already installed and be familiar with Tivoli Inventory and the Tivoli Management Framework query facility. Refer to the Tivoli Inventory User’s Guide and the Tivoli Management Framework Planning for Deployment Guide for more information about these products.

The Configuration Repository Tivoli Inventory and Tivoli Software Distribution store information in the configuration repository, which is a relational database management system (RDBMS) that holds information about system configurations in your Tivoli environment. Tivoli Inventory provides the scripts necessary to create the configuration repository as well as to install the configuration repository schema.

Tivoli Inventory must be installed before information about distributions can be stored in the configuration repository. Tivoli Software Distribution updates the configuration repository with new

376 Version 4.1 The Configuration Repository

or updated information about software packages, file packages, AutoPacks, and fpblocks that have been distributed to target machines in your environment, and organizes this information in various tables.

Note: The configuration repository is separate from the actual Tivoli object database. For more information about the configuration repository, refer to the Tivoli Management Framework Planning for Deployment Guide and the Tivoli Inventory User’s Guide.

The Query Facility The Tivoli Management Framework query facility, which consists of query libraries and queries, enables you to use Structured Query Language (SQL) query functions to access information stored in the configuration repository. In the Tivoli environment, a query library is used to create and manage Tivoli queries, which specify which view or table to search within the repository and what information to retrieve. A view enables you to access information from one or more tables, and consists of derived instances from a single table or from the relational joining of multiple tables. Tivoli the Integrating 12. netr Database Inventory Tivoli Inventory has several predefined views and queries that you can use to access information from the configuration repository without having to create a specific query library or individual queries. Tivoli Software Distribution provides a script to populate a unique query library, SWDIST_QUERIES, with predefined views, tables, and queries. For more information about the query library and queries, refer to the Tivoli Management Framework Planning for Deployment Guide and the Tivoli Inventory User’s Guide.

Updating the Repository Tivoli Software Distribution stores and updates information in the following tables in the configuration repository: INSTALLED_SW_COMPONENT Stores the history of operations. Specifically, it stores information about the target machine on which an operation

Tivoli Software Distribution User’s Guide 377 The Configuration Repository

or action was performed (such as install, remove, undo, accept, commit), the type and mode of the operation, the time at which this operation occurred, the name of the profile that was distributed, and the result of the operation. A new column, MD2_DIST_ID, has been added to this table which stores a distribution ID for each software package distribution. SOFTWARE_COMPONENT Stores information about software names and versions that have been distributed, and links this information to profile identifications. SOFTWARE_FILEPACK Stores information about software file package identification and relates this information to a file package, AutoPack, or file package block and the source host.

Each of these tables is updated after a successful or unsuccessful operation. Note, however, that not all columns in these tables are necessarily updated after an operation. You can retrieve information from these tables about the results of specific distribution attempts by running the query SWDISTDATA_QUERY against the predefined view SWDISTDATA_VIEW. SD_CM_STATUS Stores information about the names and versions of software packages, the time the last successful action or operation was performed on a software package, and the status of a software package on a particular target machine. The SD_CM_STATUS table is updated only after a successful operation. Running the CM_STATUS_QUERY retrieves software package status information directly from the SD_CM_STATUS table and not through the use of a predefined view. It is possible that the state registered in the SD_CM_STATUS table of a software package on a particular target machine is not consistent with the status recorded in the local target catalog of the same software

378 Version 4.1 The Configuration Repository

package. This inconsistency occurs when an operation is performed using a disconnected command line command. Refer to the Tivoli Software Distribution Reference Manual for more information about disconnected target commands. In this case, the endpoint returns an error to the server signalling a discrepancy and updates the SD_CM_STATUS table with the correct state. The status is also updated after the next subsequent operation. Alternatively, you can use the wsyncsp command to synchronize the status on the server for software packages on specified endpoints with the actual status on the endpoints. Refer to the Tivoli Software Distribution Reference Manual for more information about the wsyncsp command. SD_LOADED_COMP Stores information about the depot, software packages loaded in the depot, base software packages loaded on the depot, the administrator ID for the last load operation, and the execution time for the last load operation. The SD_LOADED_COMP table is updated each time a load or unload operation is performed. Running the SD_LOADED_COMPONENT_QUERY queries the database Tivoli the Integrating 12. for depot information. You can use the wswsprim command Database Inventory to enable/disable access to this table. For more information about wswsprim command usage and syntax, refer to the Tivoli Software Distribution Reference Manual. SWP_SUBSCRIPTIONS Stores information about reference models to which Web Interface users are subscribed. MOD_SUBSCRIPTIONS Stores information about software packages to which Web Interface users are subscribed.

Information about the Tivoli Software Distribution view, query, and tables is provided in the Tivoli Inventory User’s Guide. Tivoli Inventory also provides the Tivoli Inventory Configuration Repository schematic poster, which illustrates table and column associations in the configuration repository.

Tivoli Software Distribution User’s Guide 379 Upgrading the Tivoli Inventory Database Upgrading from Tivoli Inventory, Version 3.6.x or Later Upgrading the Tivoli Inventory database from Version 3.6.x or later, after installing the Historical Database component, involves running one of the scripts located in the $BINDIR/TME/SWDIS/SCRIPTS/ directory. To select the required script for your environment, determine the following: ¶ What database are you using? ¶ Have you upgraded to Tivoli Software Distribution, Version 4.1 using the patch? ¶ Have you performed a fresh install of Tivoli Software Distribution, Version 4.1?

Attention: If you upgraded to Tivoli Software Distribution, Version 4.1 using the patch, ensure that you use the correct script to avoid loss of data stored in the SD_CM_STATUS table. Table 2. Tivoli Inventory Database Upgrade Scripts Database Name Script Name for Upgrade to Script Name for Fresh Install of Version 4.1 Version 4.1 DB2 swdis_db2_upgr_41.sql swdis_db2_upgrade.sql Microsoft SQL swdis_ms_sql_upgr_41.sql swdis_ms_sql_upgrade.sql Server Oracle swdis_ora_upgr_41.sql swdis_ora_upgrade.sql Sybase swdis_syb_upgr_41.sql swdis_syb_upgrade.sql Informix® swdis_infx_upgr_41.sql swdis_infx_upgrade.sql

Running these scripts adds a new text box called state to the INSTALLED_SW_COMPONENT inventory table, changes the existing view to handle this new text box, and creates a new view related to the SD_CM_STATUS inventory table.

The steps for upgrading each type of database are listed in the following sections.

380 Version 4.1 Upgrading the Tivoli Inventory Database

Upgrading a DB2 Database Complete the following steps to run the script that upgrades the DB2 database: 1. Copy the script from the \scripts product directory to a temporary directory in which you can run DB2 on the DB2 server or the RDBMS Interface Module (RIM) host. 2. Create a connection to the DB2 server database before running the script. Issue the following command from the command line: db2 connect to user \ using

where: database_name Specifies the name or alias name of the Tivoli Inventory database. user_name Specifies the name of the user who owns the Tivoli Inventory database.

password Tivoli the Integrating 12.

Specifies the password of the user referred to by Database Inventory user_name. 3. Run the script from the command line. Enter the following command depending on your environment: ¶ Fresh install: db2 -f swdis_db2_upgrade.sql -o -t -z swdis_db2_upgrade.log ¶ Upgrade install: db2 -f swdis_db2_upgr_41.sql -o -t -z swdis_db2_upgrade.log This command runs the script, directs the output to the screen, specifies a semicolon as the delimiter at the end of a statement, and logs the output in a log file named swdis_db2_upgrade.log. The success or failure of the SQL statements is logged in this file.

Tivoli Software Distribution User’s Guide 381 Upgrading the Tivoli Inventory Database

Upgrading a SQL Server Database Complete the following steps to run the script that upgrades the SQL Server database. You must run the script as the RDBMS user tivoli. 1. Copy the script from the \scripts product directory to a temporary directory in which you can run isql on the RIM host or the RDBMS server. 2. From the directory that now contains the script, run the script as user tivoli. Enter the following command, depending on your environment, where password is the RDBMS password that is set for the SQL Server user tivoli: ¶ Fresh install: isql -U tivoli [-P ] \ -i swdis_ms_sql_upgrade.sql -o swdis_ms_sql_upgrade.log ¶ Upgrade install: isql -U tivoli [-P ] \ -i swdis_ms_sql_upgr_41.sql -o swdis_ms_sql_upgrade.log

The output of the script (that is, the success or failure of the SQL statements) is logged to the swdis_ms_sql_upgrade.log file. Upgrading an Oracle Database Complete the following steps to run the script that updates the Oracle database. You must run the script as the RDBMS user tivoli. 1. Copy the script from the \scripts product directory to a temporary directory on the RDBMS server or the RIM host. 2. From the directory that now contains the script, start an SQL*Plus session and log in to the RDBMS server as the RDBMS user tivoli. Enter the following command, where password is the RDBMS password that is set for the Oracle user tivoli: sqlplus tivoli/ 3. To capture the log information into a file, enter the following: spool swdis_ora_upgrade.log 4. In the SQL*Plus session, run the script by entering the following command depending on your environment:

382 Version 4.1 Upgrading the Tivoli Inventory Database

¶ Fresh install: @swdis_ora_upgrade.sql ¶ Upgrade install: @swdis_ora_upgr_41.sql

The success or failure of the SQL statements is logged in the log file. 5. To log out of SQL*Plus, when the script is finished, enter the following command: quit Upgrading a Sybase Database Complete the following steps to run the script that updates the Sybase database. You must run the script as the RDBMS user tivoli. 1. Copy the script from the \scripts product directory to a temporary directory in which you can run isql on the RDBMS server or the RIM host. 2. From the directory that now contains the script, run the script as the user tivoli. Enter the following command, depending on your environment, where password is the RDBMS password that is set Tivoli the Integrating 12. for the Sybase user tivoli: Database Inventory ¶ Fresh install: isql -U tivoli -P -i swdis_syb_upgrade.sql \ -o swdis_syb_upgrade.log ¶ Upgrade install: isql -U tivoli -P -i swdis_syb_upgr_41.sql \ -o swdis_syb_upgrade.log

The output of running the script is stored in the swdis_syb_upgrade.log file. Upgrading an Informix Database Complete the following steps to run the swdis_infx_upgrade.sql script that updates the Informix database. You must run the script as the RDBMS user tivoli.

Tivoli Software Distribution User’s Guide 383 Upgrading the Tivoli Inventory Database

1. Copy the script from the \scripts product directory to a temporary directory in which you can run dbaccess on the RIM host or the RDBMS server. 2. From the directory that now contains the script, run the script as the user tivoli. Enter the following command, depending on your environment, where, database_name is the name of the Inventory configuration repository: ¶ Fresh install: dbaccess @$INFORMIXSERVER swdis_infx_upgrade.sql ¶ Upgrade install: dbaccess @$INFORMIXSERVER swdis_infx_upgr_41.sql

Enabling the Historical Database and Change Management Status Features With the installation of the Tivoli Software Distribution Historical Database component, the historical database and change management status features are automatically enabled, which enables Tivoli Software Distribution to access and update the configuration repository. These features are already available if you installed the Tivoli Software Distribution Historical Database component from the Install Product dialog during the initial installation process. See “Planning and Installing Tivoli Software Distribution” on page 23 for more information about installing the historical database component.

Note: The historical database and change management features require Tivoli Inventory. You must already have Tivoli Inventory installed to complete the following procedures.

Before Tivoli Software Distribution information about target machines can be stored in the configuration repository, you must run an inventory hardware scan on each target machine that will receive software packages, file packages, AutoPacks, and fpblock distributions. An inventory profile scans each target machine and populates the configuration repository with new or updated information about each target.

384 Version 4.1 Historical Database and Change Management Features

Complete the following steps on target machines that will receive software package, file package, AutoPack, and fpblock distributions, but have not been scanned: 1. Create an inventory profile. The Tivoli Inventory User’s Guide describes how to create an inventory profile. 2. Customize the inventory profile to include only a hardware scan. By default, an inventory profile scans the target machine for both software and hardware information. To track Tivoli Software Distribution operations, however, only a hardware scan is needed, and customizing the profile to scan only for hardware configuration data will save time. The Tivoli Inventory User’s Guide describes how to customize an inventory profile. 3. Distribute the inventory profile to each target machine that will receive software packages, file packages, AutoPacks, and fpblocks. For Tivoli Software Distribution purposes, only those target machines for which you want to track distribution information need be scanned. The Tivoli Inventory User’s Guide describes how to distribute an inventory profile to target machines. 2 nertn h Tivoli the Integrating 12.

Disabling the Historical Database and Change Database Inventory Management Status Features You can disable and then enable the historical database and change management status features from the command line to control when distribution information is posted to the configuration repository. The feature is automatically enabled when you install the Tivoli Software Distribution Historical Database component. If you do not need to track distribution statistics, disable these features prior to distributing a software package. Re-enable the features to resume tracking distribution information in the configuration repository.

The following table provides the authorization role required to perform this task:

Tivoli Software Distribution User’s Guide 385 Historical Database and Change Management Features

Operation Context Required Role Disabling and Command line senior or super re-enabling the historical database and change management status features

You can perform this task only from the command line. Enter the following command: sh wswsprim {-c|-d|-s|-v}

where: –c Re-enables the historical database and change management status features. –d Disables the historical database and change management status features. –s Enables the change management status feature and automatically disables the historical database feature with the execution of this command. –v Gives the status of the historical and change management status features.

It is not possible to have the historical database feature enabled and the change management status feature disabled simultaneously. You can, however, choose to have only the change management status feature enabled. For more information about wswsprim command usage and syntax, refer to the Tivoli Software Distribution Reference Manual.

Creating the SWDIST_QUERIES Query Library In the Tivoli environment, a query library facility provides a way to create, manage, and logically organize Tivoli queries. For example, you could create a query library to hold queries that selectively retrieve information about each Tivoli Software Distribution profile type. Tivoli Software Distribution provides a script,

386 Version 4.1 Creating the SWDIST_QUERIES Query Library

swdis_queries.sh, that you can run to automatically install a query library and predefined queries. This script creates the SWDIST_QUERIES query library and populates it with the following predefined queries: SWDISTDATA_QUERY, CM_STATUS_QUERY, SD_LOADED_COMPONENT_QUERY, SWDIST_WEBUI-QUERY.

Run the swdis_queries.sh script in the Tivoli management region from which you want to query the configuration repository. Because queries and query libraries must have unique names in a Tivoli management region, you can have only one set of the Tivoli Software Distribution queries in a Tivoli management region or in a set of interconnected Tivoli management regions. For information about creating additional query libraries and queries, refer to the Tivoli Inventory User’s Guide.

The following table provides the authorization roles required to perform this task:

Operation Context Required Role Create Tivoli Software Policy region senior or super Distribution queries Tivoli the Integrating 12. netr Database Inventory

Complete the following steps to create the SWDIST_QUERIES query library and the Tivoli Software Distribution query: 1. Select the policy region in which you want to create the query library that will contain the Tivoli Software Distribution queries. 2. Add the QueryLibrary managed resource type to the policy region. Refer to the Tivoli Management Framework Planning for Deployment Guide for more information about adding managed resources to a policy region. 3. Copy the swdis_queries.sh script from the $BINDIR/TME/SWDIS/SCRIPTS/ directory to a temporary directory on the Tivoli management region server. 4. From the directory in which the script now resides, log in as a Tivoli administrator.

Tivoli Software Distribution User’s Guide 387 Creating the SWDIST_QUERIES Query Library

5. Run the swdis_queries.sh script by entering the following. Since this is a bash script that must be run in the bash environment, precede the command with the string sh, as follows: sh swdis_queries.sh region name

where: region Specifies the name of the policy region in which the query library will be created. name Specifies the name of the new query library. Specifying a name here is optional; if you do not designate a name, the query library will be named SWDIST_QUERIES.

The new query library is added in the designated policy region as follows:

Running a Query The following steps briefly describe the process of running a query from the SWDIST_QUERIES query library and of saving the query results to standard output or a file.

388 Version 4.1 Running SWDISTDATA_QUERY

The following table provides the authorization role required to perform this task:

Operation Context Required Role Run a query Query library senior or super

You can perform this task from either the Tivoli desktop or the command line. Desktop Complete the following steps to run the predefined query SWDISTDATA_QUERY from the SWDIST_QUERIES query library. (The steps for running the CM_STATUS_QUERY, SD_LOADED_COMPONENT_QUERY, SWDISTDATA_QUERY, and SWDIST_WEBUI_QUERY predefined queries, which also appear in these dialog examples, are similar.) 1. Double-click the SWDIST_QUERIES query library icon to display the SWDIST_QUERIES dialog. This query library contains the predefined query SWDISTDATA_QUERY. The following query library dialog is displayed: 2 nertn h Tivoli the Integrating 12. netr Database Inventory

2. To run this query, right-click the SWDISTDATA_QUERY icon and select Run Query. –OR–

Tivoli Software Distribution User’s Guide 389 Running SWDISTDATA_QUERY

Right-click the SWDISTDATA_QUERY icon and select Edit Query to open the Edit Query dialog. From this dialog, click Run Query. The Run Query dialog is displayed, showing the results of the SWDISTDATA_QUERY in tabular form. The following dialog illustrates a portion of the results that are displayed:

3. You can save the results of the query from the Run Query dialog by completing the following steps: a. On the Run Query dialog, click Export. The Export Query Results dialog is displayed.

b. In the Host text box, enter the name of the machine on which you would like to save the results file. If you do not specify a host name, the file will be saved on the local machine.

390 Version 4.1 Running SWDISTDATA_QUERY

c. In the File text box, enter a directory and name for the query results file. –OR– Click browse (...) to browse the file system. d. Select one of the Delimiter options to specify how to separate entries in the query results file. If you want to use a delimiter other than a comma or a tab, select Custom and enter a delimiter in the text box. e. Select the Print Headers check box if you want the output file to include the query name and the names of the columns. f. Click Save & Close to create the file. Command Line You can use the wrunquery command to run SWDISTDATA_QUERY and either display the results to standard output or save the results to a file. Enter the following from the command line: wrunquery -n -h pescado -f /tmp/query.txt -d ";" / SWDISTDATA_QUERY

where: Tivoli the Integrating 12. netr Database Inventory –n Omits headers from the results file. –h pescado Specifies pescado as the name of the machine on which to store the file. –f /tmp/query.txt Specifies /tmp/query.txt as the location and name of the query results file. –-d ″;″ Specifies a semicolon as the delimiter. SWDISTDATA_QUERY Specifies the name of the query to be run.

For more information about the wrunquery command, refer to the Tivoli Inventory User’s Guide.

Tivoli Software Distribution User’s Guide 391 Modifying SWDISTDATA_QUERY Modifying SWDISTDATA_QUERY As illustrated in the Run Query dialog shown on page 390, SWDISTDATA_QUERY retrieves and posts an extensive list of Tivoli Software Distribution data that includes information about machine name and identification, profile type and identification, source host name, whether the operation completed successfully, and the time of completion.

You can also create a customized query based on the parameters defined in SWDISTDATA_QUERY. Customizing a query enables you to search for more specific information concerning software distributions and removals in your Tivoli environment. An example of how to create a custom query follows. The Tivoli Inventory User’s Guide provides detailed descriptions of how to create, edit, and run queries.

The following example in this section briefly demonstrates how to create a new query that retrieves information about software package installations using the force option. Several of the parameters in SWDISTDATA_QUERY are used in setting up this customized query. To keep the example brief, only text boxes that are specific to customizing this search are described. Refer to the Tivoli Inventory User’s Guide for more detailed instructions and examples.

The following table provides the authorization role required to perform this task:

Operation Context Required Role Edit a query Query library senior or super

You can perform this task from either the Tivoli desktop or the command line. (The steps for editing the CM_STATUS_QUERY predefined query, which also appears in these dialog examples, are similar.) Desktop Complete the following steps to edit SWDISTDATA_QUERY from the Tivoli desktop:

392 Version 4.1 Modifying SWDISTDATA_QUERY

1. In the SWDIST_QUERIES query library, select Query from the Create menu. The Create Query dialog is displayed. 2 nertn h Tivoli the Integrating 12. netr Database Inventory

2. In the Query Name text box, enter Software Packages. 3. In the Description text box, enter Information on software packages installed. 4. Select inventory from the Repository menu.

Tivoli Software Distribution User’s Guide 393 Modifying SWDISTDATA_QUERY

5. In the Table/View Name text box, enter SWDISTDATA_VIEW and click Set. Doing this populates the Available Columns text box. 6. Use the left arrow to move the following columns from the Available Columns scrolling list to the Chosen Columns scrolling list: ¶ TME_OBJECT_LABEL ¶ SOFTWARE_COMPONENT_NAME ¶ INSTALLED_FILEPACK_TIME ¶ MD2_DIST_ID 7. To create the SQL statement to query for software package installations that use the force option, complete the following steps to add a condition in the Where Clause text box: a. In the Column Name text box, enter FILEPACK_TYPE. You can also click browse (...) and select FILEPACK_TYPE from the list of column names. This list displays the columns in the Chosen Columns scrolling list. b. Leave equals (=) as the logical operator. c. Click browse (...) in the Column Value section. Select SOFTWARE_PACKAGE, then click Close. d. Click Add to add the first criteria to the Where Clause text box. e. In the Column Name text box, enter ACTION_COMPLETED. f. In the Column Value text box, enter install (f). g. Click Add to add the second criteria to the Where Clause text box. The Create Query dialog appears as follows:

394 Version 4.1 Modifying SWDISTDATA_QUERY 2 nertn h Tivoli the Integrating 12. netr Database Inventory

8. Click Create to save the query. Click Run Query to query from this dialog. –OR– Click Create & Close to return to the query library window. Right-click the SWDIST_Software_Package icon and click Run Query. Tivoli Inventory returns the following results:

Tivoli Software Distribution User’s Guide 395 Modifying SWDISTDATA_QUERY

Command Line The following example creates the SOFTWARE_PACKAGE_INSTALLATIONS query from the command line: wcrtquery -d "information on software packages installed" \ -r inventory -v SWDISTDATA_VIEW -c TME_OBJECT_LABEL \ -c SOFTWARE_COMPONENT_NAME -c FILEPACK_TYPE \ -c INSTALLED_FILEPACK_TIME -c ACTION_COMPLETED \ -w "(FILEPACK_TYPE='SOFTWARE_PACKAGE')" \ -w "(ACTION_COMPLETED='install (f)')" \ SWDIST_QUERIES SOFTWARE_PACKAGE_INSTALLATIONS

For more information about the wcrtquery command, refer to the Tivoli Inventory User’s Guide.

396 Version 4.1 3 nertn h Tivoli the Integrating 13. nepieConsole Enterprise 13 Integrating the Tivoli Enterprise Console

Tivoli Software Distribution Tivoli Enterprise Console® Integration enables Tivoli Software Distribution to send events to the Tivoli Enterprise Console event server (event server) when a Tivoli Software Distribution operation is performed. In the Tivoli environment, an event is classified as any significant change in the state of a system resource, network resource, or network application. After the Tivoli Enterprise Console integration product is installed, Tivoli Software Distribution automatically generates events based on its operations such as successful or failed distributions or change management operations, and sends these events to the event server. This provides a means for centrally collecting Tivoli Software Distribution events and triggering actions that can be handled the same way as events from other sources or even be correlated with other events.

This chapter explains how to install and enable the Tivoli Software Distribution Tivoli Enterprise Console Integration product component. It also provides a description of the Tivoli Software Distribution event configuration file and event classes. You must be familiar with the Tivoli Enterprise Console application and its manuals, specifically the Tivoli Enterprise Console User’s Guide and the Tivoli Enterprise Console Adapters Guide. These materials provide conceptual and instructional information about events, event adapters, and classes.

Tivoli Software Distribution User’s Guide 397 Integrating the Tivoli Enterprise Console Installation To install and use the Tivoli Software Distribution Tivoli Enterprise Console Integration, Version 4.1 component, you must first have Tivoli Software Distribution, Version 4.1, and Versions 3.6.2 or later of the Tivoli Enterprise Console, and the Tivoli Enterprise Console server, installed in your Tivoli management region. If you are upgrading these products from a previous version, you also must upgrade the RDBMS database installation. Installing a current version of Tivoli Enterprise Console without updating the database may lead to problems with viewing events in the Tivoli Enterprise Console event console (event console). Refer to the Tivoli Enterprise Console User’s Guide for more information about installing and using the event server and console, and about upgrading the RDBMS database.

Before installing and using Tivoli Software Distribution Tivoli Enterprise Console Integration, you must create an event console on the Tivoli desktop, as follows: 1. From the Tivoli desktop, select Event Console from the Create menu. The Create Event Console dialog is displayed.

2. Select the event server on which the event console will reside from the Available Hosts scrolling list, then click Create.An event console icon is placed on the desktop.

Complete the following steps to install and use Tivoli Software Distribution Tivoli Enterprise Console Integration: 1. Follow the directions described in “Planning and Installing Tivoli Software Distribution” on page 23 to install the Tivoli Software

398 Version 4.1 Integrating the Tivoli Enterprise Console Tivoli the Integrating 13. nepieConsole Enterprise Distribution Tivoli Enterprise Console Integration, Version 4.1 component on the event server in the Tivoli management region. Installing the Tivoli Software Distribution Tivoli Enterprise Console Integration component copies the tecad_sdnew.baroc file to the $BINDIR/TME/SWDIS/SPO directory on the host machine. The Tivoli Software Distribution event classes are defined in this file. See “Tivoli Software Distribution Classes” on page 405 for more information about Tivoli Software Distribution event classes. 2. To set a rule base to manage events and to install the Tivoli Software Distribution event classes to the event server, run the swdistecsrvr_inst.sh script on the server where the tecad_sdnew.baroc file is located. The swdistecsrvr_inst.sh script is located in the $BINDIR/TME/SWDIS/SCRIPTS directory. To run the script, that copies the default rule base in the specified directory, enter the following: swdistecsrvr_inst.sh –b –c

where: –b Is a rule base, other than the default rule base, that is created and includes the Tivoli Software Distribution classes. –c Specifies an existing empty directory that is used as a working directory.

Note: If you are using Tivoli Enterprise Console, Version 3.7 or later, the following message is displayed before the script completes: Event group and filter for Software Distribution 4.1 must be created manually.

Unlike previous versions, Version 3.7 or later requires that you create the event group and related filter manually from the Tivoli Enterprise Console. Refer to the Tivoli

Tivoli Software Distribution User’s Guide 399 Integrating the Tivoli Enterprise Console

Enterprise Console User’s Guide for more information about creating event groups and filters. 3. Edit the tecad_sd.conf file as follows to include the event server’s name and any event filtering instructions. This file is installed with Tivoli Software Distribution and is located in the $BINDIR/TME/SWDIS/SPO directory. ####################################################### # # Configuration file for Software Distribution 4.1 # ####################################################### # # Put the event server location here ServerLocation=@EventServer ConnectionMode=connection_oriented ServerPort=0

The tecad_sd.conf file is discussed in greater detail in “The tecad_sd.conf File” on page 402. 4. Select Assign Event Groups from the event console’s icon menu. The Assign Event Groups dialog is displayed.

a. Ensure that the Software Distribution 4.1 event group is listed in the Assigned Event Groups scrolling list. To move this event group, select Software Distribution 4.1 from the Unassigned Event Groups list and click the right arrow.

400 Version 4.1 Integrating the Tivoli Enterprise Console Tivoli the Integrating 13. nepieConsole Enterprise b. Highlight the Software Distribution 4.1 event group in the Assigned Event Group scrolling list and choose the appropriate administration roles. Click Set & Close to save and close this dialog. 5. To view the events sent to this event console, select Monitor from the event console’s icon menu. The Tivoli Enterprise Console window containing the Software Distribution 4.1 event source is displayed.

6. To view the event notices, click the Software Distribution 4.1 event group button. The Software Distribution 4.1 window is displayed.

Tivoli Software Distribution User’s Guide 401 Integrating the Tivoli Enterprise Console

The Software Distribution 4.1 window lists all Tivoli Software Distribution 4.1 events in the scrolling list. These events are described fully in “Tivoli Software Distribution Classes” on page 405.

The tecad_sd.conf File The tecad_sd.conf configuration file for the Tivoli Software Distribution Tivoli Enterprise Console Integration component initially has the following default entries: ServerLocation= ConnectionMode=connection_oriented ServerPort=0

The keywords are as follows: ServerLocation Specifies the keyword @EventServer or a fully qualified identifier if multiple event servers are running in an interconnected Tivoli management region environment. You must set the value of this field after installing Tivoli Software Distribution. To obtain the event server identifier, enter the following command from the command line: wlookup -ar EventServer

402 Version 4.1 Integrating the Tivoli Enterprise Console Tivoli the Integrating 13. nepieConsole Enterprise The following is an example of the output of the command: EventServer 1723798822.2.28#Tec::Server#

The event server identifier in this example is: EventServer.

Refer to the Tivoli Management Framework Reference Manual for more information about the wlookup command. ConnectionMode Specifies the connection mode to use to connect to the event server. Valid values are connection_oriented (or its abbreviations CO and co) and connection_less. The default value is connection_oriented, which specifies that the connection with the event server is maintained for all events sent. A new connection is established only if the initial connection is lost. When connection_less is specified or used by default, a new connection is established (and discarded) for each event that is sent. ServerPort Specifies the fixed reception port number on which the Tivoli Enterprise Console server listens for connection and adapter input. This keyword value should be set to 0 (the default value) on UNIX systems unless the portmapper is not available on the server. If the Tivoli Enterprise Console server is a Windows NT system, the ServerPort should be set to the value of the tec_recv_agent_port entry in the .tec_config file. Refer to the Tivoli Enterprise Console Adapters Guide for more information about the server port specification on Windows NT machines. If the port number is not specified, the value is retrieved by calling the portmapper. ServerPort can contain up to eight values, separated by commas. Specify one port number regardless of the number of ServerLocation values specified; however, if you specify

Tivoli Software Distribution User’s Guide 403 Integrating the Tivoli Enterprise Console

more than one port number, you must specify a corresponding port number for each ServerLocation value. The default is 0.

By default, Tivoli Software Distribution sends all events to the event server. You can optionally specify event filters that indicate which events should not be sent. You can specify as many event filter entries as needed. To do so, you can include a Filter entry in the tecad_sd.conf file, as follows: Filter Specifies how events are filtered. Filter statements are used by the FilterMode entry to determine which events should be discarded. An event matches a Filter statement if each slot=value in the Filter statement is identical to the corresponding slot=value in the event. A Filter statement must contain the event class and can include any other slot=value that is defined for the event class. The format of the Filter statement is: Filter:Class=classname;slot=value;...;slot=value

Each Filter statement must be on, and contained in, a single, 512-character (maximum) line. The Filter statement cannot contain spaces. The class name specified for an event filter entry must match a defined class name. See “Tivoli Software Distribution Classes” on page 405 for a listing of classes for Tivoli Software Distribution.

For example, you can include the following entry in the tecad_sd.conf file to discard all events generated when the removal operation begins. Filter:Class=Remove_Start;

The filtering behavior can be modified by using the environment variable FilterMode. By default, FilterMode is set to OUT. By adding FilterMode=IN to the configuration file, only the events that match the filters are delivered to the event server. Refer to the Tivoli Enterprise Console Adapters Guide for detailed information about filtering.

404 Version 4.1 Integrating the Tivoli Enterprise Console Tivoli the Integrating 13. nepieConsole Enterprise If you make any changes to the tecad_sd.conf file, you must stop and restart the event server for the changes to take effect.

Tivoli Software Distribution Classes The following table lists the class name of all events defined by Tivoli Software Distribution. Specifically, these classes are defined in the tecad_sdnew.baroc file. When you install the Tivoli Software Distribution Tivoli Enterprise Console Integration component and run the swdistecsrvr_inst.sh script, these classes are compiled and included in the event server’s rule base. Use this listing to understand how Tivoli Software Distribution events are mapped to Tivoli Enterprise Console events.

Note: This list of classes is provided for reference only. Do not edit the tecad_sdnew.baroc file.

The following events are defined in the tecad_sdnew.baroc file. Refer to the Tivoli Event Integration Facility User’s Guide for more information about the syntax of .baroc files.

Event Slots Notes SD_Operation_Submitted dist_id By default, severity = sp_name HARMLESS and sub_source op_size = swdist. op_ mode SD_Operation_Started dist_id By default, severity = sp_name HARMLESS and sub_source op_size = swdist. op_ mode SD_Operation_Failed dist_id By default, severity = FATAL sp_name and sub_source = swdist. op_size op_ mode message num_targets failed_targets

Tivoli Software Distribution User’s Guide 405 Integrating the Tivoli Enterprise Console

Event Slots Notes SD_Operation_Sucessful dist_id By default, severity = sp_name HARMLESS and sub_source op_size = swdist. op_ mode message num_targets successful_targets SD_Operation_More_Targets dist_id This class is used when the sp_name target_list in any class causes successful_targets the event to exceed 4 KB. failed_targets This event is generated until sp_name the list of targets is complete. By default, severity = HARMLESS and sub_source = swdist. SD_Operation_Some_Failed dist_id By default, severity = MINOR sp_name and sub_source = swdist. op_size op_ mode message num_targets successful_targets failed_targets

406 Version 4.1 14

Creating and Executing Activity Plans Activity Creating 14. Plans with Activity Planner

The Activity Planner is a Tivoli Software Distribution feature that enables you to define a group of activities in an activity plan, submit the plan to be executed, and monitor the execution of the plan. Activities are single operations that are performed on a set of targets at specified times. Operations can include Tivoli Software Distribution operations and Tivoli Management Framework Task Library tasks.

Activities contained in a plan can have dependencies associated with them which define circumstances under which the activity should be executed. The execution of the operation defined in the activity is performed by the application to which the operation belongs. The group of activities forms the activity plan.

Using the Activity Planner You can use the Activity Planner feature to perform the following tasks: ¶ Manage a group of activities, originating from different applications, as a single activity from a single machine in the network. ¶ Schedule the activity plan to run on a specific day and time, or to be repeated at specific time intervals, days of the week, or

Tivoli Software Distribution User’s Guide 407 Using the Activity Planner

days of the month. See “Scheduling the Activity Plan” on page 430 for detailed information. ¶ Schedule the plan to repeat indefinitely. See “Scheduling Activity Plans to Run Periodically” on page 432 for detailed information. ¶ Schedule activities to run at specific time intervals during the week. See “Scheduling When to Execute an Activity” on page 426 for detailed information. ¶ Set conditions on activities so that the execution of one activity is dependent on the completion result of other activities. See “Conditioning the Execution of Activities” on page 423 for detailed information. ¶ Save activity plans in a database to resubmit them at any future time. See “Saving the Activity Plan” on page 437 for detailed information. ¶ View a list of all submitted activity plans and retrieve information such as completion status of a specific activity plan, activity, or of an activity for a specified target. See “Submitting and Monitoring Activity Plans” on page 439 for detailed information. ¶ Perform operations on activities and activity plans such as cancel, pause, resume and restart. See “Pausing, Resuming, Canceling, and Restarting an Activity” on page 444 for detailed information.

The Activity Planner feature relies on the Scheduler, a Tivoli Management Framework service, to manage time constraints specified in the activity plan. A job is submitted to the Scheduler to carry out the request. When the specified time is reached, the Scheduler performs the related operation. The Scheduler handles time constraints specified by the following parameters in the activity plan: ¶ The activity plan’s start not before time ¶ The activity plan’s complete not after time ¶ The generation of new instances in a recursive plan

408 Version 4.1 Using the Activity Planner

¶ The start at day and time of the activity’s execution window ¶ The suspend at day and time of the activity’s execution window For recursive plans, the Scheduler is responsible for keeping time of the generation of each instance of the plan. However, deleting a job from the Scheduler that represents an instance of a recursive plan, discontinues the recursion of the plan and no further instances are generated.

An activity plan can be defined using the Activity Plan Editor Plans Activity Creating 14. graphical user interface (GUI) or by defining it in a file in XML format using a text editor. The XML file in which the activity plan is defined is called the activity plan definition file. The Activity Plan Editor enables you to save plans to the XML format, and also to open a plan in the XML format into the graphical user interface. Refer to the Tivoli Software Distribution Reference Manual for more information regarding the activity plan definition file.

Activity plans prepared using the Activity Plan Editor can be saved in the following three formats: ¶ Drafts, if they are not yet complete ¶ Templates, if they are complete ¶ XML file

Draft plans and templates are stored in their respective repositories in the activity plan database, but only templates are made available for submission. You use the Activity Plan Monitor GUI to select a saved plan template and submit the plan for execution. When a plan is selected for submission, you can modify previously specified information. Once the plan is submitted for execution, the plan is saved in the submitted state, in the activity plan database, with the information specified at the time of submission. When activity plan (drafts, templates) are in use, they are automatically locked to avoid other users accessing the same plan and overwriting it. The plan unlocks when you open a new plan or exit the Activity Plan Editor GUI. Administrators can submit, monitor, control, and delete submitted activity plans using the Activity Plan Monitor GUI or the command line interface (CLI). Refer to the Tivoli Software

Tivoli Software Distribution User’s Guide 409 Using the Activity Planner

Distribution Reference Manual for more information about performing operations on activity plans using the CLI.

Using the Activity Plan Monitor GUI you can perform the following tasks: ¶ Submit activity plans to be executed ¶ View all submitted activity plans along with their status, start time, and completion time ¶ View the list of activities contained in the plan ¶ View a graphical representation of the plan in the Activity Plan Editor window ¶ For each activity, view the targets (gateways, depots) assigned to it ¶ Perform operations such as pause, cancel, and resume ¶ Restart an activity on an endpoint where the operation was unsuccessful ¶ Delete the status information of a plan from the activity plan database ¶ Launch the Distribution Status Console to monitor and control software distributions submitted using the Activity Planner.

410 Version 4.1 Launching the Activity Planner GUIs

Launching the Activity Planner GUIs You launch the Activity Plan Editor and the Activity Plan Monitor GUIs from the Tivoli desktop. 4 raigAtvt Plans Activity Creating 14.

Launching either GUI displays a login dialog. In this dialog, you specify the following information: 1. In the Host Machine text box, type the name of the host machine on which the Activity Plan Editor or Activity Plan Monitor is installed. 2. In the Login as text box, type an identified user account name for the specified host machine. Ensure that the login user account is a valid Tivoli administrator with the necessary TMR roles assigned. 3. In the Password text box, type the password associated with the specified login user. Activity Planner Roles The tasks you can perform using the Activity Plan Editor, Activity Plan Monitor, and CLI are restricted by the Tivoli management region roles assigned to you. Depending on the operations you are required to perform, you can have one or more of the following roles:

Tivoli Software Distribution User’s Guide 411 Activity Planner Roles

APM_Admin Role With this role, you can perform the following operations: ¶ Display a list of locked plans and unlock plans currently locked. ¶ Map error levels to return codes. ¶ Delete mapping of error levels and reset the default values. ¶ Display the current mapping of error levels. ¶ Start and stop the Activity Planner engine. ¶ Display and change the RIM object name. ¶ Change the user password that enables the Activity Planner engine to function properly. APM_Edit Role With this role, you can perform the following operations: ¶ Import an activity plan into the activity plan database. ¶ Delete an activity plan from the activity plan database. APM_Manage Role With this role, you can perform the following operations: ¶ Submit an activity plan for execution. ¶ Cancel, pause, resume, and restart activities or the activity plan. ¶ Clean up submitted activity plans from the activity plan database. ¶ Remove the status of a submitted activity plan. APM_View Role With this role, you can perform the following operations: ¶ Return a list of activity plans maintained in the activity plan database. ¶ Output an activity plan in the activity plan definition file format.

412 Version 4.1 Activity Planner Roles

¶ Display the status of a submitted activity plan.

Refer to the Tivoli Management Framework User’s Guide for more information about setting Tivoli management region.

Types of Activities An activity plan is a group of operations or tasks performed on a set of targets at a scheduled time. A single operation or task in an

activity plan is called an activity. Activities can perform either Tivoli Plans Activity Creating 14. Software Distribution operations or Tivoli Management Framework Task Library tasks. Activities can also be dependent upon the result of other activities.

The following Tivoli Software Distribution operations are supported: ¶ Change management operations v Install v Remove v Undo v Accept v Commit ¶ Depot management operations v Load v Unload ¶ Data movement operations v Send v Retrieve v Delete

The following Tivoli Management Framework Task Library task is supported: ¶ Execute Task

Activities that perform Tivoli Software Distribution operations are represented in the Activity Plan Editor main window by an icon that displays a box with an inserted CD-ROM.

Tivoli Software Distribution User’s Guide 413 Types of Activities

For information on the properties of these operations and their supported parameters, refer to the commands chapter in the Tivoli Software Distribution Reference Manual.

Activities that perform Tivoli Management Framework tasks are represented in the Activity Plan Editor main window by an icon that displays a timer, a schedule, and a pencil. For more information on Tivoli Management Framework Task Library tasks, refer to the Tivoli Management Framework User’s Guide.

Defining an Activity You define activities using the Activity Plan Editor GUI. When you launch the Activity Plan Editor from the Tivoli desktop the main window of the GUI displays an empty activity plan. You can proceed to define activities in the current activity plan or you can choose to open an existing plan from the File menu. Activities are displayed as icons in the main window and arrows linking activities represent dependencies among the activities. To define an activity, you specify the following: ¶ The name of the activity ¶ A brief description of the activity ¶ The type of operation the activity will perform on a set of targets ¶ Properties related to the type of operation ¶ Targets of the activity (if not specified at the activity plan level) For example, to create an activity that performs the install operation of a software package, complete the following steps: 1. Launch the Activity Plan Editor GUI from the Tivoli desktop by clicking the related icon. The Activity Plan Editor main window

414 Version 4.1 Defining an Activity

is displayed. 4 raigAtvt Plans Activity Creating 14.

2. Select the Activities icon, represented by a box with an inserted CD-ROM, from the Activities tab on the toolbar. This icon represents an activity that can perform Tivoli Software Distribution, Version 4.1 operations. The Activity Properties dialog is displayed.

3. Specify whether the activity is the final activity in the plan. See “Defining the Final Activity” on page 428 for more information. 4. Specify a name that identifies the activity in the activity plan, in the Name of Activity text box or use the default name provided.

Tivoli Software Distribution User’s Guide 415 Defining an Activity

5. Optionally, enter a string of text that describes the activity in the Description of Activity text box. 6. Click the Operation drop-down list to display a list of supported operations, then select Install. See “Types of Activities” on page 413 for a complete list of supported operations. 7. Select Properties to set the install options for the activity.

For more information about the settings in this dialog, see “Install Operation” on page 299. Also, refer to the Tivoli Software Distribution Reference Manual and the online help available from this dialog. 8. In the Software Package text box, enter the name of the software package to be installed or use the browse (...) button to browse your Tivoli environment and select a software package profile from the list of available software packages in your

416 Version 4.1 Defining an Activity

profile manager. 4 raigAtvt Plans Activity Creating 14.

9. Click OK to save the information, close the dialog and return to the Activity Properties dialog. 10. Click OK to save the information and close the dialog. An activity icon appears in the Activity Plan Editor window that represents the activity you have just defined.

Note: When adding new activities to a plan that are very similar to activities that you have already defined, you can copy and paste the activity into the same plan, or different one, to save time and reduce the possibility of errors.

Assigning Targets to an Activity You can assign targets at the activity level or at the activity plan level. However, if you assign targets for each individual activity, you cannot specify targets at the activity plan level. If you assign targets at the activity plan level, the targets apply to all of the contained activities and no other targets can be specified at the activity level. See “Defining the Targets of an Activity Plan” on page 435 for information about assigning targets at the plan level.

Tivoli Software Distribution User’s Guide 417 Assigning Targets to an Activity

Note: When specifying the targets of an activity that performs a load or unload operation, you must use the managed node label and not the gateway label or the operation will fail.

To assign targets to an activity, perform the following steps: 1. Define an activity as explained in “Defining an Activity” on page 414. 2. Right-click the activity icon in the window and select Targets from the pop-up menu. The Add Target dialog is displayed.

In this dialog, you can select how to specify the targets of an activity. You can choose from one of the following ways: ¶ A list of target names ¶ A file name containing a list of target names ¶ An inventory subscriber ¶ A query library subscriber ¶ Variables ¶ A profile manager Specifying a List of Target Names You can specify a list of target names to be the targets of an activity. To specify the targets of an activity using a list of target names, perform the following steps:

418 Version 4.1 Assigning Targets to an Activity

1. Select List of target names from the Target selection type pull-down list. 2. Type in the Insert target text box, the name of the target you want to add in the List of target names box and click Add. Alternatively, click the browse (...) button to open the Select Target dialog. The Select Target dialog enables you to select only those endpoints which are subscribers of the profile managers in your Tivoli environment. To display a list of all available endpoints, click the Target list button to display the List of targets dialog. Plans Activity Creating 14. 3. Click OK to save the changes and close the dialog. Specifying a File Name Containing a List of Targets You can specify the targets of an activity plan by indicating the path to a file containing a list of target names.The target names must be either separated by a comma, or a space, or on a separated line. To specify a file name containing a list of targets, perform the following steps: 1. Select File of target names from the pull-down list. 2. Type the name of the managed node where the file is stored, in the Managed node text box. 3. Type the path of the file on the managed node that contains the list of targets names, in the Path to file text box. 4. Click Refresh to display the content of the file in the File of target names list. 5. Click OK to save the changes and close the dialog. If changes are made to the file subsequent to adding it to the list, click Refresh to update the file contents. Specifying an Inventory Subscriber as a Target You can specify queries that access the Tivoli Inventory configuration database and selects a list of targets as the query result. To specify an inventory subscriber as a target using a Structure Query Language (SQL) query, perform the following steps: 1. Select Inventory Subscriber from the pull-down list.

Tivoli Software Distribution User’s Guide 419 Assigning Targets to an Activity

2. Click SQL panel to display the Define SQL Queries dialog. 3. Select the name of a table or view from the drop-down list to display a list of column names for the selected table. 4. Create an SQL search clause in the where box to specify what information the query should return. Use the table names, column names, and the operator buttons to create the SQL clause. 5. Click Get result to return the information defined in the SQL search clause. 6. Click OK to save the changes and close the dialog. Refer to Tivoli Inventory User’s Guide for more information about SQL queries. Specifying Query Library Subscribers as Targets You can specify a query representing a query library to return a list of possible subscribers from the Inventory configuration repository database. To select a query library from the Tivoli Enterprise object database to retrieve subscribers, perform the following steps: 1. Select Query Library Subscriber from the pull-down list. 2. Click SQL panel to display the Define SQL Queries dialog. 3. Select a query library from the pull-down list. The contents of the query library are displayed in the box. 4. Click Get result to retrieve the list of targets that satisfy the selected query library. 5. Click OK to save the changes and close the dialog. Using Variables to Specify Targets You can specify targets using variables. The list of targets is automatically evaluated at execution time without user intervention. The following list details the supported variables: $(TARGET_LIST) The target names associated with the variable are specified at submission time.

420 Version 4.1 Assigning Targets to an Activity

$(DEPOT_LIST) The targets are the managed nodes configured as depots to which the endpoints, specified in the $(TARGET_LIST) variable, are assigned. $(ORIGINATOR) The node from which the activity plan is submitted.

You can define other variables that can be used to specify targets by selecting the Variables tab from the Plan Properties notebook. See “Defining Variables” on page 436 for more information. Plans Activity Creating 14.

To use a variable to specify the targets of an activity plan, perform the following steps: 1. Select Variables from the pull-down list. 2. Select a variable in the Available variables list and click the right arrow button to move it to the Set variables list. 3. Click OK to save the changes and close the dialog. Specifying a Profile Manager You can specify profile managers as targets of an activity plan. The activities contained in the plan are performed on the subscribers associated with the specified profile manager. To specify a profile manager as the target of an activity plan, perform the following steps: 1. Select Profile manager from the pull-down list. 2. Enter the name of the profile manager in the Profile manager text box or click the browse (...) button to open the Select Profile

Tivoli Software Distribution User’s Guide 421 Assigning Targets to an Activity

Manager dialog.

3. Expand the policy regions in the left pane to display the profile managers. 4. From the Search for Profile Manager box, add the required profile manager to the List of Profile Managers in one of the following ways: ¶ Select a policy region and click the >> button to add all the profile managers contained in that policy region. ¶ Click the switch to the left of the name of the required policy region. The policy region expands to show all the profile managers it contains. ¶ Select the required profile manager and click the > button. 5. To remove a profile manager, select the profile manager name and click Remove. The profile manager is removed from the list. 6. To clear the list, select Clear. 7. Click OK to save the changes and return to the Add Target dialog. The profile that you selected are added to the Profile Manager list. 8. Click OK to save the changes and close the dialog.

422 Version 4.1 Conditioning the Execution of Activities Conditioning the Execution of Activities The execution of an activity can be dependent upon the result of the execution of another activity or activities in the same activity plan.

Assume that an activity plan consists of two activities, Activity A and Activity B. A condition can be set on Activity B, the conditioned activity, related to the outcome of the execution of Activity A, the conditioning activity, that dictates when Activity B is executed on its targets. You can condition the result of the execution of Activity A 4 raigAtvt Plans Activity Creating 14. on all its targets using one of the following classifications: Completion The execution of Activity B is performed when the operation defined in Activity A completes, regardless of whether it completes successfully or with error. Success The execution of Activity B is performed only if the operation defined in Activity A completes successfully with no error. Failure The execution of Activity B is performed if the operation defined in Activity A fails with an error.

The execution of Activity B depends on the completion of Activity A on all of the targets defined in Activity A. The operation specified in Activity B is executed when Activity A has completed execution on all its targets.

A completion percentage of targets can be specified. For example, you can specify to execute Activity B when Activity A has completed executing on 50% of its targets.

For example, to condition the execution of an activity on the successful outcome of another activity on 50% of all its targets, perform the following steps: 1. From the Activity Plan Editor window, create two activities as explained in “Defining an Activity” on page 414.

Tivoli Software Distribution User’s Guide 423 Conditioning the Execution of Activities

2. Right-click the activity on which you want to set the condition and select Condition from the pop-up menu. The Condition dialog is displayed. 3. Select Successful-All from the pull-down list and click Enter. 4. Select the conditioning activity from the List of Activities in the plan. 5. Specify 50% by clicking the down arrow and using the scroll bar to select 50%.

6. Click OK to save the information and close the dialog. The condition is represented by a red line connecting the activities in

424 Version 4.1 Conditioning the Execution of Activities

the Activity Plan Editor main window. 4 raigAtvt Plans Activity Creating 14.

Note: When specifying a condition using a percentage, the conditioned activity might not start when that percentage is reached. This might occur where a single report for the completion of an operation groups many targets together. Even if the number of targets required to satisfy the percentage has been reached, if the report is not sent to the Activity Planner engine promptly the conditioned activity will not start. To obviate this, you can modify the MDist 2 notify_interval parameter of the gateway to return the reports more frequently. Refer to the Tivoli Management Framework Reference Manual for more information about modifying MDist 2 parameters using the wmdist command.

Sorting Activities in Order of Execution You can sort activities in the order in which they are to be executed. Only activities without conditions can be sorted. Conditioned activities have a predefined order of execution and cannot be modified using the Activity Sort dialog.

Tivoli Software Distribution User’s Guide 425 Sorting Activities

To sort the activities contained in an activity plan in order of execution, perform the following steps: 1. From the Activity Plan Editor main window, select Edit→Sort Activity. The Activity Sort dialog is displayed.

2. Select an activity in the list and click the up or down arrow to rearrange the order. 3. Click OK to save the changes and close the dialog.

Scheduling When to Execute an Activity You can schedule activities 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. The execution window enables you to specify a time frame, at the activity level, within which the activity is to be executed. You can specify more than one execution window for each activity. The time refers to the time on the managed node where the plan is created. Notes: 1. An execution window cannot be specified for task-type activities. 2. An execution window must have a duration of at least five minutes.

426 Version 4.1 Scheduling an Activity

3. The period between execution windows must not be less than five minutes.

For example, to limit the execution of an activity to start on Monday evenings at 8 p.m. until Tuesday morning at 6 a.m., perform the following steps: 1. Right-click an activity in the Activity Plan Editor window and select Execution Windows. The Execution Windows dialog is displayed. 4 raigAtvt Plans Activity Creating 14. 2. Click Add to enter the execution time within which the selected activity must be executed. A row is added in the dialog. 3. Double-click the row under the Start day column and select Monday from the drop-down list. 4. Double-click the same row under the Start time column and a clock icon appears. Click the clock icon to display a 24-hour slide bar. Slide the slider to the 20:00 mark to set the start time of the execution for 8 p.m. Click above or below the slider to decrement or increment the time in minutes. 5. Double-click the same row under the Suspend day column and select Tuesday from the drop-down list. 6. Double-click the same row under the Suspend time column and a clock icon appears. Click the clock icon and using the slide

Tivoli Software Distribution User’s Guide 427 Scheduling an Activity

bar, set 06:00 as the suspend time.

7. Click OK to save the information and close the dialog. The activity can be executed only within the specified execution time, Monday from 8 p.m. through Tuesday at 6 a.m. If the activity is running and has not completed by the suspend day and time, the activity is paused and is resumed at the next specified execution time, that is, the following Monday at 8 p.m.

Defining the Final Activity You can define a final activity in the plan that is executed when all other activities in the plan have either completed or have been canceled.

You define a final activity, as follows: 1. Select either the Software Distribution activity icon or the Task Library icon from the toolbar. 2. In the Activity Properties dialog, select the Final activity check box.

428 Version 4.1 Defining the Final Activity

3. Define the final activity, its targets, and execution time is identical to that for other activities.

Note: For final activities, conditioning is not permitted.

Defining the Properties of the Activity Plan An activity plan contains one or more activities to be executed on specified target systems. Activity plans are executed consecutively

according to their execution time and priority. The activities of all Plans Activity Creating 14. plans in submission that are ready to be executed are queued up and performed in order of priority.

To define general information about the activity plan, perform the following steps: 1. From the main window of the Activity Plan Editor, select the Properties icon from the toolbar. The Properties notebook is displayed. The General page is displayed by default.

2. Replace the default name in the Name text box and optionally enter a description in the Description text box. 3. Set a priority on the activity plan by clicking the Priority pull-down list and selecting from the High, Medium, and Low options. The priority setting is the same for all activities contained in the same plan.

Tivoli Software Distribution User’s Guide 429 Defining the Properties of the Activity Plan

4. Specify which of the notification options to use when the execution of the activity plan is complete. The notification options are: ¶ E-mail ¶ Posting a notice to a notice group (the notice group is created during the installation of the product) 5. Enter an e-mail address in the Mail-ID text box. You can specify more than one address by separating the addresses with a comma. For information about configuring a mail server to correctly route e-mail generated by Tivoli Software Distribution, refer to the Tivoli Enterprise™ Installation Guide. The Post notice check box is selected by default. 6. Select the Submit paused check box to submit the plan in paused state. The execution of the plan begins when a release is performed. Scheduling the Activity Plan You can schedule to execute an activity plan one time only, or you can specify that the activity plan be executed on certain days of the week, month, or at a date or time interval. If an execution time is not specified for the activity plan, the activity plan is performed at the time it is submitted.

Scheduling Plans to Execute within a Time Interval You can schedule an activity plan to start not before and complete not after a specified time. If the execution of the plan has not completed by the specified complete not after time, you can optionally cancel any outstanding activities and stop the execution of the plan. The time reference refers to the time on the local machine where the plan is created.

For example, to schedule an activity plan to be executed not before October 20, 2001 at 7:00 a.m. and to complete by December 31, 2001 at 12 midnight, perform the following steps: 1. Select the Execution Time tab from the Plan Properties notebook.

430 Version 4.1 Scheduling the Activity Plan

2. Select the Start not before check box. The current date and time is displayed. 3. Click the Calendar icon and set the date in the calendar displayed. 4 raigAtvt Plans Activity Creating 14.

4. To modify the time, click the clock icon then use the slider to set the time. Click above or below the slider to decrement or increment the time in minutes. 5. Select the Complete not after check box and set the date and time to December 31, 2001 at 12 midnight.

Note: If you specify frequency information, you cannot specify a complete not after time.

If the activity plan does not complete within the complete not after time specified, you can cancel all activities in execution by selecting the Cancel at cutoff check box. If you do not select this check box, the complete not after time specified is ignored for those activities already in execution and any outstanding activities not yet executed are canceled.

Tivoli Software Distribution User’s Guide 431 Scheduling the Activity Plan

6. To interrupt the execution of the activity plan should an error occur during the execution of an activity, select either Warning, Error,orFatal from the Stop on error drop-down list. If the activity completes with an error level equal to or greater than the error specified, the activity plan is stopped.

Note: Because Tivoli Software Distribution return codes differ from those generated internally by Activity Planner, to ensure that the plan stops if an error occurs, set the stop on error option to warning. Alternatively, use the wseterrlev command to map a return code of 1 to either error or fatal. Refer to the wseterrlev command in the Tivoli Software Distribution Reference Manual for information about mapping return codes with error levels.

Scheduling Activity Plans to Run Periodically An activity plan can be scheduled to run more than once. You can specify to repeat the execution of a plan in days, months, at a specific date interval, or a time interval. When you specify to execute an activity plan recursively, each time the plan is executed, an instance of the plan is submitted for execution. The reference point from which the recursion begins is the start not before time specified on the Execution Time page. See “Scheduling Plans to Execute within a Time Interval” on page 430 for information about setting the start not before time. If the start not before time is not specified, the point of reference is the time the plan is submitted. The time reference is the time on the local machine where the plan is created.

For example, to schedule an activity plan to run every Tuesday, perform the following steps: 1. From the main window of the Activity Plan Editor, select the Properties icon from the toolbar. The Properties notebook is displayed.

432 Version 4.1 Scheduling the Activity Plan

2. Select the Frequency tab. The Frequency page is displayed. 4 raigAtvt Plans Activity Creating 14.

3. Select the Days of the week radio button and enter 1 in the text box. The days of the week are expressed by the numbers 1 through 7, 1 represents Sunday. 4. To dynamically recalculate the list of targets each time an instance of the activity plan is submitted, select Dynamic from the Targets resolution drop-down list. If you select Static, the list of targets calculated when the first instance of the plan is submitted is used for each successive instance submitted.

Note: If you specify frequency information, you cannot specify a complete not after time on the Execution Time page.

Interrupting the Recursion of an Activity Plan You can interrupt the recursion of an activity plan in the following ways: ¶ Specifying an expiration date on which to stop the recursion. ¶ Specifying to stop the recursion when an instance completes in error.

Tivoli Software Distribution User’s Guide 433 Scheduling the Activity Plan

¶ Specifying to stop the recursion if an overlapping of instances occurs. ¶ Deleting the job from the Tivoli Management Framework Scheduler. ¶ Using the wcntpln command. Refer to the Tivoli Software Distribution Reference Manual for the command usage and syntax.

From the Frequency page, you can discontinue the recursion mechanism by checking the expiration date check box and specifying a date on which the recursive submission of an activity plan instance should stop. To specify an expiration date to stop the recursion, perform the following steps: 1. Select the Frequency tab. The Frequency page is displayed. 2. Click the calendar and clock icons and set the date and time respectively, to the required expiration date. If an expiration date is not specified, from the command line interface, use the wcntpln command to stop the recursion mechanism. Refer to the Tivoli Software Distribution Reference Manual for more information about the wcntpln command.

To specify an error level to stop the recursion, when an error occurs, perform the following steps: 1. Select the Frequency tab. The Frequency page is displayed. 2. From the Stop on error drop-down list, specify the required error level. The recursion will stop if the plan executes with an error equal to or greater than the value you specify.

434 Version 4.1 Scheduling the Activity Plan

Refer to the wseterrlev command in the Tivoli Software Distribution Reference Manual for information about mapping return codes with error levels.

No two instances of the same recursive plan can be active at the same time. For example, if Instance A of the recursive plan is currently in execution and Instance B is due to be executed, you can choose to do one of the following: ¶ Leave the Stop on overlap check box unchecked to continue with Instance A and skip Instance B and all successive instances Plans Activity Creating 14. (Instance C, D, E, and so on) until Instance A has completed. Instance B is executed at the next scheduled repeat following the completion of Instance A. ¶ Select the Stop on overlap check box to allow Instance A to complete, the instance actively in execution, but to discontinue the recursion mechanism. Defining the Targets of an Activity Plan You can specify targets at the activity plan level or at the activity level. If the targets are specified at the activity plan level, then the operations defined in the contained activities are executed on these targets. Targets cannot be specified at the activity level if they have been specified at the activity plan level. See “Assigning Targets to an Activity” on page 417 for more information.

To assign targets to the activity plan, perform the following steps: 1. From the main window of the Activity Plan Editor, select the Properties icon from the toolbar. The Plan Properties dialog is displayed. 2. Select the Target tab. The Target page is displayed. 3. Select how to specify the targets of an activity plan.You can choose from one of the following ways: ¶ A list of target names. See “Specifying a List of Target Names” on page 418.

Tivoli Software Distribution User’s Guide 435 Defining the Targets of an Activity Plan

¶ A file name containing a list of target names. See “Specifying a File Name Containing a List of Targets” on page 419. ¶ An inventory subscriber. See “Specifying an Inventory Subscriber as a Target” on page 419. ¶ A query library subscriber. See “Specifying Query Library Subscribers as Targets” on page 420. ¶ Variables. See “Using Variables to Specify Targets” on page 420. ¶ A profile manager. See “Specifying a Profile Manager” on page 421. Defining Variables You can define variables and then use them in your activity plan to refer to a list of targets or gateways. Variables you define in this dialog appear as Available variables in the Add Target dialog when you select to specify targets using variables. See “Using Variables to Specify Targets” on page 420 for more information about defining targets using variables. For example, to define a list of gateways and the targets assigned to those gateways using the Activity Plan Editor, perform the following steps: 1. From the main window of the Activity Plan Editor, select the Properties icon from the toolbar. The Plan Properties dialog is displayed.

436 Version 4.1 Defining Variables

2. Select the Variables tab from the Properties notebook. The Variables page is displayed. 4 raigAtvt Plans Activity Creating 14.

3. Click Add to add an empty row to the Variables list. 4. Click the row under the Name column and type the name of the gateway list, such as, gw_list. 5. Click the same row under the Value column and type a list of gateway names separated by a comma, for example, gw1, gw2, gw3. 6. Click OK to save the changes and close the dialog.

Saving the Activity Plan Saving an activity plan saves it directly to the activity plan database. The activity plan database is a database used to maintain information on activity plans. To save an activity plan prepared using the Activity Plan Editor, select the Save as option from the File menu. The Save as option shows the following three options: Draft This option saves the activity plan as a draft in the activity plan database. Template This option saves the activity plan as a template in the activity plan database.

Tivoli Software Distribution User’s Guide 437 Saving the Activity Plan

XML file This option opens the Save as XML file dialog.

An activity plan saved as a template can be accessed using the Activity Plan Monitor GUI and submitted for execution. The plan is then stored in a submitted state in the activity plan database. Only plans stored as templates or plans in the submitted state can be accessed from the Activity Plan Monitor GUI. Using the Activity Plan Editor, you can reopen saved activity plan templates and drafts and modify them and save them back to the database.

Removing Activity Plans or Activities You can remove an activity plan draft or template that has been saved to the activity plan database by performing the following steps: 1. In the Activity Plan Editor, select Edit→Delete Plan. The Delete Plan dialog displays a list of draft plans and plan templates saved to the activity plan database. 2. Select a draft plan or template plan from the Delete Plan dialog. 3. Click Delete Plan. 4. Click OK to save the changes and close the dialog.

Note: This procedure removes the template from the activity plan database but not submitted plans and their status. To delete submitted plans and their status, use the Activity Plan Monitor GUI or the wdelstat command explained in the Tivoli Software Distribution Reference Manual. See “Deleting Submitted Activity Plans” on page 446.

To remove an activity from an activity plan that is currently in preparation, perform the following steps: 1. Select the activity to be removed from the Activity Plan Editor window. 2. From the Edit menu, select Remove Activity.

438 Version 4.1 Submitting and Monitoring Activity Plans Submitting and Monitoring Activity Plans The Activity Plan Monitor window displays a list of all submitted activity plans and their current status in table format. Each table row contains an expandable activity plan and each column displays a particular activity plan attribute.

The upper pane of the window displays a list of submitted activity plans. In this view, the following information is displayed:

¶ A list of submitted plans Plans Activity Creating 14. ¶ The activities contained within each plan ¶ Target information ¶ Recursion information ¶ Status of the plan ¶ Status of each activity in the plan ¶ The status of an activity on a particular target ¶ The start date and time of the plan ¶ The complete date and time of the plan completed A toolbar displays icons that enable you to select directly the same functions available from the menu bar.

To view the activities contained within an activity plan, click the expand icon to the left of the plan name. To view the targets assigned to the activity and the status of the activity on that particular target, click the expand icon to the left of the activity. You can optionally select to group targets by gateway by selecting View→Target Grouping.

Note: If an activity defined in the activity plan installs a software package with the roaming endpoints option selected, and you select to group the targets by gateway, the Activity Plan Monitor displays the original gateway of the endpoint and not the gateway to which it migrates.

Tivoli Software Distribution User’s Guide 439 Submitting and Monitoring Activity Plans

To view a graphical representation of the activity plan in the Activity Plan Editor window, perform the following steps: 1. Select a plan from the Activity Plan Monitor window. 2. Select View → Activity Plan from the menu. Activity Plan Status Activity plans and activities can have any of the following intermediate statuses: ¶ Successful ¶ Started ¶ Waiting ¶ Canceled by condition ¶ Paused ¶ Cancel pending

440 Version 4.1 Activity Plan Status

¶ Canceled ¶ Failed The final status of an activity plan can be any one of the following: ¶ Successful ¶ Failed ¶ Canceled

To view detailed information about an activity plan, including status, Plans Activity Creating 14. select the plan in the upper pane of the window and the pie chart icon on the toolbar. The lower pane displays the detailed information in list form as a pie chart.

To view information about a specific activity or an activity on a specific target, select the activity or target in the top pane and click the pie chart icon on the toolbar. The upper pane displays detailed information about the selected item in the top pane. Submitting an Activity Plan When submitting an activity plan, you select from a list of template plans. To submit an activity plan, perform the following steps: 1. Select Plans→Submit from the menu of the Activity Plan Monitor window,. The Select plan for submission dialog is displayed.

The dialog displays a list of plans saved as templates in the activity plan database.

Tivoli Software Distribution User’s Guide 441 Submitting an Activity Plan

2. Select a plan in the dialog and click OK. The Plan Submission Parameters notebook is displayed. This notebook is the same as the Plan Properties notebook used during the preparation of an activity plan using the Activity Plan Editor, except that target information cannot be specified. For more information about the pages of this notebook see the following sections: ¶ General. See “Defining the Properties of the Activity Plan” on page 429. ¶ Execution Time. See “Scheduling Plans to Execute within a Time Interval” on page 430. ¶ Frequency. See “Scheduling Activity Plans to Run Periodically” on page 432 ¶ Variables. “Defining Variables” on page 436. The General page is displayed by default.

Before submitting the plan for execution you can edit the attributes that were defined at the time the plan was created. Using the notebook, you can modify the following plan attributes:

442 Version 4.1 Submitting an Activity Plan

¶ Plan name

Note: If you do not specify a plan name in the Name text box, the name of the plan is generated at submission time in the format: name@submission_date submission_time ¶ Priority level ¶ Execution time

¶ Recursion information Plans Activity Creating 14. ¶ Expiration information ¶ User defined variables When you have finished, click OK to save the changes and close the Plan Submission Parameters notebook.

The plan is submitted for execution. An entry of the submitted plan is added to the upper pane of the Activity Plan Monitor window from where the status of the plan and its activities can be monitored. Notes: 1. When the Activity Planner executes an activity, the role required to run the operation defined in the activity is compared with the information of the administrator who initially submitted the plan containing the executing activity. This ensures that the administrator who initially submitted the plan still exists and that administrator authorization has not been lowered. If the administrator who initially submitted the plan no longer exists, or no longer has the authorization necessary to run the operation requested in the activity, the execution will fail when it is run. 2. If after submitting an activity plan for execution, an entry of the submitted plan does not appear in the upper pane of the Activity Plan Monitor window, an error has occurred while the Activity Planner engine was preparing the plan for submission. For example, a problem may occur trying to resolve target information specified in the plan. Check the log file to determine the problem.

Tivoli Software Distribution User’s Guide 443 Pausing, Resuming, Canceling, and Restarting

Pausing, Resuming, Canceling, and Restarting an Activity You can use the Activity Plan Monitor to pause, resume, cancel, and restart an activity. You select an activity contained in the list of activity plans from the Activity Plan Monitor window and select either the Pause, Resume,orCancel option from the Selected menu. Depending on the current state of the activity, only valid options are selectable. Pause Pauses the execution of an activity. For activities not yet executed, the activities are paused. For activities executed but not yet complete, the pause is managed by the application to which the activity belongs. For activities of the type Task, the pause option is not activated. Resume Resumes the execution of all activities in the activity plan that are in the paused state. For activities of the type Task, the resume option is not activated. Cancel Cancels the selected activity even if it is in execution and has not completed. The activity is canceled by the application to which it belongs. For example, for an activity related to a Tivoli Software Distribution operation, the activity is canceled by the MDist 2 service. For activities that have not yet been executed, the Activity Planner engine performs the cancel operation. For activities of the type Task, the cancel option is not activated. Restart Restarts the execution of activities in an activity plan that failed on targets of a previous execution. The activities are restarted only on the targets that failed. Launching the Distribution Status Console The Distribution Status console enables you view the status of distributions, such as which targets receive a distribution and which ones experience errors. You also can pause, resume, cancel, or delete

444 Version 4.1 Launching the Distribution Status Console

a distribution if, for example, you encounter unavailable targets, failed installations, or network outages.

You can launch the Distribution Status console from the Activity Plan Monitor window to monitor and control Tivoli Software Distribution operations defined in an activity. To launch the Distribution Status console, select View →Activity Progress from the menu.

Note: If you perform operations (pause, cancel, resume) from the Plans Activity Creating 14. Distribution Status console or using the wmdist command on Tivoli Software Distribution operations defined in an activity, the Activity Planner is not able to detect that an operation has occurred and the status displayed in the Activity Plan Monitor window is not consistent with the distribution status. For example, if you cancel an operation using wmdist –c, the distribution status is canceled, but the status reported in the Activity Plan Monitor is failed.

Refer to the Tivoli Management Framework User’s Guide for more information about the Distribution Status console. Updating the Status of an Activity Plan You can set the Activity Plan Monitor to automatically update and display the current status of all plans and activities, or have the Activity Plan Monitor update upon request. The data displayed in the window is reloaded with the current date in the activity plan database. For example, to automatically update the Activity Plan Monitor window every 2 minutes and 40 seconds, perform the following steps: 1. From the View menu, select Automatic Update. The Automatic Update dialog is displayed. 2. Select the Enable Automatic Update check box. 3. Drag the slider horizontally to the 2 minutes and 40 seconds position on the bar. 4. Click OK to save the information and close the dialog.

Tivoli Software Distribution User’s Guide 445 Updating the Status of an Activity Plan

To update the Activity Plan Monitor at any time, select Refresh from the View menu. Deleting Submitted Activity Plans Using the Activity Plan Monitor, you can delete the status of a submitted plan, or a specific instance of a recursive plan that has completed, from the list of activity plans displayed in the main window of the Activity Plan Monitor.

To delete the status of a submitted plan or the instance of a recursive plan, select a plan from the Activity Plan Monitor main window that has completed, then select Selected→Delete. Cleaning Up the Database To eliminate plans from the activity plan database that have been submitted and completed, you can use the Activity Plan Monitor to schedule a cleanup operation. You can use the force option to eliminate plans in states other than completed states. Cleanup operations can be scheduled to occur at any of the following times: ¶ Immediately ¶ One time only on a specific day and at a specific time ¶ Particular days of the week ¶ Particular days of the month ¶ A date interval ¶ A time interval

To define the plans you want to remove, you can specify any of the following options: ¶ Plans with a particular status (canceled, failed, successful) ¶ Days elapsed since plans completed ¶ Days elapsed since plans started ¶ Plans with a specific age

446 Version 4.1 Cleaning Up the Database

When all the clean up parameters have been set, the Activity Plan Monitor relies on the Tivoli Management Framework Scheduler to perform the cleanup.

Define this example cleanup of all plans in the activity plan database that have completed successfully, as follows: ¶ Days completed: at least 30 ¶ Cleanup frequency: every 15 days

¶ Start date: March 20, 2001 Plans Activity Creating 14. ¶ Start time: 8 a.m.

To do the cleanup, perform the following steps: 1. From the Activity Plan Monitor main window, select Settings→Clean Up to display the Clean up Properties dialog. The Frequency page is displayed by default.

2. In the Recursion type section, select the Date interval radio button and in the text box below, enter 00/00/15. This specifies to perform the cleanup every 15 days. 3. In the Execution Time section, select the Start date check box.

Tivoli Software Distribution User’s Guide 447 Cleaning Up the Database

4. Click the Calendar icon and set the date in the calendar displayed. 5. Select the Rules tab to display the Rules page.

6. In the text box below Days elapsed since plan started/completed, enter 30. 7. In the Reference Time section, select the Completed radio button. 8. In the Status section, deselect the Canceled check box and select the Successful check box. 9. Click OK to save the settings and close the dialog.

448 Version 4.1 15 Change Configuration Management

Change Configuration Management (CCM), together with the Activity Planner, supports software distribution management and change management in a large network. It does this by managing the workstations of specified groups of users as single entities.

The core concept of CCM is the reference model. Using CCM, you can create reference models where you define the hardware and software requirements of different groups of users, for example, Configuration Change 15. managers and software developers. You then specify the subscribers

to each group. The subscribers are the workstations used by the Management members of the groups. This allows you to manage workstations according to the role each plays within your organization.

Once you have created the reference model, you can generate an activity plan that includes all the tasks required to ensure that the subscribers match the requirements you defined for each group in the reference model.

If there is a change to requirements, or if a subscriber changes its role, you can simply update the reference model to reflect the changes and generate a new activity plan.

CCM also provides a classification of the relations between software applications to prevent definition or enforcement of incorrect configurations at the server and at the client.

Tivoli Software Distribution User’s Guide 449 Change Configuration Management

This chapter provides the following: ¶ Explanations of the concepts involved in CCM. See “Reference Models” on page 450 and “Subscribers” on page 452. ¶ A description of an example reference model. See “Reference Model Example” on page 453. ¶ Instructions on how to work with the CCM interface. See “Using CCM” on page 456.

Reference Models The reference model is the core concept of CCM. Independently of any specific workstation, it provides a profile of a desired configuration to which workstations can subscribe.

A reference model is normally made up of several reference models arranged in a hierarchy. At the top level is the parent reference model, which defines requirements that are inherited by all child reference models within the hierarchy. Each child reference model defines further requirements that can supplement, override, or block the requirements defined in the parent model.

You define the software and hardware requirements by adding configuration elements to a reference model. CCM includes the following types of configuration element: ¶ SWD elements, which allow you to define the desired state (change management status) of a specified software package. ¶ Inventory elements, which allow you to specify hardware prerequisites.

For SWD elements, you select a software package and define the state, for example, IC, that you require. For a full description of the use of software package states, refer to the chapter “Understanding Change Management Operations” in the Tivoli Software Distribution Reference Manual.

450 Version 4.1 Reference Models

You can also make any changes required for the element dependent on the state of another software package. Dependencies can be defined as the following: ¶ Prerequisites, where you define a condition that must be met before the changes required to bring the subscribers to the state specified in the SWD element can be made. For example, for a software package to be installed a prerequisite package must already be installed on the target. ¶ Exrequisites, where you define a condition that prevents the changes required to bring the subscribers to the state specified in the SWD element. For example, a software package will only be installed on targets where an exrequisite package is not installed. ¶ Corequisites, where the changes specified in another SWD element must be made as part of the sequence that includes the SWD element you are defining. For example, if you want to install a package and then install patches for the package, you must include the patches as corequisites for the element that specifies the base package. In this way, the base package is installed first and then the corequisite patches are installed. If you specify the patches as Configuration Change 15. separate SWD elements, the patches cannot be installed, as CCM

cannot determine the actions necessary to install them on the Management targets until the base package has been installed.

For Inventory elements, you define an expression that includes a hardware property selected from one of the Inventory tables. For example, Physical_Memory >= 131072.

Once the reference models have been defined, you can select the workstations that are to be subscribers to the model.

CCM includes a differencing mechanism that compares the current configuration of the subscribers with the desired state defined in the configuration elements of the reference model. The differencing mechanism produces an activity plan that includes all the actions

Tivoli Software Distribution User’s Guide 451 Reference Models

necessary to bring each subscriber to the required state. From the CCM GUI, you can submit the plan to the Activity Planner for scheduling.

Subscribers The subscribers to a reference model are software distribution targets. They are the workstations to which the profile defined in the model is to be applied. CCM provides the following methods of selecting subscribers: ¶ Specifying a .csv file that contains a comma-separated list of the targets to be included. ¶ Specifying a profile manager. The targets that subscribe to the specified profile manager subscribe to the reference model. ¶ Specifying individual targets. ¶ Defining an SQL query on the Tivoli Inventory configuration database. The targets that match the query are the subscribers to the reference model. ¶ Selecting a query representing a query library to return a list of possible subscribers from the Inventory configuration repository database.

You can build the list of subscribers to a reference model using one or more of these methods. Each entry in the subscribers list can specify to include or exclude the identified targets. So, you could define a query to include targets and then specify individual targets that must be excluded if they are returned by the query.

For all the methods except specifying individual targets, the list of subscribers is obtained when the differencing mechanism is used to create an activity plan. Web Subscribers You can also use all the methods listed in “Subscribers” to create Web subscribers. Assigning a Web subscriber to a reference model makes the model accessible from the Web Interface. See “Tivoli

452 Version 4.1 Web Subscribers

Software Distribution Web Interface” on page 333 for more information about the Web Interface.

Note: Ensure that when assigning a Web subscriber to a reference model, the model does not contain nested software packages. The Web Interface is not able to manage models that contain nested software packages.

The actions needed to bring a Web subscriber target to the desired state are not submitted as an activity plan. Instead, you use the Web Interface on the subscriber workstation to select the reference model and execute the required actions.

The Web Interface does not support some of the options for desired state that are supported for activity plans. The only desired states that can be used for Web subscriber are IC (installed and committed) and RC (removed and committed).

Reference Model Example In the example organization, Enterprise, the network users can be divided into three distinct functional groups: Configuration Change 15. ¶ Managers Management ¶ C++ developers ¶ Java developers

Figure 1 on page 454 shows the hierarchical structure of a reference model that could be used to define requirements for the subscribers to the three groups.

Tivoli Software Distribution User’s Guide 453 Reference Model Example

Figure 1. Example Reference Model The Enterprise 1.0 reference model is the root of a hierarchical tree. It contains configuration elements that define requirements common to all three groups. It has two direct child reference models, Managers 1.0 and Developers 1.0, which inherit the configuration elements defined in Enterprise 1.0. Developers 1.0 also has two child reference models, C++ Developers 1.0 and Java Developers 1.0, which inherit the configuration elements defined in Developers 1.0 and those inherited by Developers 1.0 from Enterprise 1.0.

Table 3 shows a summary of the elements defined for the Enterprise 1.0 reference model. Table 3. Summary of Elements in the Example Reference Model Reference Model Element Type Description Enterprise Inventory Physical memory at least 131072 KB SWD Package Windows NT40.1.0 in IC state SWD Package Lotus Notes.1.0 in IC state Managers SWD Package CMVC.1.0 in IC state SWD Package Office2000.1.0 in IC state Developers SWD Package CMVC.1.0 in ICU state Java Developers SWD Package JDK.1.8 in IC state

454 Version 4.1 Reference Model Example

Table 3. Summary of Elements in the Example Reference Model (continued) Reference Model Element Type Description C++ Developers SWD Package Visual C++.5.0 in IC state

Table 4 shows the subscribers assigned to each child reference model that represents a group of users. The root reference model, Enterprise, does not have any subscribers. It defines general requirements for all groups. Table 4. Subscribers to the Example Reference Model Reference Model Subscribers Enterprise - Managers Stockholm Developers Paris, Rome, Vienna Java Developers Athens, Dublin C++ Developers London, Brussels 5 hneConfiguration Change 15. When an activity plan is generated for the C++ Developers model, the differencing mechanism compares the current configuration of Management the London and Brussels targets with the configuration defined in the model. Both subscribers have the required amount of physical memory defined in the Inventory configuration element and do not have any of the software packages defined in the SWD configuration elements.

The generated activity plan includes the following actions: ¶ Install Visual C++.5.0 ¶ Install CMVC.1.0 in undoable mode ¶ Install Lotus Notes.5.0 ¶ Install Windows NT40.10

Tivoli Software Distribution User’s Guide 455 Before You Start Before You Start Before you start to use the CCM tool, you must do the following: ¶ Ensure that all installation and configuration tasks have been completed. Both the Activity Planner and the Historical Database Feature must be correctly installed, the prerequisites for using the Java GUI must have been installed on the system you are using, and the required RDBMS configurations must have been made. See “Creating RIM Objects and Database Tables for Activity Planner or CCM” on page 37. ¶ Assign a CCM role to the user ID you are working with. There are three CCM roles; View, Manage, and Edit. To complete all the tasks described in the sections that follow, you must assign the Edit role. For more information about CCM roles see the Tivoli Software Distribution 4.1 Reference Manual. For instructions on assigning roles, see the Tivoli Management Framework 3.7 User’s Guide.

Using CCM Using the information and instructions included in this section, you can complete the following tasks: ¶ Create a reference model that includes parent and child models. See “Creating the Reference Model Structure” on page 457. ¶ Add configuration elements to the reference model. See “Adding Elements to a Reference Model” on page 459. ¶ Assign subscribers to the reference model. See “Assigning Subscribers to a Reference Model” on page 464. ¶ Export reference models and save them in an XML format. See “Saving a Reference Model in XML Format” on page 472. ¶ Work with existing reference models, reimporting, modifying and deleting them. See “Modifying a Reference Model” on page 473.

456 Version 4.1 Using CCM

¶ Produce and submit an activity plan for the reference model. See “CCM and Activity Plans” on page 475. ¶ Produce reports. See “Creating CCM Reports” on page 478.

To start CCM, select the Change Configuration icon on the Tivoli desktop. As a user with the CCM Edit role, you can select all of the available CCM functions.

When you start CCM, the Change Configuration Management window appears. It is divided into upper and lower panes. In the upper pane, you define the structure of the reference model. An unnamed model is already present in this pane. In the lower pane, you add configurations and subscribers to the reference model structure you have defined in the upper pane.

There are three methods of accessing the CCM functions, although not all three ways are available for all functions: ¶ From the menus at the top of the Main window ¶ By using the icons

¶ From the pop-up menu Configuration Change 15. Creating the Reference Model Structure Management To create the reference model structure described in the reference model example in this chapter, perform the following steps: 1. In the upper pane, select the unnamed reference model and right-click to display the pop-up menu.

Tivoli Software Distribution User’s Guide 457 Creating the Reference Model Structure

2. From the menu, select Properties. The Properties dialog appears.

3. In the Name text box, enter Enterprise as the name of the parent reference model. Optionally, you can also enter version and description information. 4. In the Version text box enter 1.0 (this text box is optional). 5. In the Description text box enter the descriptive text New enterprise model to describe the reference model (this text box is optional). 6. Click OK. CCM creates the new parent reference model Enterprise. 7. Select the Enterprise reference model and right-click to display the pop-up menu. 8. Select New reference model. The Properties dialog appears, prompting you for the properties of the new child reference model. 9. In the Name text box, enter the name of the new reference model, Managers or Developers. Optionally, you can also enter version and description information. 10. Click OK. CCM creates the new child reference model.

458 Version 4.1 Creating the Reference Model Structure

11. Continue adding child reference models until the reference model structure is complete. In the example, this means adding one more child model to Enterprise, and two child models to Developers. Adding Elements to a Reference Model You can add a new element to a new or restored reference model, by choosing an available element type and entering the element name and the desired state. The new element is recorded in the CCM repository.

This section includes instructions for the following tasks: ¶ Adding an SWD element with a dependency. ¶ Adding an Inventory element.

Adding an SWD Element To add an SWD element to a reference model, perform the following steps: 1. In the upper pane, select the reference model.

2. In the lower pane, select the Elements tab. Configuration Change 15. 3. Right-click in the Elements pane to display the elements pop-up

menu. Management

Tivoli Software Distribution User’s Guide 459 Adding an SWD Element

4. Select SWD element. The Software Distribution element dialog appears.

5. Enter the name of a software package. If you do not know the name of the package, you can click the browse button to navigate to a list of the software packages that are available for each accessible profile manager. 6. Select the required software package state from the Desired state drop-down list.

Note: The Web Interface module only supports the actions related to the IC and RC desired states. If you are defining a reference model with Web subscribers, be aware of this limitation when you select a desired state. 7. To add a dependency, right-click in the Dependencies pane. A pop-up menu gives you the following options: ¶ Ex-requisite ¶ Pre-requisite

460 Version 4.1 Adding an SWD Element

¶ Co-Requisite 8. Select the required dependency type. The corresponding dialog box is displayed.

9. In the Name text box, Enter the name of the software package that is to be the pre-requisite, ex-requisite, or co-requisite of the software package you specified for this element. If you do not know the name of the package, you can click the browse button to navigate to a list of the software packages that

are available for each accessible profile manager. Configuration Change 15. 10. Select the required software package state for the dependency

from the Desired state drop-down list. Management

Tivoli Software Distribution User’s Guide 461 Adding an SWD Element

11. Click OK. The dependency dialog closes and the dependency is shown in the dependency list for the SWD element.

12. Click OK. The new SWD element is added to the reference model.

Adding an Inventory Element To add an Inventory element to a reference model, perform the following steps: 1. In the upper pane, select the reference model. 2. In the lower pane, select the Elements tab. 3. Right-click in the Elements pane to display the pop-up menu.

462 Version 4.1 Adding an Inventory Element

4. Select Inventory Element. The Inventory element dialog appears: 5 hneConfiguration Change 15.

5. Build an expression in the Inventory Condition text box, as follows: Management a. Select an inventory table view from the Select view drop down list. A list of columns for the table view appears in the lower text box. b. Select a column from the list and double-click. The column name appears in the Inventory Condition text box. c. From the panel of operators, select an operator, for example “=”, and double-click. The operator is added to the expression in the Inventory Condition text box. d. Click in the Inventory text box at the end of the expression and type in a value, for example a minimum memory size.

Tivoli Software Distribution User’s Guide 463 Adding an Inventory Element

e. If you want to build a more complex expression, select the AND or OR operators from the operator panel and then add another condition to the expression. 6. Click OK. The new inventory element is added to the reference model. Assigning Subscribers to a Reference Model You can assign subscribers to any of the component models of your reference model. To assign subscribers to a model, perform the following steps: 1. In the upper pane of the CCM Configurator window, select the reference model to which you want to assign subscribers. 2. In the lower pane, select the Subscribers tab. 3. Right-click in the Subscribers pane to display the pop-up menu:

4. Select one of the following values and follow the corresponding instructions: ¶ CSV subscriber

464 Version 4.1 Assigning Subscribers to a Reference Model

¶ Profile manager subscriber ¶ Static subscriber ¶ Inventory subscriber ¶ Query Library subscriber ¶ Web Interface subscriber The Web Interface subscriber is a different type of subscriber rather than a different method of assigning subscribers. Activity plans are not created for this type of subscriber. Instead, the actions required to reached the desired state are executed using the Web Interface. If you select this option, you can choose any of the listed assignment methods to assign subscribers as Web Interface subscribers.

Note: All methods of assigning subscribers, other than Static subscriber, are dynamic. When you add the subscriber, CCM shows you a list of selected targets. These are the targets that fit the selection criteria at this time.

Assigning a CSV Subscriber Configuration Change 15. You can select the subscribers to a reference model by indicating the path to a file containing a list of target names separated by a

comma. To specify a file name containing a list of targets, perform Management the following steps:

Tivoli Software Distribution User’s Guide 465 Assigning a CSV Subscriber

1. Select CSV subscriber from the pop-up menu. The CSV Subscriber dialog appears:

2. Select the CSV file you want to include and display its contents in the CSV subscriber list, by doing one of the following: ¶ Type the fully qualified file name in the Selected file text box and click Refresh. ¶ Click the browse button (...), navigate to the file location, select the file, and click Open to return to the CSV subscriber dialog.

466 Version 4.1 Assigning a CSV Subscriber

3. Select either the Include or Exclude button and click OK. The CSV subscriber is added to the reference model.

Assigning a Profile Manager Subscriber You can specify a profile manager as a subscriber to a reference Configuration Change 15. model. The subscribers to the selected profile manager are the targets

that are to match the configuration specified in the reference model. Management To specify a profile manager as a subscriber to a reference model, perform the following steps: 1. Select Profile manager subscriber from the pop-up menu. The Profile manager subscriber dialog appears.

2. Enter the fully qualified name of the profile manager in the Profile manager text box, or click the browse button (...)to navigate to the location of the profile manager and select it.

Tivoli Software Distribution User’s Guide 467 Assigninga Profile Manager Subscriber

Note: Using the navigation tool, you can preview the contents of the profile manager before you select it. 3. Select either the Include or Exclude button and click OK. The profile manager subscriber is added to the reference model.

Assigning a Static Subscriber You can specify a list of target names to be subscribers to a reference model. To specify the subscribers to a reference model using a list of target names, perform the following steps: 1. Select Static subscriber from the pop-up menu. The Static subscriber dialog appears:

2. Enter the name of the target you want to include in the Endpoint text box, or click the browse button (...) to navigate to the location of the target and select it. 3. Click Add. The target is displayed in the Selected endpoint list. 4. Continue building the list by selecting other targets and clicking Add.

468 Version 4.1 Assigninga Static Subscriber

5. Select either the Include or Exclude button and click OK. The static subscriber is added to the reference model.

Assigning an Inventory Subscriber You can specify queries which access the Tivoli Inventory configuration database and selects a list of targets as the query result. To specify an inventory subscribers as a target using a Structure Query Language (SQL) query, perform the following steps: 1. Select Inventory Subscriber from the pop-up menu. The Inventory subscriber dialog appears. 5 hneConfiguration Change 15. Management

2. Choose an inventory table view from the select TME_OBJECT_LABEL from drop-down list. A list of columns for the selected view is displayed. 3. Build an expression in the Where box to specify what information the query will return. To build a simple query, select a column from the list, select an operator from the panel, and

Tivoli Software Distribution User’s Guide 469 Assigning an Inventory Subscriber

then assign a constant by typing in the Where box. You can build more complex queries using the AND and OR operators. 4. Click Get result. All the results satisfying that condition are displayed in the third pane:

5. Select either the Include or Exclude button and click OK. The inventory subscriber is added to the reference model. Refer to the Tivoli Inventory User’s Guide for more information about SQL queries.

Assigning Query Library Subscribers You can specify a query representing a query library to return a list of subscribers from the Inventory configuration repository database. To select a query library from the TME object database to retrieve subscribers, perform the following steps:

470 Version 4.1 Assigning Query Library Subscribers

1. Select Query Library subscriber. The Query Library subscriber dialog box appears: 5 hneConfiguration Change 15. Management 2. Select a query library from the pull-down list. The contents of the query library are displayed in the box.

Tivoli Software Distribution User’s Guide 471 Assigning Query Library Subscribers

3. Click Get result to retrieve the list of targets that satisfy the selected query library.

4. Select either the Include or Exclude button and click OK. The query library subscriber is added to the reference model. Saving a Reference Model in XML Format When you have finished building the reference model, you can save it by exporting it to an xml format. In this format, you can read the file and edit it in any standard text or xml editor and reimport the file to CCM.

To export a reference model to xml format, perform the following steps: 1. From the File menu select Export. The Save dialog box is displayed.

472 Version 4.1 Saving a Reference Model in XML Format

2. Select the directory and, in the File name text box, type a file name. 3. Click Save. The reference model is exported in xml format to the specified file. Modifying a Reference Model Once you have created and saved a reference model, you can make changes to it to reflect new requirements. For example, once a reference model has been used to generate the actions required to bring subscribers to a required state, you can change the requirements by adding or modifying configuration elements. In this way, you can reuse the hierarchical structure you have created to make further changes to the subscribers.

To modify a reference model that you have exported to an xml format, you must import the model. When the model is displayed, you change it in the following ways: ¶ Modify the structure of the reference model by moving child reference models to new parents.

To do this, select the reference model you want to move, click Configuration Change 15. on the edge of the highlighted area, and drag and drop the model until its line connects to the new parent. Management ¶ Add new reference models to the structure. See “Creating the Reference Model Structure” on page 457. ¶ Remove reference models from the structure. To do this, select the reference model you want to remove, right-click, and select Remove from the pop-up menu.

Note: When you remove a parent reference model, the children are automatically removed. ¶ Modify the properties of a reference model. To do this, select the reference model you want to modify, right-click, and select Properties from the pop-up menu. See “Creating the Reference Model Structure” on page 457, for information about the properties that must be defined for a reference model.

Tivoli Software Distribution User’s Guide 473 Modifying a Reference Model

¶ Add a new configuration element to a reference model. See “Adding Elements to a Reference Model” on page 459. ¶ Remove a configuration element. To do this, select the reference model you want to remove an element from, in the lower pane select the element, right-click, and select Remove from the pop-up menu.

Note: The list of elements for a reference model indicates inherited elements by means of an up-arrow icon. Inherited elements can only be removed from the parent model where they are defined. ¶ Modify the properties of a configuration element, for example to specify a different software package. To do this, select the reference model for which you want to make changes, in the lower pane select the element, right-click, and select Properties from the pop-up menu. See “Adding Elements to a Reference Model” on page 459 for details of the properties of an element.

Note: The list of elements for a reference model indicates inherited elements by means of an up-arrow icon. You can modify an element that is inherited, but you must be aware that the changes you make affect not only the reference model you have selected, but also the parent model where the element is defined and any other child models that inherit the element. ¶ Assign a new subscriber to a reference model. See “Assigning Subscribers to a Reference Model” on page 464. ¶ Remove a subscriber. To do this, select the reference model you want to remove a subscriber from, in the lower pane select the subscriber, right-click, and select Remove from the pop-up menu. ¶ Modify a subscriber, for example to define a different query. To do this, select the reference model for which you want to make changes, in the lower pane select the subscriber,

474 Version 4.1 Modifying a Reference Model

right-click, and select Edit from the pop-up menu. See “Assigning Subscribers to a Reference Model” on page 464 for details of the properties of an subscriber.

Note: You can restore a reference model from the latest saved version. From the File menu, select Restore; the reference model is restored to the last saved version.

CCM and Activity Plans CCM includes two functions that use a differencing mechanism to produce a list of the actions required to bring subscribers to the desired stated defined in a reference model. These functions are Preview Activity Plan and Submit Activity Plan.

You should preview the activity plan before submitting it to the Activity Planner.

Note: Even if your model has only Web Interface subscribers, you still need to submit an activity plan to update the CMM databases; even though the activity plan is empty. In this case, there is no need to preview the plan. Configuration Change 15. Previewing an Activity Plan Management To preview an activity plan, perform the following steps: 1. Select the required reference model and right-click to display the pop-up menu.

Tivoli Software Distribution User’s Guide 475 Previewing an Activity Plan

2. Select Preview actions to display the Preview Activity dialog box:

3. You can now return to the reference model to correct any errors, before submitting the activity plan, see “Submitting an Activity Plan”. Submitting an Activity Plan To submit an activity plan, perform the following steps: 1. Select the required reference model and right-click to display the pop-up menu.

476 Version 4.1 Submitting an Activity Plan

2. Select Submit actions to display the Submit Dialog box: 5 hneConfiguration Change 15.

3. Select one of the submission options: Management ¶ Submit activity plan to submit the plan to the Activity Planner. ¶ Import activity plan to send the plan to the Activity Planner where it can be scheduled later. 4. If you selected Import activity plan, select or clear the Overwrite activity plan check box. If you selected Submit activity plan, this check box cannot be cleared. This is to prevent the submission failing because of a duplicate activity plan name in the Activity Planner database. 5. If you selected Submit activity plan, select or clear the Delete activity plan after submission check box. 6. Click OK.

Tivoli Software Distribution User’s Guide 477 Creating CCM Reports Creating CCM Reports CCM provides reports that provide you with an overview of activity plans related to reference models and targets. The following reports are available: Reference Model report This report summarizes progress for all targets that are subscribers to a specified reference model. You can specify a complete reference model, a branch of the hierarchical tree, or an individual child model. The model you specify need not be currently displayed. Target report This report summarizes progress for all reference models to which a specified target is a subscriber.

To produce the Reference Model report, perform the following steps: 1. From the Reports menu, select Reference Model. The Select reference model dialog appears.

2. Specify the name of the reference model for which you want to produce a report. You can also specify a version. 3. Click OK.

To produce the Target report, perform the following steps:

478 Version 4.1 Creating CCM Reports

1. From the Reports menu, select Target. The Select target dialog appears.

2. Specify the name of the target for which you want to produce a report. 3. Click OK.

Both versions of the report include the following information: ¶ Target name ¶ Type of subscriber, for example Profile Manager ¶ Reference model name ¶ Activity plan ID ¶ Status

Possible values are Submitted, Successful and Failed Configuration Change 15. ¶ Date and time the activity plan was submitted ¶ Date and time the result was received Management

Tivoli Software Distribution User’s Guide 479 Creating CCM Reports

480 Version 4.1 6 aaMvn Service Moving Data 16. 16 Data Moving Service

In any distributed systems environment, the issue arises of how to maintain consistency of data across the system. Data updates have to be distributed from a central point, and information collected locally must be retrieved for central consolidation and storage.

The Data Moving Service integrates data movement capabilities into the Software Package Distribution process. It provides the following benefits: ¶ Support for sending, retrieving, and deleting files. Any type of file can be sent, retrieved or deleted using the data moving command. ¶ Lenient distribution. ¶ Ability to define pre- and post-transfer tasks. ¶ Ability to define software dependencies for data transfers. The data transfer can be made dependent on the state, on the destination system, of a specified version of a software package. You can define transfer command so that no transfers are made if the specified software is not in the specified state on all destinations, or so that the transfer is only made to destinations where the software is in the specified state. ¶ Code page translation capabilities. ¶ Use of Tivoli’s multiplexed distribution (Mdist2) service, which provides queuing, priority, checkpoint restart, distribution monitoring, and bandwidth control.

Tivoli Software Distribution User’s Guide 481 Data Moving Service

¶ Distribution results checking. ¶ A consistent API for integration with the Activity Planner.

Configuring the Data Moving Service All data moving operations use the same software package object, DataMovingRequests.1. This object contains certain standard information to be used by all data moving operations, including logging options. If this object is not available, no data moving operation can be performed from the CLI or the Activity Planner.

This object is normally created automatically, in a suitable profile manager, when you install Software Distribution 4.1. However, if there is no suitable profile managers at installation time, you can create the object later by running data moving command, wspmvdata, with one of the following arguments: ¶ -A This creates the DataMovingRequests.1 object in any suitable profile manager. ¶ -p profile manager This creates a DataMovingRequests.1 object in the specified profile manager.

For more information about defining these arguments, see the section on wspmvdata in ″Using Commands″ in the Tivoli Software Distribution Reference Manual.

As with other software package objects, operations using the DataMovingRequests.1 object can only be performed by users who have been assigned at least the senior role in the policy region where the software package object resides.

You may wish to allow some users to perform data moving operations but not change management operations, for example installing and removing software packages. You can achieve this by setting up a policy region that is only contains the DataMovingRequests.1 object and assigning all the users a senior

482 Version 4.1 Data Moving Service Service Moving Data 16.

role in that region. If you decide to do this, you must remove the software package from the policy region where it has been automatically installed, and recreate it in a profile manager in the data moving policy region, using the -p argument. Notes: 1. If Tivoli management regions are interconnected when the data moving service is installed, there is only one DataMovingRequests.1 object, which serves both regions. Users of both regions, who are to perform data moving operations, must be assigned a senior role in the policy region where the object is located. 2. Information about operations using the DataMovingRequests.1 object is not stored in the Tivoli Inventory database. 3. The icon for the DataMovingRequests.1 object that appears on the Tivoli desktop has limited functionality compared with the icons for other objects. It only provides access to the Package Properties dialog. It does not allow you to open the software package file in the Software Package Editor, to open the Nested packages dialog, or to use drag and drop to perform data moving operations on targets.

Data Moving Scenarios The Data Moving Service supports the following scenarios: ¶ You want to send a file held in a central location to multiple destinations. ¶ You want to retrieve a specific file from a series of locations and consolidate the retrieved files in a single, central location. ¶ You want to delete a specified file from a series of locations. Sending Data to Multiple Destinations A retailing company with several branches distributes its price list to all branches. Updates to the price list are made at the central office. An updated price list must then be distributed in a way that ensures that all branches are kept in line with the central pricing information.

Tivoli Software Distribution User’s Guide 483 Data Moving Service

To complete the data movements required for this scenario, you define a data moving task with the following characteristics: ¶ A single data origin, which is a software distribution source host at the head office. ¶ A destination list of endpoints that includes all the branches where pricing information is held. ¶ A post-transfer task that updates the branch price lists with the new information.

The following example shows a command to complete such a transfer. wspmvdata -s @centoff -t @b1,@b2,@b3 -r tpost:/tmp/importpl.sh /prices/plist

Using this command, the file plist, which is located in the directory /prices on the centoff source host system is copied to the b1, b2, and b3 endpoint systems. Following the transfer, the script importpl.sh, which is located in the \tmp directory, runs on the b1, b2, and b3 endpoint systems. Data Retrieval from Multiple Origins Each day, sales transactions for the retail company are collected by the branches where the sales are made. At the end of the day, the sales transactions must be transferred to the central office where the sales ledger and central stock registers can be updated.

To complete the data movements required for this scenario, you define a data moving task with the following characteristics: ¶ A pre-transfer task to run on all the branch endpoint systems to extract the sales transactions to a file. ¶ An origin list that includes all the branch endpoint systems from which sales transactions are to be retrieved. ¶ A single destination source host system that is the central office. ¶ A post-transfer task that updates the central office sales ledger and stock register with the sales transactions.

484 Version 4.1 Data Moving Service Service Moving Data 16.

The following example shows a command to complete such a transfer. wspmvdata -s @b1,@b2,@b3 -t @centoff -r tpost:\tmp\importtrans.sh - r spre:\tmp\exporttran.sh $sales\trans

This command uses a pre-processing script on the b1, b2, and b3 endpoints to extract to a file called trans and store it in a directory represented by the variable $sales. These files are retrieved from the endpoints and stored on the source host system, in a directory represented by the variable $sales. As each file is retrieved, it is assigned a unique name. This name includes the file name, endpoint name, time stamp and distribution id, in the following format: filename(without extension)_endpointname_timestamp_distributionID.extension

After the transfer, the script importtrans.sh runs on the source host system. Deleting a File on Multiple Systems There is a software upgrade, which results in changes to data structures, and a file that is being used at all branches is no longer required by branches that are using the new software.

To complete the data movements required for this scenario, you define a data moving task with the following characteristics: ¶ A destination list that includes all the branch systems where the file is present. ¶ The name and location of the file on the branch systems. ¶ The delete argument. ¶ A software dependency to ensure that only branches with the new software are affected.

The following example shows a command to complete such a transfer. wspmvdata -t @b1,@b2,@b3 -S @SW_Package^2:I -d $temp/oldfile

Tivoli Software Distribution User’s Guide 485 Data Moving Service

Using this command, the file oldfile is deleted from the b1, b2, and b3 systems, on the condition that the software SW_Package version 2 is in an installed and committed state.

No origin system is required for the delete operation.

The Command Line Interface The Data Moving Service is available from the CLI and from the Activity Planner interface.

The command is wspmvdata. Some examples of how you can use this command to complete different data moving tasks are giving in “Data Moving Scenarios” on page 483.

The wspmvdata command supports a number of arguments that allow you to define the following: ¶ An origin system or list of origin systems ¶ A destination system or list of destination systems ¶ Pre- and post-transfer tasks on both the origin and destination systems ¶ Software dependencies ¶ Overriding of variable ¶ Deletion of files on a destination system or list of destination systems ¶ Distribution objects, for example, timeouts, priorities, and deadlines

Note: The wspmvdata command also supports two arguments, -p and -A, that create the DataMovingRequests.1 software package object that is used in all data moving operations. Neither of these arguments is needed if, at the time of installation, there is a suitable profile manager in which the software package object can be automatically created.

486 Version 4.1 Data Moving Service Service Moving Data 16.

For a full description of wspmvdata and its arguments, see the section on wspmvdata in ″Using Commands″ in the Tivoli Software Distribution Reference Manual.

Using Pre- and Post-Processing Scripts When you define a wspmvdata command, you can specify up to four scripts to be invoked during the data moving process. These scripts define pre- and post-processing tasks on the origin and destination systems between which you want to move data. The following are typical examples of tasks you can define using the script facility: ¶ Extracting data from a central repository on the origin system and storing it in a file that is to be moved to the destination systems. ¶ Updating a local repository on the destination systems with data from the file that has been received.

The sequence in which the scripts run in a send operation is as follows: 1. The pre-processing script runs on the origin system, which is the source host system that was specified in the command. 2. A pre-processing script runs on each destination system. The destination systems for a send are endpoints. 3. A post-processing script runs on each endpoint. 4. The post-processing script runs on the source host.

The sequence in which the scripts run in a retrieve operation is as follows: 1. A pre-processing script runs on the destination system, which is the source host. 2. A pre-processing script runs on each origin system. The origin systems for a retrieve are endpoints. 3. A post-processing script runs each endpoint that was an origin for the retrieval.

Tivoli Software Distribution User’s Guide 487 Data Moving Service

4. The post-processing script runs on the source host.

For delete operations, there is no origin system. Pre- and post-processing scripts run on the endpoints from which the file is to be deleted.

When you write a script to be used with the wspmvdata command, you must include the following arguments: $1 Operation Type This identifies the type of data-moving operation. Possible values are send, retrieve, and delete. $2 Location Type This indicates whether the script ran on a Tivoli managed node (source host) or on an endpoint. Possible values are EP_SCRIPT for endpoints, and SH_SCRIPT for source hosts. $3 Timing Type This indicates whether the script ran before or after the data moving operation. Possible values are PRE_SCRIPT and POST_SCRIPT. $4 Data File This is the fully qualified name of the file that was moved or deleted.

The values assigned to these arguments depend on the arguments you specified for the wspmvdata command.

Note: If you are writing a post-processing script for use on NT platforms, you must include code to deal with any errors caused by the file being locked.

This situation can occur when an identical file, in name and content, already exists on the target system and is locked at the distribution time. In such a case, the data moving operation does not fail with ″file locked″, because it does not attempt to replace the file, since there are no changes . As the

488 Version 4.1 Data Moving Service Service Moving Data 16.

operation has not failed, the post-processing script will run and must be able to deal with a locked file. Example The following command includes the script merge.sh as a post-processing script on the target system. wspmvdata -t @lab15124 -s @lab67135-w98,@lab15180-2000 -r tpost:/usr/sd41/scripts/merge.sh /usr/sd41/source/data.txt

The target system for this command is a source host and the source list includes two endpoints. The purpose of the merge.sh script is to create a single file on the source host system by merging the files that have been retrieved from the endpoints.

#!/bin/sh #======CM_OPERATION=$1 LOCATION=$2 PRE_POST=$3 DATA_FILE=$4 print "CM Operation:" $CM_OPERATION > /usr/sd41/scripts/merge.out; print "Location:" $LOCATION >> /usr/sd41/scripts/merge.out; print "Pre-post:" $PRE_POST >> /usr/sd41/scripts/merge.out; print "File Name" $DATA_FILE >>/usr/sd41/scripts/merge.out; print "======" >>/usr/sd41/scripts/merge.file; print "=== FILE being merged: $DATA_FILE at: vdatev ==" >>/usr/sd41/scripts/merge.file; print "======" >>/usr/sd41/scripts/merge.file; cat $DATA_FILE >> /usr/sd41/scripts/merge.file; print "Error level is:" $? >> /usr/sd41/scripts/merge.out; exit $?

When the merge.sh script runs, the fixed parameters are set as follows: $1 Retrieve $2 SH_SCRIPT $3 POST_SCRIPT $4 /usr/sd41/source/data....txt

Note: The file name, data.txt, is expanded to include the name of endpoint from which it was retrieved, a time

Tivoli Software Distribution User’s Guide 489 Data Moving Service

stamp, and an operation id. This ensures that each retrieved file has a unique name when it is written to the target directory on the source host.

The script writes these values and any errors to an output file and appends the contents of the data file to the file usr/sd41/scripts/merge.file.

490 Version 4.1 17 Pristine Installations 7 rsieInstallations Pristine 17.

This chapter describes how the Tivoli Software Distribution Pristine tool can be used to make pristine installations. A pristine installation installs an operating system on a system where no operating system or other software is installed.

The chapter is divided into four main sections: ¶ “Overview” gives an overview of the pristine installation process ¶ “Windows Steps” on page 498 describes how to make pristine installations of the supported Windows operating systems ¶ “OS/2 Steps” on page 520 describes how to make pristine installations of the supported OS/2 operating systems

Overview This section gives an overview of the pristine installation process. It also provides details of the prerequisites for the use of the tool and briefly discusses how to install it.

The Tivoli Software Distribution 4.1 Pristine tool provides support for remote, almost completely unattended pristine installations, by preparing and storing operating system images and configuration information on a server, which can be accessed through the network by boot diskettes running on the pristine system. The advantages of using the tool are as follows:

Tivoli Software Distribution User’s Guide 491 Pristine Installations: Overview

¶ You can specify installation and configuration information at a different time and place to when and where the software is being installed. Thus, the processes of preparation and installation can be approached as separate tasks. ¶ You can provide information for the installation process in a response file so that the installation can be almost completely unattended

Pristine installations can be made of the following operating systems with the Pristine tool: Windows NT Workstation 4.0 Windows 98 SE Windows 2000 Professional OS/2 Warp Server 4.0 OS/2 Warp Server for e-business 4.5

Any additional operating system software or any other software should be installed using Tivoli Software Distribution after the pristine installation has completed. Typical Network Environment A typical network environment has, apart from the pristine systems themselves, three essential elements: a pristine preparation site a code server, and a dedicated pristine gateway, as shown in the following figure:

492 Version 4.1 Pristine Installations: Overview 7 rsieInstallations Pristine 17.

Figure 2. Pristine installation scenario

Pristine Preparation Site The pristine preparation site is the system where the Pristine tool is installed and running. It must be a Tivoli endpoint, in order for the Pristine tool to be installed on it.

Code Server The Pristine tool on the pristine preparation site prepares the operating system code images and saves them on a code server, from which they can be accessed by the pristine installation process over the network, in a code server object. The Pristine tool also adds code images of any other, non-operating system software, that is required by the installation process; for example, Tivoli Management Agent. Finally, the tool allows you to customize the response files for the operating system software and other required software.

Separate code server objects can be created for each type of operating system to be installed, and, if necessary, more than one object can be created for each operating system, for example, for multiple language versions of the same operating system.

Tivoli Software Distribution User’s Guide 493 Pristine Installations: Overview

The tool is also used to add configurations to each object. A configuration contains all the information that defines how a specific system or group of systems is to be configured, in terms of the following: ¶ Customized operating system response file ¶ Customized Tivoli Management Agent response file ¶ Hard disk sizes (up to two hard disks) ¶ Hard disk partitioning requirements ¶ Optional Change Configuration Management (CCM) reference model to use ¶ Configuration notes

For each configuration, a boot diskette (for OS/2 a set of three boot diskettes) is created. This diskette is transported to the appropriate pristine system where it is used to boot the system. The boot process accesses the code server and downloads the code images, response files and configuration files, and installs the operating system.

Although shown in Figure 2 on page 493 as a separate system, the code server can be the same system as the pristine preparation site.

Dedicated Pristine Gateway The final stage in the pristine process is to assign the pristine system to a dedicated pristine gateway (a Tivoli Enterprise gateway). If the Code Server Object configuration contains a reference model, and on the gateway a specific Login-Policy has been activated, a CCM operation will be started, for example, to install software on the pristine system. Prerequisites This section details the prerequisites for the code server, the Pristine tool, the creation of the system diskette and the pristine system itself.

Code Server Prerequisites The basic operating system requirements for the code server differ, whether you wish to install a Windows or an OS/2 operating system. Windows To install any of the Windows operating systems detailed above, the code server must have one of the following operating systems installed:

494 Version 4.1 Pristine Installations: Prerequisites

Windows NT 4.0 (Server or Workstation) Windows 2000 Professional

Any Windows system can be installed from a code server on any of these platforms (for example, a Windows 2000 Pro system can be installed on a pristine system from a code server on a Windows NT 4.0 Workstation). OS/2 To install any of the OS/2 operating systems detailed above, the code server must be a system of the same Installations Pristine 17. type (for example, to install OS/2 4.0 on a pristine system the code server must be on an OS/2 4.0 system).

Apart from the operating system prerequisites, the following are also prerequisites: ¶ The code server must be an endpoint, or any system in the network to which the pristine system is connected ¶ Batch file utilities

Pristine Tool Prerequisites The Pristine tool can be installed on any of the platforms that can be used as a code server, except that: ¶ To prepare a pristine installation of a Windows operating system the tool must be installed on a Windows system ¶ To prepare a pristine installation of an OS/2 operating system the tool must be installed on an OS/2 system

Other prerequisites for the Pristine tool are as follows: ¶ The operating system images that you want to prepare must be available either from the operating system installation CD-ROMs or from hard disk. ¶ CD-ROM drive for the operating system images (optional - images can also be loaded from a hard disk).

Tivoli Software Distribution User’s Guide 495 Pristine Installations: Prerequisites

¶ A diskette drive and, for each separate code server configuration, one blank diskette for Windows, or three blank diskettes for OS/2. ¶ Code images must be available for the following required software: Windows Tivoli Management Agent for Windows OS/2 Tivoli Management Agent for OS/2 TCPIP MPTS Netscape (OS 4.0 only) Java (OS 4.0 only)

System Diskette Creation Prerequisites The prerequisites for the system diskettes differ according to whether the diskette is for Windows or OS/2:

Windows ¶ The first phase of the system diskette creation requires the use of the DOS format command and must be done on a system running native MS-DOS, Version 7.0 or higher. ¶ The second phase uses the Network Client Administrator utility, which is provided with Windows NT Server, but which can also be manually installed (by copying the executable file) on other Windows platforms, such as Windows NT Workstation or Windows 2000 Professional. ¶ The second phase also requires the use of the Windows NT Server CD-ROM.

OS/2 The following Configuration, Installation and Distribution (CID) utilities must be available, in the appropriate versions for the platform to be installed: THINLAPS THINIFS

496 Version 4.1 Pristine Installations: Prerequisites

CASINSTL SEDISK

Pristine System Prerequisites The pristine system requires: ¶ An appropriate network card and connection ¶ A diskette drive

Dedicated Pristine Gateway Prerequisites The dedicated pristine gateway can be any Tivoli Gateway, but it Installations Pristine 17. must be dedicated to the first-time registration of pristine systems. If you decide to use the CCM component to install software after the operating system has been installed, the gateway must have the following installed products: ¶ Tivoli Inventory Server and Gateway ¶ Tivoli Software Distribution Gateway ¶ Managed Node component of the CCM feature In addition, after these components have been installed you should: ¶ Create a reference model in the CCM feature to install software on the pristine system; the reference model name and version must be the same as that used in the code server object configuration ¶ Activate the login policy script by using the command: wputeppol login_policy

Tivoli Software Distribution User’s Guide 497 Pristine Installations on Windows Windows Steps This section commences with an overview of the steps to be carried out if you wish to install any of the supported Windows operating systems on a pristine system. It then describes each of those steps in detail. Pristine Installation Scenario To prepare for and carry out one or more pristine installations, follow the steps detailed below: Step 1. Plan the installations you want to make, deciding which code server objects are required to be installed, and for each object how many separate configurations will be required See “Step 1: Planning” on page 499. Step 2. Use the Pristine tool to create the code server objects identified in 1 See “Step 2: Creating and Maintaining Code Server Objects” on page 500. Step 3. For each code server object use the Pristine tool to create a configuration for each system or group of systems with similar characteristics, as determined in 1 See “Step 3: Creating and Maintaining Code Server Object Configurations” on page 507. Step 4. Prepare a system diskette for each configuration. See “Step 4: Preparing a System Diskette” on page 513. Step 5. Use the Pristine tool to add to the system diskette information that points to the code server object, thereby creating a pristine boot diskette, for each configuration See “Step 5: Creating a Pristine Boot Diskette” on page 516. Step 6. Use the boot diskette to run a pristine installation, and optionally carry out change configuration management activities. Finally, migrate the new endpoint from the dedicated pristine gateway to a normal gateway. See “Step 6: Running a Pristine Installation” on page 518.

If you intend to make pristine installations on a group of systems with the same configuration sequentially, you will need only one diskette for each configuration; if the systems are at remote locations

498 Version 4.1 Pristine Installations on Windows

and you want to carry out the pristine installations contemporaneously you will have to create a system diskette (Step 4 on page 498) and subsequently transform it into a pristine boot diskette (Step 5) for as many systems for which you need contemporaneous installations. Step 1: Planning In this section you plan how to use the Pristine tool to install an operating system on a pristine system. Planning for pristine installations considers two questions: 7 rsieInstallations Pristine 17. ¶ Which code server objects need to be created ¶ Which configurations need to be created for each code server object

Code Server Objects A code server object needs to be created for every version of every operating system you wish to install. If you work in a multi-language environment you should create a separate object for each language version of each system.

A code server object comprises, apart from the configurations, just the code images for the operating system software and the required additional software (Tivoli Management Agent). Thus, if you only have one operating system image and one image for Tivoli Management Agent, you will only need one code server object.

The Pristine tool allows you to modify code server objects, for example, in the event that a new version of Tivoli Management Agent becomes available, and to delete them when they are no longer required.

Tivoli Software Distribution User’s Guide 499 Pristine Installations on Windows: Planning

¶ Customized Tivoli Management Agent response file; the tool lets you customize the default response file in the same way ¶ The size of the hard disks of the pristine system; up to two hard disks can be defined using the Pristine tool - if the system has additional disks they must be partitioned and formatted manually after the pristine installation is complete ¶ The partitioning requirements of the hard disks, including the drive letters by which each partition can be identified; the primary partition must be identified ¶ The device drivers which are to be loaded onto the pristine system ¶ The CCM reference model to use, if any; both the model name and the version number can be specified (see “Change Configuration Management” on page 449) ¶ Configuration notes You should determine this information for each pristine system to be installed and then create a separate configuration for each system or group of systems that has a unique combination of these values. Step 2: Creating and Maintaining Code Server Objects This section shows you how to use the Pristine tool to create a code server object containing the code images of the supported Windows operating system, and of the Tivoli Management Agent that is required to be installed with the operating system.

Using the Pristine tool, you create a new code server object by doing the following: ¶ Select the operating system to install on the pristine system ¶ Locate the source code images for the operating system ¶ Define the required location for the code server object on the code server (ensure that the code server is accessible in the network before commencing this procedure) ¶ Enter any useful information about the code server object ¶ For each additional product required to be installed with the operating system (in the case of Windows only Tivoli Management Agent is required), locate the source code images

500 Version 4.1 Pristine Installations on Windows: Code Server Objects

¶ Save the code server object

The tool also subsequently lets you modify any of the parameters you have defined, or to delete the object completely (if you delete the object you will not delete the original code images).

Creating a New Code Server Object All operations using the Pristine tool can be selected in the dialogs by any of these methods: ¶ Select the item from the hierarchical menus ¶ Click on an icon in the toolbar Installations Pristine 17. ¶ Right click and select an item from the context-sensitive menu that is displayed In order to avoid unnecessary repetition in the instructions that follow, all options are described as being selected from the hierarchical menus.

In addition, you should note that items can be selected either by clicking on them or by using the tab and arrow keys to navigate around the dialog.

The steps are as follows:

Tivoli Software Distribution User’s Guide 501 Pristine Installations on Windows: Code Server Objects

1. Start the Pristine tool and the Tivoli Pristine Tool dialog is displayed.

2. Optionally select the required operating system and select Tools → New Code Server. The New Code Server Object dialog is displayed.

502 Version 4.1 Pristine Installations on Windows: Code Server Objects

3. Enter the name of the new code server object and click OK. The code server object setup dialog is displayed. 7 rsieInstallations Pristine 17.

4. Under the General tab, enter the following identification information for the operating system image: Operating System If you did not select the operating system on the previous screen select it from this pull-down. Source path Select the source path from Table 5, enter the full pathname for the directory in which the operating system image is located, or click the ellipsis (...) button and browse for the source directory. Table 5. Source Path Location for Operating System Image on CD-ROM Operating System Source Path Windows 98 \WIN98\SETUP Windows NT 4.0 \I386 Windows 2000 Professional \I386

Tivoli Software Distribution User’s Guide 503 Pristine Installations on Windows: Code Server Objects

Destination path Enter the full path on the code server where the code server object is to reside. New destination path This field is only used to change the location of an existing code server object, so it should be left blank when creating a new object. 5. Select the Information tab if you want to add additional information about the code server object (for example, creator, date, purpose of the object). 6. Select the Products tab.

7. Click on the check box for Tivoli Management Agent. The Install Directories dialog is displayed

504 Version 4.1 Pristine Installations on Windows: Code Server Objects

8. In the Source path field enter the path for the Tivoli Management Agent software image, either from the Tivoli Management Framework CD-ROM or from a hard disk location where you have previously copied it. The tool will propose a Destination Path which you are strongly advised not to alter. Click OK to save the settings and return to the code server object dialog. 9. Click the Apply button to update the object. A syntax check is performed to ensure the paths you have entered are valid and

that there is enough room for the operating system image in the Installations Pristine 17. destination folder. If the destination folder is not found after this check, it is created. The platform name and the object name is displayed in the Code Server created list:

10. Click Add if you want to create another code server object, and the New Code Server Object dialog is displayed (go back to step 3 on page 503); or click OK to return to the Pristine tool main menu.

Tivoli Software Distribution User’s Guide 505 Pristine Installations on Windows: Code Server Objects

Note: If you add another code server object, you must choose a platform from the Operating System drop-down list in the code server window.

Editing a Code Server Object You can change all but one of the code server object parameters by selecting the object, selecting Tools → Code Server, changing the value previously entered and selecting Apply.

The exception is if you want to move the code server object to a new location: 1. Select a code server object in the Main dialog and then select Tools → Code Server. 2. Select the object you want to edit from the Code Server Created list and click Edit. 3. Enter a new path in the New Destination Path text box. 4. Click Apply. A check is performed to ensure the paths you have entered are valid and that there is enough room for the operating system image in the destination folder. If there is, the code server object will be moved to the location identified in New Destination Path. 5. Click OK to return to the Pristine tool main menu.

506 Version 4.1 Pristine Installations on Windows: Configurations

Step 3: Creating and Maintaining Code Server Object Configurations For every code server object created you must create at least one configuration, which tells the pristine installation process how to configure the new operating system. The following actions are possible: ¶ “Customizing the Operating System Response File” ¶ “Customizing the Tivoli Management Agent Response File” on page 510

¶ “Adding Device Drivers” on page 510 Installations Pristine 17. ¶ “Partitioning the Client Hard Disk” on page 512 ¶ “Defining a Reference Model” on page 513 ¶ “Adding Configuration-Specific Information” on page 513

Tivoli Software Distribution User’s Guide 507 Pristine Installations on Windows: Configurations

object you want to configure.

2. Select File → New Configuration. The Pristine Configuration dialog is displayed.

508 Version 4.1 Pristine Installations on Windows: Configurations

3. Enter a name for the configuration and click OK. The Configuration dialog is displayed. 7 rsieInstallations Pristine 17.

This dialog lets you customize the operating system response file. The left panel lists all of the sections in the response file. Select a section and its installation keys and their default values are displayed in the right panel. Full details of the sections and keys and their meaning should be found in the documentation for the operating system.

Tivoli Software Distribution User’s Guide 509 Pristine Installations on Windows: Configurations

5. To add, remove or rename installation keys, do the following: a. Select a section b. Select an installation key (you do not have to do this if you are only adding a new key). c. Select Edit Key → Key → New, Delete or Rename. d. The appropriate dialog will be displayed allowing you to add, delete or rename the key, as appropriate. e. Click on OK to save the settings you have made and to return to the Configuration dialog.

Note: While for many of the keys you can use their factory defaults, your attention is particularly drawn to the keys for the installation path, the gateway port and the endpoint port which must be completed for both the operating system and for Tivoli Management Agent . 6. To add, remove or rename installation section names, do the following: a. Select the section (you do not have to do this if you are only adding a new section). b. Select Edit Key → Section → New, Delete or Rename. 7. Click on OK to save the settings you have made and to return to the Main dialog.

Customizing the Tivoli Management Agent Response File From the Configuration dialog click on the No Product pull-down and select Tivoli Management Agent. The response file sections and keys for this product will be displayed and can be customized as described for the operating system response file, above.

Adding Device Drivers For most pristine installations, the device drivers incorporated in the operating system software will be sufficient to enable the full operation of most pristine systems. However, if necessary, you can add to the code server object any device drivers that are required to be installed on the pristine system.

510 Version 4.1 Pristine Installations on Windows: Configurations

For Windows 2000 or Windows NT, this step is carried out by the Pristine tool, as follows: 1. Select Configuration → Add new device driver. The Device Driver dialog is displayed: 7 rsieInstallations Pristine 17.

2. Click Add files and select the device driver file(s) to add. 3. Click Save to save the list of device drivers and return to the Configurations dialog. Remove a driver file by selecting the file and clicking Remove.

Note: For Windows 2000 Professional and Windows NT, the driver files are added by default to a subdirectory called ‘...\$OEM$’ within the destination operating system directory. However, if you need to add network adapter files, they should be added to ‘...\$OEM$\NET’, creating the subdirectory if necessary, while video adapter driver files, for Windows NT only, should be added to ‘...\$OEM$\TEXTMODE’.

Tivoli Software Distribution User’s Guide 511 Pristine Installations on Windows: Configurations

For Windows 98 this step is performed following the instructions in the operating system documentation for adding device drivers to the operating system setup (in the code server object).

There are tabs for each of two physical volumes. On the first volume there is a default definition of a primary partition, with the drive letter C, of 2000 megabytes. 2. To change the primary partition size click on Size and change the value. 3. To add a partition, click Add,. A new partition is created, with a default size of 2000 megabytes, using the next available drive letter. The Partition type defaults to Logical, but can be changed by clicking on the Partition type of the partition in question. The total of all partitions created is shown in the box at bottom right. To change the partition size click on Size and change the value. 4. Click OK to save the partitioning details and return to the Configurations dialog.

512 Version 4.1 Pristine Installations on Windows: Configurations

Remove a partition by selecting the partition and clicking Remove and then OK.

Defining a Reference Model In order to use CCM on the pristine system you are given the option of defining a reference model. The steps are as follows: 1. Select Configuration → Reference Model. The Reference Model dialog is displayed: 7 rsieInstallations Pristine 17.

2. Enter the reference model name and/or version. 3. Click OK to save the reference model definition and return to the Configurations dialog. Remove a reference model definition by clicking Remove and then OK.

Adding Configuration-Specific Information Configuration-specific information can be added to the configuration. The steps are as follows: 1. Select Configuration → Information. The Information dialog is displayed. 2. Enter the required information. 3. Click OK to save the information and return to the Configurations dialog. Step 4: Preparing a System Diskette For each code server object configuration you will need to create a system diskette that will be used in Step 5: Creating a Pristine Boot Diskette.

Tivoli Software Distribution User’s Guide 513 Pristine Installations on Windows: System Diskette

You will use the standard diskette formatting command, and then the Network Client Administrator utility to add the files required by the client to establish a network connection with the Code Server. The steps are as follows: 1. Prepare a system diskette on a system running MS-DOS 7.0 or higher. At the DOS prompt, enter: format /s a:

This prepares a formatted disk containing the required system files. 2. From the MS-DOS system, copy the following applications onto the diskette: ¶ fdisk.com ¶ format.com ¶ smartdrv.exe ¶ xcopy.exe (in the case of a Windows 98 SE installation) 3. On a Windows NT Server, or other Windows system with Network Client Administrator installed, run Network Client Administrator (on the Windows NT server select Start → Administrative Tools → Network Client Administrator). The Network Client Administrator dialog is displayed. 4. Select the Make Network Installation Startup Disk option button and click Continue. The Share Network Client Installation Files dialog is displayed. 5. In the Path field, enter the location of the CLIENTS directory in the root of the Windows NT Server CD-ROM. Alternatively you can use the ellipsis (...) button to browse for the folder. 6. The first time you run this procedure, select the Copy files to a New Directory, and then Share option button. This creates a new shared directory in a location of your choice (the default is c:\clients).

Note: You can write diskettes subsequently from the shared directory that you created in the previous step by selecting

514 Version 4.1 Pristine Installations on Windows: System Diskette

Use Existing Shared Directory. The utility points to the copied files each time it is run. 7. Click OK. The Target Workstation Configuration dialog is displayed. 8. Select the appropriate type of disk drive for your system. 9. In the Network Client list box, select Network Client 3.0 for MS-DOS and Windows. 10. Choose a network adapter card from the list provided. If your network adapter is not included, select any of the cards listed. Installations Pristine 17. You can then copy the correct adapter files and make the appropriate modifications to the start diskette at a later stage (this is described in step 16). 11. Click OK. The Network Startup Disk Configuration dialog is displayed. 12. In the Computer Name, User Name, and Domain text boxes, enter the required details, and select the TCP/IP Network Protocol. 13. Select the Enable Automatic DHCP Configuration check box or type the appropriate data into the activated TCP/IP fields. 14. Insert the system diskette created in step 1 on page 514 into the diskette drive and click OK. A confirmation dialog box appears. 15. Click OK to create the boot diskette. 16. The system diskette has now been created and is ready to be used by the Pristine tool to create a pristine boot diskette (see “Step 5: Creating a Pristine Boot Diskette” on page 516). However, if your network card was not present in the adapter list, now do the following: a. Copy the appropriate DOS driver to the /NET directory on your start diskette. Attention: The PCI Token-Ring network adapter card is not supported. Do not copy DOS driver files for this card onto the diskette.

Tivoli Software Distribution User’s Guide 515 Pristine Installations on Windows: System Diskette

b. Using a text editor, modify the netcard statement in the system.ini file in the /NET directory so that it reads: netcard=.dos c. Locate the oemsetup.inf file for your network card and open it using a text editor. Search for the options section and make a note of the card name. An example is shown below: ;************************************************* ; Define Option ;************************************************* [Options] IBMFE [OptionsText] IBMFE = "IBM 10/100 Ethernet PCI Adapter" d. Using a text editor, modify the drivername statement in the protocol.ini file in /NET directory so that it corresponds to the name you observed in the oemsetup.inf file. e. Save and close all files. Step 5: Creating a Pristine Boot Diskette When you have created at least one configuration for a code server object (see “Step 3: Creating and Maintaining Code Server Object Configurations” on page 507) and have prepared a system diskette (see “Step 4: Preparing a System Diskette” on page 513), you can use the Pristine tool to transform the prepared system diskette into a pristine boot diskette.

516 Version 4.1 Pristine Installations on Windows: Boot Diskette

1. From the toolbar, click Tools → Create Boot Diskettes. The Create Boot Diskettes dialog is displayed: 7 rsieInstallations Pristine 17.

2. Place the diskette you created in “Step 4: Preparing a System Diskette” on page 513, into the diskette drive. 3. Complete the following fields: Server name Hostname of the code server Share name Share name of the folder that contains the code server objects (i.e. the Destination Path) User name User name under which to login to the code server (usually Administrator) Password Password to login to the code server Map drive Select the drive letter to which the shared code server object directory is to be mapped Network protocol Select TCP/IP from the drop-down list 4. Click OK. The Pristine tool writes the data to the system diskette, creating a pristine boot diskette.

Tivoli Software Distribution User’s Guide 517 Pristine Installations on Windows: Running Installation

Step 6: Running a Pristine Installation When you have completed the preparation of the boot diskette for a system or group of systems (see “Step 5: Creating a Pristine Boot Diskette” on page 516), you can commence a pristine installation. The installation procedure carries out the following operations: ¶ It uses the boot diskette to start up the pristine system and load a minimum system configuration into memory ¶ It installs the necessary protocols to connect itself into the network and to locate the code server. ¶ Using the configuration information it partitions the hard disks and commences to download and install the operating system software, using the response file to drive the installation. ¶ Each system, or group of systems is assigned to a dedicated Tivoli gateway ¶ If the code server object configuration contains a reference model, and on the gateway a specific login-policy has been activated, a CCM operation will be started

When these activities are completed, the new endpoint must be migrated from the dedicated pristine gateway to a normal gateway.

Pristine Installation Procedure A person must be present where the pristine systems are located. The tasks executed locally are: ¶ Starting the system ¶ Removing the diskette when necessary ¶ Pressing enter when requested during logon (Windows 98 only) ¶ Restarting the system if required

Once the diskette is ready and delivered to the person performing the local installation, the installation process can begin.

When the first Tivoli management agent login is connected, an automatic notification of the presence of a new machine in the Tivoli management region takes place.

518 Version 4.1 Pristine Installations on Windows: Running Installation

If you have defined a reference model you should ensure that the CCM component of Tivoli Software Distribution is activated, in order to compare the new system to the appropriate reference model and to start the specific action. This action completes the pristine installation process.

Note: If you want to use a reference model to install Tivoli Software Distribution, you should remember to install any prerequisite software. For example, on Windows NT, the appropriate Service Pack is a prerequisite for Tivoli Software Distribution, and thus must be installed first. Installations Pristine 17.

The final step is for the pristine system administrator, who must, after all installation processes are completed, migrate the new endpoint from the dedicated pristine gateway to a normal gateway.

Tivoli Software Distribution User’s Guide 519 Pristine Installations on OS/2 OS/2 Steps This section commences with an overview of the steps to be carried out if you wish to install any of the supported OS/2 operating systems on a pristine system. It then describes each of those steps in detail. Pristine Installation Scenario To prepare for and carry out one or more pristine installations you will need to follow the steps detailed below: Step 1. Plan the installations you want to make, deciding which code server objects are required to be installed, and for each object how many separate configurations will be required See “Step 1: Planning” on page 521. Step 2. Use the Pristine tool to create the code server objects identified in step 1 on page 498 See “Step 2: Creating and Maintaining a Code Server Object” on page 523. Step 3. Use the OS/2 utilities to add system files to each code server object you created in Step 2. See “Step 3: Adding System Files to Code Server Objects” on page 526. Step 4. For each code server object use the Pristine tool to create a configuration for each system or group of systems with similar characteristics, as determined in step 1 on page 498 See “Step 4: Creating and Maintaining Code Server Object Configurations” on page 529. Step 5. Prepare a set of three system diskettes for each configuration. See “Step 5: Preparing the System Diskettes” on page 532. Step 6. Use the Pristine tool to add to the system diskettes information that points to the code server object, thereby creating a set of pristine boot diskettes, for each configuration See “Step 6: Creating Pristine Boot Diskettes” on page 534. Step 7. Use the set of boot diskettes to run a pristine installation, and optionally carry out change configuration management activities. Finally you will migrate the new endpoint from

520 Version 4.1 Pristine Installations on OS/2

the dedicated pristine gateway to a normal gateway. See “Step 7: Running a Pristine Installation” on page 536.

If you intend to make pristine installations on a group of systems with the same configuration sequentially, you will need only one diskette (set of diskettes for OS/2) for each configuration; if the systems are at remote locations and you want to carry out the pristine installations contemporaneously you will have to create a system diskette (Step 5) and subsequently transform it into a pristine boot diskette (Step 6) for as many systems for which you need contemporaneous installations. Installations Pristine 17.

Note: To avoid repetition, the dialogs for the OS/2 version of the Pristine tool have not been reproduced here; please refer to pages 501 to 516 for the corresponding dialogs in the Windows format. Step 1: Planning In this section you plan how to use the Pristine tool to install an OS/2 operating system on a pristine system. Planning for pristine installations considers two questions: ¶ Which code server objects need to be created ¶ Which configurations need to be created for each code server object

Code Server Objects A code server object needs to be created for every version of the operating system you wish to install (for OS/2 you can only prepare code server objects for the operating system on which the code server is installed). If you want to make pristine installations in a multi-language environment you should create a separate object for each language version of each system.

Tivoli Software Distribution User’s Guide 521 Pristine Installations on OS/2: Planning

Thus, if you only have one operating system image and one image for each of the items of additional required software, you will only need one code server object.

Code Server Object Configurations Each code server object must have at least one configuration defined. A configuration contains the following information: ¶ Customized operating system response file; the tool lets you modify the default response file supplied with the operating system, changing values, and adding or deleting sections and keys ¶ Customized additional required software response files; the tool lets customize the default response files in the same way ¶ The size of the hard disks of the pristine system; up to two hard disks can be defined using the Pristine tool - if the system has additional disks they must be partitioned and formatted manually after the pristine installation is complete ¶ The partitioning requirements of the hard disks, including the drive letters by which each partition can be identified; the primary partition must be identified ¶ The device drivers which are to be loaded onto the pristine system ¶ The CCM reference model to use, if any; the model name and optionally the version number can be specified (see “Change Configuration Management” on page 449) ¶ Configuration notes You should determine this information for each pristine system to be installed and then create a separate configuration for each system or group of systems that has a unique combination of these values.

522 Version 4.1 Pristine Installations on OS/2: Code Server Objects

Step 2: Creating and Maintaining a Code Server Object This section shows you how to use the Pristine tool to create a code server object containing the code images of the supported OS/2 operating system and of the additional software that is required to be installed with the operating system.

Using the Pristine tool, you create a new code server object by doing the following: 7 rsieInstallations Pristine 17. ¶ Select the operating system to install on the pristine system ¶ Locate the source code images for the operating system ¶ Define the required location for the code server object on the code server (ensure that the code server is accessible in the network before commencing this procedure) ¶ Enter any useful information about the code server object ¶ For each additional product required to be installed with the operating system, locate the source code images ¶ Save the code server object

The tool also subsequently lets you modify any of the parameters you have defined, or to delete the object completely (if you delete the object you will not delete the original code images).

Creating a New Code Server Object All operations using the Pristine tool can be selected in the dialogs by any of these methods: ¶ Select the item from the hierarchical menus ¶ Click on an icon in the toolbar ¶ Right click and select an item from the context-sensitive menu that is displayed In order to avoid unnecessary repetition in the instructions that follow, all options are described as being selected from the hierarchical menus.

Tivoli Software Distribution User’s Guide 523 Pristine Installations on OS/2: Code Server Objects

In addition, you should note that items can be selected either by clicking on them or by using the tab and arrow keys to navigate around the dialog.

The steps are as follows: 1. Start the Pristine tool and the Tivoli Pristine Tool dialog is displayed. 2. Optionally select the required operating system and select Tools → New Code Server. The New Code Server Object dialog is displayed. 3. Enter the name of the new code server object and click OK. The code server object setup dialog is displayed. 4. Under the General tab, enter the following identification information for the operating system image. Operating System If you did not select the operating system on the previous screen select it from this pull-down. Source path Select the source path from Table 6, enter the full pathname for the directory in which the operating system image is located, or click the ellipsis (...) button and browse for the source directory. Table 6. Source Path Location for Operating System Image Operating System Source Path OS/2 Warp Version 4.0 \OS2IMAGE OS/2 Warp Version 4.5 \OS2IMAGE

524 Version 4.1 Pristine Installations on OS/2: Code Server Objects

5. Select the Information tab if you want to add additional information about the code server object (for example, creator, date, purpose of the object). 6. Select the Products tab. 7. Click on the check box of one of the additional required software items. The Install Directories dialog is displayed. 8. In the Source path field enter the path where the software image is located, either on the product CD-ROM or at a hard disk

location where you have previously copied it. The tool will Installations Pristine 17. propose a Destination Path which you are strongly advised not to alter. Click OK to save the settings and return to the code server object dialog. 9. Repeat steps 7 and 8 for each of the additional required software items. 10. Click the Apply button to update the object. A syntax check is performed to ensure the paths you have entered are valid and that there is enough room for the operating system and software images in the destination folder. If the destination folder is not found after this check, it is created. The platform name and the object name is displayed in the Code Server created list. 11. Click Add if you want to create another code server object, and the New Code Server Object dialog is displayed (go back to step 3 on page 524); or click OK to return to the Pristine tool main menu.

Note: If you add another code server object, you must choose an OS/2 platform from the Operating System drop-down list in the code server window.

Tivoli Software Distribution User’s Guide 525 Pristine Installations on OS/2: Code Server Objects

Deleting a Code Server Object To delete a code server object perform the following steps: 1. Select a code server object in the Main dialog and then select Tools → Code Server. 2. Select the object you want to delete from the Code Server created list and click Delete → Apply. A confirmation dialog box appears. Click Yes. The object is deleted. 3. Click OK to return to the main menu. Step 3: Adding System Files to Code Server Objects For each code server object you will need to add certain system files. In the examples below, the code server object folder (as entered in the Destination path field in step 4 on page 524) is shown as C:\CID. If you have used a different folder you should substitute your folder name. If you have more than one code server object you should apply the commands to each one (except THINSRV, which you run just once with a configuration file modified to refer to all code server objects).

Before commencing, create a folder called log within each code server object folder.

526 Version 4.1 Pristine Installations on OS/2: Adding System Files

THINSRV THINSRV is an MPTS utility that extracts the necessary code server files, verifies supplied parameters, copies the necessary files to the target. In addition, it updates the config.sys and startup.cmd files on the code server workstation to automatically start the code server at system startup.

To use the THINSRV program, perform the following steps: 1. Create the following directory: c:\cid\rsp\srvifs.

2. Before starting THINSRV, create the THINSRV configuration Installations Pristine 17. file, called default.ini, in the c:\cid\rsp\srvifs directory. An example of this file is shown below: Name = MHOLT1 GroupName = NO Adapter = 0 MaxClients = 50 MaxFiles = 100 ClientWorkers = 12 Path = c:\cid PermitWrite = NO PerClient = NO ; alias = ReadWrite,single,log,c:\cid\log

Note: The folder in the Path statement is the folder where your code server object has been created. If you have more than one code server object you should add aliases for the other code server objects and their log folders to the bottom of this file. 3. Enter the following command in the command line: thinsrv /r:c:\cid\rsp\srvifs\default.ini /t:c:\srvifs /s:c:\cid\img\srvifs /tu:c:\ /l1:c:\cid\log\thinsrv.log

This command copies the necessary code server files into the c:\srvifs directory. It also creates a valid default.ini file based on the response file named in the /r parameter.

Note: The two characters after the slash at the beginning of the third line of the command as shown here are ell one.

Tivoli Software Distribution User’s Guide 527 Pristine Installations on OS/2: Adding System Files

4. If you are using OS/2 Version 4.5, you must add the following lines to c:\startup.cmd: cd srvifs service.exe /INI:default

Configuring MPTS for Non-standard Network Adapters If a client system is using a network adapter that is unsupported by MPTS, for each created code server object you must update the MACS.ZIP file located in the C:\CID\IMG\MPTS\IBMCOM\MACS folder. To do this, perform the following steps: 1. Create a temporary directory in the root of the Code Server. In this example it is ‘macstemp’. 2. From within the macs folder, enter the following in the command line: pkunzip2 -d macs.zip c:\macstemp

The contents of the MACS.ZIP archive are now unpacked to c:\macstemp. A number of subdirectories are now present under c:\macstemp. 3. Open c:\macstemp\ibmcom\macs and copy all the files required for your network adapter into this folder. 4. Rebuild a new MACS.ZIP archive by entering the following: pkzip2 -rp macs.zip c:\macstemp\*.* 5. Copy the new MACS.ZIP archive back into C:\CID\IMG\MPTS\IBMCOM\MACS folder, overwriting the old archive.

GETREXX REXX is required on the code server to run the LCU REXX command files used to install the requested products. Because the client workstation accesses the LCU command files from a redirected drive, it makes sense to access the required files for REXX from the code server. In this way, the required REXX modules do not have to be on the original boot diskettes.

528 Version 4.1 Pristine Installations on OS/2: Adding System Files

GETREXX enables the REXX modules to be copied from the OS/2 images to the code server executable directory and it is executed from the command line when you enter the following command: c:\cid\img\locinstu\getrexx c:\cid\img\os2image c:\cid\exe Step 4: Creating and Maintaining Code Server Object Configurations For every code server object created you must create at least one configuration, which tells the pristine installation process how to

configure the new operating system. The following actions are Installations Pristine 17. possible: ¶ “Customizing the Operating System Response File” ¶ “Customizing the Additional Required Software Response Files” on page 531 ¶ “Adding Device Drivers” on page 531 ¶ “Partitioning the Client Hard Disk” on page 531 ¶ “Defining a Reference Model” on page 532 ¶ “Adding Configuration-specific Information” on page 532

Customizing the Operating System Response File The pristine tool provides you with an easy way to customize the response files that determine how the operating system will be installed. The default response files are located in the Pristine tool’s RSP subdirectory. These files can be edited using a text editor if you want to change the default values offered in the tool. 1. From the Pristine tool main dialog, see the list of available code server objects by double-clicking the platform name. Select the object you want to configure. 2. Select File → New Configuration. The Pristine Configuration dialog is displayed. 3. Enter a name for the configuration and click OK. The Configuration dialog is displayed. This dialog lets you customize the operating system response file. The left panel lists all of the sections in the response file. Select a section and its installation keys and their default values are displayed in the right panel. Full details of the sections and keys and their meaning should be found in the documentation for the operating system.

Tivoli Software Distribution User’s Guide 529 Pristine Installations on OS/2: Configurations

Note: To select a section you are recommended to double-click on the section name; a single click may be sufficient, but on certain platforms the Java code that controls the user interface does not always respond to a single click 4. To change the value of an installation key: ¶ Select a section. ¶ Double-click on the key for which the value is to be changed. The Installation Key dialog is displayed. ¶ Edit the displayed value. ¶ Click OK to return to the Configuration dialog. 5. To add, remove or rename installation keys, do the following: a. Select a section. b. Select an installation key (you do not have to do this if you are only adding a new key). c. Select Edit Key → Key → New, Delete or Rename d. The appropriate dialog will be displayed allowing you to add, delete or rename the key, as appropriate. e. Click OK to save the settings you have made and to return to the Configuration dialog.

Note: While for many of the keys you can use their factory defaults, your attention is particularly drawn to the keys for the installation path, the gateway port and the endpoint port which must be completed for the operating system and for the additional required software. 6. To add, remove or rename installation section names, do the following: a. Select the section (you do not have to do this if you are only adding a new section). b. Select Edit Key → Section → New, Delete or Rename. 7. Click OK to save the settings you have made and to return to the Main dialog.

530 Version 4.1 Pristine Installations on OS/2: Configurations

Customizing the Additional Required Software Response Files From the Configuration dialog click on the No Product pull-down and select one of the additional required software items. The response file sections and keys for this product will be displayed and can be customized as described for the operating system response file, above.

Repeat this action for each of the items in the pull-down.

Adding Device Drivers Installations Pristine 17. For OS/2, device drivers are not added using the Pristine tool. Instead you have already added them in Step 3: see “Configuring MPTS for Non-standard Network Adapters” on page 528.

Partitioning the Client Hard Disk You must define the partitions on the hard disks of the pristine system. Up to two hard disks can be partitioned. The steps are as follows: 1. Select Configuration → Prepare hard disk. The Disk Partitioning dialog is displayed: There are tabs for each of two physical volumes. On the first volume there is a default definition of a primary partition, with the drive letter C, of 2000 megabytes. 2. To change the primary partition size click on Size and change the value. 3. To add a partition, click Add,. A new partition is created, with a default size of 2000 megabytes, using the next available drive letter. The Partition type defaults to Logical, but can be changed by clicking on the Partition type of the partition in question. The total of all partitions created is shown in the box at bottom right. To change the partition size click on Size and change the value. 4. Click OK to save the partitioning details and return to the Configurations dialog. Remove a partition by selecting the partition and clicking Remove and then OK.

Tivoli Software Distribution User’s Guide 531 Pristine Installations on OS/2: Configurations

Defining a Reference Model In order to use Change Control Management on the pristine system you are given the option of defining a reference model. The steps are as follows: 1. Select Configuration → Reference Model. The Reference Model dialog is displayed: 2. Enter the reference model name and/or version. 3. Click OK to save the reference model definition and return to the Configurations dialog. Remove a reference model definition by clicking Remove and then OK.

Adding Configuration-specific Information Configuration-specific information can be added to the configuration. The steps are as follows: 1. Select Configuration → Information. The Information dialog is displayed. 2. Enter the required information. 3. Click OK to save the information and return to the Configurations dialog. Step 5: Preparing the System Diskettes To prepare the system diskettes you need to use the OS/2 system utilities SEDISK, THINLAPS, THINIFS and CASINSTL. In the examples below, the code server object folder (as entered in the Destination path field in step 4 on page 524) is shown as c:\cid. If you have used a different folder you should substitute your folder name.

SEDISK SEDISK is an OS/2 utility that creates the system diskettes for starting the pristine system. By default, the diskettes have no LAN transport drivers or redirector code; these are added at a later stage.

The SEDISK tool requires three formatted diskettes.

532 Version 4.1 Pristine Installations on OS/2: System Diskettes

To use SEDISK, perform the following steps: 1. In the directory where the SEDISK utility is located, launch SEDISK by entering the following: SEDISK /S: /T: /S: Fully qualified source path to the OS/2 disk images, which can be on a local hard drive or a redirected drive. /T: Target drive (usually the A: drive). 2. Here is an example of how you use SEDISK to create a start disk: Installations Pristine 17. sedisk /s:c:\cid\img\os2image /t:A:

This command launches SEDISK and creates three start diskettes using the OS/2 disk image in c:\cid\img\os2image.

Adding the LAN Transport Driver with THINLAPS You must add the appropriate network driver files to the start diskette. For this procedure, use THINLAPS: 1. From the three floppy disks you have created, insert the third diskette into the drive and enter the following command: thinlaps c:\cid\img\mpts A: .nif

Where .nif is the filename that corresponds to the network adapter driver file that is stored on the target. 2. When asked for another disk, insert the second diskette (from the set of three) into the floppy drive.

THINIFS and SRVIFS THINIFS is an OS/2 utility that places all the necessary SRVIFS redirection files on the LAN transport diskette. SRVIFS is a small NetBIOS-based file server and requestor, which is shipped with MPTS. SRVIFS provides redirected I/O support to enable client access to a Code Server. This is a subset of the function provided by the LAN Server. Run THINIFS by doing the following:

Tivoli Software Distribution User’s Guide 533 Pristine Installations on OS/2: System Diskettes

1. From the set of three disks, insert the third disk you created into the drive and enter the following command from the command prompt: thinfs /s:c:\cid\img\srvifs /t:A:\ /srv: /req: /D:X /tu:A:\

When requested insert the second diskette.

This provides the pristine system with the necessary information to connect to default directory on the code server. If you have a different directory you should modify the command accordingly. 2. Ensure that the LOG directory is read/write enabled, insert the third system diskette and enter the following to create an association between c:\cid\log and the client write drive: thinfs /s:c:\cid\img\srvifs /t:A:\ /srv:\\\log /req: /D:Y /tu:A:\

Adding the LAN CID Utility The LAN Configuration Installation and Distribution Utility (LCU), which is integrated with MPTS, enables you to chain together a series of CID installs. For example, an end user may require OS/2, MPTS, and LAN Server V5.0 to be installed. Once configured, this utility automatically installs all of these programs in one step.

CASINSTL This utility installs the LAN CID Utility on the system diskettes and is available from c:\cid\img\locinstu.

To execute the CASINSTL program, insert the third system diskette and enter the following statement in the command line: casinstl /tu:A:\ /cmd:X:\clients\ /D /l2:Y:\srvifs_req.log /pa:X:\img\locinstu /pl:X:\exe;X:\img\locinstu; /0 /req: Step 6: Creating Pristine Boot Diskettes When you have created at least one configuration for a code server object (see “Step 4: Creating and Maintaining Code Server Object Configurations” on page 529) and have prepared a set of system diskettes (see “Step 5: Preparing the System Diskettes” on page 532),

534 Version 4.1 Pristine Installations on OS/2: Boot Diskettes

you can use the Pristine tool to transform the prepared system diskettes into a set of pristine boot diskettes.

Note: This procedure, while being an essential step in the preparation for a pristine installation, may not need to update the system diskettes to create boot diskettes; thus, although you should have the system diskettes available you may not be asked to insert them. 1. Ensure you are logged on to the LAN by issuing the following

commands to start the LAN requester service: Installations Pristine 17. ¶ For OS/2, Version 4.0 type: net share ¶ For OS/2, Version 4.5 type: logon root /P:passwd /V:LOCAL 2. From the toolbar, click Tools → Create Boot Diskettes. The Create Boot Diskettes dialog is displayed. 3. If requested, place one of the diskettes you created in “Step 5: Preparing the System Diskettes” on page 532, into the diskette drive. 4. Complete the following fields: Server name Hostname of the code server Client boot drive Drive letter of the drive from which the pristine system will normally boot up Client source drive Drive letter of the drive to which the shared code server folder will be mapped Client log drive Drive letter of the drive to which the code server log will be mapped

These value should correspond to those supplied in the above utilities.

Tivoli Software Distribution User’s Guide 535 Pristine Installations on OS/2: Boot Diskettes

5. Click OK. The Pristine tool completes the preparation of the code server object configuration, and, if necessary, writes data also to the system diskette. Step 7: Running a Pristine Installation When you have completed the preparation of the set of pristine boot diskettes for a system or group of systems (see “Step 6: Creating Pristine Boot Diskettes” on page 534), you can commence a pristine installation. The installation procedure carries out the following operations: ¶ It uses the boot diskettes to start up the pristine system and load a minimum system configuration into memory ¶ It installs the necessary protocols to connect itself into the network and to locate the code server ¶ Using the configuration information it partitions the hard disks and commences to download and install the operating system software, using the response file to drive the installation ¶ Each system, or group of systems is assigned to a dedicated Tivoli gateway ¶ If the Code Server Object configuration contains a Reference Model, and on the gateway a specific Login-Policy has been activated, a CCM operation will be started

When these activities are completed, the new endpoint must be migrated from the dedicated pristine gateway to a normal gateway.

Pristine Installation Procedure At least one person must be present where the pristine systems are located. The tasks executed locally are: ¶ Starting the system ¶ Removing the diskettes when necessary ¶ Restarting the system if required

Once the diskettes are ready and delivered to the person performing the local installation, the installation process can begin.

536 Version 4.1 Pristine Installations on OS/2: Running Installation

When the first Tivoli management agent login is connected, an automatic notification of the presence of a new machine in the Tivoli management region takes place.

If you have defined a reference model you should ensure that the CCM component of Tivoli Software Distribution is activated, in order to compare the new system to the appropriate reference model and to start the specific action. This action completes the pristine installation process.

Note: If you want to use a reference model to install Tivoli Installations Pristine 17. Software Distribution, you should remember to install any prerequisite software.

The final step is for the pristine system administrator, who must, after all installation processes are completed, migrate the new endpoint from the dedicated pristine gateway to a normal gateway.

Tivoli Software Distribution User’s Guide 537 538 Version 4.1 18 Upgrading Windows NT 4.0 Workstation to Windows 2000 Professional

This scenario explains how to use Tivoli Software Distribution, Version 4.1 to upgrade software from Windows NT 4.0 Workstation to Windows 2000 Professional.

This scenario consists of the following procedures: T40t idw 2000 Windows to 4.0 NT ¶ Creating the response file appropriate for your environment Windows Upgrading 18. ¶ Copying the files that you need to perform the migration to the Tivoli management region server (Tivoli server) ¶ Copying the Windows 2000 files to the image server ¶ Customizing the inst_w2000.spd software package definition file ¶ Creating the software package on the Tivoli server ¶ Subscribing the endpoints to the upgrades profile manager ¶ Distributing the software package to the Tivoli endpoints ¶ Using the check_OS^1.0.spd software package definition file to verify the upgrade

Environment Configuration To complete this scenario, you must have the following environment:

Tivoli Software Distribution User’s Guide 539 Upgrading Windows NT 4.0

¶ A Windows 2000 Professional workstation with the Resource Kit 2000 installed. ¶ A Tivoli server on which to prepare and pack the software package. ¶ An image server on which to store the Windows 2000 Professional operating system files. ¶ The target workstations with Windows NT 4.0 installed. You must define the target workstations as Tivoli Software Distribution endpoints.

Creating a Response File

Note: Refer to the Microsoft Windows 2000 Resource Kit documentation for a detailed explanation of the procedure for creating a response file.

Tivoli Software Distribution, Version 4.1 provides an example of a response file that you must customize to suit your environment. Create a response file appropriate for your environment using the Windows 2000 Setup Manager Wizard or customize the following unattend.txt response file that is provided in the CD-ROM directory \package\msosupg\Unattended.txt: upgrading from Windows NT to Windows 2000

;SetupMgrTag [Data] AutoPartition=1 MsDosInitiated="0" UnattendedInstall="Yes"

[Unattended] UnattendMode=FullUnattended OemSkipEula=Yes OemPreinstall=No NtUpgrade=Yes

[GuiUnattended] AdminPassword=* OEMSkipRegional=1 TimeZone=110 OemSkipWelcome=1

540 Version 4.1 Upgrading Windows NT 4.0

AutoLogon=Yes

[UserData] FullName=Administrator OrgName=WORKGROUP ComputerName=*

[Identification] JoinWorkgroup=WORKGROUP

[Networking] InstallDefaultComponents=Yes

Copying the Files That You Need to Perform the Migration to the Tivoli Server To perform the Windows NT 4.0 Workstation to Windows 2000 professional migration you must copy the following files that are contained in the Tivoli Software Distribution, Version 4.1 CD-ROM to the Tivoli server. ¶ inst_w2000.spd ¶ Unattended.txt T40t idw 2000 Windows to 4.0 NT 8 prdn Windows Upgrading 18. Note: You can use the response file that you created in “Creating a Response File” on page 540 instead of this file. ¶ check.bat ¶ check_OS.spd To copy these files from the CD-ROM to the Tivoli Server, perform the following steps on the Tivoli server: 1. Create a directory in which to store the files. This scenario uses the upgnt_00 directory. 2. Copy the inst_w2000.spd, the Unattended.txt, the check_OS.spd and the check.bat files: ¶ For UNIX, copy the files from the CD-ROM_drive/package/msosupg/upgrNTtoW2000 directory to the /upgnt_00 directory on your Tivoli server by entering the following commands from the /upgnt_00 directory:

Tivoli Software Distribution User’s Guide 541 Upgrading Windows NT 4.0

cp /package/msosupg/upgrNTtoW2000/inst_w2000.spd . cp /package/msosupg/upgrNTtoW2000/Unattended.txt . cp /package/msosupg/upgrNTtoW2000/check_OS.spd . cp /package/msosupg/upgrNTtoW2000/check.bat . ¶ For Windows, copy the files from the :\package\msosupg\upgrNTtoW2000 directory to the \upgnt_00 directory on your Tivoli server by entering the following command from the drive\upgnt_00 directory: copy :\package\msosupg\upgrNTtoW2000\inst_w2000.spd copy :\package\msosupg\upgrNTtoW2000\Unattended.txt copy :\package \msosupg\upgrNTtoW2000\check_OS.spd copy :\package \msosupg\upgrNTtoW2000\check.bat

Copying the Windows 2000 Professional Files to the Image Server To copy the Windows 2000 Professional files to the image server, follow these steps: 1. Create a directory called shared on the C: drive of the image server. 2. Start the regedt32.exe registry editor. The Registry Editor - HKEY_ LOCAL_ MACHINE dialog displays. 3. From the HKEY_LOCAL_MACHINE subtree, select System→CurrentControlSet→Services→LanmanServer→ Parameters→NullSessionShares. 4. Select NullSessionShares. The Multi-String Editor dialog displays. 5. Enter shared and click OK. 6. Share the c:\shared directory with the target workstations that you want to upgrade from Windows NT 4.0 Workstation to Windows 2000 Professional by entering the following command: net share shared=c:\shared

542 Version 4.1 Upgrading Windows NT 4.0

7. Create the Win2000 directory under the c:\shared directory. 8. Copy the Windows 2000 Professional source files from the Windows 2000 Professional CD-ROM to the c:\shared\win2000 directory on the image server by entering the following command: xcopy :\\*.* c:\shared\win2000\*.* /s/e

where win2000source is the Windows 2000 Professional CD-ROM directory that contains the operating system source files. 9. Copy the unattended.txt response file or the response file that you created in “Creating a Response File” on page 540 to c:\shared\win2000.

Customizing the inst_w2000.spd Software Package Definition File Use the inst_w2000.spd software package definition file to upgrade Windows NT 4.0 Workstation to Windows 2000 Professional. T40t idw 2000 Windows to 4.0 NT Customize the inst_w2000.spd software package definition file by Windows Upgrading 18. specifying the \\ImageServer\shared\win2000 in the sp_path, where ImageServer is the name of the server where the image of the Windows 2000 Professional operating system is located. The inst_w2000.spd software package definition file follows: ”TIVOLI Software Package v4.1 - SPDF" package name = "Inst_w2000" title = "Install Windows 2000" version = "1.0" undoable = "o" committable = "o" history_reset = n save_default_variables = n creation_time = "2000-05-12 18:10:19" last_modification_time = "2000-05-12 18:14:08"

default_variables sp_path = "\\ImageServer\shared\win2000" end

Tivoli Software Distribution User’s Guide 543 Upgrading Windows NT 4.0

execute_user_program transactional = n

during_install

exit_codes success = 0,0 failure = 1,65535 end

path = "$(sp_path)\i386\winnt32" arguments = "/unattented:$(sp_path)\unattend.txt /s:$(sp_path)\i386" timeout = 7200 unix_user_id = 0 unix_group_id = 0 user_input_required = n output_file_append = n error_file_append = n reporting_stdout_on_server = y reporting_stderr_on_server = y max_stdout_size = 10000 max_stderr_size = 10000 bootable = y retry = 1 end

end

Creating the Software Package on the Tivoli Server Before creating a software package, you must create on the Tivoli server a profile manager that contains the software package and a directory path in which to store the software package block. Refer to the Tivoli Management Framework User’s Guide to learn how to create a profile manager. This scenario assumes that you created the upgrades profile manager and the packages directory path in which to store the inst_w2000.spb software package block in the Tivoli server. To create and build the software package on the Tivoli server, enter the following command: ¶ In a UNIX environment: wimpspo -c @upgrades -f /upgnt_00/inst_w2000.spd -t build -p /packages/inst_w2000.spb @inst_w2000^1.0

544 Version 4.1 Upgrading Windows NT 4.0

¶ In a Windows environment: wimpspo -c @upgrades -f c:\upgnt_00\inst_w2000.spd -t build -p c:\packages\inst_w2000.spd @inst_w2000^^1.0

This command does the following: v Creates the inst_w2000^1.0 software package object that is based on the c:\upgnt_00\inst_w2000.spd software package definition file v Builds a software package block v Writes the software package block in the packages directory

Subscribing the Endpoints to the Upgrades Profile Manager Subscribe the Tivoli Software Distribution endpoints to the upgrades profile manager by entering the following command from the Tivoli server: wsub @upgrades @Endpoint:target1 @Endpoint:target2 ... @Endpoint:targetn T40t idw 2000 Windows to 4.0 NT Where target1, target2, ..., targetn are the Tivoli Software Windows Upgrading 18. Distribution endpoints that you want to subscribe.

Distributing the Software Package to the Tivoli Software Distribution Endpoints To distribute the software package to the Tivoli Software Distribution endpoints, enter the following command from the Tivoli server: ¶ In a UNIX environment: winstsp @inst_w2000^1.0 @target1 @target2 ... @targetn ¶ In a Windows environment: winstsp @inst_w2000^^1.0 @target1 @target2 ... @targetn Where target1, target2, ..., targetn are the Tivoli Software Distribution endpoints on which you want to install Windows 2000 Professional. You can also create a profile manager that contains all the targets to upgrade and specify the name of the profile manager in

Tivoli Software Distribution User’s Guide 545 Upgrading Windows NT 4.0

the winstsp command. In a Windows environment, for example, if you created the win_targets profile manager, enter the following command: winstsp @inst_w2000^^1.0 @win_targets

After you enter one of the previous commands, the upgrade process starts on the Tivoli Software Distribution endpoints. When the distribution of the software package ends, the targets reboot.

Using the check_OS^1.0.spd to Verify the Upgrade Using the check_OS^1.0.spd you can verify if the Windows 2000 Professional has been installed in your environment. To perform this check perform the following steps: 1. Create and build the check_OS^1.0.spd software package on the Tivoli server, by entering the following command: ¶ In a UNIX environment: wimpspo -c @upgrades -f /upgnt_00/check_OS.spd -t build -p /packages/check_OS.spb @check_OS^1.0 ¶ In a Windows environment: wimpspo -c @upgrades -f c:\upgnt_00\check_OS.spd -t build -p c:\packages\check_OS.spd @check_OS^^1.0 2. Distribute the check_OS^1.0 software package to the Tivoli Software Distribution endpoints, by entering the following command from the Tivoli server: ¶ In a UNIX environment: winstsp @check_OS^1.0 @target1 @target2 ... @targetn ¶ In a Windows environment: winstsp @check_OS^^1.0 @target1 @target2 ... @targetn Where target1, target2, ..., targetn are the Tivoli Software Distribution endpoints on which you want to install Windows 2000 Professional. You can also create a profile manager that contains all the targets to check and specify the name of the profile manager in the winstsp command. In a Windows environment, for example, if you created the win_targets profile manager, enter the following command:

546 Version 4.1 Upgrading Windows NT 4.0

winstsp @check_OS^^1.0 @win_targets

After you enter one of the previous commands, the check process starts on the Tivoli Software Distribution endpoints. When the distribution of the software package ends, verify that the operating system indicated in the standard output section of the check_OS.log file is Windows 2000. T40t idw 2000 Windows to 4.0 NT 8 prdn Windows Upgrading 18.

Tivoli Software Distribution User’s Guide 547 Upgrading Windows NT 4.0

548 Version 4.1 9 prdn Windows Upgrading 19. Twt evc Pack Service a with NT 19 Upgrading Windows NT 4.0 with Service Pack 5 or 6

This scenario explains how to use Tivoli Software Distribution, Version 4.1 to upgrade a Windows NT 4.0 system to Service Pack 5 or Service Pack 6.

This scenario consists of the following procedures: ¶ Downloading the ntspx.spd definition file to the Tivoli management region server (Tivoli server) ¶ Copying the Service Pack files to the image server ¶ Customizing the ntspx.spd software package definition File ¶ Creating the software package on the Tivoli server ¶ Subscribing the endpoints to the upgrades profile manager ¶ Distributing the software package to the Tivoli Software Distribution endpoints

Environment Configuration To complete this scenario, you must have the following environment: ¶ A Tivoli server on which to prepare and pack the software package files. ¶ An image server on which to store the Service Pack files. In this scenario, the image server is a Windows NT workstation.

Tivoli Software Distribution User’s Guide 549 Upgrading Windows NT with a Service Pack

¶ The target workstations with Windows NT 4.0 installed. You must define the target workstations as Tivoli Software Distribution endpoints.

Downloading the ntspx.spd Definition File to the Tivoli Server

Note: Depending on which Service Pack you are installing, substitute the x variable either with 5 (for Service Pack 5) or 6 (for Service Pack 6).

To upgrade Windows NT 4.0 to Windows NT 4.0 with Service Pack, use the ntspx.spd definition file that is contained in the Tivoli Software Distribution, Version 4.1 CD-ROM. To download the ntspx.spd definition file from the CD-ROM to the Tivoli server, perform the following steps on the Tivoli server: 1. Create a directory in which to store the ntspx.spd definition file, for example the servpackx directory. 2. Copy the file: ¶ For UNIX, copy the file from CD-ROM_drive/package/msosupg/nt40srvpack directory to the /servpackx directory on your Tivoli server, by entering the following command from the /servpackx directory: cp : /package/msosupg/nt40srvpack/ntspx.spd . ¶ For Windows, copy the file from the CD-ROM_drive:\package\msosupg\nt40srvpack directory to the \servpackx directory on your Tivoli server by entering the following command from the \servpackx directory: copy :/package\msosupg\nt40srvpack\ntspx.spd

The ntspx.spd file is downloaded to the Tivoli server.

550 Version 4.1 Upgrading Windows NT with a Service Pack 9 prdn Windows Upgrading 19. Twt evc Pack Service a with NT Copying the Service Pack Files to the Image Server To copy the Service Pack files to the image server, follow these steps: 1. Create the shared directory on the C: drive of the image server. 2. Start the regedt32.exe registry editor. The Registry Editor - HKEY_ LOCAL_ MACHINE dialog displays. 3. From the HKEY_LOCAL_MACHINE subtree, select System→CurrentControlSet→Services→LanmanServer→ Parameters→NullSessionShares. 4. Select NullSessionShares.The Multi-String Editor dialog displays. 5. Enter shared and click OK. 6. Share the c:\shared directory with the target workstations that you want to upgrade from Windows NT 4.0 to Windows NT 4.0 with Service Pack by entering the following command: net share shared=c:\shared 7. Copy the spxi386.exe Service Pack executable file to the c:\shared\wint40sp directory previously created on the image server. 8. Extract the Service Pack files by entering the following command: spxi386.exe /x

The Choose Directory for Extracting Files dialog appears. 9. Enter c:\shared\spx in the Choose Directory for Extracting Files text box. The c:\shared\spx directory is the image server directory from which you extract the Service Pack files.

Tivoli Software Distribution User’s Guide 551 Upgrading Windows NT with a Service Pack Customizing the ntspx.spd Software Package Definition File Customize the ntspx.spd software package definition file by specifying \\ImageServer\shared in the sp_path variable, where ImageServer is the name of the server where the image is located.

The ntspx.spd software package definition file follows: #"TIVOLI Software Package v4.1 - SPDF" package Name = "ntspx" Title = "Install Service Pack for Windows NT 4.0" Copyright = "Tivoli Software Distribution Systems" Version = "1.0" web_view_mode = "hidden" undoable = “o” committable = “o” history_reset = n save_default_variables =n creation_time = “2001-02-02 18:10:19” last_modification_time = “2001-02-02 128:14:08” default_variables sp_path = “\\ImageServer\shared” end move_removing_host =y no_check_source_host =y lenient_distribution = n default_operation = “install” server_mode = “all” operation_mode = "not_transactional" log_mode = “0” log_user_id 0 post_notice = n before_as_uid =0 skip_non_zero = n after_as_uid = 0 no_chk_on_rm = n log_gid = 0 versioning_type = "swd" package_type = "refresh" stop_on_failure = y

execute_user_program transactional = n

during_install

exit codes

552 Version 4.1 Upgrading Windows NT with a Service Pack 9 prdn Windows Upgrading 19. Twt evc Pack Service a with NT

success = 0,0 failure = 1,65535 end

path = ”$(sp_path)\spx\update\update.exe” arguments = “-u -f -o -q” timeout = 2400 unix_user_id = 0 unix_group_id = 0 user_input_required = n output_file_append = n error_file_append = n reporting_stdout_on_server = y reporting_stderr_on_server = y max_stdout_size = 10000 max_stderr_size = 10000 bootable = y retry=1

corequisite_files end end end

This table explains the meaning of the argument values that you can specify in the above example:

Argument Values Description u Runs the installation in unattended mode. f Forces other applications to close at shutdown. n Does not back up the files for the uninstall operation. o Overwrites the OEM files without prompting. z Does not reboot when the installation is complete. q Quiet mode. The installation does not require any user intervention.

Tivoli Software Distribution User’s Guide 553 Upgrading Windows NT with a Service Pack Creating the Software Package on the Tivoli Server Before creating a software package, you must create on the Tivoli server a profile manager that contains the software package and a directory path in which to store the software package block. Refer to the Tivoli Management Framework Planning and Deployment Guide to learn how to create a profile manager. This scenario assumes that you created the upgrades profile manager and the packages directory path in which to store the ntspx.spb software package block in the Tivoli server.

To create and build the software package on the Tivoli server, enter the following command: ¶ In a UNIX environment: wimpspo -c @upgrades -f /servpackx/ntspx.spd -t build -p /packages/ntspx.spb @ntspx^1.0 ¶ In a Windows environment: wimpspo -c @upgrades -f c:\servpackx\ntspx.spd -t build -p c:\packages\ntspx.spb @ntspx^^1.0 This command does the following: ¶ Creates the ntspx^1.0 software package object that is based on the ntspx.spd software package definition file. ¶ Builds a software package block. ¶ Writes the software package block in the packages directory.

Subscribing the Endpoints to the Upgrades Profile Manager Subscribe the Tivoli Software Distribution endpoints to the Upgrades profile manager by entering the following command from the Tivoli server: wsub @upgrades @Endpoint:target1 @Endpoint:target2 ... @Endpoint:targetn

Where target1, target2, ..., targetn are the Tivoli Software Distribution endpoints that you want to subscribe.

554 Version 4.1 Upgrading Windows NT with a Service Pack 9 prdn Windows Upgrading 19. Twt evc Pack Service a with NT Distributing the Software Package to the Tivoli Software Distribution Endpoints To distribute the software package to the Tivoli Software Distribution endpoints, enter the following command from the Tivoli server: ¶ In a UNIX environment: winstsp @ntspx^1.0 @target1 @target2 ... @targetn ¶ In a Windows environment: winstsp @ntspx^^1.0 @target1 @target2 ... @targetn Where target1, target2, ..., targetn are the Tivoli Software Distribution endpoints on which you want to install Service Pack. You can also create a profile manager that contains all the targets to upgrade and specify the name of the profile manager in the winstsp command. For example, in a Windows environment, if you created the win_targets profile manager, enter the following command: winstsp @ntspx^^1.0 @win_targets

After you enter one of the previous commands, the upgrade process starts on the Tivoli Software Distribution endpoints. When the distribution of the software package ends, the targets reboot.

Tivoli Software Distribution User’s Guide 555 556 Version 4.1 A Authorization Roles

This appendix contains tables that describe the roles you need to perform Tivoli Software Distribution operations.

To perform system administration operations from within the Tivoli environment, you must be a Tivoli administrator. Depending on the operations you are required to perform, you can have one or more of the following roles: ¶ Super ¶ Senior ¶ Admin ¶ User ¶ Install-product

Setting Up Tivoli Software Distribution Profiles The following table lists the roles required to set up software package profiles:

Operation Context Required Role .AtoiainRoles Authorization A. Install Tivoli Software Desktop view for root super or install-product Distribution Create a software Profile manager senior or super package profile

Tivoli Software Distribution User’s Guide 557 Authorization Roles

Operation Context Required Role Clone a software Profile manager senior or super package profile View a software Software package user, admin, senior, or package profile super Subscribe resources to Profile manager policy admin, senior, or super a profile manager region —AND— Subscriber policy region

Defining and Deleting Profiles The following table lists the roles required to define a software package by setting its properties and to view configuration information:

Operation Context Required Role Export a software Software package user, admin, senior, or package definition file super Set or edit software Software package admin, senior, or super package profile properties Import a software Software package admin, senior, or super package definition file Delete a software Software package senior or super package profile View/modify a software Software package admin, senior, or super package profile (using the Software Package Editor)

558 Version 4.1 Authorization Roles Performing Operations The following table lists the role required to distribute a software package:

Operation Context Required Role Distribute a software Profile manager policy admin, senior, or super package profile region —AND— Subscriber policy region Schedule a software Profile manager policy admin, senior, or super package profile region —AND— distribution Subscriber policy region Calculate the size of a Profile manager policy admin, senior, or super software package region profile Remove a software Software package admin, senior, or super package profile from a subscriber

Performing Activity Planner Operations The following table lists the role required to perform Activity Planner operations:

Operation Context Required Role Import an activity plan Activity plans APM_Edit into the activity plan database Delete an activity plan Activity plans from the activity plan

database Roles Authorization A.

Tivoli Software Distribution User’s Guide 559 Authorization Roles

Operation Context Required Role Submit an activity plan Activity plans APM_Manage for execution Cancel, pause, resume, Activities and activity and restart activities or plans the activity plan Clean up submitted Activity plans activity plans from the activity plan database Remove the status of Activity plans activity plan from the activity plan database Return a list of activity Activity plans APM_View plans maintained in the activity plan database Output an activity plan Activity plan in the activity plan definition file format Display the status of a Activity plan submitted activity plan

560 Version 4.1 Authorization Roles

Operation Context Required Role Display current error Activity plan APM_Admin level mapping Map error levels to Activity plans return codes Delete mapping of error Activity plans levels and reset default values Display a list of locked Activity plans plans and unlock plans currently locked Start and stop Activity Activity Planner feature Planner engine Display and change the Activity Planner feature RIM object name Change the user Activity Planner feature password that enables the Activity Planner engine to function properly .AtoiainRoles Authorization A.

Tivoli Software Distribution User’s Guide 561 Authorization Roles Performing CCM Operations The following table lists the role required to perform CCM operations:

Operation Context Required Role Load a reference model Reference model CCM_View Import a reference Reference model model Export a reference Reference model model View the component Reference model properties of a reference model Search for a reference Reference model model Lock the children of a Reference model reference model Hide the children of a Reference model reference model Arrange the child Reference model reference models horizontally or vertically Preview the actions Reference model Access help Change Configuration Management GUI Access product Change Configuration information Management GUI

562 Version 4.1 Authorization Roles

Operation Context Required Role Save the changes to reference model CCM_Manage reference models Restore the reference reference model models from the database Add a new element, reference model subscriber, or dependency Modify a new element, reference model subscriber, or dependency Remove an element, reference model subscriber, or dependency Add a new reference reference model model Remove a reference reference model model All operations with the reference model CCM_Edit CCM_Manage role Submit an activity plan activity plan

Performing Web Interface Operations The following table lists the role required to perform Web Interface operations: .AtoiainRoles Authorization A.

Tivoli Software Distribution User’s Guide 563 Authorization Roles

564 Version 4.1 Glossary A

accept operation In Tivoli Software Distribution, Version 4, a change management operation that deletes the backup package so the previous operation can no longer be undone.

action An operation on a managed object, the semantics of which are defined as part of the managed object class definition.

action body In the Tivoli Enterprise Console product, the part of a rule that contains actions to take if the rule evaluates to true.

activity In Tivoli Software Distribution, Version 4.1, an operation that is contained in an activity plan; operations can include Tivoli Software Distribution operations and Tivoli Management Framework task library tasks. Activity definitions include: the operation to be performed, the execution time, the conditions for executing the operation, and the targets of the operation. See activity plan and execution time.

activity plan In Tivoli Software Distribution, Version 4.1, a set of activities performed on a set of targets on a specified schedule. An activity plan specifies: the activities contained in the plan, the schedule for execution, recursion information, notification information, and targets. See also activity.

Activity Plan Editor In Tivoli Software Distribution, Version 4.1, the tool, which has a graphical user interface, that is used to generate or update an activity plan. See also activity plan.

Activity Plan Monitor In Tivoli Software Distribution, Version 4.1, the tool, which has a graphical user interface, that is used to submit, monitor, and control the execution of an activity plan. See also activity plan.

admin role See authorization role.

administrator See Tivoli administrator. Glossary

Tivoli Software Distribution User’s Guide 565 administrator collection In a Tivoli environment, the collection for administrator objects that is generated by Tivoli Enterprise software. This container is represented by the Administrator icon on the Tivoli desktop; opening the icon provides access to information about each Tivoli administrator.

agent (1) In systems management, a user that, for a particular interaction, has assumed an agent role. (2) An entity that represents one or more managed objects by (a) emitting notifications regarding the objects and (b) handling requests from managers for management operations to modify or query the objects. (3) A system that assumes an agent role.

agent role In systems management, a role assumed by a user in which the user is capable of performing management operations on managed objects and of emitting notifications on behalf of managed objects.

authorization (1) In computer security, the right granted to a user to communicate with or make use of a computer system. (2) An access right. (3) The process of granting a user either complete or restricted access to an object, resource, or function.

authorization role In a Tivoli environment, a role assigned to Tivoli administrators to enable them to perform their assigned systems management tasks. A role may be granted over the entire Tivoli management region or over a specific set of resources, such as those contained in a policy region. Examples of authorization roles include: super, senior, admin, and user.

AutoPack In Tivoli Software Distribution, Version 4, a tool that enables a Tivoli administrator to create a software package. AutoPack produces the software package by (a) taking snapshots of the drive and system configuration before and after the installation of an application on a PC and (b) capturing the differences between these snapshots in the software package. C

change management In Tivoli Software Distribution, the process of planning (for example, scheduling) and controlling (for example, distributing, installing, and tracking) software changes over a network.

566 Version 4.1 class In object-oriented design or programming, a model or template that can be instantiated to create objects with a common definition and therefore, common properties, operations, and behavior. An object is an instance of a class.

CLI See command line interface (CLI).

client A computer system or process that requests a service of another computer system or process that is typically referred to as a server. Multiple clients may share access to a common server.

collection In a Tivoli environment, a container that groups objects on a Tivoli desktop, thus providing the Tivoli administrator with a single view of related resources. Either the Tivoli Management Framework or a Tivoli administrator can create a collection. The contents of a collection are referred to as its members. Examples of collections include the administrator collection and the generic collection; the administrator collection is an example of a collection generated by the Tivoli Management Framework.

command line interface (CLI) A type of computer interface in which the input command is a string of text characters. Contrast with graphical user interface (GUI).

commit operation In Tivoli Software Distribution, Version 4, a change management operation that causes all the updates prepared in the preparation phase to take effect.

commit phase In Tivoli Software Distribution, Version 4, the phase of transactional mode operation in which previously prepared actions are committed, causing all of the updates to take effect. See also transactional mode.

configuration repository In a Tivoli environment, a RIM repository that contains information that is collected or generated and stored by Tivoli Inventory and Tivoli Software Distribution. For example, Tivoli Inventory stores information regarding hardware, software, system configuration, and physical inventory; and Tivoli Software Distribution stores information regarding software package and file package operations.

CRC See cyclic redudancy check (CRC). Glossary

Tivoli Software Distribution User’s Guide 567 cyclic redundancy check (CRC) (1) A redundancy check in which the check key is generated by a cyclic algorithm. (2) A system of error checking performed at both the sending and receiving station after a block-check character has been accumulated. D

database mode profile manager See profile manager.

dataless mode profile manager See profile manager.

default policy In a Tivoli environment, a set of resource property values that are assigned to a resource when the resource is created.

deployment management The Tivoli management discipline that addresses the automation of configuration and change management activities for the ever-evolving components of a network computing system.

differencing phase In Tivoli Software Distribution, Version 4, the process by which AutoPack examines and compares before and after snapshots and, for each difference found, generates the related action and adds it to a software package.

disconnected mode In Tivoli SecureWay Global Sign-On, a method of operation that enables users to log on to targets while not connected to a network, such as from laptops while mobile.

disconnected target command In Tivoli Software Distribution, Version 4, a command that is run from the command line of a target system that is not connected to the Tivoli management region server.

discovered software package In Tivoli Software Distribution, Version 4.1, an application that was installed on an endpoint independently of Tivoli Software Distribution and that was later added to the endpoint’s catalog and given a status of “installed and discovered,” using a Tivoli Software Distribution disconnected target command.

Distributed Monitoring proxy See endpoint.

568 Version 4.1 Distribution Status console An MDist 2 interface provided by Tivoli Management Framework that enables administrators to monitor and control distributions across a network. See also MDist 2.

domain That part of a computer network in which the data processing resources are under common control.

domain name In the Internet suite of protocols, a name of a host system. A domain name consists of a sequence of subnames separated by a delimiter character. For example, if the fully qualified domain name (FQDN) of a host system is ralvm7.vnet.ibm.com, each of the following is a domain name: ¶ ralvm7.vnet.ibm.com ¶ vnet.ibm.com ¶ ibm.com

E

endpoint (1) In a Tivoli environment, a Tivoli client that is the ultimate recipient for any type of Tivoli operation. (2) In a Tivoli environment, a Tivoli service that runs on multiple operating systems and performs Tivoli operations on those systems, thereby enabling the Tivoli Management Framework to manage the systems as Tivoli clients.

endpoint gateway See gateway.

endpoint list In a Tivoli environment, a list of all endpoint clients in the Tivoli management region with their assigned gateways. See endpoint manager.

endpoint manager In a Tivoli environment, a service that runs on the Tivoli server, assigns endpoint clients to gateways, and maintains the endpoint list.

endpoint method In a Tivoli environment, a method that runs on an endpoint client as the result of a

request from other managed resources in the Tivoli management region. Results of Glossary the method are forwarded first to the gateway, then to the calling managed resource.

Tivoli Software Distribution User’s Guide 569 event adapter In a Tivoli environment, software that converts events into a format that the Tivoli Enterprise Console product can use, and forwards the events to the event server. Using the Tivoli Event Integration Facility, an organization can develop its own event adapters, tailored to its network environment and specific needs.

event card In Tivoli NetView, a graphical representation, resembling a card, of the information contained in an event sent by an agent to a manager reflecting a change in the status of one of the agent’s managed nodes.

event console In the Tivoli Enterprise Console product, a graphical user interface (GUI) that enables system administrators to view and respond to dispatched events from the event server. The Tivoli Event Integration Facility does not directly use or affect event consoles.

event server In the Tivoli Enterprise Console product, a central server that processes events. The event server creates an entry for each incoming event and evaluates the event against a rule base to determine whether it can respond to or modify the event automatically. The event server also updates the event consoles with the current event information. If the primary event server is not available, events can be sent to a secondary event server.

execution time In Tivoli Software Distribution, Version 4.1, the time frame within which an activity must be executed. Time frame specifications include the days of the week and time intervals within a day. F

fanout In communication, the process of creating copies of a distribution to be delivered locally or to be sent through the network.

file package In Tivoli Software Distribution, Version 3, a profile. The file package describes which files and directories to distribute and how to distribute them.

file package block In Tivoli Software Distribution, Version 3, a static file containing (a) the file package definition, (b) the file package attributes, (c) the source files and directories, and (d) the configuration programs of the file package.

570 Version 4.1 file package definition In Tivoli Software Distribution, Version 3, an ASCII file that identifies the contents and characteristics of a file package.

fpblock See file package block. G

gateway In a Tivoli environment, software running on a managed node that provides all communication services between a group of endpoints and the rest of the Tivoli environment. This gateway includes the multiplexed distribution (MDist) function, enabling it to act as the fanout point for distributions to many endpoints.

generic collection In a Tivoli environment, a collection that contains objects representing resources of any type.

group ID (GID) In the AIX operating system, a number that corresponds to a specific group name. The group ID can often be substituted in commands that take a group name as a value.

group profile In Tivoli User Administration, a profile that a Tivoli administrator uses to define and modify information about a group of users. H

host In a Tivoli environment, a computer that serves as a managed node for a profile distribution. I

install image See Tivoli install image.

install operation In Tivoli Software Distribution, Version 4, a change management operation that

installs a software package on a selected group of targets. Glossary

installation repository (IR) In Tivoli Software Installation Service (SIS), the directory that contains reusable installation images and other data that is used by SIS.

Tivoli Software Distribution User’s Guide 571 IPX Agent In a Tivoli environment, a PC agent that runs on IPX/SPX. An IPX Agent can be the client only of a NetWare-managed site.

IR See installation repository. J

job In a Tivoli environment, a resource consisting of a task and its pre-configured execution parameters. Among other things, the execution parameters specify the set of hosts on which the job is to execute. L

local distribution In a Tivoli environment, a distribution to target machines in the same Tivoli management region as the source machine.

local override In a Tivoli environment, a feature of all profile-based Tivoli applications—except for Tivoli Software Distribution—that allows changes made at the endpoint profile to override those in a distributed profile. M

managed node In a Tivoli environment, any managed resource on which the Tivoli Management Framework is installed.

managed object (1) A component of a system that can be managed by a management application. (2) The systems management view of a resource that can be managed through the use of systems management protocols.

managed resource In a Tivoli environment, any hardware or software entity (machine, service, system, or facility) that is represented by a database object and an icon on the Tivoli desktop. Managed resources must be a supported resource type in a policy region and are subject to a set of rules. Managed resources include, but are not limited to, managed nodes, task libraries, monitors, profiles, and bulletin boards.

572 Version 4.1 management by subscription In a Tivoli environment, the concept of managing network resources by creating sets of profiles and distributing the profiles (through profile managers) to physical entities (Tivoli resources), called subscribers.

management region In Tivoli NetView, the set of managed objects on a particular map that defines the extent of the network that is being actively managed. The management region may vary across maps.

MDist A multiplexed distribution service provided by Tivoli Management Framework that enables efficient transfer of data to multiple targets. See also MDist 2.

MDist 2 A multiplexed distribution service provided by Tivoli Management Framework that enables efficient transfer of data to multiple targets. In addition in the features provided by MDist, MDist2 provides features for monitoring and controlling a distribution throughout its life cycle. See also Distribution status console and MDist.

method In object-oriented design or programming, the software that implements the behavior specified by an operation.

Migration Control Center In Tivoli Software Distribution, Version 4.1, the tool, which has a graphical user interface, that enables system administrators to migrate from the Tivoli NetView Distribution Manager family of products to Tivoli Software Distribution, Version 4.1. The Migration Control Center migrates, for example, change files to software package blocks, procedures to tasks in a task library, and authorization profiles to administrators.

multiplexed distribution (MDist) The mechanism used by Tivoli Enterprise applications to transfer data to multiple targets. Tivoli Management Framework provides two multiplexed distribution services, MDist and MDist 2. See alsoMDist and MDist 2. N

name registry In a Tivoli environment, a name service consisting of a two-dimensional table that maps resource names to resource identifiers and corresponding information within a

Tivoli management region. Glossary

nested software package In Tivoli Software Distribution, Version 4, a software package that is added as an entry to another file package.

Tivoli Software Distribution User’s Guide 573 NetView See Tivoli NetView and Tivoli NetView for OS/390.

NetWare managed site In a Tivoli environment, a resource that represents (a) a Novell NetWare server on which the Tivoli NetWare repeater is installed and (b) one or more clients. A NetWare managed site enables profiles to be distributed through the NetWare server to one or more specified client PCs using either TCP/IP or IPX.

notice In a Tivoli environment, a message generated by a systems management operation that contains information about an event or the status of an application. Notices are stored in notice groups.

notice group In a Tivoli environment, an application- or operation-specific container that stores and displays notices pertaining to specific Tivoli functions. The Tivoli bulletin board is comprised of notice groups. A Tivoli administrator can subscribe to one or more notice groups; the administrator’s bulletin board contains only the notices that reside in a notice group to which the administrator is subscribed.

notification (1) An unscheduled, spontaneously generated report of an event that has occurred. (2) In systems management, information emitted by a managed object relating to an event that has occurred within the managed object, such as a threshold violation or a change in configuration status. O

object In a Tivoli environment, an item that a user can manipulate as a single unit to perform a task. An object can appear as text, an icon, or both.

object path In a Tivoli environment, an absolute or relative path to a Tivoli object, similar to paths in file systems.

operation In object-oriented design or programming, a service that can be requested at the boundary of an object. Operations include modifying an object or disclosing information about an object.

oserv The name of the object request broker used by the Tivoli environment. oserv runs on the Tivoli management region server and each Tivoli management region client.

574 Version 4.1 P

Plus module See Tivoli Plus module.

policy In a Tivoli environment, a set of rules that are applied to managed resources. A specific rule in a policy is referred to as a “policy method.”

policy region In a Tivoli environment, a group of managed resources that share one or more common policies. Tivoli administrators use policy regions to model the management and organizational structure of a network computing environment. The administrators can group similar resources, define access to and control the resources, and associate rules for governing the resources. The policy region contains resource types and the list of resources to be managed. A policy region is represented on the Tivoli desktop by an icon that resembles a capitol building (dome icon). When a Tivoli management region (region) is created, a policy region with the same name is also created. In this case, the region has only one policy region. However, in most cases, a Tivoli administrator creates other policy regions and subregions to represent the organization of the region. A region addresses the physical connectivity of resources whereas a policy region addresses the logical organization of resources.

policy subregion In a Tivoli environment, a policy region created or residing in another policy region. When a policy subregion is created, it initially uses the resource and policy properties of the parent policy region. The Tivoli administrator can later change or customize these properties to reflect the specific needs and differences of the subregion.

populate In a Tivoli environment, to fill a profile with information that is to be distributed to the subscribing managed resources.

preparation phase In Tivoli Software Distribution, Version 4, the phase of transactional mode operation in which each action in a software package prepares the conditions for the successful execution of an install or remove operation. If the preparation phase fails, the target system is returned to its original, stable state. See also transactional mode.

profile

In a Tivoli environment, a container for application-specific information about a Glossary particular type of resource. A Tivoli application specifies the template for its profiles; the template includes information about the resources that can be managed by that Tivoli application.

Tivoli Software Distribution User’s Guide 575 A profile is created in the context of a profile manager; the profile manager links a profile to the Tivoli resource (for example, a managed node) that uses the information contained in the profile. A profile does not have any direct subscribers.

profile manager In a Tivoli environment, a container for profiles that links the profiles to a set of resources, called “subscribers”. Tivoli administrators use profile managers to organize and distribute profiles. A profile manager is created in the context of a policy region and is a managed resource in a policy region. A profile manager can operate in one of the following two modes: Dataless mode, which enables a profile manager to distribute to any Tivoli client (including managed nodes, endpoints, PC managed nodes, and NetWare managed sites) but not to other profile managers. Database mode, which enables a profile manager to distribute to any profile manager (dataless or database), all managed nodes, all PC managed nodes, and NetWare managed sites, but not to endpoints.

proxy endpoint In Tivoli Distributed Monitoring, a representation of an entity (such as a network device or a host) that functions as a subscriber for Tivoli Distributed Monitoring profiles. A Tivoli administrator associates each proxy endpoint with a managed node; several proxy endpoints can be associated with a single managed node.

proxy managed node In a Tivoli environment, a managed resource that provides communication between the Tivoli management region server and a PC that is running the PC agent. Q

query facility In a Tivoli environment, a facility that provides SQL functions for accessing information in a RIM repository.

query library In a Tivoli environment, a facility that provides a way to create and manage Tivoli queries. R

RDBMS Interface Module (RIM) In the Tivoli Management Framework, the module in the distributed object database that contains information about the installation of the relational database management system (RDBMS).

576 Version 4.1 reference model In the context of Tivoli software, the model configuration for a system or set of systems that is used to maintain consistent configurations in a distributed environment. In Tivoli Inventory, reference models are created in the configuration repository.

registered name In a Tivoli environment, the name by which a particular resource is registered with the name registry when it is created.

remote distribution In a Tivoli environment, a distribution to target machines in a connected Tivoli management region.

repeater range In a Tivoli environment, the Tivoli clients that receive data from the repeater site.

repeater site In a Tivoli management region, a managed node that is configured with the MDist feature. A repeater site receives a single copy of data and distributes it to the next tier of clients.

resource In a Tivoli environment, an entity, such as a device, a database, or a software package. Contrast with managed resource.

resource role In a Tivoli environment, the role an administrator has over specific resources in the local Tivoli management region (region) and any connected region (for example, policy regions or the Administrator collection).

resource type In a Tivoli environment, one of the properties of a managed resource. Resource types are defined in the default policy for a policy region.

RIM See RDBMS Interface Module.

RIM host In a Tivoli environment, the managed node from which a Tivoli administrator runs the database client software and from which the relational database management system (RDBMS) server is contacted.

RIM repository Glossary In a Tivoli environment, a relational database that contains information that is collected or generated by Tivoli applications. Examples of a RIM repository include the configuration repository and the event repository.

Tivoli Software Distribution User’s Guide 577 root directory The highest level directory in a hierarchical file system. S

send operation In Tivoli Software Distribution, Version 4.1, a data moving operation that copies a data file from a source host to specified endpoints.

senior role See authorization role.

server A functional unit that provides services to one or more clients over a network. Examples include a file server, a print server, and a mail server.

signature In Tivoli Software Distribution, Version 4, unique identifying information that forms the first line in a software package definition file. Tivoli Software Distribution uses the signature for version checking and for determining what kind of importer to use to read the software package definition file.

SIS See Software Installation Service.

Software Installation Service (SIS) A Tivoli product that provides an easy-to-use, efficient interface for installing Tivoli Enterprise software. SIS uses Tivoli’s MDist technology and provides automated checking for prerequisite software, a reusable repository of installation images, and both graphical and command line interfaces for deploying Tivoli products to a large number of computers.

software package In Tivoli Software Distribution, Version 4, a database object that contains a sequential list of actions to be executed on a target system.

software package block In Tivoli Software Distribution, Version 4, a file that contains the resources referred to by the actions in a software package.

software package definition In Tivoli Software Distribution, Version 4, an ASCII text file used to describe package contents. It consists of a sequence of stanzas that describe commands to be executed. See also stanza.

578 Version 4.1 Software Package Editor In Tivoli Software Distribution, Version 4, a Java-based tool, with a graphical user interface, for creating and customizing software packages.

software package object In Tivoli Software Distribution, Version 4, a software package that has been imported into the Tivoli management environment. The software package is cataloged at the Tivoli Software Distribution server as a Tivoli database software package object. A Tivoli administrator can perform change management operations (such as install, remove, undo, accept, commit, and verify) on software package objects.

source host In Tivoli Software Distribution, the managed node on which the source files and directories referred to in a software package reside.

stanza In Tivoli Software Distribution, Version 4, a section of a software package definition. A stanza may define, for example, an action to be performed; a list of targets on which the action is to be performed; or a set of conditions under which an action is to be executed. Stanzas may be nested, and there is a single stanza (the root stanza) that contains the entire software package definition.

subscriber In a Tivoli environment, a managed node, a profile manager, an endpoint, or another Tivoli client that is subscribed to a profile manager. Although profiles are distributed to a subscriber, the subscriber may or may not be the final destination of the profile distribution.

subscription In a Tivoli environment, the process of identifying the subscribers to which profiles will be distributed.

subscription list In a Tivoli environment, a list that identifies the subscribers to a profile manager. Including a profile manager on a subscription list (in effect, a list within a list) is a way of subscribing several resources simultaneously rather than adding each one individually. In Tivoli Plus modules, a profile manager functions as a subscription list.

super role See authorization role. Glossary

Tivoli Software Distribution User’s Guide 579 T

target In Tivoli Software Distribution, Version 4, a workstation on which the actions defined in a software package are executed. The Tivoli Management Agent must be installed on the workstation. See also software package.

task library In a Tivoli environment, a container in which a Tivoli administrator can create and store tasks and jobs.

Tivoli administrator In a Tivoli environment, a system administrator who has been authorized to perform systems management tasks and manage policy regions in one or more networks. Each Tivoli administrator is represented by an icon on the Tivoli desktop.

Tivoli client A client of a Tivoli server. See Tivoli management region client and Tivoli management region server.

Tivoli Distributed Monitoring A Tivoli product that monitors system resources, initiates any necessary corrective actions, and informs system administrators of potential problems. Tivoli Distributed Monitoring consists of a group of monitors that are installed on each managed node that is to be monitored. It resolves some events on its own and may send others to the Tivoli Enterprise Console product.

Tivoli Enterprise Console A Tivoli product that collects, processes, and automatically initiates corrective actions for system, application, network, and database events; it is the central control point for events from all sources. The Tivoli Enterprise Console product provides a centralized, global view of the network computing environment; it uses distributed event monitors to collect information, a central event server to process information, and distributed event consoles to present information to system administrators.

Tivoli Enterprise software The integrated suite of Tivoli products for systems management in a large organization. These products enable system administrators to manage their network computing enterprise according to the disciplines of availability management, deployment management, operations and administration, security management, and service-level management. This suite includes Tivoli Business System Manager, Tivoli NetView for OS/390, and Tivoli Decision Support.

Tivoli environment The Tivoli applications, based upon the Tivoli Management Framework, that are installed at a specific customer location and that address network computing

580 Version 4.1 management issues across many platforms. In a Tivoli environment, a system administrator can distribute software, manage user configurations, change access privileges, automate operations, monitor resources, and schedule jobs.

Tivoli Event Integration Facility A Tivoli toolkit that provides a simple application programming interface (API) to enable customers and Tivoli Partners to develop new event adapters that can forward events to the Tivoli Enterprise Console product.

Tivoli install image In a Tivoli environment, a file that resides on a CD or in a file system and contains a Tivoli product to be installed. A Tivoli install image can be used to install the Tivoli Management Framework or to install an application onto the Framework for the first time. A single CD often includes both a Tivoli install image and a Tivoli upgrade image, and it may include Tivoli install images for more than one application. Contrast with Tivoli upgrade image.

Tivoli Inventory A Tivoli product that enables system administrators to gather hardware and software information for a network computing environment. It scans the managed resources and stores inventory information in the configuration repository.

Tivoli IT Director A Tivoli product for systems management in a small or medium organization. It is not sold directly by Tivoli Systems Inc. but rather through a Tivoli authorized reseller.

Tivoli management agent In a Tivoli environment, an agent that securely performs administrative operations.

Tivoli Management Framework The Tivoli base software that is required to run the applications in the Tivoli product suite. This software infrastructure enables the integration of systems management applications from Tivoli Systems Inc. and the Tivoli Partners. The Tivoli Management Framework includes the following: object request broker (oserv), distributed object database, basic administration functions, basic application services, and basic desktop services (such as the graphical user interface). In a Tivoli environment, the Tivoli Management Framework is installed on every client and server; however, the Tivoli management region server is the only server that holds the full object database.

Tivoli management gateway In a Tivoli environment, a system that enables bidirectional communication with Glossary Tivoli management agents.

Tivoli Software Distribution User’s Guide 581 Tivoli management region (region) In a Tivoli environment, a Tivoli server and the set of clients that it serves. An organization can have more than one region. A region addresses the physical connectivity of resources whereas a policy region addresses the logical organization of resources.

Tivoli management region client In a Tivoli environment, any computer—except the Tivoli management region server (Tivoli server)—on which the Tivoli Management Framework is installed. The oserv daemon runs on the Tivoli management region (region) client, and the region client maintains a local object database. See Tivoli client and Tivoli server.

Tivoli management region role In a Tivoli environment, the role an administrator has in the local Tivoli management region (region) and any connected region. The region role propagates the assigned authorization level to all resources in the region. For example, if a Tivoli administrator has a senior role in a region, then the administrator has the senior role over every resource in that region.

Tivoli management region server (Tivoli server) A Tivoli server for a specific Tivoli management region (region). See Tivoli client and Tivoli management region client.

Tivoli management software The overall descriptor for software from Tivoli Systems Inc., which includes Tivoli Enterprise software (for systems management in a large organization), Tivoli IT Director (for systems management in a small or medium organization), and Tivoli Cross-Site (for the management of e-commerce systems). Tivoli management software enables organizations to centrally manage their computing resources (including the critical applications that drive business performance and profits) in a simple and straightforward manner.

Tivoli Name Registry In a Tivoli environment, the table that maps names of managed resources to resource identifiers (and corresponding information) within a Tivoli management region.

Tivoli NetView A Tivoli product that enables distributed network management across multiple operating systems and protocols. Unlike Tivoli NetView for OS/390, Tivoli NetView does not provide centralized management from an OS/390 host.

Tivoli NetView for OS/390 A Tivoli product that enables centralized systems and network management from an OS/390 environment. Through its MultiSystem Manager component, Tivoli NetView

582 Version 4.1 for OS/390 enables management of distributed resources, such as Internet Protocol (IP) resources, NetWare resources, asynchronous transfer mode (ATM) resources, and others. Contrast with Tivoli NetView.

Tivoli NetWare repeater In a Tivoli environment, a server application that is installed on a Novell NetWare server and that maintains a list of available clients for the server. The Tivoli NetWare repeater works with the NetWare managed site to perform profile distribution.

Tivoli Plus module In a Tivoli environment, a management module that has been certified by the Tivoli Partner Association and that enables a specific vendor application to be managed by Tivoli management software.

Tivoli Remote Control A Tivoli product that enables a Tivoli administrator to control mouse and keyboard operations on a Windows NT managed node, an endpoint, or a PC managed node. It also provides file transfer, chat, and reboot functions.

Tivoli SecureWay Security Manager (security manager) The Tivoli product that enables the consistent definition, implementation, and enforcement of security policy in a network computing environment.

Tivoli Security Management See Tivoli SecureWay Security Manager.

Tivoli server The server that holds or references the complete set of Tivoli software, including the full object database. See Tivoli client, Tivoli management region client, and Tivoli management region server.

Tivoli Software Distribution Web Interface In Tivoli Software Distribution, Version 4, an interface that enables an end user at a Tivoli endpoint to retrieve Tivoli Software Distribution profiles using the Tivoli Web-based interface.

Tivoli upgrade image In a Tivoli environment, an image that resides on a CD or in a file system and that contains updates for a Tivoli product. A Tivoli upgrade image contains only the files that have changed since the previous product release, along with the scripts and commands that are needed for installing the new files and configuring the database. Contrast with Tivoli install image. Glossary Tivoli UserLink A Tivoli product that provides IP address synchronization between a PC agent and its associated PC managed node using the Dynamic Host Configuration Protocol

Tivoli Software Distribution User’s Guide 583 (DHCP). Tivoli UserLink also enables a PC user to pull a file package to a Windows, Windows 95, or Windows NT workstation.

Tivoli User Administration A Tivoli product that provides a graphical user interface (GUI) for centralized management of user and group accounts. It offers efficient, automated management of user and system configuration parameters, secure delegation of administrative tasks, and centralized control of all user and group accounts in a network computing environment.

transactional mode In Tivoli Software Distribution, Version 4, a mode of executing install or remove operations in two phases: the preparation phase and the commit phase. See also preparation phase and commit phase. U

undo operation In Tivoli Software Distribution, Version 4, a change management operation that returns a target system to its state before execution of a previous install or remove operation.

undoable-in-transactional mode In Tivoli Software Distribution, Version 4, a variation of transactional mode in which disk space for backup copies (required for undoability) is reserved during the preparation phase, which minimizes the risk of failure attributable to insufficient disk space during the commit phase.

undoable mode In Tivoli Software Distribution, Version 4, a mode of operation in which actions can be rolled back even if they are already committed, because a backup copy is saved.

upgrade image See Tivoli upgrade image.

user login map In a Tivoli environment, a mapping that associates a single user login name with a user account on a specified operating system. User login maps enable Tivoli administrators to log in to the Tivoli environment or perform operations within a Tivoli environment with a single user login name, regardless of the system that they are currently using.

user profile In Tivoli User Administration, a profile that is used to manage user accounts, including account information, home directories, startup files, and group membership.

584 Version 4.1 user role See authorization role. V

validation policy In a Tivoli environment, policy that ensures that all resources in a policy region comply with the region’s established policy. Validation policy prevents Tivoli administrators from creating or modifying resources that do not conform to the policy of the policy region in which the resources were created.

verify operation In Tivoli Software Distribution, Version 4, a change management operation that verifies the successful execution of the previous operation. Glossary

Tivoli Software Distribution User’s Guide 585 586 Version 4.1 Index

Special Characters activities (continued) .ini files execution window 427 modifying 91 final 428 OS/2 104 priority 429 Windows 90 removing 438 sorting 425 task 413 types 413 activity plan database A drafts and templates 409 saving to 437 accept operation 322 activity plan definition file 409 actions Activity Plan Editor 409 adding directories 65, 74 Activity Plan Monitor 410, 439 adding files 66, 76 Activity Planner adding multiple file/directory 78 creating database tables for 37 adding OS/2 desktop objects 99 creating RIM objects for 37 adding OS/2 profile objects 104 GUI component 28 adding text file objects 108 server component 26 adding Windows NT service 95 activity plans adding Windows profile objects 90 authorization 443 adding Windows registry objects 79 canceling 444 adding Windows shell objects 85 cleanup 446 check disk space 62 deleting 446 execute CID program 145 draft 409, 437 execute program 116 import 476 Install MSI Patch 189 locked 409 Install MSI Product 189 name 429 InstallShield program 146 pausing 444 Microsoft Setup Program 149 preview 475 remove actions 150 recursive 432 restart 119 recursive, interrupting 433 activities removing 438 assigining targets 417 restarting 444 change management operations 413 resuming 444 cloning 417 saving 437 conditioning 423 Index status 440 data movement operations 413 submit 476 defining 414 submitting 441 depot management operations 413

Tivoli Software Distribution User’s Guide 587 activity plans (continued) authorization roles 411, 557 (continued) targets 435 APM_Edit 559 template 409, 437 APM_Manage 560 updating status 445 APM_View 560 variables 436 CCM_Edit 563 XML file 409, 438 CCM_Manage 563 Add OS400 Library dialog 162 CCM_View 562 Add OS400 Licensed Program dialog 168 install-product 22, 557 Add OS400 Object Properties dialog 165 SDhttpd_Control 564 adding senior 22, 557 command lines 108 super 22, 557 directories 74 user 22, 557 directories to OS/400 system 172 auto reboot mode 132 files 76 AutoPack files to OS/400 system 172 command 201 inventory element 462 configuration file 204 lines to text files 108 differencing phase 203 multiple file/directory 78 excluding .INI files 227 OS/2 desktop folder 99 excluding registry entries 225 OS/2 desktop program 101 excluding text files 224 OS/2 desktop shadow 103 file system sections 205 OS/2 profile items 107 first snapshot 221 OS/400 libraries 161 monitoring registry entries 225 OS/400 licensed programs 167 monitoring text files 223 OS/400 objects 161 monitoring Windows profiles 226 SWD element 459 OS/2 desktop 208 tokens 108 OS/2 profiles 207 Windows NT service 95 OS/2 system files 208 Windows profile objects 90 preparation machine 201 Windows registry objects 79 result 234 adding objects to the software package 61 second snapshot 238 adding OS/400 objects 164 supported platforms 201, 203 Administrator, Web Interface 336 system components 203 after build programs 129 text file sections 206 Apache Web server 354, 360 Windows profile sections 207 APM_Admin role 412, 561 Windows registry sections 207 APM_Edit role 412, 559 working directory 222 APM_Manage role 412, 560 autopack command 218 APM_View role 412, 560 AutoPack Guided Process asynchronous delivery 9 automatic installation 235 attributes first snapshot 221 translate 174, 177 manual installation 229 UNIX 138 scenario 217 authorization roles 411, 557 second snapshot 231 admin 22, 557 starting 220 APM_Admin 561

588 Version 4.1 autopack.ini CCM_View role 562 customizing 209, 222 CD, installing from 304 UNIX systems 216 Change Configuration Management 449 Windows 98 214 change element 474 Windows NT, Windows 2000 213 change management operations 297 accept 21, 322 commit 21, 323 default settings 134 install 299 B remove 20, 318 BAROC file 405 undo 21, 320 base package 300 verify 21, 326 before build programs 129 change management status 121, 297, 450 boot diskette change management status feature 375 creation for pristine installation disabling 385 OS/2 534 enabling 384 Windows 516 change subscriber 474 for pristine installation 494 change target 474 building the software package changing OS/400 system values 171 convert operation 294 changing reference model 473 import operation 289 check disk space action 62 save as option 151 checkpoint restart 9, 260 byte-level differencing 3 checks 134, 302 child reference model 450 creating 458 cleanup, activity plans 446 cloning activities 417 C co-requisite dependency 451 calculating size of software packages 292 code server cancel at cutoff 431 adding system files to objects (OS/2) 526 CASINSTL, for pristine installations 534 for pristine installation 493 CCM 449 object 493 creating database tables for 37 OS/2 521 creating RIM objects for 37 Windows 499 for pristine installation 494, 497 object configuration 494 CCM_Edit role 563 object configuration creation and maintenance CCM GUI component 29 OS/2 529 CCM_Manage role 563 Windows 507 CCM report object creation and maintenance reference model 478 OS/2 523 target 478 Windows 500 CCM server component 26 prerequisites 494 CCM user roles 456 codepage translation 174, 177 Index ccm_vendor_admin.sql 37 command line interface ccm_vendor_schema.sql 37 for data moving 486 command lines, adding 108

Tivoli Software Distribution User’s Guide 589 commands component 27 (continued) autopack 218 WEB UI depot 29 df 270 component names 34 odadmin 263 components wbkupdb 24 installing 25 wcntpln 434 on endpoints 29 wcrtadmin 339 on managed nodes 27 wcrtquery 396 on the Tivoli server 25 wdelstat command 438 compute CRC 230 wdepot 275 conditions wdlssp 298 activities 423 wfptosp 2 completion 423 winstall 36, 46 examples 64, 80, 86 winstsp 274, 299 failure 423 wldsp 273, 274 in an Install MSI product/patch action 197 wmdist 264, 265, 272, 274 software package-level 123 wrpt 262 success 423 wrunquery 391 using 6 wsdhttpd 360 configuration wseterrlev 432, 435 code server object 494 wsetspat 290, 344 creation and maintenance for code server wsetspop 290 objects wspmvdata 481, 486 OS/2 529 wswsprim 379, 386 Windows 507 wsyncsp 379 configuration element 450 wuldsp 273, 275 modify 474 wwebprfget 359 remove 474 wwebprfset 359 configuration file, customizing 209 wwebrget 343 configuration repository wwebrset 343 updating with Tivoli Software Distribution commit operation 323, 324 data 377 committable mode 130 using with Software Distribution 376 complete not after 431 configuring component 27 data moving service 482 activity planner 26 configuring repeater as depot 274 activity planner GUI 28 configuring repeaters 252 CCM 26 controlling distributions 10 CCM GUI 29 converting software packages gateway 27 built to not-built 295 historical database 25 not-built to built 294 Java endpoint package editor 29 create directories option 69 pristine tool 30 creating server 25 a new software package 57 Software Package Editor (SPE) 28 Install MSI Product 58 source host 27 using AutoPack 57 Tivoli Enterprise Console 26 using the PDF Importer 57

590 Version 4.1 creating (continued) deleting OS/400 objects 166 a shortcut 85 deleting software package profiles 290 profile managers 280 delta install 300 profiles 278 dependency 125, 301, 305 creating child reference model 458 co-requisite 451 creating reference model 457 defining 2, 460 CSV file targets ex-requisite 451 assigning 465 pre-requisite 451 CSV subscriber, assigning 465 depot, permanent storage 259, 262, 274 depot list 367 depot management operations 21 depoting 10 descend directories option 69 D desired state data setting 460 deleting 481, 485 destination folder distributing 481 for MSI product 186 moving 481 device drivers retrieving 481, 484 adding for pristine installation sending 483 OS/2 531 data movement operations 21 Windows 510 data moving service 481 df command 270 command line interface 486 Dialogs configuring 482 Activity Properties 415 on an OS/400 system 178 Activity Sort 426 user roles 482 Add OS400 Library 162 using scripts 487 Add OS400 Licensed Program 168 database Add OS400 Object Properties 165 upgrading 380 Add Target 418 database mode 280 Automatic Update 445 database tables Clean up Properties 447 for Activity planner 37 Condition 424 for CCM 37 Execution Windows 427 dataless endpoint mode 280 Install 416 DataMovingRequests.1 482 Install Options 401 dedicated pristine gateway 494 Login 411 prerequisites 497 OS400 System Values Properties 171 default variables 312 Plan Properties 429 defining dependency for SWD element 460 Profile Manager 422 delete element 474 Remove OS400 Library 166 delete reference model 473 Remove OS400 Licensed Program 170 delete subscriber 474 Remove OS400 Object 167 delete target 474 Select plan for submission 441 Index deleting data 481, 485 Tivoli Enterprise Console 401 deleting OS/400 libraries 166 Variable List Editor 67, 141 deleting OS/400 licensed programs 170 Web Interface access pages 345, 361

Tivoli Software Distribution User’s Guide 591 differencing phase 203 exporting software packages 296 directories, adding 65, 74 disk space, checking 62 disposable option 303 distributing data 481 distributing nested software packages 327 F distribution manager 252 features distribution note 317 for MSI product 188, 196 distribution settings 313 file package migration 7 distribution status 309 file server 304 Distribution Status console 444 file system objects including and excluding 205 types 13 file version support 8, 68 files E autopack.ini 204 e-mail, sending 137 BAROC file 405 EBCDIC 174, 177 check.bat 541 editing software packages 143 check_OS.spd 541 element inst_w2000.spd 541 configuration 450 MSI 186, 192 inventory 450 ntspx.spd 549 adding 462 spxi386.exe 551 modify 474 tecad_sd.baroc 405 remove 474 tecad_sd.conf 400, 402 software distribution 450 tecad_sdnew.baroc 399 SWD unattended.txt 543 adding 459 Unattended.txt 540 endpoint components 29 userlink.htm 346, 361 endpoint gateway 12 w2000.spd 543 endpoint manager 255 files, adding 66, 76 endpoints 12, 254 Filter keyword 404 used as pristine preparation site 493 final activity 428 error levels 432, 434 first snapshot 221 events 397 forcing an operation 134 ex-requisite dependency 451 execute CID program action 145 execute program action using 116 execute_timeout 267 G execute user program gateway, dedicated pristine 494 on an OS/400 system 175 prerequisites 497 execution window gateway component 27 activities 427 general properties 124 exit codes 118 Generic container 58, 71 exporting reference model 472

592 Version 4.1 GETREXX, for pristine installations 528 installation (continued) GID 138 mechanisms 33 planning for 23 pristine 491 pristine tool 44 tasks 32 H using Tivoli Desktop 35 hard disk partitioning, for pristine installations using Tivoli Software Installation Service 34 OS/2 531 winstall 36 Windows 512 installation option hardware prerequisites repair 193 defining for a package 2 installation options hidden web view mode 341, 358 Java Endpoint Package Editor 40 historical database component 25 installing historical database feature 375 disconnected mode 316 disabling 385 from CD 304 enabling 384 from depot 274, 303 requirements 384 from file server 304 hung distributions language support 51 configuring wmdist parameters 265 Tivoli Software Distribution TEC Integration 398 installing components 25 InstallShield Program action, redirected installation 146 I InstallShield Program Builder 149 IFS 157, 158 Integrated File System 157, 158 import activity plan 476 inventory element 450 Importer Tool adding 462 MSI 184 Inventory integration importing authorization roles 385 built software packages 289 change management status feature 375 not-built software packages 289 configuration repository 375, 376 importing reference model 473 configuration repository tables 377 importing software packages 285, 286 disabling change management status index files 34, 36 feature 385 individual targets disabling historical database feature 385 assigning 468 enabling change management status Install MSI Patch action 189 feature 384 Install MSI Product action 189 enabling historical database feature 384 Install MSI Product wizard 184 historical database feature 375 install operation 299 query facility 377 Install Options dialog 401 upgrading database 380 installation wcrtquery command 396 Index Install Product 35 wswsprim command 386 Java endpoint package editor 39 inventory query assigning targets with 469

Tivoli Software Distribution User’s Guide 593 inventory subscriber 419 M inventory subscriber, assigning 469 managed node components 27 mandatory 317 MDist 2 (multiplexed distribution) assured delivery 9 asynchronous delivery 9 J checkpoint restart 9 Java Components 24 depoting 10 Java endpoint package editor distribution control 10 installing 39 overview 9, 258 Java Endpoint Package Editor pending distribution queues 10 installation options 40 Microsoft Setup Program action 149 Java endpoint package editor component 29 Microsoft Setup Program Builder 149 Microsoft Software Installer (MSI) 181 migration, file packages 7 mobile settings 315 mobile support 3 K modes 324 keep product images modify element 474 for MSI product 188, 192 modify subscriber 474 keyword, Filter 404 modify target 474 modifying reference model 473 moving data 481 MPTS, configuring for pristine installations pristine installation L MPTS configuring 528 LAN CID utility, for pristine installations 534 MSI language support 51 embedding packages 181 launching Software Package Editor 54 MSI file links, creating 85 selecting 186, 192 loading software package on repeater depot 274 MSI Importer Tool 184 local depot MSI installation package performing operations 374 creating 183 locked activity plans 409 using a wizard 184 locked file support 8 using dialogs 189 locked files, renaming 69 MSI installation packages 181 log file options 136 MSI product features 188, 196 log host 137 MSI product/patch log mode destination folder 186 MSI product/patch 194 keep product images 188, 192 logging information, TEC events 397 log mode 194 Login dialog 411 properties 195 redirected installation 187, 192 reinstall mode 193 source image path 187, 192

594 Version 4.1 MSI product/patch (continued) OS/400 licensed programs target image path 187, 192 adding 167 removing 170 OS/400 native file system 157, 158 adding non-native objects to 172 OS/400 objects 13 N adding 161, 164 naming the activity plan 429 removing 166 native installation 146 OS/400 Software Package Editor 159 nested software packages 16 OS/400 system distributing 327 adding directory to 172 scenario 330 adding file to 172 specifying 141 executing user program on 175 network drive installation 146, 243 using the data moving service 178 notices 137 OS/400 system value notification 430 changing 171 OS/400 systems software distribution to 155 OS400 System Values Properties dialog 171 overriding registry permissions 230 O odadmin command 263 operation modes auto reboot 132 committable 130 P default settings 130 Package Definition File (PDF) 239 reboot 132, 311 package type transactional 131, 309 patch 125 undoable 131, 310 refresh 124 undoable-in-transactional 132 parent reference model 450 order of execution 122, 142 PDF Importer Tool 6, 239 OS/2 desktop folder, adding 99 pending distribution queues 10 OS/2 desktop objects 14 permanent storage 274 OS/2 desktop program, adding 101 plans_vendor_admin.sql 37 OS/2 desktop sections 208 plans_vendor_schema.sql 37 OS/2 desktop shadow, adding 103 policy regions 12 OS/2 profile items, adding 107 configuring 340, 357 OS/2 profile objects 14 hidden 341, 357 OS/2 profiles sections 207 public 341, 357 OS/2 steps for pristine installation 520 restricted 341, 357 OS/2 system files sections 208 setting attribute 343 OS/400 libraries pre-requisite dependency 451 adding 161 preparation machine 201 Index removing 166 preparation site, pristine installation 493 prerequisites defining for a package 2

Tivoli Software Distribution User’s Guide 595 prerequisites for pristine installation 494 pristine installation (continued) preview activity plan 475 reference model 494, 497 previewing an operation 134 response file customizing primary software package 142 OS/2 529 priority 429 Windows 507 pristine installation response file usage 492 adding configuration information running OS/2 532 OS/2 536 Windows 513 Windows 518 boot diskette 494 SEDISK 532 boot diskette creation SRVIFS 533 OS/2 534 system diskette preparation Windows 516 OS/2 532 CASINSTL 534 Windows 513 CCM 494, 497 THINIFS 533 code server 493 THINLAPS 533 code server object 493 THINSRV 527 code server object configuration 494 Windows steps 498 code server object configuration creation and pristine system maintenance prerequisites 497 OS/2 529 pristine tool Windows 507 installing 44 code server object creation and maintenance prerequisites 495 OS/2 523 pristine tool component 30 Windows 500 product tags 34 code server objects, adding system files to profile manager (OS/2) 526 targets 421, 472 dedicated gateway 494 profile manager subscriber, assigning 467 defining reference model profile manager targets OS/2 532 assigning 467 Windows 513 profile managers device drivers creating 280 OS/2 531 software categories 358 Windows 510 profiles GETREXX 528 creating 278 hard disk partitioning overview 11 OS/2 531 program actions Windows 512 execute CID programs 145 LAN CID utility 534 Execute program 117, 247 network environment 492 Install MSI Patch 189 OS/2 steps 520 Install MSI Product 189 other software 492 InstallShield program 146 overview 491 Microsoft Setup Program 149 platforms 492 properties preparation site 493 editing 143 prerequisites 494 general 124

596 Version 4.1 properties (continued) reference model properties 458 modifying 143 reference model report 478 MSI product/patch 195 reference models of reference model 458 subscribing 372 software package 143, 291, 292 synchronize 371 software package-level 122 updates 364 software package object 290 Web Interface 370 Properties notebook 429 registry permissions, overriding 230 public web view mode 341, 358 reinstall mode MSI product/patch 193 remove actions 150 remove element 474 remove empty directories option 69 Q remove if modified 68, 230 queries, executing 305 remove operation query facility 377 change management operation 318 query library modes 319 using to assign targets 470 Remove OS400 Library dialog 166 query library, SWDIST_QUERIES 377 Remove OS400 Licensed Program dialog 170 query library subscriber 420 Remove OS400 Object dialog 167 remove reference model 473 removing activities 438 activity plan 438 R OS/400 libraries 166 RDBMS Interface Module (RIM) object 38 OS/400 licensed programs 170 reboot mode 132, 311 OS/400 objects 166 recursion subscriber 474 interrupting 434 target 474 recursive activity plans 432, 433 renaming locked files 69 redirected installation 146, 183, 187, 192, 243 repair functionality 133 reference model 450 repair installation option 193 creating structure 457 repair options 301 defining for pristine installation repeater OS/2 532 configuring 262 Windows 513 configuring as depot 274 example 453 depot 259 exporting to xml file 472 gateway 258 for pristine installation 494, 497 parameters 266 import activity plan for 476 restarting 273 importing from xml file 473 standalone 258 modifying 473 standalone, creating 263 preview activity plan for 475 verifying path 262 Index remove 473 repeater depot submit activity plan for 476 configuring 274 listing entries 275

Tivoli Software Distribution User’s Guide 597 repeater depot (continued) scripts (continued) loading software package 274 plans_vendor_admin.sql 37 memory space 267, 271 plans_vendor_schema.sql 37 removing software packages 275 swdis_db2_upgr_41.sql 380 space allocation 267, 271 swdis_db2_upgr.41.sql 381 replace if existing 68, 230 swdis_db2_upgrade.sql 380, 381 replace if target is newer 68 swdis_infx_upgr_41.sql 380 report swdis_infx_upgr.41.sql 384 reference model 478 swdis_infx_upgrade.sql 380, 384 target in CCM 478 swdis_ms_sql_upgr_41.sql 380 response file, used in pristine installation 492 swdis_ms_sql_upgr.41.sql 382 response files swdis_ms_sql_upgrade.sql 380, 382 customizing for pristine installations swdis_ora_upgr_41.sql 380 OS/2 529 swdis_ora_upgr.41.sql 383 Windows 507 swdis_ora_upgrade.sql 380, 383 restart action 119 swdis_syb_upgr_41.sql 380 retrieving data 481, 484 swdis_syb_upgr.41.sql 383 return codes 432, 434 swdis_syb_upgrade.sql 380, 383 RIM object swdistecsrvr_inst.sh 399 creating 38 SD_Web_Server role 355 roaming endpoint 252, 314 SD_Web_User role 355 roaming endpoints 439 SDhttpd_Control role 355, 564 roles SDK log mode 194 Activity Planner 411 SDWebUI_displayname 356, 359 Activity Planner operations 559 second snapshot 231, 238 CCM operations 562 security, authorization roles 22 distributing software packages 559 SEDISK SD_Web_Server 355 for pristine installations 532 SD_Web_User 355 segments 274 SDhttpd_Control 355 send_timeout 267 software package profiles 557 sending data 483 Web Interface operations 563 server component 25 setting desired state 460 setting resource roles 339 setting TMR roles 338 setup variations 246 S shared files 73, 78, 212 saving, activity plans 437 shared object support 8 saving default variables 141 shortcuts, creating 85 saving software packages 151 software categories 349, 359, 365 scheduled jobs 306 software distribution element 450 scheduling distributions 305 adding 459 scripts Software Installation Service 34 ccm_vendor_admin.sql 37 software package block 19, 151 ccm_vendor_schema.sql 37 software package block, maximum size 19, 294 in a data moving command 487 software package block (SPB) path 128

598 Version 4.1 software package definition (.spd) file 18, 295 software packages (continued) Software Package Definition (.spd) file 153 verifying 369, 374 Software Package Editor version 161, 162, 166, 167, 169, 171, 350 starting on OS/400 159 software packages, nested 16 Software Package Editor (SPE) software prerequisites description 56 defining for a package 2 introduction 17 sorting activities 425 launching 53, 54 source host 12, 128, 260, 289, 290 managed node 291 source host component 27 on endpoint 54 source image path OS/400 159 for MSI product 187, 192 Software Package Editor (SPE component) 28 SPB path 128, 294 software package file types 57 SPE (see Software Package Editor) 28 software package name 281 SRVIFS, for pristine installations 533 software package object stage area 128, 311 DataMovingRequests.1 482 start not before 431 definition 19 static subscriber, assigning 468 properties 290 status software package profile, deleting 290 updating 445 software package version 281 status, activity plans 440 software packages stop on error 432, 434 built format 19 stop on failure 68, 125 calculating size 292 submit activity plan 476 converting 293 submit paused 430 copyright 139 submitting, activity plans 441 creating 57 subscribe 367 description 138, 350 subscriber exporting 296 assigning from file 465 for OS/400 systems 156 assigning to reference model 464 formats 151 CSV 465 hidden 358 definition 12 importing 285, 286 in CCM 452 installing locally 374 inventory 469 local depot 374 modify 474 naming 60, 124, 159 profile manager 467 nesting 141 query library 470 not-built format 18 remove 474 properties 122, 143, 291, 292 setting 282 public 358 static 468 saving 151 Web interface 452 subscriber 358 Web interface, assigning 465 subscribing 372 subscriber web view mode 341, 358

text version 18, 153 subscriptions Index unbuilding 56, 295 reference models 372 uninstalling 369 software packages 372 updates 364, 365 SWD element 450

Tivoli Software Distribution User’s Guide 599 SWD element 450 (continued) targets (continued) adding 459 grouping 439 swdis_db2_upgr_41.sql script 380 inventory subscriber 419 swdis_db2_upgr.41.sql script 381 list of names 418 swdis_db2_upgrade.sql script 380, 381 profile manager 421, 472 swdis_infx_upgr_41.sql script 380 assigning 467 swdis_infx_upgr.41.sql script 384 query library subscriber 420 swdis_infx_upgrade.sql script 380, 384 static 433 swdis_ms_sql_upgr_41.sql script 380 variables 420 swdis_ms_sql_upgr.41.sql script 382 tecad_sd.baroc file 405 swdis_ms_sql_upgrade.sql script 380, 382 tecad_sd.conf file 400, 402 swdis_ora_upgr_41.sql script 380 tecad_sdnew.baroc file 399 swdis_ora_upgr.41.sql script 383 text file objects 13 swdis_ora_upgrade.sql script 380, 383 text file objects, adding 108 swdis_syb_upgr_41.sql script 380 text file sections, AutoPack 206 swdis_syb_upgr.41.sql script 383 THINIFS, for pristine installations 533 swdis_syb_upgrade.sql script 380, 383 THINLAPS, for pristine installations 533 SWDIST_QUERIES 377 THINSRV, for pristine installations 527 swdistecsrvr_inst.sh script 399 timeouts system components, AutoPack 203 setting for distribution 313 system diskette Tivoli Desktop installation 35 preparation for pristine installation Tivoli desktop operations 20 OS/2 532 Tivoli Enterprise Console 397 Windows 513 Tivoli Enterprise Console component 26 system diskette creation Tivoli Enterprise Console dialog 401 prerequisites for pristine 496 Tivoli Enterprise Console integration 397 Tivoli management region policy regions 12 profile managers 12 profiles 11 T subscribers 12 target Tivoli server components 25 modify 474 Tivoli Software Distribution, supported remove 474 platforms 1 target image path Tivoli Software Installation Service 34 for MSI product 187, 192 tokens, adding 108 target report 478 Tools targets InstallShield Program Builder 149 activity plans 435 PDF Importer 239 assigning 417 transactional mode 131, 309 assigning by inventory query 469 translate attribute 174, 177 assigning by query library 470 assigning from CSV file 465 assigning individual 468 dynamic 433 file name 419

600 Version 4.1 U W UID 138 wake on lan endpoint 314 unbuild 56, 295 wbkupdb command 24 undo operation wcntpln command 434 change management operation 320 wcrtadmin command 339 modes 321 wcrtquery command 396 undoable-in-transactional mode 132 wdelstat command 438 undoable mode 131, 310 wdepot command 275 uninstalling wdlssp command 298 NetWare gateway 50 Web Interface software packages 369 activating 335, 355 Tivoli Software Distribution 47 assigning Resource roles 357 UNIX attributes 138 assigning TMR roles 356 updates configuring 342 reference models 363, 364 configuring policy regions 340, 357 software packages 363, 364 creating administrator 336 updating status 445 enhanced 333, 353 upgrading scenarios roles 356, 359, 563 Windows NT 4.0 with Service Pack 5 or setting resource roles 339 6 549 setting TMR roles 337 Windows NT 4.0 Workstation to Windows software categories 358 2000 Professional 539 software package blocks 350 user roles software package description 139 CCM 456 tasks 359 data moving 482 updates page 363 UserLink.htm file 345, 361 UserLink.htm file 345, 361 Web Interface access page dialogs 345, 361 Web interface subscriber 452 Web interface subscriber, assigning 465 Web UI component 27 V WEB UI depot component 29 Variable List Editor dialog 67, 141 web view mode 341, 358 variables default setting 135 activity plans 436 hidden 135, 341, 358 built-in 5, 67, 89, 140 public 135, 341, 358 defining 437 setting 344 saving defaults 141 subscriber 135, 341, 358 targets 420 web_view_mode 356, 358 verify CRC 229 wfptosp command 2 verify operation 326 wildcards 66, 205, 206, 208, 209 verifying software packages 369, 374 Windows NT 4.0 with Service Pack 5 or 6, version checking 2, 124, 302 upgrading 549 Index versioning type 124 Windows NT 4.0 Workstation to Windows 2000 Professional, upgrading 539 Windows NT service, adding 95

Tivoli Software Distribution User’s Guide 601 Windows profile objects adding 90 types 14 Windows profile sections 207 Windows registry objects 14, 79 Windows registry sections 207 Windows shell objects adding 85 types 14 Windows steps for pristine installation 498 winstall, using 36 winstall command 36, 46 winstsp command 274, 299 wizard for embedding MSI packages 184 wldsp command 273 wmdist configuring repeater parameters 274 repeater parameters 272 working directory 222 wrpt command 262 wrunquery command 391 wsdhttpd command 360 wseterrlev command 432, 434, 435 wsetspat command 290, 344 wsetspop command 290 wspmvdata command 481, 486 wswsprim command 379, 386 wsyncsp command 379 wuldsp command 273, 275 wwebprfget command 359 wwebprfset command 359 wwebrget command 343 wwebrset command 343

X xml file activity plan definition file 409 exporting reference model to 472

602 Version 4.1

GC32-0715-00