Application Packager Admin 65
Application Packager Admin 65
Application Packager Admin 65
Packager
Administrator’s
Guide
version 6.5 (050513)
DOC
DOC
Contents
Introduction
What Is Marimba’s Application Packager? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Application Packager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Software Distribution Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Application Packager Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Package Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Application Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
UNIX Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Windows Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Windows Terminal Services Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
How to Read This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Using Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Getting Started
Before You Get Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Preparing to Package Applications on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
UNIX Tar File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
UNIX cpio Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
UNIX SVr4 Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Starting Application Packager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Editing Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Publishing Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Contents 5
Using Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Adding an Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Editing an Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Removing an Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Environment Variables on Different Windows Platforms . . . . . . . . . . . . . . . . . . . . . . 112
Configuring System and Channel Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Configuring Disk Space Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Configuring File Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Configuring Registry Entry Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Configuring Channel Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Combining Multiple Requirements by Using AND and OR Dependencies . . . . . . . . 120
Customizing a Channel by Using Scripts and Classes . . . . . . . . . . . . . . . . . . . . . . . . . 121
Customizing a Channel by Using an Executable Script . . . . . . . . . . . . . . . . . . . . . . 121
Specifying Paths for a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Failure of Post-Operation Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Using Scripts to Run a Response File for SVr4 Packages . . . . . . . . . . . . . . . . . 124
Customizing a Channel by Using a Java Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
IScript Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
IScriptContext Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Example: Simple Java Script That Implements the IScript Interface . . . . . . . . . 129
Managing Major and Minor Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Setting Scripts and Dependencies for Major Updates . . . . . . . . . . . . . . . . . . . . . . . . 130
Setting Scripts and Dependencies for Minor Updates . . . . . . . . . . . . . . . . . . . . . . . . 130
Managing Services (Windows Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Editing Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
General Properties Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Security Properties Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Advanced Properties Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Install Policies Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Uninstall Policies Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Update Policies Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Verify Installed and Verify Not Installed Policies Pages . . . . . . . . . . . . . . . . . . . 136
Repair Policies Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Adding Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Removing Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Editing the Parameters of a Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Minimizing Bandwidth Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Details About the preload and delayfiledownload Parameters . . . . . . . . . . . . . . . . . 142
Working with Packages that Contain User-Specific Files and Registry Entries . . . . . . . 143
Using the Multiple-User Feature with Policy Management . . . . . . . . . . . . . . . . . . . . 144
Package Behavior When Using the Multiple-User Feature . . . . . . . . . . . . . . . . . . . . 145
Verifying and Repairing Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Verifying Channels Before Publishing and Distribution . . . . . . . . . . . . . . . . . . . . . . . 147
Scheduling Verify and Repair for Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Manually Running Verify and Repair for Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Updating and Repairing Applications Using Shortcuts Before Startup (Windows Only) 150
Contents 7
Using File Packager
Packaging a Set of Files into a Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Updating a Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Using .NET Packager
.NET Packager Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Components of .NET Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Packaging a .NET Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Editing a .NET Packager Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
.NET Assembly Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Properties Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Application Policy Configuration Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Assembly Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Publisher Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Garbage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Dependent Assemblies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Add or Edit .NET Dependent Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Development Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Assembly Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Adding Virtual Directories for Internet Information Services . . . . . . . . . . . . . . . . . . . . . 216
Updating a Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Using Java Packager
About Java Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Packaging a Java Application into a Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Passing Arguments to the JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Editing a Java Packager Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Updating a Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Using PDA Packager
Packaging Files and PDA Applications into a Channel . . . . . . . . . . . . . . . . . . . . . . . . . 227
Using the PDA Packager to Update a Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Deploying PDA Packages to Mobile Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Using XML Template Files
Saving Your Package Editor Settings to an XML Template File . . . . . . . . . . . . . . . . . . 233
Configuring Application Packager to Use an XML Template File for Default Settings . . 234
Using XML Template Files with Packager for Shrinkwrap Windows Applications . . . . . 235
Loading XML Template Files for Configuration and Filters . . . . . . . . . . . . . . . . . . . . 236
Saving and Setting Configuration and Filters Using XML Template Files . . . . . . . . . 237
Example: XML Template Files to Use with Snapshots . . . . . . . . . . . . . . . . . . . . . . . 237
Example: Configuring the Default Settings for Newly Packaged Channels . . . . . . . . 239
Applying an XML Template File to Existing Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Contents 9
<PACKAGE> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
<CUSTOMMACRO> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
<MACRO> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
<ENVIRONMENT> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
<ENV_PROPERTY> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
<SERVICES> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
<SERVICE> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
<SERV_GENERAL> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
<SERV_SECURITY> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
<SERV_ADVANCED> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
<SERV_DEPEND> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
<SERV_POLICIES> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
<CONFIGURATION> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
<PLATFORM> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
<INSTALLER> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
<REBOOT> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
<POLICIES> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
<STARTUP> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
<VERIFYREPAIR> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
<DEPENDENCIES> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
<DEPEND_MEMORY> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
<DEPEND_PROCESSOR> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
<DEPEND_RESOLUTION> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
<DEPEND_DISKSPACE> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
<DEPEND_DRIVE> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
<DEPEND_FILES> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
<DEPEND_FILE> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
<DEPEND_REGISTRY> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
<DEPEND_REGKEY> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
<DEPEND_CHANNELS> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
<DEPEND_CHANNEL> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
<CUSTOMIZATION> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
<SCRIPTS> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
<SCRIPT> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
<PROPERTY> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
<PARAMETER> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Non-MSI Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
<DIRECTORY> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
<FILE> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
<SHORTCUT> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
<REGKEY> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
<REGVALUE> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
<METABASEKEY> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
<METABASEVALUE> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
<MODIFIERGROUP> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
<MODIFIER> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
MSI Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
<MSI_INSTALLATION> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Contents 11
12 Application Packager Administrator’s Guide
Introduction
DOC
This guide helps you use Application Packager and its components to package
software for distribution to desktops or servers.
This guide is intended for software developers, system administrators, IT
managers, and other personnel who package software for distribution to
desktops or servers. This guide assumes that you are familiar with Marimba’s
products, such as tuners and transmitters. For a review of the basics of using
Marimba products, see Introduction to Marimba Products on Marimba’s
Documentation page at www.marimba.com/doc/.
Introduction 13
What Is Marimba’s Application Packager?
• .NET Packager*
• Java Packager
• PDA Packager*
*Available on Windows only
Introduction 15
What Is Marimba’s Application Packager?
If you have an existing packaged application, you can click the appropriate
packager from the button bar on the left, select the packaged application, and
select a command at the bottom of the screen.
Introduction 17
What Is Marimba’s Application Packager?
Package Directory
After packaging an application, the result is a package directory. The package
directory is the directory in which Application Packager stores the files for a
packaged application. A package directory is created when you use any of the
packager components of Application Packager to package a software
application. When you edit and publish a packaged application, you are
actually editing and publishing the contents of the package directory. The
package directory is also sometimes referred to as the channel directory or
publish directory.
Usually, you do not need to manually edit the contents of the package
directory; Application Packager modifies the contents when you use the GUI
or command line to edit the packaged application. However, it is useful to
know what the package directory contains.
Typically, the package directory contains the following files and directories:
• parameters.txt file—The file where Application Packager stores
information for installing and launching a packaged application. The
information in this file is used by the tuner when you run a channel to
install and launch the packaged application. For a list of properties that
you can use in a channel’s parameters.txt file, refer to the Marimba
Reference Guide on Marimba’s Documentation page at www.marimba.com/doc/.
• properties.txt file—The file where Application Packager stores
information for publishing and running a channel. This file contains all
the information necessary for publishing the channel, as well as
instructions for the tuner on how to launch the channel. For a list of
properties that you can use in a channel’s properties.txt file, refer to the
Marimba Reference Guide.
• files directory—This directory contains the files that make up the
packaged application. The files in this directory are stored by their
checksum values instead of their real name.
• plugin directory—This directory contains information about any plug-ins
included with the channel. These plug-ins are usually designed to work
with the transmitter to which the channel is published.
• signed directory—Each application that is packaged with Application
Packager has its own signed directory. If the packaged application is
signed with a code-signing certificate, the contents of this directory are
used as the basis for a channel-signing signature that is used to guarantee
the integrity of the software application. The signed directory also
contains the .ncp directory, which contains the manifest file (manifest.ncp).
The manifest file contains the code and instructions required to install and
update the application.
The package directory created by the PDA Packager is somewhat different. For
more information about the package directory for PDA packages, see the
Device Management Administrator’s Guide.
Introduction 19
Supported Platforms
Application Installer
Application Installer installs the packaged application on an endpoint. If
you’ve configured a channel to install in full GUI mode, Application Installer
usually appears when a user at the endpoint subscribes to and runs for the first
time a channel created using Application Packager.
You can also configure Application Installer to run without interacting with
the user:
• In silent mode, Application Installer does not display any dialog boxes or
progress bars. It uses the default channel settings.
• In semisilent mode, Application Installer displays a progress bar only. It
uses the default channel settings.
For more information about configuring a channel to use silent and semisilent
modes, see Setting Installation Modes on page 94.
Supported Platforms
You can use Application Packager to package software for distribution on both
Windows and UNIX platforms. Remember that you must package software on
the platforms to which you plan to distribute the software. That is, your
packaging platforms must match your endpoints’ platforms.
Introduction 21
Supported Platforms
After you publish the channel to a transmitter, you can deploy the software
packaged as a channel to target WTS machines using Deployment Manager.
Using a channel to deploy software provides centralized distribution and an
efficient update mechanism for future upgrades.
Sections in this book that apply only to Windows Terminal Services machines
are marked “WTS only.”
Introduction 23
Related Documentation
Related Documentation
Also on Marimba’s Documentation page at www.marimba.com/doc/, you can find a
variety of documents—both online books and PDF versions of some of the
online help for Marimba products.
If you are not very familiar with Marimba products, be sure to read the
Introduction to Marimba Products, which describes how to use the basic
components of Marimba products, including tuners and transmitters.
Other documents that you might use under certain circumstances are
mentioned in the appropriate sections of this guide.
Using Help
To get help for Application Packager, click any of the Help buttons that appear
throughout the application, or use the Help menu. Both of these mechanisms
will start the Marimba Help channel.
Help buttons are linked to specific topics that should help you complete your
task. Once a help topic is open, you can use the hyperlinked table of contents
to find other topics of interest. Most topics also contain a hyperlinked list of
related topics at the end of the topic (indicated by a “See Also” heading).
Help is distributed with the Marimba product you’re using (for example,
Application Packager) and will be updated automatically whenever the
product channel is updated. Because help is part of a channel, the help files are
stored on your machine and are always available, even in the absence of a
network connection.
Typographical Conventions
The following formatting conventions are used in Marimba documentation.
Example Explanation
Click Apply. Names of menus, commands, buttons, and other user interface
elements appear in bold in instructional procedures.
Choose Edit > Cut This notation means (in this example) choose Cut from the Edit menu.
setup.exe File names, directory names, paths, code samples, and command-line
text appear in a monospaced font.
cd \data Where necessary to differentiate it from text the computer displays, text
you type appears in a bold monospaced font.
<your_file> Text variables are italic and enclosed in angle brackets. For example, if
the documentation states, “Type some.exe -f <your_file>,” you
might type some.exe -f mystuff.txt.
[-title] Command-line options that you can include or omit are enclosed in
square brackets.
quiet|verbose Vertical bar separates a choice of command-line options—in this
example, either quiet or verbose.
The kernel New terms appear in italics.
provides…
Introduction 25
Typographical Conventions
DOC
This chapter shows you how to begin using Application Packager. It shows
you how to start Application Packager and introduces you to the Application
Packager interface.
Getting Started 27
Before You Get Started
3 If the package is already in the filesystem format, then simply note its
location for subsequent steps. These steps assume its location is
/tmp/newdir.
Getting Started 29
Editing Channels
Editing Channels
If you want to change the contents, configuration, and properties of a channel,
you can use the Package Editor. You can access the editor from within the
various packagers or from the list of packaged applications.
Note: If you import and edit a channel that was packaged using a previous
version of Application Packager, you will be asked if you want to upgrade
the channel. You must upgrade the channel before you can edit it with the
current version of Application Packager.
▼ To edit a channel:
1 From the Application Packager window, click a button on the left-hand
side that reflects the type of channel you want to edit. For example, click
Custom to edit a channel packaged using the Custom Application
Packager.
A list of the channels you’ve packaged using that particular packager
appears. If the channel doesn’t appear in this list, you’ll need to import
the channel. For specific instructions, refer to Importing Channels on page 31.
2 Select the channel you want to edit and click Edit.
The Package Editor appears in a separate window. The options available
in the Package Editor are different for each type of channel.
Publishing Channels
Each packaging component of Application Packager creates a complete set of
files for the application you want to distribute as a channel. From the packager
or the Package Editor, you can click the Publish button to launch a wizard that
guides you through the process of publishing the channel to a transmitter.
Publishing a channel to a transmitter makes it available for distribution to
endpoints.
If you want to sign the channel for security, use a channel-signing certificate
from a certificate authority (such as VeriSign). The appropriate trust settings
should be preset in the channel for you by the packager. For more information,
refer to Publishing Channels on page 243.
Importing Channels
You can import a channel that was previously packaged by you or someone
else using Application Packager. You’ll need to know the location of the
package directory. After it is imported, you can edit the channel using the
Package Editor. For more information, refer to Using the Package Editor on page
55.
Note: If you copy a package from a CD, the files and directories in the
package will have the “read only” attribute set. Importing such a package
into Application Packager causes an error with an “access denied” exception
in the history log. Make sure you remove the “read only” attribute from the
contents of a package before importing it into Application Packager.
Getting Started 31
Removing Channels from the List
This chapter contains instructions for using Packager for Shrinkwrap Windows
Applications through the GUI. You can also use the command-line interface.
For more information, see Packager for Shrinkwrap Windows Applications Command-
Line Options on page 264.
Packaging Overview
Packaging a shrink-wrapped Windows application into a channel involves the
following steps:
1 Start Application Packager and select Packager for Shrinkwrap Windows
Applications.
2 Create a pre-install snapshot.
a. Select the file systems to monitor.
b. Select the registry entries to monitor.
3 Install the application.
a. (WTS only) Switch the WTS machine to install mode.
b. (WTS only) If necessary, make the application compatible with WTS.
4 Create a post-install snapshot.
5 Package the files and settings into a channel.
6 (Optional) Use the Package Editor to review or edit the channel.
7 Use the channel publishing wizard to publish the channel to a transmitter.
more independent the channels that you package on that machine. If you are
distributing software to WTS machines, using clean machines is important
when you add new servers to the server farm.
It is recommended that you create a packaging machine with two operating
systems, and use one of them as a backup. You can then use the backup
operating system to copy over the one you used for packaging applications.
Note: You must package software on a WTS machine if you are going to
deploy it to WTS machines.
c. On the File System Selector page (and the following pages), you
identify the file systems and registries to use for the new snapshot. For
more information, see Selecting File Systems on page 37.
• If you want the packager to use a snapshot file that you created earlier:
a. Select Load the pre-install snapshot from disk and click Next.
b. On the Load Pre-Install Snapshot page, locate and select the snapshot
file to use. Snapshot files use the .msp extension.
You can also exclude all file systems from the snapshot you are creating.
4 If you want the snapshots to include the removal of files and directories,
select the Capture removal of files and directories check box.
Removed files and directories appear on the Package Contents page of the
Package Editor with an X over them. For more information, see Packaging
the Removal of an Application on page 51.
When the snapshot is taken, the drives and directories you added are included
in the snapshot.
Whether you want to set up a filter or identify an item directly, you use the
same process.
If you want to exclude a specific directory or file, you may choose to use
path instead of name.
a. If you want to broaden the criteria so that the filter finds multiple
directories, experiment with the drop-down list options.
b. If you want to narrow the scope of your filter even more, click More
and add another layer of criteria that must be satisfied. If you want to
delete a layer of criteria, click Fewer.
5 Click OK.
Your filter appears in the Ignore list and is enabled.
▼ To remove a filter:
Select the filter name in the Ignore list and click Remove. If you want to
remove all filters, click Remove All.
• Enable parsing INI files (KEY, VALUE pairs). Select this check box if you
want INI files to be treated as special files. The packager parses the INI
files and captures any changes made to the key and value pairs in them.
Any changes found by the packager are merged with the existing file
found at the endpoint. By default, this check box is selected. If you want
the packager to process INI files as ordinary files and not merge changes
within the files, you can clear this check box. For more information, see
Working with INI Files on page 66.
• Enable processing of .NET features. Select this check box if you want to
enable .NET-specific features, such as parsing of .NET assembly policy
configuration files.
In addition, you can also save or set XML template files that contain the
configuration and filters that you want the packager to use. For more
information, see Loading XML Template Files for Configuration and Filters on page 236.
You need to select this check box to capture any changes made to the IIS
metabase when installing an application. If you do not select this check
box, you will not see the other pages involving the metabase described in
this section.
The Metabase Selector page appears. This page allows you to select the
metabase entries to include, exclude, or ignore in your snapshot. By
default, the \LM and \SCHEMA keys are included in your snapshot.
Note: When you specify the directory in which to create or save the channel,
make sure the directory does not already contain another channel. Otherwise,
the channel that you create may not be usable.
When you publish a channel update to the transmitter, the update overwrites
the previous version of the channel on the transmitter. Before you package and
publish a new version of the channel to the same channel URL, it is
recommended that you create a backup copy of a previous version of a
channel. For instructions on using Channel Copier to create a backup copy of
the channel on the transmitter, refer to Creating a Backup Copy of a Published
Channel on page 246.
The application is now under the control of Application Packager. If you later
uninstall the channel, the application is uninstalled and no longer exists on the
endpoints.
By default, the files under WFP are the system files included in WINNT\SYSTEM32.
These include core kernel DLLs and libraries generally touched only by
operating system service packs or deeply integrated applications such as
Internet Explorer.
WFP does not allow Marimba applications, such as Application Packager, to
overwrite the protected files. Thus, when it comes to distributing applications
that make changes to these protected files, Application Packager must keep the
original installation package intact. As a result, you cannot use Packager for
Shrinkwrap Windows Applications to package these types of applications. If
the original package is in a file with the .msi extension, use Marimba’s
Windows Installer Packager. If it is in a file with the .exe extension, follow the
vendor’s instructions, use Custom Application Packager or File Packager to
create the channel, and then start the executable using a post-install script.
• When you are selecting the file systems to monitor for your pre-install
snapshot, select the winnt directory only. Limiting snapshots to this
directory results in faster snapshots.
• When installing the printer driver, you do not need to enter install mode.
• After taking the pre-install snapshot but before taking the post-install
snapshot, add any printer aliases needed by the WTS machines. Printer
aliases are very important for getting printers to work on WTS machines.
To make sure printer aliases work correctly:
• On WTS machines running MetaFrame, add any printer aliases to the
wtsuprn.inf file after you install the driver. Add the printer aliases
after the pre-install snapshot but before the post-install snapshot.
• On Windows 2000 servers that don’t have MetaFrame, make sure that
you include an ntprint.inf file that has all the printer aliases needed
by the servers. Alternatively, you could write a post-install script that
appends aliases to ntprint.inf after installing the printer driver.
DOC
The Package Editor allows you to review and edit channels created using
Application Packager before you publish them. The editor allows you to do the
following changes:
• View, add, delete, and modify directories, files, and registry entries in the
channel
• Use macros for making global installation substitutions
• Configure startup and installation options for the channel and the
application it installs
• Set installation and uninstallation policies for the channel and for
individual files in the channel
• Configure verify and repair options for the channel
• Set package dependencies to configure the memory, disk space, or files
required to install and run a channel
This section contains the following topics:
• Opening a Channel for Editing on page 56
• Editing the Contents of a Channel on page 57
• Using Macros on page 82
• Setting Channel Startup Options on page 92
• Setting Installation Modes on page 94
• Enabling Installer Logging on page 97
Note: If you import and edit a channel that was packaged using a previous
version of Application Packager, you will be asked if you want to upgrade
the channel. You must upgrade the channel before you can edit it with the
current version of Application Packager. You can also upgrade several
channels at one time by using the command-line option -upgrade. For more
information, see Upgrading Channels on page 274.
• Add, delete, rename, and modify files, directories, registry entries, and
other contents of your channel
• Search the channel for files, directories, and registry keys
When you edit a Packager for Shrinkwrap Windows Applications channel, the
Package Contents page shows you the difference between the pre- and post-
install snapshot. Don’t expect to see every file in a directory you selected
during the snapshot process. Only the files, directories, and other contents
needed to create the channel appear here.
When you edit a Packager for Shrinkwrap Windows Applications channel
using the Package Editor, you are overriding the settings that the snapshot
gathered from your system. For example, perhaps the application’s installation
program put the application files in C:\Program Files\ACME, but you’d like the
application to be installed at C:\ACME on the endpoint. The Package Editor can
help you make this kind of change.
If you know how to use Microsoft’s Registry Editor (regedit), you will find
using this page very familiar. The next few topics provide basic instruction on
the most common commands that are available from this page. (Your Registry
Editor documentation may offer additional information that you may find
useful.)
Depending on what you select (file, directory, registry key, or other content),
you can right-click to see a pop-up menu of available commands for the
selected item. (The same commands are available using the Edit menu in the
Package Editor’s main menu bar.)
This section contains the following topics:
• Working with Files on page 59
• Working with INI Files on page 66
• Working with Directories on page 70
• Working with Registry Entries on page 72
• Working with Metabase Entries on page 75
• Renaming the Items in a Channel on page 80
• Deleting Items from a Channel on page 80
• Marking Items for Deletion from the Endpoints on page 81
• Searching for File System and Registry Entries on page 82
▼ To add a file:
1 On the left-hand pane, select the parent directory in which you want to
add a file.
2 Right-click the directory name and choose Add > File.
Alternatively, you can right-click in the right-hand pane and choose Add
File.
The Add File dialog box appears.
• You cannot add INI files by reference because of the way Application
Packager handles them. For more information about INI files, see Working
with INI Files on page 66.
Tip: You can also edit file properties by doing one of the following steps:
• Double-click the file.
• Select the file and press Enter.
Application Packager loaded the DLL files into the process address space of the
tuner, which made the tuner vulnerable to any defects that might exist in the
registration and deregistration methods of the DLL files. Potentially, defects in
third-party DLL files might cause problems with the tuner. To avoid these
problems, beginning in version 4.7.2.1, Application Packager uses separate
non-console Windows applications to register or deregister DLL files.
Application Packager uses one of the following Windows applications:
• regsvr32.exe. If the file path <Windows_system_directory>\regsvr32.exe
exists on the endpoint, then Application Packager will use it to silently
register and deregister DLL files. For registration, it will use the following
command-line syntax:
<Windows_system_directory>\regsvr32.exe /s <DLL_file_path>
▼ To add a shortcut:
1 On the left-hand pane, select the parent directory in which you want to
add the new shortcut.
2 Right-click the directory name and choose New > Shortcut.
The New Shortcut dialog box appears.
3 Set the shortcut’s properties:
a. Enter a name for the shortcut. The name must include the .lnk
extension.
b. For Path, enter the complete path to the item that you want the
shortcut to point to, such as a file or directory.
Note: When creating shortcuts using Package Editor, you can only
specify file system paths and not URLs.
c. Optionally, you can also set other properties for the shortcut, including
arguments and icons.
d. Click OK.
The shortcut that you added appears on the Package Contents page.
identifies the shortcut.
You can also configure shortcuts so that when an application is started
using the shortcut, the packaged application is automatically updated or
repaired. For more information, see Updating and Repairing Applications Using
Shortcuts Before Startup (Windows Only) on page 150.
Note: When you add a shortcut file (a file with a .lnk extension on
Windows) to a package, the actual file to which the shortcut refers is
added to the package. To add a real shortcut, follow the steps in this
procedure.
key1=value1
key2=value2
The following sections described how Application Packager handles INI files:
• How Application Packager Handles INI Files on page 67
• INI Files that Contain Duplicate Sections on page 67
• INI Files that Contain Duplicate Entries on page 68
Other sections that might be useful to read when working with INI files
include:
• Selecting Snapshot Customization Options on page 42
• Viewing the Contents of a File on page 64
• Applying Macros In INI Files (Windows Only) on page 85
• Modifying ASCII Text Files on page 152
• Packaging a Set of Files into a Channel on page 200
key1=value1
key2=value2
and in the post-snapshot, the file config.ini contains the following items:
[section1]
key1=value1
key3=value3
key3=value3
Note: This behavior applies with the default installation and uninstallation
policies. It no longer applies if you have changed the installation or
uninstallation policies.
For example, the INI file contains the following duplicate sections:
[section]
key1=value1
[section]
key2=value2
When the INI file is added to a package, or written to disk at installation time,
Application Packager merges the duplicate sections into a single section:
[section]
key1=value1
key2=value2
Example 1
The package contains:
[section1]
key1=value1
Example 2
The package contains:
[section1]
key1=value1
Note: You cannot have duplicate entries with the same key name and value,
as in the following example:
[section1]
key1=value1
key1=value1
Example 3
The package contains:
[section1]
key1=value1
key1=value2
key1=value2
Repair operation. If an INI file has its installation or update policies set to Allow
duplicate values, then during a repair operation Application Packager will
append a key-value pair to the section instead of overwriting an existing key-
value pair with the same key name. However, if a key-value pair with the same
key name and value already exists in the INI file at the endpoint, then
Application Packager will not append anything.
Uninstall operation. If an INI file has its installation or update policies set to
Allow duplicate values, then Application Packager keeps track of entries that
were created or merged so that they can be removed properly during
uninstallation. During an uninstall operation, Application Packager checks
which entries were created or merged with the Allow duplicate values policy and
only removes an entry from the INI file at the endpoint if both the key name
and key value matches. If only the key name matches, then Application
Packager does not remove the entry from the endpoint.
You can also use this dialog box to set installation, uninstallation, and
verification policies. For more information, refer to Setting Policies for
Installation, Update, Uninstallation, Verification, and Repair on page 104.
Caution: Use extreme care when editing the registry entries that are part of
the channels you create. It is possible to make changes that could make the
target endpoint inoperable after your channel is installed. Use the same care
when editing registry entries with the Package Editor that you would use
with Microsoft’s Registry Editor. For more information, refer to Making
Changes to the Windows Registry on page 42.
A dialog box informs you if the editor successfully imports the entries from the
registry file. The registry entries in the file that you imported now appear on
the Package Contents page.
3 Set the properties that you want for the registry entry. For more
information about using this dialog box to set policies, refer to Setting
Policies for Installation, Update, Uninstallation, Verification, and Repair on page 104.
Caution: Use extreme care when editing the metabase entries that are part of
the channels you create. It is possible to make changes that could make IIS
(and consequently your web server or FTP server) inoperable after your
channel is installed. Use the same care when editing metabase entries with
the Package Editor that you would use with Microsoft’s MetaEdit.
4 Click OK.
The metabase key that you added (including the macro name) appears on
the Package Contents page.
4 Click OK.
Tip: On Windows, you can rename an item by selecting it and pressing F2.
Note: The Delete command is not available for items that cannot be deleted.
Tip: You can also delete an item by selecting it and doing one of the following
steps:
Note: If a directory is inverted (marked for deletion), then its contents should
not be inverted again (marked for installation instead of deletion). Otherwise,
the package installation will fail at the endpoint because the contents are
being installed in a directory that does not exist.
• Find
• Find Next
Using Macros
This section describes how to use the Package Editor to add, edit, and remove
macros from a channel. It includes the following topics:
• Creating User-Defined Macros on page 84
• Examples: Using Macros in Packaged Applications on page 86
path. If the end user does not provide a path, or your macro does not use the
prompting option, the default path (the path shown on the Package Contents
page) is used. You can create as many macros as you need for a channel.
Packager for Shrinkwrap Windows Applications also uses a set of pre-defined
macros that you can use but cannot change. These are listed on the Macros
page under Available Macros. All macros appear on the Macros page under
Available Macros and User-defined Macros.
When you use a macro, make sure the macro name is preceded by a dollar sign
($). When used within a string, the macro name should also be followed by a
dollar sign (for example, home_dir\$custom_directory$\desktop). Macros are
case-sensitive.
▼ To create a macro:
1 From the Package Editor window, click the Package Contents tab.
2 Select the directory or file system for which you want to create a macro.
3 Right-click and choose Define Macro from the pop-up menu.
The New Macro dialog box appears.
4 Select a macro type from the Type list:
• User Defined. This macro has the default user namespace $name.
Macros in this namespace cannot automatically resolve themselves.
They either have default values, or they must be resolved by the user
at runtime.
• Registry Value. (Windows only) This macro has the namespace
$REG.name. It expects a second macro called $name (in the default
namespace) to exist. This macro should contain a complete path to a
registry value.
• Environment Variable. This macro has the namespace $ENV.name. It
resolves to the value of the environment variable name.
• Package Property. This macro has the namespace $APP.name. It resolves
to the value of the application property name.
• Tuner Property. This macro has the namespace $TUNER.name. It resolves
to the value of the tuner property name.
On the Package Contents page, notice that the name of the new macro you
created ($dir) appears in place of the installation directory
(C:\channels\install).
8 Click the Macros tab.
Note that under User-defined Macros is the macro you created, $dir1,
which has the default path for the installation directory.
9 Click Add, which brings up the New Macro dialog box.
10 In the New Macro dialog box:
a. For Type, select Registry Value.
b. For Macro Name, enter the name that you want (for example,
reginstall).
c. For Default Macro Definition, enter the default path you want to use
for the installation directory (for example, C:\channels\reginstall).
d. For Registry Key, enter HKEY_LOCAL_MACHINE\SYSTEM\reginstall.
e. For the corresponding Value, enter installdir.
Note: The registry key and value that you enter should be same as
those that you used when creating the registry key in Step 1. You use
the same value so that at installation time the packaged application
will read the registry key value that you defined. However, if the
registry key does not exist, then the macro will use the default macro
definition.
11 Click OK to close the New Macro dialog box and go back to the Macros
page.
Notice that the new macro you created appears under User-defined
Macros with the name $REG.reginstall.
12 Under User-defined Macros, select $dir1 and edit it so that the Default
Macro Definition is $REG.reginstall.
13 Save the packaged application and publish it.
14 From the endpoint, subscribe to the packaged application, and check
where the application got installed.
It should be installed under C:\channels\reginstall.
c. For Default Macro Definition, enter the default value you want to use
if the tuner property is not defined at the endpoint (for example,
12345).
6 Click OK to close the New Macro dialog box and go back to the Macros
page.
Notice that the new macro you created appears under User-defined
Macros with the name $TUNER.marimba.license.identifier.
7 Click the Package Contents tab.
8 Add a registry key under HKEY_LOCAL_MACHINE\Software\Castanet Info
with the following name and value:
• name: TunerID
• value: $TUNER.marimba.license.identifier
9 Save the packaged application and publish it.
10 From the endpoint, subscribe to the packaged application, and check that
the registry key TunerID appears under
HKEY_LOCAL_MACHINE\Software\Castanet Info and has the correct value.
Notice that for Default Macro Definition, the directory you selected
in Step 3 (C:\channels\install) appears automatically.
c. Select the Query user for definition check box, and type the message
you want to present to the end user in the text box. For this example,
type this message in the text box:
In what directory should the MyApplication files be installed?
6 Click OK.
On the Package Contents page, notice that the name of the new macro you
created ($install) appears in place of the installation directory
(C:\channels\install).
This name ($install) appears on the Package Contents page but will not
be seen by the people using your channel.
7 In the editor, click the Macros tab.
Notice that the new macro you created appears under User-defined
Macros with the name $install, the default definition
C:\channels\install, and with the query check box selected.
9 From the endpoint, subscribe to the packaged application, and check that
the installer prompts you for the installation directory when installing the
application. By default, it is installed under C:\channels\install.
If you want to remove all the user-defined macros, click Remove All.
8 If you want the tuner to manage exiting the application, select Allow
tuner to manage application termination.
9 If the application does not respond to an exit request and you want to
force the application to exit after a short delay, select the Force
application termination after a short delay check box and specify the
number of seconds for the delay.
Specifying a delay is useful when you want to use the tuner to exit the
application, but you want to allow applications to exit gracefully, or to
allow end users to save their work before the application is forced to exit.
10 Set the following options depending on how you want to run the
application:
• Allow -runexe option to execute any program from the command line.
Select this check box if you want to allow users to execute any
application using the command-line option -runexe
<application_name>, where <application_name> includes the full path
of the application executable or batch file. If you don’t select this check
box, you can use the command-line option -runexe without any
arguments to start only the application with the executable file
specified in the Path text box.
• Run the application in the user's context instead of the tuner’s context.
(Windows only) Select this check box if you want the application in
this channel to run in the user’s context instead of the tuner’s context.
This option may be useful when running the tuner as a service. By
default, applications started using the tuner inherit the tuner’s context.
Inheriting the tuner’s context may cause problems when the tuner is
running as a service because the application will not be running in the
logged-on user’s context (and will be missing the user’s security and
identity settings). If you choose this option, the application will have
the rights and permissions of the logged-on user only.
11 Click to save the channel.
12 In the package directory, open the parameters.txt file using a text editor
and add one or both of these properties:
• run.install=true
• run.update=true
These properties control whether the specified application should be
launched after the initial installation or after updates (both major and
minor). For more details, see run.install and run.update on page 140,
in the section Editing the Parameters of a Channel on page 137.
Optionally, you can also select Preview mode, which creates a channel that
simulates the installation process without actually installing any content. When
you install a packaged channel with preview mode selected, any pre-install
scripts and dependency checks are run; however, directories, files, registry
entries, metabase entries, and services are not installed.
When: A rollback update is triggered when a major update fails causing the
channel to be in failed state. For more information about major updates,
see Managing Major and Minor Updates on page 129.
Result: The channel ends up in a rollback state. This state indicates that
the channel update has failed and has been brought back to its previous
state. However, this state cannot successfully verify, repair, or install. It
can only be “updated” with the correct version of the channel to bring it
back into an “installed” state. During the rollback of an update, all files
overwritten are temporarily backed up so they can be restored. Like
rollback install, no scripts are executed and no dependencies are checked
during this phase.
Warning: Selecting this option might cause the removal of files and registry
entries that are critical to other applications.
endpoint before running any scripts and starting installation. In some cases,
you might want to delay the download of a channel’s files to the endpoints.
For example, if you need to use a pre-install script to run some commands or
check that some conditions are met before installing an application, you might
want to delay the download so that time and bandwidth are not wasted if the
commands fail or if the conditions are not met.
You might also want to use this option with the preload parameter. Using
these together allows you to prevent files that are already on the endpoint from
being unnecessarily downloaded again (see Minimizing Bandwidth Usage on page
141).
If you select the check box described in this section, the channel download
occurs in two parts. The initial download only includes the installer and the
manifest file (manifest.ncp), which contains the code and instructions required
to install and update the application. After any pre- scripts have run, the
second download brings over the files necessary to install or update the
application.
Note: Enabling logging in the Package Editor overrides the tuner’s default
logging options for individual channels.
▼ To enable installation logging and configure when the log rolls over:
1 In the Package Editor window, click the Configuration tab.
2 On the Configuration page, click the Installer tab.
3 Select the Enable installer logging check box.
You will not be able to configure log rollover options if installer logging is
not enabled.
4 To set a regular schedule for rolling over the installer log, choose the Roll
over option and select one of the following from the drop-down list:
• Hourly
• Daily
• Weekly
• Monthly
• Never
5 To set a file size that the installer log should reach before rolling over,
choose the Roll over at option and enter a file size in kilobytes (Kb).
The actual log entries vary depending on the event recorded. Usually, they
include the following information about each entry:
• The date and time
• The severity level
• The user ID
• The log ID
• The log message
• Additional information (usually preceded by #)
For more details about the log IDs and severity levels, refer to the logging
codes chapter of the Marimba Reference Guide, which is available from
Marimba’s Documentation page at www.marimba.com/doc.
Here are some examples of log entries:
[28/Aug/2002:13:53:50 -0700] - audit jeff 1100 Channel created
[28/Aug/2002:13:53:50 -0700] - audit jeff 1101 Channel update started
[28/Aug/2002:13:53:51 -0700] - audit jeff 1107 Channel index installed:
<index id="urn:idx:odr+YbY/zG/8NMpZNLIyWw==" size="1635186">
[28/Aug/2002:13:53:51 -0700] - audit jeff 1110 Channel checkpoint
created: undo0
[28/Aug/2002:13:53:51 -0700] - audit jeff 1102 Channel update finished:
172.16.4.90:5282: [Files changed=36, downloaded=13, bytes
received=24050/190425]
[28/Aug/2002:13:53:51 -0700] - audit jeff 1150 Channel instance started
#installing rollback
[28/Aug/2002:13:53:52 -0700] - audit jeff 9026 Adapter started
[28/Aug/2002:13:53:52 -0700] - audit jeff 9227 The adapter will execute
in the specified mode: 0, INSTALL
[28/Aug/2002:13:53:52 -0700] - audit jeff 9020 Begin Install:
http://acme:5282/MyApplication
#[28/Aug/2002:13:53:55 -0700]
#mode is: INSTALL
[28/Aug/2002:13:53:57 -0700] - audit jeff 9002 Preparing to install
[28/Aug/2002:13:53:57 -0700] - audit jeff 9008 Backup phase
[28/Aug/2002:13:53:57 -0700] - audit jeff 9009 Install phase:
http://acme:5282/MyApplication
#preinstall object: F:\Install Directory op=2, ADD succeeded
#preinstall object: F:\Install Directory\New Folder op=2, ADD succeeded
[28/Aug/2002:13:53:58 -0700] - audit jeff 9231 Object operation to be
performed: F:\Install Directory\New Folder\New Worksheet.xls, op: 2, ADD
#install object: F:\Install Directory\New Folder\New Worksheet.xls op=2,
ADD succeeded
[28/Aug/2002:13:53:58 -0700] - audit jeff 9012 Object installed:
F:\Install Directory\New Folder\New Worksheet.xls
[28/Aug/2002:13:53:58 -0700] - audit jeff 9231 Object operation to be
performed: F:\Install Directory\New Folder\New Document.doc, op: 2, ADD
#install object: F:\Install Directory\New Folder\New Document.doc op=2,
ADD succeeded
[28/Aug/2002:13:53:58 -0700] - audit jeff 9012 Object installed:
F:\Install Directory\New Folder\New Document.doc
Note: The reboot dialog box may only appear on end users’ machines if you
have selected Full mode or Semi-silent mode for the installation. Also, if end
users click on the Finish button (of the installation wizard) immediately after
using the reboot dialog box to reboot the machine, then the reboot will not
occur.
• If both check boxes are selected, then both a Reboot Now button
and a Reboot Later button appear in the Reboot dialog box. This
option gives end users the option of performing the reboot
immediately or postponing the reboot.
If you are using Java and IScript, you must change the same registry keys and
values as the batch files and executables. In addition, the script can grab the
IAdapterContext interface from the IScriptContext. The following sample code
shows what needs to be added to the Invoke() method:
IScriptContext scriptContext;
IAdapter adapter = (IAdapter) scriptContext.getFeature(“adapter”);
adapter.scheduleReboot(true);
For more information about using IScript, see Customizing a Channel by Using
Scripts and Classes on page 121.
• For the policies, the attributes checked include the RHSA (read-only,
hidden, system, and archive) attribute flags, the last modified time, and
the creation time.
• Modifying a file modifies its attributes (specifically, the last modified
time). Therefore, verifying a file’s attributes fails if the file’s contents have
been modified.
• When you set policies for container objects (such as directories, registry
keys, and metabase keys) you are actually setting the policies for the child
objects in them (subdirectories/files, registry subkeys/value pairs, and
metabase subkeys/value pairs). Container objects do not follow the
policies, but the child objects can inherit the policies. For example, when
you set the installation policies for a directory, the Install Policy tab says
“Install policy for this directory’s contents.”
• Verify Not Installed. These policies take effect during the verify and repair
phases for objects that were never installed by a channel (created using
Application Packager). For example, if a newer version of the file is
already installed on the endpoint and there is an older version in the
channel, then the newer version will not be overwritten by the older one if
the installation policy Install if object is newer—Compare objects based
on versions is selected.
• Repair. These policies take effect during the repair phase for objects.
Note: Make sure the relationship between the verify and repair policies make
sense when you set them. The verify policies determine whether a repair
takes place. As a best practice, your repair policies should match your verify
policies. Otherwise, you might see some unintended behavior.
Repairing an object does not guarantee that verifying the object will succeed
the next time it runs.
3 Right-click the item and choose Properties from the pop-up menu that
appears.
The item’s Properties dialog box appears. Depending on the item that you
selected, you’ll see some of the following tabs:
• Install
• Update
• Uninstall
• Verify Installed
• Verify Not Installed
• Repair
These tabs show the different types of policies you can set for the item.
4 Click each tab and select a policy for the item.
5 Click OK.
• Create new environment variables in your channel and add them to the
target system during installation.
• Modify standard environment variables, such as appending a new
directory to the PATH variable.
• Include macros that you created using the Application Packager.
%Path%;C:\Program Files\Acme\Whammo
5 Click OK.
The new variable appears in the list of environment variables.
If the application that you are packaging is intended for Windows NT,
Windows 2000, or Windows XP, you can have both system and user
environment variables. Click the System tab or the User tab, depending on
which type of environment variable you want.
When you are installing a package to a Windows NT, 2000, or XP endpoint and
the tuner on that endpoint is running as a non-NT service (just a regular user
application), then any environment variables under the Windows 95/98 tab
will get installed to the user environment variables of the Windows NT, 2000,
or XP endpoint. The environment variables on the Windows 95/98 tab will
override any user environment variables on the Windows NT/2000 tab for a
package. For example, if both tabs have a variable named "myvar" and the
Windows 95/98 tab has "win95value" and the Windows NT/2000 tab has
"winntvalue", "win95value" will override "winntvalue" when the "myvar"
variable is installed on a Windows NT, 2000, or XP endpoint.
• The minimum amount of disk space (in megabytes) required for a specific
drive
• Whether a file is required to exist or not exist at the endpoint, and
whether the file is required to have a certain size or date
• Whether a registry key is required to exist or not exist at the endpoint, and
whether the registry key is required to contain a certain value
You can also configure channel dependencies by creating a list of channel
URLs. You can require that:
• Channels be present
• Channels not be present
On UNIX platforms, only file dependencies and channel dependencies are
available.
5 Specify when you want this dependency to be checked (aside from the
first-time installation):
• Run on Minor Update
• Run on Verify
• Run on Repair
If you want the dependency to be checked on major updates, select the
Check dependencies on major updates check box on the Configuration -
Dependencies page. Otherwise, dependencies are checked when installing
channels only.
6 If you want to edit a file requirement, do the following steps:
a. From the Required files list, select the file that you want to edit.
b. Edit the existence, size, and date requirements for the file.
c. Click Add.
The modified file requirement appears in the list.
7 If you want to remove a file requirement, do the following steps:
a. From the Required files list, select the file that you want to remove.
b. Click Remove.
If you want to remove all the file requirements from the list, click Remove
All.
The Package Editor removes the file requirements from the list.
8 To close the dialog box and return to the main Package Editor window,
click Close or Add/Close.
and OR expressions are true. If there are no dependencies specified for AND,
then the expression is treated as true. The same also applies if there are no OR
dependencies specified.
For example, a channel requires four files, and you’ve configured two as AND
file dependencies and two as OR file dependencies. If both AND file
dependencies are satisfied and one OR file dependency is not, the channel is
installed. If both OR dependencies are satisfied and one AND file dependency
is not, the channel is not installed.
For information about using scripts to control system reboots, see Using Scripts
to Trigger Reboots on page 103.
Note: On Windows, you can configure the process creation associated with
script files having the extensions .exe or .bat by setting the
processCreationFlags in the parameters.txt file of the channel. For more
information, see processCreationFlags in Editing the Parameters of a Channel
on page 137.
Note: This feature requires Java developer assistance. For more information,
see the “Writing Java Classes for Application Packager Install Scripts” section
of the Advanced Marimba Programming Guide, available on Marimba’s
Documentation page at www.marimba.com/doc/.
You can place a Java class either in the signed\scripts directory or in a ZIP file
in the signed directory hierarchy. You specify the classpath of the Java class on
the Customization page.
a. In the Script Name box, type the name of the script. It can contain
spaces.
b. In the Type of script box, select Java.
c. For the Java class file box, do one of the following steps:
• Enter the name of your .class file. For example, MyScript.class.
• Select Add from the drop-down list to browse the local machine
and select the script file that you want to add to the channel. If you
use the Add option, the editor adds the script you selected to the
proper location in the package directory
(channel_directory\signed\scripts).
d. In the Fully qualified name box, enter the fully qualified name of the
class for a Java script. This is the name of the actual Java class (as
opposed to the file name that you specified in the Java class file box).
For example, for the Java script shown in Example: Simple Java Script That
Implements the IScript Interface on page 129, you would enter MyScript.
The fully qualified name is case-sensitive.
e. If you want to provide the script with any arguments, type the
arguments in the Arguments box. Use a space to separate multiple
arguments.
f. If you want to specify a working directory for the script, enter the path
in the Working dir box. If the path is relative to the scripts folder, then
the current working directory is set to the scripts folder. If the path is
absolute, then the current working directory is set to the parent
directory of the native executable. If the current working directory is
not set manually, then the default is the directory for which the tuner
is currently set.
g. Specify when you want to run the script by using the Run script
options and Installer phases check boxes.
h. Select the check boxes for the options you want to use:
• Ignore script exit/return code. Select if you want to ignore any exit
or return codes.
• Run this script in the user’s context. (Windows only) Select if you
want to run the script in the user’s context. This option may be
useful when running the tuner as a service. By default, scripts
started using the tuner inherit the tuner’s context. Inheriting the
tuner’s context may cause problems when the tuner is running as a
service because the script will not be running in the logged-on
user’s context (and will be missing the user’s security and identity
settings). If you choose this option, the script will have the rights
and permissions of the logged-on user only.
• Run this script as a detached process. This option does not apply
to Java scripts.
i. Click OK to add the script and return to the Customization page.
5 In the Classpath for Java scripts box, enter the classpath of the Java class
(relative to the package directory). If the Java script files are in the
package directory, you can enter signed/scripts. The classpath can be a
colon-delimited list of files and directories.
Note: Currently, you cannot enter paths that include colons (:) because they
are interpreted as delimiters.
IScript Interface
/*
* Confidential and Proprietary Information of Marimba, Inc.
*
* Copyright (c) 1998 Marimba, Inc.
* All rights reserved.
*
* @(#)IScript.java, 1.2, 08/06/1999
*/
package com.marimba.intf.packager;
/**
* This interface should be implemented by a Java-based script that is used in
* an Application Packager channel.
*
* <P>Classification: public.
*
*/
IScriptContext Interface
/*
* Confidential and Proprietary Information of Marimba, Inc.
*
* Copyright (c) 1998 Marimba, Inc.
package com.marimba.intf.packager;
/**
* Context for Java-based Script. The script can use this class to access
* macros and other features of the Application Packager.
*
* <P>Classification: public.
*
*/
int SCRIPT_PREINST = 1;
int SCRIPT_POSTINST = 2;
int SCRIPT_PREUNINST = 3;
int SCRIPT_POSTUNINST = 4;
int SCRIPT_PREUPDATE = 5;
int SCRIPT_POSTUPDATE = 6;
int SCRIPT_PREVERIFY = 7;
int SCRIPT_POSTVERIFY = 8;
int SCRIPT_PREEXEC = 9;
int SCRIPT_POSTEXEC = 10;
int SCRIPT_PREUPDATEMINOR = 11;
int SCRIPT_POSTUPDATEMINOR = 12;
int SCRIPT_PREREPAIR = 13;
int SCRIPT_POSTREPAIR = 14;
/**
* Parse the given string for macros. The return value is the string
* with all macros expanded
*/
String parse(String str);
/**
* set the given macro value
*/
boolean setMacro(String name, String value);
/**
* get the invocation phase. See SCRIPT_RUN constants above
*/
int getPhase();
/**
* access advanced features
* "context" will return the IApplicationContext for the channel
* other tuner features may also be accessed.
*/
/**
* Access point into the script from the IScript interface
*/
public int invoke(IScriptContext context, String[] args) {
System.out.println ("Welcome to my script");
return 0;
}
Minor Update. An update is considered minor if the contents of the channel are
not changed. No content changes means that there are no new, deleted, or
changed files, registry values, or environment variables. The following types of
changes are considered minor updates:
• Any changes to the Application Packager itself, such as an internal update
of its classes and, on Windows, internal DLL files
• Any changes to the properties.txt and parameters.txt files
• Any changes to the scripts or dependencies
• Any changes to the install, verify, and repair policies, whether global or
object-level
If you make any changes (except for the major update changes described
previously) to a channel in the Package Editor, undo your changes, and then
save, the time property changes. (Application Packager uses the time property
to track changes for the channel.) As a result, the channel is marked for a minor
update, even though you have not really changed anything.
there is a need for a reboot, just like major updates. If Always reboot after
successful installation is selected, the application reboots the machine on
minor updates.
You can set scripts and dependencies to be triggered during minor updates in
the following places:
• In the Required Marimba Channels dialog box: Run on Minor Update
check box
• In the Required Registry Entries dialog box: Run on Minor Update check
box
• In the Required Files dialog box: Run on Minor Update check box
• In the New/Edit Script dialog box: Minor Update check box
For more information, see Configuring System and Channel Dependencies on page
112 and Customizing a Channel by Using Scripts and Classes on page 121.
Editing Services
If an application that you packaged includes services, you can edit the
properties of those services using the Services page in the Package Editor. You
can edit general properties such as the display name and startup configuration
of the service, as well as installation, uninstallation, update, verify installed,
verify uninstalled, and repair policies for the service.
▼ To edit a service:
1 In the Package Editor window, click the Services tab.
2 On the Services page, select a service and click Edit to change its
properties.
The NT Service Properties dialog box appears. For more information
about the properties you can change, see the descriptions for the various
tabs in the dialog box:
• General Properties Page on page 132
• Security Properties Page on page 133
• Advanced Properties Page on page 134
• Install Policies Page on page 134
• Uninstall Policies Page on page 135
3 Click OK to save your changes.
• to delete dependencies
If you do not want to use the global or default policy, choose Use a policy
below and select one of the following policies:
• Always update the service.
• Update service if it doesn’t exist.
• Update service only if it exists.
• Never update service.
Adding Services
If the application that you are packaging will be installed on Windows NT,
Windows 2000, or Windows XP, you can add services using the Services page
in the Package Editor.
▼ To add a service:
1 In the Package Editor window, click the Services tab.
2 On the Services page, click Add.
The Add New NT Service dialog box appears.
3 In the Add New NT Service dialog box, enter the information for the
service that you want to add.
4 Click OK.
The service you added now appears on the Services page.
Removing Services
You can remove one or more services from a channel using the Services page
in the Package Editor.
▼ To remove a service:
1 In the Package Editor Window, click the Services tab.
2 On the Services page, select a service and click Remove.
If you want to remove all listed services, click Remove All.
The service or services you remove no longer appear on the Services page.
Some of these channel parameters have default values; some are additional
parameters that are not found in the parameters.txt file by default. Entries in
the parameters.txt file have the form:
<channel_parameter>=<parameter_value>
For example:
silent=true
For a complete list of properties that you can use in a channel’s parameters.txt
file, refer to the Marimba Reference Guide on Marimba’s Documentation page at
www.marimba.com/doc/.
msi.ui.basic.progressonly
Valid values:
• DEBUG_PROCESS
• DEBUG_ONLY_THIS_PROCESS
• CREATE_SUSPENDED
• DETACHED_PROCESS
• CREATE_NEW_CONSOLE
• NORMAL_PRIORITY_CLASS
• IDLE_PRIORITY_CLASS
• HIGH_PRIORITY_CLASS
• REALTIME_PRIORITY_CLASS
• CREATE_NEW_PROCESS_GROUP
• CREATE_UNICODE_ENVIRONMENT
• CREATE_SEPARATE_WOW_VDM
• CREATE_SHARED_WOW_VDM
• CREATE_FORCEDOS
• BELOW_NORMAL_PRIORITY_CLASS
• ABOVE_NORMAL_PRIORITY_CLASS
• CREATE_BREAKAWAY_FROM_JOB
• CREATE_DEFAULT_ERROR_MODE
• CREATE_NO_WINDOW
Description: This parameter controls process creation on Windows
platforms when processes are created using the following methods:
• From the “Launch application from tuner” option under Configuration
> Startup in the Package Editor
• From executable script files (with the extensions .exe or .bat)
• From the -runexe command-line option for packaged applications
You can set the parameter to one or more of the keywords listed under
valid values. (Use a comma-delimited list if using more than one.)
For more information about these keywords, search for “process creation
flags” on the Microsoft website (http://msdn.microsoft.com).
run.install
Note: You cannot use the preload and nofilemap parameters together.
For more information about the package directory and its contents, including
the properties.txt and parameters.txt files, see Package Directory on page 18.
For a complete list of properties that you can use in a channel’s properties.txt
or parameters.txt file, refer to the Marimba Reference Guide on Marimba’s
Documentation page at www.marimba.com/doc/.
Tip: You can also set this parameter through the Configuration – Installer tab
by selecting the Delay download of files until pre scripts have run check box.
If you use this parameter, the channel download occurs in two parts. The
initial download only includes the installer and the manifest file (manifest.ncp),
which contains the code and instructions required to install and update the
application. After any pre- scripts have run, the second download brings over
the files necessary to install or update the application.
Note: If the packaged application contains any files that are added by
reference, then the delayfiledownload parameter does not take effect during
updates.
• logon.action=updatestart
You can set these properties by using Policy Manager. For more information,
see the section about setting package properties in the Policy Management
Administrator’s Guide.
Setting these properties causes the tuner at the endpoint to update and start
Policy Service when a user logs on. These properties ensure that the user-
specific objects are installed for each user who logs on to the machine and who
has been assigned the multi-user package through a policy.
Table 2. Behavior for Packages with the Multiple-User Feature Enabled (Continued)
• There are object mismatches. The tuner re-installs the affected files or
registry entries if they are available from the tuner storage. If not, the
tuner contacts the transmitter to download the files or registry entries
needed to complete the repair.
Verify and repair behavior is different for Windows Installer packages. For
more information, see Verify and Repair Behavior for Windows Installer Packages on
page 191.
Any object mismatches found are displayed in the Verification Results window.
In addition, if you choose Verify verbose, the Verification Results window
shows the files in the packaged application and the corresponding file objects
in the channel.
Note: Scheduled verify and repair usually does not require any user
interaction. At most, users may see a verify or repair progress bar displayed.
However, if the channel’s transmitter cannot be contacted, or the channel has
been updated and the needed files are no longer available, then the user is
informed that the transmitter cannot be reached.
For example:
runchannel http://acme.com:5282/MyChannel -repair
Note: The instructions in this section describe creating a text modifier group
for a text file that is not part of the channel you are editing. If the text file is
part of the channel you are editing, you do not need to create a text modifier
group separately. When you create a text modifier, the Package Editor creates
a text modifier group after asking you to provide a name. You do not need to
specify the path of the text file if it is part of the channel.
Also, if the file you specify is on a network drive, do not use the form
\\machine_name\directory. Instead map the network drive and use the
assigned drive letter (not the machine name) when you specify the file
path.
4 Click OK.
The text modifier group you created appears in the left-hand pane under
Text Modifiers.
You can now add one more text modifiers to this group.
• The text to insert or replace with. In the text, you can use any macros
defined in the channel. When you use macros within a string, make
sure you include a dollar sign ($) preceding and following the macro
name (for example, $macro_name$). Also, remember that macros are
case-sensitive. For more information about macros, see Using Macros on
page 82.
• The action to perform. You can choose from the following actions:
• Replace at. The entire line at the given line number is replaced
with the text you specify.
• Insert at. The text is inserted on the line that you specify. For
example, if you specify line number 4, the text you insert will
appear in that line. The text that used to be on that line will now
appear on line number 5.
• The line number in the text file. To insert a line at the end of the file,
use -1 for the line number.
4 Click OK.
The text modifier that you added appears in the right-hand pane.
a. In the Package Contents page, locate the text file that you want to
modify.
b. Right-click the text file and choose Add Text Modifier > Search and
Replace Line.
The New Text Modifier Group dialog box appears.
c. Enter a name for the text modifier group (for example,
application.ini Modifiers) and click OK. Notice that the Package
Editor has already filled in the path for the text file.
The New Search and Replace Line Modifier dialog box appears.
3 Enter the following information:
• A name for the text modifier (for example, Insert machine name)
• The text to search for. In the text, you can use any macros defined in
the channel. When you use macros within a string, make sure you
include a dollar sign ($) preceding and following the macro name (for
example, $macro_name$). Also, remember that macros are case-
sensitive. For more information about macros, see Using Macros on page
82.
• The search criteria. You can choose from the following criteria:
• Exact match. The text you specify must match the entire line of text
that you want to find in the text file.
• Starts with. The text you specify must match the beginning of the
line that you want to find in the text file. You must specify at least
the first character of the line that you want to find.
For example, if you want to find this line:
host=triad.marimba.com
Then, you can search for:
host, h, or host=
• Substring match. The text you specify must match part of the line
that you want to find in the text file. The text may appear
anywhere in the line, including the beginning and end, but you
must specify at least one character that appears in the line that you
want to find.
For example, if you want to find this line:
host=triad.marimba.com
Then, you can search for:
triad, host, com, t, or =
• Ends with. The text you specify must match the end of the line that
appears in the text file. You must specify at least the last character
of the line that you want to find.
Installation Policies
• Inherit policy from parent object.
• Always install modifier group.
Update Policies
• Inherit policy from parent object.
• Update if changed.
• Always reapply this modifier group.
• Never update modifier group.
Installation Policies
• Inherit policy from group.
• Always install modifier.
• Never install modifier.
Update Policies
• Inherit policy from group.
• Update if changed.
• If the text file to be modified is not part of the channel and the file does
not exist at the endpoint, the text modifier will not be installed. There is
no error message at the endpoint.
• Text modifiers cannot be used to modify Unicode or non-ASCII text files.
• Make sure you have write permission to the file (and that the file is not
locked) on the endpoints. Otherwise, the text modifier cannot make
changes to the file.
• Also, if the file you specify is on a network drive, do not use the form
\\machine_name\directory. Instead map the network drive and use the
assigned drive letter (not the machine name) when you specify the file
path.
Note: When you save a channel after making changes, the Package Editor
will prompt you to add a history entry before saving your changes. If you
select the “Do not show this prompt again” check box, you or other users
editing the channel will no longer be prompted to add a history entry when
saving changes. If you want to reset this feature, so that the prompt again
appears every time the channel is edited and saved, edit the parameters.txt
file by setting the editor.save.history.prompt.suppress property to false.
Note: When you specify the directory in which to create or save the channel,
make sure the directory does not already contain another channel. Otherwise,
the channel that you create may not be usable.
The following log IDs and messages indicate that some files in the channel may
have been corrupted and that the channel has attempted to recover so that the
channel can run correctly.
DOC
This chapter shows you how to use the Marimba Windows Installer Packager
to package Microsoft installations (MSI) created for the Microsoft Windows
Installer. It contains the following sections:
• Windows Installer Overview on page 170
• Packaging an MSI Database into a Channel on page 172
• Benefits and Limitations of Packaging Files by Reference on page 173
• Packaging an MSI Database with Merge Modules on page 175
• Customizing Windows Installer Packages on page 175
• Opening a Windows Installer Package in the Package Editor on page 176
• Setting the Installation Modes for Windows Installer Packages on page 176
• Advertising Windows Installer Applications on page 178
• Setting the User Interface Level for Windows Installer Packages on page 179
• Managing Patches for Windows Installer Packages on page 180
• Managing Transforms for Windows Installer Packages on page 182
• Setting the File Download Options for Windows Installer Packages on page 184
• Setting Windows Installer Policies on page 186
• Setting Windows Installer Logging on page 188
• Configuring Applications to Use the Windows Installer Command Line on page
189
The Windows Installer service ships as part of the Microsoft Windows 2000,
Windows XP, and Windows Millennium Edition (Windows ME) operating
systems; it can also be installed (from a redistributable on Microsoft’s website) on
Windows 95, Windows 98, and Windows NT version 4.0.
Installation database file. Each database file contains a database that stores all
the instructions and data required to install (and uninstall) the software across
many installation scenarios. For example, a database file could contain
instructions for installing an application when a prior version of the
application is already installed. The database file could also contain
instructions for installing the software on a computer where that application
has never been present. This file has a .msi file name extension.
In addition to a database file (also known as an MSI database or MSI file), a
Microsoft installation can also include the following other components:
• External source files or cabinet files required by the installation
Packaging Overview
The Marimba Windows Installer Packager enables you to package Microsoft
installations (MSI) that were created for the Microsoft Windows Installer.
Windows Installer Packager is useful if the software vendor provided it in
Windows Installer format (.msi), and the application does not require frequent
updates or changes. You might also want to use this packager if you do not
want to violate Microsoft Logo compliance.
Note: When you specify the directory in which to create or save the channel,
make sure the directory does not already contain another channel. Otherwise,
the channel that you create may not be usable.
For example, when you use the Delete downloaded files option for your
Windows Installer package, any files downloaded for the installation are
deleted once the installation is complete. Later, if the Windows Installer
package requires a repair, the repair operation must connect to the transmitter
to download any needed files because the files that were previously
downloaded during the installation have been deleted.
For the repair operation to succeed, you need to run an administrative
installation of the MSI application before you create a Windows Installer
package. The administrative installation allows you to extract any source files
that have been included with the MSI database file. Extracting these source
files and separating them from the MSI database file allows you to take
After you have performed, the administrative installation, you can use the
Windows Installer Packager to package the MSI application (see Packaging an
MSI Database into a Channel on page 172).
These sections assume that you have created the Windows Installer package
(see Packaging an MSI Database into a Channel on page 172) and opened the
Windows Installer package in the Package Editor. For information about
opening Windows Installer package in the Package Editor, see Opening a
Windows Installer Package in the Package Editor on page 176.
When users subscribe to the package, the application is advertised but not
installed.
If a package is set to advertise and on an update the Advertise application
check box is cleared, the application on the endpoint will be installed.
• Do not display the Cancel button (MSI 2.0 and above only) —
Select this check box to hide the Cancel button on progress dialog
boxes. This option is only available with Windows Installer 2.0 and
later.
• Reduced — Choose this option to suppress authored modal dialog
boxes. The reduced UI still shows authored modeless dialog boxes and
built-in modal error message boxes. Modal dialog boxes require user
input before the installation can continue and are specified by setting
the Modal Dialog Style Bit in the Attributes column of the Dialog
table. A modeless dialog box does not require user input for the
installation to continue.
• Full — Choose this option to show all authored, progress, and error
dialog boxes. A full UI commonly exhibits user interface wizard
behavior.
5 If you want to display a dialog box that shows whether or not the
installation was successful, select the Display success/failure dialog at
end of install check box.
This option is useful if you specify a silent installation (UI level is none),
but want to see a confirmation at the end of installation.
6 If you want to display the dialog boxes used for source resolution even if
you specify a silent installation (UI level is none), select the Force display
of source resolution even if quiet (MSI 2.0 and above only) check box.
Because Windows Installer already displays the source resolution dialog
boxes for the other UI levels, this option has no effect if the UI level is not
none. This option is only available with Windows Installer 2.0 and later.
6 If you want the Windows Installer to reinstall the application if the patch
list shown for the Windows Installer package is different from the one
found on the target system, select the Force reinstall if patch list changes
check box.
By forcing a reinstall, you can ensure that the target system hosts a stable
version of the application. If you don’t force a reinstall, only the new
patches are applied.
Note: When you package an MSI database for silent installation, you can use
transforms created by third-party tools to control what is installed. When you
create the transforms, make sure that the tool you use creates transforms that
can be applied during a silent installation.
7 In the Path text box, enter paths for directories in which transform files
are stored. Separate the path names with semicolons.
During the download, all .mst files found in these locations will be added
to the transform list during installation.
8 If you want the Windows Installer to reinstall the application if the
transform list changes, select the Force reinstall if transform list changes
check box.
Transforms can only be applied to applications during installation, so this
option is useful if you want to remove the previously installed application
and reinstall it with the new transform list.
• Download .msi file only — Select this option to download only the
MSI database file and associated patches and transforms. During
installation or repair, the Windows Installer gets files from a
transmitter or another source location that you have specified using
the Alternate source or Additional sources text boxes described in the
following steps. For best results, use this option with an administrative
installation point (AIP), which is usually a shared directory on a
network server, from which the Windows Installer can get additional
files.
4 If you want to specify an alternate source from which the Windows
Installer will get files when installing or repairing an application, specify
the source location in the Alternate source text box. You can enter a URL
or a network path in the Universal Naming Convention (UNC) format (for
example, \\servername\sharename\path\directory_containing_MSI_file or
\\ipaddress\sharename\path\directory_containing_MSI_file).
Note: These policies are applied only when the tuner is operating under an
account with the appropriate system privileges.
Note: If a file already exists on the endpoint with the same name and path as
the one you specified, the file will be overwritten. However, if a directory
already exists on the endpoint with the same name and path as the log file
you specified, the log file will be created with a unique name. For example, if
you specify the log file path C:/msi.log and there is a directory named
msi.log in the C:/ root directory, the log file will be created with a unique
name, such as C:/msi.log-ncp-0.
Note: When you use the Windows Installer command line and bypass the
Windows Installer APIs, you should choose the Download all files option on
the Windows Installer - Download tab in the Package Editor. When
bypassing the Windows Installer APIs, some of the customizations to the
installation using the Package Editor pages under the Windows Installer tab
(Installation, UI Level, Patches, Transforms, Policies, and Logging) will not be
applied.
In the example given, when endpoints download and install the Windows
Installer package, the command and arguments you specified will be used.
Note: You can only repackage Windows Installer packages that were created
using Application Packager version 4.7.2 and higher.
to include the entire repeater list so that if files are not cached locally by
Windows Installer, it will connect to the repeaters instead of the master
transmitter.
• Update time. At every major or minor update, the Windows Installer
channel will reset the Windows Installer source list with any changes in
the repeater list.
• Repair time. When a repair is triggered through the Marimba
infrastructure, the Windows Installer channel will first validate the
repeater list, refreshing it.
• New action. Installed Windows Installer channels will accept a new
argument -refreshsourcelist (see -refreshsourcelist on page 276) on
endpoints to get a new repeater list and reset the repeater being used.
Depending on whether the particular repeater (from which a channel is
subscribed) is available or not, the Windows Installer may download files from
a different repeater. If all of the repeaters are down, then the Windows Installer
channel will default to the master transmitter as its URL source and the
Windows Installer will download the file from it during installation. The same
behavior occurs during repairs and updates if the Windows Installer
application is reinstalled. The master transmitter and all the repeaters must be
version 4.7.1.1 or higher for the Windows Installer to use them as sources.
Figure 1. on page 193 shows how the Windows Installer application’s source
location is set the first time a channel is installed:
2
1
3 Channel
Tuner
4
Windows
Installer
Repeater 1 Repeater 2
Endpoint Machine
Master
Transmitter
1 The tuner requests and gets an Windows Installer channel from a repeater.
2 The tuner passes the repeater information (including the list of repeaters)
to the channel.
3 The channel (specifically the adapter) passes the repeater information to
Windows Installer.
4 Windows Installer identifies the repeaters in the list as sources. It will
connect to those repeaters when it needs source files for installation,
update, or repair.
Figure 2. on page 194 shows how the Windows Installer application’s source
location is refreshed when repeater information changes:
1 2
3
5 4
External Channel
channel or Tuner
script
6
Windows
Installer
Repeater 1 Repeater 2
Endpoint Machine
Master
Transmitter
Figure 2. Refreshing the source location for an Windows Installer application when repeater
information changes
DOC
Note: When you specify the directory in which to create or save the channel,
make sure the directory does not already contain another channel. Otherwise,
the channel that you create may not be usable.
DOC
File Packager is one of the packagers included with Application Packager. The
Application Packager window allows you to start File Packager and assemble a
group of files into a channel. After packaging the channel, you publish it to
make it available to end users.
File Packager is best suited for packaging directories of files. Typically, you use
File Packager with spreadsheets, HTML files, templates, and other file types
that people want to view on their local system. You can also use File Packager
to redistribute the load from a heavily accessed file server to a group of file
servers that mirror the original. It helps keep files up to date on any number of
endpoints.
After the files are published as a channel and installed using a tuner, they can
be used normally on the endpoint. However, changes that you make to the
files will be overwritten by the next channel update. Accordingly, File Packager
is best suited to files that are to be viewed and not modified.
You can configure the channel to launch an application that can be used to
view the files. Running the channel from the tuner launches the configured
application.
Currently, File Packager produces channels that are platform specific. For
example, if you package a channel using File Packager on Windows
(95/98/NT), UNIX users will not be able to use the channel that you publish. If
you need to support multiple platforms, you’ll need to create a version of the
channel on each platform that you want to support.
You can also use File Packager from the command line. For more information,
refer to File Packager Command-Line Options on page 262.
Note: When you specify the directory in which to create or save the channel,
make sure the directory does not already contain another channel. Otherwise,
the channel that you create may not be usable.
10 (Windows only) If you want INI files to be treated as special file objects,
select the Parse INI files check box.
Application Packager parses the INI files and captures any changes made
to the key and value pairs in them. Any changes found by Application
Packager are merged with the existing file found at the endpoint. By
default, this check box is selected. If you want Application Packager to
process INI files as ordinary files and not merge changes, you can clear
this check box. For more information, see Working with INI Files on page 66.
11 Repeat Step 5–Step 9 for each directory that you want to include in the
channel you are packaging.
If you want to remove a directory that you have added, select it from the
list and click Remove.
12 If you want to launch an application when the channel runs, select the
Channel launches this application option and enter the path of the
application executable. The application that you specify starts when the
channel is started.
If you want more control over when the application is launched, you may
want to add some properties to the channel. In the package directory,
open the parameters.txt file using a text editor and add one or both of
these properties:
• run.install=true
• run.update=true
These properties control whether the specified application should be
launched after the initial installation or after updates (both major and
minor). For more details, see run.install and run.update on page 140,
in the section Editing the Parameters of a Channel on page 137.
13 If you want to specify any arguments or a working directory for the
application, click Configure and enter any arguments or the name of the
working directory.
14 After selecting and configuring the directories that you want to include in
the channel, click Package.
The files are assembled and the package directory is prepared for
publishing.
15 If you want to edit the properties and contents of the channel, click Edit to
start the Package Editor.
For more information about editing the channel, refer to Using the Package
Editor on page 55.
16 If you are ready to publish the channel that File Packager has prepared,
click Publish. (You are not required to publish the channel now. File
Packager has prepared the package directory; you can publish it at any
time.)
The publishing wizard appears and guides you through the process of
publishing the channel. For more information, refer to Publishing Channels
on page 243.
17 Return to the File Packager window and click Done.
Updating a Channel
To make it easier to publish updates of the channels you create, File Packager
offers the following options:
• Reconfigure. Choose this option if you need to add or remove directories
from your File Packager channel. You should also choose this option if
you want to reconfigure the default installation path, user prompt, and
application settings in your File Packager channel.
• Repackage only. Choose this option if only files (not directories) have
changed in your File Packager channel, and you do not want to publish
the channel yet. This option does not republish the channel; as its name
implies, it only repackages the channel (that is, it gathers the set of
required files into a package directory for publishing). You should choose
this option if you want to publish your repackaged channel to a
destination different from where you originally published it. For example,
you should use this option if you originally published the channel to your
staging transmitter and now you want to publish the repackaged channel
to the production transmitter.
• Repackage and Publish. Choose this option if only files (not directories)
have changed in your File Packager channel, and you want to publish the
channel to the same destination where you originally published it. This
option automatically publishes the repackaged channel to the destination
where you previously published it.
4 Click Repackage and choose Reconfigure from the pop-up menu that
appears.
The channel that you selected opens in File Packager.
5 Use File Packager to add and remove directories from the channel. You
can also configure other settings for the channel. For more information,
refer to Packaging a Set of Files into a Channel on page 200.
When you have finished making changes to the channel, you can package
and publish it.
DOC
This chapter shows you how to use the Marimba .NET Packager to package
.NET applications. It contains the following sections:
• .NET Packager Overview on page 205
• Components of .NET Applications on page 206
• Packaging a .NET Application on page 207
• Editing a .NET Packager Channel on page 210
• .NET Assembly Properties on page 211
• Properties Page on page 211
• Application Policy Configuration Page on page 212
• Adding Virtual Directories for Internet Information Services on page 216
• Updating a Channel on page 217
You use .NET Packager to specify the files and directories that make up the
.NET application. If you have used the File Packager component of Application
Packager previously, using .NET Packager will be very familiar. After
packaging, you can use the Package Editor to set the configuration for the
application. Then, you can publish the packaged application or channel to a
transmitters, so that it can be distributed to other machines.
Note: When you specify the directory in which to create or save the channel,
make sure the directory does not already contain another channel. Otherwise,
the channel that you create may not be usable.
Note: If you use the Package by Reference option, you cannot transfer
Windows permissions.
9 (Windows NT, Windows 2000, and Windows XP only) If you want the
files in the directory you are packaging to retain their original Windows
file permissions, select the Transfer Windows NT Permissions check box.
Windows supports two kinds of file systems: FAT and NTFS. The latter
offers more advanced file permission settings. To take full advantage of
this option, both the person who is creating the channel and the end user
must be using an NTFS file system. Otherwise, only basic Windows file
permissions or attributes (read-only, archive, hidden, system) are
preserved.
Note: End users installing the channel must have administrative
privileges to set permissions.
10 If you want INI files to be treated as special file objects, select the Parse
INI files check box.
Application Packager parses the INI files and captures any changes made
to the key and value pairs in them. Any changes found by Application
Packager are merged with the existing file found at the endpoint. By
default, this check box is selected. If you want Application Packager to
process INI files as ordinary files and not merge changes, you can clear
this check box. For more information, see Working with INI Files on page 66.
11 Repeat Step 5–Step 9 for each directory that you want to include in the
channel you are packaging.
If you want to remove a directory that you have added, select it from the
list and click Remove.
12 If you want assembly policy configuration files to be treated as special file
objects, select the Parse assembly policy configuration files check box.
13 After selecting and configuring the directories that you want to include in
the channel, click Package.
The files are assembled and the package directory is prepared for
publishing.
14 If you want to edit the properties and contents of the channel, click Edit to
start the Package Editor.
For more information about editing the channel, refer to Using the Package
Editor on page 55.
15 If you are ready to publish the channel that .NET Packager has prepared,
click Publish. (You are not required to publish the channel now. File
Packager has prepared the package directory; you can publish it at any
time.)
The publishing wizard appears and guides you through the process of
publishing the channel. For more information, refer to Publishing Channels
on page 243.
16 Return to the .NET Packager window and click Done.
Note: If you import and edit a channel that was packaged using a previous
version of Application Packager, you will be asked if you want to upgrade
the channel. You must upgrade the channel before you can edit it with the
current version of Application Packager.
• Select a file with a .config file extension, right-click the file, and
choose Properties from the pop-up menu that appears.
These files usually appear with the XML assembly policy
configuration icon .
The .NET Assembly Properties or .NET Assembly Policy Configuration
Properties dialog box appears. You can use the various pages in this
dialog box to configure assembly properties. For more information, refer
to .NET Assembly Properties on page 211.
Properties Page
Use this page to register an assembly into the global assembly cache (GAC)
and to view properties for an assembly.
Register assembly into Global Assembly Cache (GAC) — Select this check
box to register an assembly into the GAC and to make the assembly available
to other applications. The GAC stores assemblies specifically designated to be
shared by several applications on the computer.
This page shows the following .NET assembly properties:
• Name
• Version
• Locale
• Public key token
Using .NET Packager 211
.NET Assembly Properties
Assembly Binding
This page contains information about assembly version redirection and the
locations of assemblies. The text box specifies the XML namespace required for
assembly binding. The default is the string urn:schemas-microsoft-com:asm.v1.
Publisher Policy
This page specifies whether the runtime applies the publisher policy for one or
more assemblies. The publisher policy determines which version of an
assembly applications use. When an assembly vendor releases a new version of
an assembly, the vendor can include a publisher policy so applications that use
the old version now use the new version. You can specify whether to apply
publisher policy in the application's configuration file for either a specific
assembly or all assemblies the application uses.
Enable property — Select this check box to specify whether to apply the
publisher policy. By default, this check box is selected.
Apply publish policy for all assemblies — Select this check box to specify
whether to apply the publisher policy for all assemblies the application uses.
By default, this check box is selected.
Probing
This page specifies application base subdirectories for the common language
runtime (CLR) to search when loading assemblies.
Garbage Collection
This page specifies whether the runtime runs garbage collection concurrently.
If your application is single-threaded and involves heavy user interaction,
leave concurrent garbage collection enabled so the application does not pause
to perform garbage collection. If your application is a server application that is
heavily multithreaded and is not user-interface intensive, turn off concurrent
garbage collection to improve performance.
Enable property and Use concurrent garbage collection — Select these check
boxes to specify whether the runtime runs garbage collection concurrently. By
default, both check boxes are selected.
Dependent Assemblies
This page specifies the dependent assemblies along with their binding policy
and location. For each dependent assembly, this page shows the following
information:
• Name
• Culture
• Public key
• Publisher policy
Add — Click to add a dependent assembly to the configuration file. A dialog
box appears, where you can specify information for the assembly.
Edit — Click to edit the selected dependent assembly. A dialog box appears,
where you can change the information for the assembly.
Remove — Click to remove the selected dependent assembly from the
configuration file.
Specify culture — Select the check box, and, in the text box, enter a string that
specifies the language and country/region of the assembly (for example, en-us
for English-United States).
Specify public key — Select the check box, and, in the text box, enter a
hexadecimal value that specifies the strong name of the assembly (for example,
32ab4ba45e0a69a1).
Code Base
Specifies where the common language runtime can find an assembly. For the
runtime to use the codebase setting in a machine configuration file or publisher
policy file, the file must also redirect the assembly version. Application
configuration files can have a codebase setting without redirecting the
assembly version. After determining which assembly version to use, the
runtime applies the codebase setting from the file that determines the version.
If no codebase is indicated, the runtime probes for the assembly in the usual
way.
If the assembly has a strong name, the codebase setting can be anywhere on the
local intranet or the Internet. If the assembly is a private assembly, the
codebase setting must be a path relative to the application's directory.
Version/Name — Specifies the version of the assembly the codebase applies to.
The format of an assembly version number is major.minor.build.revision.
Valid values for each part of the version number are 0 to 65535 (for example,
2.0.0.0).
HREF/Location — Specifies the URL where the runtime can find the specified
version of the assembly (for example,
http://www.litwareinc.com/myAssembly.dll) .
Redirection
Redirects one assembly version to another. When you build a .NET framework
application against a strong-named assembly, the application uses that version
of the assembly at run time by default, even if a new version is available.
However, you can configure the application to run against a newer version of
the assembly. For details on how the runtime uses these files to determine
which assembly version to use, see Microsoft’s .NET documentation.
You can redirect more than one assembly version by including multiple
redirection elements in a dependent assembly element.
Old version — Specifies the version of the assembly that was originally
requested. The format of an assembly version number is
major.minor.build.revision. Valid values for each part of this version number
are 0 to 65535 (for example, 1.0.0.0).
You can also specify a range of versions in the following format:
n.n.n.n - n.n.n.n
New version — Specifies the version of the assembly to use instead of the
originally requested version in the format: n.n.n.n (for example, 2.0.0.0).
Publisher Policy
This page specifies whether the runtime applies the publisher policy for a
particular assembly. The publisher policy determines which version of an
assembly applications use. When an assembly vendor releases a new version of
an assembly, the vendor can include a publisher policy so applications that use
the old version now use the new version.
Enable property and Apply publisher policy for dependent assembly —
Select these check boxes to specify whether to apply the publisher policy to this
particular assembly. By default, these check boxes are not selected.
Development Mode
This page specifies whether the runtime searches for assemblies in directories
specified by the DEVPATH environment variable.
Important! Use this setting only at development time. The runtime does not
check the versions on strong-named assemblies found in the DEVPATH. It
simply uses the first assembly it finds.
Enable property and Use development mode — Select these check boxes to
search for assemblies in directories specified by the DEVPATH environment
variable. By default, neither check box is selected.
Assembly Qualifiers
This page specifies the full name of the assembly that should be dynamically
loaded when a partial name is used. Calling the Assembly.Load method using
partial assembly names causes the common language runtime to look for the
assembly only in the application base directory. Add assembly names to this
page to provide the full assembly information (name, version, public key
token, and culture) and cause the common language runtime to search for the
assembly in the global assembly cache. This page displays the following
information:
• Partial name — Specifies the partial name of the assembly as it appears in
the code. It must partially reference an assembly. You must specify at least
the assembly’s text name (the most common case), but you can also
include version, public key token, or culture (or any combination of the
four, but not all four). The partial name must match the name specified in
your call. For example, you cannot specify math as the partial name and
call Assembly.Load(“math, Version=3.3.3.3”) in your code.
• Strong name — Specifies the full name of the assembly as it appears in the
global assembly cache. It must include the four fields of assembly identity:
name, version, public key token, and culture.
Example:
Partial name=math
Strong name=
math,version=1.0.0.0,publicKeyToken=a1690a5ea44bab32,culture=neutral
The IIS virtual directory that you added appears in the Package Contents page.
Updating a Channel
To make it easier to publish updates of the channels you create, .NET Packager
offers the following options:
• Reconfigure. Choose this option if you need to add or remove directories
from your .NET Packager channel. You should also choose this option if
you want to reconfigure the default installation path, user prompt, and
application settings in your .NET Packager channel.
• Repackage only. Choose this option if only files (not directories) have
changed in your .NET Packager channel (for example, if you’ve added,
changed, or removed some files from the directories already included in
the channel). This option repackages the files and directories, but it retains
any settings you previously made to the channel using Package Editor.
Before repackaging, you need to save the previous configuration of the .NET
Packager channel in an XML template file so that it can be used on a
subsequent repackage. After the .NET Packager channel has been repackaged
with updated content, the XML template file is applied to restore the previous
configuration.
DOC
Java Packager is one of the packagers included with Application Packager. Java
Packager allows you to:
• package a Java application into a channel
• run a channel packaged with an alternate Java Virtual Machine (JVM)
Normally, channels run using the tuner’s Java Virtual Machine (JVM). Java
Packager supports this feature too, but it also allows you to specify an alternate
JVM for your Java application. The following restrictions apply:
• The JVM you specify must be supported by Java Packager.
The list of currently supported JVMs appear in the drop-down list on Java
Packager’s External JVM Selection page.
• The JVM must already be installed on the endpoint. This tool does not
install alternate JVMs.
• The redirection of standard input to a Java application is not supported, so
you cannot use Java Packager for console-only Java applications that
require standard input from users.
After packaging your channel, you can publish it to a transmitter as a channel.
End users can use their tuner to subscribe, start, and update your channel.
When your channel is started, the JVM in which it runs should be transparent
to the end user.
Note: When you specify the directory in which to create or save the channel,
make sure the directory does not already contain another channel. Otherwise,
the channel that you create may not be usable.
3 Click Next.
4 Click Browse and select the directory that contains the Java application.
Then click Next.
You can type the path of the directory if you prefer.
5 Set the basic publish properties:
a. In the Title of the Application box, type the name that you want to
appear in the tuner’s channel list area for your application.
b. In the Main Class box, type the name of the class that starts your
application. Do not include the .class extension.
c. In the Classpath box, type the relative path and file name of any zip
files that are needed by the application and should be published as
part of your application.
The classpath you specify is applied to the end user’s environment
each time your application runs. Use a slash (“/”) as the path
separator (for all platforms). If you have multiple classpath entries,
separate them using a colon.
For example, if your application’s source directory is c:\new_app and it
uses c:\new_app\extras\zips\xyz.zip, your classpath should be set to
extras/zips/xyz.zip (the relative path to the zip file).
d. From the Please select the type of application drop-down list, select
the application type.
• If your application was designed to run as a channel, select
Marimba Application. (An application that is designed to run as a
channel must implement Marimba’s IApplication interface.)
• If you are packaging a standard Java application, select static
main() class. (A standard Java application doesn’t use Marimba’s
APIs and uses the conventional static main() as its entry point.)
6 Click Next.
7 Select the run mode for your Java application channel:
• Run the channel in the tuner. Select this option if you want to run your
channel in the tuner using the tuner’s JVM.
If you choose this option, the channel uses the same version and type
of JVM as the tuner. For example, if the tuner is using JRE version
1.1.8, then selecting this option makes the channel use JRE version
1.1.8 as well.
• Run the channel in an external JVM, but keep channel files in the tuner.
Select this option if your channel is required to run in a particular
version of a JVM, but you want to store the channel files in the tuner.
The required JVM must be pre-installed on the end user’s system. If
you choose this option, the channel files are stored in the tuner’s
workspace directory, a tuner-controlled area of the end user’s file
system where channels are saved in a proprietary file format. This is
the recommended option when running in an external JVM because it
makes the most efficient use of end-user disk space.
• Run the channel in an external JVM, and copy the files into the
filesystem. Select this option if your channel is required to run in a
particular version of a JVM, and you want to copy the channel files to
the end user’s standard file system (that is, outside of the tuner’s
workspace directory).
The required JVM must be pre-installed on the end user’s system. If
you choose this option, you might have duplicate storage of your
channel files. Your channel accesses files and classes based on the
current working directory. This option also circumvents the use of a
class loader, which is required by some applications.
Note: In Application Packager 4.7.2.1 and earlier releases, the working
directory is currently set to the current process, not the data directory
where the main class files are. Any packaged files under the data
directory are not accessible by the main class. In Application Packager
4.7.2.2 and later releases, the current working directory is now set to
the path: <channel_data_directory>\channel. If creating that directory
fails or that path is not a directory, then the current working directory
is set to: <channel_data_directory>.
8 Click Next.
9 If your Java channel requires particular version of a JVM, select the
external JVM for your channel:
• If you want to run the channel in a separate instance of the same JVM
used by the tuner, select Use the JRE included with the tuner.
This option is intended for those who want to use the same JVM as the
tuner while minimizing the risk that their application might crash the
tuner. For example, you might be running a transmitter on the same
tuner as your application and want to minimize the risk that the
transmitter would become unavailable to endpoints.
• If you want to run your application in one of the supported external
JVMs, select Use a pre-installed JVM. Then select a JVM and version
from the associated drop-down lists.
If the JVM you want to use is not listed, it cannot be used with Java
Packager at this time. The JVM you select must already be present on
the endpoint; Java Packager does not install external JVMs. This option
is available on Windows only.
10 Click Next.
11 If you are ready to publish the channel that Java Packager has prepared,
click Publish. You are not required to publish the channel now. Java
Packager has prepared the package directory and you can publish it at any
time.
The publishing wizard appears, preloaded and displaying the properties
of the channel you just assembled. You can use the channel-signing page
to set the security options for your channel. You can also edit other
channel properties before publishing the channel to your transmitter. For
more information, refer to Publishing Channels on page 243.
12 Return to the Java Packager window and click Done.
Note: If your channel is configured to use the same instance of the JVM that
the tuner is using, then you cannot pass any arguments.
The syntax for typing the arguments on the Parameters page is:
vm.extraargs=<JVM_arg>
where <JVM_arg> is the argument you want to pass. Do not type the angle
brackets (< >) with your command.
If you have multiple arguments to pass to the JVM, you can append them to
the same command, separating each argument with a space. For example,
vm.extraargs=<JVM_arg1> <JVM_arg2> <JVM_arg3>
Updating a Channel
If a Java application you have packaged changes after publishing, you can
publish an updated channel using the latest version of the Java application.
End users will receive your updated channel automatically when their tuner
checks for updates (at its scheduled time) or when they manually update the
channel.
If the changes are simple, such as one of the class files has been modified, you
can bypass Java Packager and use Channel Copier to republish the channel
directly. Make sure the new class file is in the source directory that Java
Packager prepared, and then republish the channel.
If you want to change the JVM specifications or make substantial changes to
the way the Java application channel is packaged, you can edit the channel
using Java Packager and then republish the channel. For more information,
refer to Editing a Java Packager Channel on page 226.
DOC
The PDA Packager allows you to package either directories of files or PDA
(personal digital assistant) applications in the form of CAB files. Directories of
files might include HTML files, text files, or even .exe files. The CAB file
format is a format often used for applications that run on mobile devices. The
specific supported platform for CAB files is Strong Arm 1100.
Note: When you specify the directory in which to create or save the package,
make sure the directory does not already contain another package.
Otherwise, the package that you create may not be usable.
• Verify of applications
• Shortcut creation
• Check for sufficient disk space
• Check for dependencies
• Policy support (for example, install policies and update policies)
• Adding files by reference
Note: Before you use the PDA Packager to package a CAB file, you need to
find out the exact name of the installed application. Therefore, first install the
application on one mobile device by using ActiveSync, as you would if you
did not have Marimba products. Then use the mobile device’s Remove
Programs list to find the complete name of the application, and use that
name in the PDA Packager. (To find the Remove Programs list, on the mobile
device tap Start > Settings > System > Remove Programs.)
b. In the Install Path text box, type the desired path to the installation
directory that you want to use on the mobile device.
In most cases, you will want to use a short path. For example, if you
package C:\Program Files\Microsoft ActiveSync\MyApplication, you
will probably want the install path to be \MyApplication.
Tip: If you want to install the contents of multiple source directories to
the same directory on the endpoint, you can specify the same
installation directory for multiple source directories.
c. If you want to package a directory by reference and not include its
contents in the channel until publish time, select the Package by
Reference check box.
When you package a directory by reference, directory contents reside
on the local file system and are not added to the channel until publish
time. This is useful when you are packaging an application that
includes large files. When you add files to a channel, their contents are
copied to the package directory. As a result, the storage required by
the channel is at least the total size of the original files. The additional
storage can be significant, especially for large files. However, if you
add files by reference, you do not need the additional storage because
the contents of the files are not stored in the package directory.
Packaging by reference does not affect end users.
d. Repeat Step a–Step c for each directory that you want to include in the
channel you are packaging.
6 If you want to package a CAB file:
a. Click Add CAB, and browse to the CAB file you want to package.
In some cases, you will need to select the CAB file that corresponds to
the supported platform, which is Strong Arm 1100.
b. In the App Name text box, type the name of the application.
Tip: In order to find out what the application name should be, first
install the application on one mobile device by using ActiveSync, as
you would if you did not have Marimba products. Then use the
mobile device’s Remove Programs list to find the complete name of
the application, and use that name in the PDA Packager. (To find the
Remove Programs list, on the mobile device tap Start > Settings >
System > Remove Programs.)
c. If you want to package a CAB file by reference, select the Package by
Reference check box.
d. Repeat Step a–Step c for each CAB file that you want to include in the
channel you are packaging.
7 After selecting and configuring the directories or CAB files (or both), click
Package.
The files are assembled and the package directory is prepared for
publishing.
8 If you are ready to publish the channel that the PDA Packager has
prepared, click Publish. (You are not required to publish the channel now.
the PDA Packager has prepared the package directory; you can publish it
at any time.)
The publishing wizard appears and guides you through the process of
publishing the channel.
9 Complete the wizard pages to publish the channel to the transmitter of
your choice. Each wizard page contains a Help button that can give you
information about the fields on that page.
10 Once the channel has been successfully published and you are returned to
the PDA Packager window, you can exit the Application Packager.
• Repackage and Publish. Choose this option if only files (not directories)
have changed in your channel, and you want to publish the channel to the
same destination where you originally published it. This option
automatically publishes the repackaged channel to the destination where
you previously published it.
DOC
XML template files allow you to save, modify, and apply default settings and
configurations for Application Packager. These settings include installation
policies, macros, scripts, installation modes, and other settings that can apply
to multiple applications.
This chapter contains the following sections:
• Saving Your Package Editor Settings to an XML Template File on page 233
• Configuring Application Packager to Use an XML Template File for Default Settings
on page 234
• Using XML Template Files with Packager for Shrinkwrap Windows Applications on
page 235
• Applying an XML Template File to Existing Channels on page 240
For information about the tags that you can use in XML template files, refer to
Appendix C: XML Syntax on page 311.
Once you’ve saved your settings to an XML template file, you can use that file
to apply the settings to an existing channel. You can also apply those settings
to future channels that you create by setting the XML template file as the
default template for Application Packager.
The following items are not saved out to the XML template files:
• scripts
• text modifier groups and text modifiers
• MSI patches
• MSI transforms
The file you specified is now used everytime you package an application.
Later, if you decide to use again the default XML template file that originally
shipped with Application Packager, you can do so by following these
instructions:
• Example: Configuring the Default Settings for Newly Packaged Channels on page
239
• Example: XML Template Files to Use with Snapshots on page 237
8 In the dialog box that appears, select the XML template file you want to
use. The file contains the default filters you want Packager for Shrinkwrap
Windows Applications to use when taking snapshots.
For more information about the tags you need to use in the XML template
files, refer to Snapshot Tags on page 364.
Saving and Setting Configuration and Filters Using XML Template Files
On the Snapshot Customization Options page, you have the following XML
template file options:
• Save User Configuration and User-Defined Filters. Click to save the current
configuration and user-defined filters used by Packager for Shrinkwrap
Windows Applications to an XML template file that you can reuse. This
includes any configurations that you have set on the File System Selector
page, the Registry Selector page, and the Metabase Selector page. Later,
you can reuse those configuration and filters when packaging other
applications.
• Save Default Filters. Click to save the current default filters used by
Packager for Shrinkwrap Windows Applications to an XML template file
that you can reuse. This includes any filters on the File System Selector
(also Registry and Metabase) - Default Ignore page. Later, you can set
Packager for Shrinkwrap Windows Applications to use this XML template
file as the source for default filters.
• Set Default Filters Template. Click to select an XML template file and
configure Packager for Shrinkwrap Windows Applications to use the
default filters in that XML template file when taking snapshots. The filters
specified in the XML template file appears in the File System Selector (also
Registry and Metabase) - Default Ignore page. Note that the XML
template file that you select is used by the packager everytime you take
snapshots until you unset the XML template file.
• Unset Default Filters Template. Click to unset the XML template file that
you (or another user) previously configured Packager for Shrinkwrap
Windows Applications to use as the source for the default filters. Clicking
this button allows you to go back and use the default filters that originally
shipped with Application Packager.
The following XML template file contains examples of filters that you can use
to ignore directories, files, registry entries, and metabase entries:
<SNAPSHOT>
<FILESYSTEM>
<FILTER enabled="true" verb="is" adverb="$SYS.WINDOWS" noun="parent"
description="Windows NT backup directories" type="directory">
<FILTER enabled="true" verb="begins_with" adverb="$Nt" noun="name"
description="" type="directory"/>
</FILTER>
<FILTER enabled="true" verb="is" adverb="temp" noun="name"
description="TEMP directory" type="directory"/>
<FILTER enabled="true" verb="is" adverb="tmp" noun="name"
description="TMP directory" type="directory"/>
</FILESYSTEM>
<REGISTRY>
<FILTER enabled="true" verb="is"
adverb="\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Pol
icies\System" noun="path" description="System Boot&Logon Message"
type="key"/>
<FILTER enabled="true" verb="is"
adverb="\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Expl
orer\SessionInfo" noun="path" description="Explorer's Session
Information" type="key"/>
<FILTER enabled="true" verb="is" adverb="\HKEY_LOCAL_MACHINE\SYSTEM"
noun="parent" description="\HKLM\System except for CurrentControlSet"
type="key">
<FILTER enabled="true" verb="isn't"
adverb="CurrentControlSet" noun="name" description="" type="directory"/>
</FILTER>
<FILTER enabled="true" verb="is"
adverb="\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet" noun="parent"
description="\HKLM\System\CurrentControlSet except for Services"
type="key">
<FILTER enabled="true" verb="isn't" adverb="Services"
noun="name" description="" type="directory"/>
</FILTER>
</REGISTRY>
<METABASE>
</METABASE>
</SNAPSHOT>
where
<channel_directory>
specifies the full path of the directory where you want to place the
contents of the new channel that you are creating.
<paths_of_XML_template_files>
specifies the paths of the XML template files that you want to apply to
the channel. If you want to use more than one XML template file,
separate the paths with semicolons (;).
For example:
runchannel http://acme.com:80/Marimba/ApplicationPackager
-applytemplate “C:\Channels\MyCustomChannel”
“C:\Channels\Templates\shrinkwrap.xml;
C:\Channels\Templates\policies.xml;
C:\Channels\Templates\macros.xml”
DOC
▼ To publish a channel:
1 After creating the channel using Application Packager, click Publish.
This starts the channel publishing wizard, which guides you through the
process of publishing a channel.
2 Select a signing option for the channel you are publishing:
• Sign using this certificate. Choose this option to sign a channel using a
selected certificate. You can use the drop-down list to select a
certificate.
• Do not sign this channel. Choose this option if you do not want to sign
the channel.
Click Next.
3 If desired, enter values for the basic properties of the channel:
• Title. This is the name of the channel displayed in the tuner. It can be
an ASCII string, but you should be brief—the tuner might truncate the
title if it’s too long.
• Description. This is any text description that you want to include. This
can include contact or support information.
• Category. This is the name of the tuner category where you want the
channel to appear. If the category does not exist in the end user’s
tuner, the tuner creates the category when the user subscribes to the
channel. If you have a category name that you want shared by
multiple channels, make sure you type the name exactly. Categories
are case-sensitive.
• Author. This is usually the name of the person or group who
developed the channel.
• Copyright. This is any copyright string that you want to include, but it
should be brief (less than 50 characters).
4 Select the Set up Advanced properties check box if you want to set
additional properties of the channel, and click Next.
5 If you selected the Set up Advanced properties check box, use this page
to edit the values of channel properties.
• Property column. This displays the names of the channel properties.
• Value column. This displays the values of the channel properties. You
can edit and enter property values in the Value column. To save your
changes, be sure to press Enter after editing each property value.
For more information on the individual channel properties, refer to
Channel Copier Help (click Help from within Channel Copier).
Click Next.
6 Set the schedule for updating the channel by selecting the appropriate day
and frequency:
Days
• Never. The tuner never updates the channel; you’ll have to manually
update the channel when necessary.
For WTS machines, you set the update schedule to Never so that the
channel doesn’t get updates from the transmitter automatically. This
allows you to control when the channel is updated.
• Daily. The channel can be updated every day, only on weekdays
(Monday through Friday), or every 1 to 100 days, depending on the
number you set.
• Weekly. The channel gets updated every 1 to 100 weeks, depending on
the number you set. During the week of the update, the update occurs
only on the days you check. If no days are checked, the update occurs
on Monday.
• Monthly. The channel can be updated every 1 to 100 months on the day
you set. If you choose day 30 or 31 and the month when the update
occurs doesn’t have that day (for example, February), the update
occurs on the first day of the next month.
Frequency
• Update at. Select to choose one time of the day when updates occur.
• Update every. Select to specify multiple times of the day when updates
occur. You can set updates to happen every 1-100 minutes or hours
during the day, and you can limit the updates to a single range of
hours during the day. For example, you can have the update occur
every hour between 9 am and 5 pm, or every 30 minutes from 5 pm to
9 am.
Click Next.
7 Select the destination location for the channel:
a. Click to specify a transmitter as the destination type.
b. In the Select Destination drop-down list, enter or select the
destination transmitter.
The Destination box displays the destination URL that you selected.
8 Click Publish to publish the channel to the destination location that you
selected.
The wizard shows you progress of publishing the channel and informs
you when the channel is successfully published.
9 Click Close to exit the wizard.
Note: If you used a different port number than 5282 for the transmitter,
use that port number here.
Tip: If you don’t know the exact URL of the channel, you could enter just
the transmitter URL and press Enter. When the channels on the
transmitter appear, click the channel for which you want to create a
backup copy.
4 For the destination:
a. Make sure that (transmitter) is selected.
b. In the Select destination text box, enter the same URL that you
entered for the source.
c. Change the URL of the channel so that you know it is a backup copy,
and press Enter. For example, if the URL of the channel is originally
http://trans.acme.com:5282/MyApplication, you can change it to
http://trans.acme.com:5282/MyApplicationBackup.
5 Click Add/Close.
You are returned to the Copy window, and the copy operation that you
created is selected.
6 Click Copy.
DOC
Troubleshooting 249
Issues with Packages Created Using Application Packager
• On UNIX, /opt/Marimba/Tuner/.marimba/<keyword>.
For the console server (the tuner that you install during the initial
setup and deployment), the default installation directory on UNIX is
/usr/local/Marimba/Tuner/.marimba/ws3.
You or the person who installed the tuner might have changed the
location of this directory when you are creating the installer during setup
and deployment. For more information about log files, see the following
sections:
• Looking at the Logs on page 254
• Application Packager’s History Logs on page 255
• Endpoint Logs on page 255
Problem:
A package is stuck in the install-pending state.
Possible solutions:
Investigate the following possible causes:
• The transmitter hosting the channel is not trusted. Verify that the
transmitter host name, subnet, or IP address is listed for the the
following properties are correct: marimba.security.trusted.transmitters
and or marimba.security.identity.transmitters.
• The channel parameter userobjs is set to true, and the user is not
logged onto the machine. If the userobjs parameter is set in the
package directory or the channel.txt file of the package in the tuner’s
workspace, then verify that a user is logged onto the machine in order
to install the package.
Problem:
A package is in the failed state.
Possible solutions:
Investigate the following possible causes:
• A script included in the package failed to install.
• One or more files and registry entries failed to install.
• A dependency specified for the package is not met by the endpoint.
• The user at the endpoint does not have sufficient permissions to install
the package.
Troubleshooting 251
Issues with Packages Created Using Application Packager
Problem:
Files included in the package are not installed or removed as desired on
the endpoint.
Solution:
Investigate the following possible causes:
• Files have the incorrect install, update, or uninstall policy. In Package
Editor, check that the install, update, and uninstall policies are set
correctly.
• The user at the endpoint does not have sufficient permissions to install
or uninstall files. Verify that the user has sufficient permissions for the
files. Also, check the history logs for the package, and search for the
words “ignored” and “failed.” You might also want to find out if there
are any other applications that might share or have a lock on the files.
• The package itself might be corrupted. Check the tuner’s history logs to
see if there are any tuner storage errors.
Problem (Microsoft Windows Installer or MSI only):
A package created using Windows Installer Packager fails to install.
Possible solutions:
When troubleshooting Microsoft Windows Installer or MSI packages,
verify that the application installs successfully without being packaged
using Application Packager. You can do this by running the installer using
the msiexec program from the command line. For example:
C:\msiexec /i C:\ExampleApplication.msi
For more information about the msiexec program, see the following page
on Microsoft’s website:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxp
pro/proddocs/msiexec.asp
You can also investigate the following possible causes:
• The logged-in user does not have permissions to install objects in the
user’s profile or the HKEY_CURRENT_USER section of the registry.
Open the package in Package Editor, and go to the Windows Installer
- Installation tab. In the text box below “Enter command line property
settings…,” enter ALLUSERS=2. Then, save, republish, and reinstall the
package.
For more details about the MSI properties, refer to Microsoft Windows
Installer Help or Microsoft’s website (at the time of this writing, the URL
for the property reference is
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/msi/setup/property_reference.asp).
• The required version of Microsoft Windows Installer (msiexec.exe) is not
available on the endpoint. To find out what version of the Windows
Installer you currently have, run msiexec.exe from the command line
at the endpoint. (It is usually located under the Windows system
directory.) To find out what version of msiexec.exe is required by the
current version of , see the . If you need to upgrade, the Windows
Installer is available as a redistributable (from Microsoft’s website) for
various Windows platforms.
• The package might contain corrupt .msi, .msp, or .mst files. Try the
following solutions:
• Try running the .msi, .msp, or .mst files on a machine similar to the
target endpoint using the msiexec program from the command line.
For example:
msiexec /I C:\package.msi <options>
Troubleshooting 253
Looking at the Logs
Solution:
Investigate the following possible causes:
• Java classes did not get compiled correctly. Make sure the Java classes
are compiled correctly and include all the required libraries (JAR, ZIP,
TAR, and other files).
• The Java application has permission issues. For the external virtual
machine (VM), make sure that the user at the endpoint has access and
permission to launch and execute java.exe. Set capabilities to “all” for
the Java package’s properties.txt file before publishing
• The PATH or CLASSPATH settings are not valid. Confirm that the
required CLASSPATH is set.
See Also:
Looking at the Logs on page 254
See Also:
Turning on the Debugging Feature on page 256
Endpoint Logs
For the packaged channels or packages on each endpoint, logs are created that
record actions that take place on the endpoint. Each package’s history log is
kept in the following location:
<tuner_workspace_dir>\Ch.X\history-1.log
See Also:
Troubleshooting 255
Turning on the Debugging Feature
Note: The debugging level that you set for all the packages on the tuner
overrides the one that you set for an individual package.
• On UNIX and Windows, you can set the following property in the
parameters.txt file in the package directory:
debug.level=<integer from 0 to 10>
For example:
debug.level=2
Setting the level higher increases the detail of debugging information that
appears in the log files.
• On UNIX and Windows, you can add this flag by starting the tuner at the
command line with the -java option. Following is an example of the
syntax you would use for UNIX:
./tuner -java -DDEBUGFLAGS=<flag>=<level>,<flag>=<level>
[<other_tuner_args>]
Note: If you start the tuner with other tuner arguments in addition to
-java -DDEBUGFLAGS, you need to always place the -java -DDEBUGFLAGS
argument first, before the other arguments.
Using this -java option at the command line is the preferred way to turn
on debugging because debugging will automatically be turned off the next
time you start the tuner without the debug flag. That is, you won’t need to
remember to turn it off.
• On UNIX and Windows, you can add this flag by adding a tuner property
using Tuner Administrator. You can also add the tuner property directly to
the prefs.txt file in the tuner’s workspace. On Windows, for example, the
default location of the tuner’s workspace is
c:\Program Files\Marimba\Tuner\.marimba\<keyword>\, where <keyword> is
the endpoint’s keyword, which was assigned during installation. The
default keyword is the profile name.) That is, turn on debugging by
adding the following line to prefs.txt and then restarting the tuner:
marimba.launch.javaArgs=-DDEBUGFLAGS=<flag>=<level>,<flag>=<level>
How to specify which flags you want to use. For <flag> and <level>, use the
following values:
For <flag> use SOFTDIST. You set this debugging flag on the endpoint machine
where you are installing or updating the package. The debugging information
is written to both the tuner’s history logs and the package’s history logs.
Tip: You can also view the log messages by starting a Console Window
channel. In this case, the messages will be written to both the Console
Window and the logs. On UNIX, the messages are also written to the
command-line window following the tuner command.
For <level> use 2. The levels actually range from 1 to 10. In order to enable
debugging, you need to set this number to be greater than 1. It is
recommended that you use 2.
Example. Following is an example of the tuner property you would set in order
to turn on debugging for an endpoint:
marimba.launch.javaArgs=-DDEBUGFLAGS=SOFTDIST=2
Troubleshooting 257
Turning on the Debugging Feature
feature off by deleting the -DDEBUGFLAGS line from the prefs.txt file and then
restarting the tuner. If you turned debugging on by starting the tuner at the
command line and using the -java -DDEBUGFLAGS option, then turn the feature
off by restarting the tuner without the -java -DDEBUGFLAGS option.
See Also:
Looking at the Logs on page 254
Command-Line Basics
Each tuner comes with a program named runchannel, which you can run to
start any channel on that tuner from the command line. In this chapter, you’ll
learn about using the command-line options for Application Packager. For
information about using the runchannel program with other channels, refer to
the command-line chapter in the Marimba Reference Guide on Marimba’s
Documentation page at www.marimba.com/doc/.
That is, it must be the full URL for the channel. Note that even though the
channel URL specifies the original location of that channel on the transmitter,
runchannel still starts the channel from the tuner to which it’s been
downloaded.
For example, to view the list of command-line options for the Application
Packager channel that originate from the transmitter named trans.acme.com,
you would enter:
runchannel http://trans.acme.com:5282/ApplicationPackager -help
Note: When you specify the directory in which to create or save the channel,
make sure the directory does not already contain another channel. Otherwise,
the channel that you create may not be usable.
runchannel http://trans.acme.com:5282/ApplicationPackager
-custompackage MyCustomChannel C:\Channels\MyCustomChannel -defaults
C:\Channels\Templates\custom.xml
UNIX
runchannel http://trans.acme.com:5282/ApplicationPackager
-custompackage MyCustomChannel /opt/source/pkgs/MyCustomChannel
-defaults /opt/source/pkgs/templates/custom.xml
You need to either specify an install directory or prompt the user for a
directory where the files should be installed.
<directory> is the full path of the directory containing content to be
packaged.
as <install_directory> specifies the directory on the user’s system
where the packaged files will be installed when the channel is run.
prompt "<text>" queries the user for the directory in which to install
the packaged files when the channel is run, displaying the specified
text as a prompt for the user’s input. The text should be a message
asking the user to specify the target directory on the user’s system.
UNIX
runchannel http://trans.acme.com:5282/ApplicationPackager
-filepackage /home/user1/MyFilePackage
/home/user1/ContentFiles/src1 as /home/Install/src1 ref
/home/user1/ContentFiles/src2 as /home/Install/src2 ref
UNIX
runchannel http://trans.acme.com:5282/ApplicationPackager
-filepackage -repackage /home/user1/MyFilePackage
creates a snapshot of the system using the filters in the specified XML file
and saves the snapshot to the specified file path.
<file_path> specifies the full path and name for the file where you want
to save the snapshot.
<XML_template_file_path> specifies the XML template file that contains
the filters you want to use for the snapshot. For more information, see
Using XML Template Files with Packager for Shrinkwrap Windows Applications on
page 235 and Snapshot Tags on page 364 in Appendix C: XML Syntax.
For example:
runchannel http://trans.acme.com:5282/ApplicationPackager -snapshot
C:\SystemSnapshots\preinstall.msp
C:\SystemSnapshots\Templates\snapshot.xml
creates a new channel with the specified name in the specified directory.
<channel_directory> specifies the full path of the directory where you
want to place the contents of the new channel that you are creating.
<channel_name> specifies a name for the channel.
The latter offers more advanced file permission settings. To take full
advantage of this option, both the person who is creating the file package
and the end user must be using an NTFS file system. Otherwise, only
basic Window file permissions and attributes (read-only, archive, hidden,
system) are preserved.
Note: End users installing the channel must have administrative
privileges to set permissions.
Example:
runchannel http://trans.acme.com:5282/ApplicationPackager -
dotnetpackage -packagedir C:\Channels\MyDotNetPackage -channelname
My_Dot_Net_Pkg -sourcedir C:\AssemblyFiles\src1 as C:\Install\src1
prompt "Where to install src1?" filebyref true ntfileperm true
-sourcedir C:\AssemblyFiles\src2 as C:\Install\src2 prompt "Where to
install src2?" filebyref true ntfileperm true
That is, it must be the full URL for the channel. Note that even though the
channel URL specifies the original location of that channel on the transmitter,
runchannel still starts the channel from the tuner to which it’s been
downloaded.
Syntax for the -pdapackage option. The arguments for the -pdapackage option
are described in the rest of this section. The following options and arguments
apply to both packaging content and packaging applications:
-pdapackage -packagedir <channel_directory>
[-channelname <name_of_channel>] [-repackage]
The -pdapackage option specifies that you want to create a package for a
mobile device. The -packagedir option creates a channel in the directory
specified by <channel_directory>. This directory name is also used as the
URL name when the package is copied to your transmitter (unless you use
Channel Copier to change the URL name). Regardless of whether you
want to package an application (CAB file) or content (files in a directory),
you need to specify both the -pdapackage and -packagedir options.
If you are packaging the channel for the first time, be sure to use the
option -channelname to specify the name that you want to give the
channel.
If you are repackaging the channel, rather than packaging the channel for
the first time, you can omit the -channelname option. In this case, be sure to
use the -repackage option. For more information about repackaging, see
Using the PDA Packager to Update a Channel on page 230.
Then, if you are creating a package for the first time, depending on what type
of package you want to create, you will need to use one of the following
groups of command-line options (if you are repackaging, you need to use the
following options only if you want to add directories or CAB files or change
some other setting):
• Content files. For packaging content (one or more directories of files), use
the following options:
-sourcedir <source_directory> specifies the full path to the directory
that contains the content to be packaged.
as <target directory> specifies the full path to the directory on the
user’s system where the packaged files will be installed when the
channel is run. In most cases, you will want to use a short path. For
example, if you package C:\Program Files\Microsoft
ActiveSync\MyApplication, you will probably want the install path to
be \MyApplication.
Tip: If you want to use the command-line interface to create a package, and
then later decide to use the Application Packager’s PDA Packager graphical
user interface (GUI) to reconfigure the package, you will need to use
Application Packager’s File > Import command in the GUI, and then browse
to the channel directory. Once you import the channel directory in this
manner, the channel will be listed in the PDA Packager.
Publishing the packages. Once you have successfully packaged the directory or
CAB files by using the appropriate command-line options, you need to use
Channel Copier to actually publish the packaged application channels to your
transmitter. In the Application Packager GUI, you simply click the Publish
button to accomplish this task. (The Publishing wizard then appears and
guides you through the publishing process.) If you are using the Application
Packager’s command-line interface, however, you need to start Channel Copier
and manually copy the channels.
Upgrading Channels
This command-line option upgrades channels that were packaged using a
previous version of Application Packager to the current version. You can
upgrade channels that were packaged with Application Packager 4.0 and later.
You can start Application Packager with the runchannel program and specify
the channels to upgrade as follows:
runchannel <App_Packager_URL> -upgrade <path_of_text_file>
where <path_of_text_file> is the full path of the text file containing the
directory paths of the channels to upgrade, one entry per line.
Examples:
Windows
runchannel http://trans.acme.com:5282/Marimba/ApplicationPackager
-upgrade C:\packagedchannels\upgrade.txt
UNIX
runchannel http://trans.acme.com:5282/Marimba/ApplicationPackager
-upgrade /home/user1/packagedchannels/upgrade.txt
For example:
runchannel http://trans.acme.com:5282/Marimba/ApplicationPackager
-version
For example:
runchannel http://trans.acme.com:5282/Applications/CustomApplication
-version
where
<channel_directory> specifies the full path of the directory where you
want to place the contents of the new channel that you are creating.
<paths_of_XML_template_files> specifies the paths of the XML template
files that you want to apply to the channel. If you want to use more than
one XML template files, separate the paths with semicolons (;). For more
information, see Using XML Template Files on page 233 and Appendix C: XML
Syntax on page 311.
Examples:
Windows
runchannel http://trans.acme.com:5282/Marimba/ApplicationPackager
-applytemplate “C:\Channels\MyCustomChannel”
“C:\Channels\Templates\shrinkwrap.xml;
C:\Channels\Templates\policies.xml;
C:\Channels\Templates\macros.xml”
UNIX
runchannel http://trans.acme.com:5282/Marimba/ApplicationPackager
-applytemplate /home/user1/MyCustomChannel
/home/user1/Channels/Templates/policies.xml;
/home/user1/Channels/Templates/macros.xml”
starts the application, if any, that’s configured to start from the channel,
optionally passing arguments that the application has been configured to
accept. (Using -exec without any arguments has the same effect as using
runchannel without any options, as shown above.) If the channel has not
been installed, this option launches the installer first.
The -exec option should appear last among any options specified because
everything that follows -exec is considered an argument to be passed to a
started instance of the application.
-install
installs on the tuner whatever files the channel has been configured to
install.
-refreshsourcelist
refresh the source list for an MSI channel. This option is only valid for
channels created using the Windows Installer Packager.
-remove
-repair
checks the channel integrity and fixes any errors in the channel.
-rundir <directory>
If the macro or macro definition includes spaces, you must enclose the
entire command line within quotation marks (““).
Note: The -setmacro command-line option by itself cannot cause a major
update to occur when a packaged application is being updated. For
example, using -setmacro to set change the $dir1 macro’s value in a file-
packaged channel to another value will not cause a major update to occur.
For more information about major updates, see Managing Major and Minor
Updates on page 129.
-silent
stages an MSI channel. This option is only valid for channels created using
the Windows Installer Packager. For more information, see Staging MSI
Applications on Endpoints on page 278.
-verify
displays the version of Application Packager that was used to create this
channel. For more information, see Checking the Version of Application
Packager and Channels on page 274.
can be used to start the application, if any, that was previously installed by the
specified channel (and configured to start from that channel).
The MSI file and any support files are staged in an msi directory in the channel
directory (for example, C:\<Tuner_workspace_directory>\ch.X\data\msi, where
X is a number representing the channel).
This appendix lists the policies that are available for channels created using
Application Packager. It includes the policies that apply to the entire channel,
as well as policies that apply to specific items in a channel. It also includes a
brief description of the actions that take place for each policy.
This appendix contains the following sections:
• Policies for the Entire Channel on page 279
• Policies for Directories and Files on page 287
• Policies for Registry and Metabase Keys and Values on page 300
• Policies for NT Services on page 304
• Policies for Text Modifier Groups and Text Modifiers on page 309
The following tables describe the actions taken for each policy:
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 279
Policies for the Entire Channel
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 281
Policies for the Entire Channel
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 283
Policies for the Entire Channel
Note: For additional examples for each of the uninstallation policies, see
Determining Whether Files Are Restored or Deleted During Uninstallation on page 108.
The policies described in Table 6. Verify Policies on page 285 apply to these two
types of verification policies:
• Verify Installed. These policies take effect during the verify and repair
phases for objects that were installed by a channel (created using
Application Packager) at one point. An object can be installed during
installation, update, or repair of a channel.
• Verify Not Installed. These policies take effect during the verify and repair
phases for objects that were never installed by a channel (created using
Application Packager). For example, if a newer version of the file is
already installed on the endpoint and there is an older version in the
channel, then the newer version will not be overwritten by the older one if
the installation policy Install if object is newer—Compare objects based
on versions is selected.
As a best practice for the Verify not installed policy, set Verify the
existence of the object. Setting Verify contents of the object is not
recommended.
The policies are checked in the following order, and the first policy that fails
prevents the other policies from being checked:
1 If Don’t verify object during package verification is selected, then the object is
not checked.
2 Verify the existence of the object
3 Verify contents of the object
4 If Verify contents of the object fails, then If the contents differ, allow
Windows versions to increase is evaluated.
5 Verify the attributes of the object
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 285
Policies for the Entire Channel
The repair policies are checked in the following order, and the first policy that
fails prevents the other policies from being executed:
1 If Do not repair object is selected, then the object is not repaired.
2 Repair the contents of the object and Do not repair contents if versions
increased
3 Repair the attributes of the object
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 287
Policies for Directories and Files
The following tables describe the actions taken for each policy:
• Table 8. Installation Policies on page 290
• Table 9. Update Policies on page 291
• Table 10. Uninstallation Policies on page 293
• Table 11. Verify Policies on page 295
• Table 12. Repair Policies on page 296
Notes:
1 Some policies apply only to particular types of files:
• For files that have .exe, .ocx, or .dll file extensions (on Windows) and
other files that include version information, policies can use that
version information to determine whether or not to install, update,
uninstall, or verify those files.
• For INI files, different policies apply. Policies for INI Files on page 296
lists the policies for installing, updating, uninstalling, and verifying
INI files.
• For shortcuts and link files, the following policies do not apply:
• Install if file is newer.
• Update if file is newer.
• Verify file, but allow Windows versions to increase.
2 When you set policies for container objects (such as directories, registry
keys, and metabase keys) you are actually setting the policies for the child
objects in them (subdirectories/files, registry subkeys/value pairs, and
metabase subkeys/value pairs). For example, when you set the
installation policies for a directory, the Install Policy tab says “Install
policy for this directory’s contents.” Container objects get these policies
only:
• Always install
• Always update
• Uninstall if possible (Container objects are not uninstalled unless they
are empty of all child objects.)
• Always verify
▼ Scenario 1:
1 Delete the shortcut from the desktop endpoint.
2 Do not make modifications to the shortcut object in the channel, but just
change its update policy to “Always update.”
3 Publish and install the update. The shortcut will be placed back on the
desktop endpoint.
▼ Scenario 2:
1 Delete the shortcut from the desktop endpoint.
2 Make a modification to the shortcut object in the channel, but do not
change any policies.
3 Publish and install the update. The shortcut will be placed back on the
desktop endpoint.
▼ Scenario 3:
1 Delete the shortcut from the desktop endpoint.
2 Do not make modifications to the shortcut object in the channel, but just
change its update policy to “Always update.”
3 Publish and install the update. The shortcut will be placed back on the
desktop endpoint.
4 Delete the shortcut from the desktop endpoint again.
5 Update again without changing anything in the channel. The shortcut will
not be placed back on the desktop endpoint because there was no update
to the shortcut object itself.
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 289
Policies for Directories and Files
▼ Scenario 4:
1 Delete the shortcut from the desktop endpoint.
2 Do not make modifications to the shortcut object in the channel, but just
change its update policy to “Always update.”
3 Publish and install the update. The shortcut will be placed back on the
desktop endpoint.
4 Delete the shortcut from the desktop endpoint again.
5 Modify the channel by adding other files, but do not modify or update the
shortcut object itself.
6 When you update the channel, the shortcut will not be placed back on the
desktop endpoint, even though there was an update to the channel,
because there was no update to the shortcut object itself.
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 291
Policies for Directories and Files
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 293
Policies for Directories and Files
The policies described in Table 11. Verify Policies on page 295 apply to these two
types of verification policies:
• Verify Installed. These policies take effect during the verify and repair
phases for objects that were installed by a channel (created using
Application Packager) at one point. An object can be installed during
installation, update, or repair of a channel.
• Verify Not Installed. These policies take effect during the verify and repair
phases for objects that were never installed by a channel (created using
Application Packager). For example, if a newer version of the file is
already installed on the endpoint and there is an older version in the
channel, then the newer version will not be overwritten by the older one if
the installation policy Install if object is newer—Compare objects based
on versions is selected.
The policies are checked in the following order, and the first policy that fails
prevents the other policies from being checked:
1 If Inherit policy... is selected, then the inherited policy takes precedence.
2 If Don’t verify object during package verification is selected, then the
object is not checked.
3 Verify the existence of the object
4 Verify contents of the object
5 If Verify contents of the object fails, then If the contents differ, allow
Windows versions to increase is evaluated.
6 Verify the attributes of the object
The repair policies are checked in the following order, and the first policy that
fails prevents the other policies from being executed:
1 If Inherit policy... is selected, then the inherited policy takes precedence.
2 If Do not repair object is selected, then the object is not repaired.
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 295
Policies for Directories and Files
3 Repair the contents of the object and Do not repair contents if versions
increased
4 Repair the attributes of the object
The following tables describe the actions taken for each policy:
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 297
Policies for Directories and Files
The policies described in Table 16. Verify Policies on page 299 apply to these two
types of verification policies:
• Verify Installed. These policies take effect during the verify and repair
phases for objects that were installed by a channel (created using
Application Packager) at one point. An object can be installed during
installation, update, or repair of a channel.
• Verify Not Installed. These policies take effect during the verify and repair
phases for objects that were never installed by a channel (created using
Application Packager). For example, if a newer version of the file is
already installed on the endpoint and there is an older version in the
channel, then the newer version will not be overwritten by the older one if
the installation policy Install if object is newer—Compare objects based
on versions is selected.
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 299
Policies for Registry and Metabase Keys and Values
The following tables describe the actions taken for each policy:
• Table 18. Installation Policies on page 301
• Table 19. Update Policies on page 301
• Table 20. Uninstallation Policies on page 302
• Table 21. Verify Policies on page 303
• Table 22. Repair Policies on page 304
Note: When you set policies for container objects (such as directories, registry
keys, and metabase keys) you are actually setting the policies for the child
objects in them (subdirectories/files, registry subkeys/value pairs, and
metabase subkeys/value pairs). For example, when you set the installation
policies for a directory, the Install Policy tab says “Install policy for this
directory’s contents.” Container objects get these policies only:
• Always install
• Always update
• Uninstall if possible (Container objects are not uninstalled unless they are
empty of all child objects.)
• Always verify
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 301
Policies for Registry and Metabase Keys and Values
The policies described in Table 21. Verify Policies on page 303 apply to these two
types of verification policies:
• Verify Installed. These policies take effect during the verify and repair
phases for objects that were installed by a channel (created using
Application Packager) at one point. An object can be installed during
installation, update, or repair of a channel.
• Verify Not Installed. These policies take effect during the verify and repair
phases for objects that were never installed by a channel (created using
Application Packager). For example, if a newer version of the file is
already installed on the endpoint and there is an older version in the
channel, then the newer version will not be overwritten by the older one if
the installation policy Install if object is newer—Compare objects based
on versions is selected.
The policies are checked in the following order, and the first policy that fails
prevents the other policies from being checked:
The repair policies are checked in the following order, and the first policy that
fails prevents the other policies from being executed:
1 If Inherit policy... is selected, then the inherited policy takes precedence.
2 If Do not repair object is selected, then the object is not repaired.
3 Repair the contents of the object and Do not repair contents if versions
increased
4 Repair the attributes of the object
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 303
Policies for NT Services
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 305
Policies for NT Services
The policies described in Table 11. Verify Policies on page 295 apply to these two
types of verification policies:
• Verify Installed. These policies take effect during the verify and repair
phases for objects that were installed by a channel (created using
Application Packager) at one point. An object can be installed during
installation, update, or repair of a channel.
• Verify Not Installed. These policies take effect during the verify and repair
phases for objects that were never installed by a channel (created using
Application Packager). For example, if a newer version of the file is
already installed on the endpoint and there is an older version in the
channel, then the newer version will not be overwritten by the older one if
the installation policy Install if object is newer—Compare objects based
on versions is selected.
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 307
Policies for NT Services
The policies are checked in the following order, and the first policy that fails
prevents the other policies from being checked:
1 If Inherit policy... is selected, then the inherited policy takes precedence.
2 If Don’t verify object during package verification is selected, then the
object is not checked.
3 Verify the existence of the object
4 Verify contents of the object
5 If Verify contents of the object fails, then If the contents differ, allow
Windows versions to increase is evaluated.
6 Verify the attributes of the object
The repair policies are checked in the following order, and the first policy that
fails prevents the other policies from being executed:
1 If Inherit policy... is selected, then the inherited policy takes precedence.
2 If Do not repair object is selected, then the object is not repaired.
3 Repair the contents of the object and Do not repair contents if versions
increased
4 Repair the attributes of the object
Appendix B: Policies for Installation, Update, Uninstallation, Verification, and Repair 309
Policies for Text Modifier Groups and Text Modifiers
DOC
This appendix describes the syntax for Application Packager’s XML template
files. It contains the following sections:
• Generic Tags on page 311
• Non-MSI Tags on page 340
• MSI Tags on page 351
• Search and Modify Tags on page 355
• Snapshot Tags on page 364
The beginning of each section shows the hierarchy of XML tags.
Generic Tags
Generic tags apply to all channels created using Application Packager.
This section describes the following generic tags:
<PACKAGE>
<CUSTOMMACRO>
<MACRO>
<ENVIRONMENT>
<ENV_PROPERTY>
<SERVICES>
<SERVICE>
<SERV_GENERAL>
<SERV_SECURITY>
<SERV_ADVANCED>
<SERV_DEPEND>
<SERV_POLICIES>
<CONFIGURATION>
<PLATFORM>
<INSTALLER>
<REBOOT>
<POLICIES>
<STARTUP>
<VERIFYREPAIR>
<DEPENDENCIES>
<DEPEND_MEMORY>
<DEPEND_PROCESSOR>
<DEPEND_RESOLUTION>
<DEPEND_DISKSPACE>
<DEPEND_DRIVE>
<DEPEND_FILES>
<DEPEND_FILE>
<DEPEND_REGISTRY>
<DEPEND_REGKEY>
<DEPEND_CHANNELS>
<DEPEND_CHANNEL>
<CUSTOMIZATION>
<SCRIPTS>
<SCRIPT>
<PROPERTY>
<PARAMETER>
<PACKAGE>
Defines a channel created using Application Packager. The <PACKAGE> tag
encloses all the other tags for the channel.
Syntax
<PACKAGE
name=”name for the channel"
>
<!--child tags -->
</PACKAGE>
Attributes
• name—A string representing the name of the channel.
<CUSTOMMACRO>
Contains the user-defined macros in a channel.
Syntax
<CUSTOMMACRO>
<!-- child macro tags -->
</CUSTOMMACRO>
Attributes
None.
Example
<CUSTOMMACRO>
<MACRO definition="C:\MyPrograms" query="Install the program in
which directory?" name="$InstallDir" type="user"/>
<MACRO definition="machine1" query="Computer name?"
name="$ComputerName" type="user"/>
</CUSTOMMACRO>
<MACRO>
Defines a macro in a channel.
Syntax
<MACRO
type = "user|registry|environment|package|tuner|msi"
name = "the name of the macro"
definition = "the default macro definition"
registrykey = "registry key name - valid only if type is
registry"
registrykeyvalue = "registry key value name - valid only if type
is registry"
query = "optional query user for definition prompt description"
/>
Attributes
• type—A string that indicates the type of macro. The following types are
available:
• user—A user-defined macro with the default user namespace $name.
Macros in this namespace cannot automatically resolve themselves.
They either have default values, or they must be resolved by the user
at runtime.
• registry—A registry value macro with the namespace $REG.name. It
expects a second macro called $name (in the default namespace) to
exist. This macro should contain a complete path to a registry value.
• environment—An environment variable macro with the namespace
$ENV.name. It resolves to the value of the environment variable name.
• definition—A string representing the default definition for the macro. The
default definition is used if the macro is not resolved during installation at
the endpoint.
• registrykey—Registry key name for a registry value macro. This attribute
is valid only if the macro type is registry.
• registrykeyvalue—Registry key value name for a registry value macro.
This attribute is valid only if the macro type is registry.
• query—Optional. A string representing the question you want to ask
endpoint users when prompting them for the macro definition.
Example
<MACRO definition="C:\MyPrograms" query="Install the program in
which directory?" name="$InstallDir" type="user"/>
<ENVIRONMENT>
Contains the environment variables in a channel.
Syntax
<ENVIRONMENT>
<!--child variable tags -->
</ENVIRONMENT>
Attributes
None.
Example
<ENVIRONMENT>
<ENV_PROPERTY value="var" segment="win9x" name="TEST ENV VAR"/>
</ENVIRONMENT>
<ENV_PROPERTY>
Defines an environment variable in a channel.
Syntax
<ENV_PROPERTY
segment="win9x|winnt"
type="system|user"
Attributes
• segment—A string representing the platforms for which the environment
variable is valid. The following platforms are available:
• win9x—Windows 95 and Windows 98
• winnt—Windows NT and Windows 2000
• type—A string representing the type of environment variable. This
attribute is valid only if the attribute segment is winnt. The following types
are available:
• system—A system environment variable that applies to the system, and
thus to all users of the system.
• user—A user environment variable that is different for each user of a
particular computer. The variables include any that are set by the user,
as well as any variables defined by applications, such as the path to
the location of the application files.
• name—A string representing the name of the environment variable.
• value—A string representing the value of the environment variable.
Example
<ENV_PROPERTY value="var" segment="win9x" name="TEST ENV VAR"/>
<SERVICES>
Contains the Windows NT or Windows 2000 services in a channel.
Syntax
<SERVICES>
<!--child service tags -->
</SERVICES>
Attributes
None.
Example
<SERVICES>
<SERVICE/>
</SERVICES>
<SERVICE>
Defines a Windows NT or Windows 2000 service in a channel.
Syntax
<SERVICE>
<!--child service tags -->
</SERVICE>
Attributes
None.
Example
<SERVICE>
<!--child service tags -->
</SERVICE>
<SERV_GENERAL>
Defines the general properties of a Windows NT or Windows 2000 service in a
channel. This contains the same information that appears in the General
Properties Page tab of the Package Editor’s NT Service dialog box.
Syntax
<SERV_GENERAL
servicename="the name of the service"
displayname="the displayed name of the service"
servicepath="path of the program to run"
type="kernel_driver|filesystem_driver|own_process|share_process"
start="boot|system|automatic|demand|disabled"
errorcontrol="ignore|normal|severe|critical"
/>
Attributes
• servicename—A string representing the name of the Windows NT or
Windows 2000 service.
• displayname—A string specifying the name for the service that is displayed
in the Services Control Panel.
Example
<SERV_GENERAL errorcontrol="normal" displayname="Test Service
Display Name" type="own_process" servicepath="TestServiceProgram"
start="demand" servicename="Test Service"/>
<SERV_SECURITY>
Defines the security properties of a Windows NT or Windows 2000 service in a
channel. This contains the same information that appears in the Security
Properties Page tab of the Package Editor’s NT Service dialog box.
Syntax
<SERV_SECURITY
account="system|user"
desktop="true|false"
accountname="the name of the user account"
password="the password associated with accountname"
/>
Attributes
• account—A string specifying whether the service will log on using the
system account or the user account.
• desktop—A boolean value (true or false) specifying whether the service
provides a user interface that can be used by the logged on user when the
service is started.
• accountname—A string specifying the name of a user account for the
service to use. Although most services log on to the system account, some
services can be configured to log on to specific user accounts so that the
user can have access to resources such as files and directories protected by
Windows. This attribute is valid only if the account attribute is user.
• password—A string specifying the corresponding password for the user
account specified in the accountname attribute.
Example
<SERV_SECURITY desktop="false" account="system"/>
<SERV_ADVANCED>
Defines the advanced properties of a Windows NT or Windows 2000 service in
a channel. This contains the same information that appears in the Advanced
Properties Page tab of the Package Editor’s NT Service dialog box.
Syntax
<SERV_ADVANCED
groupname="name of the group this service belongs to"
/>
Attributes
• groupname—A string specifying the group a service is associated with. The
group usually determines the order in which the services start.
Example
<SERV_ADVANCED group="name of the group this service belongs to"/>
<SERV_DEPEND>
Specifies the groups and services on which a particular service depends. If a
service is stopped or is not running properly, other services that depend on
that service can be affected.
Syntax
<SERV_DEPEND
type="GROUP|SERVICE"
name="the name of the group or service this service depends on"
/>
Attributes
• type—A string specifying whether the service depends on a group (group)
or another service (service).
• name—A string specifying the name of the group or service on which this
service depends.
Example
<SERV_DEPEND type="group" name="the name of the group or service
this service depends on"/>
<SERV_POLICIES>
Defines the policies for a Windows NT or Windows 2000 service in a channel.
This contains the same information that appears in the Install Policies Page and
Uninstall Policies Page tabs of the Package Editor’s NT Service dialog box.
Syntax
<SERV_POLICIES
installpol="inherit|always|exists|notexist|never"
uninstallpol="remove|inherit|always|installed|never"
/>
Attributes
• installpol—A string specifying the installation policies for a service. The
available policies are: inherit, always, exists, notexist, and never. For
more information about each policy, see Policies for NT Services on page 304.
• uninstallpol—A string specifying the uninstallation policies for a service.
The available policies are: remove, inherit, always, installed, and never.
For more information about each policy, see Policies for NT Services on page
304.
Example
<SERV_POLICIES installpol="inherit|always|exists|notexist|never"
uninstallpol="inherit|always|installed|never"/>
<CONFIGURATION>
Contains the following tags:
• <PLATFORM>
• <INSTALLER>
• <POLICIES>
• <STARTUP>
• <VERIFYREPAIR>
• <DEPENDENCIES>
• <CUSTOMIZATION>
Syntax
<CONFIGURATION>
<!--child tags-->
</CONFIGURATION>
Attributes
None.
<PLATFORM>
Specifies the platforms for which the channel is valid.
Syntax
<PLATFORM
segment.win="WIN9X|WINNT|WIN2K|WINXP|WINANY"
segment.unix="SOLARIS|AIX|HPUX|LINUX|SCO|OSF1"
/>
Attributes
• segment.win—A string representing the Windows platforms for which the
channel is valid. You can specify the following platforms: WIN9X, WINNT,
WIN2K, WINXP, and WINANY.
Example
<PLATFORM segment.win="WINNT"/>
<INSTALLER>
Specifies the installation options for the channel.
Syntax
<INSTALLER
guimode="full|semisilent|silent"
preview="true|false"
rollback="true|false"
nobackup="true|false"
delayfiledownload="true|false"
updateinstall="true|false"
loggingrollover="hourly|daily|weekly|monthly|never|an integer
representing the size of the log file in kilobytes"
multiuser=”true|false”
/>
Attributes
• guimode—A string representing the graphical user interface (GUI) mode in which
the channel runs when installing the packaged application. You can specify the
following modes:
• full—Select this mode if you want an interactive installation that
prompts the end user during the process. This mode displays any
dialog boxes or progress bars to the end user during installation.
This option might be useful if you need to use a pre-install script to run
some commands or check that some conditions are met before installing
an application, you might want to delay the download so that time and
bandwidth are not wasted if the commands fail or if the conditions are not
met. You might also want to use this option with the preload parameter
(see Minimizing Bandwidth Usage on page 141). Using these together allows
you to prevent files that are already on the endpoint from being
unnecessarily downloaded again.
• updateinstall—A boolean value (true or false) specifying if you want to
install the channel automatically after it is updated. If you specify true,
the channel will automatically install after it is updated. If you specify
false, the channel will be in the install-pending state after it is updated.
Example
<INSTALLER updateinstall="true" rollback="false"
loggingrollover="32" delayfiledownload="false" preview="false"
guimode="full" nobackup="false" multiuser="false"/>
<REBOOT>
Specifies the reboot options for installing the packaged application in the
channel.
Syntax
<REBOOT
type="always|allow|disallow"
prompt="true|false"
allowCancel="true|false"
force="true|false"
/>
Attributes
• type—A string value (always, allow, or disallow) specifying whether or not
you want to allow the channel to determine if a system reboot is required.
Example
<REBOOT force="false" prompt="true" type="allow"/>
<POLICIES>
Specifies the default installation, update, uninstallation, and verification
policies for the objects in the channel.
Syntax
<POLICIES
installpol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt"
updatepol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt"
uninstallpol="remove|installed_prompt|always|installed|never"
verifypol="content|attributes|version_increase|exists|never"
verifynipol="content|attributes|version_increase|exists|never"
repairpol="content|attributes|version_increase|exists|never"
/>
Attributes
For more information about each policy, see Policies for the Entire Channel on page
279.
Example
<POLICIES updatepol="always" installpol="newer_version_prompt"
uninstallpol="installed_prompt" verifypol="verify"/>
<STARTUP>
Specifies the options for starting the packaged application.
Syntax
<STARTUP
runexe="true|false"
runuser="true|false"
launch="true|false"
launchpath="path of executable to run from the tuner”
launchargs="command-line arguments to pass to the executable"
workingdir="working directory of executable"
execmode="detach|tuner"
exectime="seconds before forced termination"
/>
Attributes
• runexe—A boolean value (true or false) specifying if you want to allow
users to execute any application using the command-line option -runexe
<application_name>, where <application_name> includes the full path of
the application executable or batch file. If you specify false, you can use
the command-line option -runexe without any arguments to start only the
application with the executable file specified in the attribute launchpath.
• runuser—A boolean value (true or false) specifying if you want the
application (or scripts) in this channel to run in the user’s context instead
of the tuner’s context.
This option may be useful when running the tuner as a service. By default,
applications started using the tuner inherit the tuner’s context. This may
cause problems when the tuner is running as a service because the
application will not be running in the logged-on user’s context (and will
be missing the user’s security and identity settings).
• launch—A boolean value (true or false) specifying if you want to start or
launch the application from the tuner. If the attribute launch is set to true,
you can use the following attributes:
• launchpath—A string representing the path and the file name of the
executable file that starts the application. You can include a macro
name (for example, $macro_name$) in the path if necessary.
• launchargs—A string representing any command-line arguments that
you want the application to use when you start it (such as starting in a
minimized state, for example).
• workingdir—A string representing the path and name of a working
directory for the application, if necessary.
• execmode—A string indicating whether you want the application to run
independently from the tuner after it is launched. If you specify
detach, the application can continue to run even if the tuner is no
longer running. If you specify tuner, the tuner will manage the
application, including exiting the application.
• exectime—An integer specifying the number of seconds you want the
tuner to wait before forcing the application to exit. This attribute is
valid only if launch is true and execmode is tuner.
Example
<STARTUP runuser="false" runexe="false"/>
<VERIFYREPAIR>
Specifies the options for automatically verifying and repairing the channel.
Syntax
<VERIFYREPAIR
repair="true|false"
schedule="schedule string"
/>
Attributes
• repair—A boolean value (true or false) specifying if you want to make
any necessary repairs to a channel at the same time that verification is
scheduled.
• schedule—A string specifying the schedule for verifying and repairing the
channel. For details and examples, see Schedule String on page 328.
Schedule String
A schedule string entered from the command line can have any of the
following forms:
every <number> days update <when>
every <number> weeks on <day_of_week> update <when>
weekdays update <when>
never
where:
<number>
is mon, tue, wed, thu, fri, sat, or sun (lowercase and with no punctuation).
To specify more than one day of the week, use a plus sign (for example,
mon+tue+fri).
<when>
Example
<VERIFYREPAIR repair="true" schedule="every 2 weeks on mon update at
04:00AM"/>
<DEPENDENCIES>
Contains the dependencies or requirements for the channel.
Syntax
<DEPENDENCIES
runonupdate="true|false">
<!-- child dependency tags -->
</DEPENDENCIES>
Attributes
• runonupdate—A boolean value (true or false) specifying if you want
dependencies to be checked when updating channels
Example
<DEPENDENCIES runonupdate="true">
<DEPEND_MEMORY value="32" op=">="/>
<DEPEND_PROCESSOR op=">=" type="p"/>
<DEPEND_RESOLUTION value="800" op=">="/>
<DEPEND_DISKSPACE>
<DEPEND_DRIVE mb="32" drive="C"/>
</DEPEND_DISKSPACE>
<DEPEND_FILES>
<DEPEND_FILE sizeop=">=" op="exists" dateop=">="
path="G:\My Folder\test.txt" isOR="false" sizevalue="100" date="09-
21-2001"/>
<DEPEND_FILE op="notexist" isOR="true" path="G:\My
Folder\training.txt"/>
</DEPEND_FILES>
<DEPEND_REGISTRY>
<DEPEND_REGKEY op="notexist"
key="\HKEY_CURRENT_CONFIG\Software\Fonts" isOR="false"/>
</DEPEND_REGISTRY>
<DEPEND_CHANNELS>
<DEPEND_CHANNEL op="exists"
url="http://products/Software_Distribution/462/ApplicationPackager"
isOR="false"/>
</DEPEND_CHANNELS>
</DEPENDENCIES>
<DEPEND_MEMORY>
Specifies the required amount of system memory (in megabytes) for the
channel.
Syntax
<DEPEND_MEMORY
op="=|<>|<|<=|>|>="
value="required amount of memory in megabytes"
/>
Attributes
• op—An operator (=, <>, <, <=, >, or >=).
• value—An integer specifying the required amount of system memory (in
megabytes).
Example
<DEPEND_MEMORY value="32" op=">="/>
<DEPEND_PROCESSOR>
Specifies the required type of processor for the channel.
Syntax
<DEPEND_PROCESSOR
op="=|<>|<|<=|>|>="
type="386|486|P|PP|P2|P3|P4"
/>
Attributes
• op—An operator (=, <>, <, <=, >, or >=).
• value—A string specifying the required type of processor.
Example
<DEPEND_PROCESSOR op=">=" type=”P"/>
<DEPEND_RESOLUTION>
Specifies the required screen resolution for the channel.
Syntax
<DEPEND_RESOLUTION
op="=|<>|<|<=|>|>="
value="640|800|1024|1280|1600"
/>
Attributes
• op—An operator (=, <>, <, <=, >, or >=).
• value—A number (640, 800, 1024, 1280, or 1600) specifying the required
screen resolution.
Example
<DEPEND_RESOLUTION value="800" op=">="/>
<DEPEND_DISKSPACE>
Contains the disk space requirements for the channel.
Syntax
<DEPEND_DISKSPACE>
<!-- DEPEND_DRIVE child tags -->
</DEPEND_DISKSPACE>
Attributes
None.
Example
<DEPEND_DISKSPACE>
<DEPEND_DRIVE mb="32" drive="C"/>
</DEPEND_DISKSPACE>
<DEPEND_DRIVE>
Specifies the disk space requirement for one disk drive.
Syntax
<DEPEND_DRIVE
drive="a drive letter"
mb="an integer representing the required disk space in megabytes"
/>
Attributes
• drive—A letter representing the drive for which you want to specify the
disk space requirement.
• mb—An integer specifying the required minimum amount of disk space (in
megabytes) for the drive.
Example
<DEPEND_DRIVE mb="32" drive="C"/>
<DEPEND_FILES>
Contains the file requirements for the channel.
Syntax
<DEPEND_FILES>
<!-- DEPEND_FILE child tags -->
</DEPEND_FILES>
Attributes
None.
Example
<DEPEND_FILES>
<DEPEND_FILE sizeop=">=" op="exists" dateop=">="
path="G:\My Folder\test.txt" isOR="false" sizevalue="100" date="09-
21-2001"/>
<DEPEND_FILE op="notexist" isOR="true" path="G:\My
Folder\training.txt"/>
</DEPEND_FILES>
<DEPEND_FILE>
Specifies the information for one required file.
Syntax
<DEPEND_FILE
path="path of the file"
isOR="true|false"
op="exists|notexist"
sizeop="=|<>|<|<=|>|>="
sizevalue="an integer representing the size of the file in bytes"
dateop="=|<>|<|<=|>|>="
date="the required date for the file in the format MM-DD-YYYY"
/>
Attributes
• path—A string representing the path and the file name of the required file.
• isOR—A boolean value (true or false) specifying if you want to make this
an OR dependency.
• op—A string (exists or notexist) specifying whether you want to require
the file to exist or not exist at the endpoint.
• sizeop—An operator (=, <>, <, <=, >, or >=) for the size of the file. This
attribute is valid only if op exists.
• sizevalue—An integer specifying the required size (in bytes) of the file.
This attribute is valid only if op and sizeop exists.
• dateop—An operator (=, <>, <, <=, >, or >=) for the date of the file. This
attribute is valid only if op exists.
• date—A date (in the MM-DD-YYYY format) specifying the required date of the
file. This attribute is valid only if op and dateop exists.
Example
<DEPEND_FILE sizeop=">=" op="exists" dateop=">="
path="G:\My Folder\test.txt" isOR="false" sizevalue="100" date="09-
21-2001"/>
<DEPEND_FILE op="notexist" isOR="true" path="G:\My
Folder\training.txt"/>
<DEPEND_REGISTRY>
Contains the registry requirements for the channel.
Syntax
<DEPEND_REGISTRY>
<!-- DEPEND_REGKEY child tags -->
</DEPEND_REGISTRY>
Attributes
None.
Example
<DEPEND_REGISTRY>
<DEPEND_REGKEY op="notexist"
key="\HKEY_CURRENT_CONFIG\Software\Fonts" isOR="false"/>
</DEPEND_REGISTRY>
<DEPEND_REGKEY>
Specifies the information for one required registry key.
Syntax
<depend_regkey
key="the name of the registry key"
valuename="the name of the value"
valuetype=”reg_sz|reg_expand_sz|reg_binary|reg_dword|reg_multi_sz”
valuevalue=”the value of the value”
op="exists|notexist"
isOR="true|false"
/>
Attributes
• key—A string representing the name of the required registry key.
• valuename—A string representing the value name in the registry key.
• valuetype—A string (reg_sz, reg_expand_sz, reg_binary, reg_dword, or
reg_multi_sz) representing the type of value in the registry key. This
attribute is valid only if valuename exists.
• valuevalue—A string representing the registry key value. This attribute is
valid only if valuename exists.
• op—A string (exists or notexist) specifying whether you want to require
the registry key value to exist or not exist at the endpoint.
• isOR—A boolean value (true or false) specifying if you want to make this
an OR dependency.
Example
<DEPEND_REGKEY op="notexist"
key="\HKEY_CURRENT_CONFIG\Software\Fonts" isOR="false"/>
<DEPEND_CHANNELS>
Contains the channel requirements (the other channels required) for the
channel.
Syntax
<DEPEND_CHANNELS>
<!-- child DEPEND_CHANNEL tags -->
</DEPEND_CHANNELS>
Attributes
None.
Example
<DEPEND_CHANNELS>
<DEPEND_CHANNEL op="exists"
url="http://products/Software_Distribution/462/ApplicationPackager"
isOR="false"/>
</DEPEND_CHANNELS>
<DEPEND_CHANNEL>
Specifies the information for one required channel.
Syntax
<DEPEND_CHANNEL
url="URL of the channel"
op="exists|notexist"
isOR="true|false"
available_control=”wait|no_wait|stop”
/>
Attributes
• url—The URL of the Marimba channel that you want to require.
• op—A string (exists or notexist) specifying whether you want to require
the channel to exist or not exist at the endpoint.
• isOR—A boolean value (true or false) specifying if you want to make this
an OR dependency.
Example
<DEPEND_CHANNEL op="exists"
url="http://products/Software_Distribution/462/ApplicationPackager"
isOR="false"/>
<CUSTOMIZATION>
Contains the classes, scripts, or executables used to customize the behavior of
your channel on the endpoint.
Syntax
<CUSTOMIZATION>
<!-- child customization tags -->
</CUSTOMIZATION>
Attributes
None.
<SCRIPTS>
Specifies the information for the scripts used to customize the behavior of your
channel.
Syntax
<SCRIPTS
classpath=”an additional classpath for Java IScripts”>
<!-- child script tags -->
<SCRIPTS/>
Attributes
• classpath—The fully qualified name of the class for a Java script. This
attribute is valid only if the script type is java.
Example
<CUSTOMIZATION>
<SCRIPTS>
<SCRIPT path="test.bat" name="test" type="exe_bat_sh"
args="argument1" flags="pix"/>
<SCRIPT path="C:\scripts\test2.bat" name="test2"
type="exe_bat_sh" args="argument1" flags="qrcs" withchannel="true"/>
</SCRIPTS>
</CUSTOMIZATION>
<SCRIPT>
Specifies the information for one class, script, or executable used to customize
the behavior of your channel.
Syntax
<SCRIPT
name="the name of the script"
type="exe_bat_sh|java"
path="the path of the script file"
javapath="the fully qualified name of the class for a Java
script"
args="arguments to pass to the script"
flags="pqiumrvfxcsdab"
withchannel="true|false"
/>
Attributes
• name—The name of the script.
• type—A string specifying the type of script. Use exe_bat_sh for .exe and
.bat files on Windows platforms, and shell scripts on UNIX platforms; use
java for Java files.
• path—The path of the script file at the endpoint, or the full path of the
script file on the packaging machine if it is to be included as part of the
channel. (See Specifying Paths for a Script on page 124.) You can specify if you
want to include the script file with the channel using the withchannel
attribute.
• javapath—The fully qualified name of the class for a Java script. This
attribute is valid only if the script type is java.
• args—The arguments to pass to the script when it runs.
• flags—A character that specifies when the script runs and whether to
ignore error codes.
• p—Before the specified phase or phases
• q—After the specified phase or phases
• i—Install
• u—Major update
• m—Minor update
• r—Uninstall (removal)
• v—Verify
• f—Repair
• x—Execute
• c—Ignore the script’s exit or return code
• s—Run the script in the user’s context
• d—Run the script as a detached process
• a—User install
• b—User update
• withchannel—A boolean value (true or false) specifying whether the
script specified is to be copied from the path specified in the path attribute
to the channel's scripts directory.
Example
<CUSTOMIZATION>
<SCRIPTS>
<SCRIPT path="test.bat" name="test" type="exe_bat_sh"
args="argument1" flags="pix"/>
<SCRIPT path="C:\scripts\test2.bat" name="test2"
type="exe_bat_sh" args="argument1" flags="qrcs" withchannel="true"/>
</SCRIPTS>
</CUSTOMIZATION>
<PROPERTY>
Specifies the name and value of one property that you want to add to the
properties.txt file of the channel.
Syntax
<PROPERTY
name="the name of the property to add to the channel’s
properties.txt file"
value="the value of the property"
/>
Attributes
• name—The name of the property to add to the channel’s properties.txt
file.
• value—A string specifying value you want to set for the property.
For a list of properties that you can use in a channel’s properties.txt file, refer
to the Marimba Reference Guide on Marimba’s Documentation page at
www.marimba.com/doc/.
Example
<PROPERTY name="author" value="My Company Inc."/>
<PARAMETER>
Specifies the name and value of one property that you want to add to the
parameters.txt file of the channel.
Syntax
<PARAMETER
name="the name of the property to add to the channel’s
parameters.txt file"
value="the value of the property"
/>
Attributes
• name—The name of the property to add to the channel’s parameters.txt
file.
• value—A string specifying value you want to set for the property.
For a list of properties that you can use in a channel’s parameters.txt file, refer
to the Marimba Reference Guide on Marimba’s Documentation page at
www.marimba.com/doc/.
Example
<PARAMETER name="rollback" value="true"/>
Non-MSI Tags
Non-MSI tags all belong inside the <PACKAGE> tag and apply only to non-MSI
channels.
This section describes the following non-MSI tags:
<DIRECTORY>
<FILE>
<SHORTCUT>
<REGKEY>
<REGVALUE>
<METABASEKEY>
<METABASEVALUE>
<MODIFIERGROUP>
<MODIFIER>
<DIRECTORY>
Specifies the information for one directory to be created on the endpoint for the
channel.
Syntax
<DIRECTORY
path="directory to create on the endpoint"
attributes="rshac"
delete="true|false"
installpol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
updatepol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|
newer_timestamp_prompt|newer_timestamp_noprompt|inherit"
uninstallpol="remove|installed_prompt|always|installed|
never|inherit"
verifypol="inherit|content|attributes|version_increase|exists|
never"
verifynipol="inherit|content|attributes|version_increase|exists|
never"
repairpol="inherit|content|attributes|version_increase|never"
uid=”on UNIX, the user’s user ID in integer form or
(if uidname is true) in string form”
uidname=”true|false”
gid=”on UNIX, the user’s group ID in integer form or
(if uidname is true) in string form”
gidname=”true|false”
user_specific=”true|false”
/>
Attributes
• path—The path of the directory to create on the endpoint.
• attributes—One or more letters specifying the attributes for the directory:
• r—Read only
• s—System
• h—Hidden
• a—Archive
• c—Compressed
• delete—A boolean value (true or false) specifying whether the directory
specified is to be deleted from the endpoint (instead of being created).
• installpol—A string specifying the installation policy for this object.
• updatepol—A string specifying the update policy for this object.
• uninstallpol—A string specifying the uninstallation policy for this object.
• verifypol—A string specifying the verification policy for this object.
• verifynipol—A string specifying the verification not installed policy for
this object.
• repairpol—A string specifying the repair policy for this object.
For a description of the policies available, see Appendix B: Policies for Installation,
Update, Uninstallation, Verification, and Repair on page 279.
<FILE>
Specifies the information for one file to be created on the endpoint for the
channel.
Syntax
<FILE
filename="name of the file to create on the endpoint"
attributes="rshac"
shared="true|false"
delete="true|false"
selfregister="true|false"
reference="true|false"
installpol="newer_version_prompt|newer_version_noprompt
|notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
updatepol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
uninstallpol="installed_prompt|always|installed|
never|inherit"
verifypol="inherit|content|attributes|version_increase|exists|
never"
verifynipol="inherit|content|attributes|version_increase|exists|
never"
repairpol="inherit|content|attributes|version_increase|never"
uid=”on UNIX, the user’s user ID in integer form or
(if uidname is true) in string form”
uidname=”true|false”
gid=”on UNIX, the user’s group ID in integer form or
Attributes
• filename—The name of the file to create on the endpoint.
• attributes—One or more letters specifying the attributes for the file:
• r—Read only
• s—System
• h—Hidden
• a—Archive
• c—Compressed
• shared—A boolean value (true or false) specifying whether the file
specified is to be shared.
• delete—A boolean value (true or false) specifying whether the file
specified is to be deleted from the endpoint (instead of being created).
• selfregister—A boolean value (true or false) specifying whether the file
(with the .ocx or .dll file extensions on Windows) should self-register.
• reference—A boolean value (true or false) specifying whether the file
should be packaged by reference. (See Adding Files by Reference on page 60.)
• installpol—A string specifying the installation policy for this object.
• updatepol—A string specifying the update policy for this object.
• uninstallpol—A string specifying the uninstallation policy for this object.
• verifypol—A string specifying the verification policy for this object.
• verifynipol—A string specifying the verification not installed policy for
this object.
• repairpol—A string specifying the repair policy for this object.
For a description of the policies available, see Appendix B: Policies for Installation,
Update, Uninstallation, Verification, and Repair on page 279.
<SHORTCUT>
Specifies the information for one shortcut to be created on the endpoint for the
channel.
Syntax
<SHORTCUT
shortcutname=”name of the shortcut”
path="path that the shortcut points to"
arguments=”any arguments to pass to the shortcut”
startlocation=”the working directory”
description=”description for the shortcut”
run=normal|minimized|maximized
iconpath=”full path of the icon image
iconpos="0 to 100"
jitupdate="true|false"
jitrepair="true|false"
installpol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
updatepol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
uninstallpol="remove|installed_prompt|always|installed|
never|inherit"
verifypol="inherit|content|exists|never"
verifynipol="inherit|content|exists|never"
repairpol="inherit|content|never"
/>
Attributes
• shortcutname—The name of the shortcut to create on the endpoint.
• path—The path and name of the file to which the shortcut points.
• arguments—The arguments to pass to the shortcut.
• startlocation—The path to the directory where the original item is or a
directory that contains some files necessary for a program (that the
shortcut points to) to run.
• description—A string describing the shortcut.
• run—A string specifying how you want the window to display this item
when the shortcut is opened:
• normal—Standard window
• minimized—A button on the task bar
• maximized—Full screen
• iconpath—A path to the icon for the shortcut.
• iconpos—An integer from 0 to 100 specifying the position of the icon
specified in the iconpath attribute.
• jitupdate—A boolean value (true or false) specifying whether the
application pointed to by the shortcut should get updated before running
when the shortcut is opened. (See Updating and Repairing Applications Using
Shortcuts Before Startup (Windows Only) on page 150.)
• jitrepair—A boolean value (true or false) specifying whether the
application pointed to by the shortcut should get repaired before running
when the shortcut is opened. (See Updating and Repairing Applications Using
Shortcuts Before Startup (Windows Only) on page 150.)
• installpol—A string specifying the installation policy for this object.
• updatepol—A string specifying the update policy for this object.
• uninstallpol—A string specifying the uninstallation policy for this object.
• verifypol—A string specifying the verification policy for this object.
• verifynipol—A string specifying the verification not installed policy for
this object.
• repairpol—A string specifying the repair policy for this object.
For a description of the policies available, see Appendix B: Policies for Installation,
Update, Uninstallation, Verification, and Repair on page 279.
<REGKEY>
Specifies the information for one registry key to be created on the endpoint for
the channel.
Syntax
<REGKEY
key="the registry key"
installpol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
updatepol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
uninstallpol="installed_prompt|always|installed|
never|inherit"
verifypol="verify|ignore|verify_flexible|inherit"
>
user_specific=”true|false”
<!-- child registry tags -->
</REGKEY>
Attributes
• key—The registry key to create on the endpoint.
• installpol—A string specifying the installation policy for this object.
• updatepol—A string specifying the update policy for this object.
• uninstallpol—A string specifying the uninstallation policy for this object.
• verifypol—A string specifying the verification policy for this object.
• user_specific—A boolean value (true or false) specifying whether the
object is specific to each local user. (See Working with Packages that Contain
User-Specific Files and Registry Entries on page 143.)
For a description of the policies available, see Appendix B: Policies for Installation,
Update, Uninstallation, Verification, and Repair on page 279.
<REGVALUE>
Specifies the information for one registry value to be created on the endpoint
for the channel.
Syntax
<REGVALUE
name="the name of the key-value pair"
value="the value of the key-value pair"
type="reg_sz|reg_dword|reg_binary"
installpol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|
newer_timestamp_prompt|newer_timestamp_noprompt|inherit"
updatepol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
uninstallpol="installed_prompt|always|installed|
never|inherit"
verifypol="verify|ignore|verify_flexible|inherit"
/>
Attributes
• name—A string specifying the name of the registry key-value pair to create
on the endpoint.
• value—A string specifying the value of the registry key-value pair to
create on the endpoint.
• type—A string specifying the type of registry key-value pair to create on
the endpoint:
• reg_sz—A string
• reg_dword—A 32-bit integer in hexadecimal format.
• reg_binary—A hexadecimal binary value.
• installpol—A string specifying the installation policy for this object.
• updatepol—A string specifying the update policy for this object.
• uninstallpol—A string specifying the uninstallation policy for this object.
• verifypol—A string specifying the verification policy for this object.
For a description of the policies available, see Appendix B: Policies for Installation,
Update, Uninstallation, Verification, and Repair on page 279.
<METABASEKEY>
Specifies the information for one metabase key to be created on the endpoint
for the channel.
Syntax
<METABASEKEY
key="the metabase key"
installpol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
updatepol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
uninstallpol="installed_prompt|always|installed|
never|inherit"
verifypol="verify|ignore|verify_flexible|inherit"
>
<!-- child metabase tags -->
</METABASEKEY>
Attributes
• key—The metabase key to create on the endpoint.
• installpol—A string specifying the installation policy for this object.
• updatepol—A string specifying the update policy for this object.
• uninstallpol—A string specifying the uninstallation policy for this object.
• verifypol—A string specifying the verification policy for this object.
For a description of the policies available, see Appendix B: Policies for Installation,
Update, Uninstallation, Verification, and Repair on page 279.
<METABASEVALUE>
Specifies the information for one metabase value to be created on the endpoint
for the channel.
Syntax
<METABASEVALUE
id="integer ID"
usertype="integer user type"
attribute="inherit|insert_path|reference|
secure|volatile"
value="the metabase value"
type="met_sz|met_dword|met_binary|
met_expand_sz|met_multi_sz"
installpol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
updatepol="newer_version_prompt|newer_version_noprompt|
notexist|exists|always|newer_timestamp_version_prompt|
newer_timestamp_version_noprompt|never|newer_timestamp_prompt|
newer_timestamp_noprompt|inherit"
uninstallpol="installed_prompt|always|installed|
never|inherit"
verifypol="verify|ignore|verify_flexible|inherit"
/>
Attributes
• id—An integer specifying the ID of the metabase value to create on the
endpoint.
• usertype—An integer specifying metabase value’s user type. (For
descriptions of the available user types, see Editing Metabase Value Data on
page 78.)
• attribute—A string specifying the attributes for the metabase value: (For
descriptions of the available attributes, see Editing Metabase Value Data on
page 78.)
• inherit
• insert_path
• reference
• secure
• volatile
• value—The data for the metabase value to create on the endpoint.
• type—A string specifying the type of the metabase value: (For descriptions
of the available types, see Adding Metabase Entries to a Channel on page 76.)
• met_sz
• met_dword
• met_binary
• met_expand_sz
• met_multi_sz
• installpol—A string specifying the installation policy for this object.
• updatepol—A string specifying the update policy for this object.
• uninstallpol—A string specifying the uninstallation policy for this object.
• verifypol—A string specifying the verification policy for this object.
For a description of the policies available, see Appendix B: Policies for Installation,
Update, Uninstallation, Verification, and Repair on page 279.
<MODIFIERGROUP>
Specifies the information for one text modifier group in the channel. It contains
the text modifiers that affect a single file.
Syntax
<MODIFIERGROUP
name="name"
filepath="the filepath that this modifier group is associated
with"
installpol="always|never|inherit"
updatepol="always|never|reinstall|inherit"
>
<!--child text modifier tags -->
</MODIFIERGROUP>
Attributes
• name—A name for the text modifier group.
• filepath—The path of the ASCII text file to be modified.
• installpol—A string specifying the installation policy for this object.
• updatepol—A string specifying the update policy for this object.
For a description of the policies available, see Appendix B: Policies for Installation,
Update, Uninstallation, Verification, and Repair on page 279.
<MODIFIER>
Specifies the information for one text modifier in the channel.
Syntax
<MODIFIER
name="a name for the text modifier"
type="insertline|searchline|searchreplace"
installpol="always|never|inherit"
updatepol="always|never|reinstall|inherit"
<!-- type-specific tags -->
/>
Attributes
• name—A name for the text modifier.
• type—A string (insertline, searchline, or searchreplace) specifying the
type of text modifier. For more information about the types of text
modifiers and the options available for each one, see Modifying ASCII Text
Files on page 152.
• installpol—A string specifying the installation policy for this object.
• updatepol—A string specifying the update policy for this object.
For a description of the policies available, see Appendix B: Policies for Installation,
Update, Uninstallation, Verification, and Repair on page 279.
MSI Tags
MSI tags all belong inside the <PACKAGE> tag and apply to MSI channels only.
This section describes the following MSI tags:
<MSI_INSTALLATION>
<MSI_ UILEVEL>
<MSI_PATCHES>
<MSI_PATCH>
<MSI_TRANSFORMS>
<MSI_TRANSFORM>
<MSI_DOWNLOAD>
<MSI_POLICIES>
<MSI_LOGGING>
<MSI_INSTALLATION>
Specifies how Windows Installer installs files after the package has been
downloaded.
Syntax
<MSI_INSTALLATION
installmode="normal|admin|asis"
reinstall="true|false"
usersettable="true|false"
msidir="the default directory to hold the .msi, patch, and
transform files prior to install"
properties="installation properties in name=value form, each
separated by at least one space"
/>
<MSI_ UILEVEL>
Specifies the level of user interface (UI) that Windows Installer presents to the
user when it installs the packaged application.
Syntax
<MSI_UILEVEL
type="default|none|basic|reduced|full"
omiterrordialogs="true|false"
/>
<MSI_PATCHES>
Contains the patches for a Windows Installer application.
Syntax
<MSI_PATCHES
reinstall="true|false"
>
<MSI_PATCH>
Specifies the information for one patch file.
Syntax
<MSI_PATCH
path="full path to the patch file"
properties="patch properties in name=value form, each separated
by at least one space"
/>
<MSI_TRANSFORMS>
Contains the transforms for a Windows Installer application. It also specifies
how transforms are packaged and applied to an installation.
Syntax
<MSI_TRANSFORMS
reinstall="true|false"
globalpath="a semicolon-separated list of paths that contain
transforms to apply"
>
<MSI_TRANSFORM>
Specifies the information for one transform file.
Syntax
<MSI_TRANSFORM
path="full path to the transform file"
/>
<MSI_DOWNLOAD>
Specifies which files will be downloaded in the package, and whether or not
they will be deleted after the installation.
Syntax
<MSI_DOWNLOAD
option="required|all|msi"
deleteafterdownload="true|false"
srclist="the URL, local, or network path to search for files"
/>
<MSI_POLICIES>
Specifies the user and machine policies that affect the installation behavior of
Windows Installer.
Syntax
<MSI_POLICIES
installer="system|all|managed"
elevated="system|true|false"
storerollback="system|true|false"
alternativebrowsing="system|true|false"
nonadminbrowsing="system|true|false"
alternatemedia="system|true|false"
logging="system|true|false"
loggingargs="the command line arguments for logging"
/>
<MSI_LOGGING>
Specifies Windows Installer logging options.
Syntax
<MSI_LOGGING
logfilepath="the path of the log file to be generated"
outofmemory_fatalexit="true|false"
errormessages="true|false"
warningmessages="true|false"
userrequests="true|false"
statusmessages="true|false"
validsourcelocation="true|false"
diskspace="true|false"
installactions="true|false"
datarecord="true|false"
userinterface="true|false"
propertyvalues="true|false"
verbose="true|false"
flushevery20="true|false"
flushline="true|false"
/>
<MODIFY_OBJECT_ATTRIBUTES>
<MODIFY_OBJECT>
Specifies the objects in the package that you want to search for and modify. It
is a container tag.
Syntax
<MODIFY_OBJECT
types=”directory,file,dll,shortcut,registry_key,registry_value,any”
canonical_path=”path of the objects to search for”
canonical_path_casesensitive=”true|false”
>
<!-- child modify object tags -->
</MODIFY_OBJECT>
Attributes
• types—The type of objects to search for in the package. You can specify a
comma-delimited list.
Required: yes
Default: none
Possible values: directory
file
dll
shortcut
registry_key
registry_value
any
Required: no
Default: none
Possible values: A string pattern representing a path.
You can substitute wildcard characters for parts of
the path. You can use an asterisk (*) as a substitute
for zero or more characters, and you can use a
question mark (?) as a substitute for any single
character.
For example, searching for c:\\*.ex? will locate
c:\\notepad.exe, but not c:\\notepad.exee.
Required: no
Default: false
Possible values: true or false
<MODIFY_OBJECT_ATTRIBUTES>
Specifies the attributes of the objects in the package that you want to modify. It
is not a container tag.
Syntax
<MODIFY_OBJECT_ATTRIBUTES
installpol=”NEWER_VERSION_PROMPT|NEWER_VERSION_NOPROMPT|
NOTEXIST|EXISTS|ALWAYS|NEWER_TIMESTAMP_VERSION_PROMPT|
NEWER_TIMESTAMP_VERSION_NOPROMPT|NEVER|NEWER_TIMESTAMP_PROMPT|
NEWER_TIMESTAMP_NOPROMPT|INHERIT”
updatepol=”NEWER_VERSION_PROMPT|NEWER_VERSION_NOPROMPT|
NOTEXIST|EXISTS|ALWAYS|NEWER_TIMESTAMP_VERSION_PROMPT|
NEWER_TIMESTAMP_VERSION_NOPROMPT|NEVER|NEWER_TIMESTAMP_PROMPT|
NEWER_TIMESTAMP_NOPROMPT|INHERIT”
verifypol=”INHERIT,CONTENT,ATTRIBUTES,
VERSION_INCREASE,EXISTS,NEVER“
verifynipol=”INHERIT,CONTENT,ATTRIBUTES,
VERSION_INCREASE,EXISTS,NEVER“
repairpol=”INHERIT,CONTENT,NEVER“
uninstallpol=”REMOVE|INSTALLED_PROMPT|
ALWAYS|INSTALLED|NEVER|INHERIT“
delete=”true|false”
attributes=”Windows:(r|s|h|a|c)*;UNIX:(0-7)(0-7)(0-7)(0-7)”
shared=”true|false”
register=”true|false”
path=”c:\winnt\system3\notepad.exe”
arguments=”argument1 argument2 argument3”
startlocation=”c:\winnt\”
description=”description_string”
run=”NORMAL|MINIMIZED|MAXIMIZED”
iconpath=”c:\winnt\icon.ico”
iconpos=”integer from 1 to 100”
jitupdate=”true|false”
jitrepair=”true|false”
value=”text or hexadecimal string”
type=”REG_SZ|REG_DWORD|REG_BINARY”
uid=”on UNIX, the user’s user ID in integer form”
gid=”on UNIX, the user’s group ID in integer form
user_specific=”true|false”
Attributes
Note: For a description of the different policies, see Appendix B: Policies for
Installation, Update, Uninstallation, Verification, and Repair on page 279.
Required: no
Default: none
Possible values: NEWER_VERSION_PROMPT
NEWER_VERSION_NOPROMPT
NOTEXIST
EXISTS
ALWAYS
NEWER_TIMESTAMP_VERSION_PROMPT
NEWER_TIMESTAMP_VERSION_NOPROMPT
NEVER
NEWER_TIMESTAMP_PROMPT
NEWER_TIMESTAMP_NOPROMPT
INHERIT
Valid Object Types: any
Required: no
Default: none
Possible values: NEWER_VERSION_PROMPT
NEWER_VERSION_NOPROMPT
NOTEXIST
EXISTS
ALWAYS
NEWER_TIMESTAMP_VERSION_PROMPT
NEWER_TIMESTAMP_VERSION_NOPROMPT
NEVER
NEWER_TIMESTAMP_PROMPT
NEWER_TIMESTAMP_NOPROMPT
INHERIT
Valid Object Types: any
Required: no
Default: none
Possible values: A comma-separated list of the following policies:
INHERIT
CONTENT
ATTRIBUTES
VERSION_INCREASE
EXISTS
NEVER
Valid Object Types: any
Required: no
Default: none
Possible values: A comma-separated list of the following policies:
INHERIT
CONTENT
ATTRIBUTES
VERSION_INCREASE
EXISTS
NEVER
Valid Object Types: any
Required: no
Default: none
Possible values: A comma-separated list of the following policies:
INHERIT
CONTENT
NEVER
Valid Object Types: any
Required: no
Default: none
Possible values: REMOVE
INSTALLED_PROMPT
ALWAYS
INSTALLED
NEVER
INHERIT
Valid Object Types: any
Required: no
Default: none
Possible values: true or false
Valid Object Types: any
Required: no
Default: none
Possible values: Windows:
(r|s|h|a|c)*
UNIX:
(0-7)(0-7)(0-7)(0-7)
Valid Object Types: file
dll
directory
Required: no
Default: none
Possible values: true or false
Valid Object Types: file
dll
• register—A boolean value (true or false) specifying whether the DLL file
should be registered. If this attribute is set to true, the DLL file will be
registered (on Windows).
Required: no
Default: none
Possible values: true or false
Valid Object Types: dll
Required: no
Default: none
Possible values: A file system path.
For example, c:\winnt\system32\notepad.exe
Valid Object Types: shortcut
• arguments—The arguments that the shortcut should pass to the path value
(specified in the path attribute) before execution.
Required: no
Default: none
Possible values: A space-separated list of arguments.
Required: no
Default: none
Possible values: A file system path.
For example, c:\winnt\
Valid Object Types: shortcut
Required: no
Default: none
Possible values: A string.
Valid Object Types: shortcut
• run—A string specifying how you want the window to display this item
when the shortcut is opened (window mode).
Required: no
Default: none
Possible values: NORMAL—Standard window
MINIMIZED—A button on the task bar
MAXIMIZED—Full screen
Valid Object Types: shortcut
Required: no
Default: none
Possible values: A file system path to the icon.
For example, c:\winnt\icon.ico
Valid Object Types: shortcut
Required: no
Default: none
Possible values: An integer from 1 to 100.
Valid Object Types: shortcut
Required: no
Default: none
Possible values: true or false
Valid Object Types: shortcut
Required: no
Default: none
Possible values: true or false
Valid Object Types: shortcut
Required: no
Default: none
Possible values: A text or hexadecimal string (depending on the
type of registry value).
Valid Object Types: registry_value
Required: no
Default: none
Possible values: REG_SZ
REG_DWORD
REG_BINARY
Valid Object Types: registry_value
Required: no
Default: false
Possible values: true or false
Valid Object Types: directories and registry keys
Snapshot Tags
Snapshot tags all belong inside the <PACKAGE> tag and apply when taking
snapshots from the command line only (see Creating Pre-Install and Post-Install
Snapshots on page 264).
Note: You can only use these tags when taking snapshots from the command
line; you cannot apply them to a packaged application.
This section describes the following snapshot tags:
<SNAPSHOT>
<FILESYSTEM>
<DIRECTORY>
<FILTER>
<REGISTRY>
<REGKEY>
<FILTER> (same as directory)
<METABASE>
<METKEY>
<FILTER> (same as directory)
<SNAPSHOT>
Defines a snapshot created using Packager for Shrinkwrap Windows
Applications. The <SNAPSHOT> tag encloses all the other tags for a snapshot.
Syntax
<SNAPSHOT
ini="true|false"
>
<!-- child snapshot tags -->
</SNAPSHOT>
Attributes
• ini—A boolean value (true or false) specifying whether you want INI
files to be treated as special file objects. If this attribute is set to true,
Application Packager will parse the INI files and capture any changes
made to the key and value pairs in them. Any changes found by
Application Packager are merged with the existing file found at the
endpoint. By default, this check box is selected. If you want Application
Packager to process INI files as ordinary files and not merge changes, you
can set this attribute to false.
<FILESYSTEM>
Contains all the directories to include and exclude in the snapshot.
Syntax
<FILESYSTEM
include="true|false"
includedeletes="true|false"
>
<!-- child filesystem tags -->
</FILESYSTEM>
Attributes
• include—A boolean value (true or false) specifying whether you want
include the specified directories in the snapshot. Set the attribute to true to
include and false to exclude.
• includedeletes—A boolean value (true or false) specifying whether you
want capture the removal of the specified directories in the snapshot. Set
the attribute to true to include and false to exclude.
<DIRECTORY>
Defines a directory to include in the snapshot.
Syntax
<DIRECTORY
path="a directory path"
/>
Attributes
• path—The path of a directory that you want to include in the snapshot.
<FILTER>
Defines a filter that specifies a directory, file, or key to ignore when taking the
snapshot.
Syntax
<FILTER
type="directory|file|key"
noun="name|parent|path"
verb="is|isn't|contains|not_contains|begins_with|ends_with"
adverb="the value of the filter"
enabled="true|false"
description=”description of the filter”
/>
Attributes
• type—A string representing the type of item (directory, file, and key) for
which you are creating a filter.
<REGISTRY>
Contains the registry entries to include and exclude in the snapshot.
Syntax
<REGISTRY
include="true|false"
includedeletes="true|false"
>
<!-- child registry tags -->
</REGISTRY>
Attributes
• include—A boolean value (true or false) specifying whether you want
include the specified registry entries in the snapshot. Set the attribute to
true to include and false to exclude.
• includedeletes—A boolean value (true or false) specifying whether you
want capture the removal of the specified registry entries in the snapshot.
Set the attribute to true to include and false to exclude.
<REGKEY>
Defines a registry key to include in the snapshot.
Syntax
<REGKEY
key="a registry key to include in the snapshot"
/>
Attributes
• key—The registry key that you want to include in the snapshot.
<FILTER>
See the description for <FILTER> on page 366.
<METABASE>
Contains the metabase entries to include and exclude in the snapshot.
Syntax
<METABASE
include="true|false"
includedeletes="true|false"
>
<!-- child metabase tags -->
</METABASE>
Attributes
• include—A boolean value (true or false) specifying whether you want
include the specified metabase entries in the snapshot. Set the attribute to
true to include and false to exclude.
• includedeletes—A boolean value (true or false) specifying whether you
want capture the removal of the specified metabase entries in the
snapshot. Set the attribute to true to include and false to exclude.
<METKEY>
Defines a metabase key to include in the snapshot.
Syntax
<METKEY
key="a metabase key to include in the snapshot"
/>
Attributes
• key—The metabase key that you want to include in the snapshot.
<FILTER>
See the description for <FILTER> on page 366.
This appendix lists the system macros available for Windows machines. It also
gives a brief description and example for each macro.
In the Package Editor, these system macros are listed in the Available Macros
section of the Macro tab. The following table lists the macros that you can use
in packaged applications that you will install on Windows machines.
Table 30. Windows System Macros
A key benefit to using the File Packager is being able to modify the specific
configuration for an application installation. After you have packaged the files
that make up an application, you can use the Application Packager’s Package
Editor component to change file attributes, file permissions, as well as install-
and update-time policies. You can also use scripts and text file modifiers to
change files at install time. (For definitions of some of these terms, see the table
at the end of this section.)
Content Replicator (Content Distribution module). Whereas Application
Packager is meant to be used for applications and for a small number of files,
Content Replicator was designed to replicate large numbers of files and
directories, and also very large files. If you need to run pre-install or post-
install scripts, you can use Deployment Manager to create remote system
commands for the scripts. Content Replicator also enables you to package
content (for example, HTML files) on one platform and then replicate them to
various UNIX and Windows platforms.
Note: You cannot subscribe the tuner directly to a data channel created by
Content Replicator. You need to use a Content Replicator command to install
the files from the data channel. In contrast, for channels created with
Application Packager, you do subscribe the tuner to the channel.
The following table provides more detail about the differences between
Content Replicator and File Packager.
DOC
Application Installer
Application Packager
A Marimba application used to package software application (and subsequent
updates) into a format that you can then distribute to target endpoints, such as
desktops or servers. It provides an interface to a family of packaging
components, including Packager for Shrinkwrap Windows Applications,
Windows Installer Packager, Custom Application Packager, File Packager, and
Java Packager.
assembly
The primary building block of a .NET framework application. It is a collection
of functionality built, versioned, and deployed as a single implementation unit
(one or multiple files). Assemblies can be static or dynamic:
• Static assemblies can include .NET framework types (interfaces and
classes), as well as resources for the assembly (bitmaps, JPEG files,
resource files, and so on). Static assemblies are stored on disk in portable
executable (PE) files.
• Dynamic assemblies run directly from memory and are not saved to disk
before execution. You can save dynamic assemblies to disk after they have
executed.
Glossary 381
An assembly file usually has the file extension .netmodule. It can be compiled
as part of an EXE or DLL file.
byte-level differencing
A Marimba feature that allows updates to be performed easily, efficiently, and
even automatically. During updates, byte-level differencing means that you
don’t need to transfer entire files. Only the new or changed bytes are
downloaded during updates.
certificate
See security certificate on page 391.
certificate authority
An agency from which security certificates can be obtained, either directly or
through Certificate Manager.
Certificate Manager
A Marimba application that can be used to obtain security certificates from a
certificate authority and to install and manage those certificates.
channel
A format that is used to publish an application or content to a transmitter so
that it can be downloaded by a tuner to a desktop or server endpoint. It
contains all the information necessary to install the application on endpoints. A
channel can be:
• An application of any type (Windows, Java, and so on)
• One or more content files, containing HTML or any data
• A combination of the above
channel category
Any of a number of named sets into which channels are organized in a tuner’s
channel list. For each category, the channel list shows a colored bar containing
the category title.
Channel Copier
A Marimba application that can be used to copy channels (and information
about them, such as channel properties) from a transmitter, CAR file, or
package directory to a transmitter or CAR file. Using Channel Copier to copy a
channel to a transmitter constitutes publishing the channel.
channel index
A representation of a channel’s file structure, including each file’s contents
along with other information, such as the file’s checksum. The transmitter
caches channel indexes for all channels published to it, to optimize its handling
of requests for channel updates.
Channel Manager
The channel that provides the user interface to the standard tuner; the tuner’s
default primary channel.
channel parameter
Information for installing and launching a packaged application. The
information in this file is used by the tuner when you run a channel to install
and launch the packaged application. See also parameters.txt on page 388.
channel property
One of many characteristics of a channel that provide information about the
channel, such as who created or published it, what its URL is, when it was last
updated, and when the next update is scheduled. Through the tuner, a user can
view channel properties and set some of them; additional channel properties
can be set by an administrator or a channel publisher. See also channel parameter
on page 383 and tuner property on page 394.
channel segment
See segment (of a channel) on page 391.
channel-signing certificate
A security certificate, indicating who published a particular channel, that’s
installed in the tuner from which the channel is being published and is used to
digitally sign the channel when it’s published.
channel update
The synchronization of a tuner’s subscribed channel with new channel data
from the transmitter, made by the tuner either automatically according to an
update schedule or specifically at the user’s request.
Glossary 383
channel URL
A channel’s uniform resource locator, which is assigned when the channel is
published and provides a unique identifier for that channel on the transmitter.
By specifying the channel URL, a user can subscribe to the channel.
checkpoint restart
A Marimba feature that enables the downloading of a channel (or channel
update) to continue seamlessly when the tuner restarts after an interruption, as
might be caused by a power outage or the loss of a network connection.
command line
An interface provided by most products that enables commands to be entered,
either at a command prompt or in a script or batch file; useful for automating
the entry of complex commands.
Content Replicator
Content Replicator is a Marimba Server Management component that does the
work of taking data files from a source system, sending the content to a data
server (that is, a transmitter), and then previewing, staging, installing, or
rolling back the content on destination machines. Content Replicator has the
following capabilities, among others:
• Takes directories from a source system on one platform and publishes
them in a format that allows for deployment on Windows NT, Windows
2000, Solaris, HP-UX, AIX, and Linux operating systems
• Downloads and activates content and applications on one or more target
servers
• Can install applications and data files regardless of whether some files are
locked on the target server; can also unlock shared network resources
• Allows you to control the rate at which content is deployed, to
accommodate bandwidth connections that vary, from high-speed
backbone access to fractional T1 speeds
dependency
A requirement that you want to check at the endpoint before downloading and
installing a channel. For example, you may want to require that a certain file or
a certain channel exist at the endpoint. If dependencies cannot be validated, the
File Packager
An Application Packager component that allows you to package a collection of
files (for example, spreadsheets, HTML files, or templates).
file reference
An Application Packager feature that allows you to publish the contents of a
file directly to the transmitter instead of adding it to the package directory first.
Using file references allows you to save disk storage space and to update files
without having to replace them manually.
history entry
An annotation in the package that allows you to keep a record or history of the
changes to a channel. A history entry might be especially useful if multiple
users are editing a package. The following fields are available for each history
entry:
• Timestamp
• Author
• E-mail
• Phone
• Subject
• Notes
Java Packager
An Application Packager component that allows you to package a Java
application and set options, such as using a different Java virtual machine
(JVM).
Glossary 385
just-in-time (JIT) application deployment
An operation for ensuring that an application is updated or repaired before it is
used. Using the Package Editor, you can configure the Windows shortcut used
to start an application, so that before the application starts, one of the following
operations take place:
• The application gets updated.
• The application gets verified, and if necessary, repaired.
• The application gets both updated and repaired.
These operations are performed before the application is started, whenever the
shortcut is used. Using this feature allows you to seamlessly update and repair
an application, without requiring users at the endpoints to manually perform
any operations, other than double-clicking the shortcut.
macro
An Application Packager feature that allows you to customize and replace
items in a channel, such as a file name or directory path. There are some pre-
defined macros included with Application Packager, and you can also create
user-defined macros.
major update
An update where the contents of the channel are changed. A major update
means files, registries, environment variables, or text modifiers have been
added, changed, or removed from the channel. For files, content changes
would include any changes in file attributes also.
manifest file
A file that contains the code and instructions required to install and update an
application packaged as a channel.
master transmitter
The transmitter whose channels a repeater or mirror transmitter replicates.
merge modules
Pre-compiled bundles of components (files, registry entries, and other
modules) that enable developers to easily add third-party features to a
Microsoft installation (MSI). See also MSI package on page 387.
minor update
An update where the contents of the channel are not changed. A minor update
means that the channel changed, but there are no new, deleted, or changed
files, registry values, or environment variables.
mirror
To replicate channels from a master transmitter to another transmitter for the
purpose of balancing the tuner request load; see mirror transmitter on page 387.
mirror transmitter
A transmitter that replicates channels from a master transmitter for the
purpose of balancing the tuner request load, but that (unlike a repeater)
doesn’t have tuner requests redirected to it from the master transmitter. Users’
tuners subscribe to channels directly on the mirror transmitter.
MSI package
See Microsoft installation (MSI) package on page 387.
.NET Packager
A component of Application Packager that allows you to package applications
that have been created using Microsoft’s .NET framework. The .NET
framework is Microsoft’s platform for building, deploying, and running Web
services and applications.
Glossary 387
package (a channel)
To prepare some kinds of applications and content for publishing as a channel,
as required by the transmitter. Java application or applet channels and HTML
content don’t require packaging before they can be published. See also
Application Packager on page 381 and channel on page 382.
package directory
The directory in which Application Packager stores the files for a packaged
application. A package directory is created when you use any of the packager
components of Application Packager to package a software application. It is
also sometimes referred to as the channel directory or publish directory.
Channel directory is also sometimes used to refer to the subdirectory of the
tuner’s workspace directory in which the files for a particular channel are
stored.
Package Editor
A component of Application Packager that allows you to add, edit, and remove
files, directories, and registry entries in packaged applications. You can also
use the Package Editor to set macros, customize environment settings, add
installation scripts, and so on.
parameters.txt
A property file that contains channel parameters and is located in the package
directory for that channel. It stores information for installing and launching a
packaged application. The information in this file is used by the tuner when
you run a channel to install and launch the packaged application.
patch files
Storage files for MSI packages that contain at least one database transform that
adds patching information to the database of its target installation. They
typically have the .msp file extension. Patches can be applied to more than one
application or can upgrade an application into another application or version.
See also Microsoft installation (MSI) package on page 387.
prefs.txt
A property file in the tuner’s workspace directory in which tuner properties
can be set when the tuner is installed, or in some cases after installation.
properties.txt
A property file in any of several locations applying to channels, tuners, or
transmitters (for example, in a package directory, the tuner’s workspace
directory, or the transmitter’s workspace directory).
property
See channel property on page 383 or tuner property on page 394.
property file
A file containing key-value pairs that define characteristics of a channel, tuner,
or transmitter, depending on the name of the file and where it’s stored.
Channel properties and parameters, tuner properties, and transmitter
properties are stored in property files.
publish (a channel)
To copy a channel (or channel update) to a transmitter in a way that enables it
to be downloaded by a tuner. This operation (which includes copying
information about the channel, such as channel properties) can be performed
with Channel Copier or, as an alternative that users of earlier versions of
Marimba products might favor, with Publisher.
publish directory
See package directory on page 388.
Glossary 389
Publisher
A Marimba application that can be used to publish channels to a transmitter, as
an alternative to Channel Copier; sometimes favored by those who have
experience with earlier versions of Marimba’s products.
repair
An action performed on a channel to check and fix problems. When you repair
a channel, the files and other objects in the channel are first verified. After
verification is complete, one of the following occurs:
• There are no object mismatches. No repairs are needed.
• There are object mismatches. The tuner re-installs the affected files or
registry entries if they are available from the tuner storage. If not, the
tuner contacts the transmitter to download the files or registry entries
needed to complete the repair.
See also verify on page 394.
repeater
A transmitter on which channels from a master transmitter have been
replicated, and to which requests made by tuners can be redirected from the
master transmitter.
replication
The transfer of channels from a master transmitter to a repeater or mirror
transmitter. This is just a duplication of the channels and not the same
operation performed by Channel Copier, which publishes channels when it
copies them to a transmitter.
rollback install
script
A file in the form of batch files, executables, or Java classes that you can use to
customize the behavior of your channel on the endpoint. Scripts are invoked at
key times in your channel’s lifecycle (install, uninstall, update, verify, repair,
execute, or a combination of these phases). There can be any number of scripts
in a channel.
security certificate
A mechanism for ensuring that a channel being subscribed to comes from the
proper source (channel-signing certificate on page 383).
segment ID
A string that identifies the specific platform and locale for which a channel
segment is intended — for example, Windows NT,x86/en_US.
semisilent installation
A mode of installation (of a packaged channel) that provides user feedback in
the form of progress bars but doesn’t offer any installation options.
services
Programs or processes that perform a specific system function, usually as
background tasks, to support other programs on Windows NT, Windows 2000,
and Windows XP. Typically, they do not require user interaction and do not
have a user interface. Some Windows applications include and install services.
Glossary 391
signed channel
A channel (or channel update) that has been digitally signed by means of a
channel-signing certificate, guaranteeing subscribers that it comes from a
reliable source and is not an unauthorized, possibly corrupted, copy. When the
user subscribes to a signed channel, a dialog box appears that requests
permission to download the channel.
silent installation
A mode of installation (of a packaged channel) that provides no user feedback
and offers no installation options. It displays no dialog boxes or progress bars
to the end user. The installer uses all of the default channel settings during
installation.
template file
See XML template file on page 395.
transform files
Files for MSI packages that the Windows Installer uses to modify the
installation database at installation time and dynamically affect the installation
behavior. Transform files typically have a .mst file name extension. Transform
files are applied at initial installation; they cannot be applied to an already
installed application.
See also Microsoft installation (MSI) package on page 387.
transmitter
The Marimba server component; it is essentially a server that delivers
applications and content in the form of channels. It is similar to a Web server,
but instead of serving Web pages, it serves channels. Channels (and channel
updates) are published to a transmitter and downloaded from there to its
clients (either tuners or other transmitters running as repeaters or mirror
transmitters). The transmitter is itself a channel that runs on the tuner or some
other tuner under the control of an administrator.
Transmitter Administrator
trusted channel
A channel that has been given permission to read or write data anywhere on
the user’s system and to call any code, including operating system code.
Channels must be signed in order to be designated as trusted.
tuner
The Marimba client component; it is the interface through which Marimba
components interact. The tuner is the application through which users
subscribe to channels that have been published on a transmitter. The tuner
downloads the channel files (or updates to them) from the transmitter to the
user’s workstation.
Tuner Administrator
A Marimba application that allows you manage tuners remotely, controlling
which channels appear on tuners or changing their configuration in other
ways.
Glossary 393
tuner property
One of many characteristics of a tuner, including the URL of its primary
channel, the URL for tuner updates, and the update schedule for its channels,
as well as licenses and proxy details. Tuner properties can be set when the
tuner is configured with Tuner Packager, and some properties can also be set
during or after tuner installation.
update schedule
The periodic timing with which updates are automatically delivered to
channels that have been subscribed to and downloaded. This schedule is set up
either when the channel is published or later at the user’s request.
verify
An action performed on a channel to check if there are any problems. When
you verify a channel, the files and other objects in the channel are compared
with the information for the channel when it was originally installed. Any
object mismatches found are recorded in the log file.
WFP
See Windows File Protection (WFP) on page 394.
Windows Installer
An installation and configuration service that ships as part of the Microsoft
Windows 2000 operating system; it can also be installed on Windows 95/98
and Windows NT 4.0. See also Microsoft installation (MSI) package on page 387.
WTS
See Windows Terminal Services (WTS) on page 394.
Glossary 395
396 Application Packager Administrator’s Guide
Index
DOC
Index 399
editing channels (.NET Packager) 210 selecting which to ignore during snapshots 41
using to edit channels 55 user specific 143
environment variables viewing the contents of INI and ASCII text
adding to a channel 110 files 64
creating in a channel 110 files directory 19
creating macros for 84 filter for snapshots
deleting from a channel 111 adding to the list of files to ignore 39
editing 111 creating a list of files and directories to ignore 38
removing from a channel 111 editing the list of files and directories to
using in a channel 109 ignore 41
using in a macro 87 removing from the list 41
environment, setting up for packaging 34 using macros in 40
-exec command-line option 276 using XML template files 236
executable scripts, using to customize channels 121 find feature, finding files and registry entries 82
formatting conventions 25
F
File Packager G
command-line options 262 GAC (global assembly cache)
compared with Content Replicator 375 defined 207
creating a new channel 200 registering assemblies into 211
installation directory 200 garbage collection, for .NET applications 213
overview 199 generic XML tags 311
platform issues 199 global assembly cache (GAC)
updating channels 203 defined 207
file references registering assemblies into 211
adding to a channel 60
benefits to using 60, 173 H
file requirements, configuring for a channel 115 Help buttons 24
file system history entries
adding to a pre-install snapshot 37 adding new history entries 164
excluding items from a snapshot 37 deleting history entries 165
ignoring from a pre-install snapshot 38 editing history entries 165
ignoring specific files or directories 39 information available 164
removing from a pre-install snapshot 38 prompting every time you save changes 164
searching for items in 82 history log files 255
selecting files to ignore by default 41 history logs on endpoints 255
selecting the snapshot source 36 history.log files for channels 97
selecting what to include in a pre-install HTML files, packaging 199
snapshot 37
filebyref command-line argument 272
I
-filepackage command-line option 262 ignore list
files adding files and directories 39
adding by reference to a channel 60 editing the list of files and directories to
adding to a channel 59 ignore 41
delaying the download of 96 removing a filter from the list 41
deleting from a channel 80 IIS metabase
deleting from the endpoints 81 adding keys to a channel 76
DLL. See DLL files check box for capturing 42
editing file properties 62 deleting keys from a channel 80
INI. See INI files overview 43
modifying text files 152 pre-install snapshot 43
renaming 80 importing channels
into Application Packager 31
Index 401
using MSI macros in scripts 85, 121 overview 15, 205
Windows Installer property 85 creating a new channel 207
major updates .netmodule file extension 206, 382
checking dependencies 130 non-MSI XML tags 340
definition of 129
setting scripts to run 130 O
manifest file 19, 97, 143, 323 operating system
merge modules, packaging with MSI 175 registry implications 42
metabase selecting the installation platform 104
adding keys to a channel 76 OR dependencies 120
deleting keys from a channel 80
editing key properties 77
P
editing key values 78 Package by Reference check box 208
overview 43 package directory
pre-install snapshot 43 contents 19
Microsoft installation (MSI). See MSI (Microsoft overview 18
installation) Package Editor
minor updates editing channels 30
checking dependencies 130 editing channels (.NET Packager) 210
definition of 130 overview 15
setting scripts to run 130 using 55
modifiers. See text file modifiers package property macros 84
.msi file name extension 170 packaged .NET channels, editing 210
MSI (Microsoft installation) packaged applications
creating macros 85 editing Windows Installer Packager
database 170, 172 channels 175
file 170 editing with Java Packager 226
macros, using in scripts 121 editing with Package Editor 55
packages, overview 14 importing into Application Packager 31
packaging an MSI database 172 removing from Application Packager’s list 32
packaging with merge modules 175 running from the command line 276
packaging with patch files 180 -packagedir command-line option 271
troubleshooting an MSI package 252 Packager for Shrinkwrap Windows Applications
using macros in scripts 85 command-line options 264
Windows Installer property macros 85 overview 14, 33
MSI XML tags 351 packagers
msiexec.exe program 170 Custom Application Packager 15, 195
.msp files description of the different packagers 14
file name extension 171 File Packager 15
for snapshot files 36 Java Packager 15, 221
.mst file name extension 171, 393 .NET Packager 15, 205
Packager for Shrinkwrap Windows
N Applications 14, 33
naming channels 48 Packager for Windows Installer 14, 171
.NET assemblies. See assemblies packaging
.NET Assembly Policy Configuration dialog box 211 a .NET application 207
.NET Assembly Properties dialog box 211 a set of files 200
.NET framework 15, 205, 387 an MSI database 172
.NET Packager files 199
command-line options 267 Java applications 221
updating channels 217 the removal of an application 51
installation directory 208 packaging machine, setting up 34
packaging process
Index 403
marking for deletion 81 setting for a packaged application 94
policies available for 107, 288 services, Windows
setting policies for 106 adding to a channel 136
uninstalling 107 editing 132
registry value macros 84 managing 131
-remove command-line option 276 removing from a channel 137
removing applications from endpoints 51 Windows Installer (MSI) 170
removing items from the endpoints 81 -setmacro command-line option 277
-repackage command-line option 263, 267, 269, 271 shortcuts
repackaging files adding to a channel 65
in a .NET Packager channel 217 configuring to repair applications before
in a File Packager channel 203 startup 150
in a PDA Packager channel 230 configuring to update applications before
-repair command-line option 277 startup 150
repair policies. See also verification policies -shrinkwrappackage command-line option 265
repairing applications before startup 150 signed directory 19
repairing channels -silent command-line option 277
manually 149 silent installation
overview 146 installing applications in silent mode 20
scheduling automatic channel repair 148 setting for a packaged application 94
restrictions and recommendations for using -snapshot command-line option 264
Application Packager 27 snapshot
rollbacks adding file systems 37
details about automatic rollbacks 95 creating the pre-install snapshot 35
setting for failed installations 95 excluding file system items from 37
when a major update fails 95 file system selection 37
when installation fails 95 files with the .msp extension 36
runchannel program 260 ignoring from file systems 38
-rundir command-line option 277 installing the application to package 47
-runexe command-line option 277 loading snapshot files into Application
runtime scripts 121 Packager 37
metabase selection 43
S modifying post-install snapshot settings 47
save as command when editing channels 166 post-install 47
scripts preparing to install the application 46
directory for 121 registry selection 41
running for major updates 130 removing from file systems 38
running for minor updates 130 saving to a file 45
using MSI macros 85, 121 selecting files to ignore by default 41
using to customize channels 121 selecting the source 36
search and modify XML tags 355 using XML template files 235
search and replace line modifiers XML tags 364
creating 155 SOFTDIST debugging flag 257
defined 152 software distribution process, overview 16
search and replace text modifiers -sourcedir command-line option 271
creating 157 -stagemsi command-line option 277
defined 152 startup options, setting for a channel 92
search feature, finding files and registry entries 82 static assemblies 206
security certificate 28, 225 strong names, for assemblies 216
self-healing channels 146 symbolic links, adding to a channel 65
semisilent installation syntax for runchannel program 260
installing applications in semisilent mode 20 system dependencies
Index 405
Windows Installer database file 170
Windows Installer Packager
command-line options 266
overview 14, 171
Windows Installer packages
customizing 175
editing 176
performing an administrative installation 176
setting command-line properties 177
setting installation modes 176
troubleshooting an MSI package 252
Windows Installer property macros 85
Windows Installer service 170
Windows machines, macros available for 371
Windows registry
making changes 42
selecting what to include and exclude in the
snapshot 41
Windows services
adding to a channel 136
editing 132
managing 131
removing from a channel 137
Windows Terminal Services
adding compatibility flags 163
changing to install mode 46
editing logon scripts 162
making applications compatible with 46, 162
overview 22
support 22
-wipackage command-line option 266
WTS. See Windows Terminal Services
X
XML namespace, for assembly binding 212
XML syntax 311
XML tags
generic tags 311
MSI tags 351
non-MSI tags 340
search and modify tags 355
snapshot tags 364
XML template files
applying to a channel 240
configuring Application Packager to use 234
overview 233
saving Application Packager settings 233
using as filters for packaging 236
using for packaging 235