using the Package Builder - Community - LANDesk

LANDesk ® Management Suite 6.62Successful Package BuildingJune 4, 2003

Building Successful Packages - 2 - v1.0

Successful Package Building using LANDesk®Management SuiteABSTRACTSoftware Packages can be friends or foes. Follow the tips in this document tobuild successful Enhanced Software Distribution packages with the LANDesk®Management Suite Package Builder. Packages can consist of changes capturedusing the Package Builder Wizard, or carefully planned commands that arecreated as part of a configuration script. Using either method, packages arecreated as a stand-alone monolithic executables. These executable files can belaunched independently on a workstation, or deployed to multiple workstations atone time using the LANDesk Desktop Manager console scheduling technology.Leveraging the power of the LANDesk Enhanced Software Distribution agentsinstalled on workstations, several layers of advanced functionality are exposed:• Application Healing - this function allows a package to be reinstalled or"healed" during a subsequent deployment. The healing function onlyreinstalls specific files that are missing or corrupt, not the entire contentsof a package.• Application Policy Management - a package can be scheduled as a policyto any workstation on a network, or to any NDS or ADS user. Complexqueries can be constructed that deploy these policies to groups of users orgroups of target workstations.• Task Completion - this function enables management of the 'occasionallyconnected client' by checking for scheduled tasks that have failed in thepast, or have not yet been run for a workstation. By default, this check ismade upon logon to the LANDesk® Management Suite domain.• Bandwidth Detection - use this feature to prevent flooding of slow WANlinks, or dial-up environments. For example, specifying WAN or LANbandwidth must be available for a package to be installed will prevent thepackage from being installed across a dial-up connection.Now, let's take a look at the Package Builder technology.PACKAGE BUILDER OVERVIEWThe Package Builder (herein referred to as PB) should be installed on a cleanOS installation. Having few applications installed will highly increase successwhen building a package.Building Successful Packages - 5 - v1.0

As a package contains files, registry keys, and other configuration items, it isimportant to build a package on the same platform to which it will be installed.For example, building a package on a Windows* XP operating system and theninstalling that package to a Windows 98 operating system will probably fail.Library files, registry keys and directory structures are different on theseoperating systems and may cause improper installation or functionality of theresulting application installation.The package also includes engine files that manage the package installation onthe target. The main installation engine is INST32.EXE.The PB Wizard uses snapshot technologyto take a ‘picture’ of the PB workstationbefore the installation of an application, andcompares that pre-installation snapshot to apost-installation snapshot to discover whatchanged on the workstation during theapplication installation. These changes are captured in a configuration (.CFG)file and then, when the package is built, all files that are referenced in theconfiguration file are copied into the package, along with the configuration fileitself. The configuration file is then used during package installation to list thechanges that must be made to the target workstation.A package does not have to consist of an application, such as Microsoft Word,but can simply be a collection of files, several registry changes, printer driverupdates, or specific desktop configuration changes that must be delivered to adistributed group of workstations.The PB contains an extensive scripting language that can be manipulatedmanually. These commands can be inserted into a snapshot packageconfiguration file, after the PB wizard iscomplete, or by opening the PB itself,without the wizard, and creating a newpackage configuration script.When a package is built, the .CFG scriptfile, the installation engine and all filesidentified by the Package Builder Wizard are compressed and wrapped into onestand-alone .EXE file. This file can be executed locally on a machine as any.EXE file can, or it can be scheduled to multiple workstations using the Schedulerin LANDesk® Management Suite.PACKAGE BUILDER COMMANDS AND OPTIONSThe Package Builder commands are grouped into the following categories:Building Successful Packages - 6 - v1.0

