tivoli software distribution user s...

Tivoli® Software DistributionUser’s GuideVersion 4.1

Tivoli Software Distribution User’s Guide, Version 4.1

Copyright Notice

© Copyright IBM Corporation 2000, 2001. All rights reserved. May only be used pursuant toa Tivoli Systems Software License Agreement, an IBM Software License Agreement, orAddendum for Tivoli Products to IBM Customer or License Agreement. No part of thispublication may be reproduced, transmitted, transcribed, stored in a retrieval system, ortranslated into any computer language, in any form or by any means, electronic, mechanical,magnetic, optical, chemical, manual, or otherwise, without prior written permission of IBMCorporation. IBM Corporation grants you limited permission to make hardcopy or otherreproductions of any machine-readable documentation for your own use, provided that eachsuch reproduction shall carry the IBM Corporation copyright notice. No other rights undercopyright are granted without prior written permission of IBM Corporation. The document isnot intended for production and is furnished “as is” without warranty of any kind. Allwarranties on this document are hereby disclaimed, including the warranties ofmerchantability and fitness for a particular purpose.

U.S. Government Users Restricted Rights—Use, duplication or disclosure restricted by GSAADP Schedule Contract with IBM Corporation.

Trademarks

IBM, Tivoli, the Tivoli logo, AIX, AS/400, DB2, OS/2, OS/400, Tivoli Enterprise, and TMEare trademarks or registered trademarks of International Business Machines Corporation orTivoli Systems Inc. in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of MicrosoftCorporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

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

Other company, product, and service names may be trademarks or service marks of others.

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

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiiiWho Should Read This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Prerequisite and Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

What This Guide Contains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

Conventions Used in This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii

Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii

Tivoli Software Distribution Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii

Accessing Publications Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix

Ordering Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxx

Providing Feedback about Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . xxx

Contacting Customer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxx

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

New Features in Version 4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Overview of Tivoli Software Distribution Highlights . . . . . . . . . . . . . . . . . . . 5

The Tivoli Software Distribution Environment . . . . . . . . . . . . . . . . . . . . . . . 11

Source Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Distribution Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

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

Object-Related Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

System Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Program Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Nested Software Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Software Package Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

iiiTivoli Software Distribution User’s Guide

Software Package Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Software Package (.sp) File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

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

Software Package Block (.spb) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Software Package Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Choosing a Software Package Format . . . . . . . . . . . . . . . . . . . . . . . . . 19

Tivoli Desktop Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Change Management Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Depot Management Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Data Movement Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

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

Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Tivoli Software Distribution Components. . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Tivoli Server Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Managed Node Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Endpoint Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Components in the Software Distribution Environment. . . . . . . . . . . . . 31

Installing Tivoli Software Distribution Components . . . . . . . . . . . . . . . . . . . 32

Installation Mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Installing Tivoli Software Distribution with Tivoli Software InstallationService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Installing Tivoli Software Distribution with the Tivoli Desktop. . . . . . . 35

Installing Tivoli Software Distribution Using the winstall Command 36

Creating RIM Objects and Database Tables for Activity Planner orCCM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Creating Database Tables and Queries . . . . . . . . . . . . . . . . . . . . . 37

Creating RIM Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

iv Version 4.1

Installing the Tivoli Software Distribution Java Endpoint PackageEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Installation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Installing the Tivoli Software Distribution Pristine Tool . . . . . . . . . . . . 44

Finishing Off. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Upgrading from Tivoli Software Distribution 4.0 . . . . . . . . . . . . . . . . . . . . . 45

Upgrading Tivoli Software Distribution, Version 4.0 with the TivoliSoftware Installation Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Upgrading Tivoli Software Distribution, Version 4.0 from the TivoliDesktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Upgrading Tivoli Software Distribution, Version 4.0 Using the wpatchCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Removing Tivoli Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Uninstalling Tivoli Software Distribution Endpoints . . . . . . . . . . . . . . . 49

Uninstalling the NetWare Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Enabling Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Language Support for Endpoint Components . . . . . . . . . . . . . . . . . . . . 52

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

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

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

The Software Package Editor Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Creating the Appsample Software Package. . . . . . . . . . . . . . . . . . . . . . . . . . 58

Naming the Appsample Software Package . . . . . . . . . . . . . . . . . . . . . . 60

Checking Disk Space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Adding Directories and Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

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

Adding Windows Operating System Directories and Files . . . . . . 73

vTivoli Software Distribution User’s Guide

Adding Windows Registry Objects. . . . . . . . . . . . . . . . . . . . . . . . 79

Adding Windows Shell Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Adding Windows Profile Objects . . . . . . . . . . . . . . . . . . . . . . . . . 90

Adding Windows NT Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

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

Adding OS/2 Desktop Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Adding OS/2 Profile Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Adding Text File Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Adding an Execute Program Action . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Adding the Restart Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

The Appsample Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

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

Setting Software Package-level Properties . . . . . . . . . . . . . . . . . . . . . . . . . 122

General Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

The Dependency Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Server Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Setting Server Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Setting Advanced Server Options . . . . . . . . . . . . . . . . . . . . . . . . 129

Log File Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Variable List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Nested Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Editing Software Package Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Program Actions in the Software Package Editor . . . . . . . . . . . . . . . . . . . . 144

The Execute CID Program Action . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

The InstallShield Program Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

The Microsoft Setup Program Action . . . . . . . . . . . . . . . . . . . . . . . . . 149

Remove Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

vi Version 4.1

Saving the Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Chapter 4. Using Tivoli Software Distribution onOS/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Defining Software Packages with OS/400 Objects . . . . . . . . . . . . . . . . . . . 156

The OS/400 Native and Integrated File Systems. . . . . . . . . . . . . . . . . . . . . 158

Using the OS/400 Software Package Editor . . . . . . . . . . . . . . . . . . . . . . . . 159

Launching the OS/400 Software Package Editor. . . . . . . . . . . . . . . . . 159

Adding OS/400 Libraries and Objects . . . . . . . . . . . . . . . . . . . . . . . . 161

Adding OS/400 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Removing OS/400 Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Removing OS/400 Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Adding OS/400 Licensed Programs . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Removing OS/400 Licensed Programs . . . . . . . . . . . . . . . . . . . . . . . . 170

Changing an OS/400 Sysval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Using Non-OS/400-Specific Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Adding Non-Native Objects to the OS/400 Native File System. . . . . . 172

Running an OS/400 Executable Program . . . . . . . . . . . . . . . . . . . . . . 175

The Data Moving Service in an OS/400 Environment . . . . . . . . . . . . . . . . 178

Chapter 5. Embedding MSI Installation Packages ina Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Benefits of Embedding MSI Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Creating a Software Package That Embeds an MSI Installation Package 183

Using the Wizard to Embed an MSI Package . . . . . . . . . . . . . . . . . . . 184

Using Dialogs to Embed or Edit an MSI Package . . . . . . . . . . . . . . . 189

Making an MSI Installation Conditional . . . . . . . . . . . . . . . . . . . . . . . 197

Chapter 6. How Does AutoPack Work? . . . . . . . . . . . . . . . . 201AutoPack Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

viiTivoli Software Distribution User’s Guide

AutoPack Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Customizing the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Notes for Certain User Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 210

Dealing with Shared Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Autopack.ini Default for Windows NT 4.0 and Windows 2000 . . . . . . 213

Autopack.ini Default for Windows 98 . . . . . . . . . . . . . . . . . . . . . . . . 214

Autopack.ini Default for UNIX Systems . . . . . . . . . . . . . . . . . . . . . . 216

Chapter 7. Generating a Software Package UsingAutoPack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Running AutoPack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Creating the First Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

The Manual Installation Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Resuming the Second Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

The Automatic Installation Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Chapter 8. Using the PDF Importer Tool . . . . . . . . . . . . . . . 239The Package Definition File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

PDF Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Package Definition Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

SetupVariation Setup Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Setup Package for Inventory Section . . . . . . . . . . . . . . . . . . . . . . . . . 240

FileIndex Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

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

Using the PDF Importer Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Sample Package Definition File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

NAVWNT.PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Chapter 9. Understanding the DistributionEnvironment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

viii Version 4.1

Introducing NoonTide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Network Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Subnet 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Subnet 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Subnet 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Subnet 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Subnet 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Subnet 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Subnet 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Creating a Repeater Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Configuring Repeater Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Setting Repeater Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Step 1: List the Current Settings of the Repeaters’ Parameters 265

Step 2: Determine the Disk Space Requirements of theApplications to be Distributed . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Step 3: Check that the Electron and Pescado Sites Have theRequired Disk Space and Memory . . . . . . . . . . . . . . . . . . . . . . . 269

Step 4: Set Electron’s Repeater Parameters. . . . . . . . . . . . . . . . . 271

Step 5: Set Pescado’s Repeater Parameters. . . . . . . . . . . . . . . . . 272

Step 6: Verify that the Repeater Parameters are Set Correctly 272

Step 7: Restart the Repeater. . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Using Repeater Depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Chapter 10. The Distribution Process. . . . . . . . . . . . . . . . . . 277Creating a Tivoli Software Distribution Profile . . . . . . . . . . . . . . . . . . . . . . 278

Setting the Profile Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

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

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

ixTivoli Software Distribution User’s Guide

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

Deleting a Software Package Profile . . . . . . . . . . . . . . . . . . . . . . . . . 290

Software Package Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

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

Converting a Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Not-built to Built . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Built to Not-built . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Exporting a Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Change Management Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Software Package States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Executing Change Management Operations . . . . . . . . . . . . . . . . . . . . 298

Install Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Remove Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Undo Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Accept Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

Commit Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Verify Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

Distributing Nested Software Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Things to Consider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Nested Package Distribution Scenario . . . . . . . . . . . . . . . . . . . . 330

Chapter 11. Tivoli Software Distribution WebInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Basic Tivoli Software Distribution Web Interface Functions . . . . . . . . . . . . 334

Enabling Basic Tivoli Software Distribution Web Interface Functions 335

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

Configuring Policy Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Software Package Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

Configuring Tivoli Software Distribution Web Interface . . . . . . . . . . . 342

x Version 4.1

Setting the Policy Region Attribute . . . . . . . . . . . . . . . . . . . . . . 343

Setting the Software Package Object Attribute . . . . . . . . . . . . . . 344

Using the Basic Tivoli Software Distribution Web Interface . . . . . . . . 345

Notifying Users about Web Interface . . . . . . . . . . . . . . . . . . . . . 348

Enhanced Tivoli Software Distribution Web Interface Functions . . . . . . . . . 353

Enabling Tivoli Software Distribution Web Interface . . . . . . . . . . . . . 355

Creating the WebUI and WebUI-Restr1 Administrators . . . . . . . . 356

Configuring Policy Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Software Package Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

Defining Software Categories. . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Managing the Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

Using the Enhanced Tivoli Software Distribution Web Interface . . . . . 360

Using the Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

Managing the Local Machine from the Tivoli SoftwareDistribution Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Chapter 12. Integrating the Tivoli Inventory Database 375The Configuration Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

The Query Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Updating the Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Upgrading from Tivoli Inventory, Version 3.6.x or Later. . . . . . . . . . . . . . . 380

Upgrading a DB2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Upgrading a SQL Server Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

Upgrading an Oracle Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

Upgrading a Sybase Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Upgrading an Informix Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Enabling the Historical Database and Change Management Status Features 384

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

Creating the SWDIST_QUERIES Query Library . . . . . . . . . . . . . . . . . . . . 386

xiTivoli Software Distribution User’s Guide

Running a Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

Desktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

Modifying SWDISTDATA_QUERY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

Desktop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

Chapter 13. Integrating the Tivoli Enterprise Console 397Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

The tecad_sd.conf File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Tivoli Software Distribution Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

Chapter 14. Creating and Executing Activity Planswith Activity Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Using the Activity Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Launching the Activity Planner GUIs . . . . . . . . . . . . . . . . . . . . . . . . . 411

Activity Planner Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Types of Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Defining an Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

Assigning Targets to an Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

Specifying a List of Target Names . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

Specifying a File Name Containing a List of Targets . . . . . . . . . . . . . 419

Specifying an Inventory Subscriber as a Target . . . . . . . . . . . . . . . . . 419

Specifying Query Library Subscribers as Targets . . . . . . . . . . . . . . . . 420

Using Variables to Specify Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . 420

Specifying a Profile Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Conditioning the Execution of Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 423

Sorting Activities in Order of Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . 425

Scheduling When to Execute an Activity . . . . . . . . . . . . . . . . . . . . . . . . . . 426

xii Version 4.1

Defining the Final Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

Defining the Properties of the Activity Plan . . . . . . . . . . . . . . . . . . . . . . . . 429

Scheduling the Activity Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430

Scheduling Plans to Execute within a Time Interval . . . . . . . . . . 430

Scheduling Activity Plans to Run Periodically . . . . . . . . . . . . . . 432

Defining the Targets of an Activity Plan. . . . . . . . . . . . . . . . . . . . . . . 435

Defining Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

Saving the Activity Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

Removing Activity Plans or Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

Submitting and Monitoring Activity Plans . . . . . . . . . . . . . . . . . . . . . . . . . 439

Activity Plan Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

Submitting an Activity Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

Pausing, Resuming, Canceling, and Restarting an Activity . . . . . . . . . 444

Launching the Distribution Status Console . . . . . . . . . . . . . . . . . . . . . 444

Updating the Status of an Activity Plan . . . . . . . . . . . . . . . . . . . . . . . 445

Deleting Submitted Activity Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Cleaning Up the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Chapter 15. Change Configuration Management . . . . . . 449Reference Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

Web Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

Reference Model Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456

Using CCM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456

Creating the Reference Model Structure . . . . . . . . . . . . . . . . . . . . . . . 457

Adding Elements to a Reference Model . . . . . . . . . . . . . . . . . . . . . . . 459

Adding an SWD Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Adding an Inventory Element . . . . . . . . . . . . . . . . . . . . . . . . . . 462

xiiiTivoli Software Distribution User’s Guide

Assigning Subscribers to a Reference Model . . . . . . . . . . . . . . . . . . . 464

Assigning a CSV Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . 465

Assigning a Profile Manager Subscriber . . . . . . . . . . . . . . . . . . . 467

Assigning a Static Subscriber. . . . . . . . . . . . . . . . . . . . . . . . . . . 468

Assigning an Inventory Subscriber . . . . . . . . . . . . . . . . . . . . . . . 469

Assigning Query Library Subscribers . . . . . . . . . . . . . . . . . . . . . 470

Saving a Reference Model in XML Format . . . . . . . . . . . . . . . . . . . . 472

Modifying a Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

CCM and Activity Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

Previewing an Activity Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

Submitting an Activity Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

Creating CCM Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

Chapter 16. Data Moving Service . . . . . . . . . . . . . . . . . . . . . . 481Configuring the Data Moving Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482

Data Moving Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Sending Data to Multiple Destinations . . . . . . . . . . . . . . . . . . . . . . . . 483

Data Retrieval from Multiple Origins . . . . . . . . . . . . . . . . . . . . . . . . . 484

Deleting a File on Multiple Systems . . . . . . . . . . . . . . . . . . . . . . . . . 485

The Command Line Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

Using Pre- and Post-Processing Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Chapter 17. Pristine Installations. . . . . . . . . . . . . . . . . . . . . . . 491Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

Typical Network Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

Pristine Preparation Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

Code Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

Dedicated Pristine Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494

xiv Version 4.1

Code Server Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494

Pristine Tool Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495

System Diskette Creation Prerequisites. . . . . . . . . . . . . . . . . . . . 496

Pristine System Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

Dedicated Pristine Gateway Prerequisites . . . . . . . . . . . . . . . . . . 497

Installing the Pristine Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

Windows Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

Pristine Installation Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

Step 1: Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

Code Server Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

Code Server Object Configurations . . . . . . . . . . . . . . . . . . . . . . 499

Step 2: Creating and Maintaining Code Server Objects. . . . . . . . . . . . 500

Creating a New Code Server Object. . . . . . . . . . . . . . . . . . . . . . 501

Editing a Code Server Object. . . . . . . . . . . . . . . . . . . . . . . . . . . 506

Deleting a Code Server Object. . . . . . . . . . . . . . . . . . . . . . . . . . 506

Step 3: Creating and Maintaining Code Server Object Configurations 507

Customizing the Operating System Response File . . . . . . . . . . . 507

Customizing the Tivoli Management Agent Response File . . . . . 510

Adding Device Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510

Partitioning the Client Hard Disk . . . . . . . . . . . . . . . . . . . . . . . . 512

Defining a Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 513

Adding Configuration-Specific Information . . . . . . . . . . . . . . . . 513

Step 4: Preparing a System Diskette. . . . . . . . . . . . . . . . . . . . . . . . . . 513

Step 5: Creating a Pristine Boot Diskette . . . . . . . . . . . . . . . . . . . . . . 516

Step 6: Running a Pristine Installation . . . . . . . . . . . . . . . . . . . . . . . . 518

Pristine Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 518

OS/2 Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Pristine Installation Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Step 1: Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

xvTivoli Software Distribution User’s Guide

Code Server Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

Code Server Object Configurations . . . . . . . . . . . . . . . . . . . . . . 522

Step 2: Creating and Maintaining a Code Server Object . . . . . . . . . . . 523

Creating a New Code Server Object. . . . . . . . . . . . . . . . . . . . . . 523

Editing a Code Server Object. . . . . . . . . . . . . . . . . . . . . . . . . . . 525

Deleting a Code Server Object. . . . . . . . . . . . . . . . . . . . . . . . . . 526

Step 3: Adding System Files to Code Server Objects . . . . . . . . . . . . . 526

THINSRV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527

Configuring MPTS for Non-standard Network Adapters . . . . . . . 528

GETREXX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

Step 4: Creating and Maintaining Code Server Object Configurations 529

Customizing the Operating System Response File . . . . . . . . . . . 529

Customizing the Additional Required Software Response Files 531

Adding Device Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

Partitioning the Client Hard Disk . . . . . . . . . . . . . . . . . . . . . . . . 531

Defining a Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

Adding Configuration-specific Information. . . . . . . . . . . . . . . . . 532

Step 5: Preparing the System Diskettes . . . . . . . . . . . . . . . . . . . . . . . 532

SEDISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

Adding the LAN CID Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

Step 6: Creating Pristine Boot Diskettes. . . . . . . . . . . . . . . . . . . . . . . 534

Step 7: Running a Pristine Installation . . . . . . . . . . . . . . . . . . . . . . . . 536

Pristine Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 536

Chapter 18. Upgrading Windows NT 4.0 Workstationto Windows 2000 Professional . . . . . . . . . . . . . . . . . . . . . . . . . 539

Environment Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539

Creating a Response File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

Copying the Files That You Need to Perform the Migration to the TivoliServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

xvi Version 4.1

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

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

Creating the Software Package on the Tivoli Server . . . . . . . . . . . . . . . . . . 544

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

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

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

Chapter 19. Upgrading Windows NT 4.0 with ServicePack 5 or 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

Environment Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

Downloading the ntspx.spd Definition File to the Tivoli Server . . . . . . . . . 550

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

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

Creating the Software Package on the Tivoli Server . . . . . . . . . . . . . . . . . . 554

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

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

Appendix A. Authorization Roles. . . . . . . . . . . . . . . . . . . . . . . 557Setting Up Tivoli Software Distribution Profiles. . . . . . . . . . . . . . . . . . . . . 557

Defining and Deleting Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558

Performing Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

Performing Activity Planner Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

Performing CCM Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562

Performing Web Interface Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587

xviiTivoli Software Distribution User’s Guide

xviii Version 4.1

Notices

References in this publication to Tivoli Systems or IBM products,programs, or services do not imply that they will be available in 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 valid intellectual property or other legallyprotectable right of Tivoli Systems or IBM, any functionallyequivalent product, program, or service can be used instead of thereferenced product, program, or service. The evaluation andverification of operation in conjunction with other products, exceptthose expressly designated by Tivoli Systems or IBM, are theresponsibility of the user. Tivoli Systems or IBM may have patentsor pending patent applications covering subject matter in thisdocument. The furnishing of this document does not give you anylicense to these patents. You can send license inquiries, in writing, tothe IBM Director of Licensing, IBM Corporation, North CastleDrive, Armonk, New York 10504-1785, U.S.A.

Use of Apache Software

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

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

The Apache Software License, Version 1.1

Copyright (c) 1999 The Apache Software Foundation. All rightsreserved.

Redistribution and use in source and binary forms, with or withoutmodification, are permitted provided that the following conditionsare met:

1. Redistributions of source code must retain the above copyrightnotice, this list of conditions and the following disclaimer.

xixTivoli Software Distribution User’s Guide

2. Redistributions in binary form must reproduce the abovecopyright notice, this list of conditions and the followingdisclaimer in the documentation and/or other materials providedwith the distribution.

3. The end-user documentation included with the redistribution, ifany, must include the following acknowledgment: “This productincludes software developed by the Apache Software Foundation(http://www.apache.org/).” Alternately, this acknowledgment mayappear in the software itself, if and wherever such third-partyacknowledgments normally appear.

4. The names “Xerces” and “Apache Software Foundation” mustnot be used to endorse or promote products derived from thissoftware without prior written permission. For writtenpermission, please contact [email protected].

5. Products derived from this software may not be called “Apache”,nor may “Apache” appear in their name, without prior writtenpermission of the Apache Software Foundation.

THIS SOFTWARE IS PROVIDED “AS IS” AND ANYEXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUTNOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS FOR A PARTICULARPURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THEAPACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORSBE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OFSUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, ORPROFITS; OR BUSINESS INTERRUPTION) HOWEVERCAUSED AND ON ANY THEORY OF LIABILITY, WHETHER INCONTRACT, STRICT LIABILITY, OR TORT (INCLUDINGNEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUTOF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THEPOSSIBILITY OF SUCH DAMAGE.

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

xx Version 4.1

originally based on software copyright (c) 1999, InternationalBusiness Machines, Inc. For more information on the ApacheSoftware Foundation, please see <http://www.apache.org/>.

ISO 9001 Certification

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

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

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

xxiTivoli Software Distribution User’s Guide

xxii Version 4.1

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 guide explains the concepts and procedures necessary for you toeffectively use Tivoli Software Distribution to distribute softwareover local area networks (LANs) and WANs.

Who Should Read This GuideThis guide is intended for system administrators who performsoftware package preparation and deployment operations. Users ofthis guide should have some knowledge of the following:

¶ The UNIX®

and PC platforms

¶ Shell programming

¶ Concepts such as directories, files, and symbolic links

¶ Operating systems running on target machines to which softwareis distributed

Prerequisite and Related DocumentsTo use the information in this guide, you should be familiar with thefollowing manuals:

¶ Tivoli Software Distribution Reference Manual

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

xxiiiTivoli 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 Guide ContainsTivoli Software Distribution User’s Guide contains the followingsections:

¶ Chapter 1, “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.

¶ Chapter 2, “Planning and Installing Tivoli Software Distribution”on page 23

Describes how to install Tivoli Software Distribution usingdifferent installation mechanisms.

¶ Chapter 3, “Creating a Software Package” on page 53

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

xxiv Version 4.1

¶ Chapter 4, “Using Tivoli Software Distribution on OS/400” onpage 155

This chapter describes the Tivoli Software Distribution featuresthat are specific for OS/400® operating systems.

¶ Chapter 5, “Embedding MSI Installation Packages in a SoftwarePackage” on page 181

Explains how to embed a Microsoft®

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

¶ Chapter 6, “How Does AutoPack Work?” on page 201

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

¶ Chapter 7, “Generating a Software Package Using AutoPack” onpage 217

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.

¶ Chapter 8, “Using the PDF Importer Tool” on page 239

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.

¶ Chapter 9, “Understanding the Distribution Environment” onpage 251

Introduces a Tivoli management region scenario to illustrate howto configure a network topology. This chapter provides steps forsetting up a distribution environment that uses endpointgateways, repeaters, and repeater depots.

¶ Chapter 10, “The Distribution Process” on page 277

Preface

xxvTivoli Software Distribution User’s Guide

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 and unbuild function, using the import and exportfunctions, and performing change management operations.

¶ Chapter 11, “Tivoli Software Distribution Web Interface” onpage 333

The enhanced Tivoli Software Distribution Web Interface enablesWeb users on UNIX and Microsoft® endpoints to download,install, subscribe to, and verify software packages; access andsubscribe to reference models for endpoint synchronization; andmanage locally installed software packages using a Web-enabledbrowser.

¶ Chapter 12, “Integrating the Tivoli Inventory Database” onpage 375

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.

¶ Chapter 13, “Integrating the Tivoli Enterprise Console” onpage 397

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.

¶ Chapter 14, “Creating and Executing Activity Plans with ActivityPlanner” on page 407

The Activity Planner feature enables you to schedule theexecution of a group of activities, submit them to be executed,and monitor and control them. Activities are single operationsthat are performed on a set of targets at specified times.Operations can include Tivoli Software Distribution, Version 4.1operations or Tivoli Management Framework tasks

Preface

xxvi Version 4.1

¶ Chapter 15, “Change Configuration Management” on page 449

Change Configuration Management (CCM) help you to managedifferent, frequent software changes to different groups ofworkstations. It keeps track of software already installed to helpyou decide which workstations need a certain version ofsoftware, and provides a scalable and flexible way of specifyingthe required hardware and software machine configuration. Itthen applies the changes to update the machine to the newconfiguration

¶ Chapter 16, “Data Moving Service” on page 481

The Data Moving Service integrates data movement capabilitiesinto the software package distribution process.

¶ Chapter 17, “Pristine Installations” on page 491

The Pristine feature provides support for installing new operatingsystems on Pristine machines, and then maintaining the newcomputers on the network.

¶ Chapter 18, “Upgrading Windows NT 4.0 Workstation toWindows 2000 Professional” on page 539

Describes how to upgrade Microsoft® Windows NT® Version 4.0Workstation to Windows® 2000 Professional.

¶ Chapter 19, “Upgrading Windows NT 4.0 with Service Pack 5 or6” on page 549

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

¶ Appendix A, “Authorization Roles” on page 557

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

Conventions Used in This GuideThe guide uses several typeface conventions for special terms andactions. These conventions have the following meaning:

Bold Lowercase or mixed-case commands, commandoptions in a syntax statement, the names of objects

Preface

xxviiTivoli Software Distribution User’s Guide

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

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

Online HelpTivoli Software Distribution, Version 4.1 provides contextual onlinehelp. To display help information you can do one of the following:

¶ Select the Help button at the bottom of a dialog to see adescription and the accepted values of the elements contained inthe dialog.

¶ From an open dialog, press F1 to see an explanation of thatdialog.

¶ Select Help from the Help pull-down menu to open the helpbrowser and display the table of contents.

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.

Preface

xxviii Version 4.1

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

Icon for empty software package profile.

Software package profile resources are created in the context of 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” onpage xxx for more information about obtaining Tivoli technicaldocumentation.

Preface

xxixTivoli Software Distribution User’s Guide

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

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 SupportThe Tivoli Customer Support Handbook athttp://www.tivoli.com/support/handbook/ provides informationabout all aspects of Tivoli Customer Support, including thefollowing:

¶ Registration and eligibility.

¶ How to contact support, depending on the severity of yourproblem.

¶ Telephone numbers and e-mail addresses, depending on thecountry you are in.

¶ What information you should gather before contacting support.

Preface

xxx Version 4.1

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.

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

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

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

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

1

1Tivoli Software Distribution User’s Guide

1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

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

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

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

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.1 softwarepackages. No migration is necessary for Version 4.0 softwarepackages. They can co-exist with Version 4.1 software packages inthe Version 4.1 environment. Refer to the Tivoli SoftwareDistribution Reference Manual for more information about thewfptosp command.

New Features in Version 4.1This section lists the new and changed functions of Tivoli SoftwareDistribution:

¶ Version checks

You can define a software package as versionable and specifywhether it is a refresh package or a patch. Refreshes are notinstalled if a later version of the package is already installed.Patches are not installed unless the version to which the patchapplies is already installed.

¶ Dependency

You can define an expression that makes the installation orremoval of a software package dependent on meeting hardwareand software prerequisites.

Highlights

2 Version 4.1

¶ Byte-level differencing

With byte-level differencing, you create and distribute deltapackages for installation, thereby significantly reduce networktraffic. A delta package is created from the differences thistechnology detects between the software package to be installed(version package), and the base package already installed on thetarget system, and only the delta package is distributed. Thedelta package is typically smaller than either the version packageor the base package. The changes contained in the delta packageare applied to the base package thereby upgrading it to the newversion. For a detailed explanation of how byte leveldifferencing works, see the Tivoli Software DistributionReference Manual.

¶ Data movement

This is a feature that provides commands to distribute, retrieve,and delete files from machines in a Tivoli Managementenvironment. It supports ASCII/EBCDIC conversion and codepage translation for text files.

¶ Pristine Operating System Install

This tool provides the capability to make an unattendedinstallation of operating systems (Windows 98 Second Edition,Windows NT 4.0 Workstation and Windows 2000 Professional;OS/2 4.0 and OS/2 4.5) on a system with no operating systeminstalled (even with unpartioned hard disks) or on a system thatis to be completely reformatted. The installation process includesassigning the pristine system to a Tivoli gateway, and optionallyinitiating a Change Configuration Management process.

¶ Windows 2000 Microsoft Installer

Provides the capability to use Tivoli Software Distribution tocreate a software package that embeds a Microsoft SoftwareInstaller (MSI) package. Both Microsoft Installer products andpatches are supported.

¶ Mobile support

This feature enhances the capability to deliver software tomobile users. By means of mobile support, end-users can decide

Highlights


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

which distributions to download or reject. While downloads arein progress, users can also pause and resume them.

¶ Activity Planner

Activity Planner enables you to schedule the execution of agroup of activities, submit them to be executed, and monitor andcontrol them. Activities are single operations that are performedon a set of targets at specified times. Operations can includeTivoli Software Distribution, Version 4.1 operations or TivoliManagement Framework tasks.

¶ Change Configuration Management (CCM)

CCM provides the capability of managing an environment bydefining a reference model in which you specify the combinationof software packages that satisfies the business needs for a set ofworkstation users within an enterprise. It helps you to bring theconfiguration of these machines from their current state to thespecified target state. It also includes support for packageversioning, software dependencies (pre-requisites, co-requisites,and ex-requisites), hardware dependencies and endpoint logins.

¶ Enhanced Tivoli Software Distribution Web Interface

This interface enables Web users on UNIX and Windowsendpoints to download, install, subscribe to, and verify softwarepackages; access and subscribe to reference models for endpointsynchronization; and manage locally installed software packagesand the local software package block repository.

¶ OS/400 endpoint support

The OS/400 endpoint support extends the capabilities of TivoliSoftware Distribution to managing software packages for OS/400target systems. Tivoli Software Distribution includes an OS/400Software Package Editor (SPE). You use the SPE on an NTsystem, which has a TCP/IP connection to an OS/400 systemthat is used as a software package preparation site. You canbuild software packages that include OS/400 objects, such aslibraries, objects, and licensed programs, and changes to OS/400system values. In addition, a software package for an OS/400system can include standard actions to add non-OS/400 files anddirectories to an OS/400 system and to execute user programs on

Highlights

4 Version 4.1

an OS/400 system. The data moving service supports movementof files between OS/400 endpoints and Tivoli SoftwareDistribution Source Hosts.

¶ Install from CD and file server

Enables you to specify that the software package to be installedis to be retrieved from a file server or a CD-ROM rather than onthe source host.

Overview of 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. The new features that Tivoli SoftwareDistribution, Version 4.1 makes available to you, enhance all thefeatures that are retained from Tivoli Software Distribution, Version4.0, the highlights of which are as follows:

¶ Remote distribution and scalability: a centralized point of controlfor automated software distribution across heterogeneousnetwork computing environments.

¶ 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 makes use of a simplified singlecontent packaging format called the software package. All ofthe techniques used to create software packages are based onthis single file format. Therefore, a software package createdusing AutoPack is identical to a package created manuallyusing the Software Package Editor, and both can be editedusing any of the available techniques explained in thischapter.

v Variables

Variables can be used to express any attribute value of typestring contained in the software package, making a software

Highlights


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

package 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 Manualfor more details on using variables in the software 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 canbe 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

¶ Automatic software package generation: AutoPack automaticallygenerates a software package by employing scanning anddifferencing technology, and comparing two successive“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.

Highlights

6 Version 4.1

¶ 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 for more information aboutmigration procedures.

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

v Automatic undo

You can perform an undo operation on the software packageso that, in the event of a fatal error during the installationprocess, the undo operation is triggered automatically andreturns the system to its state prior to the execution of thelast installation or removal operation. This means that anyfiles added by the installation that did not exist before thedistribution are removed. Files that existed before thedistribution and were removed are added back. Files thatexisted prior to the distribution and were replaced, arerestored to the previous copy. This is also true for anyadditions, deletions, or changes made to configuration orsystem 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

Highlights


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

If a locked file is encountered during a distribution, normallyit cannot be updated. Distributing the software package intransactional mode enables you to take advantage of thelocked file support feature, which permits the updating oflocked files by specifying that the target system is to berestarted at the time of installation or at the next regularsystem start up.

v Renaming if locked

This function obviates the need to reboot a workstationimmediately after a distribution when a locked file isencountered. A copy of the file is made and renamed.

v Shared object support

Because many applications use the same resources, such asfiles, directories, and registry entries, these shared objectsmust be identified in the software package. Using a sharedattribute, for example, on files and directories, you can sharefiles and directories among multiple applications. If asoftware package is designed to remove an application from atarget 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.

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 and repair functionality

The repair functionality reduces network congestion. Itidentifies which source and target objects have been modifiedor corrupted since the last successful installation of a

Highlights

8 Version 4.1

software package, and rebuild the software package with onlythese objects rather than installing the entire package again.

¶ 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, using agraphical user interface or commands, you can immediatelycheck the status of each distribution on each target systemwithout waiting until the distribution has completed for alltargets.

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

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, if due to a network error, rather than resending theentire distribution from the source host. If the interruption isdue to a power failure or machine restart, the distribution isresumed from the last successful checkpoint before theinterruption. However, a distribution that you terminaterestarts from the beginning. Paused distributions exploit thecheckpoint restart feature. The checkpoint restart feature is aTivoli Software Distribution default. Refer to the TivoliSoftware Distribution Reference Manual for more informationabout checkpoint restart.

Highlights


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

v Distribution control

You can use MDist 2 to access and control data distributionsinitiated by different applications. The graphical user interface(GUI) displays a list of all completed and pendingdistributions and their status on each endpoint (waiting,successful, failed, in progress, paused, interrupted,unavailable, cancelled, or expired).

v Pending distribution queues

MDist 2 distributions can have three priority levels: low,medium, or high. Priority levels determine the order in 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 (that isSoftware packages) associated with software packagedistributions. This enables software distributions to be storedon nodes closer to the targets. You can push softwarepackages from the depot, rather than from the source host, totarget systems associated with that depot.

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.

Highlights

10 Version 4.1

¶ 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 eliminates theneed to create scripts and programs to configure an application.You can package the required action in the software package.

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

v You can use Tivoli Inventory and the Tivoli ManagementFramework query facility to query a configuration repositoryto determine the appropriate targets of a distribution.Thisfacility also enables you to track information about softwaredistributions and the change management status of softwarepackages on target systems.

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

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

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

The Tivoli Software Distribution EnvironmentWhen you install Tivoli Software Distribution, you add a 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.

Highlights


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

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, where the software packageblock is stored, and where the files referenced in the softwarepackage and software package definition file are located. Any UNIX,OS/2, Windows NT, and Windows 2000 system in your Tivolienvironment can be a source host after Tivoli ManagementFramework and Tivoli Software Distribution are installed.

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.1 enables you to distributesoftware packages to subscribers. A subscriber is an endpoint or aprofile manager that is the target of the distribution. In the Tivolienvironment, an endpoint is a Tivoli client that receives Tivolioperations. Only endpoints can be targets of distributions. Managednodes are no longer supported as targets. The Tivoli ManagementFramework endpoint agent must be installed on managed nodes tobecome possible targets of a software distribution. Each endpoint isassigned to an endpoint gateway, which provides all communicationservices between a group of endpoints and the rest of the Tivolienvironment. The gateway includes the multiplexed distribution

Tivoli Software Distribution Environment

12 Version 4.1

(MDist 2) function, enabling this gateway to act as the fanout pointfor distributions to many endpoints. Refer to the Tivoli ManagementFramework Planning for Deployment Guide for detailed informationabout how endpoints and gateways can be configured and used inthe Tivoli environment.

Tivoli Software Distribution, Version 4.1 supports mobileendpoints.This enables mobile computer users to view a queue of allthe distributions pending for their machine and control when and inwhat order they will receive their distributions. Refer to the TivoliManagement Framework Planning for Deployment Guide for moreinformation about configuring mobile endpoints.

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 beexecuted. The 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

¶ OS/400 objects



1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

v OS/400 librariesv OS/400 objectsv OS/400 licensed programs

¶ 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

¶ Windows NT services

System ActionsThese actions include the following:

¶ Check disk space. Include this check in your software packageto be sure there is sufficient disk space on the target machine.

¶ Restart. Insert this action in your software package if a computeror operating system restart is necessary with the installation ofan application.

¶ OS/400 system value. Use this action to change OS/400 systemvalues (SYSVAL).


14 Version 4.1

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

¶ Install MSI Product Program

¶ Install MSI Patch 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 actioncan be executed only on Windows 98 target systems. You can setconditions on individual objects, or on the entire softwarepackage.

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

¶ 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 for more informationabout 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 Software



1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

Package 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 for moreinformation about using software package definition files and CLIcommands.

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 Tivoli management regions.

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, anddistribution 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.


16 Version 4.1

For instructions on nesting software packages, see “NestedPackages” on page 141. For information about distributing nestedsoftware packages, see “Distributing Nested Software Packages” onpage 327.

Software Package EditorThe Software Package Editor is a graphical interface for creating andcustomizing a software package. It can be installed on any of youravailable managed nodes and endpoints except NetWare endpoints.The Software Package Editor displays a graphical tree view of thesoftware package and its contents. You organize the actions that arecontained in the package in the order in which they are to beexecuted on the target system. There are several techniques availableto create software packages from the Software Package Editorwindow:

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

¶ Use the Install MSI Product tool to map information from anMSI file to a software package.

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

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)



1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

¶ Software package block (.spb)

A software package can be opened in the Software Package Editorregardless of the format. You can then choose to resave it in any ofthe other file types available. For more information about softwarepackage definition parameters, keywords, and formats, refer to theTivoli Software Distribution Reference Manual.

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. Forexample, the .spd file for Microsoft Office 2000 is very long. In thesoftware package file format it is compressed to a much smaller size.A software package in this format is in the not-built format.

Software Package Block (.spb)A software package block bundles all the resources necessary 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.

Software Package Formats

18 Version 4.1

However, the software package block must reside on the source host.When the software package block is distributed to an endpoint, it isnot stored on the endpoint, but is unzipped in the target directory. Byunpacking the zipped file immediately, there is no need foradditional disk space on the endpoint for the .spb file. A softwarepackage that contains all its resources is in the built format. Themaximum size of a software package 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. If the software package is in the not-builtformat, the data to be distributed resides on the source host and isresolved at distribution time. If the software package is in the builtformat, the software package block must reside on the source host.The software package is catalogued at the Tivoli SoftwareDistribution server as a software package object in the Tivolidatabase.

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 formatdoes not contain the files and resources to be distributed, it occupiesa smaller amount of disk space than a software package block.



1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

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. You will ultimately use this hierarchy to associatesoftware packages with target systems. Profiles are the resources thatare distributed. From the Tivoli desktop, you import a softwarepackage into the Tivoli environment by associating it to a TivoliSoftware 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 277 for information about the Tivoli desktop andits functions.

Change Management OperationsYou can use change management operations on software packageobjects 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 catalog it at the Tivoli Software Distribution server, youcan use the following operations to manage how package actions areexecuted. Tivoli Software Distribution performs the following changemanagement operations:

Install Performs the actions needed to install a software package.

RemoveUninstalls a software package.


20 Version 4.1

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 297for more information about change management operations andmodes.

Depot Management OperationsA repeater depot is a data repository that allows you to temporarilyor permanently store distribution data. Storing data in depots reducesnetwork traffic for frequently distributed datasets. Depots are alsobeneficial when you need to resume a distribution that wasinterrupted by unavailable nodes or network failures. Instead ofresending the entire distribution from the source host, MDist 2 sendsonly the undelivered portion. Tivoli Software Distribution, Version4.1 provides two commands to manage repeater depots:

Load Loads a software package on a repeater depot.

UnloadUnloads a software package from a repeater depot.

Data Movement OperationsTivoli Software Distribution, Version 4.1 provides the followingcommands to distribute, retrieve, and delete files from machines in aTivoli Management environment:

Tivoli Desktop Operations


1.O

verviewo

fTivo

liS

oftw

areD

istribu

tion

Send Transfers a file from a Tivoli source host to a set ofspecified Tivoli endpoint in your Tivoli environment.

RetrieveTransfers a file from each specified Tivoli endpoints to aTivoli source host.

Delete Deletes a specified file from one or more endpoints.

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

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

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

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.

Tivoli Desktop Operations

22 Version 4.1

Planning and Installing TivoliSoftware Distribution

The Tivoli Software Distribution application adds softwaredistribution capabilities to the Tivoli environment. This chapterprovides the following:

¶ A list of tasks and checks that you must perform before you startthe installation of or upgrade to Tivoli Software Distribution4.1.See “Before You Start” on page 24.

¶ Information about the components that are included in TivoliSoftware Distribution, Version 4.1 and the type of system onwhich each component must be installed. See “Tivoli SoftwareDistribution Components” on page 25.

¶ Instructions for planning your Tivoli Software Distributionenvironment and installing the application using differentinstallation mechanisms. See “Installing Tivoli SoftwareDistribution Components” on page 32.

¶ Instructions for upgrading from Tivoli Software Distribution,Version 4.0 using different installation mechanisms. See“Upgrading from Tivoli Software Distribution 4.0” on page 45.

¶ Instructions for removing Tivoli Software Distribution, Version4.1. See “Removing Tivoli Software Distribution” on page 47.

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

2


2.P

lann

ing

and

Installin

g

Before You StartBefore you start to install or upgrade to Tivoli Software Distribution4.1, do the following:

¶ Back up the Tivoli databases for all the machines in the Tivolimanagement region.

Creating backups will enable you to return to the state of theobject database before installation if, for some reason, youencounter a problem while installing the product. To create abackup of the Tivoli server and clients, select Backup from theDesktop menu or use the wbkupdb command. Refer to theTivoli Management Framework Reference Guide for informationabout the wbkupdb command.

¶ Ensure that the server, managed nodes, and endpoints, on whichyou intend to install components of Tivoli Software Distribution,Version 4.1, comply with the hardware and softwareprerequisites for the product.

Information about the prerequisites and about compatiblesoftware versions of other products is included in the ReleaseNotes for Tivoli Software Distribution, Version 4.1.

¶ Read the section “Tivoli Software Distribution Components” onpage 25 and decide which of the components you will install onwhich systems.

Note: Several of the components are dependent on othercomponents. The descriptions in this section explain thesedependencies. For example, you cannot install the WebUser Interface unless both Activity Planner and ChangeConfiguration Management (CCM) are installed; youcannot install CCM unless the Historical Databasecomponent is installed, the historical database feature isenabled, and the Activity Planner is installed.

¶ Ensure that you have the required Java components installed forthe Software Distribution you have decided to install.

Table 1 on page 25 shows the Java Components available in theTivoli Management Framework 3.7.1 and their usage in TivoliSoftware Distribution, Version 4.1.

24 Version 4.1

Table 1. Tivoli Management Framework Java ComponentsJava Component APM CCM WebUI SP

EditorWeb UIDepot

Java for Tivoli 3.7 U U U U

Tivoli Java Client Framework 3.7 U U U

Swing for Tivoli 3.7.1 U U U

JavaHelp for Tivoli 3.7.1 U U U

Tivoli MDist2 GUI

Tivoli Java RDBMS Interface(JRIM) 3.7

U U

Tivoli Software Distribution ComponentsTivoli Software Distribution includes components that must beinstalled on the following different types of machine in the SoftwareDistribution environment:

¶ Tivoli management region server (Tivoli server)

¶ Managed node

¶ Endpoint

Refer to the Tivoli Software Distribution Release Notes for moredetailed information about the prerequisites required for theinstallation of the following components.

Tivoli Server ComponentsThe following components must be installed on a Tivoli server:

Tivoli Software Distribution Server, Version 4.1Installs the Tivoli Software Distribution server component.This component includes source host capability.

Tivoli Software Distribution Historical Database, Version 4.1Installs 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.


2.P

lann

ing

and

Installin

g

You must have the Tivoli Inventory product installed prior toinstalling this component. See “Integrating the TivoliInventory Database” on page 375 for in-depth informationabout using this feature to access information from theconfiguration repository.

Tivoli Software Distribution TEC Integration, Version 4.1Installs the files that enable Tivoli Software Distribution tosend events to the Tivoli Enterprise Console® event server(event server) when a Tivoli Software Distribution operationis performed. You must install this integration product oneach event server in your Tivoli management region.

Before installing this component, you must do the following:

¶ Install Version 3.6.2 or later of the Tivoli EnterpriseConsole and the Tivoli Enterprise Console server.

¶ Create a Tivoli Enterprise Console event console so thatyou can use the swdistecsrvr_inst.sh script to install theTivoli Software Distribution event classes to the eventserver. The script enables Tivoli Software Distribution tosend events to the event server.

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

Tivoli Software Distribution Activity Planner Server, Version 4.1Installs the server component of Activity Planner. Before youinstall this component, you must install the Tivoli SoftwareDistribution Server, Version 4.1. To use Activity Planner, youmust also create a Relational Database Management System(RDBMS) Interface Module (RIM) object and databasetables on managed nodes. You can optionally install theActivity Planner GUIs on managed nodes. Activity Planneractions can also be run using the command line.

Tivoli Software Distribution Change Configuration Manager,Version 4.1

Installs the server component of the Change ConfigurationManager (CCM). Before you install this component, you

Tivoli Software Distribution Components

26 Version 4.1

must install the Activity Planner and Historical Databasefeature. To use CCM, you must also install the CCM GUIson managed nodes, and create a RIM object and databasetables on the managed nodes.

Tivoli Software Distribution Server WEB User Interface, Version4.1 This component installs the Apache Web Server, the Sun

Java Servlet APIs, the Apache JServ module, a Java VirtualMachine to run Java Servlets, Tivoli Software DistributionJava Servlets, and the Java Client Framework package toaccess the Tivoli environment from Java Servlets. To use theWeb Interface you must first install the Activity Planner andCCM features and ensure that the Tivoli SoftwareDistribution Historical Database, Version 4.1 component isinstalled and is enabled.

Managed Node ComponentsThe following components must be installed on managed nodes:

Tivoli Software Distribution Gateway, Version 4.1Installs 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.

Tivoli Software Distribution Source Host, Version 4.1The 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.

The Tivoli server functions as the default source host.However, if you want additional source hosts in yourenvironment, install this product component on a managednodes where you will run Tivoli Software Distributioncommands from the command line. To operate as a source



2.P

lann

ing

and

Installin

g

host, a manage node must fulfill the following requirementsin addition to the installation of the source host component:

¶ It must either be a gateway or configured as astand-alone repeater.

You can use the Framework wrpt command to configurethe managed node as a repeater.

¶ It must have sufficient disk space to store the softwarepackage blocks and the files referenced in the softwarepackages.

Note: This component is not supported on NetWare.managed nodes

Tivoli Software Distribution Software Package Editor, Version4.1 Installs the files that enable the Tivoli desktop to launch the

Java-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. The Tivoli Software Distribution SourceHost component must be previously installed on themanaged node.

Notes:

1. The Tivoli Software Distribution Software PackageEditor component is not supported on OS/2 and NetWaremanaged nodes.

2. On managed nodes where the Tivoli SoftwareDistribution Software Package Editor is installed,some of the functionality of the Software Package EditorGUI is disabled.

Tivoli Software Distribution Activity Planner GUIs (only formanaged nodes), Version 4.1

Installs the Activity Planner GUIs on managed nodes. Beforeyou can use Activity Planner, you must create a RIM objectand database tables on the managed nodes.


28 Version 4.1

Note: This component is not supported on OS/2 andNetWare managed nodes.

Tivoli Software Distribution Change Configuration ManagerGUI, Version 4.1

Installs the Change Configuration Manager (CCM) GUIs onmanaged nodes. Before you can use CCM, you must create aRIM object and database tables on the managed nodes.

Note: This component is not supported on OS/2 andNetWare managed nodes.

Tivoli Software Distribution Server WEB User Interface Depot,Version 4.1

Install this component on all managed nodes that function asdepots from which you can download software from theWeb. This component requires the installation of the TivoliManagement Framework, Version 3.7.1 and the TivoliManagement Framework Java Components.

Notes:

1. This component is not supported on OS/2 and NetWaremanaged nodes.

2. It is not necessary to install this component on the serverbecause it is already included in the Tivoli SoftwareDistribution Server component.

Endpoint ComponentsThe following components must be installed on endpoints:

Tivoli Software Distribution Java Endpoint Package EditorThis component consists of a series of platform-specificsoftware packages that can be installed on allendpoint-supported platforms using the Tivoli SoftwareDistribution, Version 4.1 product. This component enablesyou to use the Software Package Editor in stand-alone modeon the endpoint to create software packages and test them byinstalling them locally using the command line on thedisconnected target. You can submit disconnected commandsby clicking the SWDIS ENV icon placed on your desktop



2.P

lann

ing

and

Installin

g

after the installation of this component. You can also use TheSoftware 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. Forinformation about installing this component, see “Installingthe Tivoli Software Distribution Java Endpoint PackageEditor” on page 39.

Tivoli Software Distribution Pristine ToolThis component consists of an OS/2 and a Windowsplatform-specific software package that can be installedusing the Tivoli Software Distribution, Version 4.1 product.This tool provides support for remotely installing newoperating systems and software on pristine computers. Forinformation about installing this component, see “Installingthe Tivoli Software Distribution Pristine Tool” on page 44.


30 Version 4.1

Components in the Software Distribution EnvironmentThe relationship between all of the Tivoli Software Distributioncomponents are shown in the following figure:

Tivoli management region server

Managed nodeGateway/Repeater depot

endpoint endpointendpoint

Managed node/Source host

Tivoli SoftwareDistribution Source Host

Tivoli Software DistributionJava Package Editor

Tivoli SoftwareDistribution Server

Tivoli SoftwareDistribution Gateway

Tivoli Software DistributionJava Endpoint Package Editor

Notes:

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

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



2.P

lann

ing

and

Installin

g

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

1. Ensure Tivoli Management Framework 3.7.1 is installed

2. Install Tivoli Software Distribution Server, Version 4.1

3. Tivoli Software Distribution Gateway, Version 4.1

4. Depending on the deployment plan you have created, you caninstall the following optional Tivoli Software Distributioncomponents:

¶ Tivoli Software Distribution Source Host, Version 4.1

¶ Tivoli Software Distribution Software Package Editor,Version 4.1

¶ Tivoli Software Distribution TEC Integration, Version 4.1

¶ Tivoli Software Distribution Historical Database, Version 4.1

¶ Tivoli Software Distribution Activity Planner Server, Version4.1.

¶ Tivoli Software Distribution Activity Planner GUIs (only formanaged nodes), Version 4.1.

¶ Tivoli Software Distribution Server Change ConfigurationManager, Version 4.1

¶ Tivoli Software Distribution Change Configuration ManagerGUI, Version 4.1

¶ Tivoli Software Distribution Server WEB User Interface,Version 4.1

¶ Tivoli Software Distribution Server WEB User InterfaceDepot Component, Version 4.1

¶ Tivoli Software Distribution Java Endpoint Package Editor

¶ Tivoli Software Distribution Pristine Tool, Version 4.1

Installing Tivoli Software Distribution Products

32 Version 4.1

Notes:

1. Before you can start the installation of CCM, the ActivityPlanner must be completely installed and the relatedconfiguration tasks completed, and the Historical Databasecomponent must be installed and the historical database featureenabled.

2. If you are installing the Activity Planner or ChangeConfiguration Manager features, there are additionalconfiguration tasks that you must complete before the featurescan be used.

See “Creating RIM Objects and Database Tables for ActivityPlanner or CCM” on page 37.

Installation MechanismsYou can install the server and managed node components of TivoliSoftware Distribution using any of the following different installationmechanisms.

¶ Tivoli Software Installation Service. See “Installing TivoliSoftware Distribution with Tivoli Software Installation Service”on page 34.

¶ Tivoli desktop. See “Installing Tivoli Software Distribution withthe Tivoli Desktop” on page 35.

¶ The Tivoli Management Framework commands winstall orwpatch. See “Installing Tivoli Software Distribution Using thewinstall Command” on page 36.

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

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



2.P

lann

ing

and

Installin

g

Index File Component Name Product Tag

SWDISSRV Tivoli Software Distribution Server, Version 4.1 swdissrv_4.1

SWDISGW Tivoli Software Distribution Gateway, Version 4.1 swdisgw

SWDISSH Tivoli Software Distribution Source Host, Version 4.1 swdissh

SWDISJPS Tivoli Software Distribution Software Package Editor,Version 4.1

swdisjps

SWDISTEC Tivoli Software Distribution TEC Integration, Version4.1

swdistec

SWDISDB Tivoli Software Distribution Historical Database,Version 4.1

swdisdb

SWDAPM Tivoli Software Distribution Activity Planner Server,Version 4.1

swdapm

SWDAPMMN Tivoli Software Distribution Activity Planner GUIs,Version 4.1

swdapmmn

SWDISWEB Tivoli Software Distribution Server WEB UserInterface, Version 4.1

swdisweb

SWDWEBD Tivoli Software Distribution Server WEB User InterfaceDepot Component, Version 4.1

swdwebd

SWDCCM Tivoli Software Distribution Change ConfigurationManager, Version 4.1

swdccm

SWDCCMUI Tivoli Software Distribution Change ConfigurationManager GUI, Version 4.1

swdccmui

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

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

Installing Tivoli Software Distribution with TivoliSoftware Installation Service

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


34 Version 4.1

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. Select the machines where each component is to be installed.

4. 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. Select the machines on which to install the component.

4. Click Install.

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

Activity Context Required Role

Install Tivoli SoftwareDistribution products

Tivoli environment super orinstall-product

For detailed information about using the Tivoli desktop to install thecomponents, refer to the Tivoli Enterprise Installation Guide, Version3.7.



2.P

lann

ing

and

Installin

g

Installing Tivoli Software Distribution Using thewinstall Command

When you install the Tivoli Software Distribution components usingthe winstall command, you specify the location of the files to beinstalled, the index file of the component you want to install, and themachine or machines on which the component is to be installed.

Note: If you do not specify a machine when using the winstallcommand, the components will be installed on all managednodes.

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

The following examples illustrate the use of winstall to installcomponents on a Tivoli server or on managed nodes.

¶ To install the Tivoli Software Distribution Server component onthe Tivoli server jupiter from a CD-ROM image, enter thefollowing command:winstall –c \root\images\cdrom -i SWDISSRV.IND jupiter

where:

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

-i SWDISSRV.INDSpecifies the product index file to install.

¶ To install the Tivoli Software Distribution Gateway componenton managed nodes juno and diana from a CD-ROM image, enterthe following command:winstall –c \root\images\cdrom -i SWDISGW.IND juno diana

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


36 Version 4.1

Creating RIM Objects and Database Tables for ActivityPlanner or CCM

The Activity Planner and Change Configuration Management (CCM)features each need a RIM object and database tables. Before you cancreate these items, your system must comply with the followingprerequisites:

¶ Tivoli Management Framework 3.7.1 must be installed.

¶ The following Java components must be installed on managednodes where the Activity Planner or CCM GUI is installed:

v Tivoli Java Client Framework 3.7

v Java for Tivoli 3.7

v Tivoli Java RDBMS Interface Module (JRIM) 3.7

v Java Help for Tivoli 3.7.1

v Swing for Tivoli 3.7.1

¶ Tivoli Inventory, Version 3.6.2 or later must be installed.

¶ Tivoli Software Distribution Server, Version 4.1, componentmust be installed.

Note: The Activity Planner must be installed, the HistoricalDatabase component must be installed, and the historicaldatabase feature must be enabled before you can install andconfigure CCM.

To create the required objects, perform the following steps:

1. Install and configure the relational database management system(RDBMS).

2. Create database tables required and sample queries on the RIMhost.

3. Create a RIM object.

Creating Database Tables and QueriesInstalling the server component of Activity Planner or CCM causesthe following scripts to be written to the



2.P

lann

ing

and

Installin

g

$BINDIR/TME/SWDIS/SCRIPTS directory, where $BINDIRrepresents the system variable that contains the path of theinstallation directory of the product.

¶ For Activity Planner

v plans_vendor_admin.sql

v plans_vendor_schema.sql

¶ For CCM

v ccm_vendor_admin.sql

v ccm_vendor_schema.sql

where vendor is the name of the supported database vendor, forexample DB2®, Oracle, or Sybase.

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

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

Creating RIM ObjectsTo create the RIM object, you must use the wcrtrim command, asfollows:wcrtrim -v <vendor> -h <rimhost> -d <dbname> -u <user>-H <rimhost_path> -s <server_id> <rim_name>

where:

-v <vendor>Identifies the vendor of the RDBMS you are using. For example,DB2, Oracle, Sybase.

-h <rimhost>Identifies the managed node where the RIM host will reside.

-d <dbname>Specifies the name of the database to which the RIM object willconnect. For example, planner or ccm.


38 Version 4.1

-u <user>Specifies the name of the database user. The default user namefor Activity Planner is planner. The default user name for CCMis tivoli.

-H <rimhost_path>Specifies the fully qualified path to the database home directory.Generally, this is an environment variable created during theinstallation of the database. For example, the default home pathfor DB2 databases is set by the DB2DIR environmental variable.

-s <server_id>Specifies the database server ID that enables the RIM host toconnect to the RDBMS. Generally, this is an environmentvariable. For example, for DB2 databases, the DB2COMMenvironment variable should be set to tcpip.

<rim_name>Specifies the name of the created RIM object. The names mustbe specified as follows:

¶ planner (Activity Planner)

¶ ccm (CCM)

Installing the Tivoli Software Distribution JavaEndpoint Package Editor

This section documents the procedure to install the Tivoli SoftwareDistribution, Version 4.1 software package blocks that contain theTivoli Software Distribution Java Endpoint Package Editorcomponent. This component installs the Software Package EditorGUI and the disconnected command line. For information aboutinstalling the language support pack for this component, see“Language Support for Endpoint Components” on page 52.

The product CD-ROM includes the path \package\prepsite whichcontains the following file names for the platform-specific softwarepackage blocks:

SWDISEP_AIX.spbThe software package for the AIX® platform.



2.P

lann

ing

and

Installin

g

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

SWDISEP_NT.spbThe software package for the Windows NT and Windows2000 platform.

SWDISEP_WIN95.spbThe software package for the Windows 98 platform.

SWDISEP_NW.spbThe software package for the NetWare platform. Enables thedisconnected command line only.

SWDISEP_OS2.spbThe software package for the OS/2 platform.

SWDISEP_SOLARIS.spbThe software package for the Solaris platform.

SWDISEP_NTAS400.spbThe software package to be used, on an Windows NTplatform, for creating OS/400 software packages. TheWindows NT system to which this package is distributedmust have a TCP/IP connection to an OS/400 preparationsite where the software package SWDISEP_400PS.spb isinstalled.

SWDISEP_400PS.spbThe software package for the OS/400 preparation site.

Installation OptionsThe following table lists installation options that can be specifiedwhen you install the Tivoli Software Distribution Java EndpointPackage Editor. This component is a software package blockinstalled from the Tivoli desktop using change managementoperations on endpoints. See “Change Management Operations” onpage 297 for more information about executing change managementoperations.


40 Version 4.1

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 “DefaultVariables” on page 312 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.

Installation ProcedureTo install the software package blocks, perform the following steps:

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

2. Create a software package profile.

3. Insert the Tivoli Software Distribution, Version 4.1 CD-ROM inthe machine to which you want to import the software packageblock.

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:



2.P

lann

ing

and

Installin

g

¶ 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 in the \package\prepsite path,the required platform-specific software package block thatinstalls the Tivoli Software Distribution Java Endpoint PackageEditor component.

10. Select the software package block 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 blockand return 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 in theswdis.ini file. The path where the package is installed is:<speditor_dir path>\<interp>


42 Version 4.1

where <interp> represents the operating system type whose valuecan be any one of the following values in the Interpreter Typecolumn:

Operating System Interpreter Type

Windows NT, Windows 2000 w32-ix86

Windows 98 win95

OS/2 os2-ix86

Solaris solaris2

HP-UX hpux10

AIX aix4-r1

NetWare nw4

Additional Notes for OS/2 Installation ProcedureThe SWDISEP_OS2.spb software package block cannot be installedon the file allocation table (FAT) partition of an OS/2 target system.To install the SWDISEP_OS2.spb on an OS/2 target system, verifythat the path of the product_dir variable specified in the swdis.inifile is located on a high-performance file system (HPFS)-partitioneddisk. If it is not located on an HPFS-partitioned disk, perform thefollowing steps:

1. From the Tivoli desktop, right-click the software package blockto install.

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

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

4. In the Default Variable list, 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



2.P

lann

ing

and

Installin

g

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

The product CD-ROM includes the path \package\pristine whichcontains the following file names for the platform-specific softwarepackage blocks:

Pristine_NT.spbThe software package block for the Windows platform. It isvalid for Windows NT 4.0, Windows 2000, and Windows 98Second Edition.

To install the software package block on an endpoint, followsteps 1 through 16 in the section, “Installation Procedure” onpage 41, substituting the input file with the Pristine_NT.spbsoftware package block.

Pristine_OS2.spbThe software package block for the OS/2 platform. It is validfor OS/2 4.0 and OS/2 4.5.

To install the software package block on an OS/2 endpoint,follow steps 1 through 16 in the section, “InstallationProcedure” on page 41 and the steps in the section,“Additional Notes for OS/2 Installation Procedure” onpage 43, substituting the target_dir variable with thefollowing: target_dir=$(product_dir)\pristine

Finishing OffAfter 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.


44 Version 4.1

Upgrading from Tivoli Software Distribution 4.0You can upgrade the Tivoli server and managed node componentsfrom Tivoli Software Distribution, Version 4.0, to Tivoli SoftwareDistribution, Version 4.1, using any one of the followingmechanisms:

¶ Tivoli Software Installation Service

¶ Tivoli desktop

¶ The Tivoli Management Framework wpatch command

Notes:

1. Before upgrading to Tivoli Software Distribution, Version 4.1,using any of the methods, ensure that you have installed theFramework 3.7.1 patch.

2. When upgrading to the new Tivoli Software Package Editorcomponent, be aware that you must install the Framework 3.7.1Java components. This version of the Software Package Editordoes not include its own Java components. See Table 1 onpage 25 for details of the Framework Java components.

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

Activity Required Role

Upgrade Tivoli Software Distribution super or install-product

Note: To upgrade the Tivoli Software Distribution Java EndpointPackage Editor, Version 4.0 to Version 4.1, remove theVersion 4.0 component before installing the Tivoli SoftwareDistribution Java Endpoint Package Editor, Version 4.1component.

Upgrading Tivoli Software Distribution, Version 4.0with the Tivoli Software Installation Service

The basic procedure for using the Tivoli Software InstallationService to upgrade the components of Tivoli Software Distribution isas follows:

Upgrading from Software Distribution 4.0


2.P

lann

ing

and

Installin

g

1. Import the product images into the Software Installation ServiceDepot.

2. Select the components to be installed.

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

4. Click Install.

For detailed information on using the Tivoli Software InstallationService to upgrade the components, refer to the Tivoli EnterpriseInstallation Guide.

Upgrading Tivoli Software Distribution, Version 4.0from the Tivoli Desktop

The basic procedure for using the Tivoli desktop to upgradecomponents of Tivoli Software Distribution is as follows:

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

2. Select the media and component.

3. Select which machines to install the component.

4. Click the Install button.

For detailed information on using the Tivoli desktop to install thecomponents, refer to the Tivoli Enterprise Installation Guide.

Upgrading Tivoli Software Distribution, Version 4.0Using the wpatch Command

The following are examples of using the wpatch command toupgrade the components of Tivoli Software Distribution. See thetable “Installation Mechanisms” on page 33 for a list of componentsand their associated index file names. The index file name is used inthe wpatch command.

¶ To install the Tivoli Software Distribution Server component onthe Tivoli server jupiter from a CD-ROM image, enter thefollowing command:wpatch –c \root\images\upgrade -i SWDISSRV.IND jupiter

where:


46 Version 4.1

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

-i SWDISSRV.INDSpecifies the product installation index file to which thepatch is installed.

jupiterSpecifies the managed node on which the patch isinstalled.

Note: If you do not specify a managed node, the patchis installed on all managed nodes where the baseproduct is currently installed in the Tivolimanagement region.

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

Removing Tivoli Software DistributionTivoli Management Framework provides a command line utility toremove Tivoli applications from a specified node or from the entireTivoli management region. The wuninst command is a wrapperscript that invokes product-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 Tivoli management region.See the table “Installation Mechanisms” on page 33 for a list of theTivoli registered product tags for Tivoli Software Distributioncomponents.

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

The following examples demonstrate removal operations that youcan use to uninstall Tivoli Software Distribution or its componentsfrom your Tivoli management region environment. See the Tivoli



2.P

lann

ing

and

Installin

g

Management Framework Reference Guide for more informationabout command line 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 Tivolimanagement region in which jupiter is the Tivoli server, enter thefollowing command. Note that if the node is the Tivoli server, TivoliSoftware Distribution will be removed from the Tivoli server andfrom all managed nodes on which Tivoli Software Distribution isinstalled.wuninst swdissrv_4.1 jupiter -rmfiles

where:

swdissrv_4.1Specifies 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 Tivoli server, this option removes all databaseobjects.

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

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

Removing Tivoli Software Distribution

48 Version 4.1

Distribution 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 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“Installation Mechanisms” on page 33.

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

Uninstalling Tivoli Software Distribution EndpointsWhen uninstalling a Tivoli Software Distribution endpoint, thefollowing steps must be performed manually:

1. The following directories still exist after uninstalling theendpoint: drive:\Product_Dir\swdis. Delete them from theappropriate drive manually.



2.P

lann

ing

and

Installin

g

2. Remove the swdis.ini and swdis.bak files from the SystemDirdirectory. On UNIX platforms, these files are located in/etc/Tivoli

3. From the Windows registry, delete theSwdisUsrPrf.Endpoint_label keyword from the following path:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.

For more information about uninstalling endpoints, refer to the TivoliEnterprise Installation Guide.

Uninstalling the NetWare GatewayInstalling Tivoli Software Distribution, Version 4.1 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 theTivoli server, run the swdisNW_uninst.sh script to remove Tivoliproducts installed in the Tivoli management region from theTivoli object database. Since this command is a bash script thatmust be run in the bash environment, precede the command withthe string sh, as follows: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):


50 Version 4.1

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.exesys:\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.exesys:\Tivoli\bin\lcf_bundle.40\lib\os400\resinitsys:\Tivoli\bin\lcf_bundle.40\lib\os400\wdbldspb

Enabling Language SupportTivoli Software Distribution, Version 4.1 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.1components listed in the section “Installation Mechanisms” onpage 33 , you can enable the supported languages by installing theappropriate language support pack located on the product CD-ROMin the \images\l10n\cdrom path. Installation of the language packagesis optional. You can also install multiple language support packs fora single product. Remember, to get full language enablement youmust install the Tivoli Management Framework language supportpack as well as the language support pack for Tivoli SoftwareDistribution, Version 4.1. If you are installing the language supportpack using the Install Product dialog, the following dialog box



2.P

lann

ing

and

Installin

g

shows the list of language support packs available:

Language Support for Endpoint ComponentsThe product CD-ROM includes language support packs in the path\package\l10n, in the form of a software package block, for thefollowing endpoint components:

Tivoli Software Distribution Pristine ToolInstall the PRISTINE_l10n.spb software package block.

Tivoli Software Distribution Java Endpoint Package EditorInstall the SDGui_l10n.spb software package block.

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

Enabling Language Support

52 Version 4.1

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.On managed nodes, you install the Tivoli Software DistributionSoftware Package Editor component and some of the functionality ofthe Software Package Editor is disabled. You use this componentprimarily for customizing pre-existing software packages.

Notes:

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

2. Performance of the Software Package Editor can be degraded ifremote drives that were not accessible when the SoftwarePackage Editor was launched have been mapped to the machine.

3


3.C

reating

aS

oftw

areP

ackage

3. If you are using the Software Package Editor on a Windows 98platform, a DOS window appears minimized in the task barwhen you open or save a software package in SPD or SPBformat. Do not close this window as this will close the entireapplication.

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 on your desktop. On a Windows system, you canalso launch the Software Package Editor by selecting the entry in theStart→Programs menu. The Software Package Editor main windowdisplays.

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

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

Launching the Software Package Editor

54 Version 4.1

hostname must be identical and in the same case. You can,however, launch the Software Package Editor from theSoftware Package Editor icon on your desktop.

Launching the Software Package Editor on ManagedNodes

Some of the functions of the Software Package Editor GUI installedon managed nodes are disabled. The following list details thoseoptions that are not available:

¶ The AutoPack menu

¶ The Tools menu

¶ The browse (...) buttons. If you edit a software package on amanaged node that is not the source host of the softwarepackage, you cannot access the source host files by clicking thebrowse button.

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

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 containing



3.C

reating

aS

oftw

areP

ackage

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

You can view the contents of a software package in the built format,but you cannot edit and save the changes. To edit a software packageblock using the Software Package Editor, perform the followingsteps:

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.

4. Convert the software package back to a software package block.

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

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.


56 Version 4.1

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.

¶ 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 151 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.

The Software Package Editor Window


3.C

reating

aS

oftw

areP

ackage

¶ Select Importer→Install MSI Product from the Tools menu toimport a Microsoft Software Installer (MSI) file and map itscontents to a 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.1, makes use of a simplifiedsingle-content packaging format called the software package. All ofthe techniques used to create software packages are based on thissingle file format. Therefore, a software package created usingAutoPack is identical to a package created manually using theSoftware Package Editor, and both can be edited in 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:

The Software Package Editor Window

58 Version 4.1

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 98 target systems.

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

d. Make changes to a Windows profile by modifying an .ini file.

e. Add a Windows NT service action.

4. Create a generic container to house various OS/2-related actions,such as the following:

a. Create a folder on the desktop containing a program and 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 other

Creating the Appsample Software Package


3.C

reating

aS

oftw

areP

ackage

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

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.

Creating the Appsample Software Package

60 Version 4.1

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.

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

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.

Naming the Software Package


3.C

reating

aS

oftw

areP

ackage

–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

62 Version 4.1

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


3.C

reating

aS

oftw

areP

ackage

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 122 forinformation about setting conditions at the package level. Referto “Built-in Variables” in the Tivoli Software DistributionReference Manual for a table containing descriptions andaccepted values for built-in variables.

Checking Disk Space

64 Version 4.1

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


3.C

reating

aS

oftw

areP

ackage

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.

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

66 Version 4.1

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 for moredetailed information about using variables.

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

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



3.C

reating

aS

oftw

areP

ackage

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

¶ The Stop on failure check box is selected by default.Leave it selected to discontinue the distribution of thesoftware package if a failure occurs during the execution ofthe action.

¶ Select the Replace if target is newer check box to replacea target 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 thanthe source object, the target object is replaced. File versionsupport is available if the source host is a Windowsmachine or if the software package containing the file inquestion has been built on a Windows machine andimported in the software package block (built) format.

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

¶ Select the Remove if modified check box to flag thisobject for a subsequent remove operation. During a removeoperation of the same software package, the flag indicatesto remove the object even if the target object has beenmodified since the last install operation.

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


68 Version 4.1

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 duringan undo 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 Windowsplatforms, during an install an attempt is made to replace orrename the file under the same directory as the locked file andthe distribution completes successfully without having to waitfor a reboot of the system. The temporary file is removed



3.C

reating

aS

oftw

areP

ackage

during the next system reboot. During a remove operation, thelocked file is removed during the 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. If the file cannot be renamed or replaced, thedistribution fails.

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.

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.


70 Version 4.1

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


3.C

reating

aS

oftw

areP

ackage

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.


72 Version 4.1

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



3.C

reating

aS

oftw

areP

ackage

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

74 Version 4.1

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



3.C

reating

aS

oftw

areP

ackage


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.


76 Version 4.1

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.



3.C

reating

aS

oftw

areP

ackage

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.


78 Version 4.1

Adding Windows Registry ObjectsIn more recent Windows versions, such as Windows 98, WindowsNT, and Windows 2000, .ini files have been replaced by theWindows registry to store configuration information regarding theuser, the hardware, and the programs installed. Many applicationscontinue to use .ini files for backward compatibility. Windowsoperating systems refer to the 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


3.C

reating

aS

oftw

areP

ackage

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 98, WindowsNT 4.0, or Windows 2000 machines. Click Condition in theupper right corner of the dialog to display the Condition Editor


80 Version 4.1

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.



3.C

reating

aS

oftw

areP

ackage

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


82 Version 4.1

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.



3.C

reating

aS

oftw

areP

ackage

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


84 Version 4.1

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


3.C

reating

aS

oftw

areP

ackage


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 98, Windows NT 4.0, and Windows2000. Therefore, click Condition in the upper right corner ofthe Add Windows Shell Folder Properties dialog to display the


86 Version 4.1

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.



3.C

reating

aS

oftw

areP

ackage

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 Properties


88 Version 4.1


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



3.C

reating

aS

oftw

areP

ackage

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 Properties

Adding Windows Profile Objects

90 Version 4.1


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



3.C

reating

aS

oftw

areP

ackage

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

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 Section


92 Version 4.1

Properties dialog is displayed.

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.



3.C

reating

aS

oftw

areP

ackage

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

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


94 Version 4.1

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


3.C

reating

aS

oftw

areP

ackage


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 65 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

96 Version 4.1

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

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


3.C

reating

aS

oftw

areP

ackage

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

98 Version 4.1

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


3.C

reating

aS

oftw

areP

ackage

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


100 Version 4.1


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



3.C

reating

aS

oftw

areP

ackage

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


102 Version 4.1


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

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.



3.C

reating

aS

oftw

areP

ackage

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

104 Version 4.1

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.



3.C

reating

aS

oftw

areP

ackage

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.


106 Version 4.1

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

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

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

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



3.C

reating

aS

oftw

areP

ackage

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

108 Version 4.1

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.



3.C

reating

aS

oftw

areP

ackage

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.


110 Version 4.1

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



3.C

reating

aS

oftw

areP

ackage

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 65, 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.


112 Version 4.1

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.



3.C

reating

aS

oftw

areP

ackage

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


114 Version 4.1

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



3.C

reating

aS

oftw

areP

ackage

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

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

116 Version 4.1

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.



3.C

reating

aS

oftw

areP

ackage

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. The exit code settings control the execution of the subsequentaction in the software package. In the Exit Code box, the rangeof program completion codes are specified as a minimum andmaximum value in hexadecimal format. The minimum andmaximum values can range from 0 to 65535 (0x0, 0xffff). For aSUCCESS exit code, the default is 0.

To set the minimum and maximum range, click the text box inthe Min or Max column and type a valid hexadecimal value. Toset an exit code, click the text box in the Exit Code column andselect an option from the scrolling list. To add an exit code to thelist, click Add. Ensure the minimum and maximum range is setto an available interval between 0 and 65535. Refer to theexecute user program action in the Tivoli Software DistributionReference Manual for information about the various exit codesthat can be returned and their effect on program operations.

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


118 Version 4.1

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

Complete the following steps to add the restart action.

1. Select the Appsample software package icon in the left pane.Click the System action tab from the right toolbar, then click the

Adding the Restart Action


3.C

reating

aS

oftw

areP

ackage

Restart 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 thesoftware 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


120 Version 4.1

¶ 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

Before distributing the software package, you can use thedisconnected command line interface to test the package by buildingit and installing it locally. Use the wdlssp command to produce a listof software packages installed an endpoint, together with the versionand change management status of each software package. Refer tothe Tivoli Software Distribution Reference Manual for moreinformation about disconnected command line interface commandsand software package change management states.



3.C

reating

aS

oftw

areP

ackage

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 tobe 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. Software package properties define the followinginformation about the software package to be distributed:

¶ General options, including the name, version, versioning andpackage types, dependency rules, creation time, and modificationtime 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.

Changing the Order of Objects in the Package

122 Version 4.1

¶ 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

¶ 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 for more detailedinformation about using conditions. Click OK to return to theSoftware Package Editor window.

Setting Software Package-level Properties


3.C

reating

aS

oftw

areP

ackage

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

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

2. In the Package version text box, enter the version string. Theversion string can contain up to 16 alphanumeric characters andcan be separated into substrings using dots (.). The dots areincluded in the total length of the string. Refer to the TivoliSoftware Distribution Reference Manual for more informationabout software package name and version syntax.

3. Select a Versioning Type. SWD turns version checking on.None turns version checking off.

4. If you selected SWD for the Versioning Type, you must select aPackage Type which determines the method of version checking,as follows:

RefreshThe package cannot be installed if a later version of thepackage is already present on the target.


124 Version 4.1

PatchThe package cannot be installed if the product installed onthe target does not have the same base version as the patchto be applied.

See “Software Package Version Checking” in the “Editing theSPD File” chapter of the Tivoli Software Distribution ReferenceManual.

5. If you want to define hardware and software prerequisites for thesoftware package, click Dependency. See “The DependencyEditor” on page 125.

6. 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 333 toview how the Tivoli Software Distribution Web Interface uses theinformation entered in this text box.

7. Select the History reset check box to erase the software historyof all software packages already installed on the endpoint, if thepackage is installed successfully.

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

The Dependency EditorUsing the Dependency Editor, you can create an expression thatdefines prerequisites for executing install, remove, and undo actionsdefined in the software package. You can build a complex expressionthat includes any number of Hardware-discovered variables andmultiple occurrences of the $(installed_software) variable. See



3.C

reating

aS

oftw

areP

ackage

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

To build a dependency expression, perform the following steps:

1. Define a variable.

To define Hardware-discovered variable, enter the names of theHardware-discovered table and of the field within the table in theTable and Field text boxes, then click Add.

To define a $(installed_software) variable, click Add InstalledSoftware

The variable you specified appears in the expression box at thetop of the dialog.

2. Click one of the operators shown in the lower section of thedialog.

3. Click in the expression box and enter a constant.

You add the boolean constants, True and False, to the expression,by clicking the appropriate button in the lower section of thedialog.


126 Version 4.1

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

Note: You can check the syntax of the expression, by clickingCheck.

5. When the expression defines all the software and hardwareprerequisites you want to include, click OK to return to thePackage Properties dialog.

Server OptionsOn the Server options page, set the source host and program options.See “Software Package Properties” on page 290 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 thesoftware package block resides.

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.

4. In the Before build group box, specify any programs to be runon the source host machine before the building of the package


128 Version 4.1

takes 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. Formore information regarding change management operations andoperation modes, see “Change Management Operations” onpage 297.

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.

Undoable


130 Version 4.1

¶ 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 an error, such as a locked file.

¶ 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


132 Version 4.1

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 formore information about the lost-n-found collection.

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.


134 Version 4.1

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.

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

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 Tivoli managementregion server (Tivoli server). You can create it on a managed node ortarget by setting the information in this dialog. It is created bydefault with the name package-name^package-version.log in the path$BINDIR/../SWDIS/WORK.


136 Version 4.1

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 Tivoli serverof the Tivoli management region in which the software packagewas created. Refer to the Tivoli Management FrameworkPlanning for Deployment Guide for more information aboutconfiguring e-mail in your Tivoli management regionenvironment.

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 Tivoliserver is the default. Indicate the complete path to the log file inthe Path 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


138 Version 4.1

installed. Click browse (...) to browse the file system and import anexisting file into this dialog. See “Tivoli Software Distribution WebInterface” on page 333 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.


140 Version 4.1

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 for more detailed information about using variables.

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 packages



3.C

reating

aS

oftw

areP

ackage

specified 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 inthe 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 is


142 Version 4.1

specified 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 327 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 122.

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-clickLink under the Object type column in the right pane. A pop-upmenu is displayed.



3.C

reating

aS

oftw

areP

ackage

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

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

Note: After modifying properties of an object, the SoftwarePackage Editor Java interface does not always refresh todisplay the changes. Save the software package andreopen it to display the correct information.

Program Actions in the Software Package EditorIn addition to the actions that you added to the Appsample softwarepackage, the Software Package Editor supports the addition of anumber of program actions which execute the following types ofprograms on the target systems:

Editing Software Package Properties

144 Version 4.1

¶ IBM Configuration, Installation, and Distribution (CID)programs. See “The Execute CID Program Action”.

¶ Installation of a program using the InstallShield program. See“The InstallShield Program Action” on page 146.

¶ Installation of a program using the Microsoft Setup program. See“The Microsoft Setup Program Action” on page 149.

¶ Installation of a program using the Microsoft Software Installer(MSI) program. See “Embedding MSI Installation Packages in aSoftware Package” on page 181.

Refer to the online help documentation for a more detailedexplanation of these dialogs.

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 is

Other Software Package Actions


3.C

reating

aS

oftw

areP

ackage

displayed.

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


146 Version 4.1

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.

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



3.C

reating

aS

oftw

areP

ackage

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. 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 Tivoli server. See “The Distribution Process” onpage 277 for more information about creating profiles andimporting and distributing software packages.


148 Version 4.1

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.

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.



3.C

reating

aS

oftw

areP

ackage

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 correspondingremove 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

150 Version 4.1


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

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

152 Version 4.1

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.

Note: If you are using the Software Package Editor on aWindows 98 platform, a DOS window appears minimizedin the task bar when you open or save a software packagein SPD or SPB format. Do not close this window as thiswill close the entire application.

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 for more information aboutediting 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.To import a software package definition file into the TivoliManagement Framework environment, see “Importing a SoftwarePackage into the Tivoli Environment” on page 285.



3.C

reating

aS

oftw

areP

ackage


154 Version 4.1

Using Tivoli SoftwareDistribution on OS/400

This chapter provides a summary of the Tivoli Software Distributionfeatures that are specific for OS/400 operating systems. It includesthe following information:

¶ An overview of the Software Distribution features that areavailable for OS/400 systems. See “Defining Software Packageswith OS/400 Objects” on page 156.

¶ An overview of the file systems used on OS/400 systems. Thissection includes guidelines on how to define file locations on theOS/400 native system and the Integrated File System (IFS). See“The OS/400 Native and Integrated File Systems” on page 158.

¶ Instructions for adding OS/400-specific objects to a softwarepackage using the OS/400 Software Package Editor (SPE). See“Defining Software Packages with OS/400 Objects” on page 156.

¶ Information about adding objects to an OS/400 native filesystem using the standard Software Distribution Add Directoryand Add File actions. See “Adding Non-Native Objects to theOS/400 Native File System” on page 172.

¶ Information about using the standard Software DistributionExecute User Program action to run programs on an OS/400system. See “Running an OS/400 Executable Program” onpage 175.

4


4.S

oftw

areD

istribu

tion

on

OS

/400

¶ OS/400-specific information about the Software DistributionData Moving Service which enables you to move data in bothOS/400 native file systems and IFS. See “The Data MovingService in an OS/400 Environment” on page 178.

Notes:

1. The disconnected command line interface, available for othersystems, is not available for managing software packages onOS/400 machines.

2. AutoPack technology is not available from the OS/400Software Package Editor.

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

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

¶ SWDISEP_NTAS400.spb on the NT machine

¶ SWDISEP_400PS.spb on the OS/400 machine

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

You define and save software packages on the NT machine, but youselect the objects that are to be included in the package from the filesystem of the OS/400 machine. The software packages created inthis way can be imported to the TMR in the same way as othersoftware packages.

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

Using Tivoli Software Distribution on OS/400

156 Version 4.1

the standard SPE actions, for example, Add Directory and Add File,when defining the OS/400 software package. The OS/400 SPE alsoincludes additional actions that allow you to include OS/400 nativeobjects and programs in the software package. See “The OS/400Native and Integrated File Systems” on page 158 for an explanationof how file locations are defined using the OS/400 native system andthe IFS.

The OS/400 SPE allows you to perform the following specificOS/400 tasks:

¶ Add and remove OS/400 libraries and objects.

¶ Add and remove OS/400 licensed programs.

¶ Change OS/400 system values.

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

In addition, you can use many standard features of the SPE, asfollows:

¶ Distribute directories and files.

¶ Distribute text files that are ASCII encoded on the source hostand that could be translated in EBCDIC on the OS/400 target.

¶ Execute programs on the target.

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

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



4.S

oftw

areD

istribu

tion

on

OS

/400

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

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

The OS/400 Native and Integrated File SystemsThe OS/400 file system is an integrated database containing objectsinstead of files. The integrated file system provides you with atypical hierarchical file system interface that is analogous to a UNIXsystem.

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

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

Native objects are generally mapped into:/QSYS.LIB /<LIB_NAME>.LIB/<OBJ_NAME>.<TYPE>

The object type is identified by a .<TYPE> name suffix. IFS mapsphysical files with members into directories; therefore a physical filemember is referred to thus:/QSYS.LIB/<LIB_NAME>.LIB/<OBJ_NAME>.FILE/<MBR_NAME>.MBR


158 Version 4.1

Navigating the IFS by means of the SPE FileChooser graphical userinterface (GUI), you can install, remove, and manage softwarepackages containing UNIX objects on an OS/400 system.

Using the OS/400 Software Package EditorThe software allows you to perform change-management operationson OS/400 systems and to manage how software package actions areexecuted on an OS/400.

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

This section describes how you use the OS/400 SPE to perform thefollowing software package operations from an NT preparation site:

¶ Add an OS/400 library

¶ Add an OS/400 object

¶ Remove an OS/400 library

¶ Remove an OS/400 object

¶ Add an OS/400 licensed program

¶ Remove an OS/400 licensed program

¶ Change an OS/400 system value

Launching the OS/400 Software Package EditorStart the OS/400 Software Package Editor logon, as follows:

1. Double-click the Software Package Editor OS400 icon on yourdesktop.



4.S

oftw

areD

istribu

tion

on

OS

/400

The OS400 Logon dialog is displayed.

2. Type the OS/400 host machine name, user ID, and password forthe machine to which you want to connect.

3. Click OK to return to the Software Package Editor mainwindow.

Notes:

a. At the preparation site, your user ID should have *ALLOBJauthority on the AS/400®.

b. Before you use the OS/400 Software Package Editor, performthe following actions on the AS/400 preparation site machine:

¶ Make sure that all host server daemons have been started.See command strhostsvr *all.


160 Version 4.1

¶ Install the OS/400 Preparation Site software providedwith the software package block “SWDISEP_400PS”.

c. The build of a package runs in a job under the specified userprofile.

Adding OS/400 Libraries and ObjectsYou use the Add OS/400 Library and Add OS/400 Objectcommands to specify the OS/400 objects that are to be installed onthe target systems. An OS/400 Object can only be added within alibrary, therefore, even if the library already exists on the targetsystem, you must specify it in the software package, and thenspecify the objects within that library that are to be added on thetarget system.

You can specify which objects from the library are to be included, asfollows:

¶ All objects in the library are to be included.

¶ Only objects that have changed since a specified reference dataand time are to be included.

¶ Selected objects, specified using the Add OS/400 Objectcommand, are to be included.

To add an OS/400 library to a target system, perform the followingsteps:

1. In the Software Package Editor window, select the Add objecttab.



4.S

oftw

areD

istribu

tion

on

OS

/400

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

3. In the source Location text box, type the location of the parentlibrary where the library to be added is located or use thebrowse (...) button to locate the library. The path cannot containwildcards. The location you specify is duplicated in thedestination Location text box.

4. In the source Name text box, type the name of the library to beadded. You can use wildcards in this text box. This name isduplicated in the destination Name text box.

5. In the destination Location text box, specify the location of theOS/400 parent library to which the package is to be added, oruse the browse (...) button to locate the library.

6. In the destination Name text box, type the name of the libraryto which you want the package to be added, or use the browse(...) button to locate the library.

7. If you do not want to add all library objects, clear the Descendcheck box. This is the default.


162 Version 4.1

8. If you want to add all library objects, or changed objects, selectthe Descend check box and then define the library contents youwant added to the software package. You do this by selectingone of the following option buttons:

All ObjectsSelecting this option button adds all the objects that thelibrary contains.

Changed Objects OnlySelecting this option button adds only the objects thatwere changed after a specified reference date and time.

9. If you selected the Changed Objects Only option button, youmust specify the reference date and time in the Reference Dateand Reference Time text boxes.

The format for the time must be HH:MM:SS. Though theseparator can change according to the setting of the QTIMSEPsystem value, which supports the following separators:

¶ Colon (:)

¶ Period (.)

¶ Comma (,)

¶ Blank

10. From the Replace Options drop-down list, select theappropriate replace option, as follows:

ALL All the objects contained in the library are added to thetarget system. This is the default.

NEW Only objects that do not already exist in the targetlibrary are added to the target system.

OLD Only objects that already exist in the target library areadded to the target system to replace the old ones.

11. In the Target Release text box, type the release of the targetOS/400 system. The target release can be specified as follows:

*CURRENT This indicates the current release.



4.S

oftw

areD

istribu

tion

on

OS

/400

*PRV This indicates the previous release withmodification level 0.

VxRyMz Where x is a valid version number, y is a validrelease number and z is a valid modificationlevel.

Note: If the AS/400 endpoint is not consistent with this value,the object is not installed.

12. Define on which machine the selected library objects are to becollected at execution time, in either of the following ways:

¶ On the OS/400 preparation machine when the package iscreated: clear the Remote check box. This is the default.This creates a *SAVF.

¶ On the target machine at execution time: select the Remotecheck box. This does not create a *SAVF.

13. To insert a condition check, click the Condition button andmake your selections in the Condition Editor dialog displayed.

14. Click OK to activate the operation.

Adding OS/400 ObjectsIf you did not select the Descend check box in the Add OS/400Library dialog, you must use the Add OS/400 Object action to addindividual OS/400 objects to the OS/400 library that you have added.Each Add object has a green plus sign (+) in its icon. To add anOS/400 object to a library, perform the following steps:

1. In the left pane of the Software Package Editor window, selectthe OS/400 library object to want to add the object to.


164 Version 4.1

2. In the Add object tabbed page, click the OS400 Object icon.The Add OS400 Object Properties dialog is displayed.

3. In the source Location text box, specify the path name of thelibrary that contains the object to be added to the softwarepackage. The path cannot contain wildcards. This path name isduplicated in the destination Location text box.

4. In the source Name text box, specify of the name of the libraryobject to be added. You can use wildcards in this name.

5. In the destination Location text box, specify the destination pathname of the library to which the object is to be added.

6. In the destination Name text box, specify the name of the objectto be added.

7. Specify where the object is to be collected, as follows:

¶ Select the Remote check box if you want the object to becollected on the target machine at run time.

¶ Clear the Remote check box if you want the object to becollected on the OS/400 preparation machine when thepackage is created.

8. If you want to insert a condition check, click the Conditionbutton and make your selections in the Condition Editor dialog.




4.S

oftw

areD

istribu

tion

on

OS

/400

Removing OS/400 LibrariesTo remove a library from a target OS/400 machine, perform thefollowing steps:

1. In the Software Package Editor window, select the Removeobject tab.

2. Select the OS400 Library icon. The Remove OS400 LibraryProperties dialog is displayed.

3. In the Location text box, specify the location of the parentlibrary of the OS/400 library to be removed.

4. In the Name text box, specify the name of the library you wantto remove.

5. If you want to remove the library and its contents from the targetsystem, select the Descend check box. Clear this check box ifyou want to remove an empty library from the target system.Cleared is the default.

6. If you want to insert a condition check, click the Conditionbutton and make your selections in the Condition Editor dialogdisplayed.


Removing OS/400 ObjectsThe Remove OS/400 Object action enables you to removeindividual objects from a library. Each remove object has a redminus sign (-) in its icon. To remove an OS/400 object, perform thefollowing steps:


166 Version 4.1

1. In the left pane of the Software Package Editor window, selectthe OS/400 library from which you want to remove the object.

2. In the Remove Object page, select Remove object. The RemoveOS400 Object Properties dialog is displayed.

3. In the Location text box, specify the location of the OS/400library containing the object to be removed, if the location is notalready shown.

4. In the Name text box, specify the name of the OS/400 object tobe removed.



Adding OS/400 Licensed ProgramsUsing the Add OS/400 Licensed Program action, you can add anaction to a software package to install a licensed program on anOS/400 system. The following options are available for retrievingthe licensed program to be installed:

¶ From an existing LICPGM. This is a local operation where youprovide the ID of the licensed program already installed at thepreparation site. At build time, the program is retrieved from thesource machine, saved in a *SAVF, and included in the package.At install time, the program is installed on the target machine.

¶ From a device. This is a remote operation where you specify thedevice, for example, a CD-ROM, from which the program will



4.S

oftw

areD

istribu

tion

on

OS

/400

be installed. At build time, no *SAVF is included in the package.At install time, the program is installed on the target systemfrom the specified device.

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

To add an OS/400 licensed program, perform the following steps:

1. In the Software Package Editor window, select the Add objecttab.

2. Select the OS400 Licensed Program icon. The Add OS400Licensed Program Properties dialog is displayed.

3. In the text boxes, type the required information about thelicensed program, as follows:

Name Type the alphanumeric code of the licensed program tobe installed, in the OS/400 format (5763XD1).


168 Version 4.1

OptionType the name of the optional parts for the specifiedlicensed program. The default is *BASE.

LanguageType the language option of the specified licensedprogram. The default is *PRIMARY.

ReleaseType the release of the licensed program to be installed.This is not necessary if the specified product containsonly one release.

The default is *ONLY.

Target ReleaseType the release of the target OS/400 system. The defaultis *CURRENT.

4. From the Type drop-down list, specify the object type to berestored, as follows:

*ALL Installs both the licensed program and the languagecomponents. This is the default.

*PGMInstalls only the program. You use this type, for example,if you have upgraded the program but not the languagecomponent.

*LNG Installs only the language component. You use this type,for example, if you are adding a new language to apreviously installed licensed program.

5. If the device containing the licensed program to be added isalready located on the target machine, select the Remote checkbox and locate the program in either one of the following ways:

¶ Specify in the Savf text box the SAVF in which the licensedprogram is located. Use the format/QSYS.LIB/MYLIB.LIB/SAVF.FILE.

¶ Specify in the Device text box the device name on which theprogram is located, for example, the optional device name.



4.S

oftw

areD

istribu

tion

on

OS

/400



Removing OS/400 Licensed ProgramsThe Remove OS/400 Licensed Program action enables you tospecify the ID of the program to be removed from the target system.At install time, the specified program is removed from the targetsystem.

To remove an OS/400 licensed program, perform the followingsteps:

1. In the Software Package Editor window, select the Removeobject tab.

2. Select the OS400 Licensed Program icon. The OS400 LicensedProgram Properties dialog is displayed.

3. In the text boxes, type the required information about thelicensed program to be removed, as follows:

Name Type the alphanumeric code of the licensed program tobe removed, in the OS/400 format (5763XD1).

OptionType the name of the installation option for the specifiedlicensed program. The default is *BASE.


170 Version 4.1

LanguageType the language option of the specified licensedprogram. The default is *PRIMARY.

ReleaseType the release of the licensed program to be removed.This is not necessary if the specified product containsonly one release. The default is *ONLY.



Changing an OS/400 SysvalThe Set OS/400 System value action enables you to specify a newvalue for an OS/400 SYSVAL name/value pair.

To change a system value, perform the following steps:

1. In the OS/400 Software Package Editor window, select theSystem action tab.

2. Select the Set OS400 system value icon. The OS400 SystemValue Properties dialog is displayed.

3. In the Name text box, type the name of the system value to bechanged.

4. In the Value text box, type the new value of the system valueyou specified. For more information about OS/400 systemvalues, refer to OS/400 Work Management, SC41-5306.



4.S

oftw

areD

istribu

tion

on

OS

/400


6. Click OK to save the information and close the dialog.

Using Non-OS/400-Specific FunctionsIn addition to the OS/400 specific functions, you can use standardfunctions of the SPE when you are defining a software package fordistribution to an OS/400 system, as follows:

¶ The Add Directory and Add File functions, to add a non-nativefile, for example from a Unix system, to an OS/400 system. See“Adding Non-Native Objects to the OS/400 Native File System”.

¶ The Execute User Program action, to run a program, forexample, a C, CL, REXX, exec, or batch job script. See“Running an OS/400 Executable Program” on page 175.

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

Note: If the destination file system is OS/400 IFS, files are specifiedin the same way as for a Unix file system.

Adding Non-Native Objects to the OS/400 Native FileSystem

You can use the SPE to add objects in a software package that willadd non-native objects to an OS/400 file system. In this way, youcan take files from a non-OS/400 file system, for example Windowsor Unix, and add them to the OS/400 native file system as physicalfiles or file members.

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


172 Version 4.1

To add a directory or file to an OS/400 native file system, youspecify an OS/400 native physical file as the destination path. Atinstallation time, Software Distribution adds the file to the nativephysical file as a file plus member, or as an additional member of anexisting file.

Notes:

1. If the target physical file already exists on the target system, itmaintains its attribute, for example, PF_DTA. If the physical filedoes not exist on the target system, a new physical file is createdwith attribute PF_SRC (Source Physical File).

2. When adding members to a physical file, ensure that themaximum number of members (MAXMBRS) and the file size(SIZE) are sufficient to accept the new members.

3. You cannot add a group of files with the same name anddifferent extensions. OS/400 does not use extensions todifferentiate between files. OS/400 extensions are assigned to thefiles when they are added to the file system and the originalextensions are lost. This means that files with the same namewill overwrite each other.

4. When adding an object to an OS/400 target system, the lastmodified date is set to the current date. However, the date usedto determine whether the object should be added is the lastmodified date on the source system.

When specifying an OS/400 file system path, use the conventiondescribed in the section “The OS/400 Native and Integrated FileSystems” on page 158. For example, to add files of directory/usr/sd41/source to library mylib.lib, use the following:...add directory

location = “/usr/sd41”name = “source”destination = “/QSYS.LIB/MYLIB.LIB”add = ydescend_dirs = ytranslate = y

end...



4.S

oftw

areD

istribu

tion

on

OS

/400

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

To add files FILE1.DAT and FILE2.DAT to an existing OS/400physical file, use the following:...add directory

location = “/usr/sd41”name = “source”destination = “/QSYS.LIB/MYLIB.LIB/DATA.FILE”add = ydescend_dirs = nfile

name = “FILE1.DAT”destination = “FILE1.MBR”translate = y

endfile

name = “FILE2.DAT”destination = “FILE2.MBR”translate = y

endend

end...

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

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


174 Version 4.1

Running an OS/400 Executable ProgramYou can use the SPE to add an Execute User Program action to asoftware package that includes an OS/400 program, such as C, CL,REXX, an exec, or batch job script. At installation time, SoftwareDistribution runs the program on OS/400 subscribers.

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

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

For example, the following stanza adds an action to execute the CLprogram outmsg:.......

execute_user_programname = “outmsg”transactional = n

during_install

exit codessuccess = 0,0failure = 1,65535

end

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



4.S

oftw

areD

istribu

tion

on

OS

/400

output_file_append = yerror_file_append = y

end.......

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

The following example runs the CL post program that uses thecorequisite FILE.DAT file........

execute_user_programtransactional = n

during_install

exit codessuccess = 0,0failure = 1,65535

end

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

corequisite_files

filename = “\usr\sd41\target\file.datdestination = “\usr\sd41\target\file.dattranslate = y

endend

............

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

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


176 Version 4.1

In the example, the translate attribute for the corequisite file is set toy. This enables translation from ASCII to EBCDIC and vice versa orcode page translation. Translation is performed before the file isadded to the OS/400 target.

The following example runs the native C program myprog. Thisprogram is included in the software package. As the example shows,the program is added to the OS/400 file system using the AddOS/400 Library and Add OS/400 Object actions. Therefore, thesoftware package that contains these stanzas must be defined usingthe OS/400 SPE connected to an OS/400 preparation machine. Thisis not necessary for the non-native objects shown in the otherexamples........

add os400_liblocation = “\qsys.lib”name = “mylib.lib”destination = “\qsys.lib\mylib.lib”descend = nremote = n

os400_objname = “myprog.pgm”destination = “myprog.pgm”target_release = “*CURRENT*”remote = nreplace_option = “*ALL”

endendexecute_user_program”

name = “myprogram”transactional = n

during_install

exit_codessuccess = 0,0failure = 1,65535

end

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



4.S

oftw

areD

istribu

tion

on

OS

/400

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

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

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

The purpose of this section is to provide some examples of datamoving commands used in the OS/400 environment. Thesedemonstrate the different conventions for specifying file locationsthat are used in the OS/400 environment. See “The OS/400 Nativeand Integrated File Systems” on page 158.

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

The following example moves the file “data.dat” from a Windows orUnix source host to the OS/400 IFS and runs a post-processingprogram on the target system. The command specified here isidentical to the command that would be used to take the sameactions in a Unix file system.wspmvdata -c -s @lab15124 -P sp:/usr/sd41/source -t@lab16007-os400 -P tp:/usr/sd41/target -rtpost:/usr/sd41/scripts/post.sh data.dat

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

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


178 Version 4.1

In the following example, the file data.dat is sent from a Windows orUnix source host to an OS/400 physical file. A post-processingprogram runs on the target system.wspmvdata -c -s @lab16016 -P sp:c:/usr/sd41/source -t@lab16006-os4 -P tp:/qsys.lib/mylib.lib/data.file -rtpost:/qsys.lib/mylib.lib/post.pgm data.dat

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

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

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

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

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

todelete.FILE mymember.mbr

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



4.S

oftw

areD

istribu

tion

on

OS

/400


180 Version 4.1

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 Windows 98 and Windows NT4.0 operating systems.

If you are using a Windows 98, or Windows NT 4.0, ensure that youhave the appropriate executable installed as follows:

¶ For Windows 98, the executable is instmsia.exe.

¶ For Windows NT 4.0, the executable is instmsiw.exe.

The executables can be located on the Microsoft product CD or referto the relative Microsoft documentation.

An MSI package contains all the information that the MicrosoftWindows Installer requires to install or uninstall software products.Usually, each MSI package is composed of the following:

¶ A .msi file containing the installation database

¶ Internal, external, or cabinet files required for the installation ofthe MSI package

5


5.E

mb

edd

ing

MS

IP

ackages

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

Benefits of Embedding MSI PackagesUsing Tivoli Software Distribution, you can create and then deploy asoftware package that contains an MSI package. Distributing theMSI package using Software Distribution has several benefits. Forexample, you can do the following:

¶ 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.MDist2 performs the automatic depoting of the software packagedata to the MDist2 repeaters.

¶ Store information at a central repository regarding the status ofthe deployed package for each system on the network.

¶ Execute a native MSI installation on a target system.

¶ Use the Verify operation to identify any problems with theinstallation. The Verify operation for MSI packages reports thefollowing conditions:

v That the product is not in a valid Install state.

v That features have not been installed with the state specifiedin the software package.

v That components are missing.

Note: The Verify operation for MSI packages does notidentify situations where a later version of acomponent has been overwritten by the installation.

¶ Use the Repair installation option to repair corrupted elements ofa product that is already installed. When you define the MSIsoftware package object using the Install MSI Product dialog,you can select a Reinstall Mode that determines the type ofrepair to be made.

Embedding MSI Installation Packages

182 Version 4.1

Creating a Software Package That Embeds an MSIInstallation Package

A software package object for an MSI installation defines thefollowing:

¶ The MSI file that is to be used for the installation of the producton the target. If this file is present on the system where you arecreating the software package, you can read information requiredfor creating the software package object directly from the MSIfile.

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

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

Note: Bundled installations require a large amount of disk spaceto be free on the target. This is because they create animage of the product to be installed in a specifieddirectory on the target system. These images can beretained or deleted after the MSI installation is complete.

If the location of the product images is accessible from the targetsystems, the software package needs only to contain the pathwhere they can be accessed. This is called a RedirectedInstallation.

¶ Logging options.

¶ Reinstall options, to be used if the package is applied in repairmode.

¶ Instructions for installation or non-installation of individualproduct features.

¶ Windows installer properties.

The Software package editor supports the following methods ofcreating software package objects that embed an MSI installationpackage:



5.E

mb

edd

ing

MS

IP

ackages

¶ Using a wizard, which takes input from a specified MSI file.With this method, many of the parameters are taken directlyfrom the MSI file. This method cannot be used to install patches.

¶ Using a series of dialogs to specify values for the parametersneeded for the installation. This method can be used if the MSIfile is not present on the machine where the Software PackageDefinition file is being edited.

These dialogs can also be used to edit objects created using thewizard, so that default values set in the MSI file can be changed.

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

Note: If you are using the Software Package Editor on a Windows98 platform, a DOS window appears minimized in the taskbar when you open or save a software package in SPD orSPB format. Do not close this window as this will close theentire application.

Using the Wizard to Embed an MSI PackageYou can use this method if you have access to the MSI file for theproduct you want to include in the software package.

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

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

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


184 Version 4.1

1. From the menu bar on the Software Package Editor GUI, selectTools→Importer→Install MSI Product.

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

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



5.E

mb

edd

ing

MS

IP

ackages

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

3. Enter the name of the MSI file for the product you want toinstall or click the browse button and navigate to select the file.

4. Click Next to advance to the Application Information panel.

5. Type the path for the Destination folder for the installation, ifyou know it. Otherwise, do one of the following:

¶ Select a value from the drop-down list of paths that usedefined variables.


186 Version 4.1

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

The value you enter here is assigned to the INSTALLDIRproperty. It is the folder on the target system where the productis to be installed.

6. Click Next to advance to the Target and Source panel. On thispanel, you identify the location of the product images to beused in the MSI installation.

7. If the product images are in a directory that is accessible fromthe target systems, specify that location in the Target ImagePath text box and select the Redirected Installation checkbox.

8. If the product images are in a directory that is not accessiblefrom the target systems, you must do the following:

¶ Specify the current location of the product images in theSource Image Path text box. At distribution time, theimages are retrieved from this directory and distributed tothe target systems as part of the software package.

¶ In the Target Image Path text box, specify the location onthe target system where the product images can be stored,when they are extracted from the software package. This is



5.E

mb

edd

ing

MS

IP

ackages

the directory from which the MSI installation processretrieves the product images during installation.

¶ You can select the Keep Images check box, if you want tosave the images in the Target Image Path location wheninstallation is complete.

9. Select the Available to All Users check box, if the installedproduct is to be available to all users of the target systems. Ifthis check box is cleared, the product is only available to theuser who is logged on at installation time.

10. Click Next to advance to the Product Features panel.

This panel shows an expandable tree, which lists any productfeatures that can be installed with the MSI product. The wizardobtains these details from the MSI file that you specified.

11. To change the action to be taken for a feature do the following:

a. In the expanded tree, select the feature you want to changeand right-click to display a context menu of availableactions.

b. Select the action you require.

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


188 Version 4.1

12. Click Finish to confirm all your selections and create thesoftware package object.

Using Dialogs to Embed or Edit an MSI PackageIf you do not have the MSI file on the system where you aredefining and building your software distribution package file, youcan use a set of dialogs that guide your through inputting the detailsyou need to define the install_msi_product or install_msi_patchstanzas.

Actions that open the Install MSI Product and Install MSI Patchdialogs are available from the Programs tab of the SoftwarePackage Editor GUI.

Note: You can also use these dialogs to edit the parameters ofexisting software package objects that define MSI packages,including objects created using the Install MSI Productwizard.

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

To define an MSI package using the dialogs, complete the followingsteps:



5.E

mb

edd

ing

MS

IP

ackages

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

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

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


190 Version 4.1

3. Select Install Product to install a new product or new productversion, or Configure Product to make changes to an alreadyinstalled product, then click the General tab.

If you selected Install Product, the Install MSI Product dialogappears.

4. Complete the information on the panel as follows:



5.E

mb

edd

ing

MS

IP

ackages

a. In the MSI file text box, specify the MSI file where theproduct installation information is defined.

b. If the product images are in a directory that is accessiblefrom the target systems, specify that location in the TargetImage Path text box and select the Redirected Installationcheck box.

c. If the product images are in a directory that is not accessiblefrom the target systems, you must do the following:

¶ Specify the current location of the product images in theSource Image Path text box. At distribution time, theimages are retrieved from this directory and distributedto the target systems as part of the software package.

¶ In the Target Image Path text box, specify the locationon the target system where the product images can bestored, when they are extracted from the softwarepackage. This is the directory from which the MSIinstallation process retrieves the product images duringinstallation.

¶ You can select the Keep Images check box, if you wantto save the images in the Target Image Path locationwhen installation is complete.

d. Select Available to All Users to make the product availableto all users on the target systems. If you clear this checkbox, the product is only available to the users who arelogged on to the target systems at installation time.

5. If you selected the Configure Product option, you areprompted to supply the details of the product you want toconfigure and the path where it is installed on the target


192 Version 4.1

systems.

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



5.E

mb

edd

ing

MS

IP

ackages

7. Click the Log Mode tab.

8. Disable logging by selecting the Disabled check box or definethe logging options as follows:

a. Specify the directory where the MSI log is to be stored. Youcan enter the path in the Log Path text box or click theBrowse button to navigate to the directory.

b. Select the Log Modes by selecting or clearing check boxes.

Note: The log modes shown on the screen are standardSDK log modes. For more details, see the MicrosoftPlatform SDK documentation.

c. If you want to report the MSI log entries in the SoftwareDistribution log, select Report Log.


194 Version 4.1

9. Click the Properties tab to assign values to any WindowsInstaller properties that are required for the installation.

10. To add a property, do the following:

a. Select an appropriate Windows Installer property from thedrop-down list and click Add. The property appears in thelower text box.

b. Click in text box and assign a value to the property. Forexample, TARGETDIR=C:\properties.

11. To remove a property, select the property in the text box andclick Remove.



5.E

mb

edd

ing

MS

IP

ackages

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

13. For each feature you want to add, enter the feature name in theupper box and click Add. The feature is added to theexpandable tree.

The default action, to install the feature on the hard drive, isset. If you want to change this action, select the feature andright-click. The list of available actions appears, and you canselect the one you want.

14. To delete a feature, select it and click Remove.

15. To change the default setting for the user interface level duringinstallation, click the UI level tab. The default setting is “none”,that is, a silent installation.

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


196 Version 4.1

installations are silent.

16. When you are satisfied with the settings, click OK to create thesoftware package object.

Making an MSI Installation ConditionalLike other types of software package object, embedded MSIpackages can be made conditional. You can attach one or moreconditions to an object, so that at distribution time, the object is onlyexecuted if the conditions are met.

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

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

To define conditions for an MSI package object, complete thefollowing steps:

1. With the object open in the Install MSI Product or Install MSIPatch dialog, click the Condition button in the upper right



5.E

mb

edd

ing

MS

IP

ackages

corner of the dialog.

The Condition Editor window opens.

2. Define an expression by selecting a variable from the list and anoperator from the panel and then entering a value.

For example, select the variable os_name and the operator ==and enter the value “Windows NT”, to construct the expression


198 Version 4.1

os_name==“Windows NT”

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



5.E

mb

edd

ing

MS

IP

ackages


200 Version 4.1

How Does AutoPack Work?

This chapter introduces the concepts of AutoPack technology.

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.

AutoPack automatically generates a software package by comparingtwo successive “snapshots” of a preparation machine. A preparationmachine is any Windows, OS/2, or UNIX, refer to the TivoliSoftware Distribution Release Notes for details about supportedplatforms, on which the Tivoli Software Distribution Java EndpointPackage 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 thesoftware package, AutoPack might include unwanted data and

6


6.H

ow

Do

esA

uto

Pack

Wo

rk?

system 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 98and 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 98 system:

¶ A set of files is copied to a target directory.

¶ Entries are added to the Windows Registry.

¶ .ini files are created and modified.

How Does AutoPack Work?

202 Version 4.1

¶ 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 Windows98

Windows shell Folders, shortcuts Windows NT 4.0,Windows 2000 Windows98

OS/2 profiles Items OS/2 4.0, 4.5

OS/2 desktop Generic objects,folders, programs,shadows

OS/2 4.0, 4.5

AutoPack Components


6.H

ow

Do

esA

uto

Pack

Wo

rk?

Component Managed Objects Supported Platforms

OS/2 system files(OS2.ini andOS2SYS.ini)

Items OS/2 4.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. The end of this chapter includes the defaultautopack.ini configuration files for Windows NT 4.0, Windows 2000,Windows 98, and UNIX systems.

The autopack.ini file has the same structure as a Windows .ini file. Itcontains a general section and an include and exclude section foreach system component. See the table on page 203 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

204 Version 4.1

¶ 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 for more informationabout specifying file and directory names with wildcards. Thefollowing is the syntax for the include and exclude sections forthis 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


6.H

ow

Do

esA

uto

Pack

Wo

rk?

Notes:

1. Under the FileSystem Exclude section, exclude the directorycontaining the Tivoli code.

2. The root is monitored by default. Exclude monitoring theroot if the files being installed do not affect the rootMonitoring the root can affect performance, especially onvery large systems.

See the “Autopack.ini Default for UNIX Systems” on page 216for 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.


206 Version 4.1

¶ 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.[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 profile



6.H

ow

Do

esA

uto

Pack

Wo

rk?

files 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.[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 folder


208 Version 4.1

can 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:[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 by



6.H

ow

Do

esA

uto

Pack

Wo

rk?

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

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 ScenariosThere are certain user scenarios 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. When the differencing phase is launched from the SoftwarePackage Editor, the process hangs if the software package beingcreated contains a large number of objects. To avoid thisproblem, replace ″ -mx50m ″ with ″ -mx100m ″ in the requiredfile:

¶ On Windows NT and Windows 2000 platforms: thespeditor.bat file.

¶ On Windows 98 platforms: the swspe_95.bat file.

2. 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 98system.

¶ 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:


210 Version 4.1

C:\Windows\Cookies\index.datC:\Windows\History\index.datC:\Windows\Temporary Internet Files\index.dat

3. For distributions that update Windows system files, which couldbe locked in read or write, it is advisable to perform theinstallation in undoable-in-transactional mode. In such a case, abackup copy of the locked files is made during the commitphase.

4. When you create a software package using AutoPack that installsthe Norton AntiVirus product on a Windows 2000 endpoint, thedistribution fails if the following registry key is included in thesoftware package:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ServiceCurrent

For a successful distribution, add the registry key to theWinRegistry Exclude section.

5. When you create a software package using AutoPack for eitherthe installation of NetWare Client 5 software, or the McAfeeanti-virus software, and install it on a Windows NT endpoint, thedistribution fails. If you create a software package usingAutoPack for software that modifies the system networkconfiguration of a machine or that installs drivers, you mustmodify 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

Note: It is not recommended that you permanently delete thisline from 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

6. The OverrideRegistryPermissions option must be set to y (yes) ifyou are running any of the following user scenarios:



6.H

ow

Do

esA

uto

Pack

Wo

rk?

¶ 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

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

8. When you create a software package using AutoPack that installsMicrosoft Office 2000 software on a Windows NT endpoint, thedistribution fails because of a locked file. For a successfuldistribution, add the following file to the FileSystem Excludesection:C:\WINNT\Schedlog.txt

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.

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


212 Version 4.1

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 andWindows 2000

[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[WinProfiles Include]C:\WINNT\*.ini[WinRegistry Include]HKEY_LOCAL_MACHINE\SOFTWAREHKEY_CURRENT_USERHKEY_USERS\.DefaultHKEY_LOCAL_MACHINE\System\CurrentControlSet



6.H

ow

Do

esA

uto

Pack

Wo

rk?

[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\*.*

Autopack.ini Default for Windows 98[General]WorkingDir=C:\Program Files\Tivoli\swdis\1\autopack[FileSystem Include]C:\[TextFiles Include]c:\autoexec.bat


214 Version 4.1

c:\config.sys[TextFiles Exclude][WinProfiles Include]C:\WINDOWS\*.ini[WinProfiles Exclude]C:\WINDOWS\progman.iniC:\WINDOWS\wininit.iniC:\WINDOWS\swdis.ini[FileSystem Exclude]C:\WINDOWS\TEMP\*.*C:\Program Files\Tivoli\swdis\1\*.*C:\WINDOWS\swdis.*C:\WINDOWS\*.grpc:\boot.ini*\win386.swp*\pagefile.sysC:\WINDOWS\*.inic:\autoexec.batc:\config.sys??\recycler\*.*??\recycled\*.*C:\WINDOWS\SYSTEM\config\*.**.lnkC:\WINDOWS\APPLOG\*.*C:\WINDOWS\SchedLgU.TxtC:\WINDOWS\DEBUG\*.*C:\WINDOWS\system.datC:\WINDOWS\user.datC:\WINDOWS\*.pwl[WinRegistry Include]HKEY_LOCAL_MACHINE\SOFTWAREHKEY_CURRENT_USERHKEY_USERS\.DefaultHKEY_LOCAL_MACHINE\System\CurrentControlSet[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\PendingFileRenameOperations



6.H

ow

Do

esA

uto

Pack

Wo

rk?

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


216 Version 4.1

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

7


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

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

218 Version 4.1

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


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

220 Version 4.1

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 scans the specified drive andstore the current configuration information and directory structure inthe working directory.

Running AutoPack


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

3. Leave the Customize system monitoring check box selected tospecify objects to monitor or exclude during the differencing

Creating the First Snapshot

222 Version 4.1

phase, 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 228.

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 206. The Text Files section on page 206 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.



7.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

Note: The default files to include and exclude are different foreach supported platform. Windows, OS/2, and UNIX listdifferent 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.


224 Version 4.1

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

6. Click Next to display the Registry Entries to Exclude dialog.



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


226 Version 4.1

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



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

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.


228 Version 4.1

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. Use this option together with Replace ifexisting to verify if an existing file must be replaced.

The Manual Installation Option


7.G

eneratin

ga

So

ftware

Packag

eU

sing

Au

toP

ack

Compute CRCWhen this option is selected, after the installation of afile, 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. The


230 Version 4.1

remaining steps are executed after you have fully installed theTivoli desktop software and relaunched the AutoPack guidedprocess.

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.



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

232 Version 4.1

this information if necessary.

4. Click Next. AutoPack displays the remaining operations to beperformed.



7.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 143 for details on modifying software package properties.See “Saving the Software Package” on page 151 for details onsaving the package in different formats.


234 Version 4.1

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 formore information about disconnected CLI commands.

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



7.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 229for more information about this dialog.

3. Click Next. A list of operations to be executed is displayed.

The Automatic Installation Option

236 Version 4.1

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



7.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 143 forinformation about modifying the properties of the softwarepackage. See “Saving the Software Package” on page 151 forinformation about saving the software package in differentsoftware package formats.


238 Version 4.1

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) and isused to configure or install an application. It contains predefinedworkstation, sharing, and inventory property settings. Using the PDFImporter Tool from the Software Package Editor window, TivoliSoftware Distribution takes a PDF as input and maps the datacontained in the file to specific software package properties. Theresult is a software package displayed in the Software PackageEditor window consisting of a generic container containing an adddirectory action and a sequence of execute programs. For example,the distribution of this software package can be used to configureand install an application. See “Using the PDF Importer Tool” onpage 243 to follow how the PDF Importer is used to configure theinstallation options of the Norton AntiVirus product.

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]

8


8.U

sing

the

PD

FIm

po

rterTo

ol

¶ [Setup Package for Inventory]

¶ [FileIndex]

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.

Using the PDF Importer

240 Version 4.1

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

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



8.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 116 for moreinformation about the execute program action.


242 Version 4.1

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 247, 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.



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


244 Version 4.1

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



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


246 Version 4.1

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]



8.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=


248 Version 4.1

BYTE=WORD=LONG=TOKEN 1=TOKEN 2=TOKEN 3=TOKEN 4=



8.U

sing

the

PD

FIm

po

rterTo

ol


250 Version 4.1

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 serverthrough 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 some of the network complexities that facetoday’s businesses. This scenario describes the step-by-stepprocedure for configuring a distribution environment. It includes thefollowing steps:

9


9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

¶ Assessing the network topology and available departmentalresources.

¶ Determining the hierarchy of repeaters that best suits the actualnetwork topology exploiting the multiplexed distribution servicefor improved performance.

¶ Creating the necessary repeaters, their range of managed nodeclients, and parameters. For a repeater gateway, its endpoints areautomatically multiplexed by the gateway when they areassigned to the gateway. You can also configure a managed nodewith the MDist 2 service to create a standalone repeater site.

¶ Tuning and configuring repeaters as depots to store MDist 2distribution data in order to reduce network traffic for frequentlydistributed data sets.

You can also configure the distribution manager by creating a RIMdatabase and a RIM object in order to monitor and controldistributions. The distribution manager stores status informationabout a distribution in the database tables. There is one distributionmanager for each Tivoli management region that keeps track of allthe distributions started in it. If the distribution spans multiple Tivolimanagement regions, all status information is stored in thedistribution manager in the initiating Tivoli management region andno status information is stored in the interconnected Tivolimanagement regions.

Additional tuning is required for the roaming endpoints feature.Refer to the Tivoli Management Framework Planning forDeployment Guide for more information about the roaming endpointfeature.

For the purpose of this scenario, we assume that you are the seniorsystem administrator at NoonTide. The senior authorization role isrequired to perform the procedures described in this scenario.

252 Version 4.1

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 isdivided 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 Tivolimanagement region environment, each policy region houses eachdepartment’s resources such 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 a

Introducing NoonTide


9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

UNIX managed node gateway, called 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 policyregions 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 Tivolimanagement region server (Tivoli server) is installed. The name ofthe default policy region is taken from the name of the machine thatis hosting the Tivoli 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 100 Mbps (megabits per second), or by T1 lines,which have bandwidths of 1 Mbps.

Each subnet contains a UNIX or an NT managed node gateway thatconnects to the Tivoli server. Endpoint gateways are installed onmanaged nodes in subnets that have endpoint clients. To distribute asoftware package profile to a managed node or gateway, you mustinstall the endpoint service on it first.

Note: Only endpoints can be targets of distributions. Managed nodesare no longer supported as targets with this release.

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,

Introducing NoonTide

254 Version 4.1

including target clients and repeater sites. See “Configuring RepeaterSites” on page 262 for more information about 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. Forinformation 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 3 Subnet 4 Subnet 5 Subnet 6 Subnet 7

Subnet 2Subnet 1

pescado

Tivoli management region server

oak big pearl diamond lapis

odin

rainbow

dollar

electron

Ethernet connectionT1 connection

lolo

alloy

Network Architecture


9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

Subnet 1Subnet 1 includes machines that are connected by LAN to the Tivoliserver, pescado, in the corporate office. Subnet 1 includes machinesin the NoonTide Operations, NoonTide Administration, andMarketing departments.

NoonTide Operations

odin (Solaris managed node gateway) balder (Solaris)

thor (Solaris) loki (Solaris)

NoonTide Administration

rainbow (AIX managed node gateway) green (Windows 98)

red (Windows 98) blue (Windows 2000)

orange (Windows 2000) yellow (Windows 2000)

violet (Windows NT)

NoonTide Marketing

dollar (AIX managed node gateway) peso (Windows 98)

shilling (Windows 98) franc (Windows 2000)

pound (Windows 98) drachma (Windows 98)

rupee (Windows 2000) dinar (Windows 200)

yen (Windows NT) lira (Windows 2000)

Subnet 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 node) silver (Windows 98)

gold (Windows 98) platinum (OS/2)


256 Version 4.1


alloy (Windows NT 4.0 managed nodegateway)

Subnet 3Subnet 3 is located in the corporate office and is connected by anEthernet connection to pescado. It includes machines in theNoonTide Support department.


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 NT) camembert (HP-UX)

cottage (Windows 98) ricotta (AIX)

american (Solaris) parmesan (AIX)

jack (HP-UX) bleu (HP-UX)

provolone (AIX) edam (HP-UX)

gouda (AIX) gruyere (AIX)

swiss (HP-UX) stilton (HP-UX)

cheddar (HP-UX)



9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

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.

NoonTide Sales (West Coast)

pearl (Windows 2000 managed node gateway) agate (Windows 98)

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 98)

ruby (Windows 2000)

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 2000)

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.1 uses MDist 2 only. MDist 2 enables you toperform asynchronous distributions of large amounts of data to


258 Version 4.1

multiple targets in an enterprise. The MDist 2 service maximizesNoonTide’s data throughput by performing the following operations:

Parallel distributionEnabling parallel distribution to hosts on the same subnet.Using this feature, the data flows from the source hostpescado through the dollar and rainbow gateway repeatersand down to the endpoints, if both the Marketing andAdministration departments need this application. Thisfeature results in a distribution that can be faster thansending copies of the software in serial to each machine.

Spreading the distribution load across networksSpreading the distribution load across networks. Spreadingthe distribution load across a network tree limits resourcecontention that can arise when one server is responsible fordistributing to many client machines.

Sending single copies of the data across slower linksThe repeaters redistribute the single copies in parallel toother hosts on the far side of the slow connection. Thisdistribution is a more effective use of the network thansending a copy of the software across the network gatewayfor each remote target. For example, pescado can efficientlydistribute to pearl, diamond, and lapis using electron as arepeater site.

Using repeater depotsEnabling 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 datasegments. A repeater configured as a permanent depotmaintains the data in the repeater depot even after thedistribution has completed. A repeater depot also enables youto store software distributions on nodes closer to the targets.For example, the diamond gateway, which has repeaterdepot functionality, can start a distribution to softwarepackages from its repeater depot to the target systemsassociated with it, rather than from the source host.

Creating a Repeater Hierarchy


9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

Caching distributionsCaching distributions, which enables the checkpoint restartfunctionality. If a distribution failure occurs for one target,the fan-out point continues to distribute to the other targets.The interrupted distribution automatically resumes fromwhere it left off using the data from the repeater depot,rather than beginning all over again from the origin of thedistribution data.

By default, the Tivoli server pescado serves as the repeaterdistribution server for all the targets in the Tivoli managementregion. Pescado is also the source host and therefore also a repeater.The source host machine must be a repeater. Endpoint gateways areautomatically configured to act as MDist 2 repeaters for distributinginformation to their endpoints. The NoonTide network includesendpoint gateways at odin, big, pearl, diamond, and lapis.NoonTide has configured the rainbow and dollar gateways to serveas additional MDist 2 repeaters. The network also includes electron,a standalone repeater with the MDist 2 function.

The following diagram shows NoonTide’s repeater hierarchy. Thearrows represent the distribution flow.The distribution flow would bedifferent if the source host was not located on the pescado Tivoliserver but on a separate managed node. In this case, the distributionflow would originate at the source host.


260 Version 4.1

As in the case of the NoonTide network, one repeater site is oftennot 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.



9.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. Any repeater can be configured tobe a depot. The placement of the repeater depots depends on whereyou need depot storage facilities in your Tivoli environment. It isrecommended that you place depots on the other side of slownetwork links, like WANs, to enable quicker distributions. You mustalso consider the disk space required for the storage of distributions,especially if entire distributions are stored after they complete. Youneed to calculate the size of the distribution and select a system withthe 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 how to configure a repeater as a depot. Refer tothe Tivoli Management Framework Planning for Deployment Guideto determine repeater and repeater depot environments and settingsthat will 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 typing thewrpt command from the command line of any managed node inthe Tivoli management region. For example, when you firstinstall Tivoli Management Framework on the pescado server,wrpt gives the following output:pescado [1] wd []


262 Version 4.1

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 Tivoli management region to list theclients of the pescado repeater:odadmin odlist

The output of this command is as follows:

Region Disp Flags Port IP address Hostname(s)

2012560680 1 ct- 94 146.84.1.38 pescado,pescado.noontide.com

2 ct- 94 127.64.1.1 odin,odin.noontide.com

3 ct- 94 127.64.8.1 rainbow,rainbow.noontide.com

4 ct- 94 127.64.9.1 dollar,dollar.noontide.com

5 ct- 94 127.64.2.1 electron,electron.noontide.com

6 ct- 94 127.64.3.1 oak,oak.noontide.com

7 ct- 94 127.64.4.1 big,big.noontide.com

8 ct- 94 127.64.5.1 pearl,pearl.noontide.com

9 ct- 94 127.64.6.1 diamond,diamond.noontide.com

10 ct- 94 127.64.7.1 lapis,lapis.noontide.com

11 ct- 94 127.64.2.2 alloy, alloy.noontide.com

This list contains the names and IP addresses of managed nodesin each subnet shown in “Network Architecture” on page 254.Endpoints are not listed because they do not have the full TivoliManagement Framework (oservs). Endpoints rely on managednodes for communication with the Tivoli server.

3. Create a repeater site on all managed nodes that serve asstandalone repeaters in the repeater hierarchy. Endpoint gatewaysare automatically configured as repeater points for their clientendpoints. To create a standalone repeater, use the wrptcommand as follows:wrpt –n repeater_name range=value

Configuring Repeater Sites


9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

In the NoonTide environment, enter the following command tomake electron a standalone repeater that serves the pearl,diamond, and lapis gateway repeaters:wrpt –n electron range=8-10

Refer to the Tivoli Management Framework User’s Guide formore information about creating a standalone repeater.

4. Use the wrpt command to verify that repeater sites areconfigured correctly. The output for NoonTide’s configurationfollows:pescado [1] -wd- []odin [2] --- []rainbow [3]] --- []dollar [4]] --- []electron [5] --- [8, 9, 10]oak [6] --- []big [7] --- []pearl [8] --- []diamond [9] --- []lapis [10] --- []alloy [11] --- []

The electron repeater lists the host numbers of the machines 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 the pearl, diamond, and lapisgateways. Finally, pearl, diamond, and lapis distribute the softwarepackage to their endpoints. Each repeater and endpoint gatewaydistributes software package A in parallel to its endpoint clients.Refer to the Tivoli Management Framework Reference Manual formore information about the wrpt and odadmin commands.

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.

Configuring Repeater Sites

264 Version 4.1

Refer to the Tivoli Management Framework Reference Manual formore information about the syntax and arguments of the wmdistcommand.

You configure each repeater and endpoint gateway in the NoonTidenetwork in accordance with the amount of available memory, diskspace, and network bandwidth, and the number and bandwidthcapacity of the repeater’s targets.

The following procedure configures the electron (a Windows NTmachine) and pescado (a Solaris machine) repeaters by performingthe following steps:

1. “Step 1: List the Current Settings of the Repeaters’ Parameters”.

2. “Step 2: Determine the Disk Space Requirements of theApplications to be Distributed” on page 269.

3. “Step 3: Check that the Electron and Pescado Sites Have theRequired Disk Space and Memory” on page 269.

4. “Step 4: Set Electron’s Repeater Parameters” on page 271.

5. “Step 5: Set Pescado’s Repeater Parameters.” on page 272.

6. “Step 6: Verify that the Repeater Parameters are Set Correctly”on page 272.

7. “Step 7: Restart the Repeater” on page 273.

Step 1: List the Current Settings of the Repeaters’Parameters

Enter the following wmdist command:wmdist -s electron

wmdist -s pescado

The following is the default output of this command for the electronrepeater. The default output for the pescado repeater is the same,except that the default repeater directory for a UNIX repeater is/var/tmp/.repeater_id: 2012560680.5.7rpt_dir: $DBDIR/tmp/permanent_storage: TRUE

Setting Repeater Parameters


9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

max_sessions_high: 5max_sessions_medium: 10max_sessions_low: 40disk_max: 500 (MB)mem_max: 64 (MB)send_timeout: 300 (secs)execute_timeout: 600 (secs)notify_interval: 30 (mins)conn_retry_interval: 900 (secs)retry_ep_cutoff: 7200 (secs)net_load: 500 (KB/sec)packet_size: 16 (KB)target_net_load: 0 (KB/sec)debug_level: 3debug_delay: 0

where:

rpt_dir=pathnameSpecifies the repeater’s main directory. It is also the parentdirectory that is used to hold the depot directory and thestates directory. The depot directory contains all thesegments stored in the database and must have enough freespace to hold the value of disk_max. The states directorycontains the database that holds the persistent state of therepeater’s queue.

permanent_storage=TRUE|FALSEConfigures the repeater to be a depot. If TRUE, the depotretains segments marked for permanent storage byapplications after their distribution finishes. If FALSE, adistribution’s segments are deleted after the repeater finishessending the distribution to all its targets.

max_sessions_high=numberSpecifies the maximum number of concurrent connectionsthat a repeater opens for high-priority distributions. Theseconnections are shared among all active distributions. If therepeater runs out of high-priority connections, it tries to usea medium-priority connection.

max_sessions_medium=numberSpecifies the maximum number of concurrent connectionsthat a repeater opens for medium-priority distributions. These


266 Version 4.1

connections are shared among all active distributions. If therepeater runs out of medium-priority connections, it tries touse a low-priority connection.

max_sessions_low=numberSpecifies the maximum number of concurrent connectionsthat a repeater opens for low-priority distributions. Thisnumber must be one or greater. These connections are sharedamong all active distributions. If the repeater runs out oflow-priority connections, it waits for an open connection tocomplete before opening additional connections.

disk_max=max_size_MBSpecifies the amount of disk space allocated to the repeaterdepot. Units are in megabytes (MB). If the disk_max numberequals zero, no limit is enforced. This number cannot exceedthe size of the disk. Every distribution flowing through arepeater is stored at least temporarily in the depot. The depotmust be large enough to hold the largest distribution that youexpect to distribute.

mem_max=max_size_MBSpecifies the amount of memory used to buffer data beingsent to targets. This buffer improves performance byreducing the number of disk accesses to the depot. Thememory is shared among all active distributions. Units are inMB.

send_timeout=secondsSpecifies the timeout used to detect a network or targetfailure while sending data. A target is allowed send_timeoutseconds to receive each packet on the network. If a timeoutoccurs, the distribution remains in the repeater’s queue and aretry occurs in conn_retry_interval seconds. Refer to theTivoli Software Distribution Reference Manual for moreinformation about how Tivoli Software Distribution setstimeout values for a distribution.

execute_timeout=secondsSpecifies the time an endpoint method has to return resultsafter it has received all of a distribution’s data. Tivoli



9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

Software Distribution may be running scripts after receivingdata but before returning results to the repeater. Units are inseconds. Refer to the Tivoli Software Distribution ReferenceManual for information about overwriting this parametersetting by using the execute_timeout attribute.

notify_interval=minutesSpecifies the time interval (in minutes) between successivestatus reports. As targets finish, their results are buffered bythe repeater. When the notify_interval (in minutes) haselapsed or all of the targets of this distribution have finished,the results are flushed. The results are sent to the applicationusing MDist 2 and updated in the MDist 2 database. Refer tothe Tivoli Software Distribution Reference Manual forinformation about overwriting this parameter setting usingthe notify_interval attribute.

conn_retry_interval=secondsSpecifies the time (in seconds) that must elapse beforeunavailable or interrupted targets are retried.

retry_ep_cutoff=secondsSpecifies the amount of plan time (in seconds) that arepeater retries an unavailable or interrupted endpoint.Unavailable or interrupted repeaters are retried until thedistribution’s deadline has been reached.

net_load=KB_per_secondSpecifies the maximum amount of network bandwidth therepeater is allowed to use. Units are in kilobytes per second.This allocation is shared among all active distributions. Usedwith target_netload.

packet_size=numberSpecifies the number of bytes written to the network duringeach send.

target_netload=KB_per_secondsSpecifies the maximum amount of network bandwidth thatcan be sent to an individual target. Units are in kilobytes persecond. The default value of 0 disables this check. Used withnet_load.


268 Version 4.1

Some of these parameters can be overwritten for a particulardistribution by specifying them in the distribution options atdistribution time. For more information about repeater parameters,refer to the Tivoli Management Framework User’s Guide and theTivoli Management Framework Reference Manual.

Step 2: Determine the Disk Space Requirements of theApplications to be Distributed

Determine the disk space requirements of the applications to bedistributed by referring to the installation guides for the applications.

In this scenario assume that the installation media and some of theapplication files of the software to be distributed are distributed inthe software package. The installation media requires 180 MB andthe application requires about 25 MB. Thus, assume the largestsoftware package will be 210 MB, considering the overhead of theconfiguration programs and the software package.

Step 3: Check that the Electron and Pescado Sites Have theRequired Disk Space and Memory

Check that the electron and pescado sites have the required diskspace and memory in the directory represented by rpt_dir.

Note: You must be logged in as Administrator to perform the stepsto determine disk space and memory allocations.

1. Check for available disk space on electron (a Windows NTmachine) by clicking Start→Programs→AdministrativeTools→Disk Administrator.



9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

The C:\ drive has 388 MB of free disk space and the D:\ drivehas 1484 MB of free disk space.

2. Check for available memory on electron by clickingStart→Programs→Administrative Tools→Windows NTDiagnostics.

3. Select the Memory tab to display the following window:

About 148 MB (152,016) of memory are available.

4. Check for available memory on pescado (a Solaris machine), andlocate a file system with free space that can be used to bufferdistributions. (Commands used for finding available memoryvary by operating system.)

To check the amount of RAM installed on the machine, enter theprtconf | grep “Memory size” command. Note that thiscommand returns the total amount of memory installed, not justthe free memory. The output is:Memory size: 512 Megabytes

Finally, to check the disk partitions for available space, use thedf –k command. The output is:


270 Version 4.1

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

Because the /tmp file system uses a portion of swap space it isnot a good choice to use as a repeater. The /var file system is thebest choice for this system because it has the largest free spaceand it does not use swap space.

Step 4: Set Electron’s Repeater ParametersThe send_timeout parameter is not reconfigured in this example. Theslowest system on the network is a Pentium with 32 MB of RAM.The default send_timeout is 300 seconds, which is sufficient for thissystem’s configuration.

1. Set the mem_max and disk_max parameters. For performancereasons, do not set mem_max higher than the available RAM.The memory cache reduces disk access to improve performance.If mem_max is larger than available memory, it causes the datato be swapped to disk and the performance gain will be lost. Toavoid the possibility of a failed distribution, set the disk_maxparameter to the majority of the hard drive space available on therepeater. For example, the electron repeater has 148 MB ofavailable physical memory and 1.5 GB of free space on the D:partition of its hard drive. The following command sets themem_max parameter to 100 (so as not to reserve all the availablememory for the repeater cache) and the disk_max parameter to1000.wmdist -s electron mem_max=100 disk_max=1000

2. Set the rpt_dir parameter to be on a partition with at least thespecified disk_max value of free space. In this case, specify therepeater main directory for the electron repeater on the D:partition, under D:\tivoli\rptdir:wmdist -s electron rpt_dir=D:\tivoli\rptdir



9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

You can use a backslash (\) in the directory path if you enter thiscommand from electron. If you enter this command from aUNIX managed node, you must qualify the backslash withanother backslash or use a forward slash (/) as follows:D:/tivoli/rptdir

Step 5: Set Pescado’s Repeater Parameters.Set pescado’s repeater parameters.

1. Pescado’s physical memory is 512 MB. If pescado is used fortasks in addition to acting as a repeater, set this parameter to usea smaller portion of the resources.wmdist -s pescado mem_max=128

2. Set the rpt_dir and disk_max parameters. The /var file systemhas available disk space and files should be buffered in the/var/tmp directory. Of the 297 MB available on /var, the repeaterwill be limited to use 230 MB to ensure that it does not use allof the file system’s space.

Set the parameters as follows:wmdist -s pescado rpt_dir=/var/tmp disk_max=230

Note: For network connections with different bandwidths, therepeater parameter values must be scaled proportionally.

Step 6: Verify that the Repeater Parameters are SetCorrectly

Verify that the repeater parameters are set correctly using the wmdist–s command for each repeater. The output for the electron repeateris as follows:repeater_id: 2012560680.5.7rpt_dir: D:\tivoli\rptdirpermanent_storage: TRUEmax_sessions_high: 5max_sessions_medium: 10max_sessions_low: 40disk_max: 1000 (MB)mem_max: 100 (MB)send_timeout: 300 (secs)execute_timeout: 600 (secs)notify_interval: 30 (mins)conn_retry_interval: 900 (sec)retry_ep_cutoff: 7200 (secs)


272 Version 4.1

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: 128 (MB)send_timeout: 300 (secs)execute_timeout: 600 (secs)notify_interval: 30 (mins)conn_retry_interval: 900 (sec)retry_ep_cutoff: 7200 (secs)net_load: 500 (KB/sec)packet_size: 16 (KB)target_netload: 0 (KB/sec)debug_level: 3debug_delay: 0

Step 7: Restart the RepeaterTo stop and restart a specific gateway and its repeater, enter thefollowing command:wgateway gateway_name restart

Standalone repeaters restart after 20 minutes of inactivity. You canwait until the repeater restarts or enter the following command:odadmin reexec dispatcher_number

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. When you have configured arepeater as 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 the



9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent

wuldsp command to unload a software package from a repeaterdepot. Refer to the Tivoli Software Distribution Reference Manualfor more information about the commands. A temporary depot workslike a permanent depot except that it deletes the segments associatedwith a distribution when the distribution is completed. It isrecommended that you use depots at the end of slow, unreliablenetwork links. However, do not use depots for extremely largedistributions or data that changes frequently.

The following scenario shows how to configure the lapis repeater asa repeater depot, load a software package on the depot, install asoftware package from the depot, list the entries on the depot, andremove a software package from a depot.

1. Configure the lapis 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 lapis repeater to be a repeater depot, use thewmdist command and set the permanent_storage parameter totrue as follows:wmdist -s lapis permanent_storage=TRUE

2. Load the mypackage software package on the lapis repeaterdepot. To load the software package, use the wldsp command asfollows:wldsp @mypackage lapis

If the software package contains nested software packages on thedepot, use the wldsp command to load the primary softwarepackage. This automatically loads the nested software packagesthat it contains. In this case, a multi-segment distribution issubmitted to MDist 2 where each segment contains a differentpackage.

3. Perform an installation of the mypackage software package fromthe lapis repeater depot using the winstsp command as follows:winstsp -l from_depot @mypackage @sapphire

Using Repeater Depots

274 Version 4.1

If you have configured an RDBMS Interface Module (RIM)database, you can use the wmdist command together with the –e,–l, and –i arguments to monitor and control the distribution.

4. List the entries on the lapis repeater depot and informationrelated to each entry. This includes the ID, version, size,percentage completed, and last modification time. To list theentries, use the wdepot command with the –l argument asfollows:wdepot lapis list -l

5. Remove the mypackage software package from the lapis depot.Use the wuldsp command as follows:wuldsp @mypackage lapis

6. Delete all entries in the depot. Use the purge argument asfollows:wdepot lapis purge

You will be prompted for confirmation before the depot ispurged.



9.U

nd

erstand

ing

the

Distrib

utio

nE

nviro

nm

ent


276 Version 4.1

The Distribution Process

This chapter describes how you prepare software packages fordistribution in the Tivoli environment. From the Tivoli desktop, youcan define software packages, associate them with target machines,and distribute them to those machines, in parallel, in the same ordifferent Tivoli management regions.

You use the Tivoli desktop to import software packages into theTivoli environment, in which you can perform Tivoli SoftwareDistribution operations. The desktop supports all the operations thatyou can perform from the command line interface (CLI). Forinformation about commands, refer to the Tivoli SoftwareDistribution Reference Manual.

To perform Tivoli Software Distribution tasks, you must haveappropriate authorization. For more information about authorization,See “Authorization Roles” on page 557.

This chapter provides instructions for:

¶ Creating profiles within a profile manager, and importingsoftware packages into that profile, and for setting profilesubscribers (the profile managers and endpoints) for the profilemanager in which the profiles reside. See “Creating a TivoliSoftware Distribution Profile” on page 278.

¶ Preparing the software package for distribution within the Tivolienvironment. See“Importing a Software Package into the TivoliEnvironment” on page 285.

10


10.T

he

Distrib

utio

nP

rocess

¶ Defining the properties of a software package using either theSoftware Package Editor or the command line. See “SoftwarePackage Properties” on page 290.

¶ Calculating the size of newly created software packages and forrecalculating them if they have changed since their creation. See“Calculating the Size of a Software Package” on page 292.

¶ Converting the software package file format from softwarepackage to software package block, and vice versa. See“Converting a Software Package” on page 293.

¶ Exporting a software package object into text file (.spd) formatto produce the software package definition file. This definitionfile can be modified and imported into a software package orsoftware package block. See “Exporting a Software Package” onpage 295.

¶ Using change management operations on software packageobjects. See “Change Management Operations” on page 297.

Creating a Tivoli Software Distribution ProfileYou create a Tivoli Software Distribution profile within a profilemanager that has been defined in a policy region. You then importsoftware packages into Tivoli Software Distribution profiles. Howyou do this is exemplified in the following scenario, in which youcreate a Tivoli Software Distribution profile from the Tivoli desktopand import the Appsample software package.

In this scenario, the distribution environment comprises thefollowing:

¶ An administrator: Root_msecchi-region

¶ A policy region: msecchi-region

¶ A managed node: msecchi

¶ A profile manager that contains several software distributionprofiles: PM1

The Distribution Process

278 Version 4.1

To determine the administrator’s name that was defined for the rootuser ID when Tivoli Management Framework was installed on theserver, double click on the Administrators icon.

1. Double-click the msecchi-region icon to display the contents ofthe policy region.

Creating a Tivoli Software Distribution Profile


10.T

he

Distrib

utio

nP

rocess

2. In the Policy Region: msecchi-region dialog, select Create →ProfileManager to create a profile manager in which theAppsample software package profile will reside. The CreateProfile Manager dialog is displayed.

3. In the Name/Icon Label text box, type PM2.

4. Select the Dataless Endpoint Mode check box to enable theprofile manager to distribute software package profiles toendpoints.

Note: If you do not select the Dataless Endpoint Mode checkbox, the system is in database mode. This enablesdistribution of software package profiles to any profilemanager that has endpoints as subscribers. For moreinformation about dataless and database modes, refer tothe Tivoli Management Framework Planning forDeployment Guide.

5. Click Create & Close to return to the Policy Region:msecchi-region dialog. This now shows the PM2 profile manager.

6. To create a profile in the PM2 profile manager, double-click thePM2 icon to open the Profile Manager dialog.

7. Select Create → Profile to display the Create Profile dialog. Inthis dialog you create a software package profile for the


280 Version 4.1

APPsample software package.

8. In the Name/Icon Label text box, type the Appsample^1.0profile name.

Note: The string that represents the software package name andversion must be formed so that the name is separated fromthe version by one of the following characters:

¶ Caret (^)

¶ Dot (.)

Refer to the Tivoli Software Distribution ReferenceManual for more information about software packagename and version syntax.

9. Click Create & Close to create the new profile and return to theProfile Manager dialog. An icon representing the newly createdsoftware package profile, Appsample^1.0, is displayed in thePM2 profile manager. The format of the software package profile



10.T

he

Distrib

utio

nP

rocess

at 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: The target on which you perform the distribution of asoftware package cannot be a managed node. It must be anendpoint.

Software packages install successfully only on endpoints; however,file packages and AutoPacks can include managed nodes as


282 Version 4.1

subscribers. This limitation may govern how you organize yourprofile managers. Keep your profile managers homogeneous wherepossible: avoid mixing software packages with Version 3.6.x filepackages or AutoPacks in the same profile manager.

When performing an install change management operation you canselect subscribers from those already available in that particularprofile manager. However, when you select Profile Manager →Distribute from the Profile Manager dialog menu, you distribute toall subscribers identified in that profile manager, and you cannotselectively choose them for each type of package in the profilemanager.

In the following scenario you add two endpoints as the subscribersto the PM2 profile manager.

1. From the Profile Manager dialog, select the Appsample^1.0profile.

2. Select Profile Manager → Subscribers to display the Subscribersdialog:

3. To move a subscriber to the Current Subscribers list, select oneor more subscribers from the Available to become Subscribers



10.T

he

Distrib

utio

nP

rocess

list, 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, select one or more subscribers from theCurrent Subscribers list and click the right arrow button tomove them to the Available to become Subscribers list.

4. Move the PM1 (Profile Manager) subscriber to the CurrentSubscribers list, then click Set Subscriptions & Close. ThePM1 subscriber is added to the PM2 Profile Manager dialog.


284 Version 4.1

Importing a Software Package into the TivoliEnvironment

Before you can use a software package profile to distribute asoftware package to a target system, you must import the softwarepackage into the Tivoli environment where it is cataloged as asoftware package object in the Tivoli object database. The softwarepackage profile is only a definition of the information that eachprofile item includes. The profile items must be populated with thedatabase objects to be distributed. You can import an existingsoftware package located on either an endpoint or managed nodeinto the software package profile, or you can create a new softwarepackage within the software 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, ensure that the Tivoli Software DistributionSoftware Package Editor component is installed and perform thefollowing steps:

1. Create a software package profile as defined in “Creating aTivoli Software Distribution Profile” on page 278.

2. Right-click the software package profile icon from the ProfileManager dialog, then select Properties from the pop-up menu.The Software Package Properties dialog is displayed.

3. Click Launch Software Package Editor to display the CreateSoftware Package dialog. Type 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” on page 53.

6. Save the software package and return to the software packageprofile in the Profile Manager dialog. Check that the softwarepackage has been imported into the software package profile.

Importing a Software Package into the Tivoli Environment


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


286 Version 4.1

1. Right-click the Appsample^1.0 profile from the Profile Managerdialog, then select Import from the pop-up menu.



10.T

he

Distrib

utio

nP

rocess

The Import dialog imports a software package file into asoftware package profile.

2. 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, type the name of theendpoint in the Endpoint Name text box and then click theellipsis (...) button.

3. Select Managed Node from the Machine Type drop-down list,then type msecchi in the Managed Node Name text box.

4. Click the ellipsis (...) button to display the Select Input Filedialog. The dialog displays 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 softwarepackage 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. You can import the software package either in the built format orin the not-built format.


288 Version 4.1

To import the Appsample software package in the not-builtformat, perform the following steps:

a. Deselect the Build check box in the Location of SourceHost group box.

b. In the Source Host Name text box, type the name of thesource host. The package is built at distribution time and theresources referenced in the software package are collectedfrom the specified source host. Ensure that, when a packageis being built at distribution time or imported to the builtformat, the source host component is installed on the sourcehost. If not an error occurs.

—OR—

To import the Appsample software package in the built format,perform the following steps:

a. Select the Build check box.

b. Type the SPB path in the SPB Path text box. If the input fileis a software package or software package definition file, it isimported into a software package block. If the input file is asoftware package block, it is copied from the managed nodeor endpoint specified in the Location of Input File groupbox 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 checkbox. Select Overwrite to overwrite the software packageblock should it already exist on the source host.

In this scenario, deselect the Build check box.

7. In the Source Host Name text box, type the source host fromwhich the files in the software package block are to be obtained,if it is not already defined in the input file.



10.T

he

Distrib

utio

nP

rocess

Note: The source host can be any of the available managednodes on which the Tivoli Software Distribution sourcehost component is installed.

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.

To remove previously distributed software packages from targetsystems, you perform a Remove change management operation. See“Remove Operation” on page 318 for more information aboutremoving a software package.

Software Package PropertiesSoftware package properties can be defined in the following ways:

¶ Using the Software Package Editor.

¶ Using the wsetspop, wsetspgs, and wsetspat commands fromthe command line (excluding the Package Type and VersioningType properties).

¶ Exporting a software package to the software package definitionfile format, modifying the properties, and re-importing the fileback to the software package format.

To view the properties of the Appsample software package profilefrom the Tivoli desktop, perform the following steps:


290 Version 4.1

1. Right-click the Appsample^1.0 software package profile icon inthe Profile Manager dialog, then select Properties. The SoftwarePackage Properties dialog is displayed from which you can viewthe properties set for the software package.

2. Click Launch Software Package Editor to display the SoftwarePackage Editor. From the editor, you can do the following:

¶ View the contents of a software package

¶ Create a software package from scratch

¶ Edit software packages that are not in the not-built format

For information about editing software packages that are in thebuilt format and the options that are available when the SoftwarePackage Editor is launched from the Software Package Propertiesdialog, see “Launching the Software Package Editor on ManagedNodes” on page 55.

3. To view information on software packages nested in theAppsample^1.0 software package, click Nested SoftwarePackages. See “Distributing Nested Software Packages” onpage 327 for more information about distributing softwarepackages that contain nested packages.

Software Package Properties


10.T

he

Distrib

utio

nP

rocess

4. Click Advanced to display the Advanced Properties dialog.

The properties displayed in the Software Package Properties andAdvanced Properties dialogs are explained in “Setting SoftwarePackage-level Properties” on page 122.

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, perform the following steps:

1. Right-click the software package profile from the ProfileManager dialog, and select Calculate Size from the pop-up

Software Package Properties

292 Version 4.1

menu. The Calculate Software Package Size dialog is displayed.

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, it displays the lastrecorded calculation.

2. Click Calculate Size to recalculate the size of the currentlyselected software package (in bytes). Note that if a packagecontains only actions, that is, the package is in the not-builtformat, its size is calculated as zero.

When calculating the size of nested software packages, the size iscalculated as the sum of the size of the primary package plus thesize of the nested packages. The size can be calculated successfullyonly if the primary package and nested packages have been importedinto the Tivoli environment and cataloged 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. You can use thisoperation to convert only software package objects that already existin the object database. In other words, the software package objectsmust have been imported into the Tivoli environment.

Calculating the Size of a Software Package


10.T

he

Distrib

utio

nP

rocess

Note: The size of a software package block cannot exceed 2 GB.You can exceed this limit by nesting software packages. Eachsegment or package cannot exceed 2 GB.

A software package 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 is in a zippedfile format and bundles the actions with the resources. All theresources must be located on the selected source host, otherwise, theoperation fails.

Not-built to BuiltTo convert the Appsample software package (not-built) to a softwarepackage block (built), perform the following steps:

1. Right-click the Appsample^1.0 software package in the ProfileManager dialog, then select Convert from the pop-up menu. TheConvert Software Package dialog is displayed.

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 the Overwrite check box to overwrite the softwarepackage block if it already exists on the source host. This optionis valid only if the target format is a software package block.

4. Click Convert & Close to convert the software package into asoftware package block on the source host.

Converting a Software Package

294 Version 4.1

Built to Not-builtTo convert the Appsample software package block (built) to asoftware package (non-built), perform the following steps:

1. Right-click the software package block and select Convert. Thesoftware package block is stored on the source host defined atthe time of import and the Convert Software Package dialog isdisplayed.

2. Select the Unbuild check box if you want to save the contents ofthe software package to a staging directory.

3. If you selected the Unbuild check box, click Unbuild Directoryand navigate to the directory where you want to store thecontents of the software package when it is unbuilt.

4. Click Convert & Close. The software package is converted to anon-built format. If you selected the Unbuild check box, thecontents are saved to the Unbuild Directory and the source pathsin the software package are updated so that they point to theUnbuild Directory. Otherwise, the software package block isconverted to a software package and the source paths remainunchanged.

Exporting a Software PackageThe Export dialog enables you to export a software package objectinto text file format. This text file is the software package definitionfile. It consists of a sequence of stanzas, each of which describes anaction to be executed. Using a text editor, you can view the .spd file,modify it, and use the Import function to import the revised .spd file

Converting a Software Package


10.T

he

Distrib

utio

nP

rocess

into a software package or software package block. Refer to theTivoli Software Distribution Reference Manual for more informationabout the .spd file format.

To export a software package object to the .spd format and thenreimport it, perform the following steps.

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 is to 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 .spdfile.

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.

7. Follow the instructions in “Importing a Software Package intothe Tivoli Environment” on page 285 to import the .spd file toeither a built or not-built software package.

Exporting a Software Package

296 Version 4.1

Change Management OperationsThis section describes the following change management operationsthat you can perform on software package objects. These optionsfully automate the distributing and installing of software, and are asfollows:

¶ Install

¶ Remove

¶ Undo

¶ Accept

¶ Commit

¶ Verify

For more information about the operations and dialogs described inthis section, refer to the corresponding Tivoli Software Distributionserver command, which can be run from the command line of theserver, in the Tivoli Software Distribution Reference Manual.

Software Package StatesEach of the change management operations is performed in threesteps:

Check Test that the operation can be performed to reduce the riskof failure during the execution phase.

ExecutePerform the operation only if the check is successful.

CleanupResources acquired during the execute phase are deleted.

Depending on the state of a software package, not all operations canbe performed on it. The operational state of a software package canbe determined in the following ways:

¶ Open the Tivoli Software Distribution log file located in the pathspecified in the software package properties log path.

Change Management Operations


10.T

he

Distrib

utio

nP

rocess

¶ Install the disconnected command line on the endpoint and runthe wdlssp command.

¶ Install Tivoli Inventory and the Tivoli Software DistributionHistorical Database component and run theCM_STATUS_QUERY.

The change management state of a software package is displayed asa five-character state string in the log file. For example, a softwarepackage with the IC- - - state is a package that has been installedand committed. Refer to the Tivoli Software Distribution ReferenceManual for more detailed information about software package states.

The state of a software package is determined by the following:

¶ The nature of the last operation performed (install or remove).

¶ The state of the last operation performed (prepared orcommitted).

¶ The state of the backup package (undoable state).

¶ Whether a reboot is required to complete the operation.

¶ An additional flag that indicates an error condition or that thestatus is in the process of being changed.

Executing Change Management OperationsTo display the change management operations that can be performedon the software package, right-click the Appsample^1.0 software


298 Version 4.1

package in the Profile Manager dialog to display a pop-up menu.

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



10.T

he

Distrib

utio

nP

rocess

1. Select Install from the Appsample^1.0 software package pop-upmenu to display the Install Software Package dialog.

2. To upgrade an installed package, using byte-level differencing,select the Delta Install check box and type the name andversion of the package to be upgraded in the Base Package textbox. Tivoli Software Distribution uses the files contained in thedelta package to reconstruct each version file starting from thebase file already installed on the target and applying to it thecorresponding delta file contained in the delta package. If anyof the installed files to be reconstructed are not found on thetarget, or have been modified, or are read-only the delta


300 Version 4.1

installation fails. To apply the delta installation the base and theversion packages must have the same nested structure.Byte-level differencing uses dependency checking to verify ifthe base package has been installed on the target. The basepackage must be in the IC or ICU state. If you clear theDependency check box, no checks are done on the basepackage. For a detailed explanation of how byte-leveldifferencing works, refer to the Tivoli Software DistributionReference Manual.

If you perform a delta installation, you cannot install thesoftware package in source or repair mode.

3. In the Label text box, specify the name of the softwarepackage, for example, Appsample^1.0. The default is thesoftware package name, but you can specify any text in this textbox.

4. Specify the order in which distributions are handled byrepeaters in the Priority Level group box. The default value isMedium.

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

RepairInstalls the following:

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

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



10.T

he

Distrib

utio

nP

rocess

The software package is re-built containing only theobjects needed to perform the repair and, therefore, issmaller than the original software package, and isinstalled on the target. The repair option applies only tosoftware packages 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)

Note: The repair option also supports software packageblocks, but not when the From Depot check boxis selected. See step 8 on page 303 forinformation about the From Depot option.

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

6. 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. If the package isversionable, the version checks are made on the targeteven when this option is selected. If the version checksfail, the installation fails. Refer to the Tivoli SoftwareDistribution Reference Manual for more informationabout software package version checking.

IgnoreProceeds with the operation only on target systems thathave been successfully checked. If not specified, theoperation does not proceed if the operation is not


302 Version 4.1

consistent with the software package. For example, ifyou are performing an install operation and the softwarepackage is already installed, the operation does notproceed. (Tivoli Inventory must be 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. This attributecan be used in conjunction with the repair or sourceoptions. A check is performed on the target and the listof files to be repaired or a list of source files that havebeen modified is returned to the log file.

7. Deselect the Disposable check box to keep the data associatedwith a distribution (depot segment) at the repeater after alltarget systems have received the distribution. Select theDisposable check box to remove the data associated with adistribution from the repeater once the distribution has finished(either all endpoints have completed or the distribution hasexceeded its life span). Repeater depots that have beenconfigured to accept permanent distributions will remove thedistribution if the Disposable options is selected. For moreinformation about configuring repeater depots to acceptpermanent distributions, see “Setting Repeater Parameters” onpage 264.

Note: If the object of the distribution is a software package inthe not-built format and not a software package block,this option is disabled and the data is deleted after thesoftware package is distributed and not stored on thedepot.

8. 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 258 for more information about depots. This option doesnot apply to software packages in the not-built format.



10.T

he

Distrib

utio

nP

rocess

Note: If you select this check box, you cannot select either theFrom the Fileserver or the From CD check box.

9. Select the From Fileserver check box to specify that thesoftware package to be installed is to be retrieved from a fileserver rather than on the source host. File servers must beconfigured if this option is used. This option does not apply tosoftware packages in the not-built format.

10. Select the From CD check box to specify that the softwarepackage to be installed is to be retrieved from a CD rather thanon the source host. This option does not apply to softwarepackages in the not-built format.

11. To move a subscriber to the Install Software Package On list,select one or more subscribers from the Available Subscriberslist, then click the left arrow. By default, all subscribers in theprofile manager are displayed in the Available Subscribers list.

To remove a subscriber, select one or more subscribers from theInstall 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.

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


304 Version 4.1

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.

13. Select the Dependency check box to apply any software andhardware dependencies defined for the software package.

14. Click Schedule to schedule operations at a future time. See“Creating and Executing Activity Plans with Activity Planner”on page 407 for information about a scheduling facility that

enables you to manage a group of operations as a singleoperation from a single machine in the network. Tivoli Software



10.T

he

Distrib

utio

nP

rocess

Distribution displays the Add Scheduled Job dialog.

The Add Scheduled Job dialog can be used to schedule jobs forthe following operations:

¶ Install

¶ Remove

¶ Accept

¶ Commit


306 Version 4.1

¶ 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 timeare retried. Any ongoing distributions, or distributions that havebeen cancelled are not resubmitted.



10.T

he

Distrib

utio

nP

rocess

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 “DefaultVariables” on page 312 for more information about setting thelifetime 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.

15. To replace all values in this dialog with the default values forthis operation click Reset.

16. From the Advanced Options pull-down menu, select the optionsyou require. The following options are available:

¶ Install Operation Modes (See “Install Operation Modes” onpage 309)

¶ Default Variables (See “Default Variables” on page 312)

¶ Distribution Settings (See “Distribution Settings” onpage 313)

¶ Mobile Settings (See “Mobile Settings” on page 315)


308 Version 4.1

17. When you have finished setting options from the AdvancedOptions menu, install the software package to the selectedsubscribers by clicking Install & Close. The dialog is notdismissed until the operation has been submitted. You can viewthe status of the distribution using the Distribution StatusConsole or from the command line using the wmdist command.Refer to the Tivoli Management Framework User’s Guide formore detailed information.

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



10.T

he

Distrib

utio

nP

rocess

No Not-transactional: This option does not provide thecapability of returning the system to its initial state if theoperation fails unless you have also selected the Yesoption in the Undoable Options group box. If disk spaceis consumed before the distribution has completed, thedistribution fails and some files are left on the targetsystem. Use this option only if you are sure theoperation will complete successfully.

Yes Transactional: The execution of the operation is split intotwo phases: the preparation phase and the commit phase.During the preparation phase, each action in the packageprepares the conditions for the successful execution ofthe requested operation, which reduces the risk of failureduring the commit phase. If the preparation phasecompletes normally, in the case of an install, the files areinstalled in the staging area. At this point the commitphase begins, where the updates take effect, that is, filesare moved from the staging area to the production area.If the preparation phase fails, the system is returned toits original state. For example, this option is useful ifthere are locked files or if there is not enough diskspace. It avoids interrupting a distribution in mid-streamand leaving partial distributions (files) on the targetsystem.

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. For example,it is useful to perform an operation with this two phase(preparation and commit phase) approach when resourcesare locked or not available in the preparation phase butthen become available in the commit phase.

¶ Undoable Options

No Not-undoable: A backup package is not created andtherefore the undo of an operation is not possible.


310 Version 4.1

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. Use this optionto execute a backup copy during the commit phase.

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

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 system



10.T

he

Distrib

utio

nP

rocess

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

Default VariablesUsing this dialog, you can temporarily override the value of defaultvariables formerly defined either in the Software Package Editor orin a Software Package Definition (SPD) file for a specificdistribution. See “Creating a Software Package” on page 53 for moreinformation about setting variables from the Software PackageEditor.

Refer to the Tivoli Software Distribution Reference Manual for a listand description of Tivoli Software Distribution built-in variables.

You open this dialog by selecting Default Variables from theAdvanced Options pull-down menu in the Install Software Package


312 Version 4.1

dialog.

1. To change the value of a variable, type the name of the defaultvariable for which you want to change the value in the VariableName text box. In the Variable Value text box, type the newvalue to be assigned to the variable.

2. Using the Default Variables List group box, you can also addor remove variables to be used during the execution of anoperation.

3. Click Set to save the variables you specified, or click Set &Close to save the variables and return to the Install SoftwarePackage dialog.

Distribution SettingsUsing this dialog, you can define rules for dealing withnon-availability of targets. These rules include server-level andclient-level timeout parameters that enable you to specify a timeinterval after which either the server or client interrupts adistribution. Setting timeout parameters can avoid suspendeddistributions.



10.T

he

Distrib

utio

nP

rocess

You open this dialog by selecting Distribution Settings from theAdvanced Options pull-down menu in the Install Software Packagedialog.

1. Select the Wake on Lan EP check box if the distribution is toautomatically trigger a reboot on targets that are not available atdistribution time.

2. Select the Roaming EP check box if the distribution is to betransferred from the gateway where it is queued to the gatewaywhere a mobile endpoint, which is a target to the distribution,has connected.

If you clear this check box, the distribution remains queued atthe original gateway until the mobile endpoint connects to itagain or the distribution times out.

3. Type the date and time on which the distribution expires. Thedistribution fails for any targets that have not received thedistribution before the specified date and time.

4. Specify a Notification Interval. The default is 1800 seconds (30minutes).


314 Version 4.1

This controls the interval with which each repeater bundles upthe completed results and returns them to the application anddistribution manager.

The value specified here overrides the value previously set usingthe wmdist -s command. See “Setting Repeater Parameters” onpage 264 for more information.

5. Specify a Send Timeout period. The default is 300 seconds (fiveminutes).

Send Timeout refers to the length of time a repeater will wait fora target to receive a block of data. This timeout is used to detectnetwork or endpoint failures. The value specified here overridesthe value previously set using the wmdist -s command.

6. Specify a Execution Timeout period. The default is 300 seconds(five minutes).

Execution Timeout refers to the length of time a repeater willwait for Tivoli Software Distribution to return the result of adistribution after all the data has been sent. This timeout is usedto detect network, endpoint, or script failures, for example, ascript that is running in an infinite loop. The value specified hereoverrides the value previously set using the wmdist -s command.

7. Click Set to save the settings you specified, or click Set & Closeto save the settings and return to the Install Software Packagedialog.

Mobile SettingsUsing this dialog, you can define rules for distributing softwarepackages to mobile targets. Using the mobile settings you can do thefollowing:

¶ Determine whether mobile users can defer accepting a softwarepackage and for how long.

¶ Determine whether to reject a software package.

¶ Specify a date by which the distribution must be completed orfail.

¶ Define a sequence of messages to be sent on specified dates toalert the mobile users to the presence of the software package.



10.T

he

Distrib

utio

nP

rocess

You open this dialog by selecting Mobile Settings from theAdvanced Options pull-down menu in the Install Software Packagedialog.

1. Select the Enabled Disconnected Install check box to allowinstallation of the package in disconnected mode. Selecting thisoption enables the mobile endpoint to download the softwarepackages to the local depot and execute the Software Distributionoperation later. If you do not select the option, you must applysoftware packages when you download them.


316 Version 4.1

2. In the Distribution Note text box, type text to be sent with thedistribution, or use one of the following options to importpredefined text:

¶ Click Add note from file to navigate to a file where apre-defined message is stored.

¶ Click Add note from SPO to use the software packagedescription in the distribution note.

3. Select a Distribution Mode.

OptionalIf you select this mode, the mobile user has the option todefer or reject the installation indefinitely.

MandatoryIf you select this mode, you must specify a Mandatory dateby which the installation must be performed. The mobile usercan defer installation up to this date.

HiddenIf you select this mode, the mobile user is not given theoption of deferring the installation. The installation isperformed as soon as the user connects to a gateway.

4. If you selected Mandatory mode, you must specify a date andtime by which the installation must be performed. You can alsochoose to clear the Force check box. The force option has thefollowing effect:

SelectedThe mandatory installation is automatically started as soon asthe mobile user connects and if the mandatory date isreached. This is the default.

ClearedThe mobile user has the choice of not starting the mandatoryinstallation. However, the user will not be able to performany other operations until the mandatory installation has beenperformed.



10.T

he

Distrib

utio

nP

rocess

5. Unless you selected the Hidden distribution mode, you canspecify an escalate date and time, when a message is to be sentto mobile users alerting them that there an outstandinginstallation to perform.

If you specify a date, you must also provide a correspondingmessage. You can type the message in the text box, or click Addfrom file to navigate to a file where a predefined message isstored.

You can define up to ten escalate dates and messages.

6. Click Set to save the settings you specified, or click Set & Closeto save the settings and return to the Install Software Packagedialog.

To perform an install operation from the command line, see thewinstsp command in the Tivoli Software Distribution ReferenceManual.

Remove OperationThe 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 Operation” on page 320). 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.


318 Version 4.1

Select Remove from the Appsample^1.0 software package pop-upmenu to display the Remove Software Package dialog.

See “Install Operation” on page 299 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



10.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 309 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.

To perform a remove operation from the command line, see thewremovsp command in the Tivoli Software Distribution ReferenceManual.

Undo OperationThe 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 system


320 Version 4.1

information (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 priorinstallations. 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 Operation” on page 299 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



10.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 309 for definitions of theseoptions.

To perform an undo operation from the command line, see thewundosp command in the Tivoli Software Distribution ReferenceManual.

Accept OperationThe 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.


322 Version 4.1

Select Accept from the Appsample^1.0 software package pop-upmenu to display the Accept Software Package dialog.

See “Install Operation” on page 299 for an explanation of thecontents of the Accept Software Package dialog.

To perform an accept operation from the command line, see thewaccptsp command in the Tivoli Software Distribution ReferenceManual.

Commit OperationThe commit operation causes all the updates established in thepreparation phase to take effect.



10.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 Operation” on page 299 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


324 Version 4.1

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.

To perform a commit operation from the command line, see thewcmmtsp command in the Tivoli Software Distribution ReferenceManual.



10.T

he

Distrib

utio

nP

rocess

Verify OperationThe verify operation verifies the consistency of an installed softwarepackage and the objects on the target system. A verify operationchecks 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 Operation” on page 299 for an explanation of thecontents of the Verify Software Package dialog.

To perform a verify operation from the command line, see thewversp command in the Tivoli Software Distribution ReferenceManual.


326 Version 4.1

Distributing Nested Software PackagesThe distribution behavior of a software package containing nestedsoftware packages varies depending on the following factors:

¶ 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,

Distributing Nested Software Packages


10.T

he

Distrib

utio

nP

rocess

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.

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 297. See “NestedPackages” on page 141 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 been


328 Version 4.1

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

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



10.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)


330 Version 4.1

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.



10.T

he

Distrib

utio

nP

rocess

332 Version 4.1

Tivoli Software Distribution WebInterface

The Web Interface provided with Tivoli Software Distribution,Version 4.1 is in the following forms, both of which supportendpoints with UNIX and Windows supported platforms:

¶ Basic functions

¶ Enhanced functions

Note: In this chapter, references to a software package, imply asoftware package block (built format).

When you install the Tivoli Software Distribution Server, Version 4.1component, you can use the basic functions of the Tivoli SoftwareDistribution Web Interface, that is, download and install of softwarepackages. When you additionally install the Tivoli SoftwareDistribution Web User Interface Server, Version 4.1 component andthe Tivoli Software Distribution Web Interface Depot, Version 4.1,the following enhanced functions are available to you:

¶ Download

¶ Install

¶ Uninstall

¶ Subscribe to software packages

¶ Unsubscribe software packages

11


11.Tivo

liW

ebIn

terface

¶ Verify software packages

¶ Subscribe to reference models

¶ Unsubscribe reference models

¶ Synchronize reference models to endpoints

¶ Manage locally installed software packages

It is strongly recommended that you use the enhanced functions. Todo that, go directly to the section called “Enhanced Tivoli SoftwareDistribution Web Interface Functions” on page 353. See “Planningand Installing Tivoli Software Distribution” on page 23 for moreinformation about installing the enhanced Tivoli SoftwareDistribution Web User Interface components.

Basic Tivoli Software Distribution Web InterfaceFunctions

The basic functions of Tivoli Software Distribution Web Interfaceenables endpoints to do the following:

¶ Selectively install new software applications and data, or updateexisting software.

¶ Download software packages that were not received at a priordistribution time.

With Tivoli Software Distribution Web Interface, Web users connectto the server, obtain a current list of available Tivoli SoftwareDistribution software package profiles, and retrieve necessarysoftware packages at their convenience.

Web users can install software package blocks using any of thefollowing industry standard Java-enabled Internet browsers:

¶ Netscape Navigator

¶ Microsoft Internet Explorer

Note: Ensure that the Java and Java Script options are enabled inyour browser.

Packages can be marked for public access or they can be made

Tivoli Software Distribution Web Interface

334 Version 4.1

visible to all target computers in a subscribing profile manager. Webusers are able to access packages after authentication according totheir Tivoli role. Packages marked for public access can be accessedwithout authentication. In both cases, Web users are given access toa Web page displaying the available packages. Web users can installthese packages by clicking them, which activates a Java applet.

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. Using the enhanced Web Interface changemanagement status is reported immediately.

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. This information isthen displayed on the client browser. For more information about theHTTPd and network communications, refer to the TivoliManagement Framework Planning for Deployment Guide.

Enabling Basic Tivoli Software Distribution WebInterface Functions

Enabling the basic Tivoli Software Distribution Web Interfacefunctions on an endpoint involves 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 Distribution

Tivoli Software Distribution Web Interface


11.Tivo

liW

ebIn

terface

enables this support when you install Tivoli SoftwareDistribution server on the Tivoli management server (Tivoliserver).

¶ 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 Tivoliserver 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 SD_Web_User role. Enabling access privileges allowsWeb users to securely connect to the Tivoli server and downloadTivoli Software Distribution software package profiles.

After you have installed the Tivoli Software Distribution server, youcan use either the Tivoli desktop or the command line to create theTivoli 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 toauthorized 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 Framework

Activating Tivoli Software Distribution Web Interface

336 Version 4.1

User’s Guide for more information about creating and using Tivoliadministrators in your Tivoli management region 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.

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.

Creating a Tivoli Administrator for Web Interface


11.Tivo

liW

ebIn

terface

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

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.


338 Version 4.1

4. Set the resource role for the administrator that you created instep 1 on page 337:

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.

Note: In the case of interconnected Tivoli management regions, thesystem administrator has full control over what Web users ofone region are permitted to see in the other region. Forexample, Web users on Region-A can see the public resourcesof interconnected Region-B if the administrator of Region-A,with login nobody@hostname (or tmersrvd@hostname), hasbeen assigned the Resource role of SD_Web_User for thosepolicy regions of Region-B that are to be made visible to Webusers of Region-A and vice versa.

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



11.Tivo

liW

ebIn

terface

where:

–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 that are displayed as software categories in the TivoliSoftware Distribution Web Interface. The administrator has controlover the content of the Tivoli Software Distribution Web Interfacedisplay. It is recommended that you keep the Tivoli ManagementFramework environment separate from the Tivoli SoftwareDistribution Web Interface environment by using different policyregions for each environment.


340 Version 4.1

The displayed list is empty until an action is enforced on the policyregions. See “Setting the Policy Region Attribute” on page 343.

Policy regions can be the following types:

Public No authentication is required to view the content of theseregions, although the administrator does need to add theSD_Web_User TMR role to the nobody user login name.

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 135 formore information about setting the Web view mode from thePackage Properties dialog.



11.Tivo

liW

ebIn

terface

Notes:

1. Only software packages in the built format can be made availablethrough the Tivoli Software Distribution Web Interface.

2. Software packages that contain nested software packages cannotbe made available through the Tivoli Software Distribution WebInterface.

Configuring Tivoli Software Distribution Web InterfaceThe 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 343

¶ “Setting the Software Package Object Attribute” on page 344

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. The default valueis Hidden. It is recommended that you initially leave the accesslevel to Hidden while you verify whether the package is builtsuccessfully. When the package has been built, set the level toSubscriber or Public accordingly.


342 Version 4.1

A login ID and password must be associated with the Tivoliserver and policy regions involved if the access level is set toRestricted.

Setting the Policy Region AttributeUse the wwebrset command to set the policy region access typeattribute. The following table provides the authorization rolesrequired to perform this task:


Set the policy regionaccess type attribute

Policy region senior

To 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:

Configuring Tivoli Software Distribution Web Interface


11.Tivo

liW

ebIn

terface

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 AttributeUse the wsetspat command to set the software package objectattribute. The following table provides the authorization rolesrequired to perform this task:


Set the softwarepackage objectattribute

Software packageprofile

senior

To use the wsetspat command to set the software package objectattribute, enter the following command.wsetspat -v web_view_mode @spname

where:

-v web_view_modeSpecifies 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)

The web_view_mode attribute can also be set using defaultpolicy methods. Refer to the Tivoli Software DistributionReference Manual for more information about default policymethods.

spnameIs the name of the software package for which you want toset the software package object attribute.


344 Version 4.1

To retrieve the value of the web_view_mode attribute, use thewgetspat -v @spname command. See the Tivoli SoftwareDistribution Reference Manual for the command syntax andarguments of the wsetspat and wgetspat commands.

You can customize the web_view_mode attribute using the defaultpolicy methods explained in the Tivoli Software DistributionReference Manual.

Using the Basic Tivoli Software Distribution WebInterface

After you have created the administrator for Tivoli SoftwareDistribution Web Interface, authorized (or public) Web users canview and download new or updated Tivoli Software Distributionprofiles. Each time new software package profiles are available toWeb users, you must instruct them to connect to Tivoli SoftwareDistribution Web Interface.

Web users connect to the Tivoli Software Distribution Web Interfaceby opening the X:\etc\Tivoli\en_US\userlink.htm file with a Webbrowser to display the primary UserLink for Tivoli access page.



11.Tivo

liW

ebIn

terface

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 “Enabling LanguageSupport” on page 51 for a current listing of supportedlanguages for this release.

Click UserLink for Tivoli to load information for all UserLinkinterfaces to Tivoli applications that are installed on the clientsystem.

Using Tivoli Software Distribution Web Interface

346 Version 4.1

Tivoli Software Distribution Web Interface is available by clickingeither the Public Software Distribution Web Interface or RestrictedSoftware Distribution Basic Interface link. Clicking one of theselinks loads the Tivoli Software Distribution Web Interface.



11.Tivo

liW

ebIn

terface

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 install anyof 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.


348 Version 4.1

If you have not already bookmarked the Tivoli SoftwareDistribution Web Interface Web page, create a bookmark so thatyou can easily and directly access it.

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 Web Interface Web page isdisplayed if Tivoli Software Distribution Web Interfacesuccessfully connects to the network.

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.



11.Tivo

liW

ebIn

terface

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


350 Version 4.1

to download. This corresponds to the text entered in theTitle text box illustrated on page 125.

An icon is displayed to the left of the software package name.The icon can be either of the following:

¶ An icon with a red slash mark indicates that the 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.

To download the selected software package, click Install.



11.Tivo

liW

ebIn

terface

The Tivoli Software Distribution Web Interface browser displaysthe Install Java applet and proceeds with the download andinstallation of the selected package.

The Install Java applet dialog displays the ongoing status of theinstallation, then indicates whether the installation completessuccessfully.


352 Version 4.1

Enhanced Tivoli Software Distribution Web InterfaceFunctions

When you install the Tivoli Software Distribution Web Interface,Version 4.1 on the Tivoli server, the enhanced Web Interfacefunctions are enabled. This interface enables endpoints to do thefollowing:

¶ List all software packages available and selectively downloadnew software applications and data, or update existing software.

¶ Download software packages that were not received at a priordistribution time.

¶ Install, uninstall, and verify software packages.

¶ If you install the Tivoli Software Distribution Server WEB UserInterface Depot Component, you can choose the depot closest tothe endpoint’s location to minimize download time.

¶ Receive notifications when software updates are available.

¶ View locally installed software packages.

¶ Manage locally installed software packages using verify anduninstall options.

¶ Select a reference model and install software and data tosynchronize the endpoint with the configuration defined in theselected model.

¶ Subscribe to models and receive notices when updates areavailable.

¶ Immediate update of change management status on the Tivoliserver.

Web users can access the Web Interface using any of the followingindustry standard Java-enabled Internet browsers:

¶ Microsoft Internet Explorer, Version 4.x

¶ Microsoft Internet Explorer, Version 5.x

¶ Netscape Navigator, Version 4.6 or later

Enhanced Web Interface Functions


11.Tivo

liW

ebIn

terface

Note: Ensure that the Java and Java Script options are enabled inyour browser.

Web users are given access to a Web page containing a hierarchicallist of software categories that correspond to profile managers.Selecting a profile manager (category) displays a list of availablesoftware packages. Packages can be marked for public access or theycan be made visible to only target computers subscribed to theprofile manager. Web users are able to access packages afterauthentication according to their Tivoli role. Packages marked forpublic access can be accessed without authentication.

The installation takes place in a connected or disconnected mode anddata is transferred through the available HTTP connection. Inconnected mode, the Tivoli server is immediately updated with thechange management status. In disconnected mode, the changemanagement status is reported to the Tivoli server on the nextsuccessive connection to the Web interface or at the next TivoliSoftware Distribution operation on the target computer, as for otherdisconnected operations.

With the enhanced Tivoli Software Distribution Web Interface, thelist of software categories and associated software packages isgenerated by a Java servlet. The browser communicates directly withthe Tivoli server oserv, which forwards the request to the ApacheHTTPd Web server. The Apache Web server accepts requests frombrowsers like Netscape and Internet Explorer and then generatesdynamic HTML pages and displays the information in the clientbrowser.

You can use the enhanced Tivoli Software Distribution Web Interfacenot only to install, uninstall, verify, and subscribe to softwarepackages, but also to manage locally installed software packages.Even when no connection is available, with a web browser, you canopen the disconmain.htm file located in the LCF directory on thelocal machine, and perform any of the following operations:

¶ List software packages installed locally.

¶ Manage the local software package blocks repository.

¶ Verify that installed software packages are in the correct state.


354 Version 4.1

Enabling Tivoli Software Distribution Web InterfaceThe following section outlines how an environment can beconfigured to enable Tivoli Software Distribution Web Interface onan endpoint.

¶ Install the Tivoli Software Distribution Server WEB UserInterface, Version 4.1 component on the Tivoli server and theTivoli Software Distribution Server WEB User Interface DepotComponent, Version 4.1 on managed nodes to exploit the depotselection capability, as explained in “Planning and InstallingTivoli Software Distribution” on page 23.

¶ With the installation of the Web Interface, the swd_apm_adminadministrator is automatically assigned the SD_Web_Server role.This administrator is automatically created when you install theActivity Planner, a prerequisite to the Web Interface. TheSD_Web_Server role enables the methods necessary to retrieveall the information needed to generate dynamic html pages andalso to enable access to the port and depot settings.

¶ Assign the SDhttpd_Control role to those users who should havethe authority to start and stop the Apache Web server and toperform commands that set the port and depot locations. Theroot administrator already has this role assigned.

¶ Create an administrator, for example, with the name WebUI, andset the logins to include nobody (for UNIX) or to tmersrvd (forWindows NT and HP-UX) to give users access to publicsoftware categories. Edit the TMR roles of the WebUIadministrator to include the SD_Web_User role. Edit theResource roles of the WebUI administrator to include theSD_Web_User role for the policy regions to be made public andthat contain software packages that should be made availablefrom the Web interface.

¶ Create an administrator, for example, with the nameWebUI-Restr1, and set the login name to an existing userrecognized by the operating system. Edit the TMR roles toinclude the SD_Web_User role and edit the Resource roles toinclude the SD_Web_User role to allow the user access to therestricted policy regions.



11.Tivo

liW

ebIn

terface

¶ Set the policy region attribute.

¶ Set the software package object attribute (web_view_mode) forsoftware packages.

¶ Define software category names by setting theSDWebUI_displayname attribute.

¶ Define the depot location information

The following table outlines the configuration of the Web Interfaceenvironment.

Administrator TMR Roles Resource Roles Login name

root SDhttpd_Control

swd_apm_admin SD_Web_Server tivapm

WebUI SD_Web_User SD_Web_User (Publicpolicy regions)

nobody or tmersrvd

WebUI-Restr1 SD_Web_User SD_Web_User (Restrictedpolicy regions)

userid

Creating the WebUI and WebUI-Restr1 AdministratorsThe procedure for creating administrator is explained in step 1 of thesection “Creating a Tivoli Administrator for Web Interface” onpage 336.

Assigning TMR Roles to the WebUI and WebUI-Restr1Administrators

Use the following steps to set the TMR roles for both the WebUIand WebUI-Restr1 administrators to include the SD_Web_User role.

1. From the Create Administrator dialog, click Set TMR Roles todisplay the Set TMR Roles dialog.

2. Double-click the SD_Web_User role in the Available Rolesscrolling list to automatically move it to the Current Rolesscrolling list.

3. Click Set & Close to accept the changes and return to the CreateAdministrator dialog.


356 Version 4.1

Assigning Resource Roles to the WebUI andWebUI-Restr1 Administrators

Use the following steps to set the Resource roles for both the WebUIand WebUI-Restr1 administrators to include the SD_Web_User role.

1. From the Create Administrator dialog, click Set Resource Rolesto display the Set Resource Roles dialog.

2. In the Resources list box, select the policy region containing thesoftware package to be made available from the Tivoli SoftwareDistribution Web Interface.

3. Select the SD_Web_User role from the Available Roles scrollinglist, then click the left arrow. This role is moved from theAvailable Roles scrolling list to the Current Roles scrolling list.

4. Click Set & Close to accept your changes and return to theCreate Administrator dialog.

Configuring Policy RegionsPolicy regions are containers for managed resources such as profilemanagers. The administrator defines profile managers in the policyregion and defines the policy region access type which determineshow the information is made available on the Web interface.

Policy regions can be the following types:

Public No access rights are required to view the content of 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.

The administrator must decide which policy regions are to be Publicor Restricted. The procedure for defining the policy region attributeis explained in “Setting the Policy Region Attribute” on page 343.



11.Tivo

liW

ebIn

terface

For each profile manager defined in a policy region, a correspondingsoftware category is displayed in the Web Interface. The TivoliSoftware Distribution Web Interface displays a hierarchical list ofsoftware categories that contain software packages that have beenmade available by the administrator. Software categories correspondto profile managers. The administrator can assign category namesdifferent from the profile manager name by setting theSDWebUI_displayname attribute. If this attribute is not set, the webinterface displays the profile manager name as the software categoryname. See “Defining Software Categories” on page 359 for moreinformation about setting and retrieving the software category name.

Software categories are displayed in a hierarchical structure. Theadministrator determines the hierarchical structure when definingprofile managers in the same policy region and the associatedsubscribers. Each profile manager appears as a root category in thehierarchical structure. Profile managers that have other profilemanagers defined as subscribers, appear as an expandable category.A small icon beside each software category name indicates whetherthe software category is expandable. A triangle-shaped icon marksexpandable software categories. Categories that do not contain othercategories are marked by a diamond-shaped icon. Click thetriangle-shaped icon to expand or collapse a category. Selecting acategory name displays a list of available software packages.

Software Package PropertiesTo define the access level for a software package, set theweb_view_mode attribute to one of the following values:

Public The software package can be installed on the endpointwhether or not the endpoint is a subscriber.

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.


358 Version 4.1

The procedure for defining the software package object attribute,web_view_mode, is explained in “Setting the Software PackageObject Attribute” on page 344.

Defining Software CategoriesThe name of the software category displayed in the tree is the profilemanager name defined by the administrator unless theSDWebUI_displayname attribute has been set. You set the softwarecategory name using the wwebprfset command.

The following table provides the authorization role required toperform this task:


Set theSDWebUI_displaynameattribute

Administrator resource senior

To use the wwebprfset command to assign a name to a softwarecategory other than the associated profile name, enter the followingcommand.wwebprfset profile_manager SDWebUI_displayname

where:

profile_managerThe name of the profile manager.

SDWebUI_displaynameThe software category name to be displayed. in the Webinterface.

To retrieve the value of the SDWebUI_displayname attribute, use thewwebprfget profile_manager command. The value of this attributeis displayed in the software category hierarchical structure if it hasbeen set.

The following table outlines the roles required to perform TivoliSoftware Distribution Web Interface tasks:



11.Tivo

liW

ebIn

terface

Task Context Role

Starting and stopping the Webserver

Administrator resource senior, super, orSDhttpd_Control

Retrieving and setting the portnumber

Retrieving and setting usersor groups of users

Retrieving and setting thedepot location

Creating administrators andadding users


Setting the policy regionattribute


Setting the web_view_modeattribute

Software package profile senior

Setting theSDWebUI_displaynameattribute


Managing the Web ServerOnly administrators that have been assigned the SDhttpd_Controlrole have the necessary authorization to manage the Apache Webserver. The administrator manages the Web server using thewsdhttpd command.

Refer to the Tivoli Software Distribution Reference Manual for moreinformation about the wsdhttpd command and syntax.

Using the Enhanced Tivoli Software Distribution WebInterface

After you have created the Web access administrator for TivoliSoftware Distribution Web Interface, authorized or public Web userscan view and download new or updated software packages andmodels to which they are subscribed. If a Web user has subscribed toa specific software package or model, each time an update becomesavailable, the Web user is automatically notified.


360 Version 4.1

Web users connect to the Tivoli Software Distribution Web Interfaceby opening the X:\etc\Tivoli\en_US\userlink.htm file with a Webbrowser 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 “Enabling LanguageSupport” on page 51 for a current listing of supportedlanguages for this release.

Click the UserLink for Tivoli link to load information for allUserLink interfaces to Tivoli applications that are installed on theclient system.



11.Tivo

liW

ebIn

terface

Note: If you have installed the enhanced Tivoli SoftwareDistribution Web Interface, Version 4.1, the basic WebInterface is not longer accessible from the UserLink for Tivolipage.

The enhanced Tivoli Software Distribution Web Interface is availableby clicking the Enhanced Tivoli Software Distribution Web Interface,Version 4.1 link.


362 Version 4.1

This page shows a Web user what updates of software packages andreference models, to which that user is subscribed, have becomeavailable since the user last connected to the Web Interface. Whenyou access this page for the first time, you are prompted for aconfirmation of the installation of the command line which enablesyou to perform disconnected commands.

The Web user can select either the Public or Restricted link from thenavigation bar to view a list of available software packages thatcorrespond to the Public or Restricted policy regions that theadministrator has configured. When a Web user selects the restrictedlink, the browser authenticates the login name and password, and ifsuccessful, queries the server and generates a list of both therestricted and public profile managers (software categories). If theWeb user selects the Public link, no authentication is performed and



11.Tivo

liW

ebIn

terface

a list of public software categories is displayed. The Web user canthen select one of the software categories to display the availablesoftware packages.

Using the Web InterfaceWith Tivoli Software Distribution Web Interface, Version 4.1, youcan perform several tasks that automate the management of softwareon a local machine, with or without a network connection. Throughthe Web Interface, you can do the following:

¶ Display a list of software categories containing softwarepackages

¶ Install, uninstall, download, or verify a software package

¶ Subscribe to specific software packages and be automaticallynotified when an update is made available

¶ View and manage locally installed software packages byverifying and removing them

Downloading, Installing, and Subscribing to SoftwarePackages

Instruct Web users to complete the following steps to connect to anduse Tivoli Software Distribution Web Interface to download andinstall software packages, and subscribe the local endpoint to futureupdates of the software packages:

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.

2. Create a bookmark for the Tivoli Software Distribution WebInterface Web page to gain ready access to it from now on.

3. Select the UserLink for Tivoli link to display the secondaryaccess page.

4. Select the Tivoli Software Distribution Version 4.1 WebInterface link to display the Web Interface. Each time the Webuser connects to the Web Interface, the Updates page isdisplayed that notifies the user of any updates to softwarepackages and models to which the Web user is subscribed, and


364 Version 4.1

has not yet installed. The Web user can access a list of updatesat any time by clicking the Updates link.

Notes:

a. When a new version of a software package becomesavailable it overwrites the old version. Installing a newversion overwrites the previous version if already installed.

b. When you subscribe to a reference model, it is onlydisplayed in the Updates page when a subsequent updateoccurs.

5. Select the appropriate navigation bar link to view the softwarepackages available to you, as follows:

¶ Public, if you want to view list of public softwarecategories.

¶ Restricted, if you want to view an authenticated list ofsoftware categories. This requires your user ID andpassword. If you are unsure about or need to verify youruser name and password, contact your system administrator.

6. From the expandable list of software categories listed in the leftpane of the Web page displayed, select the category yourequire. The right pane displays a list of available softwarepackages in the right pane for the selected category.



11.Tivo

liW

ebIn

terface

Icons to the left of the software package name in the tableindicate the following:

¶ With a red slash: software package not installed on yoursystem.

¶ With a green check mark: software package alreadyinstalled on your system.

7. Select the check boxes adjacent to the software packages youwant to install, and do one of the following:

¶ Click Save copy to download the software package to thelocal machine for installing it at a later time.

¶ Click Install & Save copy to do the download and installin one step.


366 Version 4.1

¶ To see details about a software package before installing it,click its name. The Software Package Details dialog, whichcontains this information, is displayed.

8. Click Install to proceed with the installation. The Depot Listdialog for the first-selected software package is displayed.

9. From the Depot List dialog, do one of the following:

¶ For the first-selected software package, click OK to confirmthe recommended depot selected.

¶ From the option buttons below, select your required depotand click OK.

The Web Interface prompts you to decide whether to use thesame selected depot for other software packages, if you haveselected them for installation.

10. To select a different depot, click No to display the Depot Listdialog and make the selection you require.

11. Click Subscribe to subscribe the local endpoint to the selectedsoftware packages. Each time the endpoint connects to theTivoli Software Distribution Web Interface, a check isperformed and you are automatically notified if a new versionof the same software package has been made available by the



11.Tivo

liW

ebIn

terface

Administrator. If you reload this page after subscribing to asoftware package, the software package no longer appears.Click the Subscribed link from the navigation bar to view thesoftware packages to which you are subscribed.

Note: When you subscribe to a software package, and a newversion becomes available, installing the new versionoverwrites the previous version.

12. To view the ongoing status of the operations selected, clickOperations Console. The Tivoli Software Distribution WebInterface browser displays the Pending Operations dialog whichdisplays a queue of the operations to be performed.

13. Click Start to begin executing the list of pending operations.The lower pane displays the downloading and installation statusof the selected software packages.

Note: If you are using Netscape Navigator, two Java Securitydialogs are displayed consecutively asking for approvalto grant extra privileges for using the Install Java appletto download and install the selected software package.Click Grant in both cases. The privileges persist until


368 Version 4.1

the browser is closed.

From the Pending Operations dialog, you can do the followingat any time:

¶ Stop the operation and resume it at a later time

¶ Change the order of execution of the pending operation

¶ Delete a pending operation

Uninstalling a Software PackageTo uninstall a software package (an installed software package isidentified by an icon with a green check mark) perform thefollowing steps from the Tivoli Software Distribution Web Interface:

1. Select the associated check box and click Uninstall.

2. To view the progress of the operation, click Operations Console.

Verifying an Installed Software PackageTo verify the consistency of a software package already installedlocally with the same package available on the Web Interface,perform the following steps from the Tivoli software DistributionWeb Interface:



11.Tivo

liW

ebIn

terface

1. Select the associated check box and click Verify.

2. To view the progress and outcome of the operation, clickOperations Console.

Accessing Reference ModelsFrom the Tivoli Software Distribution Web Interface, you cansubscribe endpoints to reference models, and synchronize theendpoint with defined reference models, as follows:

1. From the navigation bar, select Models. A list of availablereference models is displayed in the left pane. An icon againstthe model name shows whether the endpoint is currentlysubscribed to it.

Note: Each time you connect to the Tivoli Software DistributionWeb Interface, you are notified of any updates to modelsto which the endpoint is subscribed.

2. In the left pane, select the required reference model. A list ofrelated configuration elements is displayed in the right pane.


370 Version 4.1

3. Select Subscribe to subscribe to the selected reference model.Reloading the Models Web page removes the subscribed modelfrom the list of models. Select the Subscribed link from thenavigation bar to perform other operations on the subscribedmodel.

4. Select Synchronize to synchronize the local machine with thereference model definition. A check is performed on the softwareinstalled on the local machine and the Depot List dialog displaysthe operations required to synchronize the local machine with the



11.Tivo

liW

ebIn

terface

model definition.

5. Click OK to proceed with the synchronization.

For more information about change configuration models and how toconfigure Web subscribers, see “Change Configuration Management”on page 449.

Managing Subscriptions to Software Packages andReference Models

From the Tivoli Software Distribution Web Interface, you canmanage subscriptions to software packages and reference models asfollows:

1. From the navigation bar, select Subscription.


372 Version 4.1

The Web page displays an overview of all software packages andmodels to which you are subscribed.

2. Select the check boxes of the software packages and models youwant to unsubscribe from and for which you want to discontinuenotification of updates.

3. Click each Unsubscribe button, as necessary.

Managing the Local Machine from the Tivoli SoftwareDistribution Web Interface

In the local machine pages of the Tivoli Software Distribution WebInterface, you can perform software package management operationson the local endpoint, as follows:



11.Tivo

liW

ebIn

terface

1. From the navigation bar, select Local. A local Web page isdisplayed.

2. In the left pane, select the link for the operation you want:

¶ Installed Software Packages. The right pane enables you toreinstall, uninstall, and verify locally installed softwarepackages.

¶ Local Depot. The right pane lists software package blocksstored at the local depot, and enables you to perform install,uninstall, and verify operations.

¶ Verify. The right pane enables you to verify that softwareinstalled using Tivoli Software Distribution is in the correctstate.

The tasks that you can perform are outlined on each page.


374 Version 4.1

Integrating the Tivoli InventoryDatabase

Tivoli Inventory is able to scan the machines in your Tivolimanagement region and gather hardware and software informationthat it stores in a database called the configuration repository. TivoliSoftware Distribution provides two features that automatically updateinformation stored in the Tivoli Inventory configuration repository:

Historical databaseThis feature stores the following information:

¶ Distribution operations performed on target systems,including the type of operation, the mode, the time itoccurred, the result, and the distribution ID

¶ Software names and versions that have been distributed

Change management statusThis feature stores the following information

¶ Names and versions of software packages

¶ Time of the last successful operation

¶ Last known change management state of a softwarepackage on a target system

¶ Software packages loaded in depots

¶ Software packages and reference models to which usershave subscribed

12


12.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

These features store information about Tivoli Software Distribution,Version 4.0 and 4.1 software packages and Tivoli SoftwareDistribution Version 3.6.x file packages, AutoPacks, and file packageblocks (fpblocks) that have been installed on or removed from Tivoliclients.

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 Tivoli management region, and the changemanagement status of a particular software package on a specifictarget. These two features eliminate the need to write scripts toperiodically update the configuration repository when software isdistributed or removed in your Tivoli environment.

This chapter provides a brief conceptual overview of the TivoliManagement Framework query facility and the configurationrepository that Tivoli Software Distribution shares with TivoliInventory, Version 3.6.2. It also describes how to enable the TivoliSoftware Distribution historical database and change managementstatus features 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 new

376 Version 4.1

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

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 operation

The Configuration Repository


12.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

or 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, and the result of the operation. Anew column, MD2_DIST_ID, has been added to this tablewhich stores a distribution ID for each software packagedistribution.

SOFTWARE_COMPONENTStores information about software names and versions thathave been distributed, and links this information to profileidentifications.

SOFTWARE_FILEPACKStores information about software file package identificationand relates this information to a file package, AutoPack, orfile 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 asuccessful operation. Running the CM_STATUS_QUERYretrieves software package status information directly fromthe SD_CM_STATUS table and not through the use of apredefined view.

It is possible that the state registered in theSD_CM_STATUS table of a software package on aparticular target machine is not consistent with the statusrecorded in the local target catalog of the same software


378 Version 4.1

package. This inconsistency occurs when an operation isperformed using a disconnected command line command.Refer to the Tivoli Software Distribution Reference Manualfor more information about disconnected target commands.In this case, the endpoint returns an error to the serversignalling a discrepancy and updates the SD_CM_STATUStable with the correct state. The status is also updated afterthe next subsequent operation. Alternatively, you can use thewsyncsp command to synchronize the status on the serverfor software packages on specified endpoints with the actualstatus on the endpoints. Refer to the Tivoli SoftwareDistribution Reference Manual for more information aboutthe wsyncsp command.

SD_LOADED_COMPStores information about the depot, software packages loadedin the depot, base software packages loaded on the depot, theadministrator ID for the last load operation, and theexecution time for the last load operation.

The SD_LOADED_COMP table is updated each time a loador unload operation is performed. Running theSD_LOADED_COMPONENT_QUERY queries the databasefor depot information. You can use the wswsprim commandto enable/disable access to this table. For more informationabout wswsprim command usage and syntax, refer to theTivoli Software Distribution Reference Manual.

SWP_SUBSCRIPTIONSStores information about reference models to which WebInterface users are subscribed.

MOD_SUBSCRIPTIONSStores information about software packages to which WebInterface users are subscribed.

Information about the Tivoli Software Distribution view, query, andtables is provided in the Tivoli Inventory User’s Guide. TivoliInventory also provides the Tivoli Inventory ConfigurationRepository schematic poster, which illustrates table and columnassociations in the configuration repository.



12.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

Upgrading from Tivoli Inventory, Version 3.6.x orLater

Upgrading the Tivoli Inventory database from Version 3.6.x or later,after installing the Historical Database component, involves runningone of the scripts located in the $BINDIR/TME/SWDIS/SCRIPTS/directory. To select the required script for your environment,determine the following:

¶ What database are you using?

¶ Have you upgraded to Tivoli Software Distribution, Version 4.1using the patch?

¶ Have you performed a fresh install of Tivoli SoftwareDistribution, Version 4.1?

Attention: If you upgraded to Tivoli Software Distribution, Version4.1 using the patch, ensure that you use the correct script to avoidloss of data stored in the SD_CM_STATUS table.

Table 2. Tivoli Inventory Database Upgrade ScriptsDatabase Name Script Name for Upgrade to

Version 4.1Script Name for Fresh Install ofVersion 4.1

DB2 swdis_db2_upgr_41.sql swdis_db2_upgrade.sql

Microsoft SQLServer

swdis_ms_sql_upgr_41.sql swdis_ms_sql_upgrade.sql

Oracle swdis_ora_upgr_41.sql swdis_ora_upgrade.sql

Sybase swdis_syb_upgr_41.sql swdis_syb_upgrade.sql

Informix® swdis_infx_upgr_41.sql swdis_infx_upgrade.sql

Running these scripts adds a new text box called state to 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 the Tivoli Inventory Database

380 Version 4.1

Upgrading a DB2 DatabaseComplete the following steps to run the script that upgrades the DB2database:

1. Copy the script from the \scripts product directory to a temporarydirectory in which you can run DB2 on the DB2 server or theRDBMS 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:

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 script from the command line. Enter the followingcommand depending on your environment:

¶ Fresh install:db2 -f swdis_db2_upgrade.sql -o -t -z swdis_db2_upgrade.log

¶ Upgrade install:db2 -f swdis_db2_upgr_41.sql -o -t -z swdis_db2_upgrade.log

This command runs the script, directs the output to the screen,specifies a semicolon as the delimiter at the end of a statement,and logs the output in a log file named swdis_db2_upgrade.log.The success or failure of the SQL statements is logged in thisfile.



12.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

Upgrading a SQL Server DatabaseComplete the following steps to run the script that upgrades the SQLServer database. You must run the script as the RDBMS user tivoli.

1. Copy the script from the \scripts product directory to a temporarydirectory in which you can run isql on the RIM host or theRDBMS server.

2. From the directory that now contains the script, run the script asuser tivoli. Enter the following command, depending on yourenvironment, where password is the RDBMS password that is setfor the SQL Server user tivoli:

¶ Fresh install:isql -U tivoli [-P <password>] \-i swdis_ms_sql_upgrade.sql -o swdis_ms_sql_upgrade.log

¶ Upgrade install:isql -U tivoli [-P <password>] \-i swdis_ms_sql_upgr_41.sql -o swdis_ms_sql_upgrade.log

The output of the script (that is, the success or failure of theSQL statements) is logged to the swdis_ms_sql_upgrade.log file.

Upgrading an Oracle DatabaseComplete the following steps to run the script that updates theOracle database. You must run the script as the RDBMS user tivoli.

1. Copy the script from the \scripts product directory to a temporarydirectory on the RDBMS server or the RIM 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 script by entering the followingcommand depending on your environment:


382 Version 4.1

¶ Fresh install:@swdis_ora_upgrade.sql

¶ Upgrade install:@swdis_ora_upgr_41.sql

The success or failure of the SQL statements is logged in the 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 script that updates theSybase database. You must run the script as the RDBMS user tivoli.

1. Copy the script from the \scripts product directory to a temporarydirectory in which you can run isql on the RDBMS server or theRIM host.

2. From the directory that now contains the script, run the script asthe user tivoli. Enter the following command, depending on yourenvironment, where password is the RDBMS password that is setfor the Sybase user tivoli:

¶ Fresh install:isql -U tivoli -P <password> -i swdis_syb_upgrade.sql \-o swdis_syb_upgrade.log

¶ Upgrade install:isql -U tivoli -P <password> -i swdis_syb_upgr_41.sql \-o swdis_syb_upgrade.log

The output of running the script is stored in theswdis_syb_upgrade.log file.

Upgrading an Informix DatabaseComplete the following steps to run the swdis_infx_upgrade.sqlscript that updates the Informix database. You must run the script asthe RDBMS user tivoli.



12.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

1. Copy the script from the \scripts product directory to a temporarydirectory in which you can run dbaccess on the RIM host or theRDBMS server.

2. From the directory that now contains the script, run the script asthe user tivoli. Enter the following command, depending on yourenvironment, where, database_name is the name of the Inventoryconfiguration repository:

¶ Fresh install:dbaccess <database_name>@$INFORMIXSERVER swdis_infx_upgrade.sql

¶ Upgrade install:dbaccess <database_name>@$INFORMIXSERVER swdis_infx_upgr_41.sql

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. See“Planning and Installing Tivoli Software Distribution” on page 23 formore information about installing 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.


384 Version 4.1

Complete the following steps on target machines that will receivesoftware package, file package, AutoPack, and fpblock distributions,but have not been scanned:

1. Create an inventory profile. The Tivoli Inventory User’s Guidedescribes how to create an inventory profile.

2. Customize the inventory profile to include only a hardware scan.By default, an inventory profile scans the target machine for 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. If you do not need totrack distribution statistics, disable these features prior to distributinga software package. Re-enable the features to resume trackingdistribution information in the configuration repository.


Historical Database and Change Management Features


12.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

Operation Context Required Role

Disabling andre-enabling thehistorical database andchange managementstatus features

Command line senior or super

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.

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,

Historical Database and Change Management Features

386 Version 4.1

swdis_queries.sh, that you can run to automatically install a querylibrary and predefined queries. This script creates theSWDIST_QUERIES query library and populates it with thefollowing predefined queries: SWDISTDATA_QUERY,CM_STATUS_QUERY, SD_LOADED_COMPONENT_QUERY,SWDIST_WEBUI-QUERY.

Run the swdis_queries.sh script in the Tivoli management regionfrom which you want to query the configuration repository. Becausequeries and query libraries must have unique names in a Tivolimanagement region, you can have only one set of the TivoliSoftware Distribution queries in a Tivoli management region or in aset of interconnected Tivoli management regions. For informationabout creating additional query libraries and queries, refer to theTivoli Inventory User’s Guide.

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 to a temporarydirectory on the Tivoli management region server.

4. From the directory in which the script now resides, log in as aTivoli administrator.

Creating the SWDIST_QUERIES Query Library


12.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

5. Run the swdis_queries.sh script by entering the following. Sincethis is a bash script that must be run in the bash environment,precede the command with the string sh, as follows:sh swdis_queries.sh region name

where:

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

The new query library is added in the designated policy region asfollows:

Running a 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.

Creating the SWDIST_QUERIES Query Library

388 Version 4.1



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,SD_LOADED_COMPONENT_QUERY, SWDISTDATA_QUERY,and SWDIST_WEBUI_QUERY predefined queries, which alsoappear in these dialog examples, are similar.)

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 is displayed:

2. To run this query, right-click the SWDISTDATA_QUERY iconand select Run Query.

–OR–

Running SWDISTDATA_QUERY


12.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

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:

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.


390 Version 4.1

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.

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.



12.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

Modifying SWDISTDATA_QUERYAs illustrated in the Run Query dialog shown on page 390,SWDISTDATA_QUERY retrieves and posts an extensive list ofTivoli Software Distribution data that includes information 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 exampleof 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

392 Version 4.1

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.



12.In

tegratin

gth

eTivo

liIn

vento

ryD

atabase

5. In the Table/View Name text box, enter SWDISTDATA_VIEWand click Set. Doing this populates the Available Columns textbox.

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:


394 Version 4.1

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:



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


396 Version 4.1

Integrating the Tivoli EnterpriseConsole

Tivoli Software Distribution Tivoli Enterprise Console® Integrationenables Tivoli Software Distribution to send events to the TivoliEnterprise Console event server (event server) when a TivoliSoftware Distribution operation is performed. In the Tivolienvironment, an event is classified as any significant change in thestate of a system resource, network resource, or network application.After the Tivoli Enterprise Console integration product is installed,Tivoli Software Distribution automatically generates events based onits operations such as successful or failed distributions or changemanagement operations, and sends these events to the event server.This provides a means for centrally collecting Tivoli SoftwareDistribution events and triggering actions that can be handled thesame way as events from other sources or even be correlated withother events.

This chapter explains how to install and enable the Tivoli SoftwareDistribution Tivoli Enterprise Console Integration productcomponent. It also provides a description of the Tivoli SoftwareDistribution event configuration file and event classes. You must befamiliar with the Tivoli Enterprise Console application and itsmanuals, specifically the Tivoli Enterprise Console User’s Guide andthe Tivoli Enterprise Console Adapters Guide. These materialsprovide conceptual and instructional information about events, eventadapters, and classes.

13


13.In

tegratin

gth

eTivo

liE

nterp

riseC

on

sole

InstallationTo install and use the Tivoli Software Distribution Tivoli EnterpriseConsole Integration, Version 4.1 component, you must first haveTivoli Software Distribution, Version 4.1, and Versions 3.6.2 or laterof the Tivoli Enterprise Console, and the Tivoli Enterprise Consoleserver, installed in your Tivoli management region. If you areupgrading these products from a previous version, you also mustupgrade the RDBMS database installation. Installing a currentversion of Tivoli Enterprise Console without updating the databasemay lead to problems with viewing events in the Tivoli EnterpriseConsole event console (event console). Refer to the Tivoli EnterpriseConsole User’s Guide for more information about installing andusing the event server and console, and about upgrading the RDBMSdatabase.

Before installing and using Tivoli Software Distribution TivoliEnterprise Console Integration, you must create an event console onthe 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 Tivoli Enterprise Console Integration:

1. Follow the directions described in “Planning and Installing TivoliSoftware Distribution” on page 23 to install the Tivoli Software

Integrating the Tivoli Enterprise Console

398 Version 4.1

Distribution Tivoli Enterprise Console Integration, Version 4.1component on the event server in the Tivoli management region.

Installing the Tivoli Software Distribution Tivoli EnterpriseConsole Integration component copies the tecad_sdnew.baroc fileto the $BINDIR/TME/SWDIS/SPO directory on the hostmachine. The Tivoli Software Distribution event classes aredefined in this file. See “Tivoli Software Distribution Classes” onpage 405 for more information about Tivoli Software Distributionevent classes.

2. To set a rule base to manage events and to install the TivoliSoftware Distribution event classes to the event server, run theswdistecsrvr_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, that copies the default rule base in the specifieddirectory, 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.

Note: If you are using Tivoli Enterprise Console, Version 3.7 orlater, the following message is displayed before the scriptcompletes:Event group and filter for Software Distribution 4.1must be created manually.

Unlike previous versions, Version 3.7 or later requires thatyou create the event group and related filter manuallyfrom the Tivoli Enterprise Console. Refer to the Tivoli



13.In

tegratin

gth

eTivo

liE

nterp

riseC

on

sole

Enterprise Console User’s Guide for more informationabout creating event groups and filters.

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.1########################################################## 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 402.

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.1 event group is listedin the Assigned Event Groups scrolling list. To move thisevent group, select Software Distribution 4.1 from theUnassigned Event Groups list and click the right arrow.


400 Version 4.1

b. Highlight the Software Distribution 4.1 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.1 eventsource is displayed.

6. To view the event notices, click the Software Distribution 4.1event group button. The Software Distribution 4.1 window isdisplayed.



13.In

tegratin

gth

eTivo

liE

nterp

riseC

on

sole

The Software Distribution 4.1 window lists all Tivoli SoftwareDistribution 4.1 events in the scrolling list. These events aredescribed fully in “Tivoli Software Distribution Classes” onpage 405.

The tecad_sd.conf FileThe tecad_sd.conf configuration file for the Tivoli SoftwareDistribution Tivoli Enterprise Console Integration componentinitially has the following default entries:ServerLocation=ConnectionMode=connection_orientedServerPort=0

The keywords are as follows:

ServerLocationSpecifies the keyword @EventServer or a fully qualifiedidentifier if multiple event servers are running in aninterconnected Tivoli management region environment. Youmust set the value of this field after installing TivoliSoftware Distribution. To obtain the event server identifier,enter the following command from the command line:wlookup -ar EventServer


402 Version 4.1

The following is an example of the output of the command:EventServer 1723798822.2.28#Tec::Server#

The event server identifier in this example is: EventServer.

Refer to the Tivoli Management Framework 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.

ServerPortSpecifies the fixed reception port number on which theTivoli Enterprise Console server listens for connection andadapter input. This keyword value should be set to 0 (thedefault value) on UNIX systems unless the portmapper is notavailable on the server.

If the Tivoli Enterprise Console server is a Windows NTsystem, the ServerPort should be set to the value of thetec_recv_agent_port entry in the .tec_config file. Refer to theTivoli Enterprise Console Adapters Guide for moreinformation about the server port specification on WindowsNT machines. If the port number is not specified, the valueis retrieved by calling the portmapper.

ServerPort can contain up to eight values, separated bycommas. Specify one port number regardless of the numberof ServerLocation values specified; however, if you specify



13.In

tegratin

gth

eTivo

liE

nterp

riseC

on

sole

more 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 cannotcontain spaces. The class name specified for an event filterentry must match a defined class name. See “Tivoli SoftwareDistribution Classes” on page 405 for a listing of classes forTivoli Software 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.


404 Version 4.1

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 Tivoli Enterprise Console Integration component andrun the swdistecsrvr_inst.sh script, these classes are compiled andincluded in the event server’s rule base. Use this listing tounderstand how Tivoli Software Distribution events are mapped toTivoli Enterprise Console 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.

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.



13.In

tegratin

gth

eTivo

liE

nterp

riseC

on

sole

Event Slots Notes

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.


406 Version 4.1

Creating and Executing ActivityPlans with Activity Planner

The Activity Planner is a Tivoli Software Distribution feature thatenables you to define a group of activities in an activity plan, submitthe plan to be executed, and monitor the execution of the plan.Activities are single operations that are performed on a set of targetsat specified times. Operations can include Tivoli SoftwareDistribution operations and Tivoli Management Framework TaskLibrary tasks.

Activities contained in a plan can have dependencies associated withthem which define circumstances under which the activity should beexecuted. The execution of the operation defined in the activity isperformed by the application to which the operation belongs. Thegroup of activities forms the activity plan.

Using the Activity PlannerYou can use the Activity Planner feature to perform the followingtasks:

¶ Manage a group of activities, originating from differentapplications, as a single activity from a single machine in thenetwork.

¶ Schedule the activity plan to run on a specific day and time, orto be repeated at specific time intervals, days of the week, or

14


14.C

reating

Activity

Plan

s

days of the month. See “Scheduling the Activity Plan” onpage 430 for detailed information.

¶ Schedule the plan to repeat indefinitely. See “SchedulingActivity Plans to Run Periodically” on page 432 for detailedinformation.

¶ Schedule activities to run at specific time intervals during theweek. See “Scheduling When to Execute an Activity” onpage 426 for detailed information.

¶ Set conditions on activities so that the execution of one activityis dependent on the completion result of other activities. See“Conditioning the Execution of Activities” on page 423 fordetailed information.

¶ Save activity plans in a database to resubmit them at any futuretime. See “Saving the Activity Plan” on page 437 for detailedinformation.

¶ View a list of all submitted activity plans and retrieveinformation such as completion status of a specific activity plan,activity, or of an activity for a specified target. See “Submittingand Monitoring Activity Plans” on page 439 for detailedinformation.

¶ Perform operations on activities and activity plans such ascancel, pause, resume and restart. See “Pausing, Resuming,Canceling, and Restarting an Activity” on page 444 for detailedinformation.

The Activity Planner feature relies on the Scheduler, a TivoliManagement Framework service, to manage time constraintsspecified in the activity plan. A job is submitted to the Scheduler tocarry out the request. When the specified time is reached, theScheduler performs the related operation. The Scheduler handlestime constraints specified by the following parameters in the activityplan:

¶ The activity plan’s start not before time

¶ The activity plan’s complete not after time

¶ The generation of new instances in a recursive plan

Using the Activity Planner

408 Version 4.1

¶ The start at day and time of the activity’s execution window

¶ The suspend at day and time of the activity’s execution window

For recursive plans, the Scheduler is responsible for keeping time ofthe generation of each instance of the plan. However, deleting a jobfrom the Scheduler that represents an instance of a recursive plan,discontinues the recursion of the plan and no further instances aregenerated.

An activity plan can be defined using the Activity Plan Editorgraphical user interface (GUI) or by defining it in a file in XMLformat using a text editor. The XML file in which the activity plan isdefined is called the activity plan definition file. The Activity PlanEditor enables you to save plans to the XML format, and also toopen a plan in the XML format into the graphical user interface.Refer to the Tivoli Software Distribution Reference Manual for moreinformation regarding the activity plan definition file.

Activity plans prepared using the Activity Plan Editor can be savedin the following three formats:

¶ Drafts, if they are not yet complete

¶ Templates, if they are complete

¶ XML file

Draft plans and templates are stored in their respective repositoriesin the activity plan database, but only templates are made availablefor submission. You use the Activity Plan Monitor GUI to select asaved plan template and submit the plan for execution. When a planis selected for submission, you can modify previously specifiedinformation. Once the plan is submitted for execution, the plan issaved in the submitted state, in the activity plan database, with theinformation specified at the time of submission. When activity plan(drafts, templates) are in use, they are automatically locked to avoidother users accessing the same plan and overwriting it. The planunlocks when you open a new plan or exit the Activity Plan EditorGUI. Administrators can submit, monitor, control, and deletesubmitted activity plans using the Activity Plan Monitor GUI or thecommand line interface (CLI). Refer to the Tivoli Software



14.C

reating

Activity

Plan

s

Distribution Reference Manual for more information aboutperforming operations on activity plans using the CLI.

Using the Activity Plan Monitor GUI you can perform the followingtasks:

¶ Submit activity plans to be executed

¶ View all submitted activity plans along with their status, starttime, and completion time

¶ View the list of activities contained in the plan

¶ View a graphical representation of the plan in the Activity PlanEditor window

¶ For each activity, view the targets (gateways, depots) assigned toit

¶ Perform operations such as pause, cancel, and resume

¶ Restart an activity on an endpoint where the operation wasunsuccessful

¶ Delete the status information of a plan from the activity plandatabase

¶ Launch the Distribution Status Console to monitor and controlsoftware distributions submitted using the Activity Planner.


410 Version 4.1

Launching the Activity Planner GUIsYou launch the Activity Plan Editor and the Activity Plan MonitorGUIs from the Tivoli desktop.

Launching either GUI displays a login dialog. In this dialog, youspecify the following information:

1. In the Host Machine text box, type the name of the hostmachine on which the Activity Plan Editor or Activity PlanMonitor is installed.

2. In the Login as text box, type an identified user account namefor the specified host machine. Ensure that the login user accountis a valid Tivoli administrator with the necessary TMR rolesassigned.

3. In the Password text box, type the password associated with thespecified login user.

Activity Planner RolesThe tasks you can perform using the Activity Plan Editor, ActivityPlan Monitor, and CLI are restricted by the Tivoli managementregion roles assigned to you. Depending on the operations you arerequired to perform, you can have one or more of the followingroles:

Launching the Activity Planner GUIs


14.C

reating

Activity

Plan

s

APM_Admin RoleWith this role, you can perform the following operations:

¶ Display a list of locked plans and unlock plans currentlylocked.

¶ Map error levels to return codes.

¶ Delete mapping of error levels and reset the defaultvalues.

¶ Display the current mapping of error levels.

¶ Start and stop the Activity Planner engine.

¶ Display and change the RIM object name.

¶ Change the user password that enables the ActivityPlanner engine to function properly.

APM_Edit RoleWith this role, you can perform the following operations:

¶ Import an activity plan into the activity plan database.

¶ Delete an activity plan from the activity plan database.

APM_Manage RoleWith this role, you can perform the following operations:

¶ Submit an activity plan for execution.

¶ Cancel, pause, resume, and restart activities or theactivity plan.

¶ Clean up submitted activity plans from the activity plandatabase.

¶ Remove the status of a submitted activity plan.

APM_View RoleWith this role, you can perform the following operations:

¶ Return a list of activity plans maintained in the activityplan database.

¶ Output an activity plan in the activity plan definition fileformat.

Activity Planner Roles

412 Version 4.1

¶ Display the status of a submitted activity plan.

Refer to the Tivoli Management Framework User’s Guide for moreinformation about setting Tivoli management region.

Types of ActivitiesAn activity plan is a group of operations or tasks performed on a setof targets at a scheduled time. A single operation or task in anactivity plan is called an activity. Activities can perform either TivoliSoftware Distribution operations or Tivoli Management FrameworkTask Library tasks. Activities can also be dependent upon the resultof other activities.

The following Tivoli Software Distribution operations are supported:¶ Change management operationsv Installv Removev Undov Acceptv Commit

¶ Depot management operationsv Loadv Unload

¶ Data movement operationsv Sendv Retrievev Delete

The following Tivoli Management Framework Task Library task issupported:

¶ Execute Task

Activities that perform Tivoli Software Distribution operations arerepresented in the Activity Plan Editor main window by an icon thatdisplays a box with an inserted CD-ROM.

Activity Planner Roles


14.C

reating

Activity

Plan

s

For information on the properties of these operations and theirsupported parameters, refer to the commands chapter in the TivoliSoftware Distribution Reference Manual.

Activities that perform Tivoli Management Framework tasks arerepresented in the Activity Plan Editor main window by an icon thatdisplays a timer, a schedule, and a pencil. For more information onTivoli Management Framework Task Library tasks, refer to the TivoliManagement Framework User’s Guide.

Defining an ActivityYou define activities using the Activity Plan Editor GUI. When youlaunch the Activity Plan Editor from the Tivoli desktop the mainwindow of the GUI displays an empty activity plan. You can proceedto define activities in the current activity plan or you can choose toopen an existing plan from the File menu. Activities are displayed asicons in the main window and arrows linking activities representdependencies among the activities. To define an activity, you specifythe following:

¶ The name of the activity

¶ A brief description of the activity

¶ The type of operation the activity will perform on a set oftargets

¶ Properties related to the type of operation

¶ Targets of the activity (if not specified at the activity plan level)

For example, to create an activity that performs the install operationof a software package, complete the following steps:

1. Launch the Activity Plan Editor GUI from the Tivoli desktop byclicking the related icon. The Activity Plan Editor main window

Types of Activities

414 Version 4.1

is displayed.

2. Select the Activities icon, represented by a box with an insertedCD-ROM, from the Activities tab on the toolbar. This iconrepresents an activity that can perform Tivoli SoftwareDistribution, Version 4.1 operations. The Activity Propertiesdialog is displayed.

3. Specify whether the activity is the final activity in the plan. See“Defining the Final Activity” on page 428 for more information.

4. Specify a name that identifies the activity in the activity plan, inthe Name of Activity text box or use the default nameprovided.

Defining an Activity


14.C

reating

Activity

Plan

s

5. Optionally, enter a string of text that describes the activity inthe Description of Activity text box.

6. Click the Operation drop-down list to display a list ofsupported operations, then select Install. See “Types ofActivities” on page 413 for a complete list of supportedoperations.

7. Select Properties to set the install options for the activity.

For more information about the settings in this dialog, see“Install Operation” on page 299. Also, refer to the TivoliSoftware Distribution Reference Manual and the online helpavailable from this dialog.

8. In the Software Package text box, enter the name of thesoftware package to be installed or use the browse (...) button tobrowse your Tivoli environment and select a software packageprofile from the list of available software packages in your


416 Version 4.1

profile manager.

9. Click OK to save the information, close the dialog and return tothe Activity Properties dialog.

10. Click OK to save the information and close the dialog. Anactivity icon appears in the Activity Plan Editor window thatrepresents the activity you have just defined.

Note: When adding new activities to a plan that are very similar toactivities that you have already defined, you can copy andpaste the activity into the same plan, or different one, to savetime and reduce the possibility of errors.

Assigning Targets to an ActivityYou can assign targets at the activity level or at the activity planlevel. However, if you assign targets for each individual activity, youcannot specify targets at the activity plan level. If you assign targetsat the activity plan level, the targets apply to all of the containedactivities and no other targets can be specified at the activity level.See “Defining the Targets of an Activity Plan” on page 435 forinformation about assigning targets at the plan level.



14.C

reating

Activity

Plan

s

Note: When specifying the targets of an activity that performs aload or unload operation, you must use the managed nodelabel and not the gateway label or the operation will fail.

To assign targets to an activity, perform the following steps:

1. Define an activity as explained in “Defining an Activity” onpage 414.

2. Right-click the activity icon in the window and select Targetsfrom the pop-up menu. The Add Target dialog is displayed.

In this dialog, you can select how to specify the targets of anactivity. You can choose from one of the following ways:

¶ A list of target names

¶ A file name containing a list of target names

¶ An inventory subscriber

¶ A query library subscriber

¶ Variables

¶ A profile manager

Specifying a List of Target NamesYou can specify a list of target names to be the targets of an activity.To specify the targets of an activity using a list of target names,perform the following steps:

Assigning Targets to an Activity

418 Version 4.1

1. Select List of target names from the Target selection typepull-down list.

2. Type in the Insert target text box, the name of the target youwant to add in the List of target names box and click Add.Alternatively, click the browse (...) button to open the SelectTarget dialog. The Select Target dialog enables you to select onlythose endpoints which are subscribers of the profile managers inyour Tivoli environment. To display a list of all availableendpoints, click the Target list button to display the List oftargets dialog.

3. Click OK to save the changes and close the dialog.

Specifying a File Name Containing a List of TargetsYou can specify the targets of an activity plan by indicating the pathto a file containing a list of target names.The target names must beeither separated by a comma, or a space, or on a separated line. Tospecify a file name containing a list of targets, perform the followingsteps:

1. Select File of target names from the pull-down list.

2. Type the name of the managed node where the file is stored, inthe Managed node text box.

3. Type the path of the file on the managed node that contains thelist of targets names, in the Path to file text box.

4. Click Refresh to display the content of the file in the File oftarget names list.


If changes are made to the file subsequent to adding it to the list,click Refresh to update the file contents.

Specifying an Inventory Subscriber as a TargetYou can specify queries that access the Tivoli Inventoryconfiguration database and selects a list of targets as the queryresult. To specify an inventory subscriber as a target using aStructure Query Language (SQL) query, perform the following steps:

1. Select Inventory Subscriber from the pull-down list.



14.C

reating

Activity

Plan

s

2. Click SQL panel to display the Define SQL Queries dialog.

3. Select the name of a table or view from the drop-down list todisplay a list of column names for the selected table.

4. Create an SQL search clause in the where box to specify whatinformation the query should return. Use the table names, columnnames, and the operator buttons to create the SQL clause.

5. Click Get result to return the information defined in the SQLsearch clause.


Refer to Tivoli Inventory User’s Guide for more information aboutSQL queries.

Specifying Query Library Subscribers as TargetsYou can specify a query representing a query library to return a listof possible subscribers from the Inventory configuration repositorydatabase. To select a query library from the Tivoli Enterprise objectdatabase to retrieve subscribers, perform the following steps:

1. Select Query Library Subscriber from the pull-down list.

2. Click SQL panel to display the Define SQL Queries dialog.

3. Select a query library from the pull-down list. The contents ofthe query library are displayed in the box.

4. Click Get result to retrieve the list of targets that satisfy theselected query library.


Using Variables to Specify TargetsYou can specify targets using variables. The list of targets isautomatically evaluated at execution time without user intervention.The following list details the supported variables:

$(TARGET_LIST)The target names associated with the variable are specified atsubmission time.


420 Version 4.1

$(DEPOT_LIST)The targets are the managed nodes configured as depots towhich the endpoints, specified in the $(TARGET_LIST)variable, are assigned.

$(ORIGINATOR)The node from which the activity plan is submitted.

You can define other variables that can be used to specify targets byselecting the Variables tab from the Plan Properties notebook. See“Defining Variables” on page 436 for more information.

To use a variable to specify the targets of an activity plan, performthe following steps:

1. Select Variables from the pull-down list.

2. Select a variable in the Available variables list and click theright arrow button to move it to the Set variables list.


Specifying a Profile ManagerYou can specify profile managers as targets of an activity plan. Theactivities contained in the plan are performed on the subscribersassociated with the specified profile manager. To specify a profilemanager as the target of an activity plan, perform the followingsteps:

1. Select Profile manager from the pull-down list.

2. Enter the name of the profile manager in the Profile managertext box or click the browse (...) button to open the Select Profile



14.C

reating

Activity

Plan

s

Manager dialog.

3. Expand the policy regions in the left pane to display the profilemanagers.

4. From the Search for Profile Manager box, add the requiredprofile manager to the List of Profile Managers in one of thefollowing ways:

¶ Select a policy region and click the >> button to add all theprofile managers contained in that policy region.

¶ Click the switch to the left of the name of the requiredpolicy region. The policy region expands to show all theprofile managers it contains.

¶ Select the required profile manager and click the > button.

5. To remove a profile manager, select the profile manager nameand click Remove. The profile manager is removed from the list.

6. To clear the list, select Clear.

7. Click OK to save the changes and return to the Add Targetdialog. The profile that you selected are added to the ProfileManager list.



422 Version 4.1

Conditioning the Execution of ActivitiesThe execution of an activity can be dependent upon the result of theexecution of another activity or activities in the same activity plan.

Assume that an activity plan consists of two activities, Activity Aand Activity B. A condition can be set on Activity B, the conditionedactivity, related to the outcome of the execution of Activity A, theconditioning activity, that dictates when Activity B is executed on itstargets. You can condition the result of the execution of Activity Aon all its targets using one of the following classifications:

CompletionThe execution of Activity B is performed when the operationdefined in Activity A completes, regardless of whether itcompletes successfully or with error.

SuccessThe execution of Activity B is performed only if theoperation defined in Activity A completes successfully withno error.

FailureThe execution of Activity B is performed if the operationdefined in Activity A fails with an error.

The execution of Activity B depends on the completion of ActivityA on all of the targets defined in Activity A. The operation specifiedin Activity B is executed when Activity A has completed executionon all its targets.

A completion percentage of targets can be specified. For example,you can specify to execute Activity B when Activity A hascompleted executing on 50% of its targets.

For example, to condition the execution of an activity on thesuccessful outcome of another activity on 50% of all its targets,perform the following steps:

1. From the Activity Plan Editor window, create two activities asexplained in “Defining an Activity” on page 414.

Conditioning the Execution of Activities


14.C

reating

Activity

Plan

s

2. Right-click the activity on which you want to set the conditionand select Condition from the pop-up menu. The Conditiondialog is displayed.

3. Select Successful-All from the pull-down list and click Enter.

4. Select the conditioning activity from the List of Activities in theplan.

5. Specify 50% by clicking the down arrow and using the scroll barto select 50%.

6. Click OK to save the information and close the dialog. Thecondition is represented by a red line connecting the activities in


424 Version 4.1

the Activity Plan Editor main window.

Note: When specifying a condition using a percentage, theconditioned activity might not start when that percentage isreached. This might occur where a single report for thecompletion of an operation groups many targets together.Even if the number of targets required to satisfy thepercentage has been reached, if the report is not sent to theActivity Planner engine promptly the conditioned activity willnot start. To obviate this, you can modify the MDist 2notify_interval parameter of the gateway to return the reportsmore frequently. Refer to the Tivoli Management FrameworkReference Manual for more information about modifyingMDist 2 parameters using the wmdist command.

Sorting Activities in Order of ExecutionYou can sort activities in the order in which they are to be executed.Only activities without conditions can be sorted. Conditionedactivities have a predefined order of execution and cannot bemodified using the Activity Sort dialog.



14.C

reating

Activity

Plan

s

To sort the activities contained in an activity plan in order ofexecution, perform the following steps:

1. From the Activity Plan Editor main window, select Edit→SortActivity. The Activity Sort dialog is displayed.

2. Select an activity in the list and click the up or down arrow torearrange the order.


Scheduling When to Execute an ActivityYou can schedule activities to run on specific days of the week andwithin a specified time frame such as, only during the day, duringthe night, on weekdays, or weekends. The execution window enablesyou to specify a time frame, at the activity level, within which theactivity is to be executed. You can specify more than one executionwindow for each activity. The time refers to the time on themanaged node where the plan is created.

Notes:

1. An execution window cannot be specified for task-type activities.

2. An execution window must have a duration of at least fiveminutes.

Sorting Activities

426 Version 4.1

3. The period between execution windows must not be less thanfive minutes.

For example, to limit the execution of an activity to start on Mondayevenings at 8 p.m. until Tuesday morning at 6 a.m., perform thefollowing steps:

1. Right-click an activity in the Activity Plan Editor window andselect Execution Windows. The Execution Windows dialog isdisplayed.

2. Click Add to enter the execution time within which the selectedactivity must be executed. A row is added in the dialog.

3. Double-click the row under the Start day column and selectMonday from the drop-down list.

4. Double-click the same row under the Start time column and aclock icon appears. Click the clock icon to display a 24-hourslide bar. Slide the slider to the 20:00 mark to set the start timeof the execution for 8 p.m. Click above or below the slider todecrement or increment the time in minutes.

5. Double-click the same row under the Suspend day column andselect Tuesday from the drop-down list.

6. Double-click the same row under the Suspend time column anda clock icon appears. Click the clock icon and using the slide

Scheduling an Activity


14.C

reating

Activity

Plan

s

bar, set 06:00 as the suspend time.


The activity can be executed only within the specified executiontime, Monday from 8 p.m. through Tuesday at 6 a.m. If the activityis running and has not completed by the suspend day and time, theactivity is paused and is resumed at the next specified executiontime, that is, the following Monday at 8 p.m.

Defining the Final ActivityYou can define a final activity in the plan that is executed when allother activities in the plan have either completed or have beencanceled.

You define a final activity, as follows:

1. Select either the Software Distribution activity icon or the TaskLibrary icon from the toolbar.

2. In the Activity Properties dialog, select the Final activity checkbox.

Scheduling an Activity

428 Version 4.1

3. Define the final activity, its targets, and execution time isidentical to that for other activities.

Note: For final activities, conditioning is not permitted.

Defining the Properties of the Activity PlanAn activity plan contains one or more activities to be executed onspecified target systems. Activity plans are executed consecutivelyaccording to their execution time and priority. The activities of allplans in submission that are ready to be executed are queued up andperformed in order of priority.

To define general information about the activity plan, perform thefollowing steps:

1. From the main window of the Activity Plan Editor, select theProperties icon from the toolbar. The Properties notebook isdisplayed. The General page is displayed by default.

2. Replace the default name in the Name text box and optionallyenter a description in the Description text box.

3. Set a priority on the activity plan by clicking the Prioritypull-down list and selecting from the High, Medium, and Lowoptions. The priority setting is the same for all activitiescontained in the same plan.

Defining the Final Activity


14.C

reating

Activity

Plan

s

4. Specify which of the notification options to use when theexecution of the activity plan is complete. The notificationoptions are:

¶ E-mail

¶ Posting a notice to a notice group (the notice group iscreated during the installation of the product)

5. Enter an e-mail address in the Mail-ID text box. You can specifymore than one address by separating the addresses with acomma. For information about configuring a mail server tocorrectly route e-mail generated by Tivoli Software Distribution,refer to the Tivoli Enterprise™ Installation Guide.

The Post notice check box is selected by default.

6. Select the Submit paused check box to submit the plan inpaused state. The execution of the plan begins when a release isperformed.

Scheduling the Activity PlanYou can schedule to execute an activity plan one time only, or youcan specify that the activity plan be executed on certain days of theweek, month, or at a date or time interval. If an execution time isnot specified for the activity plan, the activity plan is performed atthe time it is submitted.

Scheduling Plans to Execute within a Time IntervalYou can schedule an activity plan to start not before and completenot after a specified time. If the execution of the plan has notcompleted by the specified complete not after time, you canoptionally cancel any outstanding activities and stop the execution ofthe plan. The time reference refers to the time on the local machinewhere the plan is created.

For example, to schedule an activity plan to be executed not beforeOctober 20, 2001 at 7:00 a.m. and to complete by December 31,2001 at 12 midnight, perform the following steps:

1. Select the Execution Time tab from the Plan Propertiesnotebook.

Defining the Properties of the Activity Plan

430 Version 4.1

2. Select the Start not before check box. The current date and timeis displayed.

3. Click the Calendar icon and set the date in the calendardisplayed.

4. To modify the time, click the clock icon then use the slider to setthe time. Click above or below the slider to decrement orincrement the time in minutes.

5. Select the Complete not after check box and set the date andtime to December 31, 2001 at 12 midnight.

Note: If you specify frequency information, you cannot specify acomplete not after time.

If the activity plan does not complete within the complete notafter time specified, you can cancel all activities in execution byselecting the Cancel at cutoff check box. If you do not selectthis check box, the complete not after time specified is ignoredfor those activities already in execution and any outstandingactivities not yet executed are canceled.

Scheduling the Activity Plan


14.C

reating

Activity

Plan

s

6. To interrupt the execution of the activity plan should an erroroccur during the execution of an activity, select either Warning,Error, or Fatal from the Stop on error drop-down list. If theactivity completes with an error level equal to or greater than theerror specified, the activity plan is stopped.

Note: Because Tivoli Software Distribution return codes differfrom those generated internally by Activity Planner, toensure that the plan stops if an error occurs, set the stopon error option to warning. Alternatively, use thewseterrlev command to map a return code of 1 to eithererror or fatal.

Refer to the wseterrlev command in the Tivoli SoftwareDistribution Reference Manual for information about mappingreturn codes with error levels.

Scheduling Activity Plans to Run PeriodicallyAn activity plan can be scheduled to run more than once. You canspecify to repeat the execution of a plan in days, months, at aspecific date interval, or a time interval. When you specify toexecute an activity plan recursively, each time the plan is executed,an instance of the plan is submitted for execution. The referencepoint from which the recursion begins is the start not before timespecified on the Execution Time page. See “Scheduling Plans toExecute within a Time Interval” on page 430 for information aboutsetting the start not before time. If the start not before time is notspecified, the point of reference is the time the plan is submitted.The time reference is the time on the local machine where the planis created.

For example, to schedule an activity plan to run every Tuesday,perform the following steps:

1. From the main window of the Activity Plan Editor, select theProperties icon from the toolbar. The Properties notebook isdisplayed.


432 Version 4.1

2. Select the Frequency tab. The Frequency page is displayed.

3. Select the Days of the week radio button and enter 1 in the textbox. The days of the week are expressed by the numbers 1through 7, 1 represents Sunday.

4. To dynamically recalculate the list of targets each time aninstance of the activity plan is submitted, select Dynamic fromthe Targets resolution drop-down list. If you select Static, thelist of targets calculated when the first instance of the plan issubmitted is used for each successive instance submitted.

Note: If you specify frequency information, you cannot specify acomplete not after time on the Execution Time page.

Interrupting the Recursion of an Activity PlanYou can interrupt the recursion of an activity plan in the followingways:

¶ Specifying an expiration date on which to stop the recursion.

¶ Specifying to stop the recursion when an instance completes inerror.



14.C

reating

Activity

Plan

s

¶ Specifying to stop the recursion if an overlapping of instancesoccurs.

¶ Deleting the job from the Tivoli Management FrameworkScheduler.

¶ Using the wcntpln command. Refer to the Tivoli SoftwareDistribution Reference Manual for the command usage andsyntax.

From the Frequency page, you can discontinue the recursionmechanism by checking the expiration date check box and specifyinga date on which the recursive submission of an activity plan instanceshould stop. To specify an expiration date to stop the recursion,perform the following steps:


2. Click the calendar and clock icons and set the date and timerespectively, to the required expiration date. If an expiration dateis not specified, from the command line interface, use thewcntpln command to stop the recursion mechanism. Refer to theTivoli Software Distribution Reference Manual for moreinformation about the wcntpln command.

To specify an error level to stop the recursion, when an error occurs,perform the following steps:


2. From the Stop on error drop-down list, specify the requirederror level. The recursion will stop if the plan executes with anerror equal to or greater than the value you specify.

Note: Because Tivoli Software Distribution return codes differfrom those generated internally by Activity Planner, toensure that the plan stops if an error occurs, set the stopon error option to warning. Alternatively, use thewseterrlev command to map a return code of 1 to eithererror or fatal.


434 Version 4.1

Refer to the wseterrlev command in the Tivoli SoftwareDistribution Reference Manual for information about mappingreturn codes with error levels.

No two instances of the same recursive plan can be active at thesame time. For example, if Instance A of the recursive plan iscurrently in execution and Instance B is due to be executed, you canchoose to do one of the following:

¶ Leave the Stop on overlap check box unchecked to continuewith Instance A and skip Instance B and all successive instances(Instance C, D, E, and so on) until Instance A has completed.Instance B is executed at the next scheduled repeat following thecompletion of Instance A.

¶ Select the Stop on overlap check box to allow Instance A tocomplete, the instance actively in execution, but to discontinuethe recursion mechanism.

Defining the Targets of an Activity PlanYou can specify targets at the activity plan level or at the activitylevel. If the targets are specified at the activity plan level, then theoperations defined in the contained activities are executed on thesetargets. Targets cannot be specified at the activity level if they havebeen specified at the activity plan level. See “Assigning Targets toan Activity” on page 417 for more information.

To assign targets to the activity plan, perform the following steps:

1. From the main window of the Activity Plan Editor, select theProperties icon from the toolbar. The Plan Properties dialog isdisplayed.

2. Select the Target tab. The Target page is displayed.

3. Select how to specify the targets of an activity plan.You canchoose from one of the following ways:

¶ A list of target names. See “Specifying a List of TargetNames” on page 418.



14.C

reating

Activity

Plan

s

¶ A file name containing a list of target names. See“Specifying a File Name Containing a List of Targets” onpage 419.

¶ An inventory subscriber. See “Specifying an InventorySubscriber as a Target” on page 419.

¶ A query library subscriber. See “Specifying Query LibrarySubscribers as Targets” on page 420.

¶ Variables. See “Using Variables to Specify Targets” onpage 420.

¶ A profile manager. See “Specifying a Profile Manager” onpage 421.

Defining VariablesYou can define variables and then use them in your activity plan torefer to a list of targets or gateways. Variables you define in thisdialog appear as Available variables in the Add Target dialog whenyou select to specify targets using variables. See “Using Variables toSpecify Targets” on page 420 for more information about definingtargets using variables. For example, to define a list of gateways andthe targets assigned to those gateways using the Activity Plan Editor,perform the following steps:

1. From the main window of the Activity Plan Editor, select theProperties icon from the toolbar. The Plan Properties dialog isdisplayed.

Defining the Targets of an Activity Plan

436 Version 4.1

2. Select the Variables tab from the Properties notebook. TheVariables page is displayed.

3. Click Add to add an empty row to the Variables list.

4. Click the row under the Name column and type the name of thegateway list, such as, gw_list.

5. Click the same row under the Value column and type a list ofgateway names separated by a comma, for example, gw1, gw2,gw3.


Saving the Activity PlanSaving an activity plan saves it directly to the activity plan database.The activity plan database is a database used to maintain informationon activity plans. To save an activity plan prepared using theActivity Plan Editor, select the Save as option from the File menu.The Save as option shows the following three options:

Draft This option saves the activity plan as a draft in the activityplan database.

TemplateThis option saves the activity plan as a template in theactivity plan database.

Defining Variables


14.C

reating

Activity

Plan

s

XML fileThis option opens the Save as XML file dialog.

An activity plan saved as a template can be accessed using theActivity Plan Monitor GUI and submitted for execution. The plan isthen stored in a submitted state in the activity plan database. Onlyplans stored as templates or plans in the submitted state can beaccessed from the Activity Plan Monitor GUI. Using the ActivityPlan Editor, you can reopen saved activity plan templates and draftsand modify them and save them back to the database.

Removing Activity Plans or ActivitiesYou can remove an activity plan draft or template that has beensaved to the activity plan database by performing the followingsteps:

1. In the Activity Plan Editor, select Edit→Delete Plan. The DeletePlan dialog displays a list of draft plans and plan templates savedto the activity plan database.

2. Select a draft plan or template plan from the Delete Plan dialog.

3. Click Delete Plan.


Note: This procedure removes the template from the activity plandatabase but not submitted plans and their status. To deletesubmitted plans and their status, use the Activity Plan MonitorGUI or the wdelstat command explained in the TivoliSoftware Distribution Reference Manual. See “DeletingSubmitted Activity Plans” on page 446.

To remove an activity from an activity plan that is currently inpreparation, perform the following steps:

1. Select the activity to be removed from the Activity Plan Editorwindow.

2. From the Edit menu, select Remove Activity.

Saving the Activity Plan

438 Version 4.1

Submitting and Monitoring Activity PlansThe Activity Plan Monitor window displays a list of all submittedactivity plans and their current status in table format. Each table rowcontains an expandable activity plan and each column displays aparticular activity plan attribute.

The upper pane of the window displays a list of submitted activityplans. In this view, the following information is displayed:

¶ A list of submitted plans

¶ The activities contained within each plan

¶ Target information

¶ Recursion information

¶ Status of the plan

¶ Status of each activity in the plan

¶ The status of an activity on a particular target

¶ The start date and time of the plan

¶ The complete date and time of the plan completed

A toolbar displays icons that enable you to select directly the samefunctions available from the menu bar.

To view the activities contained within an activity plan, click theexpand icon to the left of the plan name. To view the targetsassigned to the activity and the status of the activity on thatparticular target, click the expand icon to the left of the activity. Youcan optionally select to group targets by gateway by selectingView→Target Grouping.

Note: If an activity defined in the activity plan installs a softwarepackage with the roaming endpoints option selected, and youselect to group the targets by gateway, the Activity PlanMonitor displays the original gateway of the endpoint and notthe gateway to which it migrates.

Submitting and Monitoring Activity Plans


14.C

reating

Activity

Plan

s

To view a graphical representation of the activity plan in the ActivityPlan Editor window, perform the following steps:

1. Select a plan from the Activity Plan Monitor window.

2. Select View → Activity Plan from the menu.

Activity Plan StatusActivity plans and activities can have any of the followingintermediate statuses:

¶ Successful

¶ Started

¶ Waiting

¶ Canceled by condition

¶ Paused

¶ Cancel pending

Submitting and Monitoring Activity Plans

440 Version 4.1

¶ Canceled

¶ Failed

The final status of an activity plan can be any one of the following:

¶ Successful

¶ Failed

¶ Canceled

To view detailed information about an activity plan, including status,select the plan in the upper pane of the window and the pie charticon on the toolbar. The lower pane displays the detailed informationin list form as a pie chart.

To view information about a specific activity or an activity on aspecific target, select the activity or target in the top pane and clickthe pie chart icon on the toolbar. The upper pane displays detailedinformation about the selected item in the top pane.

Submitting an Activity PlanWhen submitting an activity plan, you select from a list of templateplans. To submit an activity plan, perform the following steps:

1. Select Plans→Submit from the menu of the Activity PlanMonitor window,. The Select plan for submission dialog isdisplayed.

The dialog displays a list of plans saved as templates in theactivity plan database.

Activity Plan Status


14.C

reating

Activity

Plan

s

2. Select a plan in the dialog and click OK. The Plan SubmissionParameters notebook is displayed. This notebook is the same asthe Plan Properties notebook used during the preparation of anactivity plan using the Activity Plan Editor, except that targetinformation cannot be specified. For more information about thepages of this notebook see the following sections:

¶ General. See “Defining the Properties of the Activity Plan”on page 429.

¶ Execution Time. See “Scheduling Plans to Execute within aTime Interval” on page 430.

¶ Frequency. See “Scheduling Activity Plans to RunPeriodically” on page 432

¶ Variables. “Defining Variables” on page 436.

The General page is displayed by default.

Before submitting the plan for execution you can edit theattributes that were defined at the time the plan was created.Using the notebook, you can modify the following planattributes:

Submitting an Activity Plan

442 Version 4.1

¶ Plan name

Note: If you do not specify a plan name in the Name textbox, the name of the plan is generated at submissiontime in the format: name@submission_datesubmission_time

¶ Priority level

¶ Execution time

¶ Recursion information

¶ Expiration information

¶ User defined variables

When you have finished, click OK to save the changes and closethe Plan Submission Parameters notebook.

The plan is submitted for execution. An entry of the submitted planis added to the upper pane of the Activity Plan Monitor windowfrom where the status of the plan and its activities can be monitored.

Notes:

1. When the Activity Planner executes an activity, the role requiredto run the operation defined in the activity is compared with theinformation of the administrator who initially submitted the plancontaining the executing activity. This ensures that theadministrator who initially submitted the plan still exists and thatadministrator authorization has not been lowered. If theadministrator who initially submitted the plan no longer exists, orno longer has the authorization necessary to run the operationrequested in the activity, the execution will fail when it is run.

2. If after submitting an activity plan for execution, an entry of thesubmitted plan does not appear in the upper pane of the ActivityPlan Monitor window, an error has occurred while the ActivityPlanner engine was preparing the plan for submission. Forexample, a problem may occur trying to resolve targetinformation specified in the plan. Check the log file to determinethe problem.



14.C

reating

Activity

Plan

s

Pausing, Resuming, Canceling, and Restarting anActivity

You can use the Activity Plan Monitor to pause, resume, cancel, andrestart an activity. You select an activity contained in the list ofactivity plans from the Activity Plan Monitor window and selecteither the Pause, Resume, or Cancel option from the Selectedmenu. Depending on the current state of the activity, only validoptions are selectable.

Pause Pauses the execution of an activity. For activities not yetexecuted, the activities are paused. For activities executedbut not yet complete, the pause is managed by theapplication to which the activity belongs. For activities ofthe type Task, the pause option is not activated.

ResumeResumes the execution of all activities in the activity planthat are in the paused state. For activities of the type Task,the resume option is not activated.

CancelCancels the selected activity even if it is in execution andhas not completed. The activity is canceled by theapplication to which it belongs. For example, for an activityrelated to a Tivoli Software Distribution operation, theactivity is canceled by the MDist 2 service. For activitiesthat have not yet been executed, the Activity Planner engineperforms the cancel operation. For activities of the typeTask, the cancel option is not activated.

RestartRestarts the execution of activities in an activity plan thatfailed on targets of a previous execution. The activities arerestarted only on the targets that failed.

Launching the Distribution Status ConsoleThe Distribution Status console enables you view the status ofdistributions, such as which targets receive a distribution and whichones experience errors. You also can pause, resume, cancel, or delete

Pausing, Resuming, Canceling, and Restarting

444 Version 4.1

a distribution if, for example, you encounter unavailable targets,failed installations, or network outages.

You can launch the Distribution Status console from the ActivityPlan Monitor window to monitor and control Tivoli SoftwareDistribution operations defined in an activity. To launch theDistribution Status console, select View →Activity Progress from themenu.

Note: If you perform operations (pause, cancel, resume) from theDistribution Status console or using the wmdist command onTivoli Software Distribution operations defined in an activity,the Activity Planner is not able to detect that an operation hasoccurred and the status displayed in the Activity Plan Monitorwindow is not consistent with the distribution status. Forexample, if you cancel an operation using wmdist –c, thedistribution status is canceled, but the status reported in theActivity Plan Monitor is failed.

Refer to the Tivoli Management Framework User’s Guide for moreinformation about the Distribution Status console.

Updating the Status of an Activity PlanYou can set the Activity Plan Monitor to automatically update anddisplay the current status of all plans and activities, or have theActivity Plan Monitor update upon request. The data displayed in thewindow is reloaded with the current date in the activity plandatabase. For example, to automatically update the Activity PlanMonitor window every 2 minutes and 40 seconds, perform thefollowing steps:

1. From the View menu, select Automatic Update. The AutomaticUpdate dialog is displayed.

2. Select the Enable Automatic Update check box.

3. Drag the slider horizontally to the 2 minutes and 40 secondsposition on the bar.


Launching the Distribution Status Console


14.C

reating

Activity

Plan

s

To update the Activity Plan Monitor at any time, select Refreshfrom the View menu.

Deleting Submitted Activity PlansUsing the Activity Plan Monitor, you can delete the status of asubmitted plan, or a specific instance of a recursive plan that hascompleted, from the list of activity plans displayed in the mainwindow of the Activity Plan Monitor.

To delete the status of a submitted plan or the instance of a recursiveplan, select a plan from the Activity Plan Monitor main window thathas completed, then select Selected→Delete.

Cleaning Up the DatabaseTo eliminate plans from the activity plan database that have beensubmitted and completed, you can use the Activity Plan Monitor toschedule a cleanup operation. You can use the force option toeliminate plans in states other than completed states. Cleanupoperations can be scheduled to occur at any of the following times:

¶ Immediately

¶ One time only on a specific day and at a specific time

¶ Particular days of the week

¶ Particular days of the month

¶ A date interval

¶ A time interval

To define the plans you want to remove, you can specify any of thefollowing options:

¶ Plans with a particular status (canceled, failed, successful)

¶ Days elapsed since plans completed

¶ Days elapsed since plans started

¶ Plans with a specific age

Updating the Status of an Activity Plan

446 Version 4.1

When all the clean up parameters have been set, the Activity PlanMonitor relies on the Tivoli Management Framework Scheduler toperform the cleanup.

Define this example cleanup of all plans in the activity plan databasethat have completed successfully, as follows:

¶ Days completed: at least 30

¶ Cleanup frequency: every 15 days

¶ Start date: March 20, 2001

¶ Start time: 8 a.m.

To do the cleanup, perform the following steps:

1. From the Activity Plan Monitor main window, selectSettings→Clean Up to display the Clean up Properties dialog.The Frequency page is displayed by default.

2. In the Recursion type section, select the Date interval radiobutton and in the text box below, enter 00/00/15. This specifiesto perform the cleanup every 15 days.

3. In the Execution Time section, select the Start date check box.

Cleaning Up the Database


14.C

reating

Activity

Plan

s

4. Click the Calendar icon and set the date in the calendardisplayed.

5. Select the Rules tab to display the Rules page.

6. In the text box below Days elapsed since planstarted/completed, enter 30.

7. In the Reference Time section, select the Completed radiobutton.

8. In the Status section, deselect the Canceled check box andselect the Successful check box.

9. Click OK to save the settings and close the dialog.

Cleaning Up the Database

448 Version 4.1

Change ConfigurationManagement

Change Configuration Management (CCM), together with theActivity Planner, supports software distribution management andchange management in a large network. It does this by managing theworkstations of specified groups of users as single entities.

The core concept of CCM is the reference model. Using CCM, youcan create reference models where you define the hardware andsoftware requirements of different groups of users, for example,managers and software developers. You then specify the subscribersto each group. The subscribers are the workstations used by themembers of the groups. This allows you to manage workstationsaccording to the role each plays within your organization.

Once you have created the reference model, you can generate anactivity plan that includes all the tasks required to ensure that thesubscribers match the requirements you defined for each group in thereference model.

If there is a change to requirements, or if a subscriber changes itsrole, you can simply update the reference model to reflect thechanges and generate a new activity plan.

CCM also provides a classification of the relations between softwareapplications to prevent definition or enforcement of incorrectconfigurations at the server and at the client.

15


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

This chapter provides the following:

¶ Explanations of the concepts involved in CCM. See “ReferenceModels” on page 450 and “Subscribers” on page 452.

¶ A description of an example reference model. See “ReferenceModel Example” on page 453.

¶ Instructions on how to work with the CCM interface. See “UsingCCM” on page 456.

Reference ModelsThe reference model is the core concept of CCM. Independently ofany specific workstation, it provides a profile of a desiredconfiguration to which workstations can subscribe.

A reference model is normally made up of several reference modelsarranged in a hierarchy. At the top level is the parent referencemodel, which defines requirements that are inherited by all childreference models within the hierarchy. Each child reference modeldefines further requirements that can supplement, override, or blockthe requirements defined in the parent model.

You define the software and hardware requirements by addingconfiguration elements to a reference model. CCM includes thefollowing types of configuration element:

¶ SWD elements, which allow you to define the desired state(change management status) of a specified software package.

¶ Inventory elements, which allow you to specify hardwareprerequisites.

For SWD elements, you select a software package and define thestate, for example, IC, that you require. For a full description of theuse of software package states, refer to the chapter “UnderstandingChange Management Operations” in the Tivoli Software DistributionReference Manual.

Change Configuration Management

450 Version 4.1

You can also make any changes required for the element dependenton the state of another software package. Dependencies can bedefined as the following:

¶ Prerequisites, where you define a condition that must be metbefore the changes required to bring the subscribers to the statespecified in the SWD element can be made. For example, for asoftware package to be installed a prerequisite package mustalready be installed on the target.

¶ Exrequisites, where you define a condition that prevents thechanges required to bring the subscribers to the state specified inthe SWD element. For example, a software package will only beinstalled on targets where an exrequisite package is not installed.

¶ Corequisites, where the changes specified in another SWDelement must be made as part of the sequence that includes theSWD element you are defining.

For example, if you want to install a package and then installpatches for the package, you must include the patches ascorequisites for the element that specifies the base package. Inthis way, the base package is installed first and then thecorequisite patches are installed. If you specify the patches asseparate SWD elements, the patches cannot be installed, as CCMcannot determine the actions necessary to install them on thetargets until the base package has been installed.

For Inventory elements, you define an expression that includes ahardware property selected from one of the Inventory tables. Forexample, Physical_Memory >= 131072.

Once the reference models have been defined, you can select theworkstations that are to be subscribers to the model.

CCM includes a differencing mechanism that compares the currentconfiguration of the subscribers with the desired state defined in theconfiguration elements of the reference model. The differencingmechanism produces an activity plan that includes all the actions

Reference Models


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

necessary to bring each subscriber to the required state. From theCCM GUI, you can submit the plan to the Activity Planner forscheduling.

SubscribersThe subscribers to a reference model are software distributiontargets. They are the workstations to which the profile defined in themodel is to be applied. CCM provides the following methods ofselecting subscribers:

¶ Specifying a .csv file that contains a comma-separated list of thetargets to be included.

¶ Specifying a profile manager. The targets that subscribe to thespecified profile manager subscribe to the reference model.

¶ Specifying individual targets.

¶ Defining an SQL query on the Tivoli Inventory configurationdatabase. The targets that match the query are the subscribers tothe reference model.

¶ Selecting a query representing a query library to return a list ofpossible subscribers from the Inventory configuration repositorydatabase.

You can build the list of subscribers to a reference model using oneor more of these methods. Each entry in the subscribers list canspecify to include or exclude the identified targets. So, you coulddefine a query to include targets and then specify individual targetsthat must be excluded if they are returned by the query.

For all the methods except specifying individual targets, the list ofsubscribers is obtained when the differencing mechanism is used tocreate an activity plan.

Web SubscribersYou can also use all the methods listed in “Subscribers” to createWeb subscribers. Assigning a Web subscriber to a reference modelmakes the model accessible from the Web Interface. See “Tivoli

Reference Models

452 Version 4.1

Software Distribution Web Interface” on page 333 for moreinformation about the Web Interface.

Note: Ensure that when assigning a Web subscriber to a referencemodel, the model does not contain nested software packages.The Web Interface is not able to manage models that containnested software packages.

The actions needed to bring a Web subscriber target to the desiredstate are not submitted as an activity plan. Instead, you use the WebInterface on the subscriber workstation to select the reference modeland execute the required actions.

The Web Interface does not support some of the options for desiredstate that are supported for activity plans. The only desired statesthat can be used for Web subscriber are IC (installed and committed)and RC (removed and committed).

Reference Model ExampleIn the example organization, Enterprise, the network users can bedivided into three distinct functional groups:

¶ Managers

¶ C++ developers

¶ Java developers

Figure 1 on page 454 shows the hierarchical structure of a referencemodel that could be used to define requirements for the subscribersto the three groups.

Web Subscribers


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

The Enterprise 1.0 reference model is the root of a hierarchical tree.It contains configuration elements that define requirements commonto all three groups. It has two direct child reference models,Managers 1.0 and Developers 1.0, which inherit the configurationelements defined in Enterprise 1.0. Developers 1.0 also has two childreference models, C++ Developers 1.0 and Java Developers 1.0,which inherit the configuration elements defined in Developers 1.0and those inherited by Developers 1.0 from Enterprise 1.0.

Table 3 shows a summary of the elements defined for the Enterprise1.0 reference model.

Table 3. Summary of Elements in the Example Reference ModelReference Model Element

Type Description

Enterprise Inventory Physical memory at least 131072 KB

SWD Package Windows NT40.1.0 in IC state

SWD Package Lotus Notes.1.0 in IC state

Managers SWD Package CMVC.1.0 in IC state

SWD Package Office2000.1.0 in IC state

Developers SWD Package CMVC.1.0 in ICU state

Java Developers SWD Package JDK.1.8 in IC state

Figure 1. Example Reference Model

Reference Model Example

454 Version 4.1

Table 3. Summary of Elements in the Example Reference Model (continued)Reference Model Element

Type Description

C++ Developers SWD Package Visual C++.5.0 in IC state

Table 4 shows the subscribers assigned to each child reference modelthat represents a group of users. The root reference model,Enterprise, does not have any subscribers. It defines generalrequirements for all groups.

Table 4. Subscribers to the Example Reference ModelReference Model Subscribers

Enterprise -

Managers Stockholm

Developers Paris, Rome, Vienna

Java Developers Athens, Dublin

C++ Developers London, Brussels

When an activity plan is generated for the C++ Developers model,the differencing mechanism compares the current configuration ofthe London and Brussels targets with the configuration defined in themodel. Both subscribers have the required amount of physicalmemory defined in the Inventory configuration element and do nothave any of the software packages defined in the SWD configurationelements.

The generated activity plan includes the following actions:

¶ Install Visual C++.5.0

¶ Install CMVC.1.0 in undoable mode

¶ Install Lotus Notes.5.0

¶ Install Windows NT40.10

Reference Model Example


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

Before You StartBefore you start to use the CCM tool, you must do the following:

¶ Ensure that all installation and configuration tasks have beencompleted.

Both the Activity Planner and the Historical Database Featuremust be correctly installed, the prerequisites for using the JavaGUI must have been installed on the system you are using, andthe required RDBMS configurations must have been made. See“Creating RIM Objects and Database Tables for Activity Planneror CCM” on page 37.

¶ Assign a CCM role to the user ID you are working with.

There are three CCM roles; View, Manage, and Edit. Tocomplete all the tasks described in the sections that follow, youmust assign the Edit role. For more information about CCMroles see the Tivoli Software Distribution 4.1 Reference Manual.For instructions on assigning roles, see the Tivoli ManagementFramework 3.7 User’s Guide.

Using CCMUsing the information and instructions included in this section, youcan complete the following tasks:

¶ Create a reference model that includes parent and child models.See “Creating the Reference Model Structure” on page 457.

¶ Add configuration elements to the reference model. See “AddingElements to a Reference Model” on page 459.

¶ Assign subscribers to the reference model. See “AssigningSubscribers to a Reference Model” on page 464.

¶ Export reference models and save them in an XML format. See“Saving a Reference Model in XML Format” on page 472.

¶ Work with existing reference models, reimporting, modifyingand deleting them. See “Modifying a Reference Model” onpage 473.

Before You Start

456 Version 4.1

¶ Produce and submit an activity plan for the reference model. See“CCM and Activity Plans” on page 475.

¶ Produce reports. See “Creating CCM Reports” on page 478.

To start CCM, select the Change Configuration icon on the Tivolidesktop. As a user with the CCM Edit role, you can select all of theavailable CCM functions.

When you start CCM, the Change Configuration Managementwindow appears. It is divided into upper and lower panes. In theupper pane, you define the structure of the reference model. Anunnamed model is already present in this pane. In the lower pane,you add configurations and subscribers to the reference modelstructure you have defined in the upper pane.

There are three methods of accessing the CCM functions, althoughnot all three ways are available for all functions:

¶ From the menus at the top of the Main window

¶ By using the icons

¶ From the pop-up menu

Creating the Reference Model StructureTo create the reference model structure described in the referencemodel example in this chapter, perform the following steps:

1. In the upper pane, select the unnamed reference model andright-click to display the pop-up menu.

Using CCM


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

2. From the menu, select Properties. The Properties dialogappears.

3. In the Name text box, enter Enterprise as the name of theparent reference model. Optionally, you can also enter versionand description information.

4. In the Version text box enter 1.0 (this text box is optional).

5. In the Description text box enter the descriptive text Newenterprise model to describe the reference model (this text boxis optional).

6. Click OK. CCM creates the new parent reference modelEnterprise.

7. Select the Enterprise reference model and right-click to displaythe pop-up menu.

8. Select New reference model. The Properties dialog appears,prompting you for the properties of the new child referencemodel.

9. In the Name text box, enter the name of the new referencemodel, Managers or Developers. Optionally, you can also enterversion and description information.

10. Click OK. CCM creates the new child reference model.

Creating the Reference Model Structure

458 Version 4.1

11. Continue adding child reference models until the referencemodel structure is complete. In the example, this means addingone more child model to Enterprise, and two child models toDevelopers.

Adding Elements to a Reference ModelYou can add a new element to a new or restored reference model, bychoosing an available element type and entering the element nameand the desired state. The new element is recorded in the CCMrepository.

This section includes instructions for the following tasks:

¶ Adding an SWD element with a dependency.

¶ Adding an Inventory element.

Adding an SWD ElementTo add an SWD element to a reference model, perform the followingsteps:

1. In the upper pane, select the reference model.

2. In the lower pane, select the Elements tab.

3. Right-click in the Elements pane to display the elements pop-upmenu.

Creating the Reference Model Structure


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

4. Select SWD element. The Software Distribution element dialogappears.

5. Enter the name of a software package.

If you do not know the name of the package, you can click thebrowse button to navigate to a list of the software packages thatare available for each accessible profile manager.

6. Select the required software package state from the Desiredstate drop-down list.

Note: The Web Interface module only supports the actionsrelated to the IC and RC desired states. If you aredefining a reference model with Web subscribers, beaware of this limitation when you select a desired state.

7. To add a dependency, right-click in the Dependencies pane. Apop-up menu gives you the following options:

¶ Ex-requisite

¶ Pre-requisite

Adding an SWD Element

460 Version 4.1

¶ Co-Requisite

8. Select the required dependency type. The corresponding dialogbox is displayed.

9. In the Name text box, Enter the name of the software packagethat is to be the pre-requisite, ex-requisite, or co-requisite of thesoftware package you specified for this element.

If you do not know the name of the package, you can click thebrowse button to navigate to a list of the software packages thatare available for each accessible profile manager.

10. Select the required software package state for the dependencyfrom the Desired state drop-down list.



15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

11. Click OK. The dependency dialog closes and the dependency isshown in the dependency list for the SWD element.

12. Click OK. The new SWD element is added to the referencemodel.

Adding an Inventory ElementTo add an Inventory element to a reference model, perform thefollowing steps:

1. In the upper pane, select the reference model.

2. In the lower pane, select the Elements tab.

3. Right-click in the Elements pane to display the pop-up menu.


462 Version 4.1

4. Select Inventory Element. The Inventory element dialogappears:

5. Build an expression in the Inventory Condition text box, asfollows:

a. Select an inventory table view from the Select view dropdown list. A list of columns for the table view appears in thelower text box.

b. Select a column from the list and double-click. The columnname appears in the Inventory Condition text box.

c. From the panel of operators, select an operator, for example“=”, and double-click. The operator is added to the expressionin the Inventory Condition text box.

d. Click in the Inventory text box at the end of the expressionand type in a value, for example a minimum memory size.

Adding an Inventory Element


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

e. If you want to build a more complex expression, select theAND or OR operators from the operator panel and then addanother condition to the expression.

6. Click OK. The new inventory element is added to the referencemodel.

Assigning Subscribers to a Reference ModelYou can assign subscribers to any of the component models of yourreference model. To assign subscribers to a model, perform thefollowing steps:

1. In the upper pane of the CCM Configurator window, select thereference model to which you want to assign subscribers.

2. In the lower pane, select the Subscribers tab.

3. Right-click in the Subscribers pane to display the pop-up menu:

4. Select one of the following values and follow the correspondinginstructions:

¶ CSV subscriber

Adding an Inventory Element

464 Version 4.1

¶ Profile manager subscriber

¶ Static subscriber

¶ Inventory subscriber

¶ Query Library subscriber

¶ Web Interface subscriber

The Web Interface subscriber is a different type of subscriberrather than a different method of assigning subscribers. Activityplans are not created for this type of subscriber. Instead, theactions required to reached the desired state are executed usingthe Web Interface. If you select this option, you can choose anyof the listed assignment methods to assign subscribers as WebInterface subscribers.

Note: All methods of assigning subscribers, other than Staticsubscriber, are dynamic. When you add the subscriber, CCMshows you a list of selected targets. These are the targets thatfit the selection criteria at this time.

Assigning a CSV SubscriberYou can select the subscribers to a reference model by indicating thepath to a file containing a list of target names separated by acomma. To specify a file name containing a list of targets, performthe following steps:

Assigning Subscribers to a Reference Model


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

1. Select CSV subscriber from the pop-up menu. The CSVSubscriber dialog appears:

2. Select the CSV file you want to include and display its contentsin the CSV subscriber list, by doing one of the following:

¶ Type the fully qualified file name in the Selected file textbox and click Refresh.

¶ Click the browse button (...), navigate to the file location,select the file, and click Open to return to the CSVsubscriber dialog.

Assigning a CSV Subscriber

466 Version 4.1

3. Select either the Include or Exclude button and click OK. TheCSV subscriber is added to the reference model.

Assigning a Profile Manager SubscriberYou can specify a profile manager as a subscriber to a referencemodel. The subscribers to the selected profile manager are the targetsthat are to match the configuration specified in the reference model.To specify a profile manager as a subscriber to a reference model,perform the following steps:

1. Select Profile manager subscriber from the pop-up menu. TheProfile manager subscriber dialog appears.

2. Enter the fully qualified name of the profile manager in theProfile manager text box, or click the browse button (...) tonavigate to the location of the profile manager and select it.

Assigning a CSV Subscriber


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

Note: Using the navigation tool, you can preview the contents ofthe profile manager before you select it.

3. Select either the Include or Exclude button and click OK. Theprofile manager subscriber is added to the reference model.

Assigning a Static SubscriberYou can specify a list of target names to be subscribers to areference model. To specify the subscribers to a reference modelusing a list of target names, perform the following steps:

1. Select Static subscriber from the pop-up menu. The Staticsubscriber dialog appears:

2. Enter the name of the target you want to include in the Endpointtext box, or click the browse button (...) to navigate to thelocation of the target and select it.

3. Click Add. The target is displayed in the Selected endpoint list.

4. Continue building the list by selecting other targets and clickingAdd.

Assigninga Profile Manager Subscriber

468 Version 4.1

5. Select either the Include or Exclude button and click OK. Thestatic subscriber is added to the reference model.

Assigning an Inventory SubscriberYou can specify queries which access the Tivoli Inventoryconfiguration database and selects a list of targets as the queryresult. To specify an inventory subscribers as a target using aStructure Query Language (SQL) query, perform the following steps:

1. Select Inventory Subscriber from the pop-up menu. TheInventory subscriber dialog appears.

2. Choose an inventory table view from the selectTME_OBJECT_LABEL from drop-down list. A list of columnsfor the selected view is displayed.

3. Build an expression in the Where box to specify whatinformation the query will return. To build a simple query, selecta column from the list, select an operator from the panel, and

Assigninga Static Subscriber


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

then assign a constant by typing in the Where box. You canbuild more complex queries using the AND and OR operators.

4. Click Get result. All the results satisfying that condition aredisplayed in the third pane:

5. Select either the Include or Exclude button and click OK. Theinventory subscriber is added to the reference model.

Refer to the Tivoli Inventory User’s Guide for more informationabout SQL queries.

Assigning Query Library SubscribersYou can specify a query representing a query library to return a listof subscribers from the Inventory configuration repository database.To select a query library from the TME object database to retrievesubscribers, perform the following steps:

Assigning an Inventory Subscriber

470 Version 4.1

1. Select Query Library subscriber. The Query Library subscriberdialog box appears:

2. Select a query library from the pull-down list. The contents ofthe query library are displayed in the box.

Assigning Query Library Subscribers


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

3. Click Get result to retrieve the list of targets that satisfy theselected query library.

4. Select either the Include or Exclude button and click OK. Thequery library subscriber is added to the reference model.

Saving a Reference Model in XML FormatWhen you have finished building the reference model, you can saveit by exporting it to an xml format. In this format, you can read thefile and edit it in any standard text or xml editor and reimport thefile to CCM.

To export a reference model to xml format, perform the followingsteps:

1. From the File menu select Export. The Save dialog box isdisplayed.

Assigning Query Library Subscribers

472 Version 4.1

2. Select the directory and, in the File name text box, type a filename.

3. Click Save. The reference model is exported in xml format to thespecified file.

Modifying a Reference ModelOnce you have created and saved a reference model, you can makechanges to it to reflect new requirements. For example, once areference model has been used to generate the actions required tobring subscribers to a required state, you can change therequirements by adding or modifying configuration elements. In thisway, you can reuse the hierarchical structure you have created tomake further changes to the subscribers.

To modify a reference model that you have exported to an xmlformat, you must import the model. When the model is displayed,you change it in the following ways:

¶ Modify the structure of the reference model by moving childreference models to new parents.

To do this, select the reference model you want to move, clickon the edge of the highlighted area, and drag and drop the modeluntil its line connects to the new parent.

¶ Add new reference models to the structure.

See “Creating the Reference Model Structure” on page 457.

¶ Remove reference models from the structure.

To do this, select the reference model you want to remove,right-click, and select Remove from the pop-up menu.

Note: When you remove a parent reference model, the childrenare automatically removed.

¶ Modify the properties of a reference model.

To do this, select the reference model you want to modify,right-click, and select Properties from the pop-up menu. See“Creating the Reference Model Structure” on page 457, forinformation about the properties that must be defined for areference model.

Saving a Reference Model in XML Format


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

¶ Add a new configuration element to a reference model.

See “Adding Elements to a Reference Model” on page 459.

¶ Remove a configuration element.

To do this, select the reference model you want to remove anelement from, in the lower pane select the element, right-click,and select Remove from the pop-up menu.

Note: The list of elements for a reference model indicatesinherited elements by means of an up-arrow icon.Inherited elements can only be removed from the parentmodel where they are defined.

¶ Modify the properties of a configuration element, for example tospecify a different software package.

To do this, select the reference model for which you want tomake changes, in the lower pane select the element, right-click,and select Properties from the pop-up menu. See “AddingElements to a Reference Model” on page 459 for details of theproperties of an element.

Note: The list of elements for a reference model indicatesinherited elements by means of an up-arrow icon. Youcan modify an element that is inherited, but you must beaware that the changes you make affect not only thereference model you have selected, but also the parentmodel where the element is defined and any other childmodels that inherit the element.

¶ Assign a new subscriber to a reference model.

See “Assigning Subscribers to a Reference Model” on page 464.

¶ Remove a subscriber.

To do this, select the reference model you want to remove asubscriber from, in the lower pane select the subscriber,right-click, and select Remove from the pop-up menu.

¶ Modify a subscriber, for example to define a different query.

To do this, select the reference model for which you want tomake changes, in the lower pane select the subscriber,

Modifying a Reference Model

474 Version 4.1

right-click, and select Edit from the pop-up menu. See“Assigning Subscribers to a Reference Model” on page 464 fordetails of the properties of an subscriber.

Note: You can restore a reference model from the latest savedversion. From the File menu, select Restore; the referencemodel is restored to the last saved version.

CCM and Activity PlansCCM includes two functions that use a differencing mechanism toproduce a list of the actions required to bring subscribers to thedesired stated defined in a reference model. These functions arePreview Activity Plan and Submit Activity Plan.

You should preview the activity plan before submitting it to theActivity Planner.

Note: Even if your model has only Web Interface subscribers, youstill need to submit an activity plan to update the CMMdatabases; even though the activity plan is empty. In this case,there is no need to preview the plan.

Previewing an Activity PlanTo preview an activity plan, perform the following steps:

1. Select the required reference model and right-click to display thepop-up menu.

Modifying a Reference Model


15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

2. Select Preview actions to display the Preview Activity dialogbox:

3. You can now return to the reference model to correct any errors,before submitting the activity plan, see “Submitting an ActivityPlan”.

Submitting an Activity PlanTo submit an activity plan, perform the following steps:

1. Select the required reference model and right-click to display thepop-up menu.

Previewing an Activity Plan

476 Version 4.1

2. Select Submit actions to display the Submit Dialog box:

3. Select one of the submission options:

¶ Submit activity plan to submit the plan to the ActivityPlanner.

¶ Import activity plan to send the plan to the Activity Plannerwhere it can be scheduled later.

4. If you selected Import activity plan, select or clear theOverwrite activity plan check box.

If you selected Submit activity plan, this check box cannot becleared. This is to prevent the submission failing because of aduplicate activity plan name in the Activity Planner database.

5. If you selected Submit activity plan, select or clear the Deleteactivity plan after submission check box.

6. Click OK.



15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t

Creating CCM ReportsCCM provides reports that provide you with an overview of activityplans related to reference models and targets. The following reportsare available:

Reference Model reportThis report summarizes progress for all targets that aresubscribers to a specified reference model. You can specify acomplete reference model, a branch of the hierarchical tree, oran individual child model. The model you specify need not becurrently displayed.

Target reportThis report summarizes progress for all reference models towhich a specified target is a subscriber.

To produce the Reference Model report, perform the following steps:

1. From the Reports menu, select Reference Model. The Selectreference model dialog appears.

2. Specify the name of the reference model for which you want toproduce a report. You can also specify a version.

3. Click OK.

To produce the Target report, perform the following steps:

Creating CCM Reports

478 Version 4.1

1. From the Reports menu, select Target. The Select target dialogappears.

2. Specify the name of the target for which you want to produce areport.

3. Click OK.

Both versions of the report include the following information:

¶ Target name

¶ Type of subscriber, for example Profile Manager

¶ Reference model name

¶ Activity plan ID

¶ Status

Possible values are Submitted, Successful and Failed

¶ Date and time the activity plan was submitted

¶ Date and time the result was received



15.C

han

ge

Co

nfig

uratio

nM

anag

emen

t


480 Version 4.1

Data Moving Service

In any distributed systems environment, the issue arises of how tomaintain consistency of data across the system. Data updates have tobe distributed from a central point, and information collected locallymust be retrieved for central consolidation and storage.

The Data Moving Service integrates data movement capabilities intothe Software Package Distribution process. It provides the followingbenefits:

¶ Support for sending, retrieving, and deleting files.

Any type of file can be sent, retrieved or deleted using the datamoving command.

¶ Lenient distribution.

¶ Ability to define pre- and post-transfer tasks.

¶ Ability to define software dependencies for data transfers.

The data transfer can be made dependent on the state, on thedestination system, of a specified version of a software package.You can define transfer command so that no transfers are madeif the specified software is not in the specified state on alldestinations, or so that the transfer is only made to destinationswhere the software is in the specified state.

¶ Code page translation capabilities.

¶ Use of Tivoli’s multiplexed distribution (Mdist2) service, whichprovides queuing, priority, checkpoint restart, distributionmonitoring, and bandwidth control.

16


16.D

ataM

ovin

gS

ervice

¶ Distribution results checking.

¶ A consistent API for integration with the Activity Planner.

Configuring the Data Moving ServiceAll data moving operations use the same software package object,DataMovingRequests.1. This object contains certain standardinformation to be used by all data moving operations, includinglogging options. If this object is not available, no data movingoperation can be performed from the CLI or the Activity Planner.

This object is normally created automatically, in a suitable profilemanager, when you install Software Distribution 4.1. However, ifthere is no suitable profile managers at installation time, you cancreate the object later by running data moving command,wspmvdata, with one of the following arguments:

¶ -A

This creates the DataMovingRequests.1 object in any suitableprofile manager.

¶ -p profile manager

This creates a DataMovingRequests.1 object in the specifiedprofile manager.

For more information about defining these arguments, see the sectionon wspmvdata in ″Using Commands″ in the Tivoli SoftwareDistribution Reference Manual.

As with other software package objects, operations using theDataMovingRequests.1 object can only be performed by users whohave been assigned at least the senior role in the policy region wherethe software package object resides.

You may wish to allow some users to perform data movingoperations but not change management operations, for exampleinstalling and removing software packages. You can achieve this bysetting up a policy region that is only contains theDataMovingRequests.1 object and assigning all the users a senior

Data Moving Service

482 Version 4.1

role in that region. If you decide to do this, you must remove thesoftware package from the policy region where it has beenautomatically installed, and recreate it in a profile manager in thedata moving policy region, using the -p argument.

Notes:

1. If Tivoli management regions are interconnected when the datamoving service is installed, there is only oneDataMovingRequests.1 object, which serves both regions. Usersof both regions, who are to perform data moving operations,must be assigned a senior role in the policy region where theobject is located.

2. Information about operations using the DataMovingRequests.1object is not stored in the Tivoli Inventory database.

3. The icon for the DataMovingRequests.1 object that appears onthe Tivoli desktop has limited functionality compared with theicons for other objects. It only provides access to the PackageProperties dialog. It does not allow you to open the softwarepackage file in the Software Package Editor, to open the Nestedpackages dialog, or to use drag and drop to perform data movingoperations on targets.

Data Moving ScenariosThe Data Moving Service supports the following scenarios:

¶ You want to send a file held in a central location to multipledestinations.

¶ You want to retrieve a specific file from a series of locations andconsolidate the retrieved files in a single, central location.

¶ You want to delete a specified file from a series of locations.

Sending Data to Multiple DestinationsA retailing company with several branches distributes its price list toall branches. Updates to the price list are made at the central office.An updated price list must then be distributed in a way that ensuresthat all branches are kept in line with the central pricing information.

Data Moving Service


16.D

ataM

ovin

gS

ervice

To complete the data movements required for this scenario, youdefine a data moving task with the following characteristics:

¶ A single data origin, which is a software distribution source hostat the head office.

¶ A destination list of endpoints that includes all the brancheswhere pricing information is held.

¶ A post-transfer task that updates the branch price lists with thenew information.

The following example shows a command to complete such atransfer.wspmvdata -s @centoff -t @b1,@b2,@b3 -r tpost:/tmp/importpl.sh /prices/plist

Using this command, the file plist, which is located in the directory/prices on the centoff source host system is copied to the b1, b2, andb3 endpoint systems. Following the transfer, the script importpl.sh,which is located in the \tmp directory, runs on the b1, b2, and b3endpoint systems.

Data Retrieval from Multiple OriginsEach day, sales transactions for the retail company are collected bythe branches where the sales are made. At the end of the day, thesales transactions must be transferred to the central office where thesales ledger and central stock registers can be updated.


¶ A pre-transfer task to run on all the branch endpoint systems toextract the sales transactions to a file.

¶ An origin list that includes all the branch endpoint systems fromwhich sales transactions are to be retrieved.

¶ A single destination source host system that is the central office.

¶ A post-transfer task that updates the central office sales ledgerand stock register with the sales transactions.

Data Moving Service

484 Version 4.1

The following example shows a command to complete such atransfer.wspmvdata -s @b1,@b2,@b3 -t @centoff -r tpost:\tmp\importtrans.sh- r spre:\tmp\exporttran.sh $sales\trans

This command uses a pre-processing script on the b1, b2, and b3endpoints to extract to a file called trans and store it in a directoryrepresented by the variable $sales. These files are retrieved from theendpoints and stored on the source host system, in a directoryrepresented by the variable $sales. As each file is retrieved, it isassigned a unique name. This name includes the file name, endpointname, time stamp and distribution id, in the following format:filename(without extension)_endpointname_timestamp_distributionID.extension

After the transfer, the script importtrans.sh runs on the source hostsystem.

Deleting a File on Multiple SystemsThere is a software upgrade, which results in changes to datastructures, and a file that is being used at all branches is no longerrequired by branches that are using the new software.


¶ A destination list that includes all the branch systems where thefile is present.

¶ The name and location of the file on the branch systems.

¶ The delete argument.

¶ A software dependency to ensure that only branches with thenew software are affected.

The following example shows a command to complete such atransfer.wspmvdata -t @b1,@b2,@b3 -S @SW_Package^2:I -d $temp/oldfile

Data Moving Service


16.D

ataM

ovin

gS

ervice

Using this command, the file oldfile is deleted from the b1, b2, andb3 systems, on the condition that the software SW_Package version2 is in an installed and committed state.

No origin system is required for the delete operation.

The Command Line InterfaceThe Data Moving Service is available from the CLI and from theActivity Planner interface.

The command is wspmvdata. Some examples of how you can usethis command to complete different data moving tasks are giving in“Data Moving Scenarios” on page 483.

The wspmvdata command supports a number of arguments thatallow you to define the following:

¶ An origin system or list of origin systems

¶ A destination system or list of destination systems

¶ Pre- and post-transfer tasks on both the origin and destinationsystems

¶ Software dependencies

¶ Overriding of variable

¶ Deletion of files on a destination system or list of destinationsystems

¶ Distribution objects, for example, timeouts, priorities, anddeadlines

Note: The wspmvdata command also supports two arguments, -pand -A, that create the DataMovingRequests.1 softwarepackage object that is used in all data moving operations.Neither of these arguments is needed if, at the time ofinstallation, there is a suitable profile manager in which thesoftware package object can be automatically created.

Data Moving Service

486 Version 4.1

For a full description of wspmvdata and its arguments, see thesection on wspmvdata in ″Using Commands″ in the Tivoli SoftwareDistribution Reference Manual.

Using Pre- and Post-Processing ScriptsWhen you define a wspmvdata command, you can specify up tofour scripts to be invoked during the data moving process. Thesescripts define pre- and post-processing tasks on the origin anddestination systems between which you want to move data. Thefollowing are typical examples of tasks you can define using thescript facility:

¶ Extracting data from a central repository on the origin systemand storing it in a file that is to be moved to the destinationsystems.

¶ Updating a local repository on the destination systems with datafrom the file that has been received.

The sequence in which the scripts run in a send operation is asfollows:

1. The pre-processing script runs on the origin system, which is thesource host system that was specified in the command.

2. A pre-processing script runs on each destination system. Thedestination systems for a send are endpoints.

3. A post-processing script runs on each endpoint.

4. The post-processing script runs on the source host.

The sequence in which the scripts run in a retrieve operation is asfollows:

1. A pre-processing script runs on the destination system, which isthe source host.

2. A pre-processing script runs on each origin system. The originsystems for a retrieve are endpoints.

3. A post-processing script runs each endpoint that was an originfor the retrieval.

Data Moving Service


16.D

ataM

ovin

gS

ervice

4. The post-processing script runs on the source host.

For delete operations, there is no origin system. Pre- andpost-processing scripts run on the endpoints from which the file is tobe deleted.

When you write a script to be used with the wspmvdata command,you must include the following arguments:

$1 Operation TypeThis identifies the type of data-moving operation. Possiblevalues are send, retrieve, and delete.

$2 Location TypeThis indicates whether the script ran on a Tivoli managednode (source host) or on an endpoint. Possible values areEP_SCRIPT for endpoints, and SH_SCRIPT for sourcehosts.

$3 Timing TypeThis indicates whether the script ran before or after the datamoving operation. Possible values are PRE_SCRIPT andPOST_SCRIPT.

$4 Data FileThis is the fully qualified name of the file that was moved ordeleted.

The values assigned to these arguments depend on the argumentsyou specified for the wspmvdata command.

Note: If you are writing a post-processing script for use on NTplatforms, you must include code to deal with any errorscaused by the file being locked.

This situation can occur when an identical file, in name andcontent, already exists on the target system and is locked atthe distribution time. In such a case, the data movingoperation does not fail with ″file locked″, because it does notattempt to replace the file, since there are no changes . As the

Data Moving Service

488 Version 4.1

operation has not failed, the post-processing script will runand must be able to deal with a locked file.

ExampleThe following command includes the script merge.sh as apost-processing script on the target system.wspmvdata -t @lab15124 -s @lab67135-w98,@lab15180-2000-r tpost:/usr/sd41/scripts/merge.sh /usr/sd41/source/data.txt

The target system for this command is a source host and the sourcelist includes two endpoints. The purpose of the merge.sh script is tocreate a single file on the source host system by merging the filesthat have been retrieved from the endpoints.

When the merge.sh script runs, the fixed parameters are set asfollows:

$1 Retrieve

$2 SH_SCRIPT

$3 POST_SCRIPT

$4 /usr/sd41/source/data.<endpoint name>.<timestamp>.<operation id>.txt

Note: The file name, data.txt, is expanded to include thename of endpoint from which it was retrieved, a time

#!/bin/sh#===================================================CM_OPERATION=$1LOCATION=$2PRE_POST=$3DATA_FILE=$4print "CM Operation:" $CM_OPERATION > /usr/sd41/scripts/merge.out;print "Location:" $LOCATION >> /usr/sd41/scripts/merge.out;print "Pre-post:" $PRE_POST >> /usr/sd41/scripts/merge.out;print "File Name" $DATA_FILE >>/usr/sd41/scripts/merge.out;print "===========================================" >>/usr/sd41/scripts/merge.file;print "=== FILE being merged: $DATA_FILE at: vdatev ==" >>/usr/sd41/scripts/merge.file;print "===========================================" >>/usr/sd41/scripts/merge.file;cat $DATA_FILE >> /usr/sd41/scripts/merge.file;print "Error level is:" $? >> /usr/sd41/scripts/merge.out;exit $?

Data Moving Service


16.D

ataM

ovin

gS

ervice

stamp, and an operation id. This ensures that eachretrieved file has a unique name when it is written tothe target directory on the source host.

The script writes these values and any errors to an output file andappends the contents of the data file to the fileusr/sd41/scripts/merge.file.

Data Moving Service

490 Version 4.1

Pristine Installations

This chapter describes how the Tivoli Software Distribution Pristinetool can be used to make pristine installations. A pristine installationinstalls an operating system on a system where no operating systemor other software is installed.

The chapter is divided into four main sections:

¶ “Overview” gives an overview of the pristine installation process

¶ “Windows Steps” on page 498 describes how to make pristineinstallations of the supported Windows operating systems

¶ “OS/2 Steps” on page 520 describes how to make pristineinstallations of the supported OS/2 operating systems

OverviewThis section gives an overview of the pristine installation process. Italso provides details of the prerequisites for the use of the tool andbriefly discusses how to install it.

The Tivoli Software Distribution 4.1 Pristine tool provides supportfor remote, almost completely unattended pristine installations, bypreparing and storing operating system images and configurationinformation on a server, which can be accessed through the networkby boot diskettes running on the pristine system. The advantages ofusing the tool are as follows:

17


17.P

ristine

Installatio

ns

¶ You can specify installation and configuration information at adifferent time and place to when and where the software is beinginstalled. Thus, the processes of preparation and installation canbe approached as separate tasks.

¶ You can provide information for the installation process in aresponse file so that the installation can be almost completelyunattended

Pristine installations can be made of the following operating systemswith the Pristine tool:

Windows NT Workstation 4.0

Windows 98 SE

Windows 2000 Professional

OS/2 Warp Server 4.0

OS/2 Warp Server for e-business 4.5

Any additional operating system software or any other softwareshould be installed using Tivoli Software Distribution after thepristine installation has completed.

Typical Network EnvironmentA typical network environment has, apart from the pristine systemsthemselves, three essential elements: a pristine preparation site acode server, and a dedicated pristine gateway, as shown in thefollowing figure:

Pristine Installations: Overview

492 Version 4.1

Pristine Preparation SiteThe pristine preparation site is the system where the Pristine tool isinstalled and running. It must be a Tivoli endpoint, in order for thePristine tool to be installed on it.

Code ServerThe Pristine tool on the pristine preparation site prepares theoperating system code images and saves them on a code server,from which they can be accessed by the pristine installation processover the network, in a code server object. The Pristine tool also addscode images of any other, non-operating system software, that isrequired by the installation process; for example, Tivoli ManagementAgent. Finally, the tool allows you to customize the response filesfor the operating system software and other required software.

Separate code server objects can be created for each type ofoperating system to be installed, and, if necessary, more than oneobject can be created for each operating system, for example, formultiple language versions of the same operating system.

Figure 2. Pristine installation scenario



17.P

ristine

Installatio

ns

The tool is also used to add configurations to each object. Aconfiguration contains all the information that defines how a specificsystem or group of systems is to be configured, in terms of thefollowing:¶ Customized operating system response file¶ Customized Tivoli Management Agent response file¶ Hard disk sizes (up to two hard disks)¶ Hard disk partitioning requirements¶ Optional Change Configuration Management (CCM) reference

model to use¶ Configuration notes

For each configuration, a boot diskette (for OS/2 a set of three bootdiskettes) is created. This diskette is transported to the appropriatepristine system where it is used to boot the system. The boot processaccesses the code server and downloads the code images, responsefiles and configuration files, and installs the operating system.

Although shown in Figure 2 on page 493 as a separate system, thecode server can be the same system as the pristine preparation site.

Dedicated Pristine GatewayThe final stage in the pristine process is to assign the pristine systemto a dedicated pristine gateway (a Tivoli Enterprise gateway). If theCode Server Object configuration contains a reference model, and onthe gateway a specific Login-Policy has been activated, a CCMoperation will be started, for example, to install software on thepristine system.

PrerequisitesThis section details the prerequisites for the code server, the Pristinetool, the creation of the system diskette and the pristine system itself.

Code Server PrerequisitesThe basic operating system requirements for the code server differ,whether you wish to install a Windows or an OS/2 operating system.

Windows To install any of the Windows operating systemsdetailed above, the code server must have one of thefollowing operating systems installed:


494 Version 4.1

Windows NT 4.0 (Server or Workstation)

Windows 2000 Professional

Any Windows system can be installed from a codeserver on any of these platforms (for example, aWindows 2000 Pro system can be installed on apristine system from a code server on a WindowsNT 4.0 Workstation).

OS/2 To install any of the OS/2 operating systems detailedabove, the code server must be a system of the sametype (for example, to install OS/2 4.0 on a pristinesystem the code server must be on an OS/2 4.0system).

Apart from the operating system prerequisites, the following are alsoprerequisites:

¶ The code server must be an endpoint, or any system in thenetwork to which the pristine system is connected

¶ Batch file utilities

Pristine Tool PrerequisitesThe Pristine tool can be installed on any of the platforms that can beused as a code server, except that:

¶ To prepare a pristine installation of a Windows operating systemthe tool must be installed on a Windows system

¶ To prepare a pristine installation of an OS/2 operating system thetool must be installed on an OS/2 system

Other prerequisites for the Pristine tool are as follows:

¶ The operating system images that you want to prepare must beavailable either from the operating system installation CD-ROMsor from hard disk.

¶ CD-ROM drive for the operating system images (optional -images can also be loaded from a hard disk).

Pristine Installations: Prerequisites


17.P

ristine

Installatio

ns

¶ A diskette drive and, for each separate code server configuration,one blank diskette for Windows, or three blank diskettes forOS/2.

¶ Code images must be available for the following requiredsoftware:

WindowsTivoli Management Agent for Windows

OS/2Tivoli Management Agent for OS/2TCPIPMPTSNetscape (OS 4.0 only)Java (OS 4.0 only)

System Diskette Creation PrerequisitesThe prerequisites for the system diskettes differ according to whetherthe diskette is for Windows or OS/2:

Windows

¶ The first phase of the system diskette creation requires the useof the DOS format command and must be done on a systemrunning native MS-DOS, Version 7.0 or higher.

¶ The second phase uses the Network Client Administrator utility,which is provided with Windows NT Server, but which can alsobe manually installed (by copying the executable file) on otherWindows platforms, such as Windows NT Workstation orWindows 2000 Professional.

¶ The second phase also requires the use of the Windows NTServer CD-ROM.

OS/2The following Configuration, Installation and Distribution (CID)utilities must be available, in the appropriate versions for theplatform to be installed:

THINLAPSTHINIFS


496 Version 4.1

CASINSTLSEDISK

Pristine System PrerequisitesThe pristine system requires:

¶ An appropriate network card and connection

¶ A diskette drive

Dedicated Pristine Gateway PrerequisitesThe dedicated pristine gateway can be any Tivoli Gateway, but itmust be dedicated to the first-time registration of pristine systems. Ifyou decide to use the CCM component to install software after theoperating system has been installed, the gateway must have thefollowing installed products:

¶ Tivoli Inventory Server and Gateway

¶ Tivoli Software Distribution Gateway

¶ Managed Node component of the CCM feature

In addition, after these components have been installed you should:

¶ Create a reference model in the CCM feature to install softwareon the pristine system; the reference model name and versionmust be the same as that used in the code server objectconfiguration

¶ Activate the login policy script by using the command:wputeppol login_policy < login_policy_pristine

Installing the Pristine ToolThe Tivoli Pristine tool is installed as an endpoint component ofTivoli Software Distribution (see “Endpoint Components” onpage 29). The tool can be used on a system on which TivoliSoftware Distribution is not installed.



17.P

ristine

Installatio

ns

Windows StepsThis section commences with an overview of the steps to be carriedout if you wish to install any of the supported Windows operatingsystems on a pristine system. It then describes each of those steps indetail.

Pristine Installation ScenarioTo prepare for and carry out one or more pristine installations,follow the steps detailed below:

Step 1. Plan the installations you want to make, deciding whichcode server objects are required to be installed, and for eachobject how many separate configurations will be requiredSee “Step 1: Planning” on page 499.

Step 2. Use the Pristine tool to create the code server objectsidentified in 1 See “Step 2: Creating and Maintaining CodeServer Objects” on page 500.

Step 3. For each code server object use the Pristine tool to create aconfiguration for each system or group of systems withsimilar characteristics, as determined in 1 See “Step 3:Creating and Maintaining Code Server ObjectConfigurations” on page 507.

Step 4. Prepare a system diskette for each configuration. See “Step4: Preparing a System Diskette” on page 513.

Step 5. Use the Pristine tool to add to the system disketteinformation that points to the code server object, therebycreating a pristine boot diskette, for each configuration See“Step 5: Creating a Pristine Boot Diskette” on page 516.

Step 6. Use the boot diskette to run a pristine installation, andoptionally carry out change configuration managementactivities. Finally, migrate the new endpoint from thededicated pristine gateway to a normal gateway. See “Step6: Running a Pristine Installation” on page 518.

If you intend to make pristine installations on a group of systemswith the same configuration sequentially, you will need only onediskette for each configuration; if the systems are at remote locations

Pristine Installations on Windows

498 Version 4.1

and you want to carry out the pristine installationscontemporaneously you will have to create a system diskette (Step 4on page 498) and subsequently transform it into a pristine boot

diskette (Step 5) for as many systems for which you needcontemporaneous installations.

Step 1: PlanningIn this section you plan how to use the Pristine tool to install anoperating system on a pristine system. Planning for pristineinstallations considers two questions:

¶ Which code server objects need to be created

¶ Which configurations need to be created for each code serverobject

Code Server ObjectsA code server object needs to be created for every version of everyoperating system you wish to install. If you work in amulti-language environment you should create a separate object foreach language version of each system.

A code server object comprises, apart from the configurations, justthe code images for the operating system software and the requiredadditional software (Tivoli Management Agent). Thus, if you onlyhave one operating system image and one image for TivoliManagement Agent, you will only need one code server object.

The Pristine tool allows you to modify code server objects, forexample, in the event that a new version of Tivoli ManagementAgent becomes available, and to delete them when they are nolonger required.

Code Server Object ConfigurationsEach code server object must have at least one configurationdefined. A configuration contains the following information:¶ Customized operating system response file; the tool lets you

modify the default response file supplied with the operatingsystem, changing values, and adding or deleting sections andkeys

Pristine Installations on Windows


17.P

ristine

Installatio

ns

¶ Customized Tivoli Management Agent response file; the tool letsyou customize the default response file in the same way

¶ The size of the hard disks of the pristine system; up to two harddisks can be defined using the Pristine tool - if the system hasadditional disks they must be partitioned and formatted manuallyafter the pristine installation is complete

¶ The partitioning requirements of the hard disks, including thedrive letters by which each partition can be identified; theprimary partition must be identified

¶ The device drivers which are to be loaded onto the pristinesystem

¶ The CCM reference model to use, if any; both the model nameand the version number can be specified (see “ChangeConfiguration Management” on page 449)

¶ Configuration notes

You should determine this information for each pristine system to beinstalled and then create a separate configuration for each system orgroup of systems that has a unique combination of these values.

Step 2: Creating and Maintaining Code Server ObjectsThis section shows you how to use the Pristine tool to create a codeserver object containing the code images of the supported Windowsoperating system, and of the Tivoli Management Agent that isrequired to be installed with the operating system.

Using the Pristine tool, you create a new code server object by doingthe following:

¶ Select the operating system to install on the pristine system

¶ Locate the source code images for the operating system

¶ Define the required location for the code server object on thecode server (ensure that the code server is accessible in thenetwork before commencing this procedure)

¶ Enter any useful information about the code server object

¶ For each additional product required to be installed with theoperating system (in the case of Windows only TivoliManagement Agent is required), locate the source code images

Pristine Installations on Windows: Planning

500 Version 4.1

¶ Save the code server object

The tool also subsequently lets you modify any of the parametersyou have defined, or to delete the object completely (if you deletethe object you will not delete the original code images).

Creating a New Code Server ObjectAll operations using the Pristine tool can be selected in the dialogsby any of these methods:¶ Select the item from the hierarchical menus¶ Click on an icon in the toolbar¶ Right click and select an item from the context-sensitive menu

that is displayed

In order to avoid unnecessary repetition in the instructions thatfollow, all options are described as being selected from thehierarchical menus.

In addition, you should note that items can be selected either byclicking on them or by using the tab and arrow keys to navigatearound the dialog.

The steps are as follows:

Pristine Installations on Windows: Code Server Objects


17.P

ristine

Installatio

ns

1. Start the Pristine tool and the Tivoli Pristine Tool dialog isdisplayed.

2. Optionally select the required operating system and select Tools→ New Code Server. The New Code Server Object dialog isdisplayed.


502 Version 4.1

3. Enter the name of the new code server object and click OK.The code server object setup dialog is displayed.

4. Under the General tab, enter the following identificationinformation for the operating system image:

Operating SystemIf you did not select the operating system on theprevious screen select it from this pull-down.

Source pathSelect the source path from Table 5, enter the fullpathname for the directory in which the operatingsystem image is located, or click the ellipsis (...) buttonand browse for the source directory.

Table 5. Source Path Location for Operating System Image onCD-ROMOperating System Source Path

Windows 98 <CD-ROM>\WIN98\SETUP

Windows NT 4.0 <CD-ROM>\I386

Windows 2000 Professional <CD-ROM>\I386



17.P

ristine

Installatio

ns

Destination pathEnter the full path on the code server where the codeserver object is to reside.

New destination pathThis field is only used to change the location of anexisting code server object, so it should be left blankwhen creating a new object.

5. Select the Information tab if you want to add additionalinformation about the code server object (for example, creator,date, purpose of the object).

6. Select the Products tab.

7. Click on the check box for Tivoli Management Agent. TheInstall Directories dialog is displayed


504 Version 4.1

8. In the Source path field enter the path for the TivoliManagement Agent software image, either from the TivoliManagement Framework CD-ROM or from a hard disk locationwhere you have previously copied it. The tool will propose aDestination Path which you are strongly advised not to alter.Click OK to save the settings and return to the code serverobject dialog.

9. Click the Apply button to update the object. A syntax check isperformed to ensure the paths you have entered are valid andthat there is enough room for the operating system image in thedestination folder. If the destination folder is not found after thischeck, it is created.

The platform name and the object name is displayed in theCode Server created list:

10. Click Add if you want to create another code server object, andthe New Code Server Object dialog is displayed (go back tostep 3 on page 503); or click OK to return to the Pristine toolmain menu.



17.P

ristine

Installatio

ns

Note: If you add another code server object, you must choose aplatform from the Operating System drop-down list inthe code server window.

Editing a Code Server ObjectYou can change all but one of the code server object parameters byselecting the object, selecting Tools → Code Server, changing thevalue previously entered and selecting Apply.

The exception is if you want to move the code server object to anew location:

1. Select a code server object in the Main dialog and then selectTools → Code Server.

2. Select the object you want to edit from the Code ServerCreated list and click Edit.

3. Enter a new path in the New Destination Path text box.

4. Click Apply. A check is performed to ensure the paths you haveentered are valid and that there is enough room for the operatingsystem image in the destination folder. If there is, the code serverobject will be moved to the location identified in NewDestination Path.

5. Click OK to return to the Pristine tool main menu.

Deleting a Code Server ObjectTo delete a code server object perform the following steps:


2. Select the object you want to delete from the Code Servercreated list and click Delete → Apply. A confirmation dialog boxappears. Click Yes. The object is deleted.

3. Click OK to return to the main menu.


506 Version 4.1

Step 3: Creating and Maintaining Code Server ObjectConfigurations

For every code server object created you must create at least oneconfiguration, which tells the pristine installation process how toconfigure the new operating system. The following actions arepossible:¶ “Customizing the Operating System Response File”¶ “Customizing the Tivoli Management Agent Response File” on

page 510¶ “Adding Device Drivers” on page 510¶ “Partitioning the Client Hard Disk” on page 512¶ “Defining a Reference Model” on page 513¶ “Adding Configuration-Specific Information” on page 513

Customizing the Operating System Response FileThe pristine tool provides you with an easy way to customize theresponse files that determine how the operating system will beinstalled. The default response files are located in the Pristine tool’sRSP subdirectory. These files can be edited using a text editor if youwant to change the default values offered in the tool.

1. From the Pristine tool main dialog, see the list of available codeserver objects by double-clicking the platform name. Select the

Pristine Installations on Windows: Configurations


17.P

ristine

Installatio

ns

object you want to configure.

2. Select File → New Configuration. The Pristine Configurationdialog is displayed.


508 Version 4.1

3. Enter a name for the configuration and click OK. TheConfiguration dialog is displayed.

This dialog lets you customize the operating system responsefile. The left panel lists all of the sections in the response file.Select a section and its installation keys and their default valuesare displayed in the right panel. Full details of the sections andkeys and their meaning should be found in the documentation forthe operating system.

Note: To select a section you are recommended to double-clickon the section name; a single click may be sufficient, buton certain platforms the Java code that controls the userinterface does not always respond to a single click

4. To change the value of an installation key:

¶ Select a section

¶ Double-click on the key for which the value is to bechanged. The Installation Key dialog is displayed.

¶ Edit the displayed value.

¶ Click on OK to return to the Configuration dialog.



17.P

ristine

Installatio

ns

5. To add, remove or rename installation keys, do the following:

a. Select a section

b. Select an installation key (you do not have to do this if youare only adding a new key).

c. Select Edit Key → Key → New, Delete or Rename.

d. The appropriate dialog will be displayed allowing you to add,delete or rename the key, as appropriate.

e. Click on OK to save the settings you have made and toreturn to the Configuration dialog.

Note: While for many of the keys you can use their factorydefaults, your attention is particularly drawn to the keysfor the installation path, the gateway port and the endpointport which must be completed for both the operatingsystem and for Tivoli Management Agent .

6. To add, remove or rename installation section names, do thefollowing:

a. Select the section (you do not have to do this if you are onlyadding a new section).

b. Select Edit Key → Section → New, Delete or Rename.

7. Click on OK to save the settings you have made and to return tothe Main dialog.

Customizing the Tivoli Management Agent Response FileFrom the Configuration dialog click on the No Product pull-downand select Tivoli Management Agent. The response file sections andkeys for this product will be displayed and can be customized asdescribed for the operating system response file, above.

Adding Device DriversFor most pristine installations, the device drivers incorporated in theoperating system software will be sufficient to enable the fulloperation of most pristine systems. However, if necessary, you canadd to the code server object any device drivers that are required tobe installed on the pristine system.


510 Version 4.1

For Windows 2000 or Windows NT, this step is carried out by thePristine tool, as follows:

1. Select Configuration → Add new device driver. The DeviceDriver dialog is displayed:

2. Click Add files and select the device driver file(s) to add.

3. Click Save to save the list of device drivers and return to theConfigurations dialog.

Remove a driver file by selecting the file and clicking Remove.

Note: For Windows 2000 Professional and Windows NT, the driverfiles are added by default to a subdirectory called‘...\$OEM$’ within the destination operating systemdirectory. However, if you need to add network adapter files,they should be added to ‘...\$OEM$\NET’, creating thesubdirectory if necessary, while video adapter driver files, forWindows NT only, should be added to‘...\$OEM$\TEXTMODE’.



17.P

ristine

Installatio

ns

For Windows 98 this step is performed following the instructions inthe operating system documentation for adding device drivers to theoperating system setup (in the code server object).

Partitioning the Client Hard DiskYou must define the partitions on the hard disks of the pristinesystem. Up to two hard disks can be partitioned. The steps are asfollows:

1. Select Configuration → Prepare hard disk. The DiskPartitioning dialog is displayed:

There are tabs for each of two physical volumes. On the firstvolume there is a default definition of a primary partition, withthe drive letter C, of 2000 megabytes.

2. To change the primary partition size click on Size and change thevalue.

3. To add a partition, click Add,. A new partition is created, with adefault size of 2000 megabytes, using the next available driveletter. The Partition type defaults to Logical, but can be changedby clicking on the Partition type of the partition in question. Thetotal of all partitions created is shown in the box at bottom right.To change the partition size click on Size and change the value.

4. Click OK to save the partitioning details and return to theConfigurations dialog.


512 Version 4.1

Remove a partition by selecting the partition and clicking Removeand then OK.

Defining a Reference ModelIn order to use CCM on the pristine system you are given the optionof defining a reference model. The steps are as follows:

1. Select Configuration → Reference Model. The Reference Modeldialog is displayed:

2. Enter the reference model name and/or version.

3. Click OK to save the reference model definition and return tothe Configurations dialog.

Remove a reference model definition by clicking Remove and thenOK.

Adding Configuration-Specific InformationConfiguration-specific information can be added to the configuration.The steps are as follows:

1. Select Configuration → Information. The Information dialog isdisplayed.

2. Enter the required information.

3. Click OK to save the information and return to theConfigurations dialog.

Step 4: Preparing a System DisketteFor each code server object configuration you will need to create asystem diskette that will be used in Step 5: Creating a Pristine BootDiskette.



17.P

ristine

Installatio

ns

You will use the standard diskette formatting command, and then theNetwork Client Administrator utility to add the files required by theclient to establish a network connection with the Code Server. Thesteps are as follows:

1. Prepare a system diskette on a system running MS-DOS 7.0 orhigher. At the DOS prompt, enter:format /s a:

This prepares a formatted disk containing the required systemfiles.

2. From the MS-DOS system, copy the following applications ontothe diskette:

¶ fdisk.com

¶ format.com

¶ smartdrv.exe

¶ xcopy.exe (in the case of a Windows 98 SE installation)

3. On a Windows NT Server, or other Windows system withNetwork Client Administrator installed, run Network ClientAdministrator (on the Windows NT server select Start →Administrative Tools → Network Client Administrator). TheNetwork Client Administrator dialog is displayed.

4. Select the Make Network Installation Startup Disk optionbutton and click Continue. The Share Network ClientInstallation Files dialog is displayed.

5. In the Path field, enter the location of the CLIENTS directory inthe root of the Windows NT Server CD-ROM. Alternatively youcan use the ellipsis (...) button to browse for the folder.

6. The first time you run this procedure, select the Copy files to aNew Directory, and then Share option button. This creates anew shared directory in a location of your choice (the default isc:\clients).

Note: You can write diskettes subsequently from the shareddirectory that you created in the previous step by selecting

Pristine Installations on Windows: System Diskette

514 Version 4.1

Use Existing Shared Directory. The utility points to thecopied files each time it is run.

7. Click OK. The Target Workstation Configuration dialog isdisplayed.

8. Select the appropriate type of disk drive for your system.

9. In the Network Client list box, select Network Client 3.0 forMS-DOS and Windows.

10. Choose a network adapter card from the list provided. If yournetwork adapter is not included, select any of the cards listed.You can then copy the correct adapter files and make theappropriate modifications to the start diskette at a later stage(this is described in step 16).

11. Click OK. The Network Startup Disk Configuration dialog isdisplayed.

12. In the Computer Name, User Name, and Domain text boxes,enter the required details, and select the TCP/IP NetworkProtocol.

13. Select the Enable Automatic DHCP Configuration check boxor type the appropriate data into the activated TCP/IP fields.

14. Insert the system diskette created in step 1 on page 514 into thediskette drive and click OK. A confirmation dialog box appears.

15. Click OK to create the boot diskette.

16. The system diskette has now been created and is ready to beused by the Pristine tool to create a pristine boot diskette (see“Step 5: Creating a Pristine Boot Diskette” on page 516).However, if your network card was not present in the adapterlist, now do the following:

a. Copy the appropriate DOS driver to the /NET directory onyour start diskette.

Attention: The PCI Token-Ring network adapter card isnot supported. Do not copy DOS driver files for this cardonto the diskette.



17.P

ristine

Installatio

ns

b. Using a text editor, modify the netcard statement in thesystem.ini file in the /NET directory so that it reads:netcard=<new name>.dos

c. Locate the oemsetup.inf file for your network card and openit using a text editor. Search for the options section andmake a note of the card name. An example is shown below:;*************************************************; Define Option;*************************************************[Options]

IBMFE[OptionsText]

IBMFE = "IBM 10/100 Ethernet PCI Adapter"

d. Using a text editor, modify the drivername statement in theprotocol.ini file in /NET directory so that it corresponds tothe name you observed in the oemsetup.inf file.

e. Save and close all files.

Step 5: Creating a Pristine Boot DisketteWhen you have created at least one configuration for a code serverobject (see “Step 3: Creating and Maintaining Code Server ObjectConfigurations” on page 507) and have prepared a system diskette(see “Step 4: Preparing a System Diskette” on page 513), you canuse the Pristine tool to transform the prepared system diskette into apristine boot diskette.


516 Version 4.1

1. From the toolbar, click Tools → Create Boot Diskettes. TheCreate Boot Diskettes dialog is displayed:

2. Place the diskette you created in “Step 4: Preparing a SystemDiskette” on page 513, into the diskette drive.

3. Complete the following fields:

Server name Hostname of the code server

Share name Share name of the folder that contains the codeserver objects (i.e. the Destination Path)

User name User name under which to login to the codeserver (usually Administrator)

Password Password to login to the code server

Map drive Select the drive letter to which the shared codeserver object directory is to be mapped

Network protocolSelect TCP/IP from the drop-down list

4. Click OK. The Pristine tool writes the data to the systemdiskette, creating a pristine boot diskette.

Pristine Installations on Windows: Boot Diskette


17.P

ristine

Installatio

ns

Step 6: Running a Pristine InstallationWhen you have completed the preparation of the boot diskette for asystem or group of systems (see “Step 5: Creating a Pristine BootDiskette” on page 516), you can commence a pristine installation.The installation procedure carries out the following operations:

¶ It uses the boot diskette to start up the pristine system and loada minimum system configuration into memory

¶ It installs the necessary protocols to connect itself into thenetwork and to locate the code server.

¶ Using the configuration information it partitions the hard disksand commences to download and install the operating systemsoftware, using the response file to drive the installation.

¶ Each system, or group of systems is assigned to a dedicatedTivoli gateway

¶ If the code server object configuration contains a referencemodel, and on the gateway a specific login-policy has beenactivated, a CCM operation will be started

When these activities are completed, the new endpoint must bemigrated from the dedicated pristine gateway to a normal gateway.

Pristine Installation ProcedureA person must be present where the pristine systems are located. Thetasks executed locally are:

¶ Starting the system

¶ Removing the diskette when necessary

¶ Pressing enter when requested during logon (Windows 98 only)

¶ Restarting the system if required

Once the diskette is ready and delivered to the person performing thelocal installation, the installation process can begin.

When the first Tivoli management agent login is connected, anautomatic notification of the presence of a new machine in the Tivolimanagement region takes place.

Pristine Installations on Windows: Running Installation

518 Version 4.1

If you have defined a reference model you should ensure that theCCM component of Tivoli Software Distribution is activated, inorder to compare the new system to the appropriate reference modeland to start the specific action. This action completes the pristineinstallation process.

Note: If you want to use a reference model to install TivoliSoftware Distribution, you should remember to install anyprerequisite software. For example, on Windows NT, theappropriate Service Pack is a prerequisite for Tivoli SoftwareDistribution, and thus must be installed first.

The final step is for the pristine system administrator, who must,after all installation processes are completed, migrate the newendpoint from the dedicated pristine gateway to a normal gateway.

Pristine Installations on Windows: Running Installation


17.P

ristine

Installatio

ns

OS/2 StepsThis section commences with an overview of the steps to be carriedout if you wish to install any of the supported OS/2 operatingsystems on a pristine system. It then describes each of those steps indetail.

Pristine Installation ScenarioTo prepare for and carry out one or more pristine installations youwill need to follow the steps detailed below:

Step 1. Plan the installations you want to make, deciding whichcode server objects are required to be installed, and for eachobject how many separate configurations will be requiredSee “Step 1: Planning” on page 521.

Step 2. Use the Pristine tool to create the code server objectsidentified in step 1 on page 498 See “Step 2: Creating andMaintaining a Code Server Object” on page 523.

Step 3. Use the OS/2 utilities to add system files to each codeserver object you created in Step 2. See “Step 3: AddingSystem Files to Code Server Objects” on page 526.

Step 4. For each code server object use the Pristine tool to create aconfiguration for each system or group of systems withsimilar characteristics, as determined in step 1 on page 498See “Step 4: Creating and Maintaining Code Server ObjectConfigurations” on page 529.

Step 5. Prepare a set of three system diskettes for eachconfiguration. See “Step 5: Preparing the System Diskettes”on page 532.

Step 6. Use the Pristine tool to add to the system diskettesinformation that points to the code server object, therebycreating a set of pristine boot diskettes, for eachconfiguration See “Step 6: Creating Pristine Boot Diskettes”on page 534.

Step 7. Use the set of boot diskettes to run a pristine installation,and optionally carry out change configuration managementactivities. Finally you will migrate the new endpoint from

Pristine Installations on OS/2

520 Version 4.1

the dedicated pristine gateway to a normal gateway. See“Step 7: Running a Pristine Installation” on page 536.

If you intend to make pristine installations on a group of systemswith the same configuration sequentially, you will need only onediskette (set of diskettes for OS/2) for each configuration; if thesystems are at remote locations and you want to carry out thepristine installations contemporaneously you will have to create asystem diskette (Step 5) and subsequently transform it into a pristineboot diskette (Step 6) for as many systems for which you needcontemporaneous installations.

Note: To avoid repetition, the dialogs for the OS/2 version of thePristine tool have not been reproduced here; please refer topages 501 to 516 for the corresponding dialogs in theWindows format.

Step 1: PlanningIn this section you plan how to use the Pristine tool to install anOS/2 operating system on a pristine system. Planning for pristineinstallations considers two questions:

¶ Which code server objects need to be created

¶ Which configurations need to be created for each code serverobject

Code Server ObjectsA code server object needs to be created for every version of theoperating system you wish to install (for OS/2 you can only preparecode server objects for the operating system on which the codeserver is installed). If you want to make pristine installations in amulti-language environment you should create a separate object foreach language version of each system.

A code server object comprises, apart from the configurations, justthe code images for the operating system software and the requiredadditional software (Tivoli Management Agent, TCPIP, MPTS, etc.).

Pristine Installations on OS/2


17.P

ristine

Installatio

ns

Thus, if you only have one operating system image and one imagefor each of the items of additional required software, you will onlyneed one code server object.

The Pristine tool allows you to modify code server objects, forexample, in the event that a new version of Tivoli ManagementAgent becomes available, and to delete them when they are nolonger required.

Code Server Object ConfigurationsEach code server object must have at least one configurationdefined. A configuration contains the following information:¶ Customized operating system response file; the tool lets you

modify the default response file supplied with the operatingsystem, changing values, and adding or deleting sections andkeys

¶ Customized additional required software response files; the toollets customize the default response files in the same way

¶ The size of the hard disks of the pristine system; up to two harddisks can be defined using the Pristine tool - if the system hasadditional disks they must be partitioned and formatted manuallyafter the pristine installation is complete

¶ The partitioning requirements of the hard disks, including thedrive letters by which each partition can be identified; theprimary partition must be identified

¶ The device drivers which are to be loaded onto the pristinesystem

¶ The CCM reference model to use, if any; the model name andoptionally the version number can be specified (see “ChangeConfiguration Management” on page 449)

¶ Configuration notes

You should determine this information for each pristine system to beinstalled and then create a separate configuration for each system orgroup of systems that has a unique combination of these values.

Pristine Installations on OS/2: Planning

522 Version 4.1

Step 2: Creating and Maintaining a Code ServerObject

This section shows you how to use the Pristine tool to create a codeserver object containing the code images of the supported OS/2operating system and of the additional software that is required to beinstalled with the operating system.

Using the Pristine tool, you create a new code server object by doingthe following:

¶ Select the operating system to install on the pristine system

¶ Locate the source code images for the operating system

¶ Define the required location for the code server object on thecode server (ensure that the code server is accessible in thenetwork before commencing this procedure)

¶ Enter any useful information about the code server object

¶ For each additional product required to be installed with theoperating system, locate the source code images

¶ Save the code server object

The tool also subsequently lets you modify any of the parametersyou have defined, or to delete the object completely (if you deletethe object you will not delete the original code images).

Creating a New Code Server ObjectAll operations using the Pristine tool can be selected in the dialogsby any of these methods:¶ Select the item from the hierarchical menus¶ Click on an icon in the toolbar¶ Right click and select an item from the context-sensitive menu

that is displayed

In order to avoid unnecessary repetition in the instructions thatfollow, all options are described as being selected from thehierarchical menus.

Pristine Installations on OS/2: Code Server Objects


17.P

ristine

Installatio

ns

In addition, you should note that items can be selected either byclicking on them or by using the tab and arrow keys to navigatearound the dialog.

The steps are as follows:

1. Start the Pristine tool and the Tivoli Pristine Tool dialog isdisplayed.

2. Optionally select the required operating system and select Tools→ New Code Server. The New Code Server Object dialog isdisplayed.

3. Enter the name of the new code server object and click OK.The code server object setup dialog is displayed.

4. Under the General tab, enter the following identificationinformation for the operating system image.

Operating SystemIf you did not select the operating system on theprevious screen select it from this pull-down.

Source pathSelect the source path from Table 6, enter the fullpathname for the directory in which the operatingsystem image is located, or click the ellipsis (...) buttonand browse for the source directory.

Table 6. Source Path Location for Operating System ImageOperating System Source Path

OS/2 Warp Version 4.0 <CD-ROM>\OS2IMAGE

OS/2 Warp Version 4.5 <CD-ROM>\OS2IMAGE

Destination pathEnter the full path on the code server where the codeserver object is to reside.

New destination pathThis field is only used to change the location of anexisting code server object, so it should be left blankwhen creating a new object.


524 Version 4.1

5. Select the Information tab if you want to add additionalinformation about the code server object (for example, creator,date, purpose of the object).

6. Select the Products tab.

7. Click on the check box of one of the additional requiredsoftware items. The Install Directories dialog is displayed.

8. In the Source path field enter the path where the software imageis located, either on the product CD-ROM or at a hard disklocation where you have previously copied it. The tool willpropose a Destination Path which you are strongly advised notto alter. Click OK to save the settings and return to the codeserver object dialog.

9. Repeat steps 7 and 8 for each of the additional requiredsoftware items.

10. Click the Apply button to update the object. A syntax check isperformed to ensure the paths you have entered are valid andthat there is enough room for the operating system and softwareimages in the destination folder. If the destination folder is notfound after this check, it is created.

The platform name and the object name is displayed in theCode Server created list.

11. Click Add if you want to create another code server object, andthe New Code Server Object dialog is displayed (go back tostep 3 on page 524); or click OK to return to the Pristine toolmain menu.

Note: If you add another code server object, you must choosean OS/2 platform from the Operating System drop-downlist in the code server window.

Editing a Code Server ObjectYou can change all but one of the code server object parameters byselecting the object, selecting Tools → Code Server, changing thevalue previously entered and selecting Apply.



17.P

ristine

Installatio

ns

The exception is if you want to move the code server object to anew location:


2. Select the object you want to edit from the Code ServerCreated list and click Edit.

3. Enter a new path in the New Destination Path text box.

4. Click Apply. A check is performed to ensure the paths you haveentered are valid and that there is enough room for the operatingsystem image in the destination folder. If there is, the code serverobject will be moved to the location identified in NewDestination Path.

5. Click OK to return to the Pristine tool main menu.

Deleting a Code Server ObjectTo delete a code server object perform the following steps:


2. Select the object you want to delete from the Code Servercreated list and click Delete → Apply. A confirmation dialog boxappears. Click Yes. The object is deleted.

3. Click OK to return to the main menu.

Step 3: Adding System Files to Code Server ObjectsFor each code server object you will need to add certain systemfiles. In the examples below, the code server object folder (asentered in the Destination path field in step 4 on page 524) is shownas C:\CID. If you have used a different folder you should substituteyour folder name. If you have more than one code server object youshould apply the commands to each one (except THINSRV, whichyou run just once with a configuration file modified to refer to allcode server objects).

Before commencing, create a folder called log within each codeserver object folder.


526 Version 4.1

THINSRVTHINSRV is an MPTS utility that extracts the necessary code serverfiles, verifies supplied parameters, copies the necessary files to thetarget. In addition, it updates the config.sys and startup.cmd files onthe code server workstation to automatically start the code server atsystem startup.

To use the THINSRV program, perform the following steps:

1. Create the following directory: c:\cid\rsp\srvifs.

2. Before starting THINSRV, create the THINSRV configurationfile, called default.ini, in the c:\cid\rsp\srvifs directory. Anexample of this file is shown below:Name = MHOLT1GroupName = NOAdapter = 0MaxClients = 50MaxFiles = 100ClientWorkers = 12Path = c:\cidPermitWrite = NOPerClient = NO;alias = ReadWrite,single,log,c:\cid\log

Note: The folder in the Path statement is the folder where yourcode server object has been created. If you have morethan one code server object you should add aliases for theother code server objects and their log folders to thebottom of this file.

3. Enter the following command in the command line:thinsrv /r:c:\cid\rsp\srvifs\default.ini /t:c:\srvifs/s:c:\cid\img\srvifs /tu:c:\ /l1:c:\cid\log\thinsrv.log

This command copies the necessary code server files into thec:\srvifs directory. It also creates a valid default.ini file based onthe response file named in the /r parameter.

Note: The two characters after the slash at the beginning of thethird line of the command as shown here are ell one.

Pristine Installations on OS/2: Adding System Files


17.P

ristine

Installatio

ns

4. If you are using OS/2 Version 4.5, you must add the followinglines to c:\startup.cmd:cd srvifsservice.exe /INI:default

Configuring MPTS for Non-standard Network AdaptersIf a client system is using a network adapter that is unsupported byMPTS, for each created code server object you must update theMACS.ZIP file located in the C:\CID\IMG\MPTS\IBMCOM\MACSfolder. To do this, perform the following steps:

1. Create a temporary directory in the root of the Code Server. Inthis example it is ‘macstemp’.

2. From within the macs folder, enter the following in the commandline:pkunzip2 -d macs.zip c:\macstemp

The contents of the MACS.ZIP archive are now unpacked toc:\macstemp. A number of subdirectories are now present underc:\macstemp.

3. Open c:\macstemp\ibmcom\macs and copy all the files requiredfor your network adapter into this folder.

4. Rebuild a new MACS.ZIP archive by entering the following:pkzip2 -rp macs.zip c:\macstemp\*.*

5. Copy the new MACS.ZIP archive back intoC:\CID\IMG\MPTS\IBMCOM\MACS folder, overwriting the oldarchive.

GETREXXREXX is required on the code server to run the LCU REXXcommand files used to install the requested products. Because theclient workstation accesses the LCU command files from aredirected drive, it makes sense to access the required files forREXX from the code server. In this way, the required REXXmodules do not have to be on the original boot diskettes.


528 Version 4.1

GETREXX enables the REXX modules to be copied from the OS/2images to the code server executable directory and it is executedfrom the command line when you enter the following command:c:\cid\img\locinstu\getrexx c:\cid\img\os2image c:\cid\exe

Step 4: Creating and Maintaining Code Server ObjectConfigurations

For every code server object created you must create at least oneconfiguration, which tells the pristine installation process how toconfigure the new operating system. The following actions arepossible:¶ “Customizing the Operating System Response File”¶ “Customizing the Additional Required Software Response Files”

on page 531¶ “Adding Device Drivers” on page 531¶ “Partitioning the Client Hard Disk” on page 531¶ “Defining a Reference Model” on page 532¶ “Adding Configuration-specific Information” on page 532

Customizing the Operating System Response FileThe pristine tool provides you with an easy way to customize theresponse files that determine how the operating system will beinstalled. The default response files are located in the Pristine tool’sRSP subdirectory. These files can be edited using a text editor if youwant to change the default values offered in the tool.

1. From the Pristine tool main dialog, see the list of available codeserver objects by double-clicking the platform name. Select theobject you want to configure.

2. Select File → New Configuration. The Pristine Configurationdialog is displayed.

3. Enter a name for the configuration and click OK. TheConfiguration dialog is displayed. This dialog lets you customizethe operating system response file. The left panel lists all of thesections in the response file. Select a section and its installationkeys and their default values are displayed in the right panel.Full details of the sections and keys and their meaning should befound in the documentation for the operating system.



17.P

ristine

Installatio

ns

Note: To select a section you are recommended to double-clickon the section name; a single click may be sufficient, buton certain platforms the Java code that controls the userinterface does not always respond to a single click

4. To change the value of an installation key:

¶ Select a section.

¶ Double-click on the key for which the value is to bechanged. The Installation Key dialog is displayed.

¶ Edit the displayed value.

¶ Click OK to return to the Configuration dialog.

5. To add, remove or rename installation keys, do the following:

a. Select a section.

b. Select an installation key (you do not have to do this if youare only adding a new key).

c. Select Edit Key → Key → New, Delete or Rename

d. The appropriate dialog will be displayed allowing you to add,delete or rename the key, as appropriate.

e. Click OK to save the settings you have made and to return tothe Configuration dialog.

Note: While for many of the keys you can use their factorydefaults, your attention is particularly drawn to the keysfor the installation path, the gateway port and the endpointport which must be completed for the operating systemand for the additional required software.

6. To add, remove or rename installation section names, do thefollowing:

a. Select the section (you do not have to do this if you are onlyadding a new section).

b. Select Edit Key → Section → New, Delete or Rename.

7. Click OK to save the settings you have made and to return to theMain dialog.

Pristine Installations on OS/2: Configurations

530 Version 4.1

Customizing the Additional Required Software ResponseFiles

From the Configuration dialog click on the No Product pull-downand select one of the additional required software items. Theresponse file sections and keys for this product will be displayed andcan be customized as described for the operating system responsefile, above.

Repeat this action for each of the items in the pull-down.

Adding Device DriversFor OS/2, device drivers are not added using the Pristine tool.Instead you have already added them in Step 3: see “ConfiguringMPTS for Non-standard Network Adapters” on page 528.

Partitioning the Client Hard DiskYou must define the partitions on the hard disks of the pristinesystem. Up to two hard disks can be partitioned. The steps are asfollows:

1. Select Configuration → Prepare hard disk. The DiskPartitioning dialog is displayed: There are tabs for each of twophysical volumes. On the first volume there is a defaultdefinition of a primary partition, with the drive letter C, of 2000megabytes.

2. To change the primary partition size click on Size and change thevalue.

3. To add a partition, click Add,. A new partition is created, with adefault size of 2000 megabytes, using the next available driveletter. The Partition type defaults to Logical, but can be changedby clicking on the Partition type of the partition in question. Thetotal of all partitions created is shown in the box at bottom right.To change the partition size click on Size and change the value.

4. Click OK to save the partitioning details and return to theConfigurations dialog.

Remove a partition by selecting the partition and clicking Removeand then OK.



17.P

ristine

Installatio

ns

Defining a Reference ModelIn order to use Change Control Management on the pristine systemyou are given the option of defining a reference model. The stepsare as follows:

1. Select Configuration → Reference Model. The Reference Modeldialog is displayed:

2. Enter the reference model name and/or version.

3. Click OK to save the reference model definition and return tothe Configurations dialog.

Remove a reference model definition by clicking Remove and thenOK.

Adding Configuration-specific InformationConfiguration-specific information can be added to the configuration.The steps are as follows:

1. Select Configuration → Information. The Information dialog isdisplayed.

2. Enter the required information.

3. Click OK to save the information and return to theConfigurations dialog.

Step 5: Preparing the System DiskettesTo prepare the system diskettes you need to use the OS/2 systemutilities SEDISK, THINLAPS, THINIFS and CASINSTL. In theexamples below, the code server object folder (as entered in theDestination path field in step 4 on page 524) is shown as c:\cid. Ifyou have used a different folder you should substitute your foldername.

SEDISKSEDISK is an OS/2 utility that creates the system diskettes forstarting the pristine system. By default, the diskettes have no LANtransport drivers or redirector code; these are added at a later stage.

The SEDISK tool requires three formatted diskettes.


532 Version 4.1

To use SEDISK, perform the following steps:

1. In the directory where the SEDISK utility is located, launchSEDISK by entering the following:SEDISK /S:<source path> /T:<target drive>

/S: Fully qualified source path to the OS/2 disk images,which can be on a local hard drive or a redirected drive.

/T: Target drive (usually the A: drive).

2. Here is an example of how you use SEDISK to create a startdisk:sedisk /s:c:\cid\img\os2image /t:A:

This command launches SEDISK and creates three start diskettesusing the OS/2 disk image in c:\cid\img\os2image.

Adding the LAN Transport Driver with THINLAPSYou must add the appropriate network driver files to the startdiskette. For this procedure, use THINLAPS:

1. From the three floppy disks you have created, insert the thirddiskette into the drive and enter the following command:thinlaps c:\cid\img\mpts A: <drivername>.nif

Where <drivername>.nif is the filename that corresponds to thenetwork adapter driver file that is stored on the target.

2. When asked for another disk, insert the second diskette (from theset of three) into the floppy drive.

THINIFS and SRVIFSTHINIFS is an OS/2 utility that places all the necessary SRVIFSredirection files on the LAN transport diskette. SRVIFS is a smallNetBIOS-based file server and requestor, which is shipped withMPTS. SRVIFS provides redirected I/O support to enable clientaccess to a Code Server. This is a subset of the function provided bythe LAN Server. Run THINIFS by doing the following:

Pristine Installations on OS/2: System Diskettes


17.P

ristine

Installatio

ns

1. From the set of three disks, insert the third disk you created intothe drive and enter the following command from the commandprompt:thinfs /s:c:\cid\img\srvifs /t:A:\/srv:<code server name> /req:<pristine system name> /D:X /tu:A:\

When requested insert the second diskette.

This provides the pristine system with the necessary informationto connect to default directory on the code server. If you have adifferent directory you should modify the command accordingly.

2. Ensure that the LOG directory is read/write enabled, insert thethird system diskette and enter the following to create anassociation between c:\cid\log and the client write drive:thinfs /s:c:\cid\img\srvifs /t:A:\/srv:\\<code server name>\log/req:<pristine system name> /D:Y /tu:A:\

Adding the LAN CID UtilityThe LAN Configuration Installation and Distribution Utility (LCU),which is integrated with MPTS, enables you to chain together aseries of CID installs. For example, an end user may require OS/2,MPTS, and LAN Server V5.0 to be installed. Once configured, thisutility automatically installs all of these programs in one step.

CASINSTLThis utility installs the LAN CID Utility on the system diskettes andis available from c:\cid\img\locinstu.

To execute the CASINSTL program, insert the third system disketteand enter the following statement in the command line:casinstl /tu:A:\ /cmd:X:\clients\<configuration name> /D/l2:Y:\srvifs_req.log /pa:X:\img\locinstu /pl:X:\exe;X:\img\locinstu; /0/req:<pristine system name>

Step 6: Creating Pristine Boot DiskettesWhen you have created at least one configuration for a code serverobject (see “Step 4: Creating and Maintaining Code Server ObjectConfigurations” on page 529) and have prepared a set of systemdiskettes (see “Step 5: Preparing the System Diskettes” on page 532),

Pristine Installations on OS/2: System Diskettes

534 Version 4.1

you can use the Pristine tool to transform the prepared systemdiskettes into a set of pristine boot diskettes.

Note: This procedure, while being an essential step in thepreparation for a pristine installation, may not need to updatethe system diskettes to create boot diskettes; thus, althoughyou should have the system diskettes available you may notbe asked to insert them.

1. Ensure you are logged on to the LAN by issuing the followingcommands to start the LAN requester service:

¶ For OS/2, Version 4.0 type:net share

¶ For OS/2, Version 4.5 type:logon root /P:passwd /V:LOCAL

2. From the toolbar, click Tools → Create Boot Diskettes. TheCreate Boot Diskettes dialog is displayed.

3. If requested, place one of the diskettes you created in “Step 5:Preparing the System Diskettes” on page 532, into the diskettedrive.

4. Complete the following fields:

Server name Hostname of the code server

Client boot drive Drive letter of the drive fromwhich the pristine system willnormally boot up

Client source drive Drive letter of the drive to whichthe shared code server folder willbe mapped

Client log drive Drive letter of the drive to whichthe code server log will bemapped

These value should correspond to those supplied in the aboveutilities.

Pristine Installations on OS/2: Boot Diskettes


17.P

ristine

Installatio

ns

5. Click OK. The Pristine tool completes the preparation of thecode server object configuration, and, if necessary, writes dataalso to the system diskette.

Step 7: Running a Pristine InstallationWhen you have completed the preparation of the set of pristine bootdiskettes for a system or group of systems (see “Step 6: CreatingPristine Boot Diskettes” on page 534), you can commence a pristineinstallation. The installation procedure carries out the followingoperations:

¶ It uses the boot diskettes to start up the pristine system and loada minimum system configuration into memory

¶ It installs the necessary protocols to connect itself into thenetwork and to locate the code server

¶ Using the configuration information it partitions the hard disksand commences to download and install the operating systemsoftware, using the response file to drive the installation

¶ Each system, or group of systems is assigned to a dedicatedTivoli gateway

¶ If the Code Server Object configuration contains a ReferenceModel, and on the gateway a specific Login-Policy has beenactivated, a CCM operation will be started

When these activities are completed, the new endpoint must bemigrated from the dedicated pristine gateway to a normal gateway.

Pristine Installation ProcedureAt least one person must be present where the pristine systems arelocated. The tasks executed locally are:

¶ Starting the system

¶ Removing the diskettes when necessary

¶ Restarting the system if required

Once the diskettes are ready and delivered to the person performingthe local installation, the installation process can begin.

Pristine Installations on OS/2: Boot Diskettes

536 Version 4.1

When the first Tivoli management agent login is connected, anautomatic notification of the presence of a new machine in the Tivolimanagement region takes place.

If you have defined a reference model you should ensure that theCCM component of Tivoli Software Distribution is activated, inorder to compare the new system to the appropriate reference modeland to start the specific action. This action completes the pristineinstallation process.

Note: If you want to use a reference model to install TivoliSoftware Distribution, you should remember to install anyprerequisite software.

The final step is for the pristine system administrator, who must,after all installation processes are completed, migrate the newendpoint from the dedicated pristine gateway to a normal gateway.

Pristine Installations on OS/2: Running Installation


17.P

ristine

Installatio

ns

538 Version 4.1

Upgrading Windows NT 4.0Workstation to Windows 2000Professional

This scenario explains how to use Tivoli Software Distribution,Version 4.1 to upgrade software from Windows NT 4.0 Workstationto Windows 2000 Professional.

This scenario consists of the following procedures:

¶ Creating the response file appropriate for your environment

¶ Copying the files that you need to perform the migration to theTivoli management region server (Tivoli server)

¶ Copying the Windows 2000 files to the image server

¶ Customizing the inst_w2000.spd software package definition file

¶ Creating the software package on the Tivoli server

¶ Subscribing the endpoints to the upgrades profile manager

¶ Distributing the software package to the Tivoli endpoints

¶ Using the check_OS^1.0.spd software package definition file toverify the upgrade

Environment ConfigurationTo complete this scenario, you must have the following environment:

18


18.U

pg

radin

gW

ind

ow

sN

T4.0

toW

ind

ow

s2000

¶ A Windows 2000 Professional workstation with the Resource Kit2000 installed.

¶ A Tivoli 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.1 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=1

Upgrading Windows NT 4.0

540 Version 4.1

AutoLogon=Yes

[UserData]FullName=AdministratorOrgName=WORKGROUPComputerName=*

[Identification]JoinWorkgroup=WORKGROUP

[Networking]InstallDefaultComponents=Yes

Copying the Files That You Need to Perform theMigration to the Tivoli 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.1 CD-ROMto the Tivoli server.

¶ inst_w2000.spd

¶ Unattended.txt

Note: You can use the response file that you created in“Creating a Response File” on page 540 instead of thisfile.

¶ check.bat

¶ check_OS.spd

To copy these files from the CD-ROM to the Tivoli Server, performthe following steps on the Tivoli server:

1. Create a directory in which to store the files. This scenario usesthe upgnt_00 directory.

2. Copy the inst_w2000.spd, the Unattended.txt, the check_OS.spdand the check.bat files:

¶ For UNIX, copy the files from theCD-ROM_drive/package/msosupg/upgrNTtoW2000 directoryto the /upgnt_00 directory on your Tivoli server by enteringthe following commands from the /upgnt_00 directory:



18.U

pg

radin

gW

ind

ow

sN

T4.0

toW

ind

ow

s2000

cp <CD-ROM_drive>/package/msosupg/upgrNTtoW2000/inst_w2000.spd .

cp <CD-ROM_drive>/package/msosupg/upgrNTtoW2000/Unattended.txt .

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 the <CD-ROM_drive>:\package\msosupg\upgrNTtoW2000 directory tothe <drive>\upgnt_00 directory on your Tivoli 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

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.

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 Workstation toWindows 2000 Professional by entering the following command:net share shared=c:\shared


542 Version 4.1

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 540 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:”TIVOLI Software Package v4.1 - 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



18.U

pg

radin

gW

ind

ow

sN

T4.0

toW

ind

ow

s2000


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

Creating the Software Package on the Tivoli ServerBefore creating a software package, you must create on the Tivoliserver a profile manager that contains the software package and adirectory path in which to store the software package block. Refer tothe Tivoli Management Framework User’s Guide to learn how tocreate a profile manager. This scenario assumes that you created theupgrades profile manager and the packages directory path in whichto store the inst_w2000.spb software package block in the Tivoliserver. To create and build the software package on the Tivoli server,enter the following command:

¶ In a UNIX environment:wimpspo -c @upgrades -f /upgnt_00/inst_w2000.spd -t build -p

/packages/inst_w2000.spb @inst_w2000^1.0


544 Version 4.1

¶ 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

This command does the following:

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

Subscribing the Endpoints to the Upgrades ProfileManager

Subscribe the Tivoli Software Distribution endpoints to the upgradesprofile manager by entering the following command from the Tivoliserver:wsub @upgrades @Endpoint:target1 @Endpoint:target2 ... @Endpoint:targetn

Where target1, target2, ..., targetn are the Tivoli SoftwareDistribution endpoints that you want to subscribe.

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 Tivoliserver:

¶ 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 in



18.U

pg

radin

gW

ind

ow

sN

T4.0

toW

ind

ow

s2000

the 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

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.

Using the check_OS^1.0.spd to Verify the UpgradeUsing the check_OS^1.0.spd you 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 theTivoli 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 Tivoli server:

¶ In a UNIX environment:winstsp @check_OS^1.0 @target1 @target2 ... @targetn

¶ In a Windows environment:winstsp @check_OS^^1.0 @target1 @target2 ... @targetn

Where target1, target2, ..., targetn are the Tivoli 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:


546 Version 4.1

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.



18.U

pg

radin

gW

ind

ow

sN

T4.0

toW

ind

ow

s2000


548 Version 4.1

Upgrading Windows NT 4.0 withService Pack 5 or 6

This scenario explains how to use Tivoli Software Distribution,Version 4.1 to upgrade a Windows NT 4.0 system to Service Pack 5or Service Pack 6.

This scenario consists of the following procedures:

¶ Downloading the ntspx.spd definition file to the Tivolimanagement region server (Tivoli server)

¶ Copying the Service Pack files to the image server

¶ Customizing the ntspx.spd software package definition File

¶ Creating the software package on the Tivoli server

¶ Subscribing the endpoints to the upgrades profile manager

¶ Distributing the software package to the Tivoli SoftwareDistribution endpoints

Environment ConfigurationTo complete this scenario, you must have the following environment:

¶ A Tivoli 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.

19


19.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 theTivoli 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.1 CD-ROM. To download thentspx.spd definition file from the CD-ROM to the Tivoli server,perform the following steps on the Tivoli server:

1. Create a directory in which to store the ntspx.spd definition file,for example the servpackx directory.

2. Copy the file:

¶ For UNIX, copy the file fromCD-ROM_drive/package/msosupg/nt40srvpack directory tothe /servpackx directory on your Tivoli server, by enteringthe following 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 Tivoli 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 Tivoli server.

Upgrading Windows NT with a Service Pack

550 Version 4.1

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.



19.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.1 - SPDF"package

Name = "ntspx"Title = "Install Service Pack for Windows NT 4.0"Copyright = "Tivoli Software Distribution Systems"Version = "1.0"web_view_mode = "hidden"undoable = “o”committable = “o”history_reset = nsave_default_variables =ncreation_time = “2001-02-02 18:10:19”last_modification_time = “2001-02-02 128:14:08”default_variables

sp_path = “\\ImageServer\shared”end

move_removing_host =yno_check_source_host =ylenient_distribution = ndefault_operation = “install”server_mode = “all”operation_mode = "not_transactional"log_mode = “0”log_user_id 0post_notice = nbefore_as_uid =0skip_non_zero = nafter_as_uid = 0no_chk_on_rm = nlog_gid = 0versioning_type = "swd"package_type = "refresh"stop_on_failure = y


during_install

exit codes


552 Version 4.1

success = 0,0failure = 1,65535end

path = ”$(sp_path)\spx\update\update.exe”arguments = “-u -f -o -q”

timeout = 2400unix_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

corequisite_filesend

endend

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.



19.U

pg

radin

gW

ind

ow

sN

Tw

itha

Service

Pack

Creating the Software Package on the Tivoli ServerBefore creating a software package, you must create on the Tivoliserver a profile manager that contains the software package and adirectory path in which to store the software package block. Refer tothe Tivoli Management Framework Planning and Deployment Guideto learn how to create a profile manager. This scenario assumes thatyou created the upgrades profile manager and the packages directorypath in which to store the ntspx.spb software package block in theTivoli server.

To create and build the software package on the Tivoli 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 -p

c:\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 Tivoliserver:wsub @upgrades @Endpoint:target1 @Endpoint:target2 ... @Endpoint:targetn

Where target1, target2, ..., targetn are the Tivoli SoftwareDistribution endpoints that you want to subscribe.


554 Version 4.1

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 Tivoliserver:

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



19.U

pg

radin

gW

ind

ow

sN

Tw

itha

Service

Pack

556 Version 4.1

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


Delete a softwarepackage profile

Software package senior or super

View/modify a softwarepackage profile (usingthe Software PackageEditor)


Authorization Roles

558 Version 4.1

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


Performing Activity Planner OperationsThe following table lists the role required to perform ActivityPlanner operations:


Import an activity planinto the activity plandatabase

Activity plans APM_Edit

Delete an activity planfrom the activity plandatabase

Activity plans

Authorization Roles


A.

Au

tho

rization

Ro

les


Submit an activity planfor execution

Activity plans APM_Manage

Cancel, pause, resume,and restart activities orthe activity plan

Activities and activityplans

Clean up submittedactivity plans from theactivity plan database

Activity plans

Remove the status ofactivity plan from theactivity plan database

Activity plans

Return a list of activityplans maintained in theactivity plan database

Activity plans APM_View

Output an activity planin the activity plandefinition file format

Activity plan

Display the status of asubmitted activity plan

Activity plan

Authorization Roles

560 Version 4.1


Display current errorlevel mapping

Activity plan APM_Admin

Map error levels toreturn codes

Activity plans

Delete mapping of errorlevels and reset defaultvalues

Activity plans

Display a list of lockedplans and unlock planscurrently locked

Activity plans

Start and stop ActivityPlanner engine

Activity Planner feature

Display and change theRIM object name


Change the userpassword that enablesthe Activity Plannerengine to functionproperly


Authorization Roles


A.

Au

tho

rization

Ro

les

Performing CCM OperationsThe following table lists the role required to perform CCMoperations:


Load a reference model Reference model CCM_View

Import a referencemodel

Reference model

Export a referencemodel

Reference model

View the componentproperties of areference model

Reference model

Search for a referencemodel

Reference model

Lock the children of areference model

Reference model

Hide the children of areference model

Reference model

Arrange the childreference modelshorizontally orvertically

Reference model

Preview the actions Reference model

Access help Change ConfigurationManagement GUI

Access productinformation

Change ConfigurationManagement GUI

Authorization Roles

562 Version 4.1


Save the changes toreference models

reference model CCM_Manage

Restore the referencemodels from thedatabase

reference model

Add a new element,subscriber, ordependency

reference model

Modify a new element,subscriber, ordependency

reference model

Remove an element,subscriber, ordependency

reference model

Add a new referencemodel

reference model

Remove a referencemodel

reference model

All operations with theCCM_Manage role

reference model CCM_Edit

Submit an activity plan activity plan

Performing Web Interface OperationsThe following table lists the role required to perform Web Interfaceoperations:

Authorization Roles


A.

Au

tho

rization

Ro

les

Task Context Role

Starting and stopping the Webserver

Administrator resource senior, super, orSDhttpd_Control

Retrieving and setting the portnumber

Retrieving and setting usersor groups of users

Retrieving and setting thedepot location

Creating administrators andadding users


Setting the policy regionattribute


Setting the web_view_modeattribute

Software package profile senior

Setting theSDWebUI_displaynameattribute


Authorization Roles

564 Version 4.1

Glossary

A

accept operationIn Tivoli Software Distribution, Version 4, a change management operation thatdeletes the backup package so the previous operation can no longer be undone.

actionAn operation on a managed object, the semantics of which are defined as part of themanaged object class definition.

action bodyIn the Tivoli Enterprise Console product, the part of a rule that contains actions totake if the rule evaluates to true.

activityIn Tivoli Software Distribution, Version 4.1, an operation that is contained in anactivity plan; operations can include Tivoli Software Distribution operations andTivoli Management Framework task library tasks. Activity definitions include: theoperation to be performed, the execution time, the conditions for executing theoperation, and the targets of the operation. See activity plan and execution time.

activity planIn Tivoli Software Distribution, Version 4.1, a set of activities performed on a set oftargets on a specified schedule. An activity plan specifies: the activities contained inthe plan, the schedule for execution, recursion information, notification information,and targets. See also activity.

Activity Plan EditorIn Tivoli Software Distribution, Version 4.1, the tool, which has a graphical userinterface, that is used to generate or update an activity plan. See also activity plan.

Activity Plan MonitorIn Tivoli Software Distribution, Version 4.1, the tool, which has a graphical userinterface, that is used to submit, monitor, and control the execution of an activityplan. See also activity plan.

admin roleSee authorization role.

administratorSee Tivoli administrator.


Glo

ssary

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.

authorization(1) In computer security, the right granted to a user to communicate with or makeuse of a computer system. (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.

AutoPackIn Tivoli Software Distribution, Version 4, a tool that enables a Tivoli administratorto create a software package. AutoPack produces the software package by (a) takingsnapshots of the drive and system configuration before and after the installation ofan application on a PC and (b) capturing the differences between these snapshots inthe software package.

C

change managementIn Tivoli Software Distribution, the process of planning (for example, scheduling)and controlling (for example, distributing, installing, and tracking) software changesover a network.

566 Version 4.1

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

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 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, Version 4, a change management operation thatcauses all the updates prepared in the preparation phase to take effect.

commit phaseIn Tivoli Software Distribution, Version 4, the phase of transactional mode operationin which previously prepared actions are committed, causing all of the updates totake effect. See also transactional mode.

configuration repositoryIn a Tivoli environment, a RIM repository that contains information that is collectedor generated and stored by Tivoli Inventory and Tivoli Software Distribution. Forexample, Tivoli Inventory stores information regarding hardware, software, systemconfiguration, and physical inventory; and Tivoli Software Distribution storesinformation regarding software package and file package operations.

CRCSee cyclic redudancy check (CRC).


Glo

ssary

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.

differencing phaseIn Tivoli Software Distribution, Version 4, the process by which AutoPack examinesand compares before and after snapshots and, for each difference found, generatesthe related action and adds it to a software package.

disconnected modeIn Tivoli SecureWay Global Sign-On, a method of operation that enables users tolog on to targets while not connected to a network, such as from laptops whilemobile.

disconnected target commandIn Tivoli Software Distribution, Version 4, a command that is run from thecommand line of a target system that is not connected to the Tivoli managementregion server.

discovered software packageIn Tivoli Software Distribution, Version 4.1, an application that was installed on anendpoint independently of Tivoli Software Distribution and that was later added tothe endpoint’s catalog and given a status of “installed and discovered,” using aTivoli Software Distribution disconnected target command.

Distributed Monitoring proxySee endpoint.

568 Version 4.1

Distribution Status consoleAn MDist 2 interface provided by Tivoli Management Framework that enablesadministrators to monitor and control distributions across a network. See also MDist2.

domainThat part of a computer network in which the data processing resources are undercommon control.

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.

endpoint methodIn a Tivoli environment, a method that runs on an endpoint client as the result of arequest from other managed resources in the Tivoli management region. Results ofthe method are forwarded first to the gateway, then to the calling managed resource.


Glo

ssary

event adapterIn a Tivoli environment, software that converts events into a format that the TivoliEnterprise Console product can use, and forwards the events to the event server.Using the Tivoli Event Integration Facility, an organization can develop its ownevent adapters, tailored to its network environment and specific needs.

event cardIn Tivoli NetView, a graphical representation, resembling a card, of the informationcontained in an event sent by an agent to a manager reflecting a change in the statusof one of the agent’s managed nodes.

event consoleIn the Tivoli Enterprise Console product, a graphical user interface (GUI) thatenables system administrators to view and respond to dispatched events from theevent server. The Tivoli Event Integration Facility does not directly use or affectevent consoles.

event serverIn the Tivoli Enterprise Console product, a central server that processes events. Theevent server creates an entry for each incoming event and evaluates the eventagainst a rule base to determine whether it can respond to or modify the eventautomatically. The event server also updates the event consoles with the currentevent information. If the primary event server is not available, events can be sent toa secondary event server.

execution timeIn Tivoli Software Distribution, Version 4.1, the time frame within which an activitymust be executed. Time frame specifications include the days of the week and timeintervals within a day.

F

fanoutIn communication, the process of creating copies of a distribution to be deliveredlocally or to be sent through the network.

file packageIn Tivoli Software Distribution, Version 3, a profile. The file package describeswhich files and directories to distribute and how to distribute them.

file package blockIn Tivoli Software Distribution, Version 3, a static file containing (a) the filepackage definition, (b) the file package attributes, (c) the source files anddirectories, and (d) the configuration programs of the file package.

570 Version 4.1

file package definitionIn Tivoli Software Distribution, Version 3, an ASCII file that identifies the contentsand characteristics of a file package.

fpblockSee file package block.

G

gatewayIn a Tivoli environment, software running on a managed node that provides allcommunication services between a group of endpoints and the rest of the Tivolienvironment. This gateway includes the multiplexed distribution (MDist) function,enabling it to act as the fanout point for distributions to many endpoints.

generic collectionIn a Tivoli environment, a collection that contains objects representing resources ofany type.

group ID (GID)In the AIX operating system, a number that corresponds to a specific group name.The group ID can often be substituted in commands that take a group name as avalue.

group profileIn Tivoli User Administration, a profile that a Tivoli administrator uses to defineand modify information about a group of users.

H

hostIn a Tivoli environment, a computer that serves as a managed node for a profiledistribution.

I

install imageSee Tivoli install image.

install operationIn Tivoli Software Distribution, Version 4, a change management operation thatinstalls a software package on a selected group of targets.

installation repository (IR)In Tivoli Software Installation Service (SIS), the directory that contains reusableinstallation images and other data that is used by SIS.


Glo

ssary

IPX AgentIn a Tivoli environment, a PC agent that runs on IPX/SPX. An IPX Agent can bethe client only of a NetWare-managed site.

IRSee installation repository.

J

jobIn a Tivoli environment, a resource consisting of a task and its pre-configuredexecution parameters. Among other things, the execution parameters specify the setof hosts on which the job is to execute.

L

local distributionIn a Tivoli environment, a distribution to target machines in the same Tivolimanagement region as the source machine.

local overrideIn 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 nodeIn a Tivoli environment, any managed resource on which the Tivoli ManagementFramework is installed.

managed object(1) A component of a system that can be managed by a management application. (2)The systems management view of a resource that can be managed through the 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.

572 Version 4.1

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.

management regionIn Tivoli NetView, the set of managed objects on a particular map that defines theextent of the network that is being actively managed. The management region mayvary across maps.

MDistA multiplexed distribution service provided by Tivoli Management Framework thatenables efficient transfer of data to multiple targets. See also MDist 2.

MDist 2A multiplexed distribution service provided by Tivoli Management Framework thatenables efficient transfer of data to multiple targets. In addition in the featuresprovided by MDist, MDist2 provides features for monitoring and controlling adistribution throughout its life cycle. See also Distribution status console and MDist.

methodIn object-oriented design or programming, the software that implements thebehavior specified by an operation.

Migration Control CenterIn Tivoli Software Distribution, Version 4.1, the tool, which has a graphical userinterface, that enables system administrators to migrate from the Tivoli NetViewDistribution Manager family of products to Tivoli Software Distribution, Version4.1. The Migration Control Center migrates, for example, change files to softwarepackage blocks, procedures to tasks in a task library, and authorization profiles toadministrators.

multiplexed distribution (MDist)The mechanism used by Tivoli Enterprise applications to transfer data to multipletargets. Tivoli Management Framework provides two multiplexed distributionservices, MDist and MDist 2. See alsoMDist and MDist 2.

N

name registryIn a Tivoli environment, a name service consisting of a two-dimensional table thatmaps resource names to resource identifiers and corresponding information within aTivoli management region.

nested software packageIn Tivoli Software Distribution, Version 4, a software package that is added as anentry to another file package.


Glo

ssary

NetViewSee Tivoli NetView and Tivoli NetView for OS/390.

NetWare managed siteIn a Tivoli environment, a resource that represents (a) a Novell NetWare server onwhich the Tivoli NetWare repeater is installed and (b) one or more clients. ANetWare managed site enables profiles to be distributed through the NetWare serverto one or more specified client PCs using either TCP/IP or IPX.

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

objectIn a Tivoli environment, an item that a user can manipulate as a single unit toperform a task. An object can appear as text, an icon, or both.

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. oserv runson the Tivoli management region server and each Tivoli management region client.

574 Version 4.1

P

Plus moduleSee Tivoli Plus module.

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 (region) is created, a policy region withthe same name is also created. In this case, the region has only one policy region.However, in most cases, a Tivoli administrator creates other policy regions andsubregions to represent the organization of the region. A region addresses thephysical connectivity of resources whereas a policy region addresses the logicalorganization of 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.

populateIn a Tivoli environment, to fill a profile with information that is to be distributed tothe subscribing managed resources.

preparation phaseIn Tivoli Software Distribution, Version 4, the phase of transactional mode operationin which each action in a software package prepares the conditions for thesuccessful execution of an install or remove operation. If the preparation phase fails,the target system is returned to its original, stable state. See also transactional mode.

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.


Glo

ssary

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 toorganize and distribute profiles. A profile manager is created in the context of apolicy region and is a managed resource in a policy region. A profile manager canoperate in one of the following two modes: Dataless mode, which enables a profilemanager to distribute to any Tivoli client (including managed nodes, endpoints, PCmanaged nodes, and NetWare managed 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.

proxy endpointIn Tivoli Distributed Monitoring, a representation of an entity (such as a networkdevice or a host) that functions as a subscriber for Tivoli Distributed Monitoringprofiles. A Tivoli administrator associates each proxy endpoint with a managednode; several proxy endpoints can be associated with a single managed node.

proxy managed nodeIn a Tivoli environment, a managed resource that provides communication betweenthe Tivoli management region server and a PC that is running the PC agent.

Q

query facilityIn a Tivoli environment, a facility that provides SQL functions for accessinginformation in a RIM repository.

query libraryIn a Tivoli environment, a facility that provides a way to create and manage Tivoliqueries.

R

RDBMS Interface Module (RIM)In the Tivoli Management Framework, the module in the distributed object databasethat contains information about the installation of the relational databasemanagement system (RDBMS).

576 Version 4.1

reference modelIn the context of Tivoli software, the model configuration for a system or set ofsystems that is used to maintain consistent configurations in a distributedenvironment. In Tivoli Inventory, reference models are created in the configurationrepository.

registered nameIn a Tivoli environment, the name by which a particular resource is registered withthe name registry when it is created.

remote distributionIn a Tivoli environment, a distribution to target machines in a connected Tivolimanagement region.

repeater rangeIn a Tivoli environment, the Tivoli clients that receive data from the repeater site.

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.

resourceIn a Tivoli environment, an entity, such as a device, a database, or a softwarepackage. Contrast with managed resource.

resource roleIn a Tivoli environment, the role an administrator has over specific resources in thelocal Tivoli management region (region) and any connected region (for example,policy regions or the Administrator collection).

resource typeIn a Tivoli environment, one of the properties of a managed resource. Resourcetypes are defined in the default policy for a policy region.

RIMSee RDBMS Interface Module.

RIM hostIn a Tivoli environment, the managed node from which a Tivoli administrator runsthe database client software and from which the relational database managementsystem (RDBMS) server is contacted.

RIM repositoryIn a Tivoli environment, a relational database that contains information that iscollected or generated by Tivoli applications. Examples of a RIM repository includethe configuration repository and the event repository.


Glo

ssary

root directoryThe highest level directory in a hierarchical file system.

S

send operationIn Tivoli Software Distribution, Version 4.1, a data moving operation that copies adata file from a source host to specified endpoints.

senior roleSee authorization role.

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.

signatureIn Tivoli Software Distribution, Version 4, unique identifying information that formsthe first line in a software package definition file. Tivoli Software Distribution usesthe signature for version checking and for determining what kind of importer to useto read the software package definition file.

SISSee Software Installation Service.

Software Installation Service (SIS)A Tivoli product that provides an easy-to-use, efficient interface for installing TivoliEnterprise software. SIS uses Tivoli’s MDist technology and provides automatedchecking for prerequisite software, a reusable repository of installation images, andboth graphical and command line interfaces for deploying Tivoli products to a largenumber of computers.

software packageIn Tivoli Software Distribution, Version 4, a database object that contains asequential list of actions to be executed on a target system.

software package blockIn Tivoli Software Distribution, Version 4, a file that contains the resources referredto by the actions in a software package.

software package definitionIn Tivoli Software Distribution, Version 4, an ASCII text file used to describepackage contents. It consists of a sequence of stanzas that describe commands to beexecuted. See also stanza.

578 Version 4.1

Software Package EditorIn Tivoli Software Distribution, Version 4, a Java-based tool, with a graphical userinterface, for creating and customizing software packages.

software package objectIn Tivoli Software Distribution, Version 4, a software package that has beenimported into the Tivoli management environment. The software package iscataloged at the Tivoli Software Distribution server as a Tivoli database softwarepackage object. A Tivoli administrator can perform change management operations(such as install, remove, undo, accept, commit, and verify) on software packageobjects.

source hostIn Tivoli Software Distribution, the managed node on which the source files anddirectories referred to in a software package reside.

stanzaIn Tivoli Software Distribution, Version 4, a section of a software packagedefinition. A stanza may define, for example, an action to be performed; a list oftargets on which the action is to be performed; or a set of conditions under whichan action is to be executed. Stanzas may be nested, and there is a single stanza (theroot stanza) that contains the entire software package definition.

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.

super roleSee authorization role.


Glo

ssary

T

targetIn Tivoli Software Distribution, Version 4, a workstation on which the actionsdefined in a software package are executed. The Tivoli Management Agent must beinstalled on the workstation. See also software package.

task libraryIn a Tivoli environment, a container in which a Tivoli administrator can create andstore tasks and jobs.

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 Tivoli management region client and Tivolimanagement region 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 product.

Tivoli Enterprise ConsoleA 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 productprovides a centralized, global view of the network computing environment; it usesdistributed event monitors to collect information, a central event server to processinformation, and distributed event consoles to present information to systemadministrators.

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 Business System 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 computing

580 Version 4.1

management 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 product.

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.

Tivoli management agentIn a Tivoli environment, an agent that securely performs administrative operations.

Tivoli Management FrameworkThe Tivoli base software that is required to run the applications in the Tivoliproduct suite. This software infrastructure enables the integration of systemsmanagement applications from Tivoli Systems Inc. and the Tivoli Partners. TheTivoli Management Framework includes the following: object request broker(oserv), distributed object database, basic administration functions, basic applicationservices, and basic desktop services (such as the graphical user interface). In aTivoli environment, the Tivoli Management Framework is installed on every clientand server; however, the Tivoli management region server is the only server thatholds the full object database.

Tivoli management gatewayIn a Tivoli environment, a system that enables bidirectional communication withTivoli management agents.


Glo

ssary

Tivoli management region (region)In a Tivoli environment, a Tivoli server and the set of clients that it serves. Anorganization can have more than one region. A region addresses the physicalconnectivity of resources whereas a policy region addresses the logical organizationof resources.

Tivoli management region clientIn a Tivoli environment, any computer—except the Tivoli management region server(Tivoli server)—on which the Tivoli Management Framework is installed. Theoserv daemon runs on the Tivoli management region (region) client, and the regionclient maintains a local object database. See Tivoli client and Tivoli server.

Tivoli management region roleIn a Tivoli environment, the role an administrator has in the local Tivolimanagement region (region) and any connected region. The region role propagatesthe assigned authorization level to all resources in the region. For example, if aTivoli administrator has a senior role in a region, then the administrator has thesenior role over every resource in that region.

Tivoli management region server (Tivoli server)A Tivoli server for a specific Tivoli management region (region). See Tivoli clientand Tivoli management region client.

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 RegistryIn a Tivoli environment, the table that maps names of managed resources toresource identifiers (and corresponding information) within a Tivoli managementregion.

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.

Tivoli NetView for OS/390A Tivoli product that enables centralized systems and network management from anOS/390 environment. Through its MultiSystem Manager component, Tivoli NetView

582 Version 4.1

for OS/390 enables management of distributed resources, such as Internet Protocol(IP) resources, NetWare resources, asynchronous transfer mode (ATM) resources,and others. Contrast with Tivoli NetView.

Tivoli NetWare repeaterIn 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 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.

Tivoli Remote ControlA Tivoli product that enables a Tivoli administrator to control mouse and keyboardoperations on a Windows NT managed node, an endpoint, or a PC managed node. Italso provides file transfer, chat, and reboot functions.

Tivoli SecureWay Security Manager (security manager)The Tivoli product that enables the consistent definition, implementation, andenforcement of security policy in a network computing environment.

Tivoli Security ManagementSee Tivoli SecureWay Security Manager.

Tivoli serverThe server that holds or references the complete set of Tivoli software, including thefull object database. See Tivoli client, Tivoli management region client, and Tivolimanagement region server.

Tivoli Software Distribution Web InterfaceIn Tivoli Software Distribution, Version 4, an interface that enables an end user at aTivoli endpoint to retrieve Tivoli Software Distribution profiles using the TivoliWeb-based interface.

Tivoli upgrade imageIn a Tivoli environment, an image that resides on a CD or in a file system and thatcontains updates for a Tivoli product. A Tivoli upgrade image contains only the filesthat have changed since the previous product release, along with the scripts andcommands that are needed for installing the new files and configuring the database.Contrast with Tivoli install image.

Tivoli UserLinkA Tivoli product that provides IP address synchronization between a PC agent andits associated PC managed node using the Dynamic Host Configuration Protocol


Glo

ssary

(DHCP). Tivoli UserLink also enables a PC user to pull a file package to aWindows, Windows 95, or Windows NT workstation.

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.

transactional modeIn Tivoli Software Distribution, Version 4, a mode of executing install or removeoperations in two phases: the preparation phase and the commit phase. See alsopreparation phase and commit phase.

U

undo operationIn Tivoli Software Distribution, Version 4, a change management operation thatreturns a target system to its state before execution of a previous install or removeoperation.

undoable-in-transactional modeIn Tivoli Software Distribution, Version 4, a variation of transactional mode inwhich disk space for backup copies (required for undoability) is reserved during thepreparation phase, which minimizes the risk of failure attributable to insufficientdisk space during the commit phase.

undoable modeIn Tivoli Software Distribution, Version 4, a mode of operation in which actions canbe rolled back even if they are already committed, because a backup copy is saved.

upgrade imageSee Tivoli upgrade image.

user login mapIn a Tivoli environment, a mapping that associates a single user login name with auser account on a specified operating system. User login maps enable Tivoliadministrators to log in to the Tivoli environment or perform operations within aTivoli environment with a single user login name, regardless of the system that theyare currently using.

user profileIn Tivoli User Administration, a profile that is used to manage user accounts,including account information, home directories, startup files, and groupmembership.

584 Version 4.1

user roleSee authorization role.

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.

verify operationIn Tivoli Software Distribution, Version 4, a change management operation thatverifies the successful execution of the previous operation.


Glo

ssary

586 Version 4.1

Index

Special Characters.ini files

modifying 91OS/2 104Windows 90

Aaccept operation 322actions

adding directories 65, 74adding files 66, 76adding multiple file/directory 78adding OS/2 desktop objects 99adding OS/2 profile objects 104adding text file objects 108adding Windows NT service 95adding Windows profile objects 90adding Windows registry objects 79adding Windows shell objects 85check disk space 62execute CID program 145execute program 116Install MSI Patch 189Install MSI Product 189InstallShield program 146Microsoft Setup Program 149remove actions 150restart 119

activitiesassigining targets 417change management operations 413cloning 417conditioning 423data movement operations 413defining 414depot management operations 413

activities (continued)execution window 427final 428priority 429removing 438sorting 425task 413types 413

activity plan databasedrafts and templates 409saving to 437

activity plan definition file 409Activity Plan Editor 409Activity Plan Monitor 410, 439Activity Planner

creating database tables for 37creating RIM objects for 37GUI component 28server component 26

activity plansauthorization 443canceling 444cleanup 446deleting 446draft 409, 437import 476locked 409name 429pausing 444preview 475recursive 432recursive, interrupting 433removing 438restarting 444resuming 444saving 437status 440submit 476submitting 441


Ind

ex

activity plans (continued)targets 435template 409, 437updating status 445variables 436XML file 409, 438

Add OS400 Library dialog 162Add OS400 Licensed Program dialog 168Add OS400 Object Properties dialog 165adding

command lines 108directories 74directories to OS/400 system 172files 76files to OS/400 system 172inventory element 462lines to text files 108multiple file/directory 78OS/2 desktop folder 99OS/2 desktop program 101OS/2 desktop shadow 103OS/2 profile items 107OS/400 libraries 161OS/400 licensed programs 167OS/400 objects 161SWD element 459tokens 108Windows NT service 95Windows profile objects 90Windows registry objects 79

adding objects to the software package 61adding OS/400 objects 164Administrator, Web Interface 336after build programs 129Apache Web server 354, 360APM_Admin role 412, 561APM_Edit role 412, 559APM_Manage role 412, 560APM_View role 412, 560asynchronous delivery 9attributes

translate 174, 177UNIX 138

authorization roles 411, 557admin 22, 557APM_Admin 561

authorization roles 411, 557 (continued)APM_Edit 559APM_Manage 560APM_View 560CCM_Edit 563CCM_Manage 563CCM_View 562install-product 22, 557SDhttpd_Control 564senior 22, 557super 22, 557user 22, 557

auto reboot mode 132AutoPack

command 201configuration file 204differencing phase 203excluding .INI files 227excluding registry entries 225excluding text files 224file system sections 205first snapshot 221monitoring registry entries 225monitoring text files 223monitoring Windows profiles 226OS/2 desktop 208OS/2 profiles 207OS/2 system files 208preparation machine 201result 234second snapshot 238supported platforms 201, 203system components 203text file sections 206Windows profile sections 207Windows registry sections 207working directory 222

autopack command 218AutoPack Guided Process

automatic installation 235first snapshot 221manual installation 229scenario 217second snapshot 231starting 220

588 Version 4.1

autopack.inicustomizing 209, 222UNIX systems 216Windows 98 214Windows NT, Windows 2000 213

BBAROC file 405base package 300before build programs 129boot diskette

creation for pristine installationOS/2 534Windows 516

for pristine installation 494building the software package

convert operation 294import operation 289save as option 151

byte-level differencing 3

Ccalculating size of software packages 292cancel at cutoff 431CASINSTL, for pristine installations 534CCM 449

creating database tables for 37creating RIM objects for 37for pristine installation 494, 497

CCM_Edit role 563CCM GUI component 29CCM_Manage role 563CCM report

reference model 478target 478

CCM server component 26CCM user roles 456ccm_vendor_admin.sql 37ccm_vendor_schema.sql 37

CCM_View role 562CD, installing from 304Change Configuration Management 449change element 474change management operations 297

accept 21, 322commit 21, 323default settings 134install 299remove 20, 318undo 21, 320verify 21, 326

change management status 121, 297, 450change management status feature 375

disabling 385enabling 384

change subscriber 474change target 474changing OS/400 system values 171changing reference model 473check disk space action 62checkpoint restart 9, 260checks 134, 302child reference model 450

creating 458cleanup, activity plans 446cloning activities 417co-requisite dependency 451code server

adding system files to objects (OS/2) 526for pristine installation 493object 493

OS/2 521Windows 499

object configuration 494object configuration creation and maintenance

OS/2 529Windows 507

object creation and maintenanceOS/2 523Windows 500

prerequisites 494codepage translation 174, 177command line interface

for data moving 486command lines, adding 108


Ind

ex

commandsautopack 218df 270odadmin 263wbkupdb 24wcntpln 434wcrtadmin 339wcrtquery 396wdelstat command 438wdepot 275wdlssp 298wfptosp 2winstall 36, 46winstsp 274, 299wldsp 273, 274wmdist 264, 265, 272, 274wrpt 262wrunquery 391wsdhttpd 360wseterrlev 432, 435wsetspat 290, 344wsetspop 290wspmvdata 481, 486wswsprim 379, 386wsyncsp 379wuldsp 273, 275wwebprfget 359wwebprfset 359wwebrget 343wwebrset 343

commit operation 323, 324committable mode 130complete not after 431component 27

activity planner 26activity planner GUI 28CCM 26CCM GUI 29gateway 27historical database 25Java endpoint package editor 29pristine tool 30server 25Software Package Editor (SPE) 28source host 27Tivoli Enterprise Console 26

component 27 (continued)WEB UI depot 29

component names 34components

installing 25on endpoints 29on managed nodes 27on the Tivoli server 25

compute CRC 230conditions

activities 423completion 423examples 64, 80, 86failure 423in an Install MSI product/patch action 197software package-level 123success 423using 6

configurationcode server object 494creation and maintenance for code server

objectsOS/2 529Windows 507

configuration element 450modify 474remove 474

configuration file, customizing 209configuration repository

updating with Tivoli Software Distributiondata 377

using with Software Distribution 376configuring

data moving service 482configuring repeater as depot 274configuring repeaters 252controlling distributions 10converting software packages

built to not-built 295not-built to built 294

create directories option 69creating

a new software package 57Install MSI Product 58using AutoPack 57using the PDF Importer 57

590 Version 4.1

creating (continued)a shortcut 85profile managers 280profiles 278

creating child reference model 458creating reference model 457CSV file targets

assigning 465CSV subscriber, assigning 465

Ddata

deleting 481, 485distributing 481moving 481retrieving 481, 484sending 483

data movement operations 21data moving service 481

command line interface 486configuring 482on an OS/400 system 178user roles 482using scripts 487

databaseupgrading 380

database mode 280database tables

for Activity planner 37for CCM 37

dataless endpoint mode 280DataMovingRequests.1 482dedicated pristine gateway 494

prerequisites 497default variables 312defining dependency for SWD element 460delete element 474delete reference model 473delete subscriber 474delete target 474deleting data 481, 485deleting OS/400 libraries 166deleting OS/400 licensed programs 170

deleting OS/400 objects 166deleting software package profiles 290delta install 300dependency 125, 301, 305

co-requisite 451defining 2, 460ex-requisite 451pre-requisite 451

depot, permanent storage 259, 262, 274depot list 367depot management operations 21depoting 10descend directories option 69desired state

setting 460destination folder

for MSI product 186device drivers

adding for pristine installationOS/2 531Windows 510

df command 270Dialogs

Activity Properties 415Activity Sort 426Add OS400 Library 162Add OS400 Licensed Program 168Add OS400 Object Properties 165Add Target 418Automatic Update 445Clean up Properties 447Condition 424Execution Windows 427Install 416Install Options 401Login 411OS400 System Values Properties 171Plan Properties 429Profile Manager 422Remove OS400 Library 166Remove OS400 Licensed Program 170Remove OS400 Object 167Select plan for submission 441Tivoli Enterprise Console 401Variable List Editor 67, 141Web Interface access pages 345, 361


Ind

ex

differencing phase 203directories, adding 65, 74disk space, checking 62disposable option 303distributing data 481distributing nested software packages 327distribution manager 252distribution note 317distribution settings 313distribution status 309Distribution Status console 444

Ee-mail, sending 137EBCDIC 174, 177editing software packages 143element

configuration 450inventory 450

adding 462modify 474remove 474software distribution 450SWD

adding 459endpoint components 29endpoint gateway 12endpoint manager 255endpoints 12, 254

used as pristine preparation site 493error levels 432, 434events 397ex-requisite dependency 451execute CID program action 145execute program action

using 116execute_timeout 267execute user program

on an OS/400 system 175execution window

activities 427exit codes 118exporting reference model 472

exporting software packages 296

Ffeatures

for MSI product 188, 196file package migration 7file server 304file system objects

including and excluding 205types 13

file version support 8, 68files

autopack.ini 204BAROC file 405check.bat 541check_OS.spd 541inst_w2000.spd 541MSI 186, 192ntspx.spd 549spxi386.exe 551tecad_sd.baroc 405tecad_sd.conf 400, 402tecad_sdnew.baroc 399unattended.txt 543Unattended.txt 540userlink.htm 346, 361w2000.spd 543

files, adding 66, 76Filter keyword 404final activity 428first snapshot 221forcing an operation 134

Ggateway, dedicated pristine 494

prerequisites 497gateway component 27general properties 124Generic container 58, 71

592 Version 4.1

GETREXX, for pristine installations 528GID 138

Hhard disk partitioning, for pristine installations

OS/2 531Windows 512

hardware prerequisitesdefining for a package 2

hidden web view mode 341, 358historical database component 25historical database feature 375

disabling 385enabling 384requirements 384

hung distributionsconfiguring wmdist parameters 265

IIFS 157, 158import activity plan 476Importer Tool

MSI 184importing

built software packages 289not-built software packages 289

importing reference model 473importing software packages 285, 286index files 34, 36individual targets

assigning 468Install MSI Patch action 189Install MSI Product action 189Install MSI Product wizard 184install operation 299Install Options dialog 401installation

Install Product 35Java endpoint package editor 39

installation (continued)mechanisms 33planning for 23pristine 491pristine tool 44tasks 32using Tivoli Desktop 35using Tivoli Software Installation Service 34winstall 36

installation optionrepair 193

installation optionsJava Endpoint Package Editor 40

installingdisconnected mode 316from CD 304from depot 274, 303from file server 304language support 51Tivoli Software Distribution TEC

Integration 398installing components 25InstallShield Program action, redirected

installation 146InstallShield Program Builder 149Integrated File System 157, 158inventory element 450

adding 462Inventory integration

authorization roles 385change management status feature 375configuration repository 375, 376configuration repository tables 377disabling change management status

feature 385disabling historical database feature 385enabling change management status

feature 384enabling historical database feature 384historical database feature 375query facility 377upgrading database 380wcrtquery command 396wswsprim command 386

inventory queryassigning targets with 469


Ind

ex

inventory subscriber 419inventory subscriber, assigning 469

JJava Components 24Java endpoint package editor

installing 39Java Endpoint Package Editor

installation options 40Java endpoint package editor component 29

Kkeep product images

for MSI product 188, 192keyword, Filter 404

LLAN CID utility, for pristine installations 534language support 51launching Software Package Editor 54links, creating 85loading software package on repeater depot 274local depot

performing operations 374locked activity plans 409locked file support 8locked files, renaming 69log file options 136log host 137log mode

MSI product/patch 194logging information, TEC events 397Login dialog 411

Mmanaged node components 27mandatory 317MDist 2 (multiplexed distribution)

assured delivery 9asynchronous delivery 9checkpoint restart 9depoting 10distribution control 10overview 9, 258pending distribution queues 10

Microsoft Setup Program action 149Microsoft Setup Program Builder 149Microsoft Software Installer (MSI) 181migration, file packages 7mobile settings 315mobile support 3modes 324modify element 474modify subscriber 474modify target 474modifying reference model 473moving data 481MPTS, configuring for pristine installations

pristine installationMPTS configuring 528

MSIembedding packages 181

MSI fileselecting 186, 192

MSI Importer Tool 184MSI installation package

creating 183using a wizard 184using dialogs 189

MSI installation packages 181MSI product features 188, 196MSI product/patch

destination folder 186keep product images 188, 192log mode 194properties 195redirected installation 187, 192reinstall mode 193source image path 187, 192

594 Version 4.1

MSI product/patch (continued)target image path 187, 192

Nnaming the activity plan 429native installation 146nested software packages 16

distributing 327scenario 330specifying 141

network drive installation 146, 243notices 137notification 430

Oodadmin command 263operation modes

auto reboot 132committable 130default settings 130reboot 132, 311transactional 131, 309undoable 131, 310undoable-in-transactional 132

order of execution 122, 142OS/2 desktop folder, adding 99OS/2 desktop objects 14OS/2 desktop program, adding 101OS/2 desktop sections 208OS/2 desktop shadow, adding 103OS/2 profile items, adding 107OS/2 profile objects 14OS/2 profiles sections 207OS/2 steps for pristine installation 520OS/2 system files sections 208OS/400 libraries

adding 161removing 166

OS/400 licensed programsadding 167removing 170

OS/400 native file system 157, 158adding non-native objects to 172

OS/400 objects 13adding 161, 164removing 166

OS/400 Software Package Editor 159OS/400 system

adding directory to 172adding file to 172executing user program on 175using the data moving service 178

OS/400 system valuechanging 171

OS/400 systemssoftware distribution to 155

OS400 System Values Properties dialog 171overriding registry permissions 230

PPackage Definition File (PDF) 239package type

patch 125refresh 124

parent reference model 450PDF Importer Tool 6, 239pending distribution queues 10permanent storage 274plans_vendor_admin.sql 37plans_vendor_schema.sql 37policy regions 12

configuring 340, 357hidden 341, 357public 341, 357restricted 341, 357setting attribute 343

pre-requisite dependency 451preparation machine 201preparation site, pristine installation 493prerequisites

defining for a package 2


Ind

ex

prerequisites for pristine installation 494preview activity plan 475previewing an operation 134primary software package 142priority 429pristine installation

adding configuration informationOS/2 532Windows 513

boot diskette 494boot diskette creation

OS/2 534Windows 516

CASINSTL 534CCM 494, 497code server 493code server object 493code server object configuration 494code server object configuration creation and

maintenanceOS/2 529Windows 507

code server object creation and maintenanceOS/2 523Windows 500

code server objects, adding system files to(OS/2) 526

dedicated gateway 494defining reference model

OS/2 532Windows 513

device driversOS/2 531Windows 510

GETREXX 528hard disk partitioning

OS/2 531Windows 512

LAN CID utility 534network environment 492OS/2 steps 520other software 492overview 491platforms 492preparation site 493prerequisites 494

pristine installation (continued)reference model 494, 497response file customizing

OS/2 529Windows 507

response file usage 492running

OS/2 536Windows 518

SEDISK 532SRVIFS 533system diskette preparation

OS/2 532Windows 513

THINIFS 533THINLAPS 533THINSRV 527Windows steps 498

pristine systemprerequisites 497

pristine toolinstalling 44prerequisites 495

pristine tool component 30product tags 34profile manager

targets 421, 472profile manager subscriber, assigning 467profile manager targets

assigning 467profile managers

creating 280software categories 358

profilescreating 278overview 11

program actionsexecute CID programs 145Execute program 117, 247Install MSI Patch 189Install MSI Product 189InstallShield program 146Microsoft Setup Program 149

propertiesediting 143general 124

596 Version 4.1

properties (continued)modifying 143MSI product/patch 195of reference model 458software package 143, 291, 292software package-level 122software package object 290

Properties notebook 429public web view mode 341, 358

Qqueries, executing 305query facility 377query library

using to assign targets 470query library, SWDIST_QUERIES 377query library subscriber 420

RRDBMS Interface Module (RIM) object 38reboot mode 132, 311recursion

interrupting 434recursive activity plans 432, 433redirected installation 146, 183, 187, 192, 243reference model 450

creating structure 457defining for pristine installation

OS/2 532Windows 513

example 453exporting to xml file 472for pristine installation 494, 497import activity plan for 476importing from xml file 473modifying 473preview activity plan for 475remove 473submit activity plan for 476

reference model properties 458reference model report 478reference models

subscribing 372synchronize 371updates 364Web Interface 370

registry permissions, overriding 230reinstall mode

MSI product/patch 193remove actions 150remove element 474remove empty directories option 69remove if modified 68, 230remove operation

change management operation 318modes 319

Remove OS400 Library dialog 166Remove OS400 Licensed Program dialog 170Remove OS400 Object dialog 167remove reference model 473removing

activities 438activity plan 438OS/400 libraries 166OS/400 licensed programs 170OS/400 objects 166subscriber 474target 474

renaming locked files 69repair functionality 133repair installation option 193repair options 301repeater

configuring 262configuring as depot 274depot 259gateway 258parameters 266restarting 273standalone 258standalone, creating 263verifying path 262

repeater depotconfiguring 274listing entries 275


Ind

ex

repeater depot (continued)loading software package 274memory space 267, 271removing software packages 275space allocation 267, 271

replace if existing 68, 230replace if target is newer 68report

reference model 478target in CCM 478

response file, used in pristine installation 492response files

customizing for pristine installationsOS/2 529Windows 507

restart action 119retrieving data 481, 484return codes 432, 434RIM object

creating 38roaming endpoint 252, 314roaming endpoints 439roles

Activity Planner 411Activity Planner operations 559CCM operations 562distributing software packages 559SD_Web_Server 355SD_Web_User 355SDhttpd_Control 355software package profiles 557Web Interface operations 563

Ssaving, activity plans 437saving default variables 141saving software packages 151scheduled jobs 306scheduling distributions 305scripts

ccm_vendor_admin.sql 37ccm_vendor_schema.sql 37in a data moving command 487

scripts (continued)plans_vendor_admin.sql 37plans_vendor_schema.sql 37swdis_db2_upgr_41.sql 380swdis_db2_upgr.41.sql 381swdis_db2_upgrade.sql 380, 381swdis_infx_upgr_41.sql 380swdis_infx_upgr.41.sql 384swdis_infx_upgrade.sql 380, 384swdis_ms_sql_upgr_41.sql 380swdis_ms_sql_upgr.41.sql 382swdis_ms_sql_upgrade.sql 380, 382swdis_ora_upgr_41.sql 380swdis_ora_upgr.41.sql 383swdis_ora_upgrade.sql 380, 383swdis_syb_upgr_41.sql 380swdis_syb_upgr.41.sql 383swdis_syb_upgrade.sql 380, 383swdistecsrvr_inst.sh 399

SD_Web_Server role 355SD_Web_User role 355SDhttpd_Control role 355, 564SDK log mode 194SDWebUI_displayname 356, 359second snapshot 231, 238security, authorization roles 22SEDISK

for pristine installations 532segments 274send_timeout 267sending data 483server component 25setting desired state 460setting resource roles 339setting TMR roles 338setup variations 246shared files 73, 78, 212shared object support 8shortcuts, creating 85software categories 349, 359, 365software distribution element 450

adding 459Software Installation Service 34software package block 19, 151software package block, maximum size 19, 294software package block (SPB) path 128

598 Version 4.1

software package definition (.spd) file 18, 295Software Package Definition (.spd) file 153Software Package Editor

starting on OS/400 159Software Package Editor (SPE)

description 56introduction 17launching 53, 54managed node 291on endpoint 54OS/400 159

Software Package Editor (SPE component) 28software package file types 57software package name 281software package object

DataMovingRequests.1 482definition 19properties 290

software package profile, deleting 290software package version 281software packages

built format 19calculating size 292converting 293copyright 139creating 57description 138, 350exporting 296for OS/400 systems 156formats 151hidden 358importing 285, 286installing locally 374local depot 374naming 60, 124, 159nesting 141not-built format 18properties 122, 143, 291, 292public 358saving 151subscriber 358subscribing 372text version 18, 153unbuilding 56, 295uninstalling 369updates 364, 365

software packages (continued)verifying 369, 374version 161, 162, 166, 167, 169, 171, 350

software packages, nested 16software prerequisites

defining for a package 2sorting activities 425source host 12, 128, 260, 289, 290source host component 27source image path

for MSI product 187, 192SPB path 128, 294SPE (see Software Package Editor) 28SRVIFS, for pristine installations 533stage area 128, 311start not before 431static subscriber, assigning 468status

updating 445status, activity plans 440stop on error 432, 434stop on failure 68, 125submit activity plan 476submit paused 430submitting, activity plans 441subscribe 367subscriber

assigning from file 465assigning to reference model 464CSV 465definition 12in CCM 452inventory 469modify 474profile manager 467query library 470remove 474setting 282static 468Web interface 452Web interface, assigning 465

subscriber web view mode 341, 358subscriptions

reference models 372software packages 372

SWD element 450


Ind

ex

SWD element 450 (continued)adding 459

swdis_db2_upgr_41.sql script 380swdis_db2_upgr.41.sql script 381swdis_db2_upgrade.sql script 380, 381swdis_infx_upgr_41.sql script 380swdis_infx_upgr.41.sql script 384swdis_infx_upgrade.sql script 380, 384swdis_ms_sql_upgr_41.sql script 380swdis_ms_sql_upgr.41.sql script 382swdis_ms_sql_upgrade.sql script 380, 382swdis_ora_upgr_41.sql script 380swdis_ora_upgr.41.sql script 383swdis_ora_upgrade.sql script 380, 383swdis_syb_upgr_41.sql script 380swdis_syb_upgr.41.sql script 383swdis_syb_upgrade.sql script 380, 383SWDIST_QUERIES 377swdistecsrvr_inst.sh script 399system components, AutoPack 203system diskette

preparation for pristine installationOS/2 532Windows 513

system diskette creationprerequisites for pristine 496

Ttarget

modify 474remove 474

target image pathfor MSI product 187, 192

target report 478targets

activity plans 435assigning 417assigning by inventory query 469assigning by query library 470assigning from CSV file 465assigning individual 468dynamic 433file name 419

targets (continued)grouping 439inventory subscriber 419list of names 418profile manager 421, 472

assigning 467query library subscriber 420static 433variables 420

tecad_sd.baroc file 405tecad_sd.conf file 400, 402tecad_sdnew.baroc file 399text file objects 13text file objects, adding 108text file sections, AutoPack 206THINIFS, for pristine installations 533THINLAPS, for pristine installations 533THINSRV, for pristine installations 527timeouts

setting for distribution 313Tivoli Desktop installation 35Tivoli desktop operations 20Tivoli Enterprise Console 397Tivoli Enterprise Console component 26Tivoli Enterprise Console dialog 401Tivoli Enterprise Console integration 397Tivoli management region

policy regions 12profile managers 12profiles 11subscribers 12

Tivoli server components 25Tivoli Software Distribution, supported

platforms 1Tivoli Software Installation Service 34tokens, adding 108Tools

InstallShield Program Builder 149PDF Importer 239

transactional mode 131, 309translate attribute 174, 177

600 Version 4.1

UUID 138unbuild 56, 295undo operation

change management operation 320modes 321

undoable-in-transactional mode 132undoable mode 131, 310uninstalling

NetWare gateway 50software packages 369Tivoli Software Distribution 47

UNIX attributes 138updates

reference models 363, 364software packages 363, 364

updating status 445upgrading scenarios

Windows NT 4.0 with Service Pack 5 or6 549

Windows NT 4.0 Workstation to Windows2000 Professional 539

user rolesCCM 456data moving 482

UserLink.htm file 345, 361

VVariable List Editor dialog 67, 141variables

activity plans 436built-in 5, 67, 89, 140defining 437saving defaults 141targets 420

verify CRC 229verify operation 326verifying software packages 369, 374version checking 2, 124, 302versioning type 124

Wwake on lan endpoint 314wbkupdb command 24wcntpln command 434wcrtadmin command 339wcrtquery command 396wdelstat command 438wdepot command 275wdlssp command 298Web Interface

activating 335, 355assigning Resource roles 357assigning TMR roles 356configuring 342configuring policy regions 340, 357creating administrator 336enhanced 333, 353roles 356, 359, 563setting resource roles 339setting TMR roles 337software categories 358software package blocks 350software package description 139tasks 359updates page 363UserLink.htm file 345, 361

Web Interface access page dialogs 345, 361Web interface subscriber 452Web interface subscriber, assigning 465Web UI component 27WEB UI depot component 29web view mode 341, 358

default setting 135hidden 135, 341, 358public 135, 341, 358setting 344subscriber 135, 341, 358

web_view_mode 356, 358wfptosp command 2wildcards 66, 205, 206, 208, 209Windows NT 4.0 with Service Pack 5 or 6,

upgrading 549Windows NT 4.0 Workstation to Windows 2000

Professional, upgrading 539Windows NT service, adding 95


Ind

ex

Windows profile objectsadding 90types 14

Windows profile sections 207Windows registry objects 14, 79Windows registry sections 207Windows shell objects

adding 85types 14

Windows steps for pristine installation 498winstall, using 36winstall command 36, 46winstsp command 274, 299wizard

for embedding MSI packages 184wldsp command 273wmdist

configuring repeater parameters 274repeater parameters 272

working directory 222wrpt command 262wrunquery command 391wsdhttpd command 360wseterrlev command 432, 434, 435wsetspat command 290, 344wsetspop command 290wspmvdata command 481, 486wswsprim command 379, 386wsyncsp command 379wuldsp command 273, 275wwebprfget command 359wwebprfset command 359wwebrget command 343wwebrset command 343

Xxml file

activity plan definition file 409exporting reference model to 472

602 Version 4.1

GC32-0715-00