tivoli software distributionpublib.boulder.ibm.com/tividd/td/sw_dist/gc32-0651-00/en_us/pdf/… ·...

Tivoli SoftwareDistributionUser’s GuideVersion 4.0

Tivoli Software Distribution User’s Guide (August 2000)

Copyright Notice

Copyright © 2000 IBM Corp., including this documentation and all software. All rightsreserved. May only be used pursuant to a Tivoli Systems Software License Agreement, anIBM Software License Agreement, or Addendum for Tivoli Products to IBM Customer orLicense 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 anymeans, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, withoutprior written permission of IBM Corp. IBM Corp. grants you limited permission to makehardcopy or other reproductions of any machine-readable documentation for your own use,provided that each such reproduction shall carry the IBM Corp. copyright notice. No otherrights under copyright are granted without prior written permission of IBM Corp. Thedocument is not intended for production and is furnished “as is” without warranty of anykind. All warranties on this document are hereby disclaimed including the warranties ofmerchantability and fitness for a particular purpose.

Note to U.S. Government Users—Documentation related to restricted rights—Use,duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contractwith IBM Corporation.Trademarks

IBM, Tivoli, AIX, OS/2, RS/6000, and Tivoli Enterprise are registered trademarks ofInternational Business Machines Corp. or Tivoli Systems Inc. in the United States, othercountries or both. In Denmark, Tivoli is a trademark licensed from Kjøbenhavns Sommer -Tivoli A/S.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks or registeredtrademarks 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.

Solaris, Java and all Java-based trademarks or logos are trademarks of SunMicrosystems, Inc. in the United States, other countries, or both.

NetWare and Novell are trademarks of Novell, Incorporated.

HP-UX is a registered trademark of Hewlett-Packard Company.

InstallShield is a registered trademark of InstallShield Software Corporation in the UnitedStates and/or other countries.

Norton AntiVirus and SYMANTEC are trademarks of Symantec Corporation.

Lotus and 1-2-3 are registered trademarks of Lotus Development Corporation.

Other company, product, and service names mentioned in this document may be trademarksor service marks of others.

Refer to “Notices” on page xi for additional notices.

Contents

Notices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiWho Should Read This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Prerequisite and Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

What This Document Contains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Conventions Used in This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Platform-specific Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Tivoli Software Distribution Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Accessing Publications Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Ordering Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Providing Feedback about Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

Contacting Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

Chapter 1. Overview of Tivoli Software Distribution. . . . . 1Coexistence with Previous Product Versions . . . . . . . . . . . . . . . . . . . . . . . . . 2

Tivoli Software Distribution Highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

The Tivoli Software Distribution Environment . . . . . . . . . . . . . . . . . . . . . . . . 9

Source Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Distribution Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Software Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Object-Related Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

System Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Program Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Nested Software Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Software Package Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Software Package Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

iiiTivoli Software Distribution User’s Guide

Software Package (.sp) File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Software Package Definition (.spd) File . . . . . . . . . . . . . . . . . . . . . . . . 15

Software Package Block (.spb) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Software Package Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Tivoli Desktop Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Change Management Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 2. Planning and Installing Tivoli SoftwareDistribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Tivoli Software Distribution Components. . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Installing Tivoli Software Distribution Products . . . . . . . . . . . . . . . . . . . . . . 25

Product Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Removing Tivoli Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Uninstalling Endpoints on OS/2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Uninstalling the NetWare Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Enabling Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Chapter 3. Creating a Software Package. . . . . . . . . . . . . . . . 41Launching the Software Package Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Launching the Software Package Editor on Endpoints . . . . . . . . . . . . . 42

Launching the Software Package Editor on Managed Nodes. . . . . . . . . 43

The Software Package Editor Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Creating the Appsample Software Package. . . . . . . . . . . . . . . . . . . . . . . . . . 46

Naming the Appsample Software Package . . . . . . . . . . . . . . . . . . . . . . 47

Checking Disk Space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Adding Directories and Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Adding Windows Platform Actions to a Generic Container. . . . . . . . . . 58

Adding OS/2 Platform Actions to a Generic Container . . . . . . . . . . . . . 84

iv Version 4.0

Adding an Execute Program Action . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Adding the Restart Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

The Appsample Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Changing the Order of Objects in the Software Package. . . . . . . . . . . . . . . 108

Setting Software Package-level Properties . . . . . . . . . . . . . . . . . . . . . . . . . 109

General Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Server Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Log File Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Variable list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Nested packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Editing Software Package Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Other Software Package Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

The Execute CID Program Action . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

The InstallShield Program Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

The Microsoft Setup Program Action . . . . . . . . . . . . . . . . . . . . . . . . . 133

Remove Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Saving the Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Chapter 4. Embedding MSI Installation Packages ina Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Benefits of Embedded MSI Installation Packages . . . . . . . . . . . . . . . . . . . . 139

Creating a Software Package That Embeds an MSI Installation Package 140

Defining the Execute Program Properties for the Install Operation 142

Defining the Execute Program Properties for the Remove Operation 146

Chapter 5. How Does AutoPack Work? . . . . . . . . . . . . . . . . 149AutoPack Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

vTivoli Software Distribution User’s Guide

AutoPack Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Customizing the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Dealing with Shared Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Autopack.ini Default for Windows NT 4.0 . . . . . . . . . . . . . . . . . . . . . 160

Autopack.ini Default for UNIX Systems . . . . . . . . . . . . . . . . . . . . . . 162

Chapter 6. Generating a Software Package UsingAutoPack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Running AutoPack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Creating the First Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

The Manual Installation Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Resuming the Second Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

The Automatic Installation Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Chapter 7. Using the PDF Importer Tool . . . . . . . . . . . . . . . 185The Package Definition File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

PDF Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Package Definition Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

SetupVariation Setup Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Setup Package for Inventory Section . . . . . . . . . . . . . . . . . . . . . . . . . 186

FileIndex Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Mapping the PDF to a Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Using the PDF Importer Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Sample Package Definition File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

NAVWNT.PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Chapter 8. Understanding the DistributionEnvironment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Introducing NoonTide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Network Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

vi Version 4.0

Subnet 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Subnet 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Subnet 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Subnet 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Subnet 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Subnet 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Subnet 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Creating a Repeater Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Configuring Repeater Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Setting Repeater Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Using Repeater Depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Installing Additional Tivoli Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Chapter 9. The Distribution Process . . . . . . . . . . . . . . . . . . . 223Creating a Tivoli Software Distribution Profile . . . . . . . . . . . . . . . . . . . . . . 224

Setting the Profile Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Importing a Software Package into the Tivoli Environment. . . . . . . . . . . . . 233

Creating a New Software Package and Importing it into a SoftwarePackage Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Importing an Existing Software Package into a Software PackageProfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Deleting a Software Package Profile . . . . . . . . . . . . . . . . . . . . . . . . . 238

Software Package Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Calculating the Size of a Software Package . . . . . . . . . . . . . . . . . . . . . . . . 241

Converting a Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Exporting a Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Change Management Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Executing Change Management Operations . . . . . . . . . . . . . . . . . . . . 245

Distributing Nested Software Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

viiTivoli Software Distribution User’s Guide

Things to Consider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Chapter 10. Tivoli Software Distribution WebInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Activating Tivoli Software Distribution Web Interface . . . . . . . . . . . . . . . . 277

Creating a Tivoli Administrator for Web Interface . . . . . . . . . . . . . . . 277

Configuring Policy Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Software Package Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Configuring Tivoli Software Distribution Web Interface . . . . . . . . . . . . . . . 283

Setting the Policy Region Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Setting the Software Package Object Attribute . . . . . . . . . . . . . . . . . . 284

Using Tivoli Software Distribution Web Interface. . . . . . . . . . . . . . . . . . . . 285

Notifying Users about Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . 287

Chapter 11. Integrating the Tivoli Inventory Database 293The Configuration Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

The Query Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Updating the Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Upgrading from Tivoli Inventory, Version 3.6 or Later . . . . . . . . . . . . . . . . 297

Upgrading a DB2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Upgrading a SQL Server Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Upgrading an Oracle Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Upgrading a Sybase Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Enabling the Historical Database and Change Management Status Features 300

Disabling the Historical Database and Change Management StatusFeatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Creating the SWDIST_QUERIES Query Library . . . . . . . . . . . . . . . . . . . . 302

Running SWDISTDATA_QUERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Desktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

viii Version 4.0

Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Modifying SWDISTDATA_QUERY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Desktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

Chapter 12. Integrating the Tivoli Enterprise Console 313Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

The tecad_sd.conf File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Tivoli Software Distribution Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Chapter 13. Upgrading Windows NT 4.0 with ServicePack 5 or 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Environment Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Downloading the ntspx.spd Definition File to the TMR Server . . . . . . . . . . 324

Copying the Service Pack Files to the Image Server. . . . . . . . . . . . . . . . . . 325

Customizing the ntspx.spd Software Package Definition File . . . . . . . . . . . 326

Creating the Software Package on the TMR Server . . . . . . . . . . . . . . . . . . 327

Subscribing the Endpoints to the Upgrades Profile Manager . . . . . . . . . . . . 328

Distributing the Software Package to the Tivoli Software DistributionEndpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Chapter 14. Upgrading Windows 95 to Windows 98Second Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331


Creating a Response File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Copying the Files That You Need to Perform the Migration to the TMRServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Copying the Windows 98 Second Edition Files to the Image Server . . . . . . 334

Customizing the inst_W98SE.spd Software Package Definition File . . . . . . 335

ixTivoli Software Distribution User’s Guide




Using check_OS^1.0.spd to Verify the Upgrade . . . . . . . . . . . . . . . . . . . . . 338

Chapter 15. Upgrading Windows NT 4.0 Workstationto Windows 2000 Professional . . . . . . . . . . . . . . . . . . . . . . . . . 339


Creating a Response File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Copying the Files That You Need to Perform the Migration to the TMRServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

Copying the Windows 2000 Professional Files to the Image Server . . . . . . 342

Customizing the inst_w2000.spd Software Package Definition File . . . . . . . 343




Using the check_OS^1.0.spd to Verify the Upgrade . . . . . . . . . . . . . . . . . . 346

Appendix. Authorization Roles . . . . . . . . . . . . . . . . . . . . . . . . . 349Setting Up Tivoli Software Distribution Profiles. . . . . . . . . . . . . . . . . . . . . 349

Defining and Deleting Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

Performing Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

x Version 4.0

Notices

References in this publication to Tivoli Systems or IBM products,programs, or services do not imply that they will be available in allcountries in which Tivoli Systems or IBM operates. Any reference tothese products, programs, or services is not intended to imply thatonly Tivoli Systems or IBM products, programs, or services can beused. Subject to Tivoli System’s or IBM’s valid intellectual propertyor other legally protectable right, any functionally equivalentproduct, program, or service can be used instead of the referencedproduct, program, or service. The evaluation and verification ofoperation in conjunction with other products, except those expresslydesignated by Tivoli Systems or IBM, are the responsibility of theuser.

Tivoli Systems or IBM may have patents or pending patentapplications covering subject matter in this document. The furnishingof this document does not give you any license to these patents. Youcan send license inquiries, in writing, to the IBM Director ofLicensing, IBM Corporation, North Castle Drive, Armonk, New York10504-1785, U.S.A.

ISO 9001 Certification

This product was developed using an ISO 9001 certified qualitysystem.

Certification has been awarded by Bureau Veritas QualityInternational (BVQI) (Certification No. BVQI - 92053).

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

xiTivoli Software Distribution User’s Guide

xii Version 4.0

Preface

Tivoli®

Software Distribution provides a means of managing anddistributing software across a multiplatform network. Fordistributions that encompass wide area networks (WANs), TivoliSoftware Distribution has a built-in, WAN-smart capability thatreduces internetwork traffic and ensures an efficient distribution.

This document explains the concepts and procedures necessary foryou to effectively use Tivoli Software Distribution to distributesoftware over local area networks (LANs) and WANs.

Who Should Read This DocumentThis document is intended for system administrators who performsoftware package preparation and deployment operations. Users ofthis document 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 softwareis distributed

Prerequisite and Related DocumentsTo use the information in this document, you should be familiar withthe following manuals:

¶ Tivoli Software Distribution Reference Manual, Version 4.0

Provides detailed information about managing and distributingsoftware from the command line interface (CLI), includinginformation about editing software package definition files.

¶ Tivoli Management Framework User’s Guide, Tivoli Enterprise™

Installation Guide, Tivoli Management Framework Planning for

xiiiTivoli Software Distribution User’s Guide

Deployment Guide, Tivoli Management Framework Maintenanceand Troubleshooting Guide, and Tivoli Management FrameworkReference Manual

Provide detailed information and procedures to manage theTivoli environment from the Tivoli desktop or the CLI, includinginformation about configuring, maintaining, and troubleshootingyour Tivoli installation.

¶ Tivoli Inventory User’s Guide

Provides detailed information about managing hardware andsoftware using Tivoli Inventory.

¶ Tivoli Enterprise Console User’s Guide and Tivoli EnterpriseConsole Adapters Guide

Provides detailed information about integrating network,systems, database, and application management with TivoliEnterprise Console.

What This Document ContainsTivoli Software Distribution User’s Guide, Version 4.0 contains thefollowing sections:

¶ “Overview of Tivoli Software Distribution” on page 1

Provides an introduction to the application by describing theTivoli Software Distribution features, platform-specific options,profile management, Tivoli Software Distribution terminology,and security.

¶ “Planning and Installing Tivoli Software Distribution” onpage 21

Describes how to install Tivoli Software Distribution usingdifferent installation mechanisms.

¶ “Creating a Software Package” on page 41

Using the Appsample scenario, describes the steps required tocreate a software package using the Java™-based SoftwarePackage Editor graphical user interface (GUI), including settingsoftware package properties and adding software packageactions.

Preface

xiv Version 4.0

¶ “Embedding MSI Installation Packages in a Software Package”on page 139

Explains how to embed a Microsoft®

Software Installer (MSI)package in a Tivoli Software Distribution software package.

¶ “How Does AutoPack Work?” on page 149

Introduces the underlying concepts of AutoPack technology,including the preparation machine, AutoPack systemcomponents, the configuration file, customizing the configurationfile to suit particular workstation configurations, the snapshot,the differencing phase, and what AutoPack does to supportshared objects.

¶ “Generating a Software Package Using AutoPack” on page 163

Describes the steps required to create a software package usingAutoPack from the Software Package Editor window. Using theAutoPack Guided Process, a software package is created thatinstalls the Tivoli desktop application.

¶ “Using the PDF Importer Tool” on page 185

Describes the steps necessary to import a Microsoft SystemsManagement Server (SMS) package definition file (PDF) usingthe Importer Tool, and map its contents to a Tivoli SoftwareDistribution software package.

¶ “Understanding the Distribution Environment” on page 197

Introduces a Tivoli Management Region (TMR) scenario toillustrate how to configure a network topology. This chapterprovides steps for setting up a distribution environment that usesendpoint gateways and repeaters.

¶ “The Distribution Process” on page 223

Describes setting up the Tivoli Software Distributionenvironment, including defining profile managers within a policyregion and associating target machines with software packageprofiles. Describes Tivoli desktop functions such as using thebuild function, using the import and export functions, andperforming change management operations.

¶ “Tivoli Software Distribution Web Interface” on page 275

Preface

xvTivoli Software Distribution User’s Guide

The Web Interface for Tivoli Software Distribution enablesUNIX, Microsoft

®

Windows®

95, and Microsoft®

Windows NT®

endpoints to retrieve and install Tivoli Software Distributionprofiles using a Web-enabled browser.

¶ “Integrating the Tivoli Inventory Database” on page 293

Provides a conceptual overview of the Tivoli ManagementFramework query facility and the Tivoli Inventory configurationrepository. This chapter also describes how to enable the TivoliSoftware Distribution historical database and changemanagement status features and how to access information fromthe configuration repository.

¶ “Integrating the Tivoli Enterprise Console” on page 313

Explains how to install and enable the Tivoli Enterprise Consoleintegration product. This chapter also provides a description ofthe Tivoli Software Distribution event configuration file andevent classes.

¶ “Upgrading Windows NT 4.0 with Service Pack 5 or 6” onpage 323

Describes how to upgrade Windows NT Version 4.0 to WindowsNT Version 4.0 with Service Pack 5.0 or Service Pack 6.0.

¶ “Upgrading Windows 95 to Windows 98 Second Edition” onpage 331

Describes how to upgrade Windows 95 to Windows 98 SecondEdition.

¶ “Upgrading Windows NT 4.0 Workstation to Windows 2000Professional” on page 339

Describes how to upgrade Windows NT Version 4.0 Workstationto Windows 2000 Professional.

¶ “Authorization Roles” on page 349

Describes the roles required to perform Tivoli SoftwareDistribution Version 4.0 tasks.

Preface

xvi Version 4.0

Conventions Used in This DocumentThe document uses several typeface conventions for special termsand actions. These conventions have the following meaning:

Bold Lowercase or mixed-case commands, commandoptions in a syntax statement, the names of objectsin procedures that you type, select, click, or press, orany other information that you must use literallyappear like this, in bold.

Italics Variables, new terms, and words and phrases that areemphasized appear like this, in italics.

Monospace Code examples, output, and system messages appearlike this, in a monospace font.

Platform-specific InformationThe following table identifies the supported platform versions knownat the time of publication. For more detailed and up-to-dateinformation, please see the release notes.

Table 1. Supported PlatformsPlatform Supported Versions

AIX 4.x Server, Gateway, Endpoint:IBM

®

RS/6000®

series running AIX,Versions 4.2.1, 4.3.0, 4.3.1, 4.3.2, 4.3.3

HP-UX®

Server, Gateway, Endpoint:HP9000/700 and 800 series running HP-UX,Versions 10.2, 11 SP1, 11.1

NetWare Gateway, Endpoint:IBM-compatible PCs 486 or higher running NovellNetWare, Versions 4.11, 4.2, 5, 5 SP1, 5 SP2

OS/2®

Tivoli Desktop for Windows: Gateway, Endpoint:IBM-compatible PCs 486 or higher running IBMOS/2,Warp Connect V4, Warp Server V4,

Warp Server SMP V4, WSOD R2V4, WSOD R2Win32, Warp Server for e-business, Warp Clientfor e-business

Preface

xviiTivoli Software Distribution User’s Guide

Table 1. Supported Platforms (continued)Platform Supported Versions

Solaris Server, Gateway, Endpoint:Sun SPARC series running Solaris,Versions 2.6, 7, 7.1, 7.2

Windows Tivoli Desktop for Windows: Endpoint:IBM-compatible PCs 486 or higher runningMicrosoft Windows 95 (or later)

Windows NT Tivoli Desktop for Windows: Server, Gateway,Endpoint: IBM-compatible PCs 486 or higherrunning Microsoft Windows NT, Versions 4.0 SP4,4.0 SP5, 4.0 SP6a, 4.0 Terminal Server Edition 4.0

Tivoli Desktop for Windows: Endpoint:Windows 2000

Tivoli Software Distribution IconsThe following icons represent the Tivoli Software Distributionprofile resource displayed on the Tivoli desktop in different formats:

Icon for software package profile icon in built format.

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

Icon for empty software package profile.

Preface

xviii Version 4.0

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

Accessing Publications OnlineThe 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’sguides, redbooks, and white papers. You can access Tivolipublications online at http://www.tivoli.com/support/documents/.The documentation for some products is available in PDF andHTML formats. Translated documents are also available for someproducts.

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

Resellers should refer tohttp://www.tivoli.com/support/smb/index.html for moreinformation about obtaining Tivoli technical documentation andsupport.

Business Partners should refer to “Ordering Publications” for moreinformation about obtaining Tivoli technical documentation.

Ordering PublicationsOrder Tivoli publications online athttp://www.tivoli.com/support/Prodman/html/pub_order.html orby calling one of the following telephone numbers:

¶ U.S. customers: (800) 879-2755

¶ Canadian customers: (800) 426-4968

Preface

xixTivoli Software Distribution User’s Guide

Providing Feedback about PublicationsWe are very interested in hearing about your experience with Tivoliproducts and documentation, and we welcome your suggestions forimprovements. If you have comments or suggestions about ourproducts and documentation, contact us in one of the followingways:

¶ Send e-mail to [email protected].

¶ Fill out our customer feedback survey athttp://www.tivoli.com/support/survey/.

Contacting Customer SupportIf you need support for this or any Tivoli product, contact TivoliCustomer Support in one of the following ways:

¶ Submit a problem management record (PMR) electronically fromour Web site at http://www.tivoli.com/support/reporting/. Forinformation about obtaining support through the Tivoli CustomerSupport Web site, go to http://www.tivoli.com/support/getting/.

¶ Submit a PMR electronically through the IBMLink™ system. Forinformation about IBMLink registration and access, refer to theIBM Web page at http://www.ibmlink.ibm.com.

¶ Send e-mail to [email protected].

¶ Customers in the U.S. can call 1-800-TIVOLI8(1-800-848-6548).

¶ Customers outside the U.S. should refer to the Tivoli CustomerSupport Web site athttp://www.tivoli.com/support/locations.html for customersupport telephone numbers.

When you contact Tivoli Customer Support, be prepared to providethe customer number for your company so that support personnelcan assist you more readily.

Preface

xx Version 4.0

Overview of Tivoli SoftwareDistribution

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

Software deployment can be a challenge in large distributednetworks that comprise thousands of systems with multipleplatforms. Attempts to solve deployment management problems oftenresult in the inefficient use of resources and personnel when toomany system administrators use multiple tools to manage a system.

Tivoli provides an efficient, scalable solution to these deploymentmanagement issues. Using Tivoli applications, administrators cancreate and distribute desktop and client/server applications, managethe software life cycle, automate system inventories, and monitorsystem and configuration changes.

Tivoli Software Distribution can quickly and reliably deploysoftware across multiplatform networks, which can include UNIX,NetWare, Windows NT, Windows 95, Windows 98, and OS/2systems at remote sites.

1

1Tivoli Software Distribution User’s Guide

1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

Coexistence with Previous Product VersionsTivoli Software Distribution, Version 4.0 is a new product and notan upgrade of Tivoli Software Distribution, Version 3.6.x. While thisnew product does not require the installation of previous versions, itcan coexist with Tivoli Software Distribution, Versions 3.6.1 and3.6.2, which also run on Tivoli Management Framework, Version3.7.

You may choose to install both the new version and a previousversion of Tivoli Software Distribution in order to:

¶ Ease the migration from a previous version to the new version.

¶ Maintain backward compatibility with Tivoli Plus Modules thatrequire Tivoli Software Distribution 3.6.x.

¶ Keep your current, customized environment operational whilebeginning to exploit the new features offered by Tivoli SoftwareDistribution, Version 4.0.

The wfptosp migration command has been provided to assist you inmigrating TME 10 Software Distribution Version 3.6 (or later) filepackages to Tivoli Software Distribution, Version 4.0 softwarepackages. Refer to the Tivoli Software Distribution ReferenceManual, Version 4.0 for more information.

Tivoli Software Distribution HighlightsTivoli Software Distribution provides a centralizedsoftware-management system with which administrators can usesoftware packages to install and configure new applications, updateexisting software with newer versions, and synchronize software ondistributed systems. Tivoli Software Distribution, Version 4.0introduces new features that increase the power and ability tomanage software across a network. The following are somehighlights:

¶ Remote distribution and scalability—a centralized point ofcontrol for automated software distribution across heterogeneousnetwork computing environments.

Highlights

2 Version 4.0

¶ Software package preparation facility—the Software PackageEditor provides several ways for you to create and edit asoftware package. It supplies the following features:

v Unified software package

Tivoli Software Distribution, Version 4.0, unlike previousversions, makes use of a simplified single content packagingformat called the software package. All of the techniquesused to create software packages are based on this single fileformat. Therefore, a software package created using AutoPackis identical to a package created manually using the SoftwarePackage Editor, and both can be edited using any of theavailable techniques explained in this chapter.

v Variables

Variables can be used to express any attribute value of typestring contained in the software package, making a softwarepackage more generic for use on different target systems. Forexample, it is not necessary to create several softwarepackages for different platforms. You can substitute theplatform-specific information with variables and use the samesoftware package for distribution to multiplatform networks.Refer to the Tivoli Software Distribution Reference Manual,Version 4.0 for more details on using variables in thesoftware package.

v Conditions

You set conditions on the actions contained in a softwarepackage or on the entire software package. Using conditions,you define the circumstances under which an action isexecuted. For example, you can specify which actions are tobe executed on Windows 98 target systems and which are tobe executed only on Windows NT. This feature expands uponthe 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 theassociated installation utilities and response files, can bepackaged within the software package. Alternatively, they can

Highlights


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

be referred to as external files if they are already accessibleby the target systems such as the following:

– Microsoft Setup

– InstallShield

– Configuration, installation, and distribution (CID)programs

– Microsoft Software Installer (MSI)

¶ Automatic software package generation—AutoPackautomatically generates a software package by employingscanning and differencing technology, and comparing twosuccessive “snapshots” of a preparation machine.

¶ Import application definition files of a different format—the PDFimporter tool leads you through the process of importing aMicrosoft package definition file (PDF) and converting it into asoftware package.

¶ Tools for creating InstallShield and Microsoft Setup programobjects that can be added to the software package.

¶ Support for file packages of previous product releases. Filepackages and the new software package format can co-existwithin the same profile manager as different resource types.

¶ A migration tool to convert file package objects and file packagedefinition files to software package objects and software packagedefinition files. The keywords contained in file packages createdwith a previous product release are mapped to software packagestanzas, attributes, and commands. Refer to the Tivoli SoftwareDistribution Reference Manual, Version 4.0 for more informationabout migration procedures.

¶ Software package distributions and operations—Using the Tivolidesktop, you can perform change management operations tofully automate the distribution and installation of software. Newsupport features include the following:

v Automatic undo

Highlights

4 Version 4.0

You can choose to perform an undo operation on the softwarepackage so that, in the event of a fatal error during theinstallation process, the undo operation is triggeredautomatically and returns the system to its state prior to theexecution of the last installation or removal operation. Thismeans that any files added by the installation that did notexist prior to the distribution will be removed. Files thatexisted prior to the distribution and were removed will beadded back. Files that existed prior to the distribution andwere replaced, will be restored to the previous copy. This isalso true for any additions, deletions, or changes made toconfiguration 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 toverify that the target objects have been successfully installedon the target system.

v Locked file support

During a distribution, if a locked file is encountered,normally it cannot be updated. Distributing the softwarepackage in transactional mode enables you to take advantageof the locked file support feature, which permits the updatingof locked files by specifying that the target system is to berestarted at the time of installation or at the next regularsystem start up.

v Shared object support

Because many applications use the same resources, sharedfiles and directories must be identified in the softwarepackage. Using a shared attribute on files and directories, youcan share files and directories among multiple applications. Ifa software package is designed to remove an application froma target system, and one of the objects contained in thesoftware package is identified as a shared resource, the objectis removed when the last application using this resource isremoved. If a shared resource in a software package is foundto exist on the target, the latest version of the resource isused.

Highlights


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

v File version support

You can set different properties on objects in the softwarepackage to manage their behavior. For example, if an objectcontained in a software package already exists on the targetsystem, you can configure the object properties so that TivoliSoftware Distribution replaces the existing copy only if thecreation date of the copy is earlier than the file or directorycontained in the software package.

v Source repair functionality

The repair functionality reduces network congestion byidentifying which source and targets objects have beenmodified or corrupted since the last successful installation ofa software package, and rebuilding the software package withonly these objects rather than installing the entire packageagain.

¶ A more complete distribution engine—Tivoli SoftwareDistribution performs distributions of large amounts of data tomultiple target systems. It relies on the multiplexed distribution(MDist 2) service, which it uses to simultaneously distributelarge amounts of data to targets in an enterprise. The benefitsinclude the following:

v Asynchronous delivery

The MDist 2 service submits distributions and immediatelycommunicates the status of each distribution on each targetsystem without waiting until the distribution has completedfor all targets.

v Assured delivery

MDist 2 distributions are cached in local files on eachrepeater. If a connection to a receiver cannot be establishedor is broken, the distribution is maintained in the cache untilthe connection is re-established and the distribution can bedelivered. This feature includes the ability to resumedistributions after network errors caused by machine restartsor power failures.

v Checkpoint restart

Highlights

6 Version 4.0

When a distribution is interrupted due to a network failure,machine restart, or power failure, the distribution isautomatically resumed from the point where the interruptionoccurred rather than resending the entire distribution from thesource host. However, a distribution terminated by theadministrator will restart from the beginning. Pauseddistributions exploit the checkpoint restart feature. Thecheckpoint restart feature is a Tivoli Software Distributiondefault.

v Distribution control

System administrators can use MDist 2 to access and controldata distributions initiated by different applications. Thegraphical user interface (GUI) displays a list of all completedand pending distributions and their status on each endpoint(waiting, successful, failed, in progress, paused, interrupted,unavailable, cancelled, or expired). Administrators can pause,resume, and cancel distributions for some or all of thedistribution destinations.

v Pending distribution queues

MDist 2 distributions can have three priority levels: low,medium or high. Priority levels determine the order in whichdistributions are handled by repeaters. Distributions withhigher priority levels are handled before ones with lowerpriority. Distributions with the same priority level are handledin the order in which they are received by a repeater. MDist2 also allows a maximum number of available connections tobe specified for each priority level. A distribution with agiven priority level uses the number of connections reservedfor its priority level plus any connections allocated for lowerpriority levels.

v Depoting

A depot is a directory on the repeater site that enables you totemporarily or permanently store data segments associatedwith distributions. This enables software distributions to bestored on nodes closer to the targets. The administrator canpush software packages from the depot to target systemsassociated with that depot.

Highlights


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

These features enable you to perform rapid and optimal softwaredistributions. For more information about the MDist 2 service,refer to the Tivoli Management Framework Planning forDeployment Guide.

¶ Operating system upgrades—Tivoli Software Distributionsupports operating system upgrades for the Windows operatingsystem family.

¶ Application configuration—by installing software packages, youcan perform actions such as changing the registry, addingdesktop icons, adding statements to system files, and creatingfolders and shortcuts. Tivoli Software Distribution, Version 4.0eliminates the need to create scripts and programs to configurean application. You can package the required action in thesoftware package.

¶ Integration with other Tivoli applications—the following listdescribes Tivoli Software Distribution’s integration with otherapplications and services:

v A system administrator can use Tivoli Inventory and theTivoli Management Framework query facility to query aconfiguration repository to determine the appropriate targetsof a distribution, as well as to track information aboutsoftware distributions and the change management status ofsoftware packages on target systems.

v Using the Tivoli Management Framework Scheduler, you canschedule jobs at a future time, repeat scheduled jobsindefinitely or repeat them for a specified number of times.

v Through integration with the Tivoli Enterprise Console, TivoliSoftware Distribution sends events to the event console forall distribution operations.

v The Tivoli Software Distribution Web Interface enablesUNIX and Windows NT endpoints to retrieve and installTivoli Software Distribution profiles using a Web-enabledbrowser.

Highlights

8 Version 4.0

¶ Network and system optimization—GUI-based management forease of use, coupled with a powerful command line interface(CLI) and advanced text-based options.

The rest of this chapter introduces the main features of TivoliSoftware Distribution and its concepts; the functions are covered indetail in later chapters.

The Tivoli Software Distribution EnvironmentTivoli Software Distribution, Version 4.0 contains a new softwarepackage structure and a set of software administration operations.This section briefly reviews basic Tivoli Management Frameworkcomponents and terminology in the context of the Tivoli SoftwareDistribution product.

When you install Tivoli Software Distribution, you add a new profiletype, the software package, to the Tivoli environment. You can thenmanage the software package within the Tivoli ManagementFramework. Software packages are imported into the Tivolienvironment and are associated with profiles. Software packageprofiles contain references to data, and instructions about how thedata is to be distributed. All references to data are resolved atdistribution time. Also, the software package profile icons appearonly in the profile manager in which they were created.

Policy regions, profile managers, and profiles are mechanismsprovided by the Tivoli Management Framework to help organizeresources hierarchically. You use this hierarchy to associate softwarepackages with target machines. As with other Tivoli profile-basedapplications, Tivoli Software Distribution functions in the context ofa profile manager. Software packages are created in a profilemanager, which contains profiles and links subscribers to profiles.

Source HostThe source host is the system on which the files contained in thesoftware package block are obtained, the software package block isstored, and the files referenced in the software package and softwarepackage definition file are located. Any UNIX, OS/2 or Windows

Highlights


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

NT system in your Tivoli environment can be a source host afterTivoli Management Framework and Tivoli Software Distribution areinstalled.

The effects of distributing a Tivoli Software Distribution profiledistribution are different than those of other Tivoli profiles. Forexample, when you distribute a software package profile, youexecute actions such as adding files and directories from the sourcehost to the target, removing files and directories from the target,checking disk space on the target, and adding Windows registrykeys. For more information about profiles and profile managers,refer to the Tivoli Management Framework Planning for DeploymentGuide.

Distribution TargetsTivoli Software Distribution, Version 4.0 enables you to distributesoftware packages to endpoints. A subscriber is an endpoint or aprofile manager that is the target of the distribution. Only endpointscan be targets of distributions. Managed nodes are no longersupported as targets with this release. The Tivoli ManagementFramework endpoint agent must be installed on managed nodes andthe Tivoli Management Region (TMR) server in order to becomepossible targets of a software distribution. In the Tivoli environment,an endpoint is a Tivoli client that receives Tivoli operations. Eachendpoint is assigned to an endpoint gateway, which provides allcommunication services between a group of endpoints and the rest ofthe Tivoli environment. The gateway includes the multiplexeddistribution (MDist 2) function, enabling this gateway to act as thefanout point for distributions to many endpoints. Refer to the TivoliManagement Framework Planning for Deployment Guide fordetailed information about how endpoints and gateways can beconfigured and used in the Tivoli environment.

Software PackagesA software package contains a collection of actions to be performedon a workstation. After you create a software package and catalog itat the Tivoli Software Distribution server, you can use changemanagement operations to manage how the package actions are to be

Tivoli Software Distribution Environment

10 Version 4.0

executed. The new software packaging facility, the Software PackageEditor, provides several ways for you to create and edit softwarepackages. It organizes actions into three categories: Add and Removeobject-related actions, System actions, and Program actions.

Object-Related ActionsThe add and remove object actions drive the engine to add thespecified object to the system or to remove it from the system.Objects can be files, directories, registry keys, registry values, and soon. The types of add and remove actions and their objects include:

¶ Text file objectsv Linesv Command linesv Tokens

¶ File system objectsv Filesv Directoriesv File system links

¶ Windows registry objectsv Keysv Values

¶ Windows shell objectsv Foldersv Links

¶ Windows profile objectsv Sectionsv Items

¶ OS/2 desktop objectsv Generic objectsv Foldersv Programsv Shadows

¶ OS/2 profile objectsv Profilesv Items

Software Packages


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

¶ Windows NT services

System ActionsThese actions include the following:

¶ Check disk space

Include this check in your software package to be sure there issufficient disk space on the target machine.

¶ Restart

Insert this action in your software package if a computer oroperating system restart is necessary with the installation of anapplication.

Program ActionsProgram actions involve the execution of generic programs or theuse of third-party packaging utilities on a target system. Theyinclude the following:

¶ Execute Program

¶ Execute CID Program

¶ InstallShield Program

¶ Microsoft Setup Program

You can further organize and define actions in the software packageas follows:

¶ By using conditions, you can define the circumstances underwhich an action should be executed. For example, you can set acondition on the Add Directory action specifying that this actionbe executed only on Windows 98 target systems. Conditions canbe set on individual objects, or on the entire software package.

¶ You can use a generic container to group actions together thatmust satisfy the same condition so that change managementoperations can be executed on the actions as a group. You caninclude this container in the software package and nest othercontainers and actions inside it.

Software Packages

12 Version 4.0

¶ To make software packages more generic for use on targetworkstations with different configurations and operating systems,you can use several types of variables. Refer to the TivoliSoftware Distribution Reference Manual, Version 4.0 for moreinformation about using variables in the software package.

A software package can also be created by defining its contents in atext file known as the software package definition (SPD) file. Youcreate a software package in this file format using the SoftwarePackage Editor graphical user interface, manually by using a texteditor, or by exporting an existing software package and modifyingit.

You can also use the CLI to create and manage software packages.Refer to the Tivoli Software Distribution Reference Manual, Version4.0 for more information about using software package definitionfiles and CLI commands.

Nested Software PackagesBy adding a software package as an entry to another softwarepackage, you can create a nested software package. The softwarepackage that contains the nested software package is the primarypackage. You specify nested software packages when you create theprimary package, or you can nest them using the drag-and-dropmethod from the Tivoli desktop. When Software Distributiondistributes a software package that contains nested softwarepackages, it also distributes the nested software packages. Nestedpackages are executed in the order in which they are listed in theprimary package. By default, the nested software packages areprocessed after the primary software package. There is no limit tothe number of levels of nested software packages contained in theprimary package. In addition, you can nest software packages thatbelong to different TMRs.

When software packages are nested in a primary package, thechange management operations performed on the primary softwarepackage are also performed on the nested software packages. Thenested software packages inherit most of the properties from theprimary package. For example, nested software packages inherit thedefault change management operation, operation mode, and

Software Packages


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

distribution targets of the primary package. However, there arecertain properties specified in the nested software package thatcondition the primary software package. For example, if thecommittable option is specified in the nested software package, theprimary software package must be installed in transactional mode. Ifthe undoable option is specified in the nested software package, theprimary software package must be installed in undoable mode.

For instructions on nesting software packages, see “Nestedpackages” on page 126. See “Distributing Nested Software Packages”on page 268 for instructions and an example of distributing nested

software packages.

Software Package EditorThe Software Package Editor is a graphical interface for creating andcustomizing a software package. It can be installed on any of youravailable endpoints except NetWare endpoints. The SoftwarePackage Editor displays a graphical tree view of the softwarepackage and its contents. You organize the actions that are containedin the package in the order in which they are to be executed on thetarget system. There are several techniques available to createsoftware packages from the Software Package Editor window:

¶ Create a new software package.

¶ Open existing software packages and modify them to create newones.

¶ Use AutoPack to automatically generate a software packageusing differencing technology.

¶ Use the PDF importer tool to map specific information from aMicrosoft PDF to a software package.

See “Creating a Software Package” on page 41 for more informationabout using the Software Package Editor.

Software Packages

14 Version 4.0

Software Package FormatsRegardless of the method used to create a software package, theoutput can be saved in any of the following formats:

¶ software package file (.sp)

¶ software package definition file (.spd)

¶ software package block (.spb)

A software package in the .spd file format can be opened in theSoftware Package Editor. You can then choose to resave it as an .spdfile, or save it as one of the other file types available. For moreinformation about software package definition parameters, keywords,and formats, refer to the Tivoli Software Distribution ReferenceManual, Version 4.0.

Software Package (.sp) FileA software package saved in this format is the zipped format of an.spd file. It contains only a description of the actions to beperformed on the target system and not the files and resourcesnecessary to execute the actions. The files and resources reside onthe source host. The software package file format is the defaultformat used by the Software Package Editor. Because the softwarepackage in this format is only a description of the software package,it is in the not-built format.

Software Package Definition (.spd) FileThe software package definition file is the text version of a softwarepackage. An .spd file contains only a description of the objectscontained in the package, that is, a sequential list of actions to beexecuted on the target system and not the actual objects or resourcesthemselves. It consists of a sequence of stanzas, each of whichdescribes an action to be executed. Using a text editor, you canmodify an .spd file by manipulating the stanzas, then reopen the filein the Software Package Editor and save it in another format. Asoftware package in this format is in the not-built format.

Software Package Formats


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

Software Package Block (.spb)A software package block bundles all the resources necessary toexecute the actions contained in the software package into a standardzipped format. At distribution time, the resources do not need to becollected from the source host; they are already contained in thesoftware package block. When the software package block isdistributed to an endpoint, it is not stored on the endpoint, but isunzipped in the target directory. By unpacking the zipped fileimmediately, there is no need for additional disk space on theendpoint for the .spb file. A software package that contains all itsresources is in the built format. The maximum size of a softwarepackage block is 2 GB.

Software Package ObjectA software package object is a software package in either the built(.spb) or not-built (.sp, .spd) format that has been imported into theTivoli environment. The data to be distributed resides on the sourcehost, if the software package is in the not-built format, or in the .spbfile, if the software package is in the built format. References to dataare resolved at distribution time. The software package is cataloguedat the Tivoli Software Distribution server as a software packageobject in the Tivoli database.

Choosing a Software Package FormatIf you have created a software package using the Software PackageEditor on an endpoint or on a managed node, you must choose oneof the following software package formats:

¶ The built format (a software package block, using the files onthe local machine)

¶ The not-built format (a software package file or softwarepackage definition file)

Each format has its advantages. For example, if you maintain thesoftware package in the not-built format, you can revise the softwarepackage until the moment of distribution. The consolidation of theactions with the files and resources does not occur until distribution,and the most current files on the source host are used to build thepackage. Also, because a software package in the not-built format


16 Version 4.0

does not contain the files and resources to be distributed, it occupiesa smaller amount of disk space than a software package block.

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

Tivoli Desktop OperationsPolicy regions, profile managers, and profiles are mechanismsprovided by the Tivoli desktop to help organize resourceshierarchically. An administrator will ultimately use this hierarchy toassociate software packages with target systems. Profiles are theresources that are distributed. From the Tivoli desktop, you import asoftware package into the Tivoli environment by associating it to aTivoli Software Distribution profile contained in a profile manager.Right-click the software package profile to display a pop-up menucontaining a list of tasks you can perform on software packages,such as calculating software package size, converting the softwarepackage to different formats, exporting the software package to the.spd file format, and editing the software package by launching theSoftware Package Editor. From the pop-up menu, you can also selectchange management operations such as install, remove, undo, accept,commit, and verify. The interface drives the execution of all theoperations supported by the server CLI. See “The DistributionProcess” on page 223 for information about the Tivoli desktop andits functions.

Change Management OperationsTivoli Software Distribution offers you a number of changemanagement operations that you can use on a software packageobject to fully automate the distribution and installation of software.You can launch operations from any managed node where thenecessary components are installed. After you create a softwarepackage and catalogue it at the Tivoli Software Distribution server,you can use the following operations to manage how package actionsare executed. Tivoli Software Distribution performs the followingchange management operations:



1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

Install Performs the actions needed to install a software package.

RemoveUninstalls a software package.

Undo Returns the system to its previous state. prior to the lastinstall or remove operation.

AcceptDeletes the backup package, so the previous operation canno longer be undone.

CommitCauses all the updates performed in the preparation phase totake effect.

Verify Verifies the consistency of the software package and theobject on the target system. If the verify operation fails, thesoftware package is placed in an error state.

These Tivoli Software Distribution operations can be executed indifferent modes. See “Change Management Operations” on page 244for more information about change management operations andmodes.

SecurityTivoli Software Distribution uses Tivoli authorization roles to ensuresecure and authorized use of the application. To perform anoperation within Tivoli Software Distribution, you must have therequired authorization role for the task. In general, the roles in thecontext of Tivoli Software Distribution are as follows:

Role Operations

super Install and remove an application; perform operations listed forsenior, admin, and user

senior Create, delete, and clone software packages; edit software packageproperties; import software package definitions; perform operationslisted for admin and user

Tivoli Desktop Operations

18 Version 4.0

Role Operations

admin Subscribe resources to a profile manager, schedule and performsoftware package distributions, remove software packages fromsubscribers, perform operations listed for user

user View software packages, export software package definitions

install-product Install Tivoli Software Distribution

Tivoli Software Distribution enables you to perform policy validationfor all aspects of software packages. For more information aboutpolicy, refer to the Tivoli Software Distribution Reference Manual,Version 4.0.

Security


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

20 Version 4.0

Planning and Installing TivoliSoftware Distribution

The Tivoli Software Distribution application adds softwaredistribution capabilities to the Tivoli environment. This chapterprovides information about planning your Tivoli SoftwareDistribution environment and installing the components of theapplication using different installation mechanisms.

See the release notes for system requirements for all Tivoli SoftwareDistribution products.

Tivoli Software Distribution ComponentsTivoli Software Distribution includes the following components:

Tivoli Software Distribution Server, Version 4.0Installs the Tivoli Software Distribution server component.Install this product component on your TMR server.

Tivoli Software Distribution Gateway, Version 4.0Installs the files that enable an endpoint gateway torecognize Software Distribution methods, download themethods to endpoints, and execute the methods on theseclients to perform the requested Software Distributionoperation. Install this product on all managed nodes that areconfigured as endpoint gateways or which you plan toconfigure as endpoint gateways.

2


2.P

lann

ing

and

Installin

g

Tivoli Software Distribution Source Host, Version 4.0The source host is the system on which the files referencedin the software package are located and obtained to build thesoftware package into the software package block format.The software package block is also stored on the sourcehost. Install this product component on any of the availablemanaged nodes where you will create Tivoli SoftwareDistribution profiles or where you will run Tivoli SoftwareDistribution commands from the command line. You candesignate any managed node as a source host. However, youshould consider the disk space requirements necessary tostore the software package blocks and the files referenced inthe software package.

Note: For the source host to also function as a gateway, youmust install the Tivoli Software DistributionGateway component.

Tivoli Software Distribution Software Package EditorInstalls the files that enable the Tivoli desktop to launch theJava-based Software Package Editor on a managed node sothat you can create new software packages or modifyexisting software packages and import them into the Tivolienvironment. If you want the managed node to serve as asource host, the Tivoli Software Distribution Source Hostcomponent must be previously installed on the managednode.

Note: The Tivoli Software Distribution Software PackageEditor component is not supported on OS/2 managednodes.

Tivoli Software Distribution Java Endpoint Package EditorConsists of a series of platform-specific software packagesthat are installed on all endpoint-supported platforms usingthe Tivoli Software Distribution, Version 4.0 product. Thiscomponent enables you to use the Software Package Editorin stand-alone mode on the endpoint to create softwarepackages and test them by installing them locally using thecommand line on the disconnected target. You can also use

Tivoli Software Distribution Components

22 Version 4.0

The Software Package Editor from the Tivoli desktop on theendpoint to modify software packages and import them intothe Tivoli environment.

If the Tivoli Software Distribution Software Package Editoris already installed on a managed node and the managednode is also an endpoint, do not install the Tivoli SoftwareDistribution Java Endpoint Package Editor component. Youshould not install the Tivoli Software Distribution SoftwarePackage Editor and the Tivoli Software Distribution JavaEndpoint Package Editor on the same machine.

Tivoli Software Distribution Historical Database, Version 4.0Installs and enables the Historical Database and ChangeManagement Status features that automatically update theTivoli Inventory configuration repository with informationabout Software Distribution operations that have beenperformed in your Tivoli environment. You must have theTivoli Inventory product installed prior to installing thiscomponent. See “Integrating the Tivoli Inventory Database”on page 293 for in-depth information about using this

feature to access information from the configurationrepository.

Tivoli Software Distribution TEC Integration, Version 4.0Installs the files that enable Tivoli Software Distribution tosend events to the Tivoli Enterprise Console event serverwhen a Tivoli Software Distribution operation is performed.You must have Version 3.6.2 of the Tivoli EnterpriseConsole (TEC) and the Tivoli Enterprise Console Serverinstalled prior to installing this component, and you mustinstall this integration product on each event server in yourTMR. Also, you must create an event console prior toinstalling Tivoli Software Distribution TEC Integration andthen use the sdtecsrvr_inst.sh script to install the TivoliSoftware Distribution event classes to the TEC event server.The script enables Tivoli Software Distribution to sendevents to the TEC server.



2.P

lann

ing

and

Installin

g

See “Integrating the Tivoli Enterprise Console” on page 313for in-depth information about configuring and using thisproduct.

The relationship between all of the Tivoli Software Distributioncomponents are shown in the following figure:

Notes:

1. The TMR server automatically serves as a source host.Therefore, you do not need to install the Tivoli SoftwareDistribution Source Host component on the TMR server.However, you must install the Tivoli Software DistributionSource Host component on other managed nodes that you wantto serve as source hosts.

2. The TMR server cannot function as a Tivoli SoftwareDistribution gateway unless you install the Tivoli SoftwareDistribution Gateway component on it.


24 Version 4.0

Installing Tivoli Software Distribution ProductsBefore and after you install Tivoli Software Distribution, Tivolirecommends that you back up your Tivoli database for all machinesin the TMR. Creating backups will enable you to return to the stateof the object database before installation if, for some reason, youencounter a problem while installing the product. To create a backupof the Tivoli server and clients, select Backup from the Desktopmenu or use the wbkupdb command. Refer to the TivoliManagement Framework Reference Guide for information about thewbkupdb command.

After installing Tivoli Software Distribution, update the managedresource types of policy regions in which you want to createsoftware packages. Also, update the notice group subscriptions ofany administrators who will receive Tivoli Software Distributionnotices. Refer to the Tivoli Management Framework Planning forDeployment Guide for instructions about changing managed resourcetypes and on assigning administrator’s properties.

You can install Tivoli Software Distribution using any of thefollowing installation mechanisms:

¶ Tivoli Software Installation Service

¶ Tivoli desktop

¶ The Tivoli Management Framework commands winstall orwpatch

Product InstallTo successfully install Tivoli Software Distribution for the first time,you must complete the following tasks:

1. Ensure Tivoli Management Framework 3.7 is installed

2. Install Tivoli Software Distribution Server, Version 4.0

Depending on the deployment plan you have created, you can installthe following optional Tivoli Software Distribution components:

¶ Tivoli Software Distribution Gateway, Version 4.0

¶ Tivoli Software Distribution Source Host, Version 4.0

Installing Tivoli Software Distribution Products


2.P

lann

ing

and

Installin

g

¶ Tivoli Software Distribution Software Package Editor

¶ Tivoli Software Distribution Java Endpoint Package Editor

¶ Tivoli Software Distribution TEC Integration, Version 4.0

¶ Tivoli Software Distribution Historical Database, Version 4.0

You can install the components of Tivoli Software Distribution usingdifferent installation mechanisms. The following sections provideinformation about these methods of deployment.

Components AvailableThe following table lists the components of Tivoli SoftwareDistribution that you can install in your environment. Theinstallation images are in the root\images path on the compact disk(CD), where root represents the CD-ROM drive.

Index File Component Name Product Tag

SWDISSRV Tivoli Software Distribution Server, Version 4.0 swdissrv

SWDISGW Tivoli Software Distribution Gateway, Version 4.0 swdisgw

SWDISSH Tivoli Software Distribution Source Host, Version 4.0 swdissh

SWDISJPS Tivoli Software Distribution Software Package EditorNote: This component is not supported on an OS/2managed node.

swdisjps

N/A Tivoli Software Distribution Java Endpoint Package EditorNote: This component is packaged into a Tivoli SoftwareDistribution, Version 4.0 software package block. You mustinstall this software package block on each endpoint. See“Installing the Tivoli Software Distribution Java EndpointPackage Editor” on page 30 for instructions.

N/A

SWDISTEC Tivoli Software Distribution TEC Integration, Version 4.0 swdistec

SWDISDB Tivoli Software Distribution Historical Database, Version4.0

swdisdb

¶ The index file is used for installing the component using thewinstall and wpatch commands.

¶ The component name is used for installing the component fromeither the Tivoli desktop or SIS console.


26 Version 4.0

¶ The product tag is used for uninstalling the component using thewuninst command.

Installation OptionsThe following table lists an installation option that can be specifiedwhen you install the Tivoli Software Distribution Java EndpointPackage Editor. This component is a software package installed fromthe Tivoli desktop using change management operations onendpoints. See “Change Management Operations” on page 244 formore information about executing change management operations.No other installation options exist when installing the remainingTivoli Software Distribution components.

GUI Field Name CLI Attribute Description

Default Variable Name target_dir From the Tivoli desktop, you can usethe Default Variables dialog to overridethe default value of the target_dirvariable so that, when the softwarepackage is installed on an endpoint,you can define a location other than theproduct directory. The default value ofthe target_dir variable isproduct_dir/speditor and is stored inthe swdis.ini file. See “Other AdvancedOptions” on page 257 for more detailsabout 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 componentwith both the Software Package Editorcapability and the disconnectedcommand line interface capability.Change the value to CLI to install thecomponent with only the disconnectedcommand line capability.

Installing Tivoli Software Distribution with Tivoli SoftwareInstallation Service

The Tivoli Software Installation Service can install multiple Tivoliproducts on multiple systems in parallel. This Java-based product



2.P

lann

ing

and

Installin

g

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

The basic procedure for using Tivoli Software Installation Service toinstall the components of Tivoli Software Distribution is as follows:

1. Import the product images into the Tivoli Software InstallationService Depot.

2. Select the components to be installed.

3. Specify the installation options, if necessary. See “InstallationOptions” on page 27 to determine whether installation options arerequired for each component.

4. Select the machines where each component is to be installed.

5. Click Install.

For detailed information about using Tivoli Software InstallationService to install the components, refer to the Tivoli EnterpriseInstallation Guide, Version 3.7.

Installing Tivoli Software Distribution with the TivoliDesktop

You can also install Tivoli Software Distribution products from thedesktop. The basic procedure for using the Tivoli desktop to installcomponents of Tivoli Software Distribution is as follows:

1. From the Desktop menu, select Install→Install Product.

2. Select the media and component.

3. Specify the installation options, if necessary. See “InstallationOptions” on page 27 to determine whether installation options arerequired for each component.

4. Select the machines on which to install the component.

5. Click Install.

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


28 Version 4.0

Activity Context Required Role

Install Tivoli SoftwareDistribution products

Tivoli environment super orinstall-product

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

Installing Tivoli Software Distribution Using the winstallCommand

The following are examples of using the winstall command to installthe components of Tivoli Software Distribution. See the table“Components Available” on page 26 for a list of components andtheir associated index file names. The index file name is used in thewinstall command.

Note: If you do not specify a managed node when using thewinstall command, the components will be installed on allclients.

¶ To install the Tivoli Software Distribution Server component onTMR server jupiter from a CD-ROM image, place the files inthe default location, then enter the following command:winstall –c \root\images\cdrom -i SWDISSRV jupiter

where:

-c \root\images\cdromSpecifies the path to the CD-ROM image.

-i SWDISSRVSpecifies the product installation index file to install.

¶ To install the Tivoli Software Distribution Gateway componenton managed node juno from a CD-ROM image, place the filesin the default location, then enter the following command:winstall –c \root\images\cdrom -i SWDISGW juno

¶ To install the Tivoli Software Distribution Source Hostcomponent on managed node juno from a CD-ROM image,place the files in the default location, then enter the followingcommand:



2.P

lann

ing

and

Installin

g

winstall –c \root\images\cdrom -i SWDISSH juno

¶ To install the Tivoli Software Distribution Software PackageEditor component on managed node juno from a CD-ROMimage, place the files in the default location, then enter thefollowing command:winstall –c \root\images\cdrom -i SWDISJPS juno

¶ To install the Tivoli Software Distribution TEC Integrationcomponent on TMR server jupiter from a CD-ROM image, placethe files in the default location, and enter the followingcommand:winstall –c \root\images\cdrom -i SWDISTEC jupiter

¶ To install the Tivoli Software Distribution Historical Databasecomponent on managed node juno from a CD-ROM image,place the files in the default location, and enter the followingcommand:winstall –c \root\images\cdrom -i SWDISDB juno

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

Installing the Tivoli Software Distribution Java EndpointPackage Editor

This section documents the procedure to install the Tivoli SoftwareDistribution, Version 4.0 software package blocks that contain theTivoli Software Distribution Java Endpoint Package Editorcomponent for the following platforms:¶ AIX¶ HP-UX Version 10.01, 10.1, 10.2

Note: To use the Tivoli Software Distribution Java EndpointPackage Editor on a machine that has HP-UX, Versions10.20 or 11.00 installed, you must first install thefollowing patches:

1. On HP-UX, Version 10.20, patch PHSS_20861 isrequired, and for applications that use AbstractWindow Toolkit (AWT), it is recommended that youinstall the PHSS_19269, PHSS_17534, andPHSS_20715 patches.


30 Version 4.0

2. On HP-UX, Version 11.00, the following patches arerequired:

v PHCO_20765

v PHKL_20202

v PHCO_19666

v PHKL_20016

v PHKL_18543

PHKL_21024, PHCO_19047, PHKL_20079, andPHKL_20674 are prerequisites of PHKL_18543.

v PHCO_20882

v PHSS_20275

v PHSS_17535

v PHSS_20716 PHNE_20094 and PHSS_20145 areprerequisites of PHSS_20716.

v PHSS_20865¶ Windows NT¶ Windows 95

Note: The software package block that you install on aWindows 95 endpoint can also be installed on a Windows98 endpoint.

¶ NetWare 4.11 or 4.2¶ OS/2¶ Solaris

To install the software packages, perform the following steps:

1. After you have installed the Tivoli Software Distribution,Version 4.0 server, Tivoli Software Distribution, Version 4.0gateways, and Tivoli endpoints, open the Tivoli desktop.

2. Create a software package profile.

3. On the machine from which you want to import the softwarepackage, insert the Tivoli Software Distribution, Version 4.0CD-ROM.



2.P

lann

ing

and

Installin

g

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 thefollowing from the drop-down list:

¶ Managed node, if the machine specified in Step 3 is amanaged node.

¶ Endpoint, if the machine specified in Step 3 is an endpoint.

If you select Endpoint, enter the name of the endpoint inthe Endpoint Name text box.

7. Click the browse (...) button. The Select Input File dialogdisplays.

8. Select the machine on which you inserted the CD-ROM. If it isa managed node, select the name from the Hosts list.

9. On the product CD-ROM, locate the platform-specific TivoliSoftware Distribution software package blocks that install theTivoli Software Distribution Java Endpoint Package Editorcomponent in the package\prepsite path. The prepsite directorycontains the following file names for the platform-specificsoftware package blocks:

SD40EP_AIX.spbThe software package for the AIX platform.

SD40EP_HP.spbThe software package for the HP-UX platform.

SD40EP_NT.spbThe software package for the Windows NT platform.

SD40EP_WIN95.spbThe software package for the Windows 95 andWindows 98 platforms.

SD40EP_NW.spbThe software package for the NetWare platform.

SD40EP_OS2.spbThe software package for the OS2 platform.


32 Version 4.0

SD40EP_SOLARIS.spbThe software package for the Solaris platform.

10. Select the software package to import.

11. In the Location of Source Host group box, leave the Buildcheck box selected. Enter the source host name and the softwarepackage block path in the Source Host Name and in the SPBPath text boxes, respectively.

12. Click Import & Close to import the software package andreturn to the Profile Manager dialog.

13. Right-click the imported software package. A pop-up menudisplays.

14. Select Install. The Install Software Package dialog displays.

15. In the Available Subscribers list, select the endpoint on whichyou want to install the package.

16. Click Install & Close to begin installing the software packageto the selected subscribers. The dialog is not dismissed until theoperation has been submitted.

After the package is installed, the speditor_dir key is created inthe swdis.ini file. The path where the package is installed is:<speditor_dir path>\<interp>

where <interp> represents the operating system type whosevalue can be any one of the following values in the InterpreterType column:

Operating System Interpreter Type

Windows NT w32-ix86

Windows 95 win95

OS/2 os2-ix86

Solaris solaris2

HP-UX hpux10

AIX aix4-r1



2.P

lann

ing

and

Installin

g

Note: You cannot install the SD40EP_OS2.spb Tivoli SoftwareDistribution software package block on the file allocationtable (FAT) partition of an OS/2 target system.

To install the SD40EP_OS2.spb on an OS/2 target system,verify that the path of the product_dir variable specified inthe swdis.ini file is located on a high-performance file system(HPFS)-partitioned disk. If it is not located on anHPFS-partitioned disk, perform the following steps:

1. From the Tivoli desktop, right-click the software packageblock to install.

2. Select Install from the pop-up menu. The Install SoftwarePackage dialog is displayed.

3. From the Advanced Options menu item, select DefaultVariables. The Default Variables dialog is displayed.

4. In the Default Variable list, selecttarget_dir=$(product_dir)\speditor.

5. Substitute $(product_dir) with a path located on anHPFS-partitioned disk. For example, if your D: disk isHPFS-partitioned, you can specify:target_dir=d:\sw\speditor

Removing Tivoli Software DistributionTivoli Management Framework provides a command line utility toremove Tivoli applications from a specified node or from the entireTMR. The wuninst command is a wrapper script that invokesproduct-specific uninstall scripts.

Using the wuninst command with an application-specific producttag, you can remove Tivoli Software Distribution products from anymachine in your environment or from the TMR. See the table“Components Available” on page 26 for a list of the Tivoli registeredproduct tags for Tivoli Software Distribution components.


34 Version 4.0

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

The following examples demonstrate removal operations that youcan use to uninstall Tivoli Software Distribution or its componentsfrom your TMR environment. See the Tivoli ManagementFramework Reference Guide for more information about commandline syntax and usage for the wuninst command.

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

To remove Tivoli Software Distribution from the entire TMR inwhich jupiter is the TMR server, enter the following command. Notethat if the node is the TMR server, Tivoli Software Distribution willbe removed from the TMR server and from all managed nodes onwhich Tivoli Software Distribution is installed.wuninst swdissrv jupiter -rmfiles

where:

swdissrvSpecifies the registered product tag for the Tivoli SoftwareDistribution Server component.

–rmfilesSpecifies that all local database objects and all the associatedfiles are removed even if they are shared files.

The default behavior without the –rmfiles option is to onlyremove the database entries for the specified node. If thenode is the TMR server, this option removes all databaseobjects.

Note: You can also uninstall Tivoli Software Distribution locally oneach machine in your TMR by using the scripts located onthe machine in the $BINDIR\TME\SWDIS\SCRIPTSdirectory. Each of the components listed in the table

Removing Tivoli Software Distribution


2.P

lann

ing

and

Installin

g

“Components Available” on page 26 has a correspondingscript that can be used to uninstall each component from amachine in your TMR.

For example, to uninstall the Tivoli Software DistributionGateway component (swdisgw) and the Tivoli SoftwareDistribution Java Endpoint Package Editor (swdisjps) from themanaged node juno, complete the following steps:

1. Configure the Tivoli system environment variables usingthe setup_env.sh file. Refer to the Tivoli EnterpriseInstallation Guide, Version 3.7 for details.

2. In the $BINDIR\TME\SWDIS\SCRIPTS directory on themanaged node, locate the scripts related to the TivoliSoftware Distribution Gateway component (swdisgw) andthe Tivoli Software Distribution Java Endpoint PackageEditor (swdisjps) component.

3. Run the scripts locally on the managed node juno,specifying the following command. Since this command isa bash script that must be run in the bash environment,precede the command with the string sh, as follows:sh scriptname -rmfiles

where:

scriptnameSpecifies the script found in the$BINDIR\TME\SWDIS\SCRIPTS directory on thejune manage node that corresponds to a TivoliSoftware Distribution component listed in the table“Components Available” on page 26.

–rmfilesSpecifies that all local database objects and all theassociated files are removed even if they are sharedfiles.

Uninstalling Endpoints on OS/2When an OS/2 endpoint is the target of a software distribution, thefollowing DEVICE statement is added to the config.sys file:


36 Version 4.0

DEVICE:C\tivoli\lcf\dat\1\cache\lib\os2-ix86\courier.sys

If you uninstall the endpoint, the DEVICE statement in theconfig.sys file must be deleted manually. Otherwise an error messagedisplays at the next reboot of the machine. For more informationabout uninstalling an OS/2 endpoint, refer to the Tivoli EnterpriseInstallation Guide.

Uninstalling the NetWare GatewayInstalling Tivoli Software Distribution, Version 4.0 creates andpopulates a list of files and directories on the NetWare gateway. Touninstall Tivoli Software Distribution from the NetWare gateway,you must delete the files manually. However, do not delete thedirectories, because they may be used by other Tivoli ManagementFramework applications.

To uninstall Tivoli Software Distribution from a NetWare gateway,perform the following steps. In this example, the installationdirectory on the NetWare gateway is SYS:\TIVOLI.

1. From the $BINDIR/TME/SWDIS/SCRIPTS directory on theTMR, run the swdisNW_uninst.sh script to remove Tivoliproducts installed in the TMR from the Tivoli object database.Since this command is a bash script that must be run in the bashenvironment, precede the command with the string sh, asfollows:sh swdisNW_unist.sh <netware_gateway_hostname>

2. Delete all spd_eng files contained in the subdirectories of theinstallation 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 thefollowing pattern: libe*.*

4. Delete the following files (displayed in bold typeface):sys:\Tivoli\bin\lcf_bundle.40\INSTALLED\SWDISGW_LCFNEWsys:\Tivoli\bin\lcf_bundle.40\lib\nw4\resinit.nlmsys:\Tivoli\bin\lcf_bundle.40\lib\os2-ix86\resinit.exe



2.P

lann

ing

and

Installin

g

sys:\Tivoli\bin\lcf_bundle.40\lib\w32-ix86\resinit.exesys:\Tivoli\bin\lcf_bundle.40\lib\w32-ix86\wdusrprf.exesys:\Tivoli\bin\lcf_bundle.40\lib\win95\resinit.exe

Enabling Language SupportTivoli Software Distribution, Version 4.0 is translated into thefollowing languages:

¶ Brazilian Portuguese

¶ Chinese (Simplified)

¶ Chinese (Traditional)

¶ French

¶ German

¶ Italian

¶ Japanese

¶ Korean

¶ Spanish

After you have installed the Tivoli Software Distribution, Version 4.0components listed in the section “Components Available” on page 26,you can enable these languages by installing the appropriatelanguage support pack located in the \images\l10n\cdrom path on theproduct CD-ROM: Installation of the language packages is optional.You can also install multiple language support packs for a singleproduct. Remember, to get full language enablement you must installthe Tivoli Management Framework language support pack as well asthe language support pack for Tivoli Software Distribution, Version4.0. If you are installing the language support pack using the InstallProduct dialog, the following dialog box shows the list of language


38 Version 4.0

support packs available:

Installing language support follows the procedure for installing anyTivoli Enterprise product with the exception of the language packagefor the Tivoli Software Distribution Java Endpoint Package Editorcomponent. Refer to the Tivoli Enterprise Installation Guide, Version3.7 for instructions on installing Tivoli Enterprise products.

To install the Tivoli Software Distribution Java Endpoint PackageEditor language pack on an endpoint, follow the same procedureoutlined in “Installing the Tivoli Software Distribution Java EndpointPackage Editor” on page 30, but use the SDGui_l10n.spb file as theinput file for the installation operation. The SDGui_l10n.spb file islocated in the \root\images\package\l10n\ path on the productCD-ROM.

Enabling Language Support


2.P

lann

ing

and

Installin

g

Enabling Language Support

40 Version 4.0

Creating a Software Package

The Software Package Editor is the Tivoli Software Distributionsoftware packaging facility. It is a Java-based graphical userinterface (GUI) used to create and customize a software package.The Software Package Editor window displays a graphical tree viewof the software package and its contents.

Launching the Software Package EditorYou can use the Software Package Editor on either endpoints ormanaged nodes. On endpoints, you install the Tivoli SoftwareDistribution Java Endpoint Package Editor component and all thefunctionality of the Software Package Editor is enabled. Thiscomponent enables you to create and customize software packages.However, if the source host component is not installed on theendpoint, the file browser accesses only the local file system and notthe source host machine. On managed nodes, you install the TivoliSoftware Distribution Software Package Editor component and someof the functionality of the Software Package Editor is disabled. Youuse this component primarily for customizing pre-existing softwarepackages.

Notes:

1. Before launching the Software Package Editor on a UNIXsystem, enable host access to the X server by entering the xhost+ command.

3


3.C

reating

aS

oftw

areP

ackage

2. The Software Package Editor can experience degradedperformance if remote drives have been mapped to the machinethat were not accessible when the Software Package Editor waslaunched.

Launching the Software Package Editor on EndpointsTo launch the Software Package Editor from an endpoint on aWindows or OS/2 system, double-click the icon labelled SoftwarePackage Editor 4.0 on your desktop. On a Windows system, youcan also launch the Software Package Editor by selecting the entryin the Start→Programs menu. The Software Package Editor mainwindow displays.

Alternatively, you can launch a command line interface (CLI) usingthe SD40ENV icon on the desktop. Click this icon to open a shellwhere you can submit Tivoli Software Distribution commands at thecommand line. Refer to the Tivoli Software Distribution ReferenceManual, Version 4.0 for more information about commands.

On the same endpoint, if you also have the Tivoli desktop installed,you can also launch the editor as described in the following section.

Launching the Software Package Editor

42 Version 4.0

Both methods access the same component with the full SoftwarePackage Editor functions for creating and customizing softwarepackages. However, if the endpoint name is different from thehostname, you cannot launch the Software Package Editor from thedesktop. You must launch the Software Package Editor from itsrelated icon on the desktop.

Launching the Software Package Editor on ManagedNodes

If you are launching the Software Package Editor from an emptysoftware package profile, the Create Software Package dialog isdisplayed first, before the Software Package Editor main window.

Enter the source host name and click Set & Close. The SoftwarePackage Editor main window is displayed. If you are launching theSoftware Package Editor from a software package profile containinga software package in the built (.spb) or not-built format (.sp), theSoftware Package Editor main window is displayed.

You can view the contents of a software package in the built format(.spb), but you cannot edit and save the changes. To edit a softwarepackage block using the Software Package Editor, perform thefollowing 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 SoftwarePackage Editor menu.



3.C

reating

aS

oftw

areP

ackage

4. Convert the software package back to a software package block.For the software package to be rebuilt, all the source files mustbe located on the source host machine.

However, this procedure would not work for software packageblocks that were created using AutoPack on an endpoint and thenimported into the object database. All of the source files necessary torebuild the software package block are located on the preparationmachine (endpoint) where AutoPack originally generated thesoftware package block. For more information about convertingsoftware packages to different formats, see “Converting a SoftwarePackage” on page 242.

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

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

A software package contains a number of actions to be executed ona target machine. These actions can be divided into the followingcategories:

¶ The add object and remove object actions drive the engine toadd the specified object to the system or to remove it from thesystem.

¶ System actions, such as checking disk space, and restarting thetarget machine.


44 Version 4.0

¶ 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 followingmethods while working in the Software Package Editor mainwindow.

¶ After launching the Software Package Editor, create a newsoftware package in the Software Package Editor main window.

¶ Select Open from the File menu to open an existing softwarepackage (.sp), software package definition (.spd) file or softwarepackage block (.spb). Edit the software package and save it withanother name so that both the original software package and theedited software package can be used for distribution. You canalso choose to save the software package in a different fileformat (.sp, .spd, .spb). See “Saving the Software Package” onpage 135 for more information about software package formats.

¶ Select the AutoPack menu to automatically generate a softwarepackage comparing two successive snapshots of a preparationmachine’s system.

¶ Select Importer→PDF from the Tools menu to import aMicrosoft Package Definition File (PDF) and map its contents toa software package.

¶ Select Program Builder from the Tools menu and choose oneof the native installation options: InstallShield or MSSetup.These tools guide you in creating actions in the softwarepackage that execute third-party native install programs.

Tivoli Software Distribution, Version 4.0, unlike previous versions,makes use of a simplified single-content packaging format called thesoftware package. All of the techniques used to create softwarepackages are based on this single file format. Therefore, a software

The Software Package Editor Window


3.C

reating

aS

oftw

areP

ackage

package created using AutoPack is identical to a package createdmanually using the Software Package Editor, and both can be editedin the same way.

Creating the Appsample Software PackageIn this section, you will create a sample software package calledAppsample on a Windows NT system. The Appsample softwarepackage consists of typical actions that take place when installing anapplication on a workstation.

Windows and OS/2 operating system actions are organized in twoseparate generic containers. Generic containers are used to groupactions together that must satisfy the same condition. You addactions to the software package in the order in which they should beexecuted.

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

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

1. Check disk space.

2. Add all files contained in a directory called Appsample.

3. Create a generic container to house various Windowsplatform-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 NTand Windows 95 target systems.

c. Add a new Windows shell folder containing a shortcut on theWindows desktop.

The Software Package Editor Window

46 Version 4.0

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 ashadow.

b. Create an OS/2 profile object which adds an item containinga new section and key by modifying an .ini file.

c. Add a line of text, two tokens, and a device to the config.sysfile.

5. Create an Execute program object whose purpose is to create alog file at the end of the install operation to store informationsuch as a timestamp or version number.

6. Add a restart action that restarts the target system after the installoperation of the software package is complete.

These items represent the changes that take place or the actions thatare executed on the target machine when the software package isdistributed.

Some actions require conditions to be set on the execution of theaction. For example, certain actions are executed on only particularoperating systems. The same software package can have certainactions that are executed on only Windows 98 systems and otheractions that are executed on only Windows NT systems. A conditiongoverns whether an action will be executed or whether it will beskipped for a specific target system. The following sample scenarioillustrates how to apply these conditions using the Software PackageEditor.

Naming the Appsample Software PackageWhen you launch the Software Package Editor, it displays an emptysoftware package icon whose default name is Noname. Begin bynaming the software package Appsample.

Creating the Appsample Software Package


3.C

reating

aS

oftw

areP

ackage

The name of the software package is a property of the softwarepackage. You can replace Noname by clicking it and typingAppsample 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 iconfrom the left toolbar. (To view the name of an icon in theSoftware Package Editor GUI, hover the mouse pointer over theicon for a few seconds.)

–OR–

Select the software package icon, then from the menu clickEdit→Properties.

The Package Properties dialog is displayed.

2. Specify the name of the software package in the Package nametext box of the General properties page. This name is displayedbeside the software package icon in the Software Package Editorwindow. For the purpose of this scenario, enter Appsample inthe Package name text box.

Naming the Software Package

48 Version 4.0

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 aredescribed in “Setting Software Package-level Properties” onpage 109.

5. Click OK to return to the Software Package Editor window.

6. Save the software package. You can use the package name as thefile name or use a different name.

7. To begin adding actions to the Appsample software package, youcan perform one of the following actions:

a. Click Edit→Insert to select one of the categories of actions.

–OR–

b. Select the appropriate category from the tabbed toolbar andselect an icon associated with the tab.

–OR–

c. Right-click the software package icon in the left pane thenselect Insert and the appropriate category from the pop-upmenu.

Checking Disk SpaceThe necessary disk space required is a parameter of the softwarepackage. You can use this action to check the disk space on theendpoint. If the space requirements are met, the distributionproceeds. If the space requirements are not met, the distribution doesnot occur, and an error event is logged and the administrator isnotified.

Complete the following steps to add the check disk space action tothe Appsample software package:

1. Select the System action tab from the tabbed toolbar, then clickthe Check disk space icon. The Check Disk Space Properties

Naming the Software Package


3.C

reating

aS

oftw

areP

ackage

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.

4. Click Add to add the action to the list. You can add more thanone check disk space action to the same list. To remove a checkdisk space action from the list, select it then click Remove.

Checking Disk Space

50 Version 4.0

5. Click Condition to display the Condition Editor dialog.

In this dialog, you can apply a restriction to the execution of thecheck disk space action by defining the circumstances underwhich the action should be executed. Conditions can be appliedas follows:

¶ On individual actions and objects contained in the softwarepackage

¶ On the entire software package (package level)

For example, to limit the execution of the check disk spaceaction to Windows NT systems only, specify the followingexpression in the Condition Editor dialog: $(os_name) ==Windows_NT. Click OK to apply the condition to the actionand to return to the Check Disk Space Properties dialog. See“Setting Software Package-level Properties” on page 109 forinformation about setting conditions at the package level. Referto “Built-in Variables” in the Tivoli Software DistributionReference Manual, Version 4.0 for a table containing descriptionsand accepted values for built-in variables.

Checking Disk Space


3.C

reating

aS

oftw

areP

ackage

6. Click OK to return to the Software Package Editor window. Thepackage contains the check disk space action displayed in theright pane.

Adding Directories and FilesUse the add directory object action to add directories, files, and linksand to set file system object attributes related to the target operatingsystem. In this scenario, you will add an action that adds all filescontained in a directory called Appsample to the software package.

Begin by adding an add directory action to the Appsample softwarepackage:

1. Select the Appsample software package icon in the left pane.

2. Select the Add object tab from the right toolbar and click theDirectory icon.

Checking Disk Space

52 Version 4.0

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 clickbrowse (...) to display a file system browser dialog.

b. In the Name text box, enter *.* to specify that all filescontained in the Appsample directory are to be added to thepackage. The files are installed with their original name intothe 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 wildcardcharacters include (*), which matches any string, and (?),which matches any single character. For moreinformation about specifying file and directory nameswith pattern-matching characters, refer to the TivoliSoftware Distribution Reference Manual, Version 4.0.

4. In the Destination group box, you find the same informationyou entered in the Source group box. The destination representswhere the specified directory is created on the target system.Delete c:\Appsample in the Location text box and use a

Adding Directories and Files


3.C

reating

aS

oftw

areP

ackage

variable to render this operation more generic for use ondifferent operating systems. Right double-click the Locationtext box to display the Variable List Editor.

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

a. In the Name text box, enter target_dir.

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 andit will change all occurrences in the software package. Refer tothe Tivoli Software Distribution Reference Manual, Version 4.0for more detailed information about using variables.

6. Click OK to return to the Add directory properties dialog.


54 Version 4.0

The source name is repeated in the destination Name text box.The files are installed with their original name into the targetdirectory at installation time.

7. Set the check boxes in the Add Directory Properties dialog:

¶ The Stop on failure check box is selected by default. Leaveit selected to discontinue the distribution of the softwarepackage if a failure occurs during the execution of the action.

¶ Select the Replace if target is newer check box to replace atarget object even if the target object is newer than thesource object. On Windows platforms, to determine whichfile is newer, Tivoli Software Distribution evaluates theversion of the file. If the version of the target file is newerthan the source file, the target file is replaced. If the versionis not set, or on platforms other than Windows, TivoliSoftware Distribution evaluates the modification time. If themodification time of the target object is more recent than thesource object, the target object is replaced. File versionsupport is available if the source host is a Windows machineor if the software package containing the file in question hasbeen built on a Windows machine and imported in thesoftware package block (built) format.

¶ The Replace if existing check box is selected by default.Leave it selected to replace an object that already exists onthe target.

¶ Select the Remove if modified check box to flag this objectfor a subsequent remove operation. During a removeoperation of the same software package, the flag indicates toremove the object even if the target object has been modifiedsince the last install operation.

¶ Select the Add check box to create the directory if it doesnot already exist on the target system.



3.C

reating

aS

oftw

areP

ackage

8. Click Advanced to specify platform-specific file systemattributes.

9. Leave the Create directories check box selected to createdirectories if they do not already exist on the target system. Ifyou know that the directory already exists, clear this check boxso that during an install the directory is not created and during anundo operation the directory is not removed.

10. Leave the Remove empty directories check box selected toremove empty directories when performing a subsequentremove operation of this software package.

11. Select the Descend directories check box to add the entiredirectory tree to the software package. If it is not selected, onlythe files listed below the top-level directory are added.

12. Select the Rename if locked check box to temporarily renamefiles that are in use by another application. For Windows NT,Windows 95, and Windows 98 systems, during an install andcommit operation the file is renamed under the same directoryas the locked file and the distribution completes successfullywithout having to wait for a reboot of the system. The


56 Version 4.0

temporary file is removed during the next system reboot.During a remove operation, the locked file is removed duringthe next system reboot.

For OS/2 systems, only .exe and .dll files are supported. Thelocked file is closed so that it can be replaced with the filebundled in the software package. During a remove operation,the locked file is closed so that it can be removed from thetarget system.

13. Click OK to confirm the file system object properties selected.

For more information about the file system attributes in thisdialog, refer to the online help documentation or the TivoliSoftware Distribution Reference Manual, Version 4.0.

14. Click OK to add this action to the software package. Select thesoftware package icon in Software Package Editor window todisplay the Add directory object action.



3.C

reating

aS

oftw

areP

ackage

Adding Windows Platform Actions to a GenericContainer

The following actions to be added to the Appsample softwarepackage are all Windows platform-related actions. You can grouprelated actions together in a generic container and set a condition onthe entire container that governs the execution of the containedactions.

Complete the following steps to add a generic container to thesoftware package that contains Windows platform-related actions.

1. Select the Appsample software package icon in the left pane ofthe Software Package Editor window.

2. Click Container on the tabbed toolbar and select the Genericcontainer icon. The Generic Container Properties dialog isdisplayed.

3. In the Name text box, enter a descriptive string such asWindows platform actions. Before you add this container to thesoftware package, you must set a condition on the entire

Adding Windows Platform Actions to a Generic Container

58 Version 4.0

container. Click Condition to display the Condition Editor.

4. Enter the following expression to satisfy all Windows actions thatwill be added to this container: $(os_name) LIKE ‘Win*’ thenclick OK. Click OK to add the generic container to the softwarepackage.



3.C

reating

aS

oftw

areP

ackage

An exclamation mark in the right pane indicates that a conditionhas been set on the generic container.

Adding Windows Operating System Directories and FilesNext, you will add an action that adds two system .dll files found onthe source machine. One of the files is a shared file. Because manyapplications use the same resources, shared files and directories mustbe identified in the software package to prevent them from beingremoved when an application is removed. If a shared resource in asoftware package is found to exist on the target, the default is tomaintain the latest version of the shared resource.

1. Select the Windows platform actions icon in the left pane, thenclick Add object→Directory from the right toolbar. The Add


60 Version 4.0

Directory Properties dialog is displayed.

2. In the Source group box, enter the parent directory c:\winnt inthe Location text box. Enter the subdirectory system32 in theName text box.

3. In the Destination group box, right double-click the Locationtext box to display the Variable List Editor dialog. Select the$(system_dir) variable to represent the directory where the filewill be installed on the target machine. Click OK.

4. Click OK to add the add directory action to the softwarepackage. The Software Package Editor displays the adddirectory action contained in the Windows platform actionsgeneric container.

Adding Windows Directories and Files


3.C

reating

aS

oftw

areP

ackage

5. Specify the file to be added to the target system by nesting anAdd file action in the add directory action. Select the Adddirectory action in the left pane, then select the File icon fromthe Add object tab on the toolbar. The Add File Properties


62 Version 4.0


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 theIs shared check box from the General page of the Add FileSystem 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, theadd file action is displayed in the right pane of the SoftwarePackage Editor main window.



3.C

reating

aS

oftw

areP

ackage

9. Add a second .dll file to the same directory. You can eitherrepeat the same process and select the Add file icon from theAdd object tab on the toolbar, or you can use the followingtimesaving 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 leftpane, then select Paste. An identical add file action is addedto the add directory action.

c. Select the second add file action and select the Propertiesicon from the left toolbar.


64 Version 4.0

The Add File Properties dialog is displayed.

You can also add more than one file or directory at the sametime by right-clicking the Add directory action and selectingInsert→Multiple file/directory. A file system browser isdisplayed. Select any number of files and directories and clickAdd. Click OK to add the add file and directory actions to thesoftware package.

10. Change the file name from App32.dll to Apprun32.dll. ClickAdvanced, then deselect the Is shared check box, as this is nota 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.



3.C

reating

aS

oftw

areP

ackage

Adding Windows Registry ObjectsIn more recent Windows versions, such as Windows 95 andWindows NT, .ini files have been replaced by the Windows registryto store configuration information regarding the user, the hardware,and the programs installed. Many applications continue to use .inifiles for backward compatibility. Windows operating systems refer tothe registry during operation.

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

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

Adding Windows Registry Objects

66 Version 4.0

1. Select the Windows platform actions generic container icon inthe left pane of the Software Package Editor window.

2. From the Add object tab on the toolbar, click the Windowsregistry key icon. The Add Windows Registry Key Propertiesdialog is displayed.

3. Select HKEY_LOCAL_MACHINE in the Hive drop-downlist.

4. Specify the Parent Key and the Key. Enter SOFTWARE\Tivoliin the Parent key text box and enter Appsample in the Key textbox.

5. Select the Override permissions check box to temporarilyoverride access permissions for adding or removing protectedregistry keys and values. Access permissions are restored afterthe operation is completed.

6. A condition must be applied to this particular action. Systemregistry changes are applicable only to Windows 95 (or later) orWindows NT 4.0 machines. Click Condition in the upper right



3.C

reating

aS

oftw

areP

ackage

corner of the dialog to display the Condition Editor 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 isvalid. Click OK to set the condition on the object.

8. Click OK to add the Windows registry object to the softwarepackage. The Software Package Editor displays the Windowsregistry key.


68 Version 4.0

9. To add a subkey to the Appsample Windows registry key, selectthe Appsample Windows registry key icon. From the tabbedtoolbar, click the Windows registry key icon from the Addobject tab. The Add Windows Registry Key Properties dialog is



3.C

reating

aS

oftw

areP

ackage

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, thenselect Value from the Add object tab. The Add WindowsRegistry Value Properties dialog is displayed.

13. Enter InstallationDirectory in the Name box.

14. From the Type drop-down list, select the appropriate type ofvalue (String, Binary, DWORD, Multistring, or Expand String).Select Expand String from the drop-down list.


70 Version 4.0

15. To enter the value in the Data text box, click Edit. The Dataeditor dialog is displayed. Use the same variable defined in“Adding Directories and Files” on page 52 by rightdouble-clicking the Value text box. Select the $(target_dir)variable from the Variable List Editor dialog and click OK tosave the data and return to the Data editor dialog. To add thisvalue to the Data text box, click OK. To modify this value,click Edit.

16. In the Position drop-down list, specify where the new valueshould be placed in the system registry. Select Replace tosubstitute the value on the target system.

17. Leave the Replace if existing check box selected to replace thevalue if it already exists in the system registry.

18. Click OK to display the Software Package Editor window andview the value added to the key.



3.C

reating

aS

oftw

areP

ackage

Adding Windows Shell ObjectsAdding Windows shell objects involves creating folders and links toprograms. You can use this action to configure a target machine’sdesktop.

Complete the following steps to create a shortcut or link to theAppsample application in a new folder, Tivoli Appsample, located onthe desktop.

1. From the Software Package Editor window, select the Windowsplatform actions generic container icon.

2. From the Add object tab on the toolbar, select the Windowsshell folder icon. The Add Windows Shell Folder Properties

Adding Windows Shell Objects

72 Version 4.0


3. Use a built-in variable to specify the location of the folder.Right double-click the Location text box to display the VariableList Editor dialog.

4. Select the $(all_users_shell_desktop) variable and click OK toplace the variable in the Location text box.

5. Enter Tivoli Appsample in the Folder text box. This will be thename of the folder on the target system.

6. In the Folder type group box, select Common if the folder andall its contained commands are common to all users. SelectPersonal, to specify that the folder and its contents apply to thelogged-on user only and to install them at the next user logonby the user profile update program.

7. Select the Add check box to create the new folder if it does notalready exist on the target system.

8. Before you add the folder to the software package, you must seta condition on this particular action. Windows shell objectsapply only to Windows 95 or Windows NT 4.0. Therefore, clickCondition in the upper right corner of the Add Windows Shell



3.C

reating

aS

oftw

areP

ackage

Folder Properties dialog to display the 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 theWindows shell folder.

10. Click OK to add the Windows shell folder to the softwarepackage.


74 Version 4.0

11. Add a link to the Windows shell folder. Select the TivoliAppsample folder icon in the left pane of the Software PackageEditor window, then click the Link icon from the Add objecttab on the toolbar. The Add Windows Shell Link Propertiesdialog is displayed.



3.C

reating

aS

oftw

areP

ackage

12. In the Display name text box, enter Appsample 1.0 as the namecontained in the new folder, Tivoli Appsample, on the desktop.

13. In the Command text box, indicate the full path to theexecutable file that launches the application. Specify part of thepath using the variable defined in “Adding Directories andFiles” on page 52. Right double-click the Command text box todisplay the Variable List Editor dialog. Select the $(target_dir)variable, then click OK to insert the variable in the Commandname text box. Complete the full path to the command asfollows: $(target_dir)\Appsample\bin\Appsample.exe

14. Click OK to add the link to the folder and return to theSoftware Package Editor window.


76 Version 4.0

Adding Windows Profile ObjectsYou can use the Windows profile objects to update Windows .inifiles. Windows .ini files store configuration and default settings, suchas the computer’s hardware, or environment preferences such asfonts and background color. You update .ini files by manipulatingsections that contain values associated to keys. In the followingexample, you create a new section containing an installationdirectory key.

Complete the following steps to add Windows profile objects to thesoftware package.

1. Select the Windows platform actions generic container icon.

2. From the Add object tab on the tabbed toolbar, click theWindows profile icon. The Add Windows Profile Propertiesdialog is displayed.

3. Enter the full path to the appsample.ini file in the File nametext box. Use a built-in variable to specify part of the pathnameby right double-clicking the File name text box. Select the$(system_root) variable and click OK to add the variable to thetext box. Complete the file name entry as follows:$(system_root)\appsample.ini.

4. Set a condition on this action to restrict its execution toWindows NT targets only. Click Condition in the upper right

Adding Windows Profile Objects


3.C

reating

aS

oftw

areP

ackage

corner of the dialog to display the Condition Editor.

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

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


78 Version 4.0

7. To add a new section to the appsample.ini file, select theWindows profile icon and click the Section icon from the Addobject tab on the toolbar. The Add Windows Profile SectionProperties dialog is displayed.



3.C

reating

aS

oftw

areP

ackage

8. In the Section name text box, enter 1.0 as the name of thesection. Click OK to add the section to the Windows profile.

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


80 Version 4.0

displayed.

10. In the Key text box, enter InstallationDirectory as the keycontained in the section.

11. Enter the $(target_dir) variable defined in “Adding Directoriesand Files” on page 52 in the Value text box, which representsthe value associated with the key.

12. Leave the Duplicate check box selected to update the value ofthe key if it should already exist on the target system.

13. Click OK to add the key to the software package.



3.C

reating

aS

oftw

areP

ackage

Adding Windows NT ServicesThe Windows NT service action can either install or remove aservice from a Windows NT target operating system. To install theTivoli Appsample Service on the target system, complete thefollowing steps:

1. Select the Windows platform actions generic container icon inthe Software Package Editor window.

2. From the Add object tab on the tabbed toolbar, click theWindows NT service icon. The Add Windows NT Service

Adding Windows NT Services

82 Version 4.0

Properties dialog is displayed.

3. Enter the name of the service to be installed on the targetsystem. In the Name text box, enter TivoliAppsample.

4. In the Path text box, enter the path to the service. Use thevariable defined in “Adding Directories and Files” on page 52 toexpress part of the pathname. Right double-click the Path textbox. The Variable List Editor dialog is displayed. Select thetarget_dir variable from the list, then click OK to enter thevariable 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 softwarepackage. The Software Package Editor window displays theaction in the right pane.

Adding Windows NT Services


3.C

reating

aS

oftw

areP

ackage

Adding OS/2 Platform Actions to a Generic ContainerYou can group OS/2 platform-related actions together in a genericcontainer and set a condition on the entire container that governs theexecution of all of the contained actions. You created a similarcontainer for Windows-related actions in “Adding Windows PlatformActions to a Generic Container” on page 58.

1. Select the Appsample software package icon in the left pane ofthe Software Package Editor.

2. Click Container on the tabbed toolbar and select the Genericcontainer icon. The Generic Container Properties dialog isdisplayed.

3. Enter OS/2 platform actions in the Name text box.

Adding OS/2 Actions to a Generic Container

84 Version 4.0

4. Click Condition and set the following condition on the genericcontainer using the Condition Editor: $(os_name) == ‘OS/2’.Click OK.

5. Click OK to add the OS/2 platform actions generic container tothe software package. The Software Package Editor windowdisplays the empty container.

Adding OS/2 Desktop ObjectsOS/2 desktop folders function much like containers that are used toorganize objects, programs, documents, and other folders. Thefolders 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:

Adding OS/2 Actions to a Generic Container


3.C

reating

aS

oftw

areP

ackage

1. Select the OS/2 platform actions icon. Select the OS/2desktop folder icon from the Add object tab on the tabbedtoolbar. The Add OS/2 Desktop Folder Properties dialog isdisplayed.

2. Right double-click the Location text box to express the locationof 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.

4. Enter <TIVOLI_APPSAMPLE> in the OID text box.

5. Click OK to add the OS/2 folder action to the softwarepackage.

Adding OS/2 Desktop Objects

86 Version 4.0

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



3.C

reating

aS

oftw

areP

ackage


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

8. Enter Appsample as the title of the program.

9. In the Working directory text box, enter the working directoryof the program. Enter $(target_dir)\bin.

10. Click OK to add the program action to the OS/2 folder action.


88 Version 4.0

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



3.C

reating

aS

oftw

areP

ackage


12. This particular shadowed object does not have an associatedobject identification (OID); therefore, select the Title radiobutton 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 52.

b. In the Title text box, enter README.TXT for the title ofthe shadowed object.

13. Click OK to add the shadowed object to the OS/2 folder. TheSoftware Package Editor displays the shadowed object action.


90 Version 4.0

Adding OS/2 Profile ObjectsYou can use OS/2 profile objects to update .ini files that containconfiguration information. In the following example, you add a newitem containing installation information to the Appsample.ini file.

Complete the following steps to add OS/2 profile objects to thesoftware package.

1. Select the OS/2 platform actions generic container icon.

Adding OS/2 Profile Objects


3.C

reating

aS

oftw

areP

ackage

2. From the Add object tab, click the OS/2 profile icon. The AddOS/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 pathnameby right double-clicking the text box. Select the variable andclick OK. Complete the entry to read$(system_root)\appsample.ini. Click OK to add the OS/2profile to the software package. The Software Package Editordisplays the OS/2 profile action.


92 Version 4.0

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



3.C

reating

aS

oftw

areP

ackage

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 textbox.

7. In the Value text box, use the variable $(target_dir), defined in“Adding Directories and Files” on page 52.

8. Select Replace from the Position drop-down list to replace theitem in the appsample.ini file.

9. Use the String default value selected in the Type group box.The key value, InstallationDirectory, is a string-type value.

10. Click OK to add the item to the OS/2 profile. The SoftwarePackage Editor displays the OS/2 profile item.


94 Version 4.0

Adding Text File ObjectsAdding text file objects to a target system enables you to manipulateany type of text file, including DOS configuration files such asautoexec.bat and config.sys, by adding lines, command lines, ortokens to the file. The following example illustrates how to modifythe config.sys file on an OS/2 target machine by adding a text lineto the file, adding a token to the SET PATH and LIBPATH keys, andadding a command line to the file.

Complete the following steps to add text file objects to the softwarepackage:

1. Select the OS/2 platform actions icon in the left pane, thenfrom the Add object tab, click the Text file icon on the toolbar.

Adding Text File Objects


3.C

reating

aS

oftw

areP

ackage

The Add Text File Properties dialog is displayed.

2. Express part of the file name using a built-in variable. Rightdouble-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 thefile 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 fileobject contained in the software package.


96 Version 4.0

4. To add a text line to the config.sys file, select the text file iconin the left pane, then select the Line icon from the Add Objecttab on the toolbar. The Add Text File Line Properties dialog isdisplayed.



3.C

reating

aS

oftw

areP

ackage

5. In the Text text box enter the following line of text to be addedto the config.sys file: REM - BEGIN TIVOLI APPSAMPLESECTION.

6. Indicate that the line should be placed at the end of the text fileby selecting End from the Position drop-down list.

7. Click OK to add the text line action to the text file object. TheSoftware Package Editor displays the text file line action.

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


98 Version 4.0

displayed.

9. In the Text text box, specify the token value to be added to theSET PATH key. Use the variable $(target_dir), defined in“Adding Directories and Files” on page 52, then complete theentry in the Text text box to read $(target_dir)\bin.

10. In the Key text box, enter SET PATH. This value instructs theoperating system to include $(target_dir)\bin in its search. Asemicolon is automatically inserted before this value.

11. Use the End default value in the Position box to specify thatthe token will be inserted at the end of the corresponding lineof the config.sys file.

12. Click OK to add the token action to the software package. TheSoftware Package Editor displays the add token action.



3.C

reating

aS

oftw

areP

ackage

13. Add a second token that adds a directory to the LIBPATH key.The OS/2 target operating system will include the directory inits search when loading dynamic link libraries. Select the textfile object in the left pane, then select the Token icon from theAdd object tab on the toolbar. The Add Text File Propertiesdialog is displayed.

14. In the Text text box, enter $(target_dir)\dll. In the Key textbox, enter LIBPATH. Use the End default value in the Positionbox and click OK to add the second token to the text file. TheSoftware Package Editor displays the two tokens in the rightpane.


100 Version 4.0

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



3.C

reating

aS

oftw

areP

ackage

Line Properties dialog is displayed.

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

17. In the Key text box, enter the file name of the driver file. EnterAppsamp.sys in the text box.

18. In the Command text box, enter DEVICE.

19. In the Position box, use the End default value to add thiscommand to the end of the config.sys file.

20. Click OK to add the command line action to the text lineaction. The Software Package Editor displays the command lineaction.


102 Version 4.0

Adding an Execute Program ActionYou can specify user-defined executable programs to be executedduring particular change management operations. Tivoli SoftwareDistribution 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 moreinformation about change management operations, see “ChangeManagement Operations” on page 244.

To add an execute program action, complete the following steps.

1. Select the Appsample software package icon in the left pane andclick the Program tab.

Adding an Execute Program Action


3.C

reating

aS

oftw

areP

ackage

2. Select the Execute program icon to display the ExecuteProgram Properties dialog.

3. In this dialog, configure the software package to execute the userprogram log_aft.exe after the install operation is complete. In theName text box, enter a program name. If you do not specify aname, the default value is the file name entered in the Path textbox.

4. With the Install tab selected, enter the pathname to theexecutable file in the Path text box. Use the $(temp_dir) built-invariable to express a portion of the path name. Rightdouble-click the Path text box and select the $(temp_dir)variable from the Variable List Editor dialog. Click OK to addthe variable to the Path text box. Complete the pathname asfollows: $(temp_dir)\log_aft.exe.


104 Version 4.0

5. Select Bootable to manage programs that can execute a reboot.Specify the maximum number of times the program must bere-executed after it reboots in the Retry text box.

6. In the Corequisite Files box, click Add to specify one or morefiles or directories that must be downloaded together with theprogram during execution. After execution, these files aredeleted.

7. Click OK to add the execute program action to the softwarepackage. The Software Package Editor displays the programaction.

See “Embedding MSI Installation Packages in a Software Package”on page 139 for information about using the Execute program action

to embed a Microsoft Software Installer (MSI) installation packagein a software package.



3.C

reating

aS

oftw

areP

ackage

Adding the Restart ActionTo complete the Appsample software package, add a restart action asthe final action in the package. Software package actions areexecuted sequentially, in the order displayed in the Software PackageEditor window. In this example, add a restart action that will restartthe target computer after the install operation of the softwarepackage is complete. For more information about changemanagement operations, see “Change Management Operations” onpage 244.

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 theRestart icon. The Restart Properties dialog is displayed.

2. The restart action is executed in relation to three changemanagement operations: install, remove and undo. In the RestartProperties dialog, you can select an option in one of theoperation group boxes or select options from all three groupboxes. For example, in the Restart during install box, you selectNone so that the target system is not restarted during an installoperation. You select After to perform the restart after theexecution of the last action contained in the software package.You select Immediately to perform the restart actionimmediately. The remaining sequential actions contained in the

Adding the Restart Action

106 Version 4.0

software package are executed after the restart action iscomplete. Keep the default selection and click OK to return tothe 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 PackageThe complete Appsample software package includes the followingactions and objects:

1. Check disk space

2. File system objects

3. Windows generic container

¶ 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



3.C

reating

aS

oftw

areP

ackage

Before distributing the software package, you can use thedisconnected command line interface to test the package by buildingit and installing it locally. Refer to the Tivoli Software DistributionReference Manual, Version 4.0 for more information about thedisconnected command line interface commands.

Changing the Order of Objects in the SoftwarePackage

You can control the order in which the actions contained in asoftware package are executed during the distribution to the targetsystem. To rearrange the order of the actions to be executed, selectthe action in the right pane and use the up and down arrows to theright of the right pane.

It may be necessary to use the up and down arrows when adding anew action to an existing software package. The new action isautomatically added to the bottom of the sequential list of actions inthe Software Package Editor and, therefore, will be the last action to


108 Version 4.0

be executed on the target system. Use the arrows to move the actionto the appropriate point of execution.

Setting Software Package-level PropertiesTo set package-level properties, use the Software Package Editor orthe command line. From the Software Package Editor window, selectthe software package icon in the left pane and select Propertiesfrom the Edit menu or toolbar, or right-click to display a pop-upmenu. For instructions on setting software package properties fromthe command line, refer to the Tivoli Software Distribution ReferenceManual, Version 4.0. Software package properties define thefollowing information about the software package to be distributed:

¶ General options, including the name, version, creation time, andmodification time of the software package.

¶ The source host from which the source files and directories aredistributed.

¶ Programs to be run before or after the build operation fordifferent target platforms.

¶ Server execution modes, default operations, and operationmodes.

¶ Log information and notification behavior about the softwarepackage distribution and platform-specific options to handle userand group ownership of files on the UNIX platform.

¶ Built-in and user defined variables.

To display the Package Properties dialog, right-click the softwarepackage icon in the left pane of the Software Package Editorwindow, then select Properties from the pop-up menu. A dialogcontaining the following tabs is displayed:

¶ General

¶ Server options

¶ Log file

¶ Description

Changing the Order of Objects in the Package


3.C

reating

aS

oftw

areP

ackage

¶ Copyright

¶ Variable list

¶ Nested packages

Notice the Condition button in the upper right-hand corner of thedialog. The Condition button in the Package Properties dialogenables you to set a condition at the package level. Package-levelconditions are considered before lower-level conditions. If apackage-level condition is not met, the package is not installed andan error message is sent. If the package-level condition is met, but alower-level condition is not met, the package will install successfullyexcept for those objects whose conditions were not met. Refer to theTivoli Software Distribution Reference Manual, Version 4.0 for moredetailed information about using conditions. Click OK to return tothe Software Package Editor window.

General PropertiesOn the General page, specify unique information that defines andidentifies the software package.

Setting Software Package-Level Properties

110 Version 4.0

1. Enter a unique name in the Package name text box.

2. In the Package version text box, enter one to three numericalstrings separated by a period (.). There is no limit to the numberof digits you can specify in each string.

3. Enter a title for the package in the Title text box. The title is alonger name associated with the package and is used mainly fordisplay purposes. Tivoli Software Distribution Web Interfacedisplays this text in the Description column of the Web Interface.See “Tivoli Software Distribution Web Interface” on page 275 toview how the Tivoli Software Distribution Web Interface uses theinformation entered in this text box.

4. Select the History reset check box to erase the software historyif the package is installed successfully.

5. Leave the Stop on failure check box selected to stop thedistribution to a target if the execution of an action fails. (Thedistribution continues for other targets.) If you do not select thisbox, errors are logged as specified in the Log file page of thePackage Properties dialog, and the distribution continues, ifpossible.

Creation time and Modification time assist in identifying thesoftware package.

Server OptionsOn the Server options page, set the source host and program options.See “Software Package Properties” on page 239 for more informationabout server-related properties.



3.C

reating

aS

oftw

areP

ackage

Setting Server OptionsTo set the server options, select the Server options tab from thePackage Properties dialog. The following dialog is displayed:

1. In the Name text box, specify the source host machine on whichthe source files referenced in the software package reside.

2. In the SPB path text box, specify the complete path where thesource files referenced in the software package reside on thesource host. This is also where the build operation takes place.

3. In the Stage area text box, specify the complete path to the stagearea, which is the working directory of the distribution server.This directory is created during the distribution and erased afterthe distribution is complete.


112 Version 4.0

4. In the Before build group box, specify any programs to be runon the source host machine before the building of the packagetakes place. The program is executed on the source host prior tothe install operation on the target machine. In the After buildgroup box, specify any programs to run on the source host afterthe build has taken place. For example, if some files required toperform the build are located on a remote drive, use a beforebuild program to mount the remote drive before the build takesplace.

a. Enter the path and file name in the Program name text box.

b. Enter files that the program requires input from, duringexecution, in the Input file name text box.

c. Set the user identification under which to run the before andafter programs in the UID text box.

d. In the Environment text box, specify the environmentvariables for the programs specified in the Before build orAfter build group boxes.

e. Select the Skip distribution check box to skip distributing thesoftware package to a subscriber if the Before build programfails and returns a non-zero exit code.

Setting Advanced Server OptionsClick the Advanced button on the Server options page to display theServer options - Advanced dialog.



3.C

reating

aS

oftw

areP

ackage

In this dialog, set default values for software package propertiesrelated to change management operations and operation modes.These values are used when you perform a drag-and-dropdistribution operation from the Tivoli desktop, or when you select asoftware package profile, then select Distribute. For moreinformation regarding change management operations and operationmodes, see “Change Management Operations” on page 244.

1. Default operation mode

Select the default operation mode of the software package:

Committable

¶ Select Yes to install the software package intransactional mode.

¶ If you select No, the software package cannot beinstalled in transactional mode.

¶ Select Optional to allow the end-user to decidewhether the software package is installed intransactional mode.


114 Version 4.0

Undoable

¶ If you select Yes, the software package must beinstalled in undoable mode.

¶ If you select No, the software package cannot beinstalled in undoable mode.

¶ Select Optional to allow the end-user to decidewhether the software package is installed in undoablemode.

TransactionalTransactional mode installs the file in a staging areaduring the preparation phase and then moves the filefrom the staging area to the production area during thecommit phase.

¶ Select No if you do not want the system to returnitself to a consistent state after an operation, even ifthe operation fails.

¶ Select Yes to request the system to either remain in aconsistent state after an operation or, if at least oneaction does not succeed, to abort the operation andreturn to its initial state.

¶ Select Only if necessary to request the system toexecute an operation only if it detects that it cannotproceed because of temporary errors that coulddisappear during the commit phase.

¶ Select Auto commit to request the system toautomatically commit a pending operation.

UndoableWhen you are not sure of the results of an operation,select undoable mode, which allows you to return thesystem to its previous state with a successive undooperation.

¶ Select No to disable the ability to undo an operation.

¶ Select Yes to allow the ability to return the system toits previous state using a backup package.



3.C

reating

aS

oftw

areP

ackage

¶ Select If possible to request the system to continuean operation even if the process to acquire backupcopies fails.

¶ If you select Transactional, the operation isperformed in two phases: the preparation phase andthe commit phase, as in transactional mode.However, during the preparation phase, disk space isreserved for backup copies in the staging area, whichminimizes the risk of failure due to insufficient diskspace during the commit phase. During the commitphase, the staging area is freed up and all the updatesdone in the preparation phase take effect.

¶ Select Auto accept to have the system automaticallyaccept an undoable operation.

RebootThe reboot options are enabled when the Commit changemanagement operation is selected in the Defaultoperation group box. Reboot options are not valid onUNIX systems.

¶ Select No to execute the commit operation without amachine reboot. This option increases the possibilityof errors due to possible locked resources.

¶ Select Yes to execute the commit phase the next timethe machine is rebooted by the user.

¶ Select Only if necessary to execute the commitphase with a machine reboot only if necessary. Forexample, if locked files are found, an auto rebootwill be performed.

¶ Select Auto reboot to execute the commit phasewith a reboot when only the operating system isrunning and all other applications are closed. Thisoption prepares the system to complete the operationwhen the Tivoli Software Distribution agentautomatically runs the reboot operation.

2. Extended Attributes


116 Version 4.0

Select one or any combination of the following options:

No check on source hostDeselect this check box to perform a check on whetherthe managed node and the file contents exist when theobject is imported as a software package.

Move SPO removing hostLeave this check box selected to move the softwarepackage to the lost-n-found collection if the log host orsource host of the software package has removed. Referto the Tivoli Software Distribution Reference Manual,Version 4.0 for more information about the lost-n-foundcollection.

No check on removeWhen this check box is selected, during the removal of asoftware package, all objects included in the softwarepackage are located and removed, regardless of the statusof the software package.

3. Default server mode

Set the default server mode. These options control which files inthe software package are distributed. Select one of the followingmutually exclusive options.

All Installs all files and directories in the software package.

SourceInstalls only those objects that have a modification timeon the source that is later than the time of the last install.

RepairInstalls only the following:

¶ The source objects that since the time of the lastsuccessful installation have been corrupted, modified,or are not present on the target, to make the targetobjects consistent with the source objects

¶ The objects and actions on the target that have beenchanged or corrupted since the time of the lastsuccessful installation



3.C

reating

aS

oftw

areP

ackage

The software package is re-built and installed on thetarget. The repair option applies only to softwarepackages in the following operational states:

¶ Target machines on which the software package hasalready been installed and committed (IC)

¶ Target machines on which the software package hasbeen installed and committed, but the softwarepackage is in error (IC---E)

Refer to the Tivoli Software Distribution ReferenceManual for more information about software packageoperational states.

Select one of the following mutually exclusive options:

No checksNo checks are performed.

ChecksVerifies that the installation can be executed before theinstallation is attempted (requires Tivoli Inventory to beinstalled).

Force Forces the operation regardless of the changemanagement state of the software package on the target.For example, even if the software package may alreadybe installed, the execution of the operation is forced.

IgnorePerforms the installation only on targets that have beensuccessfully checked (requires Tivoli Inventory to beinstalled).

PreviewReturns to the log file on the server a list of actions thatwould be executed if you were to perform an installoperation. 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.


118 Version 4.0

RemoveUninstalls a software package.

Undo Returns the system to its previous state, prior to the lastinstall or remove operation.

AcceptDeletes the backup package, so the previous operationcan no longer be undone.

CommitCauses all the updates performed in the preparation phaseto take effect.

Verify Verifies the consistency of the software package and theobject on the target system. If the verify operation fails,the software package is placed in an error state.

Lenient distributionSelect this check box to allow distributions and removalsto subscribers even if they are not specified in the profilemanager of the software package.

Change management operations and operation modes areexplained in more detail in the Tivoli Software DistributionReference Manual, Version 4.0.

5. Web view mode

By means of a Web browser, software package blocks can bemade available for installation. Select one of the followingoptions:

HiddenThe software package is not accessible from the Webuser interface.

SubscriberThe software package is accessible only to subscribersassigned to the software package profile in the currentprofile manager.

Public The software package is accessible to all, withoutlimitations.



3.C

reating

aS

oftw

areP

ackage

For more information about these software package properties,see “Tivoli Software Distribution Web Interface” on page 275.

Log File PropertiesUse the following options to configure information logging on themanaged node selected as the log server. Tivoli SoftwareDistribution can issue a report of the success or failure of thesoftware package operation using e-mail, the notice group, or a logfile. However, specific information about errors encountered duringan operation is available only in the log file.

It is recommended that you always specify a log file. TivoliSoftware Distribution creates the log file on the TMR server. Youcan create it on a managed node or target by setting the informationin this dialog. It is created by default with the namepackage-name^package-version.log in the path$BINDIR\swdis\work.


120 Version 4.0

1. In the Path text box, specify the desired directory for the log fileon 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, TivoliSoftware Distribution overwrites the log file for each distributionof the software package.

2. Select the Notice to software distribution group check box in theLog information options group box to have Tivoli SoftwareDistribution post a notice to the group when a software packageoperation is performed. The notice includes an indication ofsuccess or failure of the operation for each target. You mustsubscribe to the Tivoli Software Distribution notice group toview the notices.

3. Type an e-mail address in the e-mail to text box to have TivoliSoftware Distribution send e-mail, including an indication ofsuccess or failure of the operation for each target, to thespecified address when a software package operation isperformed. You can specify multiple e-mail addresses byseparating each domain name with a comma.

The e-mail path and the alias must be valid on the TMR serverof the TMR in which the software package was created. Refer tothe Tivoli Management Framework Planning for DeploymentGuide for more information about configuring e-mail in yourTMR environment.

4. In the Log to host text box, type the name of the managed nodeon which you want the log file to be located. The log host mustbe a managed node. If you do not specify a host, the TMR serveris the default. Indicate the complete path to the log file in thePath text box, or click browse (...) to browse the local filesystem.

5. Set the UNIX file mode of the generated log file in the Modetext box.

6. Set the UNIX user identification number in the UID text box.



3.C

reating

aS

oftw

areP

ackage

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

You can specify log file permissions for UNIX target machinesin the Package Properties - UNIX Attributes dialog.

a. To set the ownership for a particular group, enter the numericgroup identification in the Group UID text box. The groupidentification is a number that corresponds to a specific groupname. The default permissions for groups are Read andExecute.

b. To set the ownership for a particular user, enter the numericuser identification (UID) in the User UID text box. The useridentification is a number that uniquely identifies a user tothe system. The defaults for users are selected in the Ownergroup box: Read, Write, and Execute.

c. Specify log file permissions for other types of users in theOthers group box. The default does not support any type offile permission.

DescriptionSelect the Description tab from the Package Properties dialog. Youcan enter a more detailed description of the software package on thispage. If the software package is going to be made available from theTivoli Software Distribution Web Interface, the text should beentered in HTML format; otherwise, plain text is acceptable. TheWeb Interface uses the information displayed in this dialog to give amore detailed description of the software package block being


122 Version 4.0

installed. Click browse (...) to browse the file system and import anexisting file into this dialog. See “Tivoli Software Distribution WebInterface” on page 275 for more information about how the WebInterface uses this information.

CopyrightSelect the Copyright tab and enter copyright information in the textbox. This information, like the description, is used to help you



3.C

reating

aS

oftw

areP

ackage

identify software packages.

Variable listThe Variable list page contains all the built-in variables supported byTivoli Software Distribution. From this page you can also createvariables.


124 Version 4.0

To create a variable on the Variable list page, enter a variable namein the Name text box, assign it a value in the Value text box, thenselect Add.

Check the Save default variables check box to make the defaultvariables persistent for future use. The default variables are saved asuser variables and are added to the swdis.var file on the targetsystem during the software package installation, so that the samevariables can be used for installing upgrades or additional softwarepackage features. Refer to the Tivoli Software Distribution ReferenceManual, Version 4.0 for more detailed information about usingvariables.



3.C

reating

aS

oftw

areP

ackage

Nested packagesSelect the Nested packages tab to specify existing softwarepackages within the current software package. The current softwarepackage is called the primary software package and the packagesspecified within it are called nested software packages.

To nest software packages in the primary software package, performthe following steps:

1. Double-click the text box in the Package name column and typethe name of the first nested software package. Nested softwarepackages and the primary package must have the same sourcehost but can reside in different policy regions.

2. Double-click the text box in the Package version column andtype the version of the nested software package. The version canbe one to three numerical strings separated by a period (.). Thereis no limit to the number of digits you can specify in each string.

3. Specify additional nested software packages by clicking Add. Atdistribution time, the nested software packages are executed in


126 Version 4.0

the order in which they are listed in this dialog. You can alsospecify the primary package itself in this list.

The order of execution is determined by the position of the softwarepackages specified in the list. For example, if the primary package isspecified in the third position in the list, the first two nestedpackages are installed before the primary package. If the primarypackage is not present in the list, it is installed before all nestedsoftware packages. You can also nest software packages using theTivoli desktop. Drag-and-drop a software package icon from theProfile Manager dialog onto another to nest a software package. See“Distributing Nested Software Packages” on page 268 for moreinformation about the distribution behavior of primary softwarepackages containing nested software packages.

Editing Software Package PropertiesYou can modify a software package by selecting Properties from theEdit menu or toolbar, or by using the right mouse button to display apop-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 thesoftware package icon in the left pane of the Software PackageEditor window, then select Properties to display the dialogs outlinedin “Setting Software Package-level Properties” on page 109.

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

The following procedure describes how to modify the link propertiescontained in the Add Windows shell folder action contained in theAppsample software package.

1. Select the Tivoli Appsample Windows shell folder icon in theleft pane of the Software Package Editor window, then right-click



3.C

reating

aS

oftw

areP

ackage

Link under the Object type column in the right pane. A pop-upmenu is displayed.

2. Select Properties to reopen the Add Windows Shell LinkProperties dialog displayed at step 11 on page 75.

3. Make any necessary changes, then select OK to confirm thechanges.

Other Software Package ActionsThe Appsample software package demonstrates the most commonactions executed during an installation procedure. Several otheractions supported by the Software Package Editor that are notdemonstrated in the Appsample scenario are outlined in thefollowing pages. Refer to the online help documentation for a moredetailed explanation of these dialogs.

Editing Software Package Properties

128 Version 4.0

The Execute CID Program ActionThe IBM configuration, installation, and distribution (CID)architecture provides for the remote, unattended installation andconfiguration of OS/2 applications that use the OS/2 SoftwareInstaller. The OS/2 Software Installer response file (.rsp file) is usedas the input.

Select the Program tab and click the Execute CID Program iconfrom the toolbar. The Execute CID Program Properties dialog isdisplayed.

The InstallShield Program ActionThe InstallShield program action enables you to create a programobject that runs installations of applications that use the InstallShieldinstallation program. You can use this program action to install anapplication whose installable files are located on a network drive.

Other Software Package Actions


3.C

reating

aS

oftw

areP

ackage

Tivoli Software Distribution uses the application’s native installation(InstallShield) to perform a redirected installation. For example, toinstall the Tivoli desktop application whose installable files arelocated 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 andselect Properties from the pop-up menu.

b. On the General page, enter the software package name andversion and a descriptive title.

c. Click Condition on the Software Package Properties dialogin the upper right corner of the dialog. Enter the followingexpression in the dialog: os_name LIKE ’Win*’, then clickOK.

d. Select the Variable list tab. Enter net_dir in the Name textbox and the path to the installation images\\aquarius\images\desktop in the Value text box, then clickSet.

e. Click OK to save the software package property settings andclose the dialog.

2. Select the Program tab, then click the InstallShield programicon from the toolbar. The InstallShield Program Propertiesdialog is displayed.


130 Version 4.0

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

b. In the Path text box, use the net_dir variable to define part ofthe path to the setup executable. Right double-click the Pathtext box to display the Variable List Editor dialog. Select thenet_dir variable, then click OK to enter the variable in thetext box. Complete the entry in the Path text box to read asfollows: $(net_dir)\setup.exe.



3.C

reating

aS

oftw

areP

ackage

3. Click Advanced to set the response and log files. TheInstallShield Program Properties – Advanced dialog is displayed.

a. In the Response file text box, enter the InstallShield responsefile $(net_dir)\setup.iss.

b. In the Log file text box, enter the pathname of theInstallShield log file. Use the $(system_drive) variable toexpress part of the path by entering the following:$(system_drive)\tmp\install.log.

c. Leave the Silent check box selected to perform an unattendedinstallation.

d. Click OK to save the values and return to the InstallShieldProgram Properties dialog.

4. Click OK to add the InstallShield program action to the softwarepackage.

5. Save the software package in the .spd format. You can proceedwith the distribution and installation of the software package byimporting it into a software package profile from the Tivolidesktop on the TMR server. See “The Distribution Process” onpage 223 for more information about creating profiles andimporting and distributing software packages.

The Software Package Editor also provides the InstallShield tool toguide you through the creation of an InstallShield program object. Tolaunch the InstallShield tool, select Tools→ProgramBuilder→InstallShield from the menu bar. Refer to the online helpabout this tool for more information.


132 Version 4.0

The Microsoft Setup Program ActionThe Microsoft Setup program action enables you to create a programobject that runs installations of Windows applications that use theMicrosoft Setup installer.

Select the Program tab, then click the MS Setup program iconfrom the toolbar. The Microsoft Setup Program Properties dialog isdisplayed.

The Software Package Editor also provides an MSSetup tool toguide you through the creation of an MSSetup program object. Tolaunch the MSSetup tool, select Tools→Program Builder→MSSetupfrom the menu bar.

Remove ActionsA typical installation process, in addition to adding objects such asfiles, directories, registry entries, and shell folders, must also removesome objects. Every object-related action described in this chapterthat adds an object to a target machine also has a corresponding



3.C

reating

aS

oftw

areP

ackage

remove object-related action. For example, to uninstall an applicationthat is not equipped with an uninstall utility, you can add a series ofremove actions to the software package to remove the folders, files,directories and registry entries related to the installation of theapplication.

Click the Remove object tab from the toolbar to display the possibleremove actions. For example, to remove a value assigned to aWindows registry key, complete the following steps:

1. Select the Windows registry key icon to display the RemoveWindows Registry Key Properties dialog.

2. Enter the Hive, Parent Key, Key, and Class.

3. Select the Remove check box if you want Tivoli SoftwareDistribution to remove the Windows registry key containing thevalue.

4. Click OK to add the Remove Windows registry key action to thesoftware package.

5. Right-click the Remove Windows registry key action and selectInsert→Value. The Remove Windows Registry Value Properties

Remove Actions

134 Version 4.0


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

Saving the Software PackageThe Appsample software package created in the Software PackageEditor displays only a description of the objects contained in thepackage. That is, it contains a sequential list of actions to beexecuted on the target machine and not the objects or resourcesthemselves such as files and programs to be executed. Actionsrequire resources to be executed. When the actions are consolidatedwith the actual resources (files, directories, registry keys, and so on),the software package is considered to be in a built format (.spb).

A software package that consists solely of a description of theactions and objects contained in the package and not the objects orresources 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:

Remove Actions


3.C

reating

aS

oftw

areP

ackage

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 Filename text box. The file name can be different from the packagename.

3. In the Files of type list, select Software Package Block (.spb),then click Save. Saving the software package in this formatperforms a local build of the software package. All source filesmust reside on the local machine for the build to be performedsuccessfully. Depending on the size of the package, this operationmay take several minutes.

Upon completion of the build operation, Software Distributionasks if you would like to reload the package in the SoftwarePackage Editor main window. The procedure to reload thesoftware package can take several minutes if the softwarepackage contains an add directory action with the Descenddirectories option selected. When the software package isreloaded, the structure may be different because SoftwareDistribution must add the entire directory tree to the softwarepackage by creating the related actions (add directory, add file).For more information about the Descend directories option, seestep 11 on page 56.

Note the other two formats available. You can also save theAppsample software package as a software package file byselecting Software Package (.sp) from the Files of type list.

Saving the Software Package

136 Version 4.0

4. To transform the software package file or software package blockinto a software package definition file, open the file in theSoftware Package Editor, then save it in software packagedefinition format by selecting this option from the Files of typedrop-down list. This procedure transforms the software packageinto text file format. The text file consists of a sequence ofstanzas, each of which describes the actions contained in thesoftware package.

You can use the .spd file as the basis to create a new softwarepackage or to edit an existing one. Refer to the Tivoli SoftwareDistribution Reference Manual, Version 4.0 for more informationabout editing the .spd file.

The .spd file is the text version of the information that theSoftware Package Editor tree view displays. Using a text editor,you can view the .spd file, modify it, and then reopen it in theSoftware Package Editor and save it in another format. To viewthe Appsample software package in the software packagedefinition file format (Appsample.spd), refer to the .spd fileexamples in the Tivoli Software Distribution Reference Manual,Version 4.0. To import a software package definition file into theTivoli Management Framework environment, see “Importing aSoftware Package into the Tivoli Environment” on page 233.



3.C

reating

aS

oftw

areP

ackage


138 Version 4.0

Embedding MSI InstallationPackages in a Software Package

This section explains how to use Tivoli Software Distribution tocreate a software package that embeds a Microsoft Software Installer(MSI) package. In the Windows environment, an MSI package ismanaged using the Microsoft Windows Installer. The MicrosoftWindows Installer is an installation and configuration servicecontained in the Microsoft Windows 2000 operating system. It isalso provided in a service pack to the Microsoft Windows 95,Windows 98, and Windows NT 4.0 operating systems. An MSIpackage contains all the information that the Microsoft WindowsInstaller 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 ofthe MSI package

For detailed information about the Microsoft Windows Installer, referto the Microsoft Platform SDK documentation.

Benefits of Embedded MSI Installation PackagesUsing Tivoli Software Distribution, you can create and then deploy asoftware package that contains an MSI package. This type ofpackage provides many benefits. For example, you can do thefollowing:

4


4.E

mb

edd

ing

MS

IP

ackages

¶ Execute a native MSI installation on a target system. With theMSI technology, you can perform the following actions:

v Automatically repair corrupted components of a previouslyinstalled product

v Advertise product features and run On Demand installations

¶ Deploy the software package to a large number of target systemswithout user interaction, thereby avoiding the complexity of apreliminary deployment to network file servers.

¶ Optimize the use of the network using the MDist 2 feature.MDist 2 performs the automatic depoting of the softwarepackage data to the MDist 2 repeaters.

¶ Store information at a central repository regarding the status ofthe deployed package for each system on the network.

Creating a Software Package That Embeds an MSIInstallation Package

The following section uses an example to demostrate how to create asoftware package that embeds an MSI package. The softwarepackage enables you to install or remove the MSI package withoutuser interaction. You manage the MSI package by adding an executeprogram action in a software package with the Software PackageEditor. The Execute program action can be configured to execute theMsiExec installation program on Windows-based machines on whichMicrosoft Installer support is available. MsiExec is the executableprogram that interprets MSI packages and installs products.

To create the software package, you must store the MSI package onthe machine on which the Software Package Editor is running. In thefollowing example, the catsdb.msi MSI installation package is used.To add the Execute program action to the software package, performthe following steps:

Embedding MSI Installation Packages

140 Version 4.0

1. In the Software Package Editor window, select the Program tab.



4.E

mb

edd

ing

MS

IP

ackages

2. Click the Execute program action. The Execute ProgramProperties dialog displays.

3. In the Name text box, enter the name of the Execute programobject.

Next, you must define the Execute program properties for the installor remove operation.

Defining the Execute Program Properties for theInstall Operation

To install the MSI package using a software package, all the productfiles that are required by the MsiExec program must be available atthe target system during the installation. For this reason, the filesthat are part of the product package, including the .msi installationdatabase, are distributed to a temporary directory on the systembefore the execution of the MsiExec program.


142 Version 4.0

Tivoli Software Distribution provides the $(temp_dir) built-invariable to specify a directory path where the temporary files arestored on the target system. In the following example, the productfiles are located in the d:\catsdb directory of the target system thatyou use to prepare the package.

To define the Execute program properties for the installation of theMSI package, enter the following information in the ExecuteProgram Properties dialog.

1. With the Install tab selected, enter the following command in thePath text box:msiexec

2. In the Corequisite Files group box, click Add to specify thedirectory path that contains the MSI package and the productfiles. In this example, d:\catsdb is the directory that contains the



4.E

mb

edd

ing

MS

IP

ackages

catsdb.msi files and the product files. Tivoli SoftwareDistribution recreates the contents of the d:\catsdb directory inthe $(temp_dir)\catsdb directory on each target system.

3. Select the directory in the Corequisite Files group box, then clickEdit. The Add Directory Properties dialog displays.

4. In the Destination group box, type $(temp_dir) in the Locationtext box.

5. Click OK to return to the Execute Program Properties dialog.


144 Version 4.0

6. Click Advanced. The Execute Program Properties - Advanceddialog displays.

7. Enter the following in the Arguments text box:/qn /I $(temp_dir)\catsdb\catsdb.msi

where:

/qn Specifies an installation not requiring user interaction.

/I Specifies that the MSI package is to be installed.

<full msi path>Specifies the path on the target system in which the .msipackage and its product files are installed. In thisexample, the target path is$(temp_dir)\catsdb\catsdb.msi.



4.E

mb

edd

ing

MS

IP

ackages

8. Click OK to save the information and return to the ExecuteProgram Properties dialog. You can now define the properties forthe remove operation.

Defining the Execute Program Properties for theRemove Operation

The remove operation can be performed by referencing theProductCode property value of the installed MSI package or byproviding the path of the MSI package. The first method eliminatesthe need to specify the .msi package as a corequisite file. To definethe execute program properties for removing the MSI package, enterthe following information in the Execute Program Properties dialog.

1. With the Remove tab selected, enter the following command inthe Path field:msiexec


146 Version 4.0

2. Click Advanced. The Execute Program Properties - Advanceddialog displays.

3. Enter the following in the Arguments text box:/qn /x 5DC36340-4E67-5CBC-C0G3-4G59G10EG6G

where

/qn Specifies an installation not requiring user interaction.

/x Specifies that the MSI package is to be removed.

<product code property value>Specifies the ProductCode property value of the MSIpackage. In this example, the value is5DC36340-4E67-5CBC-C0G3-4G59G10EG6G



4.E

mb

edd

ing

MS

IP

ackages

Note: The product code property value is contained inthe .msi database. You can find it by accessing thedatabase using an editing tool provided byMicrosoft or other third parties.

4. Click OK to add the Execute program action to the softwarepackage. The Software Package Editor displays the Executeprogram action in the package list.


148 Version 4.0

How Does AutoPack Work?

The previous chapter described how to manually create softwarepackages. This chapter introduces the concepts of AutoPacktechnology.

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

You can use the AutoPack technology by selecting AutoPack fromthe Software Package Editor menu or by using the autopackcommand from the command line. For more information about theautopack command, refer to the Tivoli Software DistributionReference Manual, Version 4.0.

AutoPack automatically generates a software package by comparingtwo successive “snapshots” of a preparation machine. A preparationmachine is any Windows 95, Windows 98 (or later), Windows NT,OS/2 3.x, or UNIX computer on which the Tivoli SoftwareDistribution Java Endpoint Package Editor component is installed.

It is recommended that you use a preparation machine with few orno other applications installed. Because AutoPack relies ondifferencing technology that detects file and system configurations,using a simple system will avoid file contention. If other applicationsare installed on the preparation machine before you create the

5


5.H

ow

Do

esA

uto

Pack

Wo

rk?

software package, AutoPack might include unwanted data andsystem files, or exclude vital system files from the software package.It also helps avoid problems associated with shared objects amongdifferent applications.

It is recommended that you create a software package on the sameoperating system as the target machine. Doing this avoids filecontention that can result between different operating systems. Forexample, if you are installing Netscape Navigator on Windows 95and Windows NT systems, create a software package on eachplatform.

Note: Because AutoPack technology automatically detects both fileand system changes that take place during the installation ofan application, applications that are hardware dependent cancreate problems. For example, some graphics applications aredependent on monitor type. During the installation of thesetypes of applications, hardware settings are memorized thatwill cause incompatibility with targets that have differentsettings than those of the preparation machine.

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

AutoPack ComponentsAutoPack enables you to create software packages for distribution totarget machines without having to write configuration programs orperform additional installation tasks. It automatically determines thefiles to be distributed to the target machine and also handles changesto system components such as registry changes, desktop icons, andprograms listed on the Start menu. Consider some of the changesthat take place on system components when an application isinstalled on a Windows 95 system:

¶ A set of files is copied to a target directory.

¶ Entries are added to the Windows Registry.

¶ .ini files are created and modified.

How Does AutoPack Work?

150 Version 4.0

¶ 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 beforethe installation of an application and another after the installation iscomplete, and then uses differencing technology to identify thechanges that have taken place in the state of these components. Thedifferencing phase is the process by which the first and secondsnapshots 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 hasbeen added to the system. The addition of this file is detected duringthe differencing phase and an action is generated to add this file tothe software package. System components vary depending on theoperating system. The following table illustrates various componentsmonitored by AutoPack, their corresponding managed objects, andthe platforms that support each component.

Component Managed Objects Supported Platforms

File system Files, directories,symbolic links (forUNIX platforms)

All

Text files Lines, tokens, andcommands

All

Windows profiles (.ini) Sections, items Windows

Windows registry Keys, values Windows NT 4.0,Windows 2000 Windows95, Windows 98

Windows shell Folders, shortcuts Windows NT 4.0,Windows 2000 Windows95, Windows 98

OS/2 profiles Items OS/2 3.x, 4.0, 4.5

OS/2 desktop Generic objects,folders, programs,shadows

OS/2 3.x, 4.0, 4.5

AutoPack Components


5.H

ow

Do

esA

uto

Pack

Wo

rk?

Component Managed Objects Supported Platforms

OS/2 system files(OS2.ini andOS2SYS.ini)

Items OS/2 3.x and later

Windows NT services Services Windows NT 4.0,Windows 2000

AutoPack Configuration FileThis section describes the structure of the AutoPack configurationfile autopack.ini for Windows systems, and provides a typicalautopack.ini file for UNIX systems. AutoPack uses the configurationfile to establish which objects of a given component should bemonitored and which objects should be ignored during thedifferencing phase. AutoPack stores the configuration file in theworking directory. See “Autopack.ini Default for Windows NT 4.0”on page 160 to view a sample configuration file.

The autopack.ini file has the same structure as a Windows .ini file. Itcontains a general section and an include and exclude section foreach system component. See the table on page 151 for a list ofsystem components and the objects they manage. The includesections list the objects in the related component that must bemonitored during the snapshot, while the exclude sections list asubset of the objects in the include section that must be ignoredduring the differencing phase. For example, you can specify anentire directory structure in the include section, but can excludespecific files contained in this directory by specifying them in theexclude section. If a difference is found in an object listed in theexclude list, the action related to this object will not be included inthe software package.

Note: It is important that the include sections of the autopack.ini filedo not change between the First Snapshot and the SecondSnapshot.

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

AutoPack Components

152 Version 4.0

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

For UNIX systems, the working directory isdir_endpoint/swdis/autopack, where dir_endpoint represents thedirectory on the endpoint.

¶ FileSystem Sections. Use the FileSystem sections to manage themonitoring of file system objects. In the include section, specifythe drives that you want to scan. For Windows and OS/2platforms, the $(system_drive) is always monitored even if youdo not add it to the include section. In the exclude section,specify the directories or files that should be ignored during thedifferencing phase. You can use wildcards in this section. Forexample, to list all files in the temp directory in the FileSystemExclude section, use c:\temp\*.* in the list. Refer to the TivoliSoftware Distribution Reference Manual, Version 4.0 for moreinformation about specifying file and directory names withwildcards. The following is the syntax for the include andexclude sections for this component:[FileSystem Include]<drive_1><drive_2>...<drive_n>

[FileSystem Exclude]<pathname_1><pathname_2>...<pathname_n>

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

AutoPack Configuration File


5.H

ow

Do

esA

uto

Pack

Wo

rk?

Attention: Under the FileSystem Exclude section, exclude thedirectory containing the Tivoli code. Monitoring the root,especially on very large systems, could affect performance.See the “Autopack.ini Default for UNIX Systems” on page 162for a sample UNIX autopack configuration file.

¶ TextFiles Sections. Use these sections to manage the monitoringof text file objects. List the text files to be monitored in theinclude section, and text files to be ignored during thedifferencing phase in the exclude section. You can use wildcardsin both of these sections.[TextFiles Include]<pathname_1><pathname_2>...<pathname_n>

[TextFiles Exclude]<pathname_1><pathname_2>...<pathname_n>

When AutoPack monitors a file as a text file object, it detectschanges that have taken place inside the file, then generates anaction in the software package to apply only those changes tothe target machine. This differs from monitoring files as filesystem objects because, when AutoPack monitors file systemobjects, the entire file is replaced on the target system. Toillustrate this, consider monitoring changes to the config.sys file.Monitoring this file as a text file object enables you to replicateonly changes to the file, such as adding new lines or deletinglines from the file. Monitoring the file as a file system objectresults in the entire config.sys file being added to the packageand distributed to the target machine.

¶ WinProfiles Sections. Use these sections to manage themonitoring of Windows profiles such as .ini files. In the includesection, specify the files you want to monitor. In the excludesection, specify files that must be ignored during the differencingphase. Wildcards can be used in both sections.


154 Version 4.0

[WinProfiles Include]<pathname_1><pathname_2>...<pathname_n>

[WinProfiles Exclude]<pathname_1><pathname_2>...<pathname_n>

Monitor .ini files as WinProfile objects if you want to detectonly the changes that take place inside an .ini file. Monitor themas file system objects if you want the entire file packed into thesoftware package for distribution to the target machine.

¶ WinRegistry Sections. Use these sections to manage themonitoring of Windows Registry paths. Specify registry paths tomonitor in the include sections and specify registry paths to beignored during the differencing phase. Wildcards are notpermitted in registry paths.[WinRegistry Include]<regpath_1><regpath_2>...<regpath_n>

[WinRegistry Exclude]<regpath_1><regpath_2>...<regpath_n>

¶ OS2Profiles Sections. Use these sections to monitor OS/2profiles or .ini files except for the OS2.ini and OS2SYS.ini files.These files are treated as OS2SystemFiles objects. UnlikeWindows profiles, OS/2 profiles are binary files. Specify profilefiles you want to monitor in the include section, and specifyprofile files that must be ignored during the differencing phasein the exclude section. Wildcards can be used in both of thesesections.



5.H

ow

Do

esA

uto

Pack

Wo

rk?

[OS2Profiles Include]<pathname_1><pathname_2>...<pathname_n>

[OS2Profiles Exclude]<pathname_1><pathname_2>...<pathname_n>

Monitor .ini files as OS2Profile objects if you want to detectonly the changes that take place inside an .ini file. Monitor themas file system objects if you want the entire file packed into thesoftware package for distribution to the target machine.

¶ OS2SystemFiles Sections. The include section of thiscomponent contains the OS2.ini and OS2SYS.ini files. Do notmodify this section. However, you can modify the excludesection to specify sections of .ini files that must be ignoredduring the differencing phase. For example, these files containinformation about objects on the desktop that are unrelated tothe target machine. Exclude those sections containinginformation about desktop objects by adding them to the excludesection. The following is the syntax for the exclude section:[OS2SystemFiles Include]c:\os2\os2.inic:\os2\os2sys.ini

[OS2SystemFiles Exclude]<file:section><file:section>...<file:section>

¶ OS2Desktop Sections. The include section of this componentcontains a list of desktop folders to be monitored. Each foldercan be specified by using either the full path name or by usingits object ID. Do not modify the exclude section. Wildcards arenot permitted in these sections. The following syntax illustrateshow desktop folders are specified:


156 Version 4.0

[OS2Desktop Include]<pathname_1 OR object-id_1><pathname_2 OR object-id_2>...<pathname_n OR object-id_n>

Customizing the Configuration FileAutoPack creates the configuration file the first time it runs. Eachsection contains defaults based on the workstation configuration.These defaults are set to satisfy the most widely detected operatingsystems on workstations. For example, because most installationprocedures modify the same registry keys, the WinRegistry Includesection is set to monitor the following registry paths:HKEY_LOCAL_MACHINE\SOFTWAREHKEY_CURRENT_USERHKEY_USERS\.DefaultHKEY_LOCAL_MACHINE\System\CurrentControlSet

You can add an object to its related exclude section to ignore anychanges in that object and avoid including this change in thesoftware package, or you can add an object to its related includesection to monitor any changes in that object and include thosechanges in the software package.

The WinRegistry Exclude section contains registry keys that do notneed to be monitored. These are keys that have no part in theinstallation of software and should not be included in the softwarepackage. 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 themachine and changes constantly independent of the installation of anapplication.

The WinProfiles Exclude section contains files that do not need to bemonitored. For example, the winit.ini file is listed in this section bydefault. This file contains information regarding files that should bedeleted after restarting the system and have nothing to do with theinstallation of an application.



5.H

ow

Do

esA

uto

Pack

Wo

rk?

The file system drive to be monitored is configured for Windowssystems by default. You may need to edit the autopack.ini fileseveral times if the default settings are not applicable to your systemcomponents. For UNIX systems, you may need to personalize theFileSystem Include section. To minimize monitoring time, you canspecify a subset of file systems rather than indicating the root toavoid monitoring every file system on the target system.

Notes for Certain User EnvironmentsThere are specific user environments which require customizing theautopack.ini file to achieve a successful installation of the softwarepackage generated using AutoPack. The following points describeknown scenarios which require some user intervention:

1. The FileSystem Exclude section must be customized if you runthe following scenario:

¶ Create a software package using autopack for the MicrosoftOffice 2000 or Netscape 4.7 applications on a Windows 95or Windows 98 system.

¶ Install the software package specifying the undo option.

In this particular scenario, the installation will completesuccessfully only if the following files are inserted in theFileSystem Exclude section:c:\windows\Cookies\index.datc:\windows\History\index.datc:\windows\Temporary Internet Files\index.dat

2. A software package created using AutoPack for the installation ofNetWare Client 5 software and is installed on a Windows NTendpoint is not installed successfully. If you create a softwarepackage using AutoPack for software that modifies the systemnetwork configuration of a machine or that installs drivers, youmust modify the autopack.ini file before running the differencingphase as follows:

a. Delete the following line from the RegistryExclude section:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services


158 Version 4.0

Note: It is not recommended to permanently delete this linefrom the autopack.ini file because it could causeproblems when installing other programs.

b. In the General section, set the OverrideRegistryPermissionsoptions to y (yes) as follows:OverrideRegistryPermissions=y

3. The OverrideRegistryPermissions option must be set to y (yes) ifyou are running any of the following user environments:

¶ Create a software package using AutoPack for the DB2 clientsoftware and install the software package on a Windows NTor Windows 2000 endpoint.

¶ Create a software package using AutoPack for the Exceed6.1 software and install the software package on a Windows2000 endpoint.

¶ Create a software package using AutoPack for MicrosoftOffice 2000 software and install the software package on aWindows 2000 endpoint. Alternatively, add the followingentry in the WinRegistry Exclude section of the autopack.inifile:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\

ServiceCurrent

4. Create a software package using AutoPack for Microsoft Office2000 software. If you perform an undoable installation of thesoftware package on either a Windows NT or Windows 2000endpoint, you must increase the amount of virtual memory to atleast 300 MB.

5. If you prepare a software package using AutoPack for the NortonAntiVirus software, after installing the software package youmust perform machine reboot twice to install the softwaresuccessfully.

Dealing with Shared ObjectsThe preparation machine should have only a minimum set ofapplications installed: the operating system and AutoPack. Besidespreventing file contention, this helps avoid problems associated withshared objects.



5.H

ow

Do

esA

uto

Pack

Wo

rk?

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

CurrentVersion\SharedDLLS

Not all applications use this registry path to store their referencecounters. Apple QuickTime, for example, stores shared files underthe 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 anapplication already installed on the preparation machine, and anapplication to be installed between the first and second snapshot. Asalready mentioned, shared objects will not be reinstalled. Therefore,during the differencing phase, AutoPack includes the shared file andregistry entry as part of the software package. The file and registryentry were present before the installation and no changes occurred tothese files after the installation. No commands are generated to addthis file and registry entry.

AutoPack can minimize the problems associated with shared objectsby monitoring reference counters.

Autopack.ini Default for Windows NT 4.0[General]ComputeCRC=nVerifyCRC=nCompressionMethod=storedOverrideRegistryPermissions=nReplaceIfNewer=nRemoveIfModified=nReplaceIfExisting=yWorkingDir=C:\Program Files\Tivoli\swdis\autopack[FileSystem Include]C:\[TextFiles Include]c:\autoexec.batc:\config.sys


160 Version 4.0

[WinProfiles Include]C:\WINNT\*.ini[WinRegistry Include]HKEY_LOCAL_MACHINE\SOFTWAREHKEY_CURRENT_USERHKEY_USERS\.DefaultHKEY_LOCAL_MACHINE\System\CurrentControlSet[FileSystem Exclude]C:\TEMP\*.*C:\Program Files\Tivoli\swdis\*.*C:\WINNT\swdis.*C:\WINNT\*.grpc:\boot.ini*\win386.swp*\pagefile.sysC:\WINNT\*.inic:\autoexec.batc:\config.sys??\recycler\*.*??\recycled\*.*C:\WINNT\System32\config\*.**.lnkC:\*\ntuser.dat.logC:\*\ntuser.dat[TextFiles Exclude][WinProfiles Exclude]C:\WINNT\progman.iniC:\WINNT\wininit.iniC:\WINNT\swdis.ini[WinRegistry Exclude]HKEY_LOCAL_MACHINE\SAMHKEY_LOCAL_MACHINE\System\CloneHKEY_LOCAL_MACHINE\SOFTWARE\Program GroupsHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

\SharedDLLsHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PerflibHKEY_LOCAL_MACHINE\System\CurrentControlSet\EnumHKEY_LOCAL_MACHINE\System\CurrentControlSet\ServicesHKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion

\ExplorerHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

\ReliabilityHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

\Session Manager[WinShell Exclude]??\recycler\*.*??\recycled\*.*C:\WINNT\System32\config\*C:\TEMP\*.*



5.H

ow

Do

esA

uto

Pack

Wo

rk?

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


162 Version 4.0

Generating a Software PackageUsing AutoPack

AutoPack automatically generates a software package by reproducingthe results of an installation on a preparation machine. In thischapter, the AutoPack guided process is used to create a softwarepackage that replicates the installation of the Tivoli desktop byperforming the following tasks:

¶ Scanning drives on the preparation machine where software willbe installed to create a first snapshot, or preinstallation snapshot,of the drive and system configurations. (It is important that thepreparation machine have few or no other applications installed.The machine must also be of the same operating system type asthe target PC.)

¶ Bundling the file and system changes that result from installingsoftware on the preparation machine for distribution to targetmachines.

¶ Taking a second snapshot, or post-installation snapshot, of thepreparation machine drive and identifying the installed files andsystem changes.

¶ Creating a software package based on the difference between thefirst and second snapshots.

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

6


6.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

AutoPack process step-by-step from start to finish, or you can launcheach step separately if you need to customize the preparationmachine between steps.

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

To launch each sequential step, select AutoPack from the menu barand choose one of the following items:

¶ First Snapshot

¶ Second Snapshot

¶ Differencing

Refer to this chapter and the online help for more detailedinformation about these dialogs.

Notes:

1. This procedure can be executed locally on a disconnectedmachine using the command line interface. Refer to theautopack command in the Tivoli Software Distribution ReferenceManual, Version 4.0.

2. You cannot use AutoPack to create software packages thatperform operating system upgrades and installation.

Running AutoPackUse a Windows NT 4.0 PC as the preparation machine to create theTivoli desktop software package for Windows NT 4.0 targets. RunAutoPack on the same operating system as the target system. OnlyWindows NT 4.0 procedures are described in this chapter.

1. Verify that the preparation machine has few or no applicationsinstalled. To list the applications installed on a Windows NT 4.0PC, double-click the Add/Remove Programs icon from theWindows NT Control Panel. A dialog similar to the following is

Generating a Software Package Using AutoPack

164 Version 4.0

displayed:

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

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

Running AutoPack


6.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

2. To launch the AutoPack guided process, selectAutoPack→Guided Process from the menu bar in the SoftwarePackage Editor window.

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

Running AutoPack

166 Version 4.0

displayed.

3. Click Next to proceed with the first snapshot.

Creating the First SnapshotThe first snapshot is a preliminary snapshot of the preparationmachine drive and system configuration before the installation of theTivoli desktop application. AutoPack will scan the specified driveand store the current configuration information and directorystructure in the working directory.

Running AutoPack


6.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

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

This dialog corresponds to the General section of theautopack.ini file, as this is where the working directory isspecified. See “AutoPack Configuration File” on page 152 formore information about the autopack.ini file.

In the Working directory text box, specify the directory namewhere you want to temporarily store the results of thesnapshots. This directory contains the output files of the firstand second snapshots. The default is<product_directory>\autopack. The <product_directory> defaultvalue is located in the <system_root>\swdis.ini file if you areworking in a Windows or OS/2 environment, or in theetc\Tivoli\swdis.ini file if you are working in a UNIXenvironment. You can change the default by modifying theautopack.ini file.

2. In the Drives to monitor scrolling list, specify the drives thatyou want to monitor during the first and second snapshots. Youcan specify more than one drive. The default is your systemdrive.

Creating the First Snapshot

168 Version 4.0

3. Leave the Customize system monitoring check box selected tospecify objects to monitor or exclude during the differencingphase, such as text files, registry entries, or .ini files. IfAutoPack detects any differences in the objects that you specifyto monitor, the related action is included in the softwarepackage. AutoPack ignores any differences found in the objectsyou 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 theSoftware Installation Options dialog found in step 10 onpage 174.

In the Text Files to Include dialog, indicate the files that youwant to monitor during the differencing phase. This dialogcorresponds to the Text Files section of the autopack.ini fileexplained on page 154. The Text Files section on page 154 alsoexplains the difference between monitoring files as text fileobjects as opposed to file system objects. The Text Files toInclude dialog lists some files that AutoPack monitors bydefault. These files are usually operating system files. It isrecommended that you do not remove the files listed here. Youcan, however, add text files to be monitored by clicking Addfiles or delete other files from the list by selecting Remove.



6.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

Note: The default files to include and exclude are different foreach platform. Windows NT, Windows 95, OS/2, andUNIX 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 thedifferencing phase. You can, for example, exclude a subset ofthe objects specified in the corresponding include dialog. If anydifferences are found in these objects during the differencingphase, their related actions are excluded from the softwarepackage.


170 Version 4.0

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

In this dialog, you can specify registry paths that you want tomonitor during the differencing phase. Click Add to add newentries to the list or click Remove to remove selected entriesfrom the list. This dialog corresponds to the WinRegistrysection of the autopack.ini file explained on page 155.

6. Click Next to display the Registry Entries to Exclude dialog.



6.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

Specify registry paths to ignore during the differencing phase.In this dialog, add entries that contain information that is notused for the installation of the application. For example, thefollowing entry is already in the exclude dialog by defaultbecause it contains performance information of the targetsystem that is not applicable to the installation of theapplication:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\

Windows NT\CurrentVersion\Perflib

7. Click Add to add new entries to the exclude list, or clickRemove 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 theautopack.ini file explained on page 154. Add files that you wantto monitor during the differencing phase by clicking Add files.Remove a selected file from the list by clicking Remove. Click


172 Version 4.0

Next to display the Win Profiles to Exclude dialog.

Specify .ini files to ignore during the differencing phase. ClickAdd files to add new files to the default list, or click Removeto 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 areexcluded by default. Add any files or directories that you wantto ignore during the differencing phase. If differences are found



6.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

in these files or directories during the differencing phase, theyare excluded from the software package. This dialogcorresponds to the FileSystem section of the autopack.ini fileexplained on page 153.

Note: You must include the following directories in the SystemFiles to Exclude list:

¶ The directory where you installed the endpoint. Thedefault is C:\Program Files\LCF.

¶ The directory where you installed the server. Thedefault is C:\Tivoli.

10. Click Next. The Software Installation Options dialog isdisplayed.

In this dialog, you can choose from two installation options:

¶ Manual installation

¶ Automatic installation

The following sections describe these installation options.


174 Version 4.0

The Manual Installation OptionYou can install the Tivoli desktop software manually by selectingManual Installation from the Software Installation Options dialog.The manual installation option interrupts the AutoPack GuidedProcess to allow you to install the software. You choose when toresume with the second snapshot by relaunching the AutoPackGuided Process.

1. Select Next on the Software Installation Options dialog todisplay the Software Package Properties dialog.

2. Replace the default software package name MyPackage withTivoliDesktop.

3. Leave the default value 1.0 in the Version text box.

4. Select the appropriate check boxes:

Verify CRCWhen this option is selected, when checking the identityof the source and target files, Tivoli SoftwareDistribution compares their cyclic redundancy check(CRC) values.

Compute CRCWhen this option is selected, after the installation of a

The Manual Installation Option


6.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

file, Tivoli Software Distribution compares the CRC ofthe file installed on the target machine with thecorresponding file in the package to check whether thefile was corrupted during distribution or installation.

Replace if existingThis option specifies to replace an object that alreadyexists on the target. It is selected by default.

Remove if modifiedThis option specifies to remove the object even if thetarget object has been modified.

Override Registry PermissionsIf this option is selected, access permissions for addingor removing protected registry keys and values aretemporarily overridden, then restored after the operationis completed.

5. Click Next to display a dialog listing the steps to be performed.

Because you selected manual installation, the steps to beperformed are the first snapshot and the manual installation. Theremaining steps are executed after you have fully installed theTivoli desktop software and relaunched the AutoPack guidedprocess.


176 Version 4.0

6. Select Finish to launch the execution of the first snapshot.

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

8. Install the Tivoli desktop software as you would normally.Regardless of how you run the executable, be sure to close allapplications.

9. When the installation is complete, you can resume the secondsnapshot.

Resuming the Second SnapshotAfter you have installed the software, resume the second snapshotand the creation of the software package.

1. Select AutoPack→Guided Process from the menu bar of theSoftware Package Editor window.



6.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

An introductory dialog is displayed.

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

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

Resuming the Second Snapshot

178 Version 4.0

this information if necessary.

4. Click Next. AutoPack displays the remaining operations to beperformed.



6.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

5. Click Finish to begin creating the second snapshot.

6. At the completion of the final operation, the Tivoli desktopsoftware package and its contents are displayed in the SoftwarePackage Editor window.

You can use the Software Package Editor tools to customize thepackage properties. See “Editing Software Package Properties” onpage 127 for details on modifying software package properties.See “Saving the Software Package” on page 135 for details onsaving the package in different formats.


180 Version 4.0

Before building the software package, check the AutoPack resultin the Software Package Editor and remove any unwantedobjects. After you have built the software package, you can test itusing the disconnected command line interface (CLI) commands.Refer to the Tivoli Software Distribution Reference Manual,Version 4.0 for more information about disconnected CLIcommands.

The Automatic Installation OptionUsing the AutoPack Guided Process, you can select either AutomaticInstallation or Manual Installation to install the application. Whenyou choose the automatic installation option, the installationexecutable specified is launched during the guided process, andAutoPack automatically resumes with the second snapshot after theinstallation is complete. Using the automatic installation option, youcan install only a single application; that is, you can specify onlyone executable.

Note: Using the AutoPack Guided Process, the automatic installationoption does not function properly with certain applications,such as Tivoli applications and WinZip software. AutoPack isunable to detect when the installation is complete. The firstsnapshot is created correctly and the setup executable of theapplication is launched automatically. However, AutoPackerroneously starts the second snapshot before the installationis complete, which creates an incorrect differencing result. Inthis case, use the manual installation option to install thesoftware.

1. In the Command text box of the Software Installation Optionsdialog, enter the drive and path to the application’s installation



6.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

setup program.

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

Complete the Software Package Properties dialog. See page 175for more information about this dialog.

3. Click Next. A list of operations to be executed is displayed.

The Automatic Installation Option

182 Version 4.0

Note: Some installations recommend that you close activeapplications before proceeding with the installation. Selectthe Close the Software Package Editor check box toclose the Software Package Editor before beginning theautomatic installation. Doing this maximizes use ofresources. Upon completion of the installation procedure,you can resume with the second snapshot by launching theSoftware Package Editor and selecting AutoPack→GuidedProcess. AutoPack reminds you that a previous AutoPackprocedure has not been completed and asks if you wouldlike 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



6.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

completion.

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

Upon completion of the automatic installation process, AutoPackautomatically resumes with the second snapshot. During theautomatic installation, you may be prompted to install theapplication. AutoPack will resume with the second snapshot atthe end of the installation.

At the completion of the final operation, the Software PackageEditor window displays the software package generated byAutoPack. You can use the Software Package Editor to customizeit. See “Editing Software Package Properties” on page 127 forinformation about modifying the properties of the softwarepackage. See “Saving the Software Package” on page 135 forinformation about saving the software package in differentsoftware package formats.


184 Version 4.0

Using the PDF Importer Tool

A Microsoft Systems Management Server (SMS) package definitionfile (PDF) is a text file that contains configuration information that isstructured much like a standard initialization file (.INI file). Itcontains predefined workstation, sharing, and inventory propertysettings. Using the PDF Importer Tool from the Software PackageEditor window, Tivoli Software Distribution takes a PDF as inputand maps the data contained in the file to specific software packageproperties. The result is a software package displayed in theSoftware Package Editor window consisting of a generic containercontaining an add directory action and a sequence of executeprograms.

The Package Definition FileThe image directory of the PDF is the directory structure thatcontains all the files required to support the installation or removaloptions in the PDF. The importer tool uses the directory structure increating the software package. The following are required sections ina PDF:

¶ [PDF]

¶ [Package Definition]

¶ [SetupVariation Setup]

¶ [Setup Package for Inventory]

¶ [FileIndex]

7


7.U

sing

the

PD

FIm

po

rterTo

ol

PDF SectionThe PDF section identifies the file as a package definition file.Tivoli Software Distribution checks this section to verify that itsupports the version of the PDF format used by the file.

Package Definition SectionThe Package Definition section defines the overall software packageproperties. This section contains information such as the version ofthe product, comment settings, a list of setup variations supported bythe package, and the access permissions of the packages created withthe PDF.

SetupVariation Setup SectionThis section defines the setup variations specified in the PackageDefinition section. Setup variations specify package commands andsupported platforms.

Setup Package for Inventory SectionThe Setup Package for Inventory section defines the inventoryproperties of the package. The inventory properties are used toidentify a package by searching for a set of files that you specify inthe package’s inventory properties. For each file, you specify theattributes used to detect the file (such as file date, file size, cyclicredundancy check (CRC) value, and so on).

FileIndex SectionThe PDF must have a key that defines each file specified in theSetup Package for Inventory section. Each file corresponds to a keythat defines the attributes of the file.

Mapping the PDF to a Software PackageThe following illustrates how the PDF Importer Tool takes a packagedefinition file as input and maps specific information to softwarepackage objects to create a software package. The PDF importingprocess involves identifying the PDF file and customizing thefollowing information:

¶ The PDF name

Using the PDF Importer

186 Version 4.0

¶ The image and target package directories:

v You can compress the entire directory structure in thesoftware package before it is distributed to the target systems.

–OR–

v You can mount the package directory as a shared directoryduring the installation process. The installation program takesinput files from a remote source.

¶ Properties of the software package that correspond to thePackage 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 aredirectly mapped to software package objects by the PDF ImporterTool. Those keys not included in the tables are not mapped by thetool.

PDF Section PDF Key Software Packageattribute or action

Comments

[PDF] Version Tivoli SoftwareDistribution verifiesthat it supports thePDF version.



7.U

sing

the

PD

FIm

po

rterTo

ol

PDF Section PDF Key Software Packageattribute or action

Comments

[Package Definition] Product, Version Together, these keysbecome the name ofthe generic container

Comment Software packagedescription

Setup Variations Software packagedefault variables

The$(setup_variations)variable is created atthe end of the importprocess. Its value isthe default setupvariation selected.

CommandLine Execute programduring install andexecute programarguments

Break down thecommand line intoprogram path andarguments.

UserInputRequired Execute programduring install,advanced propertiesoption

The value for thisitem specifieswhether this packagecommand requiresuser interaction tocomplete thecommand.

SynchronousSystemExitRequired

Execute programduring install,bootable option

Indicates that theprogram will cause asystem reboot.

SupportedPlatforms Software packageconditions

The supportedplatform list ismapped as acondition in thesoftware package.

See “Adding an Execute Program Action” on page 103 for moreinformation about the execute program action.


188 Version 4.0

Using the PDF Importer ToolThe following scenario illustrates how to import definitions from aPDF file, NAVWNT.PDF, to produce a software package. The PDFfile used in this example is part of the Norton AntiVirus™ productfrom SYMANTEC™1. You can view the package definition file,“NAVWNT.PDF” on page 193, and see how its sections relate to thedialogs of the PDF Importer Tool.

1. To launch the PDF Importer Tool, select Tools→Importer→PDFfrom the menu of the Software Package Editor window.

2. In the PDF Name text box, enter the path to the NAVWNT.PDFfile.

3. Perform one of the following actions:

¶ Select the Redirected installation check box to indicate thatthe files required for the installation of the AntiVirusapplication are located in a remote network path. If the fileimages are located on a remote disk, you can mount theremote disk or create an execute program action that mountsthe remote disk using the following command:

1. Use of the Norton AntiVirus product requires a license from Symantec Corporation. For more information aboutthe Norton AntiVirus product, refer to the SYMANTEC Web site: http://www.symantec.com. Norton AntiVirusand SYMANTEC are trademarks of Symantec Corporation.



7.U

sing

the

PD

FIm

po

rterTo

ol

net use remote_disk \\path_name

-OR-

¶ Do not select this option if the files required for theinstallation of the AntiVirus application are located in a localpath.

For this scenario, do not select this check box.

4. In the Image path text box, enter the directory structure thatcontains all the files required to support the installation of theNorton AntiVirus application. The directory tree specified isbundled in the software package as an add file system object.

5. In the Target image path text box, enter the directory from wherethe installation executable is launched on the target system. Ifyou selected the Redirected installation option in step 3, youwould need to specify the remote disk that you mounted or thatyou entered in the execute program action.

6. Click Next to display the Package Definition dialog.

The importer tool extracts the information contained in thisdialog from the Package Definition section of the NAVWNT.PDFfile.


190 Version 4.0

7. Click Next to display the setup options defined in theNAVWNT.PDF file.

A setup dialog is displayed for each setup variation contained inthe PDF. Therefore, in the case of the NAVWNT.PDF file, asetup dialog is displayed for the Complete, Deinstall, and Manualsetup options. See the text format of the NAVWNT.PDF file onpage 193 to view the setup variation sections.

Use these panels to customize package commands andarguments. Make any necessary changes so that the informationin these panels reflects the target system environment. ClickNext to display the successive setup panels.



7.U

sing

the

PD

FIm

po

rterTo

ol

8. After the last setup panel, the Default setup variation panel isdisplayed.

This panel displays the list of setup variations supported by theNAVWNT.PDF file. Select one of the options as the defaultsetup to be used when this software package is installed. Theselected default setup variation becomes the value of the$(setup_variations) variable that is created at the end of theimport process.

9. Click Finish to complete the importation process. A softwarepackage is displayed in the Software Package Editor window.The software package consists of a generic container thatcontains an add directory action and a series of executeprograms. The add directory action contains the directorystructure, as specified in the image path that contains all the files


192 Version 4.0

required to support the installation.

For each setup variation contained in the PDF, a correspondingexecute program is generated. However, when you distribute thissoftware package, only the execute program for the default setupvariation is executed. A condition which satisfies the value of thedefault setup variation is set on this execute program action.Youcan change the default setup variation even after the importprocess is complete by changing the value of the$(setup_variations) variable in the Variable list editor or usingthe command line.

Sample Package Definition FileThe following is the text of the NAVWNT.PDF file. The PDFImporter Tool extracts information from this file to create a softwarepackage.

NAVWNT.PDF[PDF]Version=1.0

[Complete Setup]



7.U

sing

the

PD

FIm

po

rterTo

ol

CommandLine=setup.exe -s -sms -mnavwnt.mifCommandName=CompleteUserInputRequired=FALSESupportedPlatforms=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=DeinstallUserInputRequired=TRUESupportedPlatforms=Windows NT 4.0 (x86)

[Manual Setup]CommandLine=setup.exeCommandName=ManualUserInputRequired=TRUESupportedPlatforms=Windows NT 4.0 (x86, axp)SynchronousSystemExitRequired=TRUE

[Package Definition]Product=NAVNTVersion=5.0Comment=Norton AntiVirus 5.0 for Windows NTSetupVariations=Complete, Deinstall, ManualErrorCodes=YesCompany=Symantec CorporationImportDirectory=.SetupDirectory=.Environments=Windows NT 4.0 (x86)Capabilities=Local Setup, Iimport;TelephoneSupportNumber=RebootAfterInstall=NoRebootAfterDeInstall=No

[SMS Import Commands]cmd 1=

[Setup Package for Inventory]InventoryThisPackage=TRUEDetection Rule Part 1=file 1

[file 1]FILE=NAVWNT.EXECOLLECT=FALSEChecksum=CRC=DATE=SIZE=TIME=


194 Version 4.0

BYTE=WORD=LONG=TOKEN 1=TOKEN 2=TOKEN 3=TOKEN 4=



7.U

sing

the

PD

FIm

po

rterTo

ol


196 Version 4.0

Understanding the DistributionEnvironment

When you install Tivoli Software Distribution, you can immediatelystart creating software packages and distributing software. However,some planning at this point will lead to a more efficient andmanageable distribution environment. In particular, you shouldconsider the following questions:

¶ What types of software do you want to distribute and how muchdisk space does each require?

¶ Will certain types of network connections slow down adistribution (such as slow WAN connections)?

¶ How can you configure the network and Tivoli repeaters toefficiently distribute multiple software packages?

¶ Can you use the established relationships between machines tohelp distribute software (such as endpoints connected to a servervia a Tivoli gateway)?

¶ Are other Tivoli applications available to ease distributionefforts?

This chapter addresses these questions by presenting an examplescenario involving NoonTide Enterprises. NoonTide Enterprises is afictitious company with many of the network complexities that facetoday’s businesses. This scenario describes the step-by-stepprocedure for configuring a distribution environment. It includes thefollowing steps:

8


8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

¶ Assessing the network topology and available departmentalresources.

¶ Configuring the MDist 2 repeater to determine which machinesare suitable to be multiplexed. For a repeater gateway, itsendpoints are automatically multiplexed by the gateway whenthey are assigned to the gateway. You can also configure amanaged node with the MDist 2 service to create a standalonerepeater site.

¶ Creating the necessary repeaters, their range of managed nodeclients, and parameters.

¶ Tuning and configuring repeaters as depots to store MDist 2distribution data in order to reduce network traffic for frequentlydistributed data sets.

¶ Configuring the distribution manager in order to monitor andcontrol distributions and update the status in the database. Thedistribution manager stores status information about adistribution in the database tables. There is one distributionmanager for each TMR that keeps track of all the distributionsstarted in it. If the distribution spans multiple TMRs, all statusinformation is stored in the distribution manager in the initiatingTMR and no status information is stored in the interconnectedTMRs.

Using the distribution environment that is established in this chapter,the following chapters demonstrate how to distribute softwarepackages using Tivoli Software Distribution’s software packagetechnology. For the purpose of this scenario, we assume that you areNoonTide’s senior system administrator. The senior authorizationrole is required to perform the procedures described in this scenario.

Introducing NoonTideNoonTide Enterprises develops, markets, and sells electronicproducts to an international market. Their principal departmentsinclude Engineering, Support, Marketing, Administration, and Sales.NoonTide has installed and uses Tivoli Management Framework andseveral Tivoli applications to manage a distributed network that is

198 Version 4.0

divided into seven subnets—four in the corporate office and three inregional offices. Each department is represented by a policy region,which is created to model the management and organizationalstructure of a network computing environment, as well as to enforcecommon policies between related departments. In NoonTide’s TMRenvironment, each policy region houses each department’s resourcessuch as subregions, managed nodes, endpoints, and profile managers.

The following policy regions exist on the administrator’s desktop:

For example, the Engineering policy region represents theEngineering department. The Engineering policy region contains aUNIX managed node gateway, big, that serves endpoints. TheEngineering policy region also contains the Product, Research, andTest subpolicy regions that group and control access to resources forthese three components of the Engineering department.

NoonTide also organizes its environment according to administrationtasks. The System Monitors and Tivoli Software Distribution policy

Introducing NoonTide


8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

regions contain Tivoli Distributed Monitoring and Tivoli SoftwareDistribution subregions, jobs, and tasks. The pescado-region policyregion is the default policy region that is created when the TMRserver is installed. The name of the default policy region is takenfrom the name of the machine that is hosting the TMR server(pescado).

Network ArchitectureUnderstanding and planning NoonTide’s network topology isessential to configuring its distribution environment. NoonTide hasseven subnets—four in the corporate office and three in regionaloffices. Subnets are connected either by Ethernet connections, whichhave bandwidths of 10 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 thatconnects to the TMR server. Endpoint gateways are installed onmanaged nodes in subnets that have endpoint clients. Only endpointscan be targets of distributions. Managed nodes are no longersupported as targets with this release. To distribute a softwarepackage profile to a managed node or gateway, you must install theendpoint service on it first.

A repeater can be part of a gateway (gateway repeater) or it can becreated as a standalone repeater on a managed node that does nothave a gateway on it (standalone repeater). Standalone repeaters candistribute only to other repeaters, while gateway repeaters can alsodistribute to their endpoints (targets). The repeater managermaintains information about the Tivoli network configuration,including target clients and repeater sites. See the wrpt command in“Configuring Repeater Sites” on page 208 for more informationabout configuring repeaters.

The endpoint manager controls and configures gateways andendpoints, assigns endpoints to gateways, and maintains the endpointlist. The endpoint manager is available from the Tivoli desktop. For

Introducing NoonTide

200 Version 4.0

information about the endpoint manager, endpoint gateways, andmanaged resources, refer to the Tivoli Management FrameworkPlanning for Deployment Guide.

The following diagram illustrates NoonTide’s network topology.

Subnet 1Subnet 1 includes machines that are connected by LAN to the TMRserver, pescado, in the corporate office. Subnet 1 includes machinesin the NoonTide Operations, NoonTide Administration, andMarketing departments.

Network Architecture


8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

NoonTide Operations

odin (Solaris managed node gateway)

thor (Solaris) loki (Solaris)

balder (Solaris)

NoonTide Administration

rainbow (AIX managed node gateway) green (Windows 95)

red (Windows 98) blue (Windows 95)

orange (Windows 2000) yellow (Windows 2000)

violet (Windows 95)

NoonTide Marketing

dollar (AIX managed node gateway) peso (Windows 98)

shilling (Windows 95) franc (Windows 2000)

pound (Windows 98) drachma (Windows 98)

rupee (Windows 2000) dinar (Windows 95)

yen (Windows 95) lira (Windows 2000)

Subnet 2Subnet 2 is located in the corporate office and is connected by a T1connection to pescado. It includes machines in the HQ Salesdepartment.

NoonTide Sales (Corporate)

electron (Windows NT 4.0 managed nodegateway)

silver (Windows 98)

gold (Windows 98) platinum (OS/2)


202 Version 4.0

Subnet 3Subnet 3 is located in the corporate office and is connected by anEthernet connection to pescado. It includes machines in theNoonTide Support department.

NoonTide Sales (Corporate)

oak (AIX managed node gateway) maple (AIX)

cedar (Solaris) walnut (HP-UX)

mahogany (HP-UX) elm (HP-UX)

Subnet 4Subnet 4 includes machines in the Engineering department. Thissubnet is located in the corporate office and is connected by anEthernet connection to pescado.

NoonTide Engineering

big (HP-UX managed node gateway) brie (Solaris)

philly (Windows 95) 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)

Subnet 5Subnet 5 includes machines in the West Coast Sales department andis located in a regional office. It is connected by a T1 line toelectron.



8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

NoonTide Sales (West Coast)

pearl (NT 4.0 managed node gateway) agate (Windows 95)

coral (Windows 2000)

Subnet 6Subnet 6 includes machines in the Central Sales department and islocated 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 95)

ruby (Windows 95)

Subnet 7Subnet 7 includes machines in the East Coast Sales department andis located in a regional office. It is connected by a T1 line toelectron.

NoonTide Sales (East Coast)

lapis (NT 4.0 managed node gateway) opal (Windows 98)

sapphire (Windows 95)

Creating a Repeater HierarchyNoonTide Enterprises has configured its network environment tooptimize use of Tivoli’s Multiplexed Distribution (MDist 2) service.Every repeater (gateway or standalone) contains both an MDist 1repeater and an MDist 2 repeater. However, Tivoli SoftwareDistribution, Version 4.0 uses MDist 2 only. MDist 2 enables you toperform asynchronous distributions of large amounts of data tomultiple targets in an enterprise. The MDist 2 service maximizesNoonTide’s data throughput by performing the following operations:

¶ Enabling parallel distribution to hosts on the same subnet. Usingthis feature, the data flows from the source host pescado through


204 Version 4.0

the dollar and rainbow gateway repeaters and down to theendpoints, if both the Marketing and Administration departmentsneed this application. This feature results in a distribution thatcan be faster than sending copies of the software one at a timeto each machine.

¶ Spreading the distribution load across networks. Spreading thedistribution load across a network tree limits resource contentionthat can arise when one server is responsible for distributing tomany client machines.

¶ Sending a single copy of the data across slower links to therepeater, which redistributes it in parallel to other hosts on thefar side of the slow connection. This distribution is a moreeffective use of the network than sending a copy of the softwareacross the network gateway for each remote target. For example,pescado can efficiently distribute to pearl, diamond, and lapisusing electron as a repeater site.

¶ Enabling repeaters to temporarily or permanently storedistribution data at an intermediate fan-out point called arepeater depot. A repeater depot has the built-in MDist 2capability of permanently or temporarily storing data segments.A repeater configured as a permanent depot maintains the data inthe repeater depot even after the distribution has completed. Arepeater depot also enables you to store software distributions onnodes closer to the targets. For example, the diamond gateway,which has repeater depot functionality, can distribute softwarepackages from its repeater depot to the target systems associatedwith it.

¶ Caching distributions, which enables the checkpoint restartfunctionality. If a distribution failure occurs for one target, thefan-out point continues to distribute to the other targets. Theinterrupted distribution automatically resumes from where it leftoff using the data from the repeater depot, rather than beginningall over again from the origin of the distribution data.

By default, the TMR server (pescado) serves as the repeaterdistribution server for all the targets in the TMR. Pescado is also thesource host and therefore also a repeater. The source host machine

Creating a Repeater Hierarchy


8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

must be a repeater. Endpoint gateways are automatically configuredto act as MDist 2 repeaters for distributing information to theirendpoints. The NoonTide network includes endpoint gateways atodin, big, pearl, diamond, and lapis. NoonTide has configuredrainbow and dollar gateways to serve as additional MDist 2repeaters. The network also includes electron, a standalone repeaterwith the MDist 2 function.

The following diagram illustrates NoonTide’s repeater hierarchy. Thelines represent the distribution flow.The distribution flow would bedifferent in the case where the source host was not located on thepescado TMR but on a separate managed node. The distribution flowwould originate at the source host.


206 Version 4.0

In the case of NoonTide’s network topology, one repeater site isoften not enough to handle heavy network traffic and large softwaredistributions. To determine the number of additional repeaters neededin any given environment, use the following guidelines:

¶ If the network has slow network links, designate one managednode on each side of the network link to be a repeater with alocal copy of the Tivoli binaries.

¶ If the range (the managed node clients that receive data from therepeater site) of a repeater site contains too many clients inmultiple subnets, add a repeater site for each subnet.



8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

In addition to determining the number of repeaters, you will alsoneed to determine which of the MDist 2 repeaters are to beconfigured as permanent depots. Every repeater can be configured tobe a depot. Thus, the placement of the repeaters must take intoconsideration where you will need depot storage facilities in yourTivoli environment. It is recommended that you place depots on theother side of slow network links, like WANs, to enable quickerdistributions. You must also consider the disk space required for thestorage of distributions, especially if entire distributions are storedafter they complete. You need to calculate the size of the distributionand select a system with the required disk space.

Before you begin a distribution, you can verify the repeater route ordistribution path by using the wrpt command with the –q argument.Refer to the Tivoli Management Framework Reference Manual formore information about the wrpt command syntax and arguments.

The remainder of this chapter describes how to determine whetheradditional repeaters are needed, how to configure the parameters foreach repeater, and configuring a repeater as a depot. Refer to theTivoli Management Framework Planning for Deployment Guide todetermine repeater and repeater depot environments and settings thatwill work best in your environment. In addition, the TivoliManagement Framework Planning for Deployment Guide providesinformation about configuring endpoint gateways on managed nodesthat serve endpoints.

Configuring Repeater SitesAs NoonTide’s senior system administrator, you must complete eachof the following steps to determine whether more repeater sites arenecessary and, if so, how to configure them:

1. Determine which machines are defined as repeaters by enteringthe wrpt command from the command line of any managed nodein the TMR. For example, when you first install TivoliManagement Framework on the pescado server, wrpt results inthe following output:pescado [1] wd []


208 Version 4.0

After you configure NoonTide’s environment, run wrpt to list thedefault repeater on pescado, all endpoint gateways, and eachmanaged 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 lineof any managed node in the TMR to list the clients of thepescado 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

9 ct- 94 127.64.6.1 diamond,diamond.noontide.com

10 ct- 94 127.64.7.1 lapis,lapis.noontide.com

Note that this list contains the names and IP addresses ofmanaged nodes in each subnet shown in “Network Architecture”on page 200. Endpoints are not listed because they do not have

the full Tivoli Management Framework (oservs). Endpoints relyon managed nodes for communication with the TMR server.

3. Create a repeater site on all managed nodes that serve asrepeaters in the repeater hierarchy. Endpoint gateways areautomatically configured as repeater points for their clientendpoints.

4. Use the wrpt command to verify that repeater sites areconfigured correctly. The output for NoonTide’s configurationfollows:

Configuring Repeater Sites


8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

pescado [1] -wd- []odin [2] --- []rainbow [3]] --- []dollar [4]] --- []electron [5] --- [8, 9, 10]oak [6] --- []big [7] --- []pearl [8] --- []diamond [9] --- []lapis [10] --- []

The electron repeater lists the host numbers of the machines itserves as their range.

In NoonTide’s environment, pescado distributes software package Ato its endpoint clients, which are managed by the rainbow, odin,dollar, oak, big, and electron gateways. The electron repeaterdistributes software package A to its clients, the pearl, diamond, andlapis gateways. Finally, pearl, diamond, and lapis distribute thesoftware package to their endpoints. Each repeater and endpointgateway distributes software package A in parallel to its endpointclients. Refer to the Tivoli Management Framework ReferenceManual for more information about the wrpt and odadmincommands.

Setting Repeater ParametersNow that you have created standalone repeater and endpoint gatewayrepeater sites for NoonTide’s network, you must configure each ofthem to efficiently handle software distributions. Use the wmdistcommand to configure MDist 2 repeater parameters and managedistributions for both standalone repeaters and gateway repeaters.Refer to the wmdist command in the Tivoli Management FrameworkReference Manual for more information about command syntax andarguments.

As this scenario continues, you will distribute Adobe FrameMaker tovarious NoonTide departments. The following procedure determineshow much disk space is required for the application and how muchmemory is available on each repeater site in order to define therepeater parameters.

Configuring Repeater Sites

210 Version 4.0

You will configure each repeater and endpoint gateway in theNoonTide network in accordance with the amount of availablememory, disk space, and network bandwidth, and the number andbandwidth capacity of the repeater’s targets. For brevity, thefollowing steps configure two repeaters, electron (a Windows NTmachine) and pescado (a Solaris machine), then electron isconfigured as a repeater depot:

1. List the current settings of the repeaters’ parameters by enteringthe following wmdist command:wmdist -s electron

wmdist -s pescado

The following is the default output of this command for theelectron repeater. The default output for the pescado repeater isthe same, except that the default repeater directory for a UNIXrepeater is /var/tmp/.repeater_id: 2012560680.5.7rpt_dir: $DBDIR/tmp/permanent_storage: TRUEmax_sessions_high: 5max_sessions_medium: 10max_sessions_low: 40disk_max: 1000 (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: 3debug_delay: 0

where:

[rpt_dir]Specifies the repeater’s main directory. It is also theparent directory that is used to hold the depot directoryand the states directory. The depot directory contains allthe segments stored in the database and must haveenough free space to hold the value of disk_max. The

Setting Repeater Parameters


8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

states directory contains the database that holds thepersistent state of the repeater’s queue.

[permanent_storage]Configures the repeater to be a depot. If TRUE, thedepot retains segments marked for permanent storage byapplications after their distribution finishes. If FALSE, adistribution’s segments are deleted after the repeaterfinishes sending the distribution to all its targets.

[max_sessions_high]Specifies the maximum number of concurrentconnections that a repeater opens for high-prioritydistributions. These connections are shared among allactive distributions. If the repeater runs out ofhigh-priority connections, it tries to use amedium-priority connection.

[max_sessions_medium]Specifies the maximum number of concurrentconnections that a repeater opens for medium-prioritydistributions. These connections are shared among allactive distributions. If the repeater runs out ofmedium-priority connections, it tries to use a low-priorityconnection.

[max_sessions_low]Specifies the maximum number of concurrentconnections that a repeater opens for low-prioritydistributions. This number must be one or greater. Theseconnections are shared among all active distributions. Ifthe repeater runs out of low-priority connections, it waitsfor an open connection to complete before openingadditional connections.

[disk_max]Specifies the amount of disk space allocated to therepeater depot. Units are in megabytes (MB). If thedisk_max number equals zero, no limit is enforced. Thisnumber cannot exceed the size of the disk. Everydistribution flowing through a repeater is stored at least


212 Version 4.0

temporarily in the depot. The depot must be large enoughto hold the largest distribution that you expect todistribute.

[mem_max]Specifies the amount of memory used to buffer databeing sent to targets. This buffer improves performanceby reducing the number of disk accesses to the depot.The memory is shared among all active distributions.Units are in MB.

[send_timeout]Specifies the timeout used to detect a network or targetfailure while sending data. A target is allowedsend_timeout seconds to receive each packet on thenetwork. If a timeout occurs, the distribution remains inthe repeaters queue and a retry occurs inconn_retry_interval seconds.

[execute_timeout]Specifies the amount of time an endpoint method has toreturn results after it has received all of a distribution’sdata. Some applications may be running scripts afterreceiving data but before returning results to the repeater.Units are in seconds.

[notify_interval]Specifies the frequency (in minutes) of status reporting.As targets finish, their results are buffered by therepeater. When the notify_interval has elapsed or all ofthe targets of this distribution have finished, the resultsare flushed. The results are sent to the application usingMDist 2 and updated in the MDist 2 database.

[conn_retry_interval]Specifies the frequency (in seconds) that unavailable orinterrupted targets are retried.

[retry_ep_cutoff]Specifies the amount of plan time (in seconds) that arepeater retries an unavailable or interrupted endpoint.



8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

Unavailable or interrupted repeaters are retried until thedistribution’s deadline has been reached.

[net_load]Specifies the maximum amount of network bandwidththe repeater is allowed to use. Units are in kilobytes persecond. This allocation is shared among all activedistributions. Used with target_netload.

[packet_size]Specifies the number of bytes written to the networkduring each send.

[target_netload]Specifies the maximum amount of network bandwidththat can be sent to an individual target. Units are inkilobytes per second. The default value of 0 disables thischeck. Used with net_load.

For more information about repeater parameters, refer to theTivoli Management Framework User’s Guide and the TivoliManagement Framework Reference Manual.

2. Determine the disk space requirements of the applications to bedistributed by referring to the installation guides for theapplications.

This scenario distributes both the installation media and some ofthe application files in the software package. The installationmedia requires 180 MB and the application requires about 25MB. Thus, assume the largest FrameMaker software package willbe 210 MB, considering the overhead of the configurationprograms and the software package.

3. Check that the electron and pescado sites have the required diskspace and memory.

Note: You must be logged in as Administrator to perform thesteps to determine disk space and memory allocations.

a. Check for available disk space on electron (a Windows NTmachine) by double-clicking the Disk Administrator icon in


214 Version 4.0

the Administrative Tools window group.

The C:\ drive has 1778 MB of free disk space.

b. Check for available memory on electron (a Windows NTmachine) by double-clicking the Windows NT Diagnosticsicon in the Administrative Tools window group.

Select the Memory tab to display the following window:



8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

About 184 MB (184,372) of memory are available and 298MB (298,364 KB) of paging space are available. Also, boththe C:\ and D:\ directories are used for the system’s pagingfile.

c. Check for available memory and paging space on pescado, aSolaris machine, and locate a file system with free space thatcan be used to buffer distributions. (Commands used forfinding available memory and paging space vary by operatingsystem.)

To check for free swap space, use the swap –l command. Theoutput is:

Swapfile/dev/vx/dsk/swapvol

dev115,1

swaplo8

blocks817480

free486440

To check the amount of RAM installed on the machine, enterthe prtconf | grep “Memory size” command. Note that thiscommand returns the total amount of memory installed, notjust the free memory. The output is:Memory size: 512 Megabytes

Finally, to check the disk partitions for available space, usethe df –k command. The output is:

Filesystem/dev/vx/dsk/rootvol/dev/vx/dsk/usr/procfd/dev/vx/dsk/rootdg/vol06swap

kbytes24646324999100983020602632

used1822541845820058691168332

avail39569404190029780534300

capacity82%82%00%66%11%

Mounted on///usr/proc/var/tmp

The /tmp file system uses a portion of swap space and,therefore, is a poor choice to use as a repeater. The /var filesystem is the best choice for this system because it has thelargest free space and it does not use swap space.

4. Set electron’s repeater parameters. The send_timeout parameter isnot reconfigured. The slowest system on the network is a 486


216 Version 4.0

with 8 MB of RAM. The default send_timeout is 300 seconds,which is sufficient for this system’s configuration.

a. Set the mem_max and disk_max parameters. For performancereasons, do not set mem_max higher than the available RAM.The memory cache is used to reduce disk access to improveperformance. If mem_max is larger than available memory, itcauses the data to be swapped to disk and the performancegain will be lost. To avoid the possibility of a faileddistribution, set the disk_max parameter to the majority of thehard drive space available on the repeater. The disk_maxparameter must be as large as the entire distribution. Forexample, the following command sets these parameters for asystem with 64 MB of RAM and 3 gigabytes of availablehard drive space.wmdist -s electron mem_max=64000 disk_max=1000

b. Set the rpt_dir parameter to be on the partition with the mostfree space. The directory specified for this parameter mustreside on the NTFS drive and must be accessible (read, write,and execute permissions) by all users. In this case, use therecommended \temp directory on the C: drive:wmdist -s electron rpt_dir=C:\temp

Note that you can use a backslash (\) in the directory path ifyou enter this command from electron. If you enter thiscommand from a UNIX managed node, you must use aforward slash (/) or qualify the backslash with anotherbackslash as follows: C:\\temp.

5. Set pescado’s repeater parameters.

a. Set the mem_max parameter. Pescado’s physical memory is512 MB and available swap space is 486 MB. If pescado isused for tasks in addition to acting as a repeater, set thisparameter to use a smaller portion of the resources.wmdist -s pescado mem_max=256000

b. Set the rpt_dir and disk_max parameters. All users must havewrite permissions to the directory specified for the rpt_dirparameter. The /var file system has available disk space and



8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

files should be buffered in the /var/tmp directory. Of the 297MB available on /var, the repeater will be limited to use 230MB to ensure that it does not use all of the file system’sspace.

Set the parameters as follows:wmdist -s pescado rpt_dir=/var/tmp disk_max=230000

Note: For network connections with different bandwidths,the repeater parameter values must be scaledproportionally.

6. Verify that the repeater parameters are set correctly by enteringthe wmdist –s command for each repeater. The output for theelectron repeater is as follows:repeater_id: 2012560680.5.7rpt_dir: $DBDIR/tmp/permanent_storage: TRUEmax_sessions_high: 5max_sessions_medium: 10max_sessions_low: 40disk_max: 1000 (MB)mem_max: 64 (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: 3debug_delay: 0

The output for the pescado repeater is:repeater_id: 2012560680.1.357rpt_dir: /var/tmp/permanent_storage: TRUEmax_sessions_high: 5max_sessions_medium: 10max_sessions_low: 40disk_max: 230 (MB)mem_max: 256 (MB)send_timeout: 300 (secs)execute_timeout: 600 (secs)notify_interval: 30 (mins)


218 Version 4.0

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: 3debug_delay: 0

Note: When configuring repeater parameters, you may be asked torestart the gateway.

Using Repeater DepotsUnlike repeaters, repeater depots are able to store an entiredistribution and resume a distribution that has been halted byunavailable nodes or network failures. Once you have configured arepeater to be a repeater depot, you can submit distributions withrepeater depots as the targets. Data, or distribution segments, can betemporarily or permanently stored on the depot depending on thesettings of the repeater’s parameters. You can use the wldspcommand to load a software package on a repeater depot or thewuldsp command to unload a software package from a repeaterdepot. Refer to the Tivoli Software Distribution Reference Manualfor more information about the wldsp and wuldsp commands. Atemporary depot works like a permanent depot except that it deletesthe segments associated with a distribution once the distribution iscompleted. It is recommended that you use depots at the end ofslow, unreliable network links. However, do not use depots forextremely large distributions or data that changes frequently.

In this scenario, you will configure the electron repeater to be arepeater depot, load a software package on the depot, list the entrieson the depot, and remove a software package from a depot.

1. Configure the electron repeater to be a repeater depot. It needsenough space for all of the active distributions, plus space for alldistributions that will be permanently stored on the repeaterdepot.

To configure the electron repeater to be a repeater depot, use thewmdist command and set the permanent_storage parameter totrue as follows:wmdist -s electron permanent_storage=TRUE



8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

2. To load the mypackage software package on the electron repeaterdepot, use the wldsp command as follows:wldsp @mypackage electron

To load a software package containing nested software packageson the depot, use the wldsp command to load the primarysoftware package. Loading the primary software packageautomatically loads the nested software packages that it contains.In this case, a multi-segment distribution is submitted to MDist 2where each segment contains a different package.

3. Perform an installation of the mypackage software package fromthe electron repeater depot using the winstsp command asfollows:winstsp -l from_depot @mypackage

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. To list the entries on the electron repeater depot and informationrelated to each entry such as ID, version, size, percentagecompleted, and last modification time, use the wdepot commandtogether with the –l argument as follows:wdepot electron list -l

5. To remove the mypackage software package from the electrondepot, use the wuldsp command as follows:wuldsp @mypackage electron

6. To delete all entries in the depot, use the purge argument asfollows:wdepot electron purge

You will be prompted for confirmation before the depot ispurged.

For more information about the winstsp, wldsp, and wuldspcommands, refer to the Tivoli Software Distribution Reference

Using Repeater Depots

220 Version 4.0

Manual, Version 4.0. For more information about the wdepot andwmdist commands, refer to the Tivoli Management FrameworkReference Manual.

Installing Additional Tivoli ApplicationsNow that the NoonTide network is configured to handle networktraffic efficiently, it will use existing and newly created relationshipsto deploy software. Before you use the network configurations todistribute software packages in your network, you can install otherTivoli applications that can ease your distribution efforts.

To finish configuring the distribution environment, considerinstalling other Tivoli applications that provide additional capabilitiesto Tivoli Software Distribution. These include Tivoli Inventory andTivoli Web Interface.

You can use Tivoli Inventory to query a configuration database todetermine targets of a distribution. For example, you can query thedatabase for machines that have 20 MB of available disk spacebefore distributing an application.

A user on a Windows or UNIX endpoint can use the Tivoli WebInterface to retrieve Software Distribution profiles. This is useful ifan endpoint was not available when the software package wasoriginally distributed or if the user wants to update an applicationusing an existing software package.

If these products are available to an administrator, you can installthem before distributing software packages to help the deployment.Refer to the corresponding user’s guides for these products forinstallation instructions.

Using Repeater Depots


8.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

Installing Additional Tivoli Applications

222 Version 4.0

The Distribution Process

Using Tivoli Software Distribution, you can deploy desktop anddistributed applications with ease. From a central point, you cancreate software packages and distribute them in parallel to targetmachines in the same or different Tivoli Management Regions(TMRs). The TMR server is a Tivoli Management Frameworkcomponent that distributes Tivoli Software Distribution softwarepackages to target machines.

You use the Tivoli desktop to import software packages into theTivoli environment. The Tivoli desktop enables you to performTivoli Software Distribution operations on software packages such ascalculate size, convert, export, and change management operationssuch as install, remove, undo, accept, commit, and verify. The Tivolidesktop is what drives the execution of all the operations supportedby the server command line interface (CLI). Refer to the TivoliSoftware Distribution Reference Manual, Version 4.0 for informationabout commands. The previous chapters illustrated how to create andcustomize software packages. This chapter describes how to preparesoftware packages for distribution in the Tivoli environment.

To perform Tivoli Software Distribution tasks, you must have properauthorization. The Administrator facility on the Tivoli desktopprovides a senior administrator the ability to create administratoraccounts and assigns them the authority to perform tasks. Forexample, an administrator must have the super role to perform aninstall operation. See “Authorization Roles” on page 349 for moreinformation about Tivoli authorization roles. The administrator

9


9.T

he

Distrib

utio

nP

rocess

defines software packages and associates them with target machines.Installing Tivoli Software Distribution adds a new profile type, thesoftware package, managed by Tivoli Management Framework in theTivoli environment. To distribute a software package, you import itfrom the endpoint or managed node, thereby associating a softwarepackage object to the object database on the server. The Tivolidatabase object represents the software package. The profile is onlya definition of the information that each profile item includes. Theprofile is created from within a profile manager. Profile managers actas containers for profiles and link the profiles to a set of resourcescalled subscribers. Tivoli supports software packages only in thecontext of profile managers. Therefore, you must perform all tasksthat involve setting up profiles in a profile manager.

Profile managers are defined and used within a policy region tocontain and associate one or more target machines with one or moresoftware package profiles. The target machines subscribe to profileswithin profile managers. The subscribers of a profile managercontaining the software package object are the default targets of aTivoli Software Distribution operation. Policy regions and subregionsare collections of resources for which the same set of policies apply.Different criteria can be used to build these regions, such aspermission hierarchy, geography, departments, and so on. Policyregions and profile managers should be structured in a way thatfacilitates the distribution process. Policy regions, profile managers,and profiles are mechanisms provided by the Tivoli ManagementFramework to help organize resources hierarchically. For moreinformation about creating and using profiles and profile managers,Refer to the Tivoli Management Framework Planning forDeployment Guide.

Creating a Tivoli Software Distribution ProfileYou can create profiles from within a profile manager, and a profilemanager is defined within a policy region. Software packages areimported into Tivoli Software Distribution profiles. Use thefollowing steps to create a Tivoli Software Distribution profile fromthe Tivoli desktop to house the Appsample software package.

The Distribution Process

224 Version 4.0

In this scenario, the current distribution environment is made up ofan administrator, Root_msecchi-region; a policy region,msecchi-region; the msecchi managed nodes, and the PM1 profilemanager containing several software distribution profiles. Currently,there is only one administrator defined in the Tivoli environment,Root_msecchi-region. Double-click the Administrators icon to viewthe Administrator’s name. This is the administrator that was definedfor the root user ID when the Tivoli Management Framework wasinstalled on the server.

Administrators define and maintain policies. Policies are a set ofrules that are applied to managed resources. Policy regions helporganize the managed resources on the Tivoli desktop.

1. To add the SoftwarePackage resource to the policy region list ofmanaged resources, right-click the msecchi-region icon andselect Managed Resources from the pop-up menu to display the

Creating a Tivoli Software Distribution Profile


9.T

he

Distrib

utio

nP

rocess

Set Managed Resources dialog:

The dialog shows that the SoftwarePackage resource has alreadybeen added to the msecchi-region policy region. Click Close toreturn to the Tivoli desktop.

2. Double-click the msecchi-region icon to display the contents ofthe policy region.

3. In the Policy Region: msecchi-region dialog, selectCreate→ProfileManager to create a profile manager in which theAppsample software package profile will reside. The Create


226 Version 4.0

Profile Manager dialog is displayed.

4. Enter PM2 in the Name/Icon Label text box. Note the DatalessEndpoint Mode check box. A profile manager can operate in oneof two modes: dataless mode or database mode. The datalessmode enables a profile manager to distribute software packageprofiles to endpoints. The database mode enables softwarepackage profile distributions to any profile manager (dataless)that has endpoints as subscribers. For more information aboutoperating a profile manager in either of these modes, refer to theTivoli Management Framework Planning for Deployment Guide.Select the Dataless Endpoint mode check box and click Create& Close to return to the Policy Region: msecchi-region dialogdisplaying the new profile manager icon.

5. To create a profile in the PM2 profile manager, double-click thePM2 icon to open the Profile Manager dialog for the PM2



9.T

he

Distrib

utio

nP

rocess

profile manager.


228 Version 4.0

6. Select Create→Profile to display the Create Profile dialog.

7. To create a software package profile to house the Appsamplesoftware package, enter Appsample^1.0 as the profile name inthe Name/Icon Label text box. Avoid using characters other thanalphanumeric characters, the dash (-), underscore (_), and caret(^) symbols. Also, the profile name must not exceed 32characters. The accepted format is name followed by the versionof the software package, separated by a caret (^) symbol. This isparticularly useful if you intend to create profiles for differentversions of a software package. For example, you could createprofiles with the following names to represent different versionsof the SP_name software package:

SP_name^1.0SP_name^2.5SP_name^2.7

Note: The version can be one to three numerical stringsseparated by a period. There is no limit to the number ofdigits in each string. For example, SP_name^20.12.00.

8. Click Create & Close to create the new profile and return to theProfile Manager dialog. An icon representing the newly created



9.T

he

Distrib

utio

nP

rocess

software package profile, Appsample^1.0, is displayed in thePM2 profile manager. The format of the software package profileat this point is empty.

Setting the Profile SubscribersBefore you can perform a profile operation, you must set thesubscribers (the profile managers and endpoints to which the profilemanager distributes) for the profile manager in which the profileresides.

Note: In Tivoli Software Distribution, Version 4.0, managed nodescannot be subscribers of a software package profile. Althoughnothing prevents you from distributing a software package


230 Version 4.0

profile to a manage node, it is not a valid operation. You mustcheck the log file on the TMR for the error message.

Software packages install successfully only on endpoints; however,file packages and AutoPacks can include managed nodes assubscribers. This limitation may govern how you organize yourprofile managers. Keep your profile managers homogeneous wherepossible: avoid mixing software packages with file packages orAutoPacks in the same profile manager. Although it is true that whenperforming an install change management operation you can selectsubscribers from those already available in that particular profilemanager, this becomes a problem when you select ProfileManager→Distribute from the Profile Manager dialog menu. Thisoption distributes to all subscribers identified in that profile managerand does not allow you to selectively choose them for each type ofpackage in the profile manager.

In this scenario you will add two endpoints as the subscribers to thePM2 profile manager.

1. Select the Appsample^1.0 profile from the Profile Managerdialog.

2. Select Profile Manager→Subscribers to display the Subscribersdialog:



9.T

he

Distrib

utio

nP

rocess

3. To move a subscriber to the Current Subscribers list, choose oneor more subscribers from the Available to become Subscriberslist, then click the left arrow button. By default, all subscribers inthe profile manager are displayed in the Available to becomeSubscribers list.

To remove a subscriber, choose one or more subscribers from theCurrent Subscribers list and click the right arrow button to movethem to the Available to become Subscribers list. Move the PM1(Profile Manager) subscriber to the Current Subscribers list, thenclick Set Subscriptions & Close. The PM1 subscriber is addedto the PM2 Profile Manager dialog.


232 Version 4.0

Importing a Software Package into the TivoliEnvironment

Before a software package profile can be used to distribute asoftware package to a target system, you must import the softwarepackage into the Tivoli environment where it is catalogued as asoftware package object in the Tivoli object database. The profile isonly a definition of the information that each profile item includes.The profile items must be populated with the database objects to bedistributed. You can import an existing software package located oneither an endpoint or managed node into the software packageprofile, or you can create a new software package within thesoftware package profile.

Creating a New Software Package and Importing itinto a Software Package Profile

To create a new software package and import it into a softwarepackage profile, complete the following steps:

1. Create a software package profile as defined in “Creating aTivoli Software Distribution Profile” on page 224.

2. Right-click the software package profile icon from the ProfileManager dialog, then select Properties.

3. Click Launch Software Package Editor to display the CreateSoftware Package dialog. Enter the source host name.

4. Click Set & Close to close the dialog and launch the SoftwarePackage Editor. The Software Package Editor main window isdisplayed.

5. Create the software package using the Software Package Editoras explained in Creating a Software Package.

6. Save the software package and return to the software packageprofile in the Profile Manager dialog. The software package hasbeen imported into the software package profile.

Importing a Software Package into the Tivoli Environment


9.T

he

Distrib

utio

nP

rocess

Importing an Existing Software Package into aSoftware 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 packagecontains only a description of the objects contained in the package,that is, a sequential list of actions to be executed on the targetsystem and not the actual resources themselves, such as files andprograms. The resources reside on the source host. A softwarepackage in the built format already contains all the objects andresources required by the actions in a zipped file format.

In this scenario, the Appsample^1.0 profile is populated with theAppsample software package, which is in the not-built format.


234 Version 4.0

1. Right-click the Appsample^1.0 profile from the Profile Managerdialog, then select Import from the pop-up menu.



9.T

he

Distrib

utio

nP

rocess

2. The Import dialog imports a software package file into asoftware package profile.

In the Location of Input File group box, specify the machinetype from the drop-down list. The options are Managed Nodeand Endpoint. If you select Endpoint, enter the name of theendpoint in the Endpoint Name text box before clicking browse(...).

3. Select Managed Node from the Machine Type drop-down list,then enter msecchi in the Managed Node Name text box.

4. Click browse (...) to view the file system hierarchy for themsecchi managed node. The file you select in this browser dialogis the file that is imported into the Appsample^1.0 software


236 Version 4.0

package profile.

5. Trace the path to the Appsample.sp file in the Directories andFiles boxes. Click Set File & Close to return to the Importdialog.

6. To import the Appsample software package in the not-builtformat, deselect the Build check box in the Location of SourceHost group box. If the software package is not being built at thistime, it is not necessary to indicate the SPB Path, but you mustindicate the source host. The package will be built at distributiontime, and the resources referenced in the software package arecollected from the source host indicated. However, if the inputfile is already in built format, you must select the Build checkbox. Be certain that when a software package is being built atdistribution time or when being imported to the built format, thesource host component is installed on the source host; otherwise,an error results.

—OR—

To import the software package in the software package block(.spb, built) format, select the Build check box. If the input file



9.T

he

Distrib

utio

nP

rocess

is a software package or software package definition file, it willbe imported into a software package block. If the input file isalready a software package block, it will be copied from themanaged node or endpoint specified in the Location of Input Filegroup box to the specified software package block path on thesource host.

Note: Always select the Build check box when importing asoftware package block.

Selecting the Build check box enables the Overwrite check box.Select Overwrite to overwrite the software package block shouldit already exist on the source host.

For this scenario, deselect the Build check box.

7. Enter the source host name in the Source Host Name text box.The source host is where the files in the software package blockare obtained and where the software package block is stored. Thesource host can be any of the available managed nodes on whichthe Tivoli Software Distribution source host component isinstalled. If the source host and SPB path have already beendefined in the software package specified in the Input File Pathtext box, you can leave this information blank in this dialog.

8. Click Import & Close. The software package profile icon in theProfile Manager dialog is now in the not-built format.

Deleting a Software Package ProfileWhen you delete a software package profile, it is removed from theTivoli database and its icon is removed from the profile manager.Deleting a profile does not delete the source files or directories orthe distributed files or directories on the subscribers.

Note: If you delete a software package for which you havescheduled a distribution, you must delete the job from thescheduler. Deleting a profile does not automatically delete thejob. Refer to the Tivoli Management Framework Planning forDeployment Guide for more information about using thescheduler.


238 Version 4.0

To remove previously distributed software packages from targetsystems, you perform a Remove change management operation. See“Remove (wremovsp)” on page 260 for more information aboutremoving a software package.

Software Package PropertiesSoftware package properties are defined using the Software PackageEditor or from the command line. To view the properties of theAppsample software package profile from the Tivoli desktop,complete the following steps:

1. Right-click the Appsample^1.0 software package profile icon inthe Profile Manager dialog, then select Properties. The SoftwarePackage Properties dialog is displayed.

2. From this dialog, you can view the properties set for the softwarepackage. You define software package properties using theSoftware Package Editor or the command line, or by exporting toa software package definition file. By clicking Launch SoftwarePackage Editor, you can:

¶ View and edit the contents of a software package

¶ Create a software package from scratch



9.T

he

Distrib

utio

nP

rocess

Only software packages in the not-built format (.sp, .spd) can beedited using the Software Package Editor. See “Launching theSoftware Package Editor on Managed Nodes” on page 43 formore information about editing software packages in the builtformat.

However, not all of the Software Package Editor options areenabled when the Software Package Editor is launched from theSoftware Package Properties dialog. For more information aboutSoftware Package Editor limitations, see “Launching theSoftware Package Editor on Managed Nodes” on page 43.

3. To view information on software packages nested in theAppsample^1.0 software package, click Nested SoftwarePackages. See “Distributing Nested Software Packages” onpage 268 for more information about distributing softwarepackages that contain nested packages.

4. Click Advanced to display the Advanced Properties dialog.

The properties displayed in the Software Package Properties andAdvanced Properties dialogs are those explained in “Setting

Software Package Properties

240 Version 4.0

Software Package-level Properties” on page 109 from theSoftware Package Editor. See also the online help about thesedialogs for more information.

Calculating the Size of a Software PackageCalculate the size of a software package at the source host todetermine the total size of the files it contains. Use this option torecalculate the size if you have made changes to the package sinceits creation.

To calculate the size of the Appsample software package in the builtformat, complete the following steps:

1. Right-click the software package profile from the ProfileManager dialog, and select Calculate Size from the pop-upmenu. The Calculate Software Package Size dialog is displayed.

2. The Calculate Software Package Size dialog displays the name ofthe software package and its profile manager. If the size of thesoftware package had already been calculated in the past, itdisplays the last recorded calculation. Click Calculate Size torecalculate the size of the currently selected software package (inbytes). Note that if a package contains only actions, that is, thepackage is in the not-built format, its size will be calculated aszero.

When calculating the size of nested software packages, the size iscalculated as the sum of the size of the primary package plus the

Software Package Properties


9.T

he

Distrib

utio

nP

rocess

size of the nested packages. The size can be calculated successfullyonly if the primary package and nested packages have been importedinto the Tivoli environment and catalogued as software packageobjects in the Tivoli object database.

Converting a Software PackageThe convert operation is used to transform the software package fileformat from software package to software package block, or fromsoftware package block to software package. This operation can beused to convert only software package objects that already exist inthe object database. In other words, the software package objectsmust have been imported into the Tivoli environment.

Note: The size of a software package block cannot exceed 2 GB.

A software package (.sp) contains only a description of the objectscontained in the package. That is, it contains a sequential list ofactions to be executed on the target machine and not the actualobjects or resources themselves, such as files or programs, which arelocated on the source host. A software package block (.spb) is in azipped file format and bundles the actions with the resources. All theresources must be located on the selected source host; otherwise, theoperation fails.

To convert the Appsample software package (not-built) to a softwarepackage block (built), complete the following steps:

1. Right-click the Appsample^1.0 software package in the ProfileManager dialog, then select Convert from the pop-up menu.

Calculating the Size of a Software Package

242 Version 4.0

2. In the SPB Path text box, type the path and file name for thesoftware package block on the source host. The source host isthe managed node defined when the package is imported.

3. Select Overwrite to overwrite the software package block if italready exists on the source host. This option is valid only if thetarget format is a software package block.

4. Click Convert & Close to convert the software package into asoftware package block on the source host.

To convert the Appsample software package block (built) to asoftware package (not-built), follow these steps.

Note: When you perform the convert operation of a software blockto a software package, the software package block is deletedfrom the source host. Make a copy of the software packageblock prior to the operation if necessary.

1. Right-click the software package block and select Convert. The.spb is stored on the source host defined at the time of import.The dialog displays the text “Convert to not-built format.”

2. Click Convert to convert the software package block to asoftware package, or click Convert & Close to perform theconversion and return to the Profile Manager window.

Exporting a Software PackageThe Export dialog enables you to export a software package object(.sp, spb) into text file (.spd) format. This text file is the softwarepackage definition file. It consists of a sequence of stanzas, each ofwhich describes an action to be executed. Using a text editor, youcan view the .spd file, modify it, and use the Import function toimport the revised .spd file into a software package or softwarepackage block. Refer to the Tivoli Software Distribution ReferenceManual, Version 4.0 for more information about the .spd file format.

To export a software package object to the .spd format and thenreimport it, complete these steps.

Converting a Software Package


9.T

he

Distrib

utio

nP

rocess

1. Right-click the Appsample^1.0 software package profile, thenselect Export from the pop-up menu.

2. Specify the name of the managed node to which the file shouldbe exported in the Managed Node Name text box.

3. In the Path text box, specify the full pathname of the file on themanaged node to which the software package will be exported.To export to a remote managed node, you must specify its fullyqualified path.

4. Select the Overwrite check box to overwrite an existing .spd fileshould it exist.

5. Click Export & Close to export the software package to the .spdfile format.

6. Open and edit the software package definition file using a texteditor. You can view software package definition files in theTivoli Software Distribution Reference Manual, Version 4.0.

7. Follow the instructions in “Importing a Software Package intothe Tivoli Environment” on page 233 to import the .spd file toeither a built or not-built software package.

Change Management OperationsTivoli Software Distribution offers a number of change managementoperations that are performed on a software package object. Theseoptions fully automate distributing and installing software. TivoliSoftware Distribution supports the following operations that act onsoftware packages:

Exporting a Software Package

244 Version 4.0

¶ Install

¶ Remove

¶ Undo

¶ Accept

¶ Commit

¶ Verify

The following sections briefly describe change managementoperations. For more information about operations and dialogs thatfollow, refer to the corresponding Tivoli Software Distribution servercommand, which can be run from the command line of the server, inthe Tivoli Software Distribution Reference Manual, Version 4.0. Youcan also refer to the online help by clicking Help on thecorresponding dialog from the Tivoli Management Frameworkdesktop.

Executing Change Management OperationsEach of the change management operations is performed in threesteps:

1. Check

Test that the operation can be performed to reduce the risk offailure during the execution phase.

2. Execute

Perform the operation only if the check is successful.

3. Cleanup

Resources acquired during the execute phase are deleted.

Depending on the state of a software package, not all operations canbe performed on it. The state of a software package is determined bythe following:

¶ The last operation performed (install or remove).

¶ The state of the last operation performed (prepared orcommitted).

¶ The state of the backup package (undoable state).

Change Management Operations


9.T

he

Distrib

utio

nP

rocess

¶ Whether a reboot is required to complete the operation.

¶ An additional flag to indicate error condition.

To view the state of a software package, you can use TivoliInventory; view the system log file; or run the wdlssp command,which produces a list of software packages installed on a targetmachine and the version and the state of each software package.Refer to the Tivoli Software Distribution Reference Manual, Version4.0 for more information about software package states, the wdlsspcommand, and the use of change management operations.

To display the change management operations that can be performedon the software package, right-click the Appsample^1.0 softwarepackage in the Profile Manager dialog to display a pop-up menu.


246 Version 4.0

From this menu, you can view software package properties, calculatethe size of the software package, convert the software package into asoftware package block, export software packages, and performchange management operations on software packages.

Install (winstsp)The install operation performs the actions contained in the softwarepackage. The actions executed by the install operation depend on thenature of the action. For example, while the install operation of theadd file action copies a file to the target file system, the installoperation of the remove registry key action removes a registry keyfrom the target system Windows registry.

1. Select Install from the Appsample^1.0 software package pop-upmenu to display the Install Software Package dialog.



9.T

he

Distrib

utio

nP

rocess

2. In the Label text box, specify the name of the software package,for example, Appsample^1.0. The default is the softwarepackage name, but you can specify any text in this text box.

3. Specify the order in which distributions are handled byrepeaters in the Priority Level group box. The default value isMedium.

4. In the Changes group box, click one of the following:

All Installs all the files in the software package.

SourceInstalls only those source host files that have beenmodified since the last successful distribution to thetarget system. This option applies only to not-builtsoftware packages and only to target machines wherethe software package has already been installed andcommitted.

RepairInstalls only the following:

¶ The source objects that since the time of the lastsuccessful installation have been corrupted,modified, or are not present on the target, to makethe target objects consistent with the source objects

¶ The objects and actions on the target that have beenchanged or corrupted since the time of the lastsuccessful installation

The software package is re-built and installed on thetarget. The repair option applies only to softwarepackages in the following operational states:

¶ Target machines on which the software package hasalready been installed and committed (IC)

¶ Target machines on which the software package hasbeen installed and committed, but the softwarepackage is in error (IC---E)


248 Version 4.0

Refer to the Tivoli Software Distribution ReferenceManual for more information about software packageoperational states.

5. In the Checks group box, click one of the following:

No ChecksExcludes all options in this box.

ChecksVerifies whether the installation can be executed beforethe installation is attempted. (Tivoli Inventory must beinstalled.)

Force Forces the operation regardless of the state of thesoftware package on the target system.

IgnorePerforms the installation only on target systems thathave been successfully checked. (Tivoli Inventory mustbe installed.).

PreviewReturns to the log file on the server a list of actions thatwould be executed if you performed an install. Thesoftware package is not actually installed.

6. Deselect the Disposable check box to keep the data associatedwith a distribution at the repeater after all target systems havereceived the distribution. Select the Disposable check box toremove the data associated with a distribution from the repeateronce the distribution has finished (either all endpoints havecompleted or the distribution has exceeded its life span).Repeater depots that have not been configured to acceptpermanent distributions will remove the data associated with thedistribution. However, repeater depots that have been configuredto accept permanent distributions will store the distribution. Formore information about configuring repeater depots to acceptpermanent distributions, see “Setting Repeater Parameters” onpage 210.

Note: If the object of the distribution is a software package inthe not-built format and not a software package block,



9.T

he

Distrib

utio

nP

rocess

this option is disabled and the data is deleted after thesoftware package is distributed and not stored on thedepot or gateway.

7. Select the From Depot check box to specify that the softwarepackage to be installed resides on the repeater depot rather thanon the source host. See “Creating a Repeater Hierarchy” onpage 204 for more information about depots. This option doesnot apply to software packages in the not-built format.

8. To move a subscriber to the Install Software Package On list,choose one or more subscribers from the Available Subscriberslist, then click the left arrow. By default, all subscribers in theprofile manager are displayed in the Available Subscribers list.

To remove a subscriber, choose one or more subscribers fromthe Install Software Package On list and click the right arrow tomove them to the Available Subscribers list.

If the Available Subscribers list contains a profile manager, aplus sign (+) appears in front of its name. You can double-clicka profile manager name to expand it and display the Tivoliendpoints it contains and the other profile managers thatsubscribe to it. You can then select any of the subscribers andadd them to the Install Software Package On list. If you select aprofile manager name in the Available Subscribers list, youmust deselect it before double-clicking it.

The name of an expanded profile manager has a dash (–) infront of it in the Available Subscribers list. To compress anexpanded profile manager entry, double-click the profilemanager name. Click Expand All or Compress All to expandor compress all profile managers in the Available Subscriberslist.

9. If you have Tivoli Inventory installed, you can selectsubscribers by scanning the available Tivoli endpoints forcertain criteria defined by a query in a query library. Click


250 Version 4.0

Query to display the Execute a Query dialog.

In this dialog, you can use the Tivoli configuration repository todefine a list of distribution targets for a profile manager thatcontains a software package. It lists the available query librariesthat 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 configurationrepository and return the names of the endpoints that meet thecriteria. This list automatically populates the Install SoftwarePackage On list. Refer to the Tivoli Management FrameworkPlanning for Deployment Guide for more information aboutcreating and using queries. Click Close to return to the InstallSoftware Package dialog.



9.T

he

Distrib

utio

nP

rocess

10. Click Schedule to schedule operations at a future time. TivoliSoftware Distribution displays the Add Scheduled Job dialog.

The Add Scheduled Job dialog can be used to schedule jobs forthe following operations:

¶ Install

¶ Remove

¶ Accept


252 Version 4.0

¶ Commit

¶ Undo

Tivoli Software Distribution automatically retries an unavailabletarget for the length of its distribution lifetime, without waitinguntil the distribution to all other targets is complete.

Note: When performing a distribution of a software packageprofile using either the Distribute option from the ProfileManager menu or the drag-and-drop method, thescheduler’s retry options do not function.

You can also set retry options by selecting SetRetry/Cancel/Restriction Options from the Add Scheduled Jobdialog. The Set Retry/Cancel/Restriction Options dialog isdisplayed.

When the time set in the Retry Options group box arrives, anytargets that experienced a failed distribution prior to this time



9.T

he

Distrib

utio

nP

rocess

are retried. Any ongoing distributions, or distributions that havebeen cancelled are not resubmitted.

Conversely, if a repeat is scheduled in the Repeat The Jobgroup box, the distribution is repeated for all targets, includingthose that were previously unavailable and are currently beingretried by the MDist 2 service. The result is two instances ofthe same distribution to the same target at the same time. Toavoid this situation, set the lifetime of the distribution shorterthan the repeat interval. See Timeout Settings in “OtherAdvanced Options” on page 257 for more information aboutsetting the lifetime of a distribution.

If Checks, Ignore, or Force is selected in the Checks group boxfrom the operation dialogs that support the scheduling function,the check requested is performed when the scheduled timearrives and the job is executed. If retry or repeat, or both, areselected for a job, the checks are performed before theexecution of the selection. Checks are not performedimmediately for scheduled distributions because the state of thesoftware package for a target could change before the scheduledtime arrives.

Refer to the Tivoli Management Framework Planning forDeployment Guide for more information about creating tasksand jobs and using drag-and-drop to schedule a job.

Click Close to close the Add Scheduled Job dialog and returnto the Install Software Package dialog.

11. To replace all values in this dialog with the default values forthis operation click Reset.

12. Before you click Install & Close, set the options in theOperation Modes, Default Variables, and Timeout Settingsdialogs available from the Advanced Options menu item on theInstall Software Package dialog.


254 Version 4.0

Install Operation ModesSelecting Operation Modes from the Advanced Options pull-downmenu enables you to specify additional options to be used whenexecuting an install operation.

The options available in this dialog depend on the selections youmake. For example, selecting Yes in the Transactional Options groupbox enables the Auto-Commit check box in the AutomaticOperations group box, which was previously grayed out. Selectingthe Auto-Commit check box enables the Reboot Options that werepreviously grayed out. Reboot options are not valid on UNIXsystems. The install operation supports the following executionoptions:

¶ Transactional Options

No Not-transactional: This option does not provide thecapability of returning the system to its initial state if theoperation fails. Use this option only if you are sure theoperation will complete successfully.

Yes Transactional: Requests the system to either leave itselfin a consistent state after an operation or, if at least oneaction does not succeed, to abort the operation andreturn itself to its initial state.



9.T

he

Distrib

utio

nP

rocess

If necessaryPreferably not-transactional: Requests the system to notexecute the operation in transactional mode if it detectsthat it cannot proceed because of temporary errors thatcould disappear during the commit phase.

¶ Undoable Options

No Not-undoable: A backup package is not created andtherefore the undo of an operation is not possible.

Yes Undoable: Requests the ability to return the system to itsprevious state; creates a backup package.

Note: This option is recommended for softwarepackages that install system files, because theoperation can then be rolled back (undone)without damaging the system.

If possiblePreferably-undoable: Attempts to create a backuppackage, but continues with the normal installation if theprocess to acquire backup copies fails.

TransactionalUndoable-in-transactional: Requests the system toreserve the necessary disk space for backup copies in thestaging area during the preparation phase, whichminimizes the risk of failure due to insufficient diskspace during the commit phase. During the commitphase, the staging area is freed up and all the updatesdone in the preparation phase take effect.

¶ Reboot Options

No Not-in-a-reboot: Auto-commit without a reboot. Executesthe commit operation without a machine reboot. Thisoption increases the possibility of errors due to possiblelocked resources.

Yes In-a-reboot: Auto-commit with a user reboot. Executesthe commit phase the next time the machine is rebootedby the user.


256 Version 4.0

If necessaryExecutes the commit phase with a machine reboot onlyif necessary. For example, if locked files are found, anauto reboot will be performed.

AutomaticAuto-reboot: Executes the commit phase with a rebootwhen only the operating system is running and all otherapplications are closed. This option prepares the systemto complete the operation when the Tivoli SoftwareDistribution agent automatically runs the rebootoperation.

¶ Automatic Operations

Auto-CommitRequests the system to automatically commit a pendingoperation.

Auto-AcceptRequests the system to automatically accept an undoableoperation.

Click Set to save the options you selected, or click Set & Close tosave the options and return to the Install Software Package dialog.

Other Advanced OptionsIn addition to the Operation Modes dialog, the Advanced Optionsmenu contains up to two other options, depending on the type ofoperation being performed: Default Variables and Timeout Settings.



9.T

he

Distrib

utio

nP

rocess

1. Select Default Variables to display the following dialog:

You can override the value of default variables formerly definedeither in the Software Package Editor or in a Software PackageDefinition (SPD) file. See “Creating a Software Package” onpage 41 for more information about setting variables from theSoftware Package Editor.

a. To change the value of a variable, type the name of thedefault variable for which you want to change the value inthe Variable Name text box. In the Variable Value text box,type the new value to be assigned to the variable.

b. Using the Default Variables List group box, you can also addor remove variables to be used during the execution of anoperation.

c. Click Set to save the variables you specified, or click Set &Close to save the variables and return to the Install SoftwarePackage dialog.

Refer to the Tivoli Software Distribution Reference Manual,Version 4.0 for a list and description of Tivoli SoftwareDistribution built-in variables.


258 Version 4.0

2. Select the Timeout Settings option from the Advanced Optionsmenu to set server-level and client-level timeout parameters thatenable you to specify a time interval after which either the serveror client interrupts a distribution. Setting timeout parameters canavoid suspended distributions.

¶ The Deadline refers to the date on which a distributionexpires, that is, when it fails for unavailable targets.

¶ The Notification Interval text box specifies the notificationinterval with which each repeater bundles up the completedresults and returns them to the application and distributionmanager. The interval is expressed as a positive integerrepresenting seconds. The default value is 1800 seconds (30minutes). The value specified here overrides the valuepreviously set using the wmdist -s command. See “SettingRepeater Parameters” on page 210 for more information.

¶ Send Timeout refers to the length of time a repeater will waitfor a target to receive a block of data. This timeout is used todetect network or endpoint failures. The default length oftime is 300 seconds (five minutes). The value specified hereoverrides the value previously set using the wmdist -scommand.



9.T

he

Distrib

utio

nP

rocess

¶ Execution Timeout refers to the length of time a repeater willwait for Tivoli Software Distribution to return the result of adistribution after all the data has been sent. This timeout isused to detect network, endpoint, or script failures, forexample, a script that is running in an infinite loop. Thedefault length of time is 300 seconds (five minutes). Thevalue specified here overrides the value previously set usingthe wmdist -s command.

3. Click Set to save the settings you specified, or click Set & Closeto save the settings and return to the Install Software Packagedialog.

When you have finished setting options from the Advanced Optionsmenu, install the software package to the selected subscribers byclicking Install & Close from the Install Software Package dialog.The dialog is not dismissed until the operation has been submitted.You can view the status of the distribution using the DistributionStatus Console or from the command line using the wmdistcommand. Refer to the Tivoli Management Framework User’s Guide,Version 3.7 for more detailed information.

Remove (wremovsp)The remove operation uninstalls the software package; that is, itperforms the opposite action of the install operation. The removeoperation does not return the system to its state prior to the lastexecuted operation (see “Undo (wundosp)” on page 262). The actionsperformed by the remove operation depend on the nature of theaction. Add object-related actions are reversed. For example, whilethe remove operation on the add file action removes a file from thefile system, the remove operation of the add registry key actionremoves a registry key from the Windows registry. However, theremove operation on a remove object-action does nothing. Thebehavior of remove operations on program and system actions isdefined in the program and system action properties.


260 Version 4.0

Select Remove from the Appsample^1.0 software package pop-upmenu to display the Remove Software Package dialog.

See “Install (winstsp)” on page 247 for an explanation of thecontents of the Remove Software Package dialog.

Remove Operation ModesSelecting Operation Modes from the Advanced Options menuenables you to specify additional options to be used when



9.T

he

Distrib

utio

nP

rocess

performing a remove operation.

The remove operation supports the same options as the installoperation. See “Install Operation Modes” on page 255 for definitionsof these options.

Note: Do not select the Transactional radio button in the UndoableOptions group box if you are removing a software packagethat has installed system files. Use the undo operation instead.

Undo (wundosp)The undo operation returns the system to its state prior to theexecution of the previous operation. This operation is used forobjects for which the previous operation was submitted in undoableor in transactional mode to roll back the system to its original state.Files added by the installation that did not exist prior to thedistribution are removed. If the files existed prior to the distributionand were removed, they are added back. If they existed prior to thedistribution and were replaced, the previous copy is restored.Additions, deletions, or changes made to configuration or systeminformation (registry changes, .ini file entries, folders, shortcuts, andso on) are reset to their original state. However, this operation isvalid only for the last attempted installation, not for prior


262 Version 4.0

installations. In the event of fatal errors during the installationprocess, this operation is triggered automatically.

Select Undo from the Appsample^1.0 software package pop-upmenu to display the Undo Software Package dialog.

See “Install (winstsp)” on page 247 for an explanation of thecontents of the Undo Software Package dialog.

Undo Operation ModesSelecting Operation Modes from the Advanced Options menuenables you to specify additional options to be used when executing



9.T

he

Distrib

utio

nP

rocess

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 255 for definitions of theseoptions.

Accept (waccptsp)The accept operation discards the resources needed to undo theprevious operation. The accept operation, which frees up systemresources, should be performed only when you are certain that youwill not need to undo the previous operation. After running an acceptoperation, the previous operation is no longer undoable.


264 Version 4.0

Select Accept from the Appsample^1.0 software package pop-upmenu to display the Accept Software Package dialog.

See “Install (winstsp)” on page 247 for an explanation of thecontents of the Accept Software Package dialog.

Commit (wcmmtsp)The commit operation causes all the updates established in thepreparation phase to take effect.



9.T

he

Distrib

utio

nP

rocess

Select Commit from the Appsample^1.0 software package pop-upmenu to display the Commit Software Package dialog.

See “Install (winstsp)” on page 247 for an explanation of thecontents of the Commit Software Package dialog.

Commit Operation ModesSelecting on Operation Modes from the Advanced Options menuenables you to specify additional options to be used when executing


266 Version 4.0

a commit operation.

The commit operation supports the following execution options:

No Not-in-a-reboot: Executes the commit operation without apotentially unnecessary machine reboot. However, this optionincreases the possibility of errors due to locked resources.

Yes In-a-reboot: Executes the commit operation with a rebootwhen only the operating system is running. This optionprepares the system to complete the commit phase the nexttime the machine is rebooted by the user.

If necessaryReboot-only-if-necessary: Executes the commit operationwith a reboot only if files are locked on the target at thetime of distribution.

AutomaticAuto-reboot: Same as the Yes option, but the rebootoperation is automatically run by the Tivoli SoftwareDistribution agent.

Verify (wversp)The verify operation verifies the consistency of an installed softwarepackage and the objects on the target system. A verify operation



9.T

he

Distrib

utio

nP

rocess

checks that the changes that occurred during the last operation areintact. If this operation fails, the software package is placed in anerror state. The actions performed by the verify operation depend onthe nature of the action. For example, while the verify operation ofthe add file action verifies that the copied file still exists, the verifyoperation of the add registry key action verifies that the registry keyis still in the Windows registry.

Select Verify from the Appsample^1.0 software package pop-upmenu to display the Verify Software Package dialog.

See “Install (winstsp)” on page 247 for an explanation of thecontents of the Verify Software Package dialog.

Distributing Nested Software PackagesThe distribution behavior of a software package containing nestedsoftware packages varies depending on the following factors:


268 Version 4.0

¶ The type of change management operation submitted on theprimary package

¶ The change management status of the primary and nestedsoftware packages

¶ The installation options set in the primary and nested softwarepackages

When Tivoli Software Distribution change management operationsare performed on a primary package, the operation is also performedon the nested software packages. The following is the behavior of aprimary software package containing nested software packages foreach change management operation:

Install The install operation installs the primary software packageand its nested software packages in the order specifiedduring the package creation. Even if the Stop on failureoption is not selected in the primary package, if theinstallation of a nested software package fails, theinstallation of the primary package fails also. Recoveryactions may be performed, depending on the installationoptions specified in the software package. For example, ifthe install operation was submitted in undoable mode, thetarget system is returned to its state prior to the installationfailure.

RemoveSubmitting a remove operation on a primary softwarepackage that contains nested software packages removes thepackages in the reverse order in which they were originallyinstalled.

Undo The undo operation is performed on the primary package andnested software packages in the reverse order in which theywere originally installed. The undo operation is successful ifthe operation on the primary package completes successfully,and the operation on each of the nested software packagescompletes successfully. The undo operation fails if theprimary software package or one of its nested softwarepackages were not originally installed in transactional mode.

Distributing Nested Software Packages


9.T

he

Distrib

utio

nP

rocess

AcceptThe accept operation is performed on the primary softwarepackage and its nested software packages in the orderspecified at creation time. If one or more software packagesare in error, they are ignored during the accept operation.The accept operation completes successfully only if theprimary software package and its nested software packagesare in a not-undoable state.

CommitThe commit operation is performed on the primary softwarepackage and its nested software packages in the orderspecified at creation time. The commit operation completessuccessfully when the primary package and its nestedpackages are installed in a committed state.

Verify The verify operation is performed on the primary softwarepackage and on its nested software packages in the orderspecified at creation time.

For more information about change management operations, see“Change Management Operations” on page 244. See “Nestedpackages” on page 126 for more information about specifying theorder of execution of the primary package and nested softwarepackages.

Things to ConsiderBefore implementing nested software packages, consider thefollowing:

¶ Nested software packages are built independently from theprimary software package.

¶ Nested software packages are imported into the Tivolienvironment individually. If one or more nested softwarepackages is not in the object database and an operation has beensubmitted on the primary package, the operation is unsuccessfuland an error message for each missing package is displayed.

¶ The source host for all packages must be the same


270 Version 4.0

¶ Nested software packages can reside in different policy regions,but the user performing an operation on a primary packagecontaining nested software packages must have the properauthorization role.

¶ The repair operation is performed only on the primary softwarepackage. No changes are performed during this operation.

¶ No checks are performed on the nested software packages whenthe primary package is imported into the object database. Allchecks are performed when a change management operation issubmitted on the primary package. For this reason, no checks areperformed when a software package is removed from the objectdatabase or renamed.

¶ Submitting operations in a disconnected target mode does nothave any effect on nested software packages. Use only servercommands.

¶ Utilizing the MDist 2 functionality, each software package isconsidered a segment. When distributing or loading a primarypackage containing two nested software packages, thedistribution uses three distinct segments: one for the primarypackage, one for the first nested software package, and one forthe second nested software package.



9.T

he

Distrib

utio

nP

rocess

Nested Package Distribution ScenarioConsider the software package structure illustrated by the followingfigure:

Software Packages B, C and D are nested in Software Package A.The order of execution of the software packages is the orderspecified during the creation of the primary software package. In thisscenario, the primary software package has been specified to beexecuted first and the nested packages follow. The following is theorder 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 PackageA (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)


272 Version 4.0

The default change management operation and operation mode set inthe primary package override the defaults specified in the nestedsoftware packages. When an install operation is submitted on theprimary package, the following steps are performed:

1. Software package status information is retrieved from theinventory 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 logreports that the rollback has been performed successfully.

6. An undo operation is executed on Software Package B. The logreports that the rollback has been performed successfully.

7. An undo operation is executed on Software Package C. The logreports 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 operationis interrupted and recovery operations are performed. The relatedreports containing the results of the operation are sent in accordancewith the log information options specified in each of the softwarepackages. However, the log for the primary software package alsocontains the results of the operations for the nested softwarepackages. Because the nested software packages were returned totheir original state, a report is not transmitted back to the server.

When an installation completes successfully, and the HistoricalDatabase and Change Management Status features are enabled, theconfiguration repository is updated with the information related tothe primary software package and the nested software packages.



9.T

he

Distrib

utio

nP

rocess

274 Version 4.0

Tivoli Software Distribution WebInterface

Using Tivoli Software Distribution Web Interface enables Web userson UNIX, Windows 95, and Windows NT endpoints to retrieveTivoli Software Distribution profiles. This interface enablesendpoints to do the following:

¶ Selectively download new software applications and data, orupdate existing software.

¶ Download software packages that were not received at a priordistribution time.

The benefits of Tivoli Software Distribution Web Interface are easilyrecognized in today’s increasingly mobile network computingenvironment. As the use of laptops and remote computing grows,end-users are frequently disconnected from their organizations’network.

With Tivoli Software Distribution Web Interface, Web users connectto the server, obtain a current list of available Tivoli SoftwareDistribution profiles, and retrieve necessary profiles at theirconvenience.

Web users can install software package blocks using anindustry-standard Java-enabled Internet browser, such as NetscapeCommunicator

®

or Microsoft Internet Explorer. Packages can bemarked for public access or they can be made visible to all target

10


10.Tivo

liW

ebIn

terface

computers in a subscribing profile manager. Web users are able toaccess packages after authentication according to their Tivoli role.Packages marked for public access can be accessed withoutauthentication. In both cases, Web users are given access to a Webpage displaying the available packages. Web users can install thesepackages by clicking them, which activates a Java applet. The Javaapplet requires granting of special privileges and setting securityoptions in your browser.

If you are using Microsoft Internet Explorer, make sure the securityoptions have been properly configured. A security warning may bedisplayed immediately after you click either the restricted or publiclink from the UserLink for Tivoli access page. Grant all thenecessary access privileges and continue with the selection of adownloadable software package.

If you are using Netscape Communicator, you must enable the Javaand JavaScript advanced options.

The installation takes place in a disconnected mode, and data istransferred through the available HTTP connection. Packageinstallation status is reported to the Tivoli server at the next TivoliSoftware Distribution operation on the target computer, as for otherdisconnected operations.

Not only does this capability free administrators from performingrepeated profile distributions to ensure that each endpoint clientreceives the software, it also provides endpoints access toinformation or software upgrades between scheduled distributions.

With Tivoli Software Distribution Web Interface, the browsercommunicates directly with the server oserv, which forwards therequest to the Tivoli HTTP daemon (HTTPd). The HTTPd processesthe client request and outputs information, in HTML format, aboutavailable Tivoli Software Distribution profiles to which the user issubscribed. This information is then displayed on the client browser.For more information about the HTTPd and networkcommunications, refer to the Tivoli Management FrameworkPlanning for Deployment Guide.

Tivoli Software Distribution Web Interface

276 Version 4.0

Activating Tivoli Software Distribution Web InterfaceEnabling Tivoli Software Distribution Web Interface on an endpointinvolves the following steps:

¶ Setting up preliminary Tivoli Software Distribution WebInterface files on the endpoint—Tivoli Management Frameworkinstalls these files when a client machine is configured as anendpoint.

¶ Installing support for a Tivoli Software Distribution WebInterface authentication realm—Tivoli Software Distributionenables this support when you install Tivoli SoftwareDistribution, Version 4.0, on the TMR server.

¶ Activating user access to Tivoli Software Distribution WebInterface by assigning a Web Interface administration role to aTivoli administrator.

To activate public access, it is recommended that you assign apublic Web Interface administrator. You must use the followinguser 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 TMRserver and the public policy regions.

Creating a Tivoli Administrator for Web InterfaceTo grant Web users network privileges to access Tivoli SoftwareDistribution Web Interface, you must create a Tivoli administratorand add the new SD_Web_User role. Enabling access privilegesallows Web users to securely connect to the TMR server anddownload Tivoli Software Distribution profiles.

After you have installed Tivoli Software Distribution, Version 4.0,you can use either the Tivoli desktop or the command line to createthe Tivoli administrator for Web Interface. When you create thisadministrator, Tivoli Management Framework sets up anadministrator object with access to the Tivoli Software DistributionWeb Interface and enables you to add login names to grant access to

Activating Tivoli Software Distribution Web Interface


10.Tivo

liW

ebIn

terface

authorized users. Note that you can specify login access byindividual user identifications (UID) or by a common UID that youhave set up for a group of users. In either case, you must have avalid set of UIDs for your environment.

The following procedure briefly demonstrates how to create a Tivoliadministrator specifically for Tivoli Software Distribution WebInterface. It also shows how to initialize a list of authorized users forthis Tivoli administrator. See the Tivoli Management FrameworkUser’s Guide for more information about creating and using Tivoliadministrators in your TMR environment.

The following table provides the authorization roles required toperform this task:

Operation Context Role

Create and add usersto the Web Interfaceadministration role

Administratorsresource

senior

DesktopUse the following steps to create the Tivoli Software DistributionWeb Interface administration role:

1. Create a Tivoli administrator for Tivoli Software DistributionWeb Interface.

a. Select Create Administrator from the Administrator iconpop-up menu to display the Create Administrator dialog.

b. Enter the name of the administration role in the AdministratorName/Icon Label text box.

c. Enter a user login name (not a numeric user ID) in the UserLogin Name text box. The user login name must be a validlogin name. To create a public administrator, set the userlogin name to nobody (UNIX machines, except HP-UX), ortmersrvd (Windows NT machines and HP-UX).

d. Enter the administrator’s group name (not a numeric groupID) in the Group Name text box.

Creating a Tivoli Administrator for Web Interface

278 Version 4.0

2. Set the TMR roles for the administrator that you created in step1:

a. Click Set TMR Roles to display the Set TMR Roles dialog.

b. Select the SD_Web_User role from the Available Rolesscrolling list, then click the left arrow. This role is movedfrom the Available Roles scrolling list to the Current Rolesscrolling list.

–OR–

Double-click SD_Web_User in the Available Roles scrollinglist to automatically move it to the Current Roles scrollinglist.

c. Click Set & Close to accept your changes and return to theCreate Administrator dialog.

Note: Tivoli automatically authorizes all users who are assignedthe senior, super, user, and admin roles access to TivoliSoftware Distribution Web Interface. For example, if youhave assigned psmith with the user role, do not add thisuser name in the Set Login Names dialog—psmith will beable to access Web Interface from any system with a validlogin.

3. Set the login names for users who will be able to access TivoliSoftware 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 AddLogin Name text box, then press the Enter key.

Note: The login name must be a valid user ID in yourenvironment. It is recommended that all login namesbe qualified for a specific machine. This helps ensurethe security and integrity of your distributed system bylimiting the locations from which a desktop orcommand line interface (CLI) command may beinitiated.



10.Tivo

liW

ebIn

terface

The new login name is added to the Current Login Namesscrolling list.

c. If you want to add more than one login, repeat this step foreach login that you want to add.

d. Click Set & Close to accept your changes and return to theCreate Administrator dialog.

4. Set the resource role for the administrator that you created instep 1:

a. Click Set Resource Roles to display the Set Resource Rolesdialog.

b. In the Resources list box, select the policy region containingthe software package to be made available from the TivoliSoftware Distribution Web Interface.

c. Select the SD_Web_User role from the Available Rolesscrolling list, then click the left arrow. This role is movedfrom the Available Roles scrolling list to the Current Rolesscrolling list.

–OR–

Double-click SD_Web_User in the Available Roles scrollinglist to automatically move it to the Current Roles scrollinglist. Repeat this procedure for each policy region that containssoftware packages to be made available from the TivoliSoftware Distribution Web Interface.

d. Click Set & Close to accept your changes and return to theCreate Administrator dialog.

Command LineTo use the wcrtadmin command to create a Tivoli administratorspecifically for Tivoli Software Distribution Web Interface, enter thefollowing command:wcrtadmin -l adent -l jchen -l mgarza -l wwarren \-r @distinguished:SDWebUI,SD_Web_User UserLink

where:


280 Version 4.0

–l adent –l jchen –l mgarza –l wwarrenSets up a Tivoli login for each user specified. The loginparameter must be a valid login name—not a numeric userID.

–r @distinguished:SDWebUI,SD_Web_User UserLinkSpecifies the Web Interface for Tivoli Software Distributionadministration role. Enter this parameter exactly as shown toensure that the authorization is set correctly.

To add login names to the Tivoli Software Distribution WebInterface administrator after creating it, enter the followingcommand:wsetadmin -l tford -l ngupta UserLink

where:

–l tford –l nguptaAdds the specified logins

UserLinkSpecifies the name of the Tivoli administrator whoseproperties you want to change

See the Tivoli Management Framework Reference Manual forinformation about wcrtadmin and wsetadmin command syntax andusage. Rather than entering each new login name individuallythrough the Tivoli dialog or with the wsetadmin command, you maywant to create a script to automate this process.

Configuring Policy RegionsThe administrator must define profile managers using appropriatenames for the software categories. The administrator has control overthe content of the Tivoli Software Distribution Web Interface display.It is recommended that you keep the Tivoli Management Frameworkenvironment separate from the Tivoli Software Distribution WebInterface environment by using different policy regions for eachenvironment.

The displayed list is empty until an action is enforced on the policyregions.



10.Tivo

liW

ebIn

terface

Policy regions can be the following types:

Public No access rights are required to view the content of theseregions.

RestrictedOnly users with access rights to restricted regions can viewthe content of restricted policy regions.

HiddenThis is the default. The content of the Hidden policy regionis not accessible through the Tivoli Software DistributionWeb Interface when the Hidden attribute is set.

Software Package PropertiesTo define the availability of a software package through the TivoliSoftware Distribution Web Interface, set the web_view_modeattribute to one of the following values:

Public The software package can be installed on the endpointwhether or not the endpoint is subscribed.

SubscriberThe software package can be installed on the endpoint onlyif the endpoint is subscribed to the profile manager in whichthe software package is defined.

HiddenThis is the default option. A software package is notdisplayed when the attribute is set to Hidden.

The user is presented with a list of software packages for which acomplete image file exists. A complete image file is a package builtin the software package block format. See step 5 on page 119 formore information about setting the Web view mode from thePackage Properties dialog.

Notes:

1. Only software packages in the built format can be made availablethrough the Tivoli Software Distribution Web Interface.


282 Version 4.0

2. Software packages that contain nested software packages cannotbe made available through the Tivoli Software Distribution WebInterface.

Configuring Tivoli Software Distribution WebInterface

The administrator must perform the following procedure to correctlyconfigure 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 tochoose sensible, understandable names for the profile managers,as these names are visible to subscribers.

3. Enable policy regions and their contents for viewing, either bypublic or restricted subscription. Use the CLI to set and view thepolicy region access type attribute and also the software packageobject attribute. For more information about using the CLI to setattributes, refer to the following sections:

¶ “Setting the Policy Region Attribute” on page 284

¶ “Setting the Software Package Object Attribute” on page 284

Note: It is recommended that Tivoli Software Distribution WebInterface be used to provide software upgrades to existinginstalled packages, and also to provide small utilitypackages. Depending on the size of the software packageblock and connection speed, the transfer of files from theserver to the endpoint can potentially be slow.

4. Set the access level for the software package. It is recommendedthat you initially set the access level to Hidden while you verifywhether the package is built. When the package has been built,set the level to Subscriber or Public accordingly.

A login ID and password must be associated with the TMRserver and policy regions involved if the access level is set toRestricted.



10.Tivo

liW

ebIn

terface

Setting the Policy Region AttributeTo use the wwebrset command to set the policy region access typeattribute, enter the following command. Since this command is abash script that must be run in the bash environment, precede thecommand with the string sh:wwebrset regionname accesstype

where:

regionnameIs the name of the policy region for which the access typeattribute is to be set

accesstypeIs one of the following:

¶ Public

¶ Restricted

¶ Hidden

To use the wwebrget command to view the policy region accesstype attribute, enter the following command. Since this command isa bash script that must be run in the bash environment, precede thecommand with the string sh:wwebrget regionname

where:

regionnameIs the name of the policy region for which you want to viewthe access type attribute.

The system displays the access type that is currently set for thespecified policy region, for example:Access type for PolicyRegion test-region is: "Public"

Setting the Software Package Object AttributeTo use the wsetspat command to set the software package objectattribute, enter the following command.wsetspat -v webviewmode @spname

Configuring Tivoli Software Distribution Web Interface

284 Version 4.0

where:

-v webviewmodeSpecifies the value of the web_view_mode attribute, whichspecifies the access permissions for the software package.The following are the possible values:

¶ Public

¶ Subscriber

¶ Hidden (the default)

spnameIs the name of the software package for which you want toset the software package object attribute.

To retrieve the value of the web_view_mode attribute, use thewgetspat -v @spname command. See the Tivoli SoftwareDistribution Reference Manual, Version 4.0 for the command syntaxand arguments of the wsetspat and wgetspat commands.

Using Tivoli Software Distribution Web InterfaceAfter you have created the administrator for Tivoli SoftwareDistribution Web Interface, authorized (or public) Web users canview and download new or updated Tivoli Software Distributionprofiles to which they are subscribed. Each time new softwarepackage profiles are available to Web users, you must instruct themto connect to Tivoli Software Distribution Web Interface.

Web users connect to the Tivoli Software Distribution Web Interfaceby opening the X:\etc\Tivoli\en_US\userlink.htm file with a Web

Configuring Tivoli Software Distribution Web Interface


10.Tivo

liW

ebIn

terface

browser to display the primary UserLink for Tivoli access page.

Note: This illustration shows the English version of the UserLinkfor Tivoli access page. When instructing users to launch theuserlink.htm page, ensure that they are asked to open thecorrect language-specific file. In this case, including theen_US directory in the pathname launches the Englishversion. Opening the X:\etc\Tivoli\jp_JP\userlink.htm file startsthe Japanese version, and so on. See the Tivoli SoftwareDistribution User’s Guide for a current listing of supportedlanguages for this release.

The primary access page loads information for all UserLinkinterfaces to Tivoli applications that are installed on the clientsystem. Tivoli Software Distribution Web Interface is available byclicking either the Public Software Distribution 4.0 Web Interface orRestricted Software Distribution 4.0 Web Interface link. Clicking oneof these links loads the Tivoli Software Distribution Web Interface

Using Tivoli Software Distribution Web Interface

286 Version 4.0

secondary access page.

When a Web user selects the restricted link, the browserauthenticates the login name and password, and if successful, queriesthe server and generates a list of both the restricted and publicprofile managers (software categories). If the Web user selects thePublic link, no authentication is performed and a list of publicsoftware categories is displayed. The Web user can then downloadany of the available profiles in the selected software category.

Notifying Users about Web InterfaceInstruct Web users to complete the following steps to connect to anduse Tivoli Software Distribution Web Interface:

1. Connect to Tivoli Software Distribution Web Interface byopening the X:\etc\Tivoli\en_US\userlink.htm file with a Webbrowser. The primary access page is displayed.

If you have not already bookmarked the Tivoli SoftwareDistribution Web Interface Web page, create a bookmark so thatyou can easily and directly access it.



10.Tivo

liW

ebIn

terface

2. Select the public or restricted link to open the secondary accesspage. This page provides an interface to all Tivoli applicationsthat you are authorized to use.

If you select the restricted link, you must log on using your username and password. Enter your user name and password in thetext boxes. If you are unsure about or need to verify your username and password, contact your system administrator.

The Tivoli Software Distribution 4.0 Web Interface Web page isdisplayed if Tivoli Software Distribution Web Interfacesuccessfully connects to the network.

Note: If you are using Microsoft Internet Explorer, a securitywarning may be displayed requesting permission to grantaccess privileges. Select Yes to grant the access privileges.

3. Select one of the categories from the Software Category list inthe left pane. The list of available software packages for theselected category is listed in the right pane.


288 Version 4.0

The following properties are listed for each software package:

Software PackageThe name of the software package, as defined during itscreation.

VersionThe version of the software package available for you todownload.

Size The size of the software package in bytes. Thisinformation is available to the Tivoli SoftwareDistribution Web Interface browser if your systemadministrator performed an operation to calculatesoftware package size when creating it. Contact yoursystem administrator if this information is not available.

DescriptionA description of each software package available for you



10.Tivo

liW

ebIn

terface

to download. This corresponds to the text entered in theTitle text box illustrated on page 110.

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 softwarepackage is not installed on your computer.

¶ An icon with a green check mark indicates that the softwarepackage is installed on your computer. It is still possible todownload the package, but it will overwrite the currentinstallation.

4. Select the software package that you want to download byclicking either the icon or the software package link in thesoftware package column.

If you click the icon, a message is displayed that asks if you aresure you want to install. Click OK to install, or Cancel to stopthe installation.

If you click the software package name, a window is displayedthat contains details of the software package such as, the size ofthe package, the estimated download time for the speed of theconnection, and a detailed description of the software package.


290 Version 4.0

To download the selected software package, click Install.

The Tivoli Software Distribution Web Interface browser displaysthe Install Java applet and proceeds with the download andinstallation of the selected package.

Note: If you are using Netscape Communicator, two JavaSecurity dialogs are displayed consecutively asking forapproval to grant extra privileges for using the Install Javaapplet to download and install the selected softwarepackage. Click Grant in both cases. The privileges persistuntil the browser is closed.

The Install Java applet dialog displays the ongoing status of theinstallation, then indicates whether the installation completessuccessfully.



10.Tivo

liW

ebIn

terface


292 Version 4.0

Integrating the Tivoli InventoryDatabase

Tivoli Inventory is able to scan the machines in your TMR andgather hardware and software information that it stores in a databasecalled the configuration repository. Tivoli Software Distributionprovides two features that automatically update information stored inthe Tivoli Inventory configuration repository:

¶ Historical database

¶ Change management status

These features store information about Tivoli Software Distribution,Version 4.0 software packages and Tivoli Software Distribution 3.6file packages, AutoPacks, and file package blocks (fpblocks) thathave been installed on or removed from Tivoli clients. The ability toaccess information about these types of objects makes these featuresvery versatile.

Using the Tivoli Management Framework query facility, you canretrieve information from the configuration repository concerningsuccessful or failed Tivoli Software Distribution operations that haveoccurred in your TMR, and the change management status of aparticular software package on a specific target. These two featureseliminate the need to write scripts to periodically update theconfiguration repository when software is distributed or removed inyour Tivoli environment.

11


11.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

This chapter provides a brief conceptual overview of the TivoliManagement Framework query facility and the configurationrepository that Tivoli Software Distribution shares with TivoliInventory. It also describes how to enable the Tivoli SoftwareDistribution historical database and change management statusfeatures and how to access information from the configurationrepository. To use these features, you must have already installed andbe familiar with Tivoli Inventory and the Tivoli ManagementFramework query facility. Refer to the Tivoli Inventory User’s Guideand the Tivoli Management Framework Planning for DeploymentGuide for more information about these products.

The Configuration RepositoryTivoli Inventory and Tivoli Software Distribution store informationin the configuration repository, which is a relational databasemanagement system (RDBMS) that holds information about systemconfigurations in your Tivoli environment. Tivoli Inventory providesthe scripts necessary to create the configuration repository as well asto install the configuration repository schema.

Tivoli Inventory must be installed before information aboutdistributions can be stored in the configuration repository. TivoliSoftware Distribution updates the configuration repository with newor updated information about software packages, file packages,AutoPacks, and fpblocks that have been distributed to targetmachines in your environment, and organizes this information invarious tables.

Note: The configuration repository is separate from the actual Tivoliobject database. For more information about the configurationrepository, refer to the Tivoli Management FrameworkPlanning for Deployment Guide and the Tivoli InventoryUser’s Guide.

294 Version 4.0

The Query FacilityThe Tivoli Management Framework query facility, which consists ofquery libraries and queries, enables you to use Structured QueryLanguage (SQL) query functions to access information stored in theconfiguration repository. In the Tivoli environment, a query library isused to create and manage Tivoli queries, which specify which viewor table to search within the repository and what information toretrieve. A view enables you to access information from one or moretables, and consists of derived instances from a single table or fromthe relational joining of multiple tables.

Tivoli Inventory has several predefined views and queries that youcan use to access information from the configuration repositorywithout having to create a specific query library or individualqueries. Tivoli Software Distribution provides a script to populate aunique query library, SWDIST_QUERIES, with predefined views,tables, and queries. For more information about the query library andqueries, refer to the Tivoli Management Framework Planning forDeployment Guide and the Tivoli Inventory User’s Guide.

Updating the RepositoryTivoli Software Distribution stores and updates information in thefollowing tables in the configuration repository:

INSTALLED_SW_COMPONENTStores the history of operations. Specifically, it storesinformation about the target machine on which an operationor action was performed (such as install, remove, undo,accept, commit), the type and mode of the operation, thetime at which this operation occurred, the name of theprofile that was distributed, the last known state of thesoftware package on a target machine, and the result of theoperation. A new column, MD2_DIST_ID, has been added tothis table which stores a distribution ID for each softwarepackage distribution.

The Configuration Repository


11.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

SOFTWARE_COMPONENTStores information about software names and versions thathave been distributed, and links this information to profileidentifications.

SOFTWARE_FILEPACKStores information about software package files and relatesthis information to a software package, file package,AutoPack, or file package block and the source host.

Each of these tables is updated after a successful or unsuccessfuloperation. Note, however, that not all columns in these tables arenecessarily updated after an operation. You can retrieve informationfrom these tables about the results of specific distribution attemptsby running the query SWDISTDATA_QUERY against the predefinedview SWDISTDATA_VIEW.

SD_CM_STATUSStores information about the names and versions of softwarepackages, the time the last successful action or operation wasperformed on a software package, and the status of asoftware package on a particular target machine.

The SD_CM_STATUS table is updated only after a successfuloperation. Running the CM_STATUS_QUERY retrieves softwarepackage status information directly from the SD_CM_STATUS tableand not through the use of a predefined view.

It is possible that the state registered in the SD_CM_STATUS tableof a software package on a particular target machine is not consistentwith the status recorded in the local target catalog of the samesoftware package. This inconsistency occurs when an operation isperformed using a disconnected command line command. Refer tothe Tivoli Software Distribution Reference Manual, Version 4.0 formore information about disconnected target commands. In this case,the endpoint returns an error to the server signalling a discrepancyand updates the SD_CM_STATUS table with the correct state.

Information about the Tivoli Software Distribution view, query, andtables is provided in the Tivoli Inventory User’s Guide. Tivoli


296 Version 4.0

Inventory also provides the Tivoli Inventory ConfigurationRepository schematic poster, which illustrates table and columnassociations in the configuration repository.

Upgrading from Tivoli Inventory, Version 3.6 or LaterTo upgrade the Tivoli Inventory database from Version 3.6 or later,after installing the Historical Database component, run one of thefollowing scripts, depending on the database you are using. Thesescripts are found in the $BINDIR/TME/SWDIS/SCRIPTS/ directory.

¶ swdis_db2_upgrade.sql (for DB2)

¶ swdis_ms_sql_upgrade.sql (for Microsoft SQL Server)

¶ swdis_ora_upgrade.sql (for Oracle)

¶ swdis_syb_upgrade.sql (for Sybase)

Running these scripts adds a new text box called state to theINSTALLED_SW_COMPONENT inventory table, changes theexisting view to handle this new text box, and creates a new viewrelated to the SD_CM_STATUS inventory table.

The steps for upgrading each type of database are listed in thefollowing sections.

Upgrading a DB2 DatabaseComplete the following steps to run the swdis_db2_upgrade.sqlscript, which upgrades the DB2 database:

1. Copy the swdis_db2_upgrade.sql script from the \scripts productdirectory to a temporary directory in which you can run DB2 onthe DB2 server or the RDBMS Interface Module (RIM) host.

2. Create a connection to the DB2 server database before runningthe script. Issue the following command from the command line:db2 connect to <database_name> user <user_name> \using <password>

where:



11.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

database_nameSpecifies the name or alias name of the Tivoli Inventorydatabase.

user_nameSpecifies the name of the user who owns the TivoliInventory database.

passwordSpecifies the password of the user referred to byuser_name.

3. Run the swdis_db2_upgrade.sql script from the command line.Enter the following command:db2 -f swdis_db2_upgrade.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 thisfile.

Upgrading a SQL Server DatabaseComplete the following steps to run the swdis_ms_sql_upgrade.sqlscript, which upgrades the SQL Server database. You must run thescript as the RDBMS user tivoli.

1. Copy the swdis_ms_sql_upgrade.sql script from the \scriptsproduct directory to a temporary directory in which you can runisql on the RIM host or the RDBMS server.

2. From the directory that now contains the script, run theswdis_ms_sql_upgrade.sql script as user tivoli. Enter thefollowing command, where password is the RDBMS passwordthat is set for the SQL Server user tivoli:isql -U tivoli [-P <password>] \-i swdis_ms_sql_upgrade.sql -o swdis_ms_sql_upgrade.log

The output of the script (that is, the success or failure of theSQL statements) is logged to the swdis_ms_sql_upgrade.log file.

Upgrading from Tivoli Inventory, Version 3.6 or Later

298 Version 4.0

Upgrading an Oracle DatabaseComplete the following steps to run the swdis_ora_upgrade.sqlscript, which updates the Oracle database. You must run the script asthe RDBMS user tivoli.

1. Copy the swdis_ora_upgrade.sql script from the \scripts productdirectory to a temporary directory on the RDBMS server or theRIM host.

2. From the directory that now contains the script, start anSQL*Plus session and log in to the RDBMS server as theRDBMS user tivoli. Enter the following command, wherepassword is the RDBMS password that is set for the Oracle usertivoli:sqlplus tivoli/<password>

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 swdis_ora_upgrade.sql script byentering the following command:@swdis_ora_upgrade.sql

The success or failure of the SQL statements is logged in the logfile.

5. To log out of SQL*Plus, when the script is finished, enter thefollowing command:quit

Upgrading a Sybase DatabaseComplete the following steps to run the swdis_syb_upgrade.sqlscript, which updates the Sybase database. You must run the script asthe RDBMS user tivoli.

1. Copy the swdis_syb_upgrade.sql script from the \scripts productdirectory to a temporary directory in which you can run isql onthe RDBMS server or the RIM host.

2. From the directory that now contains the script, run theswdis_syb_upgrade.sql script as the user tivoli. Enter the



11.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

following command, where password is the RDBMS passwordthat is set for the Sybase user tivoli:isql -U tivoli -P <password> -i swdis_syb_upgrade.sql \-o swdis_syb_upgrade.log

The output of running the script is stored in theswdis_syb_upgrade.log file.

Enabling the Historical Database and ChangeManagement Status Features

With the installation of the Tivoli Software Distribution HistoricalDatabase component, the historical database and change managementstatus features are automatically enabled, which enables TivoliSoftware Distribution to access and update the configurationrepository. These features are already available if you installed theTivoli Software Distribution Historical Database component from theInstall Product dialog during the initial installation process. Refer tothe Tivoli Enterprise Installation Guide for instructions if you havenot yet installed the historical database component.

Note: The historical database and change management featuresrequire Tivoli Inventory. You must already have TivoliInventory installed to complete the following procedures.

Before Tivoli Software Distribution information about targetmachines can be stored in the configuration repository, you must runan inventory hardware scan on each target machine that will receivesoftware packages, file packages, AutoPacks, and fpblockdistributions. An inventory profile scans each target machine andpopulates the configuration repository with new or updatedinformation about each target.

Complete the following steps on any target machines that willreceive software package, file package, AutoPack, and fpblockdistributions, but have not been scanned:

1. Create an inventory profile. The Tivoli Inventory User’s Guidedescribes how to create an inventory profile.


300 Version 4.0

2. Customize the inventory profile to include only a hardware scan.By default, an inventory profile scans the target machine for bothsoftware and hardware information. To track Tivoli SoftwareDistribution operations, however, only a hardware scan is needed,and customizing the profile to scan only for hardwareconfiguration data will save time. The Tivoli Inventory User’sGuide describes how to customize an inventory profile.

3. Distribute the inventory profile to each target machine that willreceive software packages, file packages, AutoPacks, andfpblocks. For Tivoli Software Distribution purposes, only thosetarget machines for which you want to track distributioninformation need be scanned. The Tivoli Inventory User’s Guidedescribes how to distribute an inventory profile to targetmachines.

Disabling the Historical Database and ChangeManagement Status Features

You can disable and then enable the historical database and changemanagement status features from the command line to control whendistribution information is posted to the configuration repository. Thefeature is automatically enabled when you install the Tivoli SoftwareDistribution Historical Database component. It is recommended thatyou disable these features prior to deploying a file package forwhich you do not want to track distribution statistics. Re-enable thefeatures to resume tracking distribution information in theconfiguration repository.

The following table provides the authorization role required toperform this task:

Operation Context Required Role

Disabling andre-enabling thehistorical database andchange managementstatus features

Command line senior or super

Historical Database and Change Management Features


11.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

You can perform this task only from the command line. Enter thefollowing command:sh wswsprim {-c|-d|-s|-v}

where:

–c Re-enables the historical database and change managementstatus features.

–d Disables the historical database and change managementstatus features.

–s Enables the change management status feature andautomatically disables the historical database feature with theexecution of this command.

–v Gives the status of the historical and change managementstatus features.

It is not possible to have the historical database feature enabled andthe change management status feature disabled simultaneously. Youcan, however, choose to have only the change management statusfeature enabled. For more information about wswsprim commandusage and syntax, refer to the Tivoli Software Distribution ReferenceManual, Version 4.0.

Creating the SWDIST_QUERIES Query LibraryIn the Tivoli environment, a query library facility provides a way tocreate, manage, and logically organize Tivoli queries. For example,you could create a query library to hold queries that selectivelyretrieve information about each Tivoli Software Distribution profiletype. Tivoli Software Distribution provides a script,swdis_queries.sh, that you can run to automatically install a querylibrary and two predefined queries. This script creates theSWDIST_QUERIES query library and populates it with thepredefined queries SWDISTDATA_QUERY andCM_STATUS_QUERY.

Run the swdis_queries.sh script in the TMR from which you want toquery the configuration repository. Because queries and query

Historical Database and Change Management Features

302 Version 4.0

libraries must have unique names in a TMR, you can have only oneset of the Tivoli Software Distribution queries in a TMR or in a setof interconnected TMRs. For information about creating additionalquery libraries and queries, refer to the Tivoli Inventory User’sGuide.

The following table provides the authorization roles required toperform this task:


Create Tivoli SoftwareDistribution queries

Policy region senior or super

Complete the following steps to create the SWDIST_QUERIESquery library and the Tivoli Software Distribution query:

1. Select the policy region in which you want to create the querylibrary that will contain the Tivoli Software Distribution queries.

2. Add the QueryLibrary managed resource type to the policyregion. Refer to the Tivoli Management Framework Planning forDeployment Guide for more information about adding managedresources to a policy region.

3. Copy the swdis_queries.sh script from the$BINDIR/TME/SWDIS/SCRIPTS/ directory on the TMR serverto a temporary directory.

4. From the directory in which the script now resides, log in as aTivoli administrator.

5. Run the swdis_queries.sh script by entering the following:swdis_queries.sh region name

where:

region Specifies the name of the policy region in which thequery library will be created.

name Specifies the name of the new query library. Specifying aname here is optional; if you do not designate a name,the query library will be named SWDIST_QUERIES.

Creating the SWDIST_QUERIES Query Library


11.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

The new query library is added in the designated policy region asfollows:

Running SWDISTDATA_QUERYThe following steps briefly describe the process of running a queryfrom the SWDIST_QUERIES query library and of saving the queryresults to standard output or a file.



Run a query Query library senior or super

You can perform this task from either the Tivoli desktop or thecommand line.

DesktopComplete the following steps to run the predefined querySWDISTDATA_QUERY from the SWDIST_QUERIES querylibrary. (The steps for running the CM_STATUS_QUERY predefinedquery, which also appears in these dialog examples, are similar.)

Creating the SWDIST_QUERIES Query Library

304 Version 4.0

1. Double-click the SWDIST_QUERIES query library icon todisplay the SWDIST_QUERIES dialog. This query librarycontains the predefined query SWDISTDATA_QUERY. Thefollowing query library dialog displays:

2. To run this query, right-click the SWDISTDATA_QUERY iconand select Run Query.

–OR–

Right-click the SWDISTDATA_QUERY icon and select EditQuery to open the Edit Query dialog. From this dialog, clickRun Query.

The Run Query dialog is displayed, showing the results of theSWDISTDATA_QUERY in tabular form. The following dialogillustrates a portion of the results that are displayed:

Running SWDISTDATA_QUERY


11.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

3. You can save the results of the query from the Run Query dialogby completing the following steps:

a. On the Run Query dialog, click Export. The Export QueryResults dialog is displayed.

b. In the Host text box, enter the name of the machine on whichyou would like to save the results file. If you do not specifya host name, the file will be saved on the local machine.

c. In the File text box, enter a directory and name for the queryresults file.

–OR–

Click browse (...) to browse the file system.

d. Select one of the Delimiter options to specify how to separateentries in the query results file. If you want to use a delimiterother than a comma or a tab, select Custom and enter adelimiter in the text box.

e. Select the Print Headers check box if you want the outputfile to include the query name and the names of the columns.

f. Click Save & Close to create the file.


306 Version 4.0

Command LineYou can use the wrunquery command to runSWDISTDATA_QUERY and either display the results to standardoutput or save the results to a file. Enter the following from thecommand line:wrunquery -n -h pescado -f /tmp/query.txt -d ";" / SWDISTDATA_QUERY

where:

–n Omits headers from the results file.

–h pescadoSpecifies pescado as the name of the machine on which tostore the file.

–f /tmp/query.txtSpecifies /tmp/query.txt as the location and name of thequery results file.

–-d ″;″Specifies a semicolon as the delimiter.

SWDISTDATA_QUERYSpecifies the name of the query to be run.

For more information about the wrunquery command, refer to theTivoli Inventory User’s Guide.

Modifying SWDISTDATA_QUERYAs illustrated in the Run Query dialog shown on page 305,SWDISTDATA_QUERY retrieves and posts an extensive list ofTivoli Software Distribution information that includes data aboutmachine name and identification, profile type and identification,source host name, whether the operation completed successfully, andthe time of completion.

You can also create a customized query based on the parametersdefined in SWDISTDATA_QUERY. Customizing a query enablesyou to search for more specific information concerning softwaredistributions and removals in your Tivoli environment. An example



11.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

of how to create a custom query follows. The Tivoli Inventory User’sGuide provides detailed descriptions of how to create, edit, and runqueries.

The following example in this section briefly demonstrates how tocreate a new query that retrieves information about software packageinstallations using the force option. Several of the parameters inSWDISTDATA_QUERY are used in setting up this customizedquery. To keep the example brief, only text boxes that are specific tocustomizing this search are described. Refer to the Tivoli InventoryUser’s Guide for more detailed instructions and examples.



Edit a query Query library senior or super

You can perform this task from either the Tivoli desktop or thecommand line. (The steps for editing the CM_STATUS_QUERYpredefined query, which also appears in these dialog examples, aresimilar.)

DesktopComplete the following steps to edit SWDISTDATA_QUERY fromthe Tivoli desktop:

Modifying SWDISTDATA_QUERY

308 Version 4.0

1. In the SWDIST_QUERIES query library, select Query from theCreate menu. The Create Query dialog is displayed.

2. In the Query Name text box, enter Software Packages.

3. In the Description text box, enter Information on softwarepackages installed.

4. Select inventory from the Repository menu.

5. In the Table/View Name text box, enter SWDISTDATA_VIEWand click Set. Doing this populates the Available Columns textbox.



11.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

6. Use the left arrow to move the following columns from theAvailable Columns scrolling list to the Chosen Columns scrollinglist:

¶ TME_OBJECT_LABEL

¶ SOFTWARE_COMPONENT_NAME

¶ INSTALLED_FILEPACK_TIME

¶ MD2_DIST_ID

7. To create the SQL statement to query for software packageinstallations that use the force option, complete the followingsteps 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_TYPEfrom the list of column names. This list displays the columnsin the Chosen Columns scrolling list.

b. Leave equals (=) as the logical operator.

c. Click browse (...) in the Column Value section. SelectSOFTWARE_PACKAGE, then click Close.

d. Click Add to add the first criteria to the Where Clause textbox.

e. In the Column Name text box, enterACTION_COMPLETED.

f. In the Column Value text box, enter install (f).

g. Click Add to add the second criteria to the Where Clausetext box. The Create Query dialog appears as follows:


310 Version 4.0

8. Click Create to save the query. Click Run Query to query fromthis dialog.

–OR–

Click Create & Close to return to the query library window.Right-click the SWDIST_Software_Package icon and click RunQuery. Tivoli Inventory returns the following results:



11.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

Command LineThe following example creates theSOFTWARE_PACKAGE_INSTALLATIONS query from thecommand 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 theTivoli Inventory User’s Guide.


312 Version 4.0

Integrating the Tivoli EnterpriseConsole

Tivoli Software Distribution for Software Packages TEC Integrationenables Tivoli Software Distribution to send events to the TivoliEnterprise Console (TEC) event server when a Tivoli SoftwareDistribution operation is performed. In the Tivoli environment, anevent is classified as any significant change in the state of a systemresource, network resource, or network application. After the TECintegration product is installed, Tivoli Software Distributionautomatically generates events based on its operations such assuccessful or failed distributions or change management operations,and sends these events to the TEC event server. This provides ameans for centrally collecting Tivoli Software Distribution eventsand triggering actions that can be handled the same way as eventsfrom other sources or even be correlated with other events.

This chapter explains how to install and enable the Tivoli SoftwareDistribution TEC Integration product component. It also provides adescription of the Tivoli Software Distribution event configurationfile and event classes. You must be familiar with the TivoliEnterprise Console application and its manuals, specifically theTivoli Enterprise Console User’s Guide and the Tivoli EnterpriseConsole Adapters Guide. These materials provide conceptual andinstructional information about events, event adapters, and classes.

12


12.In

tegratin

gth

eTivo

liE

nterp

riseC

on

sole

InstallationTo install and use the Tivoli Software Distribution TEC Integration,Version 4.0 component, you must first have Tivoli SoftwareDistribution, Tivoli Enterprise Console, and the Tivoli EnterpriseConsole Server installed in your TMR. If you are upgrading theseproducts from a previous version, you also must upgrade theRDBMS database installation. Installing a current version of TivoliEnterprise Console without updating the database may lead toproblems with viewing events in the event console. Refer to theTivoli Enterprise Console User’s Guide for more information aboutinstalling and using the enterprise server and console, and aboutupgrading the RDBMS database.

Before installing and using Tivoli Software Distribution TECIntegration, you must create an event console on the Tivoli desktop,as follows:

1. From the Tivoli desktop, select Event Console from the Createmenu. The Create Event Console dialog is displayed.

2. Select the event server on which the event console will residefrom the Available Hosts scrolling list, then click Create. Anevent console icon is placed on the desktop.

Complete the following steps to install and use Tivoli SoftwareDistribution TEC Integration:

Integrating the Tivoli Enterprise Console

314 Version 4.0

1. Follow the directions described in “Planning and Installing TivoliSoftware Distribution” on page 21 to install the Tivoli SoftwareDistribution TEC Integration, Version 4.0 component on theevent server in the TMR.

Installing the Tivoli Software Distribution TEC Integrationcomponent copies the tecad_sdnew.baroc file, located in the$BINDIR/TME/SWDIS/SPO directory, to the host machine. TheTivoli Software Distribution event classes are defined in this file.See “Tivoli Software Distribution Classes” on page 320 for moreinformation about Tivoli Software Distribution event classes.

2. To set a rule base to manage events and to install the TivoliSoftware Distribution event classes to the TEC event server, runthe swdistecsrvr_inst.sh script on the server where thetecad_sdnew.baroc file is located. The swdistecsrvr_inst.sh scriptis located in the $BINDIR/TME/SWDIS/SCRIPTS directory. Torun the script, enter the following:swdistecsrvr_inst.sh –b <rule_base> –c <directory>

where:

–b <rule_base>Is a rule base, other than the default rule base, that iscreated and includes the Tivoli Software Distributionclasses.

–c <directory_name>Specifies an existing empty directory that is used as aworking directory.

3. Edit the tecad_sd.conf file as follows to include the eventserver’s name and any event filtering instructions. This file isinstalled with Tivoli Software Distribution and is located in the$BINDIR/TME/SWDIS/SPO directory.######################################################### Configuration file for Software Distribution 4.0#########################################################



12.In

tegratin

gth

eTivo

liE

nterp

riseC

on

sole

# Put the event server location hereServerLocation=@EventServerConnectionMode=connection_orientedServerPort=0

The tecad_sd.conf file is discussed in greater detail in “Thetecad_sd.conf File” on page 318.

4. Select Assign Event Groups from the event console’s iconmenu. The Assign Event Groups dialog is displayed.

a. Ensure that the Software Distribution 4.0 event group is listedin the Assigned Event Groups scrolling list. To move thisevent group, select Software Distribution 4.0 from theUnassigned Event Groups list and click the right arrow.

b. Highlight the Software Distribution 4.0 event group in theAssigned Event Group scrolling list and choose theappropriate administration roles. Click Set & Close to saveand close this dialog.

5. To view the events sent to this event console, select Monitorfrom the event console’s icon menu. The Tivoli EnterpriseConsole window containing the Software Distribution 4.0 eventsource is displayed.


316 Version 4.0

6. To view the event notices, click the Software Distribution 4.0event group button. The Software Distribution 4.0 window isdisplayed.



12.In

tegratin

gth

eTivo

liE

nterp

riseC

on

sole

The Software Distribution 4.0 window lists all Tivoli SoftwareDistribution 4.0 events in the scrolling list. These events aredescribed fully in “Tivoli Software Distribution Classes” onpage 320.

The tecad_sd.conf FileThe tecad_sd.conf configuration file for the Tivoli SoftwareDistribution TEC Integration component initially has the followingdefault entries:ServerLocation=ConnectionMode=connection_orientedServerPort=0

The keywords are as follows:

ServerLocationSpecifies the keyword @EventServer or a fully qualifiedidentifier if multiple TEC servers are running in aninterconnected TMR environment. You must set the value ofthis field after installing Tivoli Software Distribution. Toobtain the event server identifier, enter the followingcommand from the command line:wlookup -ar EventServer

Refer to the Tivoli Management Framework ReferenceManual for more information about the wlookup command.

ConnectionModeSpecifies the connection mode to use to connect to the eventserver. Valid values are connection_oriented (or itsabbreviations CO and co) and connection_less. The defaultvalue is connection_oriented, which specifies that theconnection with the event server is maintained for all eventssent. A new connection is established only if the initialconnection is lost.

When connection_less is specified or used by default, a newconnection is established (and discarded) for each event thatis sent.


318 Version 4.0

ServerPortSpecifies the fixed reception port number on which the TECserver listens for connection and adapter input. This keywordvalue should be set to 0 (the default value) on UNIXsystems unless the portmapper is not available on the server.

If the TEC server is a Windows NT system, the ServerPortshould be set to the value of the tec_recv_agent_port entry inthe .tec_config file. Refer to the Tivoli Enterprise ConsoleAdapters Guide for more information about the server portspecification on Windows NT machines. If the port numberis not specified, the value is retrieved by calling theportmapper.

ServerPort can contain up to eight values, separated bycommas. Specify one port number regardless of the numberof ServerLocation values specified; however, if you specifymore than one port number, you must specify acorresponding port number for each ServerLocation value.The default is 0.

By default, Tivoli Software Distribution sends all events to the eventserver. You can optionally specify event filters that indicate whichevents should not be sent. You can specify as many event filterentries as needed. To do so, you can include a Filter entry in thetecad_sd.conf file, as follows:

Filter

Specifies how events are filtered. Filter statements are usedby the FilterMode entry to determine which events should bediscarded. An event matches a Filter statement if eachslot=value in the Filter statement is identical to thecorresponding slot=value in the event. A Filter statementmust contain the event class and can include any otherslot=value that is defined for the event class. The format ofthe 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



12.In

tegratin

gth

eTivo

liE

nterp

riseC

on

sole

contain spaces. The class name specified for an event filterentry must match a defined class name. See “Tivoli SoftwareDistribution Classes” for a listing of classes for TivoliSoftware Distribution.

For example, you can include the following entry in thetecad_sd.conf file to discard all events generated when the removaloperation begins.Filter:Class=Remove_Start;

The filtering behavior can be modified by using the environmentvariable FilterMode. By default, FilterMode is set to OUT. Byadding FilterMode=IN to the configuration file, only the events thatmatch the filters are delivered to the event server. Refer to the TivoliEnterprise Console Adapters Guide for detailed information aboutfiltering.

If you make any changes to the tecad_sd.conf file, you must stopand restart the event server for the changes to take effect.

Tivoli Software Distribution ClassesThe following table lists the class name of all events defined byTivoli Software Distribution. Specifically, these classes are definedin the tecad_sdnew.baroc file. When you install the Tivoli SoftwareDistribution TEC Integration component and run theswdistecsrvr_inst.sh script, these classes are compiled and includedin the event server’s rule base. Use this listing to understand howTivoli Software Distribution events are mapped to Tivoli EnterpriseConsole events.

Note: This list of classes is provided for reference only. Do not editthe 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 moreinformation about the syntax of .baroc files.


320 Version 4.0

Event Slots Notes

SD_Operation_Submitted dist_idsp_nameop_sizeop_ mode

By default, severity =HARMLESS and sub_source= swdist.

SD_Operation_Started dist_idsp_nameop_sizeop_ mode


SD_Operation_Failed dist_idsp_nameop_sizeop_ modemessagenum_targetsfailed_targets

By default, severity = FATALand sub_source = swdist.

SD_Operation_Sucessful dist_idsp_nameop_sizeop_ modemessagenum_targetssuccessful_targets


SD_Operation_More_Targets dist_idsp_namesuccessful_targetsfailed_targetssp_name

This class is used when thetarget_list in any class causesthe event to exceed 4 KB.This event is generated untilthe list of targets is complete.By default, severity =HARMLESS and sub_source= swdist.

SD_Operation_Some_Failed dist_idsp_nameop_sizeop_ modemessagenum_targetssuccessful_targetsfailed_targets

By default, severity = MINORand sub_source = swdist.



12.In

tegratin

gth

eTivo

liE

nterp

riseC

on

sole


322 Version 4.0

Upgrading Windows NT 4.0 withService Pack 5 or 6

This scenario explains how to use Tivoli Software Distribution,Version 4.0 to upgrade a Windows NT 4.0 system to Service Pack 5or Service Pack 6.

This scenario consists of the following procedures:

¶ Downloading the ntspx.spd definition file to the TMR server

¶ Copying the Service Pack files to the image server

¶ Customizing the ntspx.spd software package definition File

¶ Creating the software package on the TMR server

¶ Subscribing the endpoints to the upgrades profile manager

¶ Distributing the software package to the Tivoli SoftwareDistribution endpoints

Environment ConfigurationTo complete this scenario, you must have the following environment:

¶ A TMR server on which to prepare and pack the softwarepackage files.

¶ An image server on which to store the Service Pack files. In thisscenario, the image server is a Windows NT workstation.

13


13.U

pg

radin

gW

ind

ow

sN

Tw

itha

Service

Pack

¶ The target workstations with Windows NT 4.0 installed. Youmust define the target workstations as Tivoli SoftwareDistribution endpoints.

Downloading the ntspx.spd Definition File to theTMR Server

Note: Depending on which Service Pack you are installing,substitute the x variable either with 5 (for Service Pack 5) or6 (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 TivoliSoftware Distribution, Version 4.0 CD-ROM. To download thentspx.spd definition file from the CD-ROM to the TMR Server,perform the following steps on the TMR 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 fromCD-ROM_drive/package/msosupg/nt40srvpack directory tothe /servpackx directory on your TMR server, by entering thefollowing command from the /servpackx directory:cp <CD-ROM_drive>:/package/msosupg/nt40srvpack/ntspx.spd

¶ For Windows, copy the file from theCD-ROM_drive:\package\msosupg\nt40srvpack directory tothe <drive>\servpackx directory on your TMR server byentering the following command from the <drive>\servpackxdirectory:copy <CD-ROM_drive>:/package\msosupg\nt40srvpack\ntspx.spd

The ntspx.spd file is downloaded to the TMR server.

Upgrading Windows NT 4.0 with Service Pack 5 or 6

324 Version 4.0

Copying the Service Pack Files to the Image ServerTo copy the Service Pack files to the image server, follow thesesteps:

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, selectSystem→CurrentControlSet→Services→LanmanServer→Parameters→NullSessionShares.

4. Select NullSessionShares.The Multi-String Editor dialogdisplays.

5. Enter shared and click OK.

6. Share the c:\shared directory with the target workstations thatyou want to upgrade from Windows NT 4.0 to Windows NT 4.0with Service Pack by entering the following command:net share shared=c:\shared

7. Copy the spxi386.exe Service Pack executable file to thec:\shared\wint40sp directory previously created on the imageserver.

8. Extract the Service Pack files by entering the followingcommand:spxi386.exe /x

The Choose Directory for Extracting Files dialog appears.

9. Enter c:\shared\spx in the Choose Directory for Extracting Filestext box. The c:\shared\spx directory is the image server directoryfrom which you extract the Service Pack files.



13.U

pg

radin

gW

ind

ow

sN

Tw

itha

Service

Pack

Customizing the ntspx.spd Software PackageDefinition File

Customize the ntspx.spd software package definition file byspecifying \\ImageServer\shared in the sp_path variable, whereImageServer is the name of the server where the image is located.

The ntspx.spd software package definition file follows:#TIVOLI Software Package v4.0 - SPDFPackage

Name = "ntspx"Title = "Install Service Pack for Windows NT 4.0"Copyright = "Tivoli Software Distribution Systems"Version = 1.0undoable = “o”committable = “o”history_reset = nsave_default_variables =ncreation_time = “2000-02-02 18:10:19”last_modification_time = “2000-02-02 128:14:08”default_variablessp_path = “\\ImageServer\shared”

endmove_removing_host =yno_check_source_host =ylenient_distribution = ndefault_operation = “install”server_mode = “all”log_mode = “0”log_user_id “0”post_notice = nbefore_as_uid =0skip_non_zero = nafter_as_uid = 0no_chk_on_rm = nlog_gid = 0stop_on_failure = y

execute_user_programtransactional = n

during_install

exit codessuccess = 0,0failure = 1,65535end


326 Version 4.0

path = ”$(sp_path)\spx\update\update.exe”arguments = “-u -f -o -q”

timeout = 2400unix_user_id = 0unix_group_id = 0user_input_required = nreporting_stdout_on_server = yreporting_stderr_on_server = ymax_stdout_size = 10000max_stderr_size = 10000bootable = yretry=1

corequisite_filesend

end

This table explains the meaning of the argument values that you canspecify 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 uninstalloperation.

o Overwrites the OEM files without prompting.

z Does not reboot when the installation iscomplete.

q Quiet mode. The installation does not requireany user intervention.

Creating the Software Package on the TMR ServerBefore creating a software package, you must create on the TMRserver a profile manager that contains the software package and adirectory path in which to store the software package block. See theTivoli Management Framework Planning and Deployment Guide,Version 4.0 to learn how to create a profile manager. This scenario



13.U

pg

radin

gW

ind

ow

sN

Tw

itha

Service

Pack

assumes that you created the upgrades profile manager and thepackages directory path in which to store the ntspx.spb softwarepackage block in the TMR server.

To create and build the software package on the TMR server, enterthe 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 -pc:\packages\ntspx.spb @ntspx^^1.0

This command does the following:

¶ Creates the ntspx^1.0 software package object that is based onthe 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 ProfileManager

Subscribe the Tivoli Software Distribution endpoints to the Upgradesprofile manager by entering the following command from the TMRserver:wsub @upgrades @Endpoint:target1 @Endpoint:target2 ... @Endpoint:targetn

Where target1, target2, ..., targetn are the Tivoli SoftwareDistribution endpoints that you want to subscribe.


328 Version 4.0

Distributing the Software Package to the TivoliSoftware Distribution Endpoints

To distribute the software package to the Tivoli SoftwareDistribution endpoints, enter the following command from the TMRserver:

¶ 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 SoftwareDistribution endpoints on which you want to install Service Pack.You can also create a profile manager that contains all the targets toupgrade and specify the name of the profile manager in the winstspcommand. For example, in a Windows environment, if you createdthe win_targets profile manager, enter the following command:winstsp @ntspx^^1.0 @win_targets

After you enter one of the previous commands, the upgrade processstarts on the Tivoli Software Distribution endpoints. When thedistribution of the software package ends, the targets reboot.



13.U

pg

radin

gW

ind

ow

sN

Tw

itha

Service

Pack

330 Version 4.0

Upgrading Windows 95 toWindows 98 Second Edition

This scenario explains how to use Tivoli Software Distribution,Version 4.0 to upgrade a Windows 95 system to a Windows 98Second Edition system.


¶ Creating a response file appropriate for your environment

¶ Copying the files that you need to perform the migration to theTMR server

¶ Copying the Windows 98 files to the image server

¶ Customizing the inst_W98SE.spd software package definitionfile



¶ Distributing the software package to the Tivoli endpoints

¶ Using the check_OS.spd software package definition file toverify the upgrade


14


14.U

pg

radin

gW

ind

ow

s95

toW

ind

ow

s98

¶ A Windows 98 Second Edition workstation with the ResourceKit 98 installed.

¶ A TMR server on which to prepare and pack the softwarepackage.

¶ An image server on which to store the Windows 98 operatingsystem files.

¶ The target workstations with Windows 95 installed. You mustdefine the target workstations as Tivoli Software Distributionendpoints.

Creating a Response File

Note: Refer to the Microsoft Windows 98 Second Edition ResourceKit documentation for a detailed explanation of the procedurefor creating a response file.

Tivoli Software Distribution, Version 4.0 provides two examples ofresponse files that you must customize to suit your environment.Create the response files appropriate for your environment using theMicrosoft Batch 98 tool or customize the S_upgW98.inf and theD_upgW98.inf response files stored in theCD-ROM_drive:\package\msosupg\upgrW95toW98 directory.S_upgW98.inf is an example of response file that you can use toupgrade workstations with static IP addresses. D_upgW98.inf is anexample of response file that you can use to upgrade workstationswith Dynamic Host Configuration Protocol (DHCP) addresses.If youare upgrading an environment that has workstations that use staticaddresses, you must create a response file for each workstation toupgrade specifying the appropriate workstation IP address in eachresponse file.

Copying the Files That You Need to Perform theMigration to the TMR Server

To perform the migration from Windows 95 to Windows 98 SecondEdition, you must copy the following files that are contained in theTivoli Software Distribution, Version 4.0 CD-ROM to the TMRserver:

Upgrading Windows 95 to Windows 98 Second Edition

332 Version 4.0

¶ inst_W98SE.spd

¶ S_upgW98.inf, D_upgW98SE.inf

Note: You can use the response file that you created “Creating aResponse File” on page 332 instead of this file.

¶ logonyes.reg

¶ check_OS.spd

To copy the files from the CD-ROM to the TMR Server, perform thefollowing steps on the TMR server:

1. Create a directory in which to store the files. This scenario usesthe upg95_98 directory.

2. Copy the inst_W98SE.spd, the S_upgW98.inf, D_upgW98SE.infand the logonyes.reg files:

¶ For UNIX, copy the files fromCD-ROM_drive/package/msosupg/upgrW95toW98 directoryto the /upg95_98 directory on your TMR server by enteringthe following command from the /upg95_98 directory:cp <CD-ROM_drive>/package/msosupg/upgrW95toW98/inst_W98SE.spd

cp <CD-ROM_drive>/package/msosupg/upgrW95toW98/*.inf

cp <CD-ROM_drive>/package/msosupg/upgrW95toW98/logonyes.reg

¶ For Windows, copy the files from the <CD-ROM_drive>:\package\msosupg\upgrW95toW98 directory tothe <drive>\upg95_98 directory on your TMR server byentering the following command from the drive\upg95_98directory:copy <CD-ROM_drive>:\package\msosupg\upgrW95toW98\inst_W98SE.spd

copy <CD-ROM_drive>:\package\msosupg\upgrW95toW98\*.inf

copy <CD-ROM_drive>:\package\msosupg\upgrW95toW98\logonyes.reg

3. Copy the check_OS.spd file:

¶ For UNIX, copy the file fromCD-ROM_drive/package/msosupg/upgrW95toW98 directoryto the /upgnt_00 directory on your TMR server, by enteringthe following commands from the /upg95_98 directory:cp <CD-ROM_drive>/package/msosupg/upgrW95toW98/check_OS.spd



14.U

pg

radin

gW

ind

ow

s95

toW

ind

ow

s98

¶ For Windows, copy the file from theCD-ROM_drive:\package\msosupg\upgrW95toW98 directoryto the <drive>\upgnt_00 directory on your TMR server byentering the following command from the drive\upg95_98directory:copy <CD-ROM_drive>:\package\msosupg\upgrW95toW98\check_OS.spd

Copying the Windows 98 Second Edition Files to theImage Server

To copy the Windows 98 files to the image server, follow thesesteps:

1. Create a directory called shared on the C: drive of the imageserver.



4. Select NullSessionShares. The Multi-String Editor dialogdisplays.


6. Share the c:\shared directory with the target workstations thatyou want to upgrade from Windows 95 to Windows 98 SecondEdition by entering the following command:net share shared=c:\shared

7. Create the Win98_SE directory under the c:\shared directory.

8. Copy the Windows 98 Second Edition source files from theWindows 98 Second Edition CD-ROM to thec:\shared\win98_SE directory on the image server by entering thefollowing command:xcopy <CD-ROM_drive>:\<win98source>\*.* c:\shared\win98_SE\*.* /s/e

where win98source is the Windows 98 Second Edition CD-ROMdirectory that contains the operating system source files.


334 Version 4.0

9. Copy the appropriate response file created in “Creating aResponse File” on page 332 and the logonyes.reg file toc:\shared\win98_SE.

Customizing the inst_W98SE.spd Software PackageDefinition File

Use the inst_W98SE.spd software package definition file to upgradeWindows 95 to Windows 98 Second Edition. Customize theinst_W98SE.spd software package definition file by specifying the\\ImageServer\shared\win98_SE in the Remote_path variable, whereImageServer is the name of the server where the image of theWindows 98 Second Edition operating system is located. Theinst_W98SE.spd software package definition file that address theresponse file for a dynamic environment follows:"TIVOLI Software Package v4.0 - SPDF"package

name = "Inst_w98_se"title = "Install Windows 98 second edition"version = "1.0"undoable = "o"committable = "o"history_reset = nsave_default_variables = ncreation_time = "2000-05-12 18:10:19"last_modification_time = "2000-05-12 18:14:08"

default_variablessp_path = "\\ImageServer\shared"

end


during_install

exit_codessuccess = 0,0failure = 1,65535

end

path = "$(sp_path)\win98_se\setup.exe"arguments = "$(sp_path)\win98_se\D_upgW98.inf"timeout = 7200unix_user_id = 0



14.U

pg

radin

gW

ind

ow

s95

toW

ind

ow

s98

unix_group_id = 0user_input_required = noutput_file_append = nerror_file_append = nreporting_stdout_on_server = yreporting_stderr_on_server = ymax_stdout_size = 10000max_stderr_size = 10000bootable = yretry = 1

end

end

end

Creating the Software Package on the TMR ServerBefore creating a software package, you must create on the TMRserver a profile manager that contains the software package and adirectory path in which to store the software package block. See theTivoli Management Framework User’s Guide, Version 3.7 to learnhow to create a profile manager. This scenario assumes that youcreated the upgrades profile manager and the packages directory pathin which to store the inst_W98SE.spb software package block in theTMR server. To create and build the software package on the TMRserver, enter the following command:

¶ In a UNIX environment:wimpspo -c @upgrades -f /upg95_98/inst_W98SE.spd -t build -p

/packages/inst_W98SE.spb @inst_W98SE^1.0

¶ In a Windows environment:wimpspo -c @upgrades -f c:\upg95_98\inst_W98SE.spd -t build -p

c:\packages\inst_W98SE.spd @inst_W98SE^1.0


v Creates the inst_W98SE^1.0 software package object that isbased on the c:\upg95_98\inst_W98SE.spd software packagedefinition file

v Builds a software package block

v Writes the software package block in the packages directory


336 Version 4.0


Subscribe the Tivoli Software Distribution endpoints to the upgradesprofile manager by entering the following command from the TMRserver:wsub @upgrades @Endpoint:target1 @Endpoint:target2 ... @Endpoint:targetn




¶ In a UNIX environment:winstsp @inst_W98SE^1.0 @target1 @target2 ... @targetn

¶ In a Windows environment:winstsp @inst_W98SE^^1.0 @target1 @target2 ... @targetn

Where target1, target2, ..., targetn are the Tivoli SoftwareDistribution endpoints on which you want to install Service Pack.You can also create a profile manager that contains all the targets toupgrade and specify the name of the profile manager in the winstspcommand. In a Windows environment, for example, if you createdthe win_targets profile manager, enter the following command:winstsp @inst_W98SE^^1.0 @win_targets




14.U

pg

radin

gW

ind

ow

s95

toW

ind

ow

s98

Using check_OS^1.0.spd to Verify the UpgradeUsing the check_OS^1.0.spd software package definition file youcan verify if the Windows 98 Second Edition operating system hasbeen installed in your environment. To perform this check performthe following steps:

1. Create and build the check_OS^1.0.spd software package on theTMR 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 TivoliSoftware Distribution endpoints, by entering the followingcommand from the TMR 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 SoftwareDistribution endpoints on which you want to install Windows2000 Professional. You can also create a profile manager thatcontains all the targets to check and specify the name of theprofile manager in the winstsp command. In a Windowsenvironment, for example, if you created the win_targets profilemanager, enter the following command:winstsp @check_OS^^1.0 @win_targets

After you enter one of the previous commands, the check processstarts on the Tivoli Software Distribution endpoints. When thedistribution of the software package ends. Verify that theoperating system indicated in the standard output section of thecheck_OS.log file is Windows 98.


338 Version 4.0

Upgrading Windows NT 4.0Workstation to Windows 2000Professional

This scenario explains how to use Tivoli Software Distribution,Version 4.0 to upgrade software from Windows NT 4.0 Workstationto Windows 2000 Professional.


¶ Creating the response file appropriate for your environment

¶ Copying the files that you need to perform the migration to theTMR server

¶ Copying the Windows 2000 files to the image server

¶ Customizing the inst_w2000.spd software package definition file



¶ Distributing the software package to the Tivoli endpoints

¶ Using the check_OS^1.0.spd software package definition file toverify the upgrade


15


15.U

pg

radin

gW

ind

ow

sN

T4.0

toW

ind

ow

s2000

¶ A Windows 2000 Professional workstation with the Resource Kit2000 installed.

¶ A TMR server on which to prepare and pack the softwarepackage.

¶ An image server on which to store the Windows 2000Professional operating system files.

¶ The target workstations with Windows NT 4.0 installed. Youmust define the target workstations as Tivoli SoftwareDistribution endpoints.

Creating a Response File

Note: Refer to the Microsoft Windows 2000 Resource Kitdocumentation for a detailed explanation of the procedure forcreating a response file.

Tivoli Software Distribution, Version 4.0 provides an example of aresponse file that you must customize to suit your environment.Create a response file appropriate for your environment using theWindows 2000 Setup Manager Wizard or customize the followingunattend.txt response file that is provided in the CD-ROM directory<CD-ROM>\package\msosupg\Unattended.txt:upgrading from Windows NT to Windows 2000

;SetupMgrTag[Data]

AutoPartition=1MsDosInitiated="0"UnattendedInstall="Yes"

[Unattended]UnattendMode=FullUnattendedOemSkipEula=YesOemPreinstall=NoNtUpgrade=Yes

[GuiUnattended]AdminPassword=*OEMSkipRegional=1TimeZone=110OemSkipWelcome=1AutoLogon=Yes

Upgrading Windows NT 4.0 Workstation to Windows 2000 Professional

340 Version 4.0

[UserData]FullName=AdministratorOrgName=WORKGROUPComputerName=*

[Identification]JoinWorkgroup=WORKGROUP

[Networking]InstallDefaultComponents=Yes

Copying the Files That You Need to Perform theMigration to the TMR Server

To perform the Windows NT 4.0 Workstation to Windows 2000professional migration you must copy the following files that arecontained in the Tivoli Software Distribution, Version 4.0 CD-ROMto the TMR server.

¶ inst_w2000.spd

¶ Unattended.txt

Note: You can use the response file that you created in“Creating a Response File” on page 340 instead of thisfile.

¶ check.bat

¶ check_OS.spd

To copy these files from the CD-ROM to the TMR Server, performthe following steps on the TMR server:

1. Create a directory in which to store the files. This scenario usesthe upgnt_00 directory.

2. Copy the inst_w2000.spd and the Unattended.txt files:

¶ For UNIX, copy the files from theCD-ROM_drive/package/msosupg/upgrNTtoW2000 directoryto the /upgnt_00 directory on your TMR server by enteringthe following commands from the /upgnt_00 directory:cp <CD-ROM_drive>/package/msosupg/upgrNTtoW2000/inst_w2000.spd



15.U

pg

radin

gW

ind

ow

sN

T4.0

toW

ind

ow

s2000

cp <CD-ROM_drive>/package/msosupg/upgrNTtoW2000/Unattended.txt

¶ For Windows, copy the files from the <CD-ROM_drive>:\package\msosupg\upgrNTtoW2000 directory tothe <drive>\upgnt_00 directory on your TMR server byentering the following command from the drive\upgnt_00directory:copy <CD-ROM_drive>:\package\msosupg\upgrNTtoW2000\inst_w2000.spd

copy <CD-ROM_drive>:\package\msosupg\upgrNTtoW2000\Unattended.txt

3. Copy the check_OS.spd and the check.bat files:

¶ For UNIX, copy the files fromCD-ROM_drive/package/msosupg/upgrNTtoW2000 directoryto the /upgnt_00 directory on your TMR server, by enteringthe following commands from the /upgnt_00 directory:cp <CD-ROM_drive>/package/msosupg/upgrNTtoW2000/check_OS.spd

cp <CD-ROM_drive>/package/msosupg/upgrNTtoW2000/check.bat

¶ For Windows, copy the files from theCD-ROM_drive:\package\msosupg\upgrNTtoW2000 directoryto the drive\upgnt_00 directory on your TMR server byentering the following command from the drive\upgnt_00directory:copy <CD-ROM_drive>:\package\msosupg\upgrNTtoW2000\check_OS.spd

copy <CD-ROM_drive>:\package\msosupg\upgrNTtoW2000\check.bat

Copying the Windows 2000 Professional Files to theImage 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 imageserver.



342 Version 4.0


4. Select NullSessionShares. The Multi-String Editor dialogdisplays.


6. Share the c:\shared directory with the target workstations thatyou want to upgrade from Windows NT 4.0 Workstation toWindows 2000 Professional by entering the following command:net share shared=c:\shared

7. Create the Win2000 directory under the c:\shared directory.

8. Copy the Windows 2000 Professional source files from theWindows 2000 Professional CD-ROM to the c:\shared\win2000directory on the image server by entering the followingcommand:xcopy <CD-ROMdrive>:\<win2000source>\*.*c:\shared\win2000\*.* /s/e

where win2000source is the Windows 2000 ProfessionalCD-ROM directory that contains the operating system sourcefiles.

9. Copy the unattended.txt response file or the response file thatyou created in “Creating a Response File” on page 340 toc:\shared\win2000.

Customizing the inst_w2000.spd Software PackageDefinition File

Use the inst_w2000.spd software package definition file to upgradeWindows NT 4.0 Workstation to Windows 2000 Professional.Customize the inst_w2000.spd software package definition file byspecifying the \\ImageServer\shared\win2000 in the sp_path, whereImageServer is the name of the server where the image of theWindows 2000 Professional operating system is located. Theinst_w2000.spd software package definition file follows:



15.U

pg

radin

gW

ind

ow

sN

T4.0

toW

ind

ow

s2000

”TIVOLI Software Package v4.0 - SPDF"package

name = "Inst_w2000"title = "Install Windows 2000"version = "1.0"undoable = "o"committable = "o"history_reset = nsave_default_variables = ncreation_time = "2000-05-12 18:10:19"last_modification_time = "2000-05-12 18:14:08"

default_variablessp_path = "\\ImageServer\shared\win2000"

end


during_install

exit_codessuccess = 0,0failure = 1,65535

end

path = "$(sp_path)\i386\winnt32"arguments = "/unattented:$(sp_path)\unattend.txt

/s:$(sp_path)\i386"timeout = 7200unix_user_id = 0unix_group_id = 0user_input_required = noutput_file_append = nerror_file_append = nreporting_stdout_on_server = yreporting_stderr_on_server = ymax_stdout_size = 10000max_stderr_size = 10000bootable = yretry = 1

end

end

end


344 Version 4.0

Creating the Software Package on the TMR ServerBefore creating a software package, you must create on the TMRserver a profile manager that contains the software package and adirectory path in which to store the software package block. See theTivoli Management Framework User’s Guide, Version 3.7 to learnhow to create a profile manager. This scenario assumes that youcreated the upgrades profile manager and the packages directory pathin which to store the inst_w2000.spb software package block in theTMR server. To create and build the software package on the TMRserver, 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

¶ In a Windows environment:wimpspo -c @upgrades -f c:\upgnt_00\inst_w2000.spd -t build -pc:\packages\inst_w2000.spd @inst_w2000^^1.0


v Creates the inst_w2000^1.0 software package object that isbased on the c:\upgnt_00\inst_w2000.spd software packagedefinition file

v Builds a software package block

v Writes the software package block in the packages directory


Subscribe the Tivoli Software Distribution endpoints to the Upgradesprofile manager by entering the following command from the TMRserver:wsub @upgrades @Endpoint:target1 @Endpoint:target2 ... @Endpoint:targetn




15.U

pg

radin

gW

ind

ow

sN

T4.0

toW

ind

ow

s2000



¶ 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 SoftwareDistribution endpoints on which you want to install Windows 2000Professional. You can also create a profile manager that contains allthe targets to upgrade and specify the name of the profile manager inthe winstsp command. In a Windows environment, for example, ifyou created the win_targets profile manager, enter the followingcommand:winstsp @inst_w2000^^1.0 @win_targets


Using the check_OS^1.0.spd to Verify the UpgradeUsing the check_OS^1.0.spbdyou can verify if the Windows 2000Professional has been installed in your environment. To perform thischeck perform the following steps:

1. Create and build the check_OS^1.0.spd software package on theTMR 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


346 Version 4.0

2. Distribute the check_OS^1.0 software package to the TivoliSoftware Distribution endpoints, by entering the followingcommand from the TMR 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 SoftwareDistribution endpoints on which you want to install Windows2000 Professional. You can also create a profile manager thatcontains all the targets to check and specify the name of theprofile manager in the winstsp command. In a Windowsenvironment, for example, if you created the win_targets profilemanager, enter the following command:winstsp @check_OS^^1.0 @win_targets

After you enter one of the previous commands, the check processstarts on the Tivoli Software Distribution endpoints. When thedistribution of the software package ends, verify that theoperating system indicated in the standard output section of thecheck_OS.log file is Windows 2000.



15.U

pg

radin

gW

ind

ow

sN

T4.0

toW

ind

ow

s2000

348 Version 4.0

Authorization Roles

This appendix contains tables that describe the roles you need toperform Tivoli Software Distribution operations.

To perform system administration operations from within the Tivolienvironment, you must be a Tivoli administrator. Depending on theoperations you are required to perform, you can have one or more ofthe following roles:

¶ Super

¶ Senior

¶ Admin

¶ User

¶ Install-product

Setting Up Tivoli Software Distribution ProfilesThe following table lists the roles required to set up softwarepackage profiles:


Install Tivoli SoftwareDistribution

Desktop view for root super or install-product

Create a softwarepackage profile

Profile manager senior or super

A


A.

Au

tho

rization

Ro

les


Clone a softwarepackage profile

Profile manager senior or super

View a softwarepackage profile

Software package user, admin, senior, orsuper

Subscribe resources toa profile manager

Profile manager policyregion —AND—Subscriber policyregion

admin, senior, or super

Defining and Deleting ProfilesThe following table lists the roles required to define a softwarepackage by setting its properties and to view configurationinformation:


Export a softwarepackage definition file

Software package user, admin, senior, orsuper

Set or edit softwarepackage profileproperties

Software package admin, senior or super

Import a softwarepackage definition file

Software package admin, senior or super

Delete a softwarepackage profile

Software package senior or super

Authorization Roles

350 Version 4.0

Performing OperationsThe following table lists the role required to distribute a softwarepackage:


Distribute a softwarepackage profile



Schedule a softwarepackage profiledistribution



Calculate the size of asoftware packageprofile

Profile manager policyregion


Remove a softwarepackage profile from asubscriber

Software package admin, senior, or super

Authorization Roles


A.

Au

tho

rization

Ro

les

352 Version 4.0

Glossary

This glossary defines technical terms used in the documentation forTivoli products and includes selected terms and definitions from:

¶ The American National Standard Dictionary for InformationSystems, ANSI X3.172-1990, copyright 1990 by the AmericanNational Standards Institute (ANSI). Copies may be purchasedfrom the American National Standards Institute, 11 West 42ndStreet, New York, New York 10036. Definitions are identified bythe symbol (A) after the definition.

¶ The Information Technology Vocabulary developed bySubcommittee 1, Joint Technical Committee 1, of theInternational Organization for Standardization and theInternational Electrotechnical Commission (ISO/IEC JTC1/SC1).Definitions of published parts of this vocabulary are identifiedby the symbol (I) after the definition; definitions taken fromdraft international standards, committee drafts, and workingpapers being developed by ISO/IEC JTC1/SC1 are identified bythe symbol (T) after the definition, indicating that finalagreement has not yet been reached among the participatingNational Bodies of SC1.

¶ The IBM Dictionary of Computing, New York: McGraw-Hill,1994.

¶ Internet Request for Comments: 1208, Glossary of NetworkingTerms

¶ Internet Request for Comments: 1392, Internet Users’ Glossary

¶ The Object-Oriented Interface Design: IBM Common UserAccess Guidelines, Carmel, Indiana: Que, 1992.

The following cross-references are used in this glossary:

Contrast with:This refers the reader to a term that has an opposed orsubstantively different meaning.

See: This refers the reader to (a) a related term, (b) a term that is


Glo

ssary

the expanded form of an abbreviation or acronym, or (c) asynonym or more preferred term.

A

absolute pathA path that begins with the root directory. The absolute path may also be known asthe “full pathname”. Contrast with relative path.

accept operationA change management operation that discards the resources needed to undo theprevious operation. After the execution of an accept operation, the operation cannotbe undone.

action(1) An operation on a managed object, the semantics of which are defined as part ofthe managed object class definition. (2) In the AIX operating system, a defined taskthat an application performs. An action modifies the properties of an object ormanipulates the object in some way.

administratorSee Tivoli administrator.

administrator collectionIn a Tivoli environment, the collection for administrator objects that is generated byTivoli Enterprise software. This container is represented by the Administrator iconon the Tivoli desktop; opening the icon provides access to information about eachTivoli administrator.

agent(1) In systems management, a user that, for a particular interaction, has assumed anagent role. (2) An entity that represents one or more managed objects by (a)emitting notifications regarding the objects and (b) handling requests from managersfor management operations to modify or query the objects. (3) A system thatassumes an agent role.

agent roleIn systems management, a role assumed by a user in which the user is capable ofperforming management operations on managed objects and of emitting notificationson behalf of managed objects.

applicationA collection of software components used to perform specific types of user-orientedwork on a computer.

354 Version 4.0

application programming interface (API)A software interface that enables applications to communicate with each other. AnAPI is the set of programming language constructs or statements that can be codedin an application program to obtain the specific functions and services provided byan underlying operating system or service program.

attributeA characteristic that identifies and describes a managed object. The characteristiccan be determined, and possibly changed, through operations on the managedobject.

authorization(1) In computer security, the right granted to a user to communicate with or makeuse of a computer system. (T) (2) An access right. (3) The process of granting auser either complete or restricted access to an object, resource, or function.

authorization roleIn a Tivoli environment, a role assigned to Tivoli administrators to enable them toperform their assigned systems management tasks. A role may be granted over theentire Tivoli Management Region or over a specific set of resources, such as thosecontained in a policy region. Examples of authorization roles include: super, senior,admin, and user.

AutoPackA Tivoli Software Distribution tool that enables a Tivoli administrator to create asoftware package. AutoPack produces the software package by (a) taking snapshotsof the PC’s drive and system configuration before and after the installation of anapplication on the PC and (b) capturing the differences between these snapshots inthe software package.

C

change managementThe process of planning (for example, scheduling) and controlling (for example,distributing, installing, and tracking) software changes over a network. This issometimes known as “software management.”

check boxA square box with associated text that represents a choice. When a user selects thechoice, the check box is filled to indicate that the choice is selected. The user canclear the check box by selecting the choice again, thereby deselecting the choice.

class(1) In object-oriented design or programming, a model or template that can beinstantiated to create objects with a common definition and therefore, commonproperties, operations, and behavior. An object is an instance of a class. (2) In the


Glo

ssary

AIX operating system, pertaining to the I/O characteristics of a device. Systemdevices are classified as block or character devices.

CLISee command line interface (CLI).

clientA computer system or process that requests a service of another computer system orprocess that is typically referred to as a server. Multiple clients may share access toa common server.

collectionIn a Tivoli environment, a container that groups objects on a Tivoli desktop, thusproviding the Tivoli administrator with a single view of related resources. Either theTivoli Management Framework or a Tivoli administrator can create a collection. Thecontents of a collection are referred to as its members. Examples of collectionsinclude the administrator collection and the generic collection; the administratorcollection is an example of a collection generated by the Tivoli ManagementFramework.

command(1) A request from a terminal for the performance of an operation or the executionof a particular program. (2) In Tivoli NetView for OS/390, a sequence of charactersthat is submitted to cause an action. A command contains a verb and an object.

command line interface (CLI)A type of computer interface in which the input command is a string of textcharacters. Contrast with graphical user interface (GUI).

commit operationIn Tivoli Software Distribution, an operation performed by a configuration programon target managed nodes after a file package distribution. This function enables aTivoli administrator to distribute a file package to multiple targets and to make thedistributed information available on all targets at the same time.

commit phaseIn Tivoli Software Distribution, the phase of transactional mode in which theprepared actions are committed, causing all of the updates to take effect.

configuration repositoryIn a Tivoli environment, an RDBMS Interface Module (RIM) repository thatcontains information that is collected or generated by Tivoli Inventory and TivoliSoftware Distribution. For example, in the configuration repository, Tivoli Inventorystores information regarding hardware, software, system configuration, and physicalinventory; and Tivoli Software Distribution stores information regarding file packageoperations.

356 Version 4.0

containerA visual user-interface component that holds objects.

CRCSee cyclic redundancy check (CRC).

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 stationafter a block-check character has been accumulated.

D

database mode profile managerSee profile manager.

dataless mode profile managerSee profile manager.

default policyIn a Tivoli environment, a set of resource property values that are assigned to aresource when the resource is created.

deployment managementThe Tivoli management discipline that addresses the automation of configurationand change management activities for the ever-evolving components of a networkcomputing system.

desktopA graphical user interface (GUI) that enables a user to interact with and performoperations on a computer system.

differencing phaseThe process by which AutoPack examines and compares the first and secondsnapshots, and for each difference found, the related command is generated andadded to the software package.

directoryIn a hierarchical file system, a container for files or other directories.

domainThat part of a computer network in which the data processing resources are undercommon control. (T)


Glo

ssary

domain nameIn the Internet suite of protocols, a name of a host system. A domain name consistsof a sequence of subnames separated by a delimiter character. For example, if thefully 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 typeof Tivoli operation. (2) In a Tivoli environment, a Tivoli service that runs onmultiple operating systems and performs Tivoli operations on those systems, therebyenabling the Tivoli Management Framework to manage the systems as Tivoliclients.

endpoint gatewaySee gateway.

endpoint listIn a Tivoli environment, a list of all endpoint clients in the Tivoli ManagementRegion with their assigned gateways. See endpoint manager.

endpoint managerIn a Tivoli environment, a service that runs on the Tivoli server, assigns endpointclients to gateways, and maintains the endpoint list.

event classIn the Tivoli Enterprise Console, a classification for an event that indicates the typeof information that the event adapter will send to the event server.

event consoleIn the Tivoli Enterprise Console, a graphical user interface (GUI) that enablessystem administrators to view and respond to dispatched events from the eventserver. The Tivoli Event Integration Facility (EIF) does not directly use or affectevent consoles.

event serverIn the Tivoli Enterprise Console, a central server that processes events. The eventserver creates an entry for each incoming event and evaluates the event against arule base to determine whether it can respond to or modify the event automatically.

358 Version 4.0

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 eventserver.

export/importIn Tivoli Software Distribution, a feature that enables a Tivoli administrator to save(export) a file package definition as a text file, to edit the keywords and lists in thedefinition, and to retrieve (import) the definition from the text file to set theproperties for the file package.

F

fanoutIn communication, the process of creating copies of a distribution to be deliveredlocally or to be sent through the network.

field(1) An identifiable area in a window. Examples of fields are: an entry field, intowhich a user can type or place text, and a field of radio button choices, from whicha user can select one choice. (2) The smallest identifiable part of a record. (3) InTivoli NetView, the building block of which objects are composed. A field ischaracterized by a field name, a data type (integer, Boolean, character string, orenumerated value), and a set of flags that describe how the field is treated by TivoliNetView. A field can contain data only when it is associated with an object.

G

gateway(1) A functional unit that interconnects two computer networks with differentnetwork architectures. A gateway connects networks or systems of differentarchitectures. A bridge interconnects networks or systems with the same or similararchitectures. (T) (2) A functional unit that connects two networks orsubnetworks having different characteristics, such as different protocols or differentpolicies concerning security or transmission priority. (3) In a Tivoli environment,software running on a managed node that provides all communication servicesbetween a group of endpoints and the rest of the Tivoli environment. This gatewayincludes the multiplexed distribution (MDist) function, enabling it to act as thefanout point for distributions to many endpoints. (4) The combination of machinesand programs that provide address translation, name translation, and system servicescontrol point (SSCP) rerouting between independent SNA networks to allow thosenetworks to communicate. A gateway consists of one gateway NCP and at least onegateway VTAM.


Glo

ssary

graphical user interface (GUI)A type of computer interface consisting of a visual metaphor of a real-world scene,often of a desktop. Within that scene are icons, representing actual objects, that theuser can access and manipulate with a pointing device. Contrast with command lineinterface (CLI).

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 avalue.

GUISee graphical user interface (GUI).

H

host(1) A computer that is connected to a network (such as the Internet or an SNAnetwork) and provides an access point to that network. Also, depending on theenvironment, the host may provide centralized control of the network. The host canbe a client, a server, or both a client and a server simultaneously. (2) In a Tivolienvironment, a computer that serves as a managed node for a profile distribution.

HTTPdSee HTTP daemon (HTTPd).

HTTP daemon (HTTPd)A multithreaded Web server that receives incoming Hypertext Transfer Protocol(HTTP) requests.

I

install operationA change management operation that installs a software package on a selected groupof targets.

instanceIn object-oriented programming, an object created by instantiating a class.

instantiateIn object-oriented programming, to represent a class abstraction with a concreteinstance of the class.

360 Version 4.0

L

local distributionIn a Tivoli environment, a distribution to target machines in the same TivoliManagement Region as the source machine.

local overridesIn a Tivoli environment, a feature of all profile-based Tivoli applications—exceptfor Tivoli Software Distribution—that allows changes made at the endpoint profileto override those in a distributed profile.

M

managed node(1) In Internet communications, a workstation, server, or router that contains anetwork management agent. In the Internet Protocol (IP), the managed node usuallycontains a Simple Network Management Protocol (SNMP) agent. (2) In a Tivolienvironment, any managed resource on which the Tivoli Management Framework isinstalled.

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 useof systems management protocols.

managed resourceIn 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 Tivolidesktop. Managed resources must be a supported resource type in a policy regionand are subject to a set of rules. Managed resources include, but are not limited to,managed nodes, task libraries, monitors, profiles, and bulletin boards.

management by subscriptionIn a Tivoli environment, the concept of managing network resources by creating setsof profiles and distributing the profiles (through profile managers) to physicalentities (Tivoli resources), called subscribers.

MDistIn a Tivoli environment, a service that enables efficient distribution of large amountsof data across complex networks. MDist is an abbreviation for multiplexeddistribution. MDist and MDist 2 are two types of multiplexed distributiontechnology; MDist 2 extends MDist to handle the large-scale distributionrequirements of Tivoli Enterprise software applications.


Glo

ssary

MDist 2multiplexed distribution 2. In a Tivoli environment, a service that providesasynchronous operation, data queries, and repeater depots in addition to the MDistservice. See also MDist.

method(1) In object-oriented design or programming, the software that implements thebehavior specified by an operation. (2) In Tivoli NetView for OS/390, a programthat runs in the Resource Object Data Manager (RODM) address space andcommunicates with RODM using an application programming interface (API).Methods are usually small programs that perform specific tasks on data in the datacache.

multiplexed distribution (MDist)See MDist.

N

noticeIn a Tivoli environment, a message generated by a systems management operationthat contains information about an event or the status of an application. Notices arestored in notice groups.

notice groupIn a Tivoli environment, an application- or operation-specific container that storesand displays notices pertaining to specific Tivoli functions. The Tivoli bulletin boardis comprised of notice groups. A Tivoli administrator can subscribe to one or morenotice groups; the administrator’s bulletin board contains only the notices that residein 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 anevent that has occurred within the managed object, such as a threshold violation ora change in configuration status.

O

object(1) In object-oriented design or programming, a concrete realization of a class thatconsists of data and the operations associated with that data. (2) An item that a usercan manipulate as a single unit to perform a task. An object can appear as text, anicon, or both. (3) In Tivoli NetView for OS/390, the part of a NetView commandthat follows the verb. The object describes where the action of the verb is to occur.

362 Version 4.0

object pathIn a Tivoli environment, an absolute or relative path to a Tivoli object, similar topaths in file systems.

operationIn object-oriented design or programming, a service that can be requested at theboundary of an object. Operations include modifying an object or disclosinginformation about an object.

oservThe name of the object request broker used by the Tivoli environment. The oservruns on the TMR server and each TMR client.

P

pattern-matching characterA special character such as an asterisk (*) or a question mark (?) that can be used torepresent one or more characters. Any character or set of characters can replace apattern-matching character.

policyIn a Tivoli environment, a set of rules that are applied to managed resources. Aspecific rule in a policy is referred to as a “policy method.”

policy regionIn a Tivoli environment, a group of managed resources that share one or morecommon policies. Tivoli administrators use policy regions to model the managementand organizational structure of a network computing environment. Theadministrators can group similar resources, define access to and control theresources, and associate rules for governing the resources. The policy regioncontains resource types and the list of resources to be managed. A policy region isrepresented on the Tivoli desktop by an icon that resembles a capitol building (domeicon). When a Tivoli Management Region (TMR) is created, a policy region withthe same name is also created. In this case, the TMR has only one policy region.However, in most cases, a Tivoli administrator creates other policy regions andsubregions to represent the organization of the TMR. A TMR addresses the physicalconnectivity of resources whereas a policy region addresses the logical organizationof resources.

policy subregionIn 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 policyproperties of the parent policy region. The Tivoli administrator can later change orcustomize these properties to reflect the specific needs and differences of thesubregion.


Glo

ssary

preparation machineAny Windows 95 (or later), Windows NT, or OS/2 system on which the TivoliSoftware Distribution Java Endpoint Package Editor component is installed. Thepreparation machine should have few or no other applications installed.

preparation phaseThe phase of transactional mode in which each action in a package prepares theconditions for the successful execution of the requested operation.

profileIn a Tivoli environment, a container for application-specific information about aparticular type of resource. A Tivoli application specifies the template for itsprofiles; the template includes information about the resources that can be managedby that Tivoli application.A profile is created in the context of a profile manager; the profile manager links aprofile to the Tivoli resource (for example, a managed node) that uses theinformation contained in the profile. A profile does not have any direct subscribers.

profile managerIn a Tivoli environment, a container for profiles that links the profiles to a set ofresources, called subscribers . Tivoli administrators use profile managers to organizeand distribute profiles. A profile manager is created in the context of a policy regionand is a managed resource in a policy region. A profile manager can operate in oneof the following two modes:

¶ Dataless mode, which enables a profile manager to distribute to any Tivoliclient (including managed nodes, endpoints, PC managed nodes, and NetWaremanaged sites) but not to other profile managers.

¶ Database mode, which enables a profile manager to distribute to any profilemanager (dataless or database), all managed nodes, all PC managed nodes, andNetWare managed sites—but not to endpoints.

Q

queryIn the Tivoli environment, a combination of statements that are used to search theconfiguration repository for systems that meet certain criteria.

query libraryIn the Tivoli environment, a facility that provides a way to create and manage Tivoliqueries.

R

RDBMSSee relational database management system (RDBMS).

364 Version 4.0

registered nameIn a Tivoli environment, the name by which a particular resource is registered withthe name registry when it is created.

relational database management system (RDBMS)A collection of hardware and software that organizes and provides access to arelational database.

relative pathA path that begins with the working directory. Contrast with absolute path.

remote distributionIn a Tivoli environment, a distribution to target machines in a connected TivoliManagement Region.

remove operationA change management operation that performs the opposite action to the installoperation. This operation removes a software package from selected targets.

repeater siteIn a Tivoli Management Region, a managed node that is configured with the MDistfeature. A repeater site receives a single copy of data and distributes it to the nexttier of clients.

resource(1) Any facility of a computing system or operating system required by a job ortask, and including main storage, input/output devices, the processing unit, data sets,and control or processing programs. (2) In Tivoli NetView for OS/390, anyhardware or software that provides function to the network. (3) See managedresource.

resource type(1) In a Tivoli environment, one of the properties of a managed resource. Resourcetypes are defined in the default policy for a policy region. (2) In Tivoli NetView forOS/390, one of the three elements, which also include data type and display type,that are used to describe the organization of panels. Resource types in one categoryinclude central processing unit, channel, control unit, and I/O device; and in anothercategory, they include communication controller, adapter, link, cluster controller, andterminal.

root directoryThe highest level directory in a hierarchical file system.


Glo

ssary

S

serverA 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.

shellA software interface between a user and the operating system of a computer. Shellprograms interpret commands and user interactions on devices such as keyboards,pointing devices, and touch-sensitive screens and communicate them to theoperating system. Shells simplify user interactions by eliminating the user’s concernwith operating system requirements. A computer may have several layers of shellsfor various levels of user interaction.

signatureIn Tivoli Software Distribution, the first line of the software package definition file(SPDF), which uniquely identifies the object. Software Distribution uses thesignature for version checking and for determining what kind of importer to use toread the SPDF.

software packageIn Tivoli Software Distribution, a database object that contains a sequential list ofactions to be executed on a target system that are related to the installation ofsoftware applications.

software package blockIn Tivoli Software Distribution, a file that contains the resources referred to by theactions in a software package.

software package definition fileAn ASCII text file used by the Software Distribution engine to describe packagecontents. It consists of a sequence of stanzas that describe commands to beexecuted.

Software Package EditorA Java-based graphical user interface for creating and customizing softwarepackages.

software package objectA software package that has been imported into the Tivoli ManagementEnvironment. The software package is catalogued at the Software Distribution serveras a Tivoli database software package object. You can perform change managementoperations on software package objects such as install, remove, undo, accept,commit, and verify.

366 Version 4.0

source hostIn Tivoli Software Distribution, the managed node on which the files and directoriesreferenced in a software package reside.

subscriberIn a Tivoli environment, a managed node, a profile manager, an endpoint, or anotherTivoli client that is subscribed to a profile manager. Although profiles are distributedto a subscriber, the subscriber may or may not be the final destination of the profiledistribution.

subscriptionIn a Tivoli environment, the process of identifying the subscribers to which profileswill be distributed.

subscription listIn 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 away of subscribing several resources simultaneously rather than adding each oneindividually. In Tivoli Plus modules, a profile manager functions as a subscriptionlist.

systems management(1) Functions in the application layer related to the management of Open SystemsInterconnection (OSI) resources and their status across all layers of the OSIarchitecture. (I) (2) The tasks involved in maintaining computer andcommunication systems, for example: changing configuration, identifying faults,securing access, accounting for resource usage, and analyzing performance.

T

targetSee endpoint.

Tivoli administratorIn a Tivoli environment, a system administrator who has been authorized to performsystems management tasks and manage policy regions in one or more networks.Each Tivoli administrator is represented by an icon on the Tivoli desktop.

Tivoli clientA client of a Tivoli server. See TMR client and TMR server.

Tivoli Distributed MonitoringA Tivoli product that monitors system resources, initiates any necessary correctiveactions, and informs system administrators of potential problems. Tivoli DistributedMonitoring consists of a group of monitors that are installed on each managed nodethat is to be monitored. It resolves some events on its own and may send others tothe Tivoli Enterprise Console.


Glo

ssary

Tivoli Enterprise Console (TEC)A Tivoli product that collects, processes, and automatically initiates correctiveactions for system, application, network, and database events; it is the centralcontrol point for events from all sources. The Tivoli Enterprise Console provides acentralized, global view of the network computing environment; it uses distributedevent monitors to collect information, a central event server to process information,and distributed event consoles to present information to system administrators.

Tivoli Enterprise softwareThe integrated suite of Tivoli products for systems management in a largeorganization. These products enable system administrators to manage their networkcomputing enterprise according to the disciplines of availability management,deployment management, operations and administration, security management, andservice-level management. This suite includes Tivoli Global Enterprise Manager,Tivoli NetView for OS/390, and Tivoli Decision Support.

Tivoli environmentThe Tivoli applications, based upon the Tivoli Management Framework, that areinstalled at a specific customer location and that address network computingmanagement issues across many platforms. In a Tivoli environment, a systemadministrator can distribute software, manage user configurations, change accessprivileges, automate operations, monitor resources, and schedule jobs.

Tivoli Event Integration FacilityA Tivoli toolkit that provides a simple application programming interface (API) toenable customers and Tivoli Partners to develop new event adapters that canforward events to the Tivoli Enterprise Console.

Tivoli install imageIn a Tivoli environment, a file that resides on a CD or in a file system and containsa Tivoli product to be installed. A Tivoli install image can be used to install theTivoli Management Framework or to install an application onto the Framework forthe first time. A single CD often includes both a Tivoli install image and a Tivoliupgrade image, and it may include Tivoli install images for more than oneapplication. Contrast with Tivoli upgrade image.

Tivoli InventoryA Tivoli product that enables system administrators to gather hardware and softwareinformation for a network computing environment. It scans the managed resourcesand stores inventory information in the configuration repository.

Tivoli IT DirectorA Tivoli product for systems management in a small or medium organization. It isnot sold directly by Tivoli Systems Inc. but rather through a Tivoli authorizedreseller.

368 Version 4.0

Tivoli management agent (TMA)In the Tivoli environment, an agent that securely performs administrative operations.

Tivoli Management FrameworkThe base software that is required to run any of the Tivoli systems managementapplications. This software infrastructure enables the integration of systemsmanagement applications from Tivoli and the Tivoli Partners. The TivoliManagement Framework includes the following:

¶ Object request broker (oserv)

¶ Distributed object database

¶ Basic administration functions

¶ Basic application services

¶ Basic desktop services such as the graphical user interface (GUI)

In a Tivoli environment, the Tivoli Management Framework is installed on everyclient and every server with these exceptions:

¶ The Tivoli Management Framework is never installed on an endpoint.

¶ The TMR server is the only server that contains the full object database.

Tivoli Management Region (TMR)In a Tivoli environment, a Tivoli server and the set of clients that it serves. Anorganization can have more than one TMR. A TMR addresses the physicalconnectivity of resources, whereas a policy region addresses the logical organizationof resources.

Tivoli management softwareThe overall descriptor for software from Tivoli Systems Inc., which includes TivoliEnterprise software (for systems management in a large organization), Tivoli ITDirector (for systems management in a small or medium organization), and TivoliCross-Site (for the management of e-commerce systems). Tivoli managementsoftware enables organizations to centrally manage their computing resources(including the critical applications that drive business performance and profits) in asimple and straightforward manner.

Tivoli Name Registry (TNR)A name service consisting of a two-dimensional table that maps resource names toresource identifiers and corresponding information within a Tivoli ManagementRegion (TMR).

Tivoli NetViewA Tivoli product that enables distributed network management across multipleoperating systems and protocols. Unlike Tivoli NetView for OS/390, Tivoli NetViewdoes not provide centralized management from an OS/390 host.


Glo

ssary

Tivoli NetView for OS/390A Tivoli product that enables centralized systems and network management from anOS/390 environment. Through its MultiSystem Manager component, Tivoli NetViewfor 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 (TNWR)In a Tivoli environment, a server application that is installed on a Novell NetWareserver and that maintains a list of available clients for the server. The TivoliNetWare repeater works with the NetWare managed site to perform profiledistribution.

Tivoli Partner AssociationA partnership program that is led by Tivoli Systems Inc. for business, industry, andproduct partners. The Tivoli Partner Association provides programs and benefits forbusiness partners (including systems integrators, outsourcers, and resellers) to sellTivoli Enterprise and IT Director products. Industry and product partners collaboratewith Tivoli Systems Inc. in creating hardware and software products that are TivoliReady.™

Tivoli Plus moduleIn a Tivoli environment, a management module that has been certified by the TivoliPartner Association and that enables a specific vendor application to be managed byTivoli management software. To be certified by the Tivoli Partner Association, theTivoli Plus module must include certain features such as enablement for the TivoliGlobal Enterprise Manager (Tivoli GEM).

Tivoli ReadyPertaining to a product that has passed rigorous product certification testing byTivoli Systems Inc. to ensure that the product delivers turnkey (or ″out-of-the-box″)integration with Tivoli management software. A product that has passed thiscertification testing carries the Tivoli Ready logo.

Tivoli Remote ControlA Tivoli product that enables a Tivoli administrator to control mouse and keyboardoperations on an NT managed node or a PC managed node.

Tivoli Security ManagementTivoli Enterprise software that enables the consistent definition, implementation, andenforcement of security policy in a network computing environment.

Tivoli serverThe server that holds or references the complete set of Tivoli software, including thefull object database. See Tivoli client, TMR client, and TMR server.

370 Version 4.0

Tivoli Software DistributionA Tivoli product that automates software distribution to clients and servers in anetwork computing environment. An organization can use this product to install andupdate applications and software in a coordinated, consistent manner across anetwork. Tivoli Software Distribution creates file packages and software packagesand distributes them to predefined subscribers.

Tivoli Software Distribution Web InterfaceA tool provided by Tivoli Software Distribution that enables an end-user on a Tivoliendpoint to retrieve Software Distribution profiles using the Tivoli Web-basedinterface.

Tivoli upgrade imageIn a Tivoli environment, a file that resides on a CD or in a file system and containsupdates for a Tivoli product. A Tivoli upgrade image contains only the files thathave changed since the previous product release, with the scripts and commandsthat are needed for installing the new files and configuring the database. Contrastwith Tivoli install image.

Tivoli User AdministrationA Tivoli product that provides a graphical user interface (GUI) for centralizedmanagement of user and group accounts. It offers efficient, automated managementof user and system configuration parameters, secure delegation of administrativetasks, and centralized control of all user and group accounts in a network computingenvironment.

TMRSee Tivoli Management Region (TMR).

TMR clientIn a Tivoli environment, any computer—except the TMR server—on which theTivoli Management Framework is installed. The oserv daemon runs on the TMRclient, and the TMR client maintains a local object database. See Tivoli client andTivoli server.

TMR serverA Tivoli server for a specific Tivoli Management Region (TMR). See Tivoli clientand TMR client.

TNRSee Tivoli Name Registry (TNR).

transactional modeIn Tivoli Software Distribution, a mode of executing operations in which all actionsmust either succeed or fail. At the conclusion of the operation, if the system is notleft in a stable state, the system returns to its initial state.


Glo

ssary

U

undo operationIn Tivoli Software Distribution, a change management operation that returns thesystem to its state prior to the execution of the previous install or remove operation.

undoable modeIn Tivoli Software Distribution, a mode of executing operations in which operationscan be rolled back even if they are already committed.

undoable-in-transactional modeIn Tivoli Software Distribution, a mode of executing operations in which disk spacefor backup copies is reserved during preparation phase, which minimizes the risk offailure during the commit phase because of insufficient disk space.

user profile(1) In computer security, a description of a user that includes such information asuser ID, user name, password, access authority, and other attributes obtained atlogon. (2) In Tivoli User Administration, a profile that is used to manage useraccounts, including account information, home directories, startup files, and groupmembership.

V

validation policyIn a Tivoli environment, policy that ensures that all resources in a policy regioncomply with the region’s established policy. Validation policy prevents Tivoliadministrators from creating or modifying resources that do not conform to thepolicy of the policy region in which the resources were created.

variable(1) In programming languages, a language object that may take different values, oneat a time. The values of a variable are usually restricted to a certain data type. (I)(2) A quantity that can assume any of a given set of values. (A) (3) A name usedto represent a data item whose value can be changed while the program is running.(4) In the Simple Network Management Protocol (SNMP), a match of an objectinstance name with an associated value. (5) In the NetView command list language,a character string beginning with “&” that is coded in a command list and isassigned a value during execution of the command list.

verify operationIn Tivoli Software Distribution, a change management operation that verifies thesuccessful execution of the last operation.

372 Version 4.0

W

wildcard characterSee pattern-matching character.

working directoryThe directory that is currently in use by an operating system or application. If nopath is specified, this is the directory to which data is written, from which data isdeleted, or in which data is searched.


Glo

ssary

374 Version 4.0

Index

Special Characters.ini files

modifying 77OS/2 91Windows 77

Aaccept operation 264actions

adding directories 52, 61adding files 53, 63adding multiple file/directory 65adding OS/2 desktop objects 86adding OS/2 profile objects 91adding text file objects 95adding Windows NT service 82adding Windows profile objects 77adding Windows registry objects 66adding Windows shell objects 72check disk space 49execute CID program 129execute program 103InstallShield program 129Microsoft Setup Program 133remove actions 133restart 106

addingcommand lines 95directories 61files 63lines to text files 95multiple file/directory 65OS/2 desktop folder 86OS/2 desktop program 88OS/2 desktop shadow 90OS/2 profile items 94

adding (continued)tokens 95Windows NT service 82Windows profile objects 77Windows registry objects 66

Adding objects to the software package 49Administrator, Web Interface 277after build programs 113asynchronous delivery 6attributes, UNIX 122authorization roles 349

admin 19, 349install-product 19, 349senior 18, 349super 18, 349user 19, 349

auto reboot mode 116AutoPack

command 149configuration file 152differencing phase 151excluding .INI files 173excluding registry entries 171excluding text files 170file system sections 153first snapshot 167monitoring registry entries 171monitoring text files 169monitoring Windows profiles 172OS/2 desktop 156OS/2 profiles 155OS/2 system files 156preparation machine 149result 180second snapshot 184supported platforms 149, 151system components 151text file sections 154Windows profile sections 154


Ind

ex

AutoPack (continued)Windows registry sections 155working directory 168

autopack command 164AutoPack Guided Process

automatic installation 181first snapshot 167manual installation 175scenario 163second snapshot 177starting 166

autopack.inicustomizing 157, 168UNIX default 162UNIX systems 162Windows NT default 160

BBAROC file 320before build programs 113building the software package

convert operation 242import operation 237save as option 135

Ccalculating size of software packages 241change management operations 244

accept 18, 264commit 18, 265default settings 118install 247remove 18, 260undo 18, 262verify 18, 267

change management status featuredisabling 301enabling 300

check disk space action 49

checkpoint restart 7, 205checks 118, 249command lines, adding 95commands

autopack 164df 216msiexec 143odadmin 209swap 216wbkupdb 25wcrtadmin 280wcrtquery 312wdepot 220wdlssp 246wfptosp 2winstall 29, 30winstsp 220, 247wldsp 219, 220wmdist 210, 211, 218, 219wrpt 200, 208wrunquery 307wsetspat 284wswsprim 302wuldsp 219, 220wwebrget 284wwebrset 284

commit operation 265, 266committable mode 114components, installing 21compute CRC 175conditions

examples 51, 67, 73software package-level 110using 3

configuration file, customizing 157configuration repository

updating with Tivoli Software Distributiondata 295

using with Software Distribution 294configuring repeater as depot 219configuring repeaters 198controlling distributions 7converting software packages

built to not-built 243not-built to built 243

corequisite files 144

376 Version 4.0

create directories option 56creating

a new software package 45using AutoPack 45using the PDF Importer 45

a shortcut 72profile managers 226profiles 224

Ddatabase mode 227dataless mode 227default variables 258deleting software package profiles 238depot, permanent storage 205, 208, 219depoting 7descend directories option 56df command 216dialogs

Install Options 317Tivoli Enterprise Console 317Variable List Editor 54, 125Web Interface access pages 285

differencing phase 151directories, adding 52, 61disk space, checking 49disposable option 249distributing nested software packages 268distribution manager 198distribution status 260

Ee-mail, sending 121editing software packages 127endpoint gateway 10endpoint manager 200endpoints 10, 200events 313execute CID program action 129

execute program actionembedding MSI packages 142using 103

exporting software packages 244

Ffile package migration 4file system objects

including and excluding 153types 11

file version support 6, 55files

autopack.ini 152BAROC file 320check.bat 341check_OS.log 338check_OSÔm3381.0.spd, 338check_OS.spd 331, 341D_upgW98SE.inf 333inst_w2000.spd 341inst_W98SE.sp 333inst_W98SE.spb 336logonyes.reg 333ntspx.spd 323S_upgW98.inf 333SDGui_l10n.spb 39spxi386.exe 325tecad_sd.baroc 320tecad_sd.conf 315, 318tecad_sdnew.baroc 315unattended.txt 343Unattended.txt 340userlink.htm 286w2000.spd 343

files, adding 53, 63Filter keyword 319first snapshot 167forcing an operation 118


Ind

ex

Ggateway component 21general properties 110Generic container 46, 58GID 122

Hhidden web view mode 282historical database feature 293

disabling 301enabling 300installing 23requirements 300

hung distributionsavoiding by setting wmdist parameters 211configuring wmdist parameters 211

Iimporting

built software packages 237not-built software packages 237

importing software packages 233install operation 247Install Options dialog 317installation

Install Product 28winstall 29

installingfrom depot 220, 250language support 38Tivoli Software Distribution components 21Tivoli Software Distribution TEC

Integration 314InstallShield Program action, redirected

installation 130InstallShield Program Builder 132Inventory integration

authorization roles 301change management status feature 293

Inventory integration (continued)configuration repository 293, 294configuration repository tables 295disabling change management status

feature 301disabling historical database feature 301enabling change management status

feature 300enabling historical database feature 300historical database feature 293query facility 295wcrtquery command 312wswsprim command 302

Kkeyword, Filter 319

Llanguage support 38launching Software Package Editor 42links, creating 72loading software package on repeater depot 220locked file support 5locked files, renaming 56log file options 120log host 121logging information, TEC events 313

MMDist 2 (multiplexed distribution)

assured delivery 6asynchronous delivery 6checkpoint restart 7depoting 7distribution control 7overview 6, 204

378 Version 4.0

MDist 2 (multiplexed distribution) (continued)pending distribution queues 7

Microsoft Setup Program action 133Microsoft Setup Program Builder 133migration, file packages 4modes 266MSI installation packages 139msiexec command 143

Nnative installation 130nested software packages 13

distributing 268scenario 272specifying 126

network drive installation 130, 189notices 121

Oodadmin command 209operation modes

auto reboot 116committable 114default settings 114reboot 116, 256transactional 115, 255undoable 115, 256undoable-in-transactional 116

order of execution 108, 127OS/2 desktop folder, adding 86OS/2 desktop objects 11OS/2 desktop program, adding 88OS/2 desktop sections 156OS/2 desktop shadow, adding 90OS/2 profile items, adding 94OS/2 profile objects 11OS/2 profiles sections 155OS/2 system files sections 156overriding registry permissions 176

PPackage Definition File (PDF) 185PDF Importer Tool 4, 185pending distribution queues 7permanent storage 219policy regions 9, 224

configuring 281hidden 282public 282restricted 282setting attribute 284

preparation machine 149previewing an operation 118primary software package 126profile managers 224

creating 226modes 227

profilescreating 224overview 9

program actionsexecute CID programs 129Execute program 104, 193InstallShield program 129Microsoft Setup Program 133

propertiesediting 127general 110modifying 127software package 127, 239, 240software package-level 109software package object 239

public web view mode 282

Qqueries, executing 251query facility 295query library, SWDIST_QUERIES 295


Ind

ex

Rreboot mode 116, 256redirected installation 130, 189registry permissions, overriding 176remove actions 133remove empty directories option 56remove if modified 55, 176remove operation

change management operation 260modes 261

renaming locked files 56repair functionality 117repair options 248repeater

configuring 208configuring as depot 219depot 205gateway 204parameters 211standalone 204verifying path 208

repeater depotconfiguring 219listing entries 220loading software package 219removing software packages 220space allocation 212

replace if existing 55, 176replace if target is newer 55restart action 106

Ssaving default variables 125saving software packages 135scheduled jobs 252scripts

swdis_db2_upgrade.sql 297swdis_ms_sql_upgrade.sql 298swdis_ora_upgrade.sql 299swdis_syb_upgrade.sql 299swdistecsrvr_inst.sh 315

second snapshot 177, 184

security, authorization roles 18segments 220server component 21setting resource roles 280setting TMR roles 279setup variations 192shared files 60, 65, 160shared object support 5shortcuts, creating 72software categories 288software package block 16, 135software package block, maximum size 16, 242software package block (SPB) path 112software package definition (.spd) file 15, 243Software Package Definition (.spd) file 137Software Package Editor (SPE) 11, 14, 41, 44,

184installing 22launching 41, 42managed node 240on endpoint 42

software package file types 45software package object

definition 16properties 239

software package profile, deleting 238software packages

built format 16calculating size 241converting 242copyright 123creating 45description 122, 289exporting 244formats 135importing 233naming 48, 111nesting 126not-built format 15properties 109, 127, 239, 240saving 135text version 15, 137version 111, 289

software packages, nested 13source host 9, 112, 205, 238source host component 22

380 Version 4.0

SPB path 112, 237, 243stage area 112, 256stop on failure 55, 111subscriber web view mode 282subscribers

definition 10profile manager 224setting 230

swap command 216swdis_db2_upgrade.sql script 297swdis_ms_sql_upgrade.sql script 298swdis_ora_upgrade.sql script 299swdis_syb_upgrade.sql script 299SWDIST_QUERIES 295swdistecsrvr_inst.sh script 315system components, AutoPack 151

TTEC component 23TEC integration 313tecad_sd.baroc file 320tecad_sd.conf file 315, 318tecad_sdnew.baroc file 315text file objects 11text file objects, adding 95text file sections, AutoPack 154timeout settings 259Tivoli desktop operations 17Tivoli Enterprise Console 313Tivoli Enterprise Console dialog 317Tivoli Management Region (TMR)

managed resources 225policy regions 9, 224profile managers 9, 224profiles 9, 224subscribers 10, 224

Tivoli Software Distribution, supportedplatforms 1

TMR server 223tokens, adding 95Tools

InstallShield Program Builder 132PDF Importer 185

transactional mode 115, 255

UUID 122undo operation

change management operation 262modes 263

undoable-in-transactional mode 116undoable mode 115, 256uninstalling

NetWare gateway 37OS/2 endpoints 36Tivoli Software Distribution 34

UNIX attributes 122upgrading scenarios

Windows 95 to Windows 98 SecondEdition 331

Windows NT 4.0 with Service Pack 5 or6 323

Windows NT 4.0 Workstation to Windows2000 Professiona 339

UserLink.htm file 285

VVariable List Editor dialog 54, 125variables

built-in 3, 54, 76, 124saving defaults 125

verify CRC 175verify operation 267

Wwbkupdb command 25wcrtadmin command 280wcrtquery command 312wdepot command 220


Ind

ex

wdlssp command 246Web Interface

activating 277configuring 283configuring policy regions 281creating administrator 277setting resource roles 280setting TMR roles 279software package blocks 289software package description 123UserLink.htm file 285

Web Interface access page dialogs 285web view mode 282

default setting 119hidden 119, 282public 119, 282setting 284subscriber 119, 282

wfptosp command 2wildcards 53, 153, 154, 155, 156Windows 95 to Windows 98 Second Edition,

upgrading 331Windows NT 4.0 with Service Pack 5 or 6,

upgrading 323Windows NT 4.0 Workstation to Windows 2000

Professional, upgrading 339Windows NT service, adding 82Windows profile objects

adding 77types 11

Windows profile sections 154Windows registry objects 11, 66Windows registry sections 155Windows shell objects

adding 72types 11

winstall command 29, 30winstsp command 220, 247wldsp command 219wmdist

configuring repeater parameters 219repeater parameters 218

wmdist repeater parameters 211working directory 168wrpt command 200, 208wrunquery command 307

wsetspat command 284wswsprim command 302wuldsp command 219, 220wwebrget command 284wwebrset command 284

382 Version 4.0

Printed in the United States of Americaon recycled paper containing 10%recovered post-consumer fiber.

GC32-0651-00