• Base Installation• Appearance• Messages & Input• System Changes• IF Conditions• Defaults & CallsEach category has several functionscommands that can be chosen as parta package.orofBase installationTitleFirstScreenDirectoryFileWinItemLastScreenUnInstallVersionInfoThis command displays the title which appears in the top left corner of thescreen during installation. The .CFG file can have two Title commands:one for the title and one for a subtitleThis command displays a personalized screen of text at the beginning ofthe installation process.The DefaultDir command is used to specify a default disk drive anddirectory for use during the installation.Use this command to tell the installation program which file(s) to copyfrom the installation diskette(s). Also use it to identify which directory thefiles should be copied to or copied fromThis command specifies a program group that adds the program to theStart | Programs menu in Windows.This command displays a personalized screen of text at the end of theinstallation process.This command specifies whether an uninstall program is to be created.This command defines the version information that will be associated withthis package and that can be viewed in Windows Explorer by right-clickingProperties.AppearanceAnimationIntroScreenIntroSoundScreenColorScreenGraphicThis command displays a series of bitmap files sequentially so that theyproduce an animation effect.This command displays a graphic (bipmap image) as the first step in theinstallation.This command plays a sound file (.WAV) as the first step in theinstallation.This command sets the background screen color.his command sets the background graphic to display during installation.Messages & inputsAskUse these commands to generate a prompt to the user and assign theuser's response to a variable.Building Successful Packages - 7 - v1.0

GroupInsertDiskPopMessagePromptsSetVariableShowReadmeThis set of commands allows you to provide the user with options (that is,a selection over which files are to be installed). This command set bothdefines the file groups and displays a message window giving the user aselection.This command is used only if you arrange you own diskettes. Do not usethis command if you use the Make Diskettes option in the Build menu tobuild the diskettes automatically.This command displays a test billboard during file copy.This command allows you to change the value of the default prompts.Click on any of the following prompts for a description of that prompt.This command creates a custom variable name and assigns a stringvalue to it.This command displays a text file at the conclusion of the installation.System changes·AddTextAutoexecBackupConfigCopyDeleteIniFileNTServiceRebootRegistryRegserverRenameShortcutWinGroupThis command modifies a text fileUse this command to specify changes to the user's AUTOEXEC.BAT file.This command creates a Backup subdirectory under the main installationdirectory ($DEFAULTDIR$), and makes a copy of any file that is to beoverwritten during installation. All overwritten files (in the same or differentdirectories) are copied into the Backup directory.Use this command to specify changes to the user's CONFIG.SYS file.This command copies a file (or files) from one location to anotherThis command deletes a file or files from a user’s systemThis command is used to modify any type of .INI file on the end user’ssystem.This command stops or starts a Windows NT service on a Windows NT orWindows 2000 computer.This command restarts the end-user’s system after the installation.This command makes modifications to the file registry found in theWindows operating systems.This command registers a self-registering .OXC or .DLL file.This command renames a file on the end-user’s system or on theinstallation diskettes.This command creates a shortcut on the end-user’s systemThis command displays the current available Windows groups and allowsthe user to select from the list or create a new group by typing in a name.Building Successful Packages - 8 - v1.0

If conditionsIf $ASKn$If $SYSn$If $variable$If CPU()If DiskSpace()If FileVer()If FindModem()If CDROM()If GroupIf IsFile()If Locate()If MemoryIf SearchIfSearch(Registry)If SoundCard()If Video()If OSVer()ElseEndIfExitMessageThe $ASKn$ variable is assigned the value of whatever the user hastyped in response to an ASK command.The $SYSTEM$, $SYS2$, and $SYS3$ are assigned the values ofwhatever the user types on the command line when running theinstallation program.The SetVariable command assigns the value to $variable$This command detects the user's system and allows the installation toperform differently based on the type of CPU the user has.This command detects the available free space on the specified drive,and allows the installation to perform differently based on the availablespace.This command checks the timestamp or internal version number of aspecific file.This command checks for the existence of a modem on one of the serialports on the user's system.This command determines whether a CDROM drive is installed on theend-user’s systemhe Group command sets up groups that a user can select from.The If IsFile("[path]filename") command checks for the existence of a filewithin a specific directory on the user's system.The If Locate("filename", drive/dir) command searches the user’s systemfor a specific file. It will search all directories on some or all drives.This command checks the RAM of the computer.This command searches a text file for a specified text string.This command searches the registry for a specified key and name andthen stores the string value in specified variables.This command checks for the existence of a sound card on one of theserial ports on the user's system.This command allows you to create an IF condition based on three valuesof the computer’s video display capabilityThis command allows you to create an IF condition based on the enduser’s operating system.This command creates an “else” condition within an IF statementThis command is required to mark the end of an IF statement.This command enables you to terminate the installation based on theevaluation of an IF statement.Defaults & CallsBlankLineFontNameOverWriteFileProgressBarThis command adds a blank line to the script. It has no effect onexecution.This command is useful for international users because the default font(MS Sans Serif) does not display some international character sets suchas Chinese and Japanese.This command determines the default behavior for installing files thatalready exist on the user’s systemThis command is used only if you choose to manually build diskettes.Most people specify files to be installed, and let Package Builder collectfiles, compress them, and build installation. In this case, you do not needBuilding Successful Packages - 9 - v1.0

RemRunAtStartRunAtMiddleRunAtExitthis command in your .CFG fileThis command adds a remark to the .CFG file.This command runs an executable before the installation starts.This command runs an executable during the installation.This command runs an executable at the end of the installation.SCRIPT ORDER OF EXECUTIONWhen the package is executed on the target workstation, the package script fileis not executed in a top-down manner as one may expect.Builder stores a version of the configuration file script (.cfg) inside the monolithicexecutable. This configuration script is used to determine what happens duringthe installation.The installation engine (INST32.EXE) does not execute all of the commands inthe script in order. The purpose of this document is to explain why commandsare not executed in order, and the order of execution of commands.Reasons for Script ReorderingScript commands that produce user interface are at the heart of script reordering.Consider a script that installs a large number of files, and then user interface thatallows the user to choose which set of remaining files should be installed. Thiscauses two problems. The lesser problem is that the user must watch the entireinstallation in order to complete all dialogs. The greater problem is that if theuser selected the “Back” button, the large set of files must be uninstalled.The solution is to execute all user interface commands, and to execute “IF”statements that are based on the output of those interface commands beforeexecuting other commands like file and registry commands. If the “IF”statements return FALSE, the commands they enclose will be marked such thatthey will not be executed.Script Order DetailsThe installation engine makes multiple passes of the script; each time it attemptsto execute specific types of commands. The individual passes through the scriptare as follows:1. The following commands are processed:MINCPUTYPEANIMATIONPROMPTSBuilding Successful Packages - 10 - v1.0

FONTNAMESETRUNATSTART2. Static “IF” statements are executed. If the statement returns false, allcommands within the “IF” block (except those in the “ELSE” block) aremarked as non-executing. The static “IF” statements include:IF WINVER()IF DOSVER()IF ISFILE()IF MEMORY()IF CPU()IF VIDEO()IF SEARCH()IF SEARCH(Registry)IF SOUNDCARD()IF FINDMODEM()IF FILEVER()IF CDROM()3. Dynamic “IF” statements and user interface statements are executed, andthe “IF” blocks marked for non-execution depending on the result of the“IF” execution. The dynamic “IF” statements include:IF GROUPIF $ASKN$IF DISKSPACE()IF LOCATE()IF $4. File commands are processed in the order they occur in the script. Othercommands, like registry commands, are still not executed at this timeregardless of the order in the configuration file. The file commands arethen flagged so they will not be run again at a later stage. File commandsinclude:FILEINSERTDISKCOPYDELETERUNATMIDDLE5. All remaining commands, including registry, .ini file commands, andRUNATEXIT, are executed in the order they occur in the script.Building Successful Packages - 11 - v1.0

This order of execution limits conditional blocks from performing any tests onchanges that occur during the installation of the package. They exist solely tocheck the state of the machine before any installation occurs.COMMON ISSUESRegistry SettingsIf changes have been made to the HKEY_CURRENT_USER registry key in apackage, the installer detects whether someone is logged in and applies changesto that user’s registry and that user’s “documents and settings” directories.Also, the Package Builder Wizard offers a “build options” button. This dialogallows the administrator to configure how registry changes made toKEY_CURRENT_USER and file changes made to the current user’s “documentsand settings” directory (like the desktop, program files shortcuts, etc.) will beinterpreted upon install. The changes, when applied to target machines, can beassociated with either:1. Only the logged-in user2. All users profiles found in the registryDangerous Registry EntriesSometimes the Package Builder Wizard captures changes that can causecorruption of the system when deployed. These changes are typically registrysettings in the CurrentControlSet and Hardware subdirectories. Rather thanignore these changes, we wrap the registry calls in an “IF” statement like this:IF $DANGEROUS$ = "TRUE"BEGINREGISTRYKEY:new,"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk"VALUE:reg_dword,replace,"type","1"ENDREGISTRYENDIFThe user then has the choice of:1. Using the package without modification2. Defining the environment variable “$DANGEROUS$” equal to TRUE – thiswill allow the changes to be made on each machine with this variable set3. Editing the script to selectively delete “IF $DANGEROUS$” statementsBuild vs Rebuild All – Which Should I Choose?Adding files to a package is done in two main steps. In the first step, eachreferenced file is compressed into the working\temp directory to the namespecified in the .CFG script. The second step looks for files in the temp directoryBuilding Successful Packages - 12 - v1.0

and appends them to the package.The “Build” command will only update files in the temp directory that were notpreviously there.“Rebuild all” deletes all of the compressed files in the temp directory. Whenediting a monolithic exe, there is no difference between build and rebuild all forany files that still have the “name=” parameter specified in the .CFG file becausethey will be moved over directly from the previous instance of the package,unchanged.File replacement logicWhen rebuilding a monolithic .EXE, the builder will reuse all of the files put insidethe original package that are still referenced in the .CFG script. In order to triggerthe builder to grab existing files from your system instead of using the files in theprevious instance of the package, you must update the .CFG line that refers tothe file by manually removing the “name=” parameter. This will cause the builderto retrieve the file from your system each time. By default, the “name=”parameter is not included on the FILE: line of a script.Healing vs Reinstalling – Which is Best?Since version 6.5, when building a script to distribute a package, a “heal” or“repair” option is available. This feature is activated in a number of ways.o If a package is installed a second time and UI is disabled, then thepackage automatically goes into heal mode.o If a package is installed a second time and the /Ah+ parameter isprovided, then it goes into heal mode.o If a package is installed a second time and UI is enabled, the user will beprompted whether to heal the package or reinstall. If the user choosesheal, then the package goes into heal mode.RunAtExitTo perform complex operations in a package, it may be desirable to nestfunctionality in a child package that is launched by the parent package. This canbe done by typing either “~0000.exe” or “inst32.exe” followed by the desired childpackage name (which could be in the temp directory if flagged with the “temp”attribute in the parent’s CFG file). Path information is not important because theinstaller looks for either of these strings and automatically spawns another copyof itself with the specified package name.The advantage of running child packages by using inst32 instead of typing thepackage name is that another copy of inst32.exe, header32.exe, andenuinst32.dll need not be downloaded to the target computer (into the tempBuilding Successful Packages - 13 - v1.0

directory) before running the package. The disadvantage of using inst32 is thatthe child package’s temp.shr will NOT be processed.The installer attempts to block itself from being run multiple times simultaneously,but it only checks for this occurrence inside of header32 and aiclient. Runninginst32.exe directly from within a parent package will allow two packages to runsimultaneously.NOTE: Although this scenario will likely work quite well, it is not supported. Anyproblems you run into are yours to solve. As a result, we do not officially supportRunAtMiddle and RunAtStart commands that refer to other installer packages.Also, unless the child package has been flagged with the “temp” attribute, it willnot have been extracted from the parent package by the time the run commandis processed.Building Successful Packages - 14 - v1.0