CA Client Automation - 14.0

PDF
English

Non-TOC Topics

Contents
cla140
Contents
Register Product Version
When you register a product version, all files and subdirectories from the version directory of the product archive are transferred to the Software Package Library on the manager system, and the product is made available for distribution to target computers. To register the product, you must have the appropriate permission set on the manager system.
Follow these steps:
  1. Do one of the following in the product archive window:
    • Right-click the desired version in the left pane, and select Register Product from the shortcut menu.
    • Select the desired version in the left pane, and click the Register Version icon SXP Packager GUI icon for Register product version on the toolbar.
    • Select the desired version in the left pane, and choose Tools, Register Product from the Packager main menu.
    The Register a Version of a Product dialog opens. In the dialog the name and version number of the product are displayed.
  2. Enter the name of the manager system that contains the Software Package Library you want to register the product version in and your user credentials (user name, security provider, authority/domain, password),
    Click the double arrowhead button SXP Packager GUI icon for Hide information to hide, and SXP Packager GUI icon for Show information to display the User, Security Provider, Authority/Domain, and Password fields.
  3. Click Register.
Options
On the Options dialog you can choose one or more of the following options:
Select the appropriate check box to choose the option.
Clear the check box to deselect the option.
Enable Trace option
For diagnostic purposes, you can optionally record the activities of the Packager in a trace file, called trace.txt, on the Packaging Computer. The trace file is available in the trace subdirectory of the Packager installation directory. If necessary, the Packager creates backup files called trace.ba0, trace.ba1, and so on. The trace.txt file always contains the recent information.
Enable Autostart option
If the Autostart option is selected in the Options dialog, the Packager starts automatically after each system start.
Enable Reset Reference System option
During the packaging process, the product installation on the reference system of the Packaging Computer is recorded. After package creation has completed, the reference system is by default reset to its original state.
In the Tools, Options menu of the Packager main menu, you have the option to enable or disable resetting the reference system. By default, this option, called Enable Reset Reference System, is selected.
If the Enable Reset Reference System option is not selected (reset is disabled), all products that are installed on the reference system during package creation will remain there and are cumulated.
Disabling the reference system reset on the Packaging Computer can be of use when the Packager is installed on a virtual machine. In this case the reference system can be reset quickly by using a virtual snapshot.
When reset is disabled, the Packager needs no backup files of the reference system. Consequently, all backup-related tasks and GUI items, for example, the Backup files tab in the Configure Reference System dialog, are removed from the Packager's user interface.
Tools
Align Product Version
Opens the Align Product Version dialog.
Check Parameters
Scans the archive files of the selected SXP product version
Check Properties
Checks the selected MSI product for undefined properties. If at least one undefined property is found, an MSI property editor is started to set or change properties.
Convert into MSI
Initiates the conversion of an SXP product_product into the Microsoft Installer (MSI) format. The converted product is called MSI product, and is stored in the product archive with the same version number as the SXP product, expanded by .msi.
Register Product
Opens the Register Product Version dialog.
Options ,,,
Opens the Options dialog.
Congratulations after SXP Package Creation
After successful creation of an SXP package you have the option to register the SXP package in the Software Package Library.
Alternatively, you can first convert the SXP package into the MSI packaging format (for the Microsoft Installer) and then register the converted MSI product in the Software Package Library.
List of File System Changes
When using the automatic method (Custom mode), the List of File System Changes dialog appears after the Using the Software dialog processes are completed.
All files created or modified, and all directories created by the automatic method display in the list box. On one tab you can find all common files and directories, on the other tab all user-specific files and directories. User-specific files and directories are all files and directories under the home directory of a user or user profile. A digit in a green box, located next to the directory name indicates root directories. The digit refers to the number of the root directory.
A root directory is specified within the SXP archive files by the internal SxpRootDir
n
 parameter, where
n
 is the number of a root directory. For details, see info.sxp.
You can choose between viewing only directories, only files, or both, by activating the appropriate button. The same way, you can sort the list entries by directory, by type, or by items to be packaged.
File Options
You can assign options to each file, using the appropriate check boxes on the right-most side. These options are:
  • Icon for the file option Install file only if not existent Install file only when file does not exist (for user-specific files only)
    This option protects user-specific files against overwriting by newly installed software.
    For example, if a user has already created his or her own dictionary for office applications and a more recent office application is to be installed, this option ensures that the user’s dictionary file is not overwritten by the application's default dictionary.
  • Icon for the file option No file removal during uninstall Do not remove file during uninstallation (for user-specific files only)
    This option helps the user to keep a user-specific file (for example, dictionary as described under Icon for the file option Install file only if not existent ) on the target computer, even if the application to which it belongs is uninstalled.
    You can use Packager filters to assign the same option (1.0, ±1, or both) to all files in a group, that is, files with the same extension in the same directory (Product files filters tab on the Configure Reference System dialog.)
Delete Options for Directories
You can assign delete options to each directory, by checking a combination of the appropriate check boxes on the right-most side. The following table lists the applicable combinations:
Checked Options
Meaning
Delete option 1 for a directory of an SXP product Delete option 2 for a directory of an SXP product Delete option 3 for a directory of an SXP product
The directory is fully deleted, including any files, subdirectories, and files created by the user following installation.
Select this combination only if you are certain that other applications have not stored files at this location.
Delete option 1 for a directory of an SXP product Delete option 2 for a directory of an SXP product
The directory and subdirectories are deleted if they do not contain any files (default for root directories).
Delete option 1 for a directory of an SXP product
The directory is deleted if it is empty (default for subdirectories of root directories).
None
The directory is not deleted.
Each multi-use directory and all of its higher-level directories must have none of the boxes checked (directory is not deleted). (A multi-use directory is used by two or more applications.)
The information on directories specified on this dialog is recorded in the dirs.sxp or udirs.sxp (user-specific) archive files.
The information on files specified on this dialog is recorded in the archive files files.sxp and ufiles.sxp (user-specific), and in the compressed archive files files.cmp and ufiles.cmp (user-specific).
Finish
When you are finished with all options on the List of File System Changes dialog, click Continue.
Reference Counter-dependent Uninstallation
The reference counter-dependent uninstallation option controls the multiple use of a file. When you apply this file option, a counter (reference counter) on the target computer is updated upon file installation and removal. If it does not already exist, the reference counter is created. The counter is incremented by 1 each time the file is installed and decremented by 1 each time the file is removed. The Installer deletes this file (and the reference counter) only, if the counter resets to zero during uninstallation.
For example, if a DLL file such as vbxxx.dll is part of an application program, this DLL file is installed for the first time when you install the application program. If you install any other application program that contains the same DLL file (vbxxx.dll), the reference counter for the file is incremented. When you remove any of the application programs that use the same DLL file, the reference counter is decremented. Normally, the file is deleted, however, when using the reference counter option, the file is retained to ensure that the other application programs that need vbxxx.dll are able to run.
The reference counter-dependent uninstallation file option is effective only, if it is specified for all products on the target computer that use this file. We recommend that you apply this option .
To choose the reference counter-dependent uninstallation option, select the appropriate file path name on the Product Files Filter tab of the Configure Reference System dialog and click the reference counter-dependency button.
Apply the reference counter-dependent uninstallation option only for files that are used by several application programs and only when absolutely necessary! Unnecessary counters increase the registry size and slow down installation. Moreover, this file option is effective only, if it is applied to all products installed on the target computer that contain this file.
Version-Dependent Installation
The version-dependent file installation option ensures that a previously installed version of a file on the target computer is overwritten only, if it is older than the file to be installed. For this mechanism to work the file must have a version ID assigned. The Installer checks the internal version ID of the file during installation of the product on the target computer.
All product files with an internal version ID are automatically assigned the version-dependent installation option. All .dll and .exe files generally have a version ID.
To specify the version-dependent installation option, select the appropriate file path name on the Product Files Filter tab of the Configure Reference System dialog and click the version-dependency button.
Information about the Product
On the Product tab you provide product information for the selected product version. This information is stored in the Product section of the Info.sxp archive file.
  • Optional descriptive name
    Indicates Name and Version of the product. Name is the product name and description, maximum 47 characters. Version is the product version (the original manufacturer's product version, informal).
  • Product type
    Specifies the type of the product:
    • Complete
       -- Indicates a full product.
    • Delta
       -- Indicates a delta version for an already installed product.
  • Target operating systems
    Specifies the target operating systems on which the product can be installed.
    The left list box shows all available operating systems SXP products can be delivered to and installed on.
    The right list box shows the operating systems, for which the SXP product is currently allowed. You can move entries from the left to the right box, and conversely, using the double-arrowhead buttons.
    If you check the 64 bit only check box, all 32-bit operating systems are removed from both list boxes. When you uncheck the check box again, all 32-bit operating systems are added to the Available OS box only.
    When the Allow future OS check box is checked, the SXP product can also be installed on future versions of the operating system family without modifications.
  • Product based behavior on the target system
    Describes the behavior of the Installer on the target computer during installation and removal of the SXP product and in the case the installation fails.
    Installation Bootlevel and Deinstallation Bootlevel:
    Boot Level
    Action
    Comment
    0
    Target driven
    If circumstances during installation or removal of the product on the target computer require a reboot (for example, when a file to be replaced is locked on the target computer), the Installer initiates this reboot.Default, when the Packaging Computer has not been rebooted during the reference installation.
    1
    Logoff required
    Requires a user to log off and on to activate changes to the Windows desktop and registry.
    3
    Restart after batch
    Automatically initiates a system reboot at the end of the transaction.Default, when the Packaging Computer has been rebooted during the reference installation.
    4
    Restart after job
    Initiates a system reboot immediately after the end of the installation or removal of the product.
    For boot levels 1 and 3 the following applies: In a transaction with several installation and uninstallation jobs, the uninstallation jobs are executed first. The highest deinstallation boot level that occurs is recorded and the necessary system boot is performed at the end of all uninstallation jobs. If no deinstallation boot level exists, the installation boot level is used. Then the same procedure is applied to all installation jobs (using the highest installation boot level).
    The boot level 2 no longer applies with this Packager version. If an older package that contains the boot level 2 entry is being edited, the boot level is internally set to "1—Logoff required".
    Resetlevel:
    Defines the action to perform if the installation of the SXP product fails. 
    If this parameter is assigned, it overwrites the reset level pre-configured for the Installer. Products that use the reset level must be generated with the automatic method of packaging.
    By default, the reset level is not set and no ResetLevel entry exists in the Product section of the info.sxp archive file. In this case, the settings on the target computer define the reset behavior (target driven). If you want to overwrite this standard setting on the target computer, you must enter a reset level manually in the Product section of the info.sxp or use the info.sxp editor (double-click the info.sxp icon on the Packager main window) and set the reset level on the Product tab.
    The following table lists the permitted reset levels:
Reset Level
Action
Comment
No entry in info.sxp
Target driven - recommended
The settings on the target computer define the reset behavior.
0
No rollback
No reset.
1
Limited rollback
Specifies a limited reset. The product is uninstalled, but previously existing files on the target computer that were deleted or modified by the installation are not restored.
Exception: Even if an installation fails and reset level 1 is invoked, an INI or ASCII file that was modified through an ini
nnnn
.sxp or asc
nnnn
.sxp archive file is always reset to its original content.
The following changes are not canceled by reset level 1:
Files specified in files.sxp in the InsDelFiles section remain deleted.
If an installation fails in some way and a reset is invoked, the files specified in the FilesInArchives section of the files.sxp archive file are not restored, if these files previously existed on the target computer from an earlier version. Examples include DLL files in the system directory.
Consequently, some files of the new version of the product remain on the target computer.
2
Complete rollback
Specifies a complete reset. Reset level 2 is more extensive than reset level 1. Previously existing files on the target computer that were deleted by the installation are restored.
Configuring the Packaging Process
When you use the automatic method (Custom mode) of packaging, a list of files that will be included in the new product archive is generated after the reference installation is completed.
For each of these files, you can define install and delete options on the List of File System Changes dialog. To simplify this process, you can preconfigure file filters. To configure these file filters, select File, Configure Reference System, Product files filter.
You can specify two options simultaneously:
The preconfigured filter mechanism works only, if the options have been specified for the file in every product on the target computer that contains the file. That is, all products installed on the target computer must have been created with the options.
To reset the default setting for the preconfigured filters, select the Product files filter box on the Defaults tab of the Configure Reference System dialog.
Locale Section of an SXP Archive File
To support different character sets, each archive file contains the Locale section. The Locale section indicates the code page the archive file is written in.
This section must not be changed and therefore is not displayed by the archive file editor.
The Locale section is generated automatically with the Codepage value being set to 3, which indicates UTF-8 format. The SrcCodepage entry is currently created only in context of INI files in UNICODE format, when the Packager records changes of such a file. The Installer also creates and executes the INI files as UNICODE files.
The structure of the Locale section is as follows:
#Locale#
mandatory
Codepage=
Code_page
 
SrcCodepage=
Code_page_source
optional
  • Codepage
    Indicates the code page used to write the archive file. Currently the value is set to 3, indicating UTF-8 format.
  • SrcCodepage
    (Used only for INI files in UNICODE format)
    Indicates the code page of the source file. Currently the value is set to 0, indicating UNICODE format.
Edit Archive Files
Edit the current archive file in this area.
Structure and syntax details of the current archive file and its sections are described under Archive Files Overview.
When you click the close button in the upper right corner, you are asked if you want to save the changes you made.
ASCII files
If partial changes are made to existing ASCII files on the Packaging Computer during product packaging, only these partial changes are reproduced in the ASCII file of the same name when the product is installed on the target computer.
The ASCII files tab on the Configure Reference System dialog specifies the ASCII files to be monitored for modification. The Packager finds the changes and records them in an asc
nnnn
.sxp archive file.
Backup files
The Backup files tab on the Configure Reference System dialog specifies all file system areas or path names to store in special backup archives. As a result, you are able to restore the original reference system as soon as a product has been packaged.
Set the recursive option, if you want to include in the backup all of the subdirectories of the path names you specify.
If you make changes on this tab and then click Apply or OK, the Backup System Files dialog appears. The modifications you specified are automatically entered in the backup archive.
If you do not protect a file or path by specifying it on the Backup files tab, the file or path can be changed or deleted permanently by the reference installation!
You should very precisely define the areas to be backed up, and include only essential areas; otherwise, the size of the archives increases considerably, thereby increasing the time required to perform the backup and restore operations.
Files specified under the ASCII files tab do not need to be entered here. The Packager backs them up and restores them automatically.
The files are backed up only once when using the Packager for the first time, or on demand by selecting File, Backup System Files.
Reference System Defaults
The reference system is preset with default values when the Packager is installed, but might have been reconfigured as you work with it. To revert to the default factory settings for the reference system, use the Defaults tab on the Configure Reference System dialog. You can restore defaults for all tabs or for selected tabs by checking the appropriate check box.
Expandable Registry Values
The Expandable Registry Values tab on the Configure Reference System dialog specifies the registry values to expand during reference installations.
Some registry values are predefined by the reference system. For example:
[HKEY_LOCAL_MACHINE]\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path
The values displayed in the first box of the Expandable Registry values tab must be defined on the Keys to scan tab. Values specified in this tab must be in the range defined by the Keys to scan tab and Keys to exclude tab.
In contrast to the Keys to scan tab, however, you can use the Expandable Registry values tab to treat registry values differently, with regard to expanding and overwriting.
You can enter values of the following types only:
    • REG_SZ (string)
    • REG_EXPAND_SZ (expand string)
    • REG_MULTI_SZ.
If the registry values you specify on the Expandable Registry Values tab are expanded during a reference installation, the Packager will record whether the original registry value was appended or prefixed.
Keys to Exclude
The Keys to exclude tab on the Configure Reference System dialog specifies the registry areas that should not be checked for changes when the product is being packaged.
If you specify a key on the Keys to exclude tab, changes made to the key during the reference installation will not be recorded!
The registry areas to exclude are dynamic areas, modified by Windows at runtime. Unless the keys for these registry areas are excluded from the packaging process, this dynamic modification may corrupt the reference installation. By default, these registry keys are excluded from the packaging process, through the Keys to exclude tab.
The default settings preclude the need to enter any keys on this dialog. You can exclude additional keys, for example, keys belonging to products not installed by the Packager, or products that can be installed in the future. A working knowledge of the registry is necessary to exclude the proper keys for these purposes.
To browse the registry to select a registry key to exclude, select the root from the Root field, then click the browse button (...) next to the Key field.
All keys and values under the selected Key to exclude are excluded from the check, if you select the Recursively option.
Areas that are pre-defined by default cannot be changed; therefore, the folder is unavailable (grayed out).
Keys to scan
The Keys to scan tab on the Configure Reference System dialog specifies the registry keys to scan. During the reference installation of a product, the Packager checks for changes, and records changes in the registry of those areas specified on the Keys to scan tab.
If you do not specify a key on the Keys to scan tab, then changes made to the key during the reference installation will not be recorded, and, therefore, the key will not be reset to its original state after the reference installation is completed.
A key entry is interpreted recursively, which means, the Packager checks for changes below the specified key.
Specifying default keys on the Keys to scan tab is sufficient for most products.
The Packager detects:
  • New keys
  • New values
  • Modified values
  • Deleted keys
  • Deleted values
Use the two preset main keys only. You do not need to specify other keys, because all other keys are sub keys of these two keys.
Paths to exclude
The Paths to exclude tab on the Configure Reference System dialog specifies paths that should not be checked for changes during the reference installation of a product. Dimmed folders indicate paths that cannot be changed. Yellow folders contain either defaults or values you have set that can be changed.
Specify the path name. Optionally specify a file mask to indicate which files to exclude.
Set the Recursive option to exclude all subdirectories of specified paths, if so desired.
Add or remove special folders from the list using the Special Folder dialog.
Paths to scan
During a reference installation, the Packager records the following files and directories:
  • Files and directories added when the product is installed
  • Files and directories deleted when the product is installed
  • Files modified when the product is installed, based on size and date
During the packaging process, the Packager checks only those areas that are specified on the Paths to scan tab of the Configure Reference System dialog for changes, when you use the automatic method of packaging. On the Paths to scan tab, you can specify an entire drive or a specific path. If you specify a path, only that path is checked. A path name is interpreted recursively, meaning that the Packager checks for changes in the specified path and all of its subdirectories. For example, if you specify c:, the entire c: drive is checked. If you specify c:\winnt, the c:\winnt directory and all of its subdirectories are checked. User-specific data entries show a face on the icon.
To add any other directory to the path list, use the Browse button (...) or enter the directory name directly into the Path field. Note that removing a folder from the path list does not affect the Paths to exclude tab.
The Special Folder dialog lets you add or remove special folders from the path list. Removing a special folder from the path list automatically adds it to the list of available folders. Adding a special folder to the path list removes the folder from the list of available folders.
In general, additional and modified files and directories are copied completely to the product. The exception is ASCII files. For each ASCII file, you can specify that only the changes to the file are recorded. By default, changes to any file with a .ini extension are always recorded in this way.
Files and directories marked for deletion are deleted on the target computer when the product is installed.
If existing files or directories are deleted or modified on the Packaging Computer's reference system while the product is being installed, they can be restored only in the following cases.
  • If the files and directories are removed during reference installation at the time scheduled for software installation
  • If the files or directories were specified on the Backup files tab, and therefore were backed up
If you do not specify a path on the Paths to scan tab, then changes made to the path during the reference installation are not recorded, and the path is not reset to its original state after the reference installation has completed.
Product Files Filter
The Product Files Filter tab on the Configure Reference System dialog lets you manage file options, version-dependent install, reference counter-dependent uninstall, or both, for all files in a group, that is, for all files with the same file extension in a directory.
Select a product file mask, click Edit, and check the desired file option button. Click Change to change the file option assignment in the displayed file list.
To remove selected product files from the displayed file list, select a product file mask and click Remove.
Actions.sxp Archive File
The actions.sxp archive file specifies pre-programs and post-programs for the installation and uninstallation of the product on the target computer. All pre-programs and post-programs are optional. If used, the actions.sxp archive file must be created manually
The file contains the following sections:
  • Specifies the pre-programs for the installation.
  • Specifies the programs that are executed if the installation is faulty. These programs cancel the changes made by the pre-programs.
  • Specifies the post-programs for the installation.
  • Specifies the programs that are executed if the uninstallation is faulty. These programs cancel the changes made by the post-programs.
  • Specifies the pre-programs for the uninstallation.
  • Enables post-programs to be called during uninstallation.
  • Replaces parameters for all files listed in this section.
 Both 64-bit and 32-bit programs can be launched from the actions.sxp archive file.
The structure of the actions.sxp archive file is described in Structure of the Actions.sxp File.
Structure of the Actions.sxp File
The structure of the actions.sxp archive file is as follows:
 
#InsPreActions#
optional
 
#InsPreErrActions#
optional
 
#InsPostActions#
optional
 
#InsPostErrActions#
optional
 
#DeiPreActions#
optional
 
#DeiPostActions#
optional
 
#ReplaceParams#
optional
 
InsPreActions, InsPostActions, DeiPreActions, and DeiPostActions Sections of Actions.sxp
Program_call_1
[,
return_code
[,
timeout
]]
optional
:
 
Program_call_m
[,
return_code
[,
timeout
]]
optional
All programs listed in the sections must be available at the time of execution!
  • Program_call
    Specifies the program path with parameters. This program call is executed in the phase of the section from which it is called. Only *.exe, *.com, and *.bat files can be called. The sequence of calls is 1-m.
    Always specify the full path name and file extension of the program to be called. Since the path may contain Blanks (spaces), enclose it in quotation marks!
    If the program call is created using the internal $(SxpSrvRelDir) parameter, the path in the DeiPreActions and DeiPostActions sections must not contain Blanks (spaces).
    If the executed program asynchronously starts other programs and termniates, these spawned programs are not monitored.
  • return_code
    Specifies the return value, if the program runs successfully. This value is compared to the actual return value. A negative comparison causes an error in the process.
    If this value is not specified, the comparison cannot be made.
  • timeout
    Specifies the number of minutes that can elapse before the started program is terminated. If the program continues running past the timeout period, the Installer tries to stop the program, cancels the installation, and displays an appropriate error message.
InsPreErrActions and InsPostErrActions Sections of Actions.sxp
 
Program_call_1
[,
timeout
]
optional
:
 
Program_call_m
[,
timeout
]
optional
  • Program_call
    Specifies the program path with parameters. This program call is executed in the phase of the section from which it is called. Only *.exe, *.com, and *.bat files can be called. The sequence of calls is 1-m.
    Always specify the full path name and file extension of the program to be called. Since the path may contain Blanks (spaces), enclose it in quotation marks!
    If the program call is created using the internal $(SxpSrvRelDir) parameter, the path in the DeiPreActions and DeiPostActions sections must not contain Blanks (spaces).
    If the executed program asynchronously starts other programs and termniates, these spawned programs are not monitored.
  • timeout
    Specifies the number of minutes that can elapse before the started program is terminated. If the program continues running past the timeout period, the Installer tries to stop the program, cancels the installation, and displays an appropriate error message.
ReplaceParams Section of Actions.sxp
 
File_path_1
optional
:
 
File_path_m
optional
  • File_path
    Specifies the absolute file path.
Files listed in this section, which are located in the Software Package Library (that is, their path name starts with $(SxpSrvRelDir),) are copied to the local archive and then changed in the local archive.
Files that contain parameter and are compressed in the files.cmp archive, must be referred to in the ReplaceParams section of files.sxp.
Ascnnnn.sxp Archive File
This archive file contains information for modifying an ASCII file. It is essential that the ASCII file be specified when configuring the reference system. Remember that nnnn is the variable for an incremented number, and that each modified ASCII file is documented in a separate ascnnnn.sxp file, beginning with asc0001.sxp. File attributes are also recorded.
If you manually create an ascnnnn.sxp file or delete automatically created files, ensure that these files are numbered in continuous ascending order. If necessary, rename them to meet this requirement.
The ascnnnn.sxp archive file contains the following sections:
  • Specifies the file path of the ASCII files.
  • Specifies the lines to be inserted in the ASCII file specified in Info. It can be applied to the autoexec.bat and config.sys files only.
    This section is created by the automatic method, because the files autoexec.bat and config.sys are specified by default in the configuration of the reference system.
  • Specifies the scripts for modifying all other ASCII files that were specified when configuring the reference system.
For further information and an example see Structure of the Ascnnnn.sxp File and Example How to Use Ascnnnn.sxp.
Structure of the Ascnnnn.sxp File
The structure of the ascnnnnn.sxp archive file is as follows:
 
#Info#
optional
 
 
 
#InsLines#
optional
 
 
 
#ScriptFiles#
optional
 
 
 
Info Section of the Ascnnnn.sxp File
This section specifies the file path and attributes for the ASCII file, which is to be modified by means of this ascnnnn.sxp file.
The Info section can have the following entries:
Path=
File_path
Attributes=
Attribute_value
InsLines Section of the Ascnnnn.sxp File
The InsLines section is created automatically during the reference installation of a product.
The InsLines section can have the following entries:
Line_1
optional
:
 
Line_n
optional
  • Line
    Specifies the lines that are to be inserted in the ASCII file specified in the Info section of the ascnnnn.sxp archive file.
ScriptFiles Section of the Ascnnnn.sxp File
The Scripts section of the ascnnnn.sxp archive file describes scripts for modifying all other ASCII files (besides autoexec.bat and config.sys) that are specified when the reference system of the Packaging Computer was configured. For details about these specifications see the ASCII Files tab in the Configure Reference System dialog under File, Settings.
For a description of the Packager-specific scripting language see Packager Scripting Language.
For each ASCII file listed on the ASCII Files tab, the Packager creates the following:
  • An ascnnnn.sxp file.
  • A script ascnnnn.ins, for modifying the ASCII file during installation of the product.
  • A script ascnnnn.dei, for modifying the ASCII file during uninstallation of the product.
The Packager automatically enters the names of these scripts in the ScriptFiles section. In the ascnnnn.ins and ascnnnn.dei scripts, you can use parameters.
The ScriptFiles section can have the following entries:
 
Install=asc
nnnn
.ins
optional
:
 
Deinstall=asc
nnnn
.dei
optional
:
 
  • Install
    Specifies a script to be executed when the SXP product is installed on the target computer.
  • Deinstall
    Specifies a script to be executed when the SXP product is removed from the target computer.
Modifications to the ASCII files described in asc
nnnn
.ins and asc
nnnn
.dei must correspond precisely. For example, suppose you want to use an insert command to insert a line in an ASCII file after the installation of a packaged product and then use a delete command to delete the same line after uninstallation. The line to be deleted in ascnnnn.dei must be an exact match for the line that was inserted from ascnnnn.ins; otherwise, this line will not be deleted from the ASCII file when the product is uninstalled.
Paths and Parameters
You can create the ScriptFiles section manually, if necessary. You must specify the scripts with their absolute paths. You can use parameters in path specifications. Usually, the script is enclosed with the product, for example, in the version directory. When the script is enclosed with the product, you can specify the path using the internal $(SxpSrvRelDir) parameter.
You can use scripts to modify any ASCII files. The automatically generated scripts are very basic scripts that may need to be modified. Any recorded changes are appended to the ASCII file on the target computer.
    • When an uninstall routine is called, $(SxpSrvRelDir) is converted to the path name of the source of the installation files; however, these files are only available temporarily. Therefore, during installation of the product, the uninstall routine is copied to the target computer's $(SxpLocRelDir) and will be invoked later, during uninstallation of the product.
    • If you want to use additional files (such as related.dll or response files) that reside in the directory $(SxpSrvRelDir) or its subdirectories, then you must create a post-program batch file to copy these files to the directory $(SxpLocRelDir) or its appropriate subdirectories.
    • When the program is defined using the internal parameter $(SxpSrvRelDir), the path must not contain a blank.
Example How to Use Ascnnnn.sxp
This example illustrates how an ascnnnn.sxp file and its script files work together:
  • asc0001.sxp specifies the script files asc0001.ins and asc0001.dei.
  • asc0001.ins appends an IP address to the services file on the target computer after the installation of product XYZ.
  • asc0001.dei deletes that IP address after the uninstallation of product XYZ.
asc0001.sxp
#Sign#
ArchiveName=asc0001
Release=1000
SXP=1.0
#Info#
Path=$(SxpWinSysDir)\drivers\etc\services
Attributes=32
#ScriptFiles#
Install=$(SxpSrvRelDir)\asc0001.ins
Deinstall=$(SxpSrvRelDir)\asc0001.dei
asc0001.ins
delete line "$(trap)          162/udp    snmp"
append noblock "tec-trap-service   162/udp  "
append noblock "$(trap)         13333/udp    snmp"
The parameters to be used must already be known on the target computer. Therefore, the parameter product containing the definition of these parameters must be already distributed and installed on the target computer.
asc0001.dei
append noblock "$(trap)         162/udp    snmp"
delete line "tec-trap-service   162/udp  "
delete line "$(trap)         13333/udp    snmp"
The lines to be deleted must be specified (with respect to number of blanks, use of tabulators, and so on) exactly as in asc0001.ins, otherwise they will not be found.
Dirs.sxp Archive File
The dirs.sxp file specifies the directories to be created and removed during installation of the product on the target computer. It is generated automatically during the reference installation. Directory attributes are recorded. The dirs.sxp file contains the following sections:
  • Contains directories to be created during installation.
  • Contains directories to be deleted during installation. Installations performed using the automatic method make no entries in this section.
  • Contains directories and subdirectories to be deleted during installation. The automatic method enters directories that were deleted during the reference installation. Subdirectories are deleted automatically.
  • Specifies the directories to be created during uninstallation of the product. During the reference installation, the Packager fills in this section based on the uninstall options set.
  • Specifies the directories to be deleted during uninstallation of the product. During the reference installation, the Packager fills in this section and the flags based on the uninstall options set.
  • Specifies the directories and subdirectories to be deleted during uninstallation of the product. During the reference installation, the Packager fills in this section and the flags based on the uninstall options set.
  • Specifies attribute information for directories. During the reference installation, the Packager fills in this section, one entry for each directory created.
  • Specifies attribute information for directories to be set when the product is uninstalled.
For further information and an example see Structure of the Dirs.sxp Archive File and Example of Dirs.sxp Archive File.
Structure of the Dirs.sxp Archive File
The dirs.sxp archive file has the following structure:
 
#InsAddDirs#
optional
 
 
 
#InsDelDirs#
optional
 
 
 
#InsDelDirsWithSubs#
optional
 
 
 
#DeiAddDirs#
optional
 
 
 
#DeiDelDirs#
optional
 
 
 
#DeiDelDirsWithSubs#
optional
 
 
 
#InsSetDirAttr#
optional
 
 
 
#DeiSetDirAttr#
optional
 
 
 
The directory path in the file structure given above refers to the absolute directory path.
InsAddDirs Section of Dirs.sxp
The InsAddDirs section can have the following entries:
Directory_path_1
optional
:
 
Directory_path_m
optional
 
 
These directories are created during installation.
  • Directory_path
    Specifies the absolute directory path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory, must be used.
InsDelDirs Section of Dirs.sxp
The InsDelDirs section can have the following entries:
 
Flag_1,Directory_path_1
optional
:
 
Flag_m,Directory_path_m
optional
 
 
This section contains directories that are to be deleted during installation (depending on the flag). The automatic method makes no entry in the InsAddDirs section.
  • Flag
    Specifies the removal of a directory.
    • N
      The directory is deleted only if it does not contain any subdirectories or files.
    • D
      The directory and all its files are deleted only if the directory has no subdirectories.
  • Directory_path
    Specifies the absolute directory path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory, must be used.
InsDelDirsWithSubs Section of Dirs.sxp
The InsDelDirsWithSubs section can have the following entries:
 
Flag_1
,
Directory_path_1
optional
:
 
Flag_m
,
Directory_path_m
optional
 
 
The InsDelDirsWithSubs section specifies directories and subdirectories to be deleted during installation.
  • Flag
    Specifies the removal of a directory.
    Default: N
    • N
      The directory is deleted only if it does not contain any subdirectories or files.
    • D
      The directory and all its files are deleted only if the directory has no subdirectories.
  • Directory_path
    Specifies the absolute directory path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory, must be used.
DeiAddDirs Section of Dirs.sxp
The DeiAddDirs section can have the following entries:
 
Directory_path_1
optional
:
 
Directory_path_m
optional
 
 
The DeiAddDirs section specifies the path names of the directories to be created during uninstallation of the product. The Packager generates the assignment to this section based on the uninstall options set.
  • Directory_path
    Specifies the absolute directory path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory, must be used.
DeiDelDirs Section of Dirs.sxp
The DeiDelDirs section can have the following entries:
 
Flag_1,Directory_path_1
optional
:
 
Flag_m,Directory_path_m
optional
 
 
The DeiDelDirs section contains directories to be deleted during uninstallation of the product. The automatic method generates the assignment to this section based on the uninstall options set.
  • Flag
    Specifies the removal of a directory.
    Default: N
    • N
      The directory is deleted only if it does not contain any subdirectories or files.
    • D
      The directory and all its files are deleted only if the directory has no subdirectories.
  • Directory_path
    Specifies the absolute directory path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory, must be used.
DeiDelDirsWithSubs Section of Dirs.sxp
The DeiDelDirsWithSubs section can have the following entries:
 
Flag_1,Directory_path_1
optional
:
 
Flag_m,Directory_path_m
optional
 
 
The DeiDelDirsWithSubs section contains directories that are to be deleted along with their subdirectories during uninstallation of the product. During the reference installation, the Packager fills in this section and the flags, based on the uninstall options set.
  • Flag
    Specifies the removal of a directory.
    Default: N
    • N
      The directory is deleted only if it does not contain any subdirectories or files.
    • D
      The directory and all its files are deleted only if the directory has no subdirectories.
  • Directory_path
    Specifies the absolute directory path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory, must be used.
InsSetDirAttr Section of Dirs.sxp
The InsSetDirAttr section can have the following entries:
 
attribute_1
,
directory_path_1
optional
:
 
attribute_m
,
directory_path_m
optional
 
 
The InsSetDirAttr section contains file attribute information for directories, which is applied when the product is installed.
  • attribute
    Specifies the File attribute.
    During the reference installation, the Packager automatically records the attribute information for each directory created. Note that only the R (Read-only), H (Hidden), and S (System) file attributes are automatically recorded. For each directory, one entry is generated in the InsSetDirAttr section.
  • Directory_path
    Specifies the absolute directory path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory, must be used.
DeiSetDirAttr Section of Dirs.sxp
The DeiSetDirAttr section can have the following entries:
 
attribute_1
,
directory_path_1
optional
:
 
attribute_m
,
directory_path_m
optional
 
 
The DeiSetDirAttr section contains file attribute information for directories, which is applied when the product is uninstalled.
  • attribute
    Specifies the File attribute.
    During the reference installation, the Packager automatically records the attribute information for each directory created. Note that only the R (Read-only), H (Hidden), and S (System) file attributes are automatically recorded. For each directory, one entry is generated in the InsSetDirAttr section.
  • Directory_path
    Specifies the absolute directory path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory, must be used.
Example of a Dirs.sxp Archive File
Following is an example how directories can be specified for an SXP product:
#Sign#
ArchiveName=ie5
Release=1000
SXP=1.0
#InsAddDirs#
$(SxpRootDir1)
$(SxpRootDir1)\Microsoft Shared
$(SxpRootDir1)\Services
$(SxpRootDir1)\System
$(SxpRootDir2)
$(SxpRootDir2)\Connection Wizard
$(SxpRootDir2)\Setup
$(SxpRootDir2)\Uninstall Information
$(SxpWinProgDir)
#DeiDelDirs#
N,$(SxpRootDir2)\Uninstall Information
N,$(SxpRootDir2)\Setup
N,$(SxpRootDir2)\Connection Wizard
N,$(SxpRootDir1)\System
N,$(SxpRootDir1)\Services
N,$(SxpRootDir1)\Microsoft Shared
#DeiDelDirsWithSubs#
N,$(SxpRootDir2)
N,$(SxpRootDir1)
#InsSetDirAttr#
0x00000001,$(SxpRootDir1)
Files.sxp Archive File
The files.sxp file specifies information about the product files and a reference to the cmp archive file in which the files are stored in compressed format. It is generated automatically during the reference installation.
The files.sxp file contains the following sections:
  • Specifies the CMP (compressed) archive files. The reference installation automatically generates a files.cmp (all product files) and a ufiles.cmp (user-specific files) archive files.
  • Specifies the file paths of the files in the cmp archive files.
  • Specifies the files to be deleted during installation.
  • Specifies the files in the cmp archives in which parameters are used. You must enter the product files manually in this section. During the installation, the parameters in the files named above are replaced by their target computer-specific values.
    The parameters in the files entered here are replaced by the appropriate target computer values during installation. The file path must refer to the target file.
If you want to change properties of a file, like FAT attributes or installation options, edit the CMP file.
Structure of the Files.sxp File
The files.sxp archive file has the following structure:
#CmpArchives#
optional
 
 
 
#FilesInArchives#
optional
 
 
 
#InsDelFiles#
optional
 
 
 
#ReplaceParams#
optional
 
 
 
CmpArchives Section of Files.sxp
The CmpArchives section lists the CMP files (*.cmp)
.
The reference installation automatically generates a files.cmp (all product files) archive file.
The CmpArchives section can have the following entries:
Archive_file_name_1
optional
:
 
Archive_file_name_1
optional
 
 
  • Archive_file_name
    Specifies the name of the compressed archive file, which must be in the same directory as the product files.
FilesInArchives Section of Files.sxp
The FilesInArchives section can have the following entries:
File_path_1
optional
:
 
File_path_m
optional
 
 
Specifies the file paths of all files in the CMP File.
  • File_path
    Specifies the absolute file path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory must be used.
InsDelFiles Section of Files.sxp
The InsDelFiles section can have the following entries:
DFlag_1
,
File_path_1
optional
:
 
DFlag_m
,
File_path_m
optional
 
 
  • DFlag
    (Optional)
    Indicates if the file and its reference counter (if there is one) are deleted. If this DFlag is not set or does not exist, the file and its reference counter (if there is one) are deleted.
    • 0x00000000
      The file and its reference counter (if there is one) are deleted.
    • 0x00000010
      Reference counters are considered, that is, the reference counter for the file referenced by file path (if there is a reference counter) is decreased, and the file will only be deleted if the reference counter is 0 or does not exist.
      Default: 0x00000000
  • File_path
    Specifies the absolute path of the file to which the DFlag is applied.
ReplaceParams Section of Files.sxp
The ReplaceParams section can have the following entries:
File_path_1
optional
:
 
File_path_n
optional
 
 
  • File_path
    Specifies the file path of the configuration files in the CMP File in which parameters are used. During installation, the parameters in the files entered in this section are replaced by their target computer-specific values. The file path must refer to the target file.
    If a file uses a parameter, you must specify the path name to that file in the FilesInArchives section.
    For example, if the file named $(SxpRootDir1)\templates\file1.cnf uses a parameter, you must enter the following in the FilesInArchives section:
    $(SxpRootDir1)\templates\file1.cnf
ReplaceParamsUNICODE Section of Files.sxp
The ReplaceParamsUNICODE section can have the following entries:
File_path_1
optional
:
 
File_path_n
optional
 
 
  • File_path
    Specifies the file path of the UNICODE configuration files in the CMP File in which parameters are used. During installation, the parameters in the UNICODE files entered in this section are replaced by their target computer-specific values. The file path must refer to the target file.
    If a file uses a parameter, you must specify the path name to that file in the FilesInArchives section.
    For example, if the file named $(SxpRootDir1)\templates\file1.cnf uses a parameter, you must enter the following in the FilesInArchives section:
    $(SxpRootDir1)\templates\file1.cnf
Example of Files.sxp
Following is an example of a files.sxp archive file:
#Sign#
ArchiveName=40agent
Release=1000
SXP=1.0
#ReplaceParams#
$(SxpRootDir2)\SD\ASM\CONF\ASM.CNF
#CmpArchives#
files.cmp
#FilesInArchives#
$(SxpRootDir2)\BIN\Catocfge.exe
$(SxpRootDir2)\SD\ASM\CONF\ASM.CNF
$(SxpRootDir2)\SD\ASM\CONF\COMPATTR.CNF
Examples how to use Files.sxp
To parameterize an SXP product, you must edit both the product archive and the parameter archive.
Edit the Product Archive
If the product you are packaging contains any kind of configuration file, such as *.cnf, that you intend to parameterize, you must edit the files.sxp file after you install the product on the Packaging Computer. In this example, you edit the organization.cnf file in order to parameterize it and adapt it for use at your site.
  1. Start packaging the product and continue until you have installed the product as part of the packaging process. If you are using the automatic method, you should stop at the Installing a Version dialog, after you have installed the product, but before you click Continue.
  2. Edit the file (that is, organization.cnf) using a text editor such as Notepad.
    In the organization.cnf file, replace the keyword, Sales Department, with the parameter, $(Department).
  3. Finish the packaging process.
  4. Edit the files.sxp file: In the ReplaceParams section, add the path name of the modified configuration file, for example, $(SxpRootDir1)\organization.cnf.
    The Installer checks all listed product files for parameters.
    Alternatively, after packaging, you can use the CMP Editor to edit the packaged product, whose files are compressed in files.cmp. Using the CMP Editor is the only method to edit the files.cmp file.
Edit the Parameter Archive - General Steps
The following general steps ensure that the parameters you entered can be replaced by real values on the target computers:
  1. Create the desired client parameters, for example Department. The parameter names must match the parameter names used in the SXP package.
  2. Create groups and PCs. The PC names must match the names of the target computers. For instructions, see Modifying Default Parameters for Computer Groups and Individual Computerspar_gruppe.
  3. Define the default values for these parameters. If required, define the group-specific and PC-specific values also.
  4. Create a parameter product. To create a parameter product, select Edit, Parameter, create parameter product from the Client Parameters dialog. On the Create Parameter Product dialog, enter the name and version number you want to assign to the parameter product and click OK.
  5. Register the parameter product to the Software Package Library.
  6. Distribute the parameter product to the target computers.
Edit the Parameter Archive - Specific Steps for this Example
The following steps are the same as the general steps shown above, except that they have been modified for this example. Follow these steps to ensure that the parameters you entered can be replaced by real values on the target computers:
  1. In this example, the value human-resources is assigned to the Department parameter. Create the parameter Department with a default value. Add group icons called dep-h-resources and dep-financials.
  2. In these groups, create PC icons with the same names as the target computers. (These names must match the name entry in the Identity section of the SxpEngxx.ini file.)
  3. In the dep-h-resources group, change the value of Department to human-resources. In the dep-financials group, change the value of Department to financials.
  4. Create a parameter product.
  5. Register the parameter product.
  6. Distribute to the target computers.
During installation on the target computer, the Installer resolves the parameter Department in the organization.cnf file. For all target computers in the dep-h-resources group, the parameters are replaced with the value human-resources. For all target computers in the dep-financials group, the parameters are replaced with the value financials.
Organization.cnf File before Installation
The contents of organization.cnf file after installation follows. The contents vary according to the group to which the target computer was assigned:
Product file on the Target Computer Assigned to Department: $(Department)
(Files.sxp File:)
#Sign#
ArchiveName=ReplPar
Release=1000
SXP=1.0
#ReplaceParams#
$(SxpRootDir1)\Organization.cnf
#CmpArchives#
files.cmp
#FilesInArchives#
$(SxpRootDir1)\Organization.cnf
Organization.cnf File after Installation
For PCs that are assigned to the dep-h-resources group:
Product file on the target computer assigned to department: human-resources
For PCs that are assigned to the dep-financials group:
Product file on the target computer assigned to department: financials.
Gac.sxp Archive File
The Global Assembly Cache (GAC) is a directory containing Shared Assemblies and is located in the file system under %Windows%\Assembly. The GAC stores global components and can keep multiple versions of an individual file (even with the same file name). The GAC is also known as Fusion.
The location of the GAC is specified in the registry under HKLM\Software\Microsoft\Fusion.
The Global Assembly Cache (GAC) is automatically installed with the .NET runtime system. The assemblies in the GAC have their own reference counting. To correctly handle this references counting, all changes in the GAC are recorded and installed using the Fusion API.
The Packager stores changes made to the GAC in the gac.sxp archive file.
The gac.sxp archive file can contain any number of the following sections:
  • CreateAssembly
    n
  • DeleteAssembly
    n
n
 is the sequence number of the archive file (1, 2, 3, and so on).
An example follows that shows how a gac.sxp archive file containing one CreateAssembly and one DeleteAssembly section looks like:
#Sign#
ArchiveName=gac_xmpl
Release=4002
SXP=1.0
#Locale#
Codepage=3
#CreateAssembly1#
AsmDisplayName=MyAsm, Version=1.0.2879.30837, Culture=GER, PublicKeyToken=316630fb36ca936c
AsmFile=$(SxpWinDir)\assembly\GAC\MyAsm\1.0.2879.30837_GER_316630fb36ca936c\MyAsm.dll
Ref.Size=32
Ref.Flags=0
Ref.guidScheme=Data1=2ec93463 Data2=b0c3 Data3=45e1 Data4=8364327e96aea856
Ref.Identifier=SXP
Ref.NonCanonicalData=Created by SXP Installer
#DeleteAssembly1#
AsmDisplayName=MyAsm, Version=1.0.2879.30837, Culture=GER, PublicKeyToken=316630fb36ca936c
AsmFile=$(SxpWinDir)\assembly\GAC\MyAsm\1.0.2879.30837_GER_316630fb36ca936c\MyAsm.dll
Ref.Size=32
Ref.Flags=0
Ref.guidScheme=Data1=2ec93463 Data2=b0c3 Data3=45e1 Data4=8364327e96aea856
Ref.Identifier=Test
Ref.NonCanonicalData=MyReferenz
The AsmDisplayName and AsmFile entries are mandatory.
The Ref.
xxx
 entries are optional and specify a reference to install. An assembly is only removed from the GAC when all references are deleted. This means that the SXP Installer removes an assembly from the GAC, only if the assembly specified in the DeleteAssembly
n
 section deletes the last reference. Otherwise, only the reference is deleted. Accordingly, the SXP Installer installs the reference only when the assembly in a CreateAssembly
n
 section is already installed.
If the reference entries are missing in a CreateAssembly
n
 section, the assembly is installed without a reference.
Assemblies that are installed by the Microsoft Installer (MSI) have a special GUID scheme (FUSION_REFCOUNT_MSI_GUID defined in fusion.h). Only the Microsoft Installer can use this GUID scheme when installing assemblies. Therefore, the SXP Installer changes the GUID scheme before it performs an installation. The SXP Installer substitutes the MSI GUID scheme with the OPAQUE GUID scheme and changes the Identifier from MSI to SXP.
The registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Fusion, where the Fusion API stores information about the assemblies, is excluded from the registry scan performed by the SXP Packager.
During the uninstallation of an SXP package, assemblies deleted during the installation of the package are not restored.
Gina.sxp Archive File
The gina.sxp archive file is created automatically, if a product that you generate using the automatic method, replaces the current Windows system file msgina.dll but still needs to use it together with its own gina.dll.
The Packager then stores the reference to the original msgina.dll in this sxp file.
If you create a software package using the manual method, you must also create the gina.sxp file manually and enter the reference to the msgina.dll in the Chain section.
Example of a Gina.sxp archive file:
#Sign#
ArchiveName=40solomo
Release=7900
SXP=1.0
#Chain#
KeyName=SYSTEM\CurrentControlSet\Services\NTGuard\Scanner Settings
ValueName=OldGina
Info.sxp Archive File
The info.sxp file specifies general information about a product. This file is required. It is generated automatically.
The info.sxp file contains the following sections:
  • Contains information specific to the archived product.
  • Contains information about the home or root directory.
  • Indicates dependencies on other products on the target computer.
  • Indicates dependencies on other products on other systems.
  • Contains descriptive text or comments of any length.
For further information see Structure of the Info.sxp Archive File.
Structure of the info.sxp Archive File
The info.sxp archive file has the following structure:
#Product#
mandatory
Entries for this section
 
 
 
#RootDirs#
optional
 
 
 
#InternalDependence#
optional
 
 
 
#ExternalDependence#
optional
 
 
 
#Description#
optional
 
Product Section of Info.sxp
The Product section contains the following entries with information about the product:
ArchiveName=archive_name
mandatory
LongName=product_name
mandatory
Version=product_version
mandatory
Release=archive_version
mandatory
PreRelease=predecessor
mandatory
Systems=system_id
mandatory
SystemsDos=0
 
SystemsWin9x=0
 
SystemsWinNT=system_id
 
CreateDate=creation_date
optional
CreateBy=creator
optional
BootLevel=boot_level
optional
DeinstBootLevel=
boot_level
optional
ResetLevel=reset_level
optional
OSVersion=operating_system_version
optional
AdminVersion=packager_version
optional
DataUnitSizeVector=
dataunitsize_target
optional
VarCode
reserved for internal use
  • ArchiveName
    Specifies the name of the package as it appears in the Packager's product archive (maximum 32 bytes).
  • LongName
    Indicates the product name and description, maximum 47 characters.
  • Version
    Indicates the product version (original manufacturer's product version; informal)
  • Release
    Indicates the product package version (1000 - 9999); the version number specified when the product was packaged.
  • PreRelease
    Indicates the previous product package version (0000 - 9998). If this entry is 0000, it refers to a "complete" product If the entry is between 1000 and 9998, it refers to an update for a previous version.
  • Systems
    This is a legacy entry, which is used by older Installer versions only.
    Specifies the operating systems on which the product can be installed.
    Each operating system is assigned a unique decimal value as shown in the list following. The parameter value (
    system_id
    ) assigned to Systems is derived from the sum of the values of the permitted operating systems. For example, the entry Systems=768 specifies that the product can be installed on target computers running Windows XP or Windows 2003 (256 + 512 = 768).
8
Windows NT
16
Windows 2000
2048
Windows Server 2000
256
Windows XP
4096
Windows XP x64
512
Windows Server 2003
8192
Windows Server 2003 x64
1024
Windows Vista
16384
Windows Vista x64
32768
Windows Server 2008
65536
Windows Server 2008 x64
    • SystemsDos
      Not supported. This entry is always set to 0 by the Packager.
    • SystemsWin9x
      Not supported. This entry is always set to 0 by the Packager.
    • SystemsWinNT
      Specifies the operating systems with Platform ID 2 (NT) on which the product can be installed.
      Each operating system is assigned a unique decimal value as shown in the list below. Additionally, the value 1 is used to indicate, that the product can also be installed on all successor operating systems with the same platform ID.
      The parameter value (
      system_id
      ) assigned to SystemsWinNT is derived from the sum of the values of the permitted operating systems. For example, the entry SystemsWinNT=5889 specifies that the product can be installed on target computers running the 64-bit operating systems Windows XP x64, Windows Server 2003 x64, Windows Vista x64, Windows Server 2008 x64, or any predecessor of these operating systems (256 + 512 + 1024 + 4096 + 1 = 5889).
1
"Future operating systems", this means, all successors with the same platform ID
4
Windows NT
8
Windows 2000
128
Windows Server 2000
16
Windows XP
256
Windows XP x64
32
Windows Server 2003
512
Windows Server 2003 x64
64
Windows Vista
1024
Windows Vista x64
2048
Windows Server 2008
4096
Windows Server 2008 x64
    • CreateDate
      Specifies the date on which the product was created.
    • CreateBy
      Specifies the name of the person who packaged the SXP product.
    • BootLevel and DeinstBootLevel
      BootLevel specifies the behavior during installation of the SXP product (installation boot level).
      DeinstBootLevel specifies the behavior during uninstallation of the SXP product (deinstallation boot level).
      The installation boot level is set automatically by the reference installation, however, it can be modified manually. You can set boot levels for installation and deinstallation separately. If a deinstallation boot level is not specified, the value of the installation boot level is used.
      The Installer can change the boot level to a higher value, if a logoff/logon or reboot is necessary to install the product.
      Boot Level
      Action
      Comment
      0
      Target driven
      If circumstances during installation or removal of the product on the target computer require a reboot (for example, when a file to be replaced is locked on the target computer), the Installer initiates this reboot.Default, when the Packaging Computer has not been rebooted during the reference installation.
      1
      Logoff required
      Requires a user to log off and on to activate changes to the Windows desktop and registry.
      3
      Restart after batch
      Automatically initiates a system reboot at the end of the transaction.Default, when the Packaging Computer has been rebooted during the reference installation.
      4
      Restart after job
      Initiates a system reboot immediately after the end of the installation or removal of the product.
      For boot levels 1 and 3 the following applies: In a transaction with several installation and uninstallation jobs, the uninstallation jobs are executed first. The highest deinstallation boot level that occurs is recorded and the necessary system boot is performed at the end of all uninstallation jobs. If no deinstallation boot level exists, the installation boot level is used. Then the same procedure is applied to all installation jobs (using the highest installation boot level).
      The boot level 2 no longer applies with this Packager version. If an older package that contains the boot level 2 entry is being edited, the boot level is internally set to "1—Logoff required".
      • Packager Sets Boot Level:
        By default the Packager sets boot level 0. However, if the setup program reboots or the Restart button was selected during reference installation, the Packager changes this value to boot level 3.
      • Installer Changes Boot Level:
        When the Installer installs a product with boot level 0 and the files to be replaced are locked by an active process, the Installer automatically changes to boot level 3.
      • Manual Modification of Boot Level:
        You can manually change the boot level by:
        • Choosing to reboot during the reference installation, if you are creating a product.
        • Using the info.sxp editor (by double-clicking the info.sxp icon on the Packager main window) and changing the boot level settings on the Product tab.
        • Editing the boot level entries in the Product section of the info.sxp file manually.
    • ResetLevel
      Defines the action to perform if the installation of the SXP product fails.
      If this parameter is assigned, it overwrites the reset level pre-configured for the Installer. Products that use the reset level must be generated with the automatic method of packaging.
      By default, the reset level is not set and no ResetLevel entry exists in the Product section of the info.sxp archive file. In this case, the settings on the target computer define the reset behavior (target driven). If you want to overwrite this standard setting on the target computer, you must enter a reset level manually in the Product section of the info.sxp or use the info.sxp editor (double-click the info.sxp icon on the Packager main window) and set the reset level on the Product tab.
      The following table lists the permitted reset levels:
Reset Level
Action
Comment
No entry in info.sxp
Target driven - recommended
The settings on the target computer define the reset behavior.
0
No rollback
No reset.
1
Limited rollback
Specifies a limited reset. The product is uninstalled, but previously existing files on the target computer that were deleted or modified by the installation are not restored. Exception: Even if an installation fails and reset level 1 is invoked, an INI or ASCII file that was modified through an ini
nnnn
.sxp or asc
nnnn
.sxp archive file is always reset to its original content.
The following changes are not canceled by reset level 1:
    • Files specified in files.sxp in the InsDelFiles section remain deleted.
    • If an installation fails in some way and a reset is invoked, the files specified in the FilesInArchives section of the files.sxp archive file are not restored, if these files previously existed on the target computer from an earlier version. Examples include DLL files in the system directory. Consequently, some files of the new version of the product remain on the target computer.
2
Complete rollback
Specifies a complete reset. Reset level 2 is more extensive than reset level 1. Previously existing files on the target computer that were deleted by the installation are restored.
OSVersion
Specifies the operating system under which the product was packaged.
    • AdminVersion
      Specifies the Packager version used to package the product.
    • DataUnitSizeVector
      Specifies the data unit size (32-bit and/or 64-bit) that the operating environment on the target computer must have. An SXP package is only delivered and installed on a target computer when the data unit size of the target computer is specified through DataUnitSizeVector.
      An SXP product packaged in a 64-bit operating environment can only be installed on target computers running a 64-bit operating environment, even if a 32-bit operating environment has been specified as target operating system in info.sxp.
      dataunitsize_target
       can have the following decimal values:
      32 (for 32-bit data unit size only)
      64 (for 64-bit data unit size only)
      96 (for both 32-bit and 64-bit data unit sizes)
      Default:
       96
      To ensure backward compatibility, the Installer installs all SXP packages that do not have the DataUnitSizeVector entry.
RootDirs Section of info.sxp
The RootDirs section of the info.sxp archive file can have the following entries:
 
SxpRootDir1=First_root_directory
optional
:
 
SxpRootDir
n
=nth_root_directory
optional
 
 
  • SxpRootDirn
    Specifies the root directory number n of the product.
  • nth_root_directory
    Specifies the directory path. This is initially generated by the reference installation as an absolute path. Instead of the absolute path, you can optionally enter a client parameter manually. The Installer initially determines the value of the client parameter locally. Therefore, you can set root directories individually.
Example: Using a parameter to specify the directory path
SxpRootDir1=$(LocalMSOfficePath)
A client parameter, LocalMSOfficePath, is defined for a product, such as Microsoft Office 2000, which indicates the valid root directory on the target computer. On target computer1, the parameter could have the value E:\Office2000 and on target computer2 the value D:\Applications\Office2000.
InternalDependence Section of info.sxp
InternalDependence section of the info.sxp archive file can have the following entries:
Archive_name_1 operator_1 version_1
optional
:
 
Archive_name_n operator_n version_n
optional
 
 
The InternalDependence section describes dependencies on other products on the target computer. In this section, you can make any number of entries describing dependencies. All entries in this section are optional.
  • Archive_name
    Specifies the name of the package as it appears in the Packager's product archive (maximum 32 bytes). Note, that on DOS and Windows 3.x only up to eight bytes are supported.
  • Operator
    Specifies, in connection with a version number, when to install the product. The following operators are permitted:
    =
    Installation, when this version of the product is installed.
    >
    Installation, when a later version of the product is installed.
    <
    Installation, when an earlier version of the product is installed.
    >=
    Installation, when this version or a later version of the product is installed.
    <=
    Installation, when this version or an earlier version of the product is installed.
    !
    Each of the above operators can be negated by prefixing it with an exclamation point (!).
    When the exclamation point (!) is used as operator, a condition is regarded as true, even if the product is not installed on the target computer. Use the exclamation point (!) operator if the installation is not to be performed when the two versions are compared.
    Example: prod_a !<= 2000 specifies that the product is not installed if version 1000 to 2000 of prod_a is installed on the target computers. If prod_a is not installed or if the version is > 2000, the new product is installed.
    The operator must be enclosed in blanks (spaces)!
  • Version
    Indicates the version of a product with dependencies (range: 1000 - 9999).
      Example: Specifies that an MS Office program can only be installed on Windows NT 4.0 or newer
#InternalDependence#
Word >= 7000
PPoint >= 5000
An Excel product can be installed
only
if the products Word and PPoint are already installed with the specified or a newer version on the target computer, that is,
only
on Windows NT 4.0 or newer. The Excel product is created as a delta product (using the automatic method) based on previously generated products Word (Version 7000) and PPoint (Version 5000).
ExternalDependence Section of info.sxp
The ExternalDependence section of the info.sxp archive file can have the following entries:
Target_computer_1,Archive_name_1 operator_1 version_1
optional
:
 
Target_computer_1,Archive_name_n operator_n version_n
optional
 
 
The ExternalDependence section describes dependencies of the product on other products on other (“external”) target computers. In this section, you can create multiple entries specifying dependencies. All entries in this section are optional.
  • Target_computer
    Indicates the name of the other “external” target computer containing the required product. The name of the target computer has the following criteria:
    • FQDN name is not supported.
    • If the target display name is changed, then display name is mentioned instead of the actual hostname.
  • Archive_name
    Specifies the name of the package as it appears in the Packager's product archive (maximum 32 bytes).
  • Operator
    Specifies, in connection with a version number, when to install the product. The following operators are permitted:
    =
    Installation, when this version of the product is installed.
    >
    Installation, when a later version of the product is installed.
    <
    Installation, when an earlier version of the product is installed.
    >=
    Installation, when this version or a later version of the product is installed.
    <=
    Installation, when this version or an earlier version of the product is installed.
    !
    Each of the above operators can be negated by prefixing it with an exclamation point (!).
    When the exclamation point (!) is used as operator, a condition is regarded as true, even if the product is not installed on the target computer. Use the exclamation point (!) operator if the installation is not to be performed when the two versions are compared.
    Example: prod_a !<= 2000 specifies that the product is not installed if version 1000 to 2000 of prod_a is installed on the target computers. If prod_a is not installed or if the version is > 2000, the new product is installed.
    The operator must be enclosed in blanks (spaces)!
  • Version
    Specifies the version of a product with dependencies (range: 1000 - 9999).
In products that have been migrated from an earlier Software Delivery version, an additional parameter may appear in entries before “Target_computer“, separated by a comma. This parameter is obsolete and is no longer evaluated.
Example: Specify that a client component is installed only when a server component of version 1000 is installed on the application server
In a client-server application, the client component, Xclient, should be installed only when the accompanying server component, Xserver, of version 1000 is installed on the application server with the unique name ApplsServer1.
As a prerequisite to install the client component Xclient as an SXP product on the target computer, the server component Xserver must have been installed also as an SXP product on the target computer ApplsServer1.
To specify this dependency, insert the following line in the info.sxp archive file of the Xclient product:
#ExternalDependence#
ApplsServer1,Xserver = 1000
Description Section of info.sxp
The Description section of the info.sxp archive file can contain the following entries:
Line_1
optional
:
 
Line_n
optional
 
 
In the Description section you can enter multiple lines containing descriptive text and comments. The first 127 bytes are used as comment in the CA ITCM Explorer.
All entries in this section are optional.
If you want to describe any parameter used, avoid using the form $(parameter). Otherwise, the Installer will automatically replace the parameter string. We recommend either using $$(parameter) or substituting the $, for example, §(parameter).
Ininnnn.sxp Archive File
An archive file ininnnn.sxp is automatically created for each ini file packaged using the automatic method, in other words, for all ini files located in the path specified on the Paths to Scan tab. All the sections in this SXP file are automatically generated by the automatic method. File attributes are also recorded.
If you manually create an ininnnn.sxp file or delete automatically created files, note that these files must be numbered in ascending sequential order, beginning with ini0001.sxp.
The file contains the following sections:
  • Specifies the path name of the corresponding ini file.
  • Specifies sections of the ini file (specified in the Info section) that are deleted during installation. The automatic method does not enter anything in this section.
  • Specifies entries deleted during installation.
  • Specifies entries inserted during installation.
  • Specifies sections of the ini file (specified in the Info section) that are deleted during uninstallation of the product.
  • Specifies entries deleted during uninstallation of the product.
  • Specifies entries inserted during uninstallation of the product. The automatic method does not enter anything in this section.
Any INI files on the Packaging Computer that do not follow Microsoft Windows standards for INI files are completely packaged in the files.cmp file. In other words, instead of only the changes to the INI file being recorded during the reference installation and applied to the same INI file on the target computer, the INI file on the target computer is completely replaced with the INI file from the Packaging Computer.
For further information and an example see Structure of the Ininnnn.sxp File and Example of How to Use Ini0001.sxp.
Structure of the Ininnnn.sxp File
The structure of the ininnnnn.sxp archive file is as follows:
#Info#
 
 
 
 
#InsDelSections#
optional
 
 
 
#InsDelEntries#
optional
 
 
 
#InsAddEntries#
optional
 
 
 
#DeiDelSections#
optional
 
 
 
#DeiAddEntries#
optional
 
 
 
#DeiDelEntries#
optional
 
 
 
The following parameter applies to all sections of the ininnnn.sxp archive file:
  • Separator
    Specifies the separator between the substrings of individual values in an entry. Any character may be used as separator.
    The separator is evaluated only in extended entries (Flag=X). If the separator is omitted, it is preset to empty space.
    Example where the separator is the comma (,):
    run=c:\win\start,c:\winchk\winchk.exe
Info Section of the Ininnnn.sxp File
This section specifies the file path and attributes for the INI file.
The Info section can have the following entries:
Path=
File_path
 
Attributes=
Attribute_value
 
InsDelSections Section of the Ininnnn.sxp File
The InsDelSections section specifies the sections of the INI file that are to be deleted during installation. The reference installation does not enter anything in this section.
The section names of the INI file must be specified in square brackets [ ], for example, [Sound, Setting].
The InsDelSections section can have the following entries:
[
Section_1
]
optional
:
 
[
Section_1
]
optional
 
 
InsDelEntries Section of the Ininnnn.sxp File
The InsDelEntries section specifies the entries of the INI file that are to be deleted during installation. You must specify a delete flag for each entry that you add to this section.
The section name of the INI file must be specified in square brackets [ ], for example, [Sound, Setting].
The InsDelEntries section can have the following entries:
Flag_1,Separator_1,
[
Section
],
Entry_1
optional
:
 
Flag_n,Separator_n,
[
Section
],
Entry_n
optional
 
 
  • Flag
    Specifies the deletion action:
    • N
      Normal entry. Deletes this entry from the section.
    • M
      Multiple entry. Deletes all entries corresponding to the entry name you specify from the section.
    • X
      Extended entry. Deletes the specified substring from the entry. The separator indicates the substring.
InsAddEntries Section of the Ininnnn.sxp File
The InsAddEntries section specifies the entries of the INI file that are to be inserted during installation. You must specify an insert flag for each entry that you add to this section.
The section name of the INI file must be specified in square brackets [ ], for example, [Sound, Setting].
The InsAddEntries section can have the following entries:
Flag_1,Separator_1,
[
Section
],
Entry_1
optional
:
 
Flag_n,Separator_n,
[
Section
],
Entry_n
optional
 
 
  • Flag
    Specifies the insertion action:
    • N
      Normal entry. Inserts this entry in the section.
    • M
      Multiple entry. Inserts this entry in the section. If this entry already exists, the new entry is also added, if the values are different.
    • X
      Extended entry. Inserts this entry in the section. If this entry already exists, the value of the entry is extended to include the specified value. The specified separator separates the values.
DeiDelSections Section of the Ininnnn.sxp File
The DeiDelSections section specifies the sections of the INI file that are to be deleted during uninstallation of the product.
The section names of the INI file must be specified in square brackets [ ], for example, [Sound, Setting].
The DeiDelSections section can have the following entries:
[
Section_1
]
optional
:
 
[
Section_1
]
optional
 
 
DeiDelEntries Section of the Ininnnn.sxp File
The DeiDelEntries section specifies the entries of the INI file that are to be deleted during uninstallation. You must specify a delete flag for each entry that you add to this section.
The section name of the INI file must be specified in square brackets [ ], for example, [Sound, Setting].
The DeiDelEntries section can have the following entries:
Flag_1,Separator_1,
[
Section
],
Entry_1
optional
:
 
Flag_n,Separator_n,
[
Section
],
Entry_n
optional
 
 
  • Flag
    Specifies the deletion action:
    • N
      Normal entry. Deletes this entry from the section.
    • M
      Multiple entry. Deletes all entries corresponding to the entry name you specify from the section.
    • X
      Extended entry. Deletes the specified substring from the entry. The separator indicates the substring.
DeiAddEntries Section of the Ininnnn.sxp File
The DeiAddEntries section specifies the entries of the INI file that are to be inserted during uninstallation. You must specify an insert flag for each entry that you add to this section.
The section name of the INI file must be specified in square brackets [ ], for example, [Sound, Setting].
The DeiAddEntries section can have the following entries:
Flag_1,Separator_1,
[
Section
],
Entry_1
optional
:
 
Flag_n,Separator_n,
[
Section
],
Entry_n
optional
 
 
  • Flag
    Specifies the insertion action:
    • N
      Normal entry. Inserts this entry in the section.
    • M
      Multiple entry. Inserts this entry in the section. If this entry already exists, the new entry is also added, if the values are different.
    • X
      Extended entry. Inserts this entry in the section. If this entry already exists, the value of the entry is extended to include the specified value. The specified separator separates the values.
Example How to Use Ini0001.sxp
This example includes the InsDelSections, InsDelEntries, and InsAddEntries sections. The Hidden attribute is set for the Ini file.
$(SxpRootDir1)\sample.ini File:
[DeleteSection]
Any entry=One entry is as good as another
[DeleteEntries]
Entry3=anything
Entry1=something else
Entry2=something else&anything&anything else
Entry3=whatever
[InsertEntries]
NormalEntry=100
MultipleEntry=first value
ExtendedEntry=one three four
Ini0001.sxp File:
#Sign#
ArchiveName=test1
Release=2222
#Info#
Path=$(SxpRootDir1)\sample.ini
SXP=1.0
Attributes=34
#InsDelEntries#
N,,[DeleteEntries],Entry1
X,&,[DeleteEntries],Entry2=anything
M,,[DeleteEntries],Entry3
#InsDelSections#
[DeleteSection]
#InsAddEntries#
N,,[InsertEntries],NormalEntry=222
M,,[InsertEntries],MultipleEntry=second value
X, ,[InsertEntries],ExtendedEntry=two
Sample.ini File following Installation of Test1:
[DeleteEntries]
Entry2=something else&anything else
[InsertEntries]
NormalEntry=222
MultipleEntry=second value
MultipleEntry=first value
ExtendedEntry=one three four two
Links.sxp Archive File
The links.sxp and ulinks.sxp archive files describe the links (that means shortcuts) to be installed, modified, or deleted within the Windows Explorer. Links that are found in common folders will be written to links.sxp. Links that are found in user-specific folders will be written into ulinks.sxp.
The file contains the following sections:
  • Specifies links to be added during installation.
  • InsAddWILink
    n
    Reserved for internal use. Do not edit!
  • InsAddWILinkEx
    n
    Reserved for internal use. Do not edit!
  • Specifies links to be changed during installation.
  • Specifies links to be deleted during installation.
  • Specifies links to be added during uninstallation.
  • Specifies links to be changed during uninstallation.
  • Specifies links to be deleted during uninstallation.
These sections are optional and may occur several times each. The number
n
 is used to distinguish between sections of the same name. A section defines a link.
The structure of the links.sxp archive file is described in Structure of the Links.sxp File.
An example can be found under Example of Links.sxp.
Structure of Links.sxp
The links.sxp archive file has the following structure:
#InsAddLink1#
optional
 
:
 
#InsAddLink
n
#
optional
 
#InsChgLink1#
optional
 
:
 
#InsChgLink
n
#
optional
 
#InsDelLink1#
optional
 
:
 
#InsDelLink
n
#
optional
 
#DeiAddLink1#
optional
 
:
 
#DeiAddLink
n
#
optional
 
#DeiChgLink1#
optional
 
:
 
#DeiChgLink
n
#
optional
 
#DeiDelLink1#
optional
 
:
 
#DeiDelLink
n
#
optional
 
InsAddLink, InsChgLink, DeiAddLink, and DeiChgLink Sections of Links.sxp
The InsAddLink, InsChgLink, DeiAddLink
,
 and DeiChgLink sections of the links.sxp archive file can have the following entries:
LnkPath=
Link_name
mandatory
Path=
Program_path
mandatory
Arguments=
Call_arguments
 
Symbol=
Item_path
,
Item_index
 
WorkDir=
Working_directory
 
Description=
Description
 
Hotkey=
Hotkey
 
Show=
Display_options
 
  • LnkPath
    Specifies the complete path of the link file.
  • Path
    Specifies the complete path of the file to which the link file is linked.
  • Arguments
    Lists arguments of the program to which a link is to be established.
  • Symbol
    Specifies item path and index.
  • WorkDir
    Indicates the working directory of the application.
  • Description
    Describes the link.
  • HotKey
    Specifies the Hotkey used for starting the application.
  • Show
    Specifies display options, as follows:
    • 1
      The application starts with the window in its original size and position. The window is activated.
    • 3
      The application starts with the window maximized. The window is activated.
    • 7
      The application starts with the window minimized. The window is not activated.
InsDelLink and DeiDelLink Sections of Links.sxp
The InsDelLink and DeiDelLink sections of the links.sxp archive file must have the following entry:
LnkPath=
Link_name
mandatory
  • LnkPath
    Specifies the complete path of the link file.
Example of Links.sxp
Following is an example of a links.sxp archive file:
#InsAddLink1#
LnkPath=$(SxpRootDir1)\Readme.lnk
Path=$(SxpWinProgDir)\Winamp\readme.txt
Arguments=
Symbol=,0
WorkDir=$(SxpWinProgDir)\Winamp
Description=
Hotkey=0
Show=1
#DeiDelLink1#
LnkPath=$(SxpRootDir1)\Readme.lnk
Original.sxp Archive File
The original.sxp file specifies settings for installing and removing a packaged product on the target computer by running its original setup.exe or uninstall.exe program. Because the installation and uninstallation process is to run without user interaction, you must specify one or more response files to answer the questions asked by the setup or uninstallation program.
You must create the original.sxp file manually.
The original.sxp archive file contains the following sections:
  • Contains path names for the response files.
  • Specifies scripts that modify response files.
  • Contains program calls for installation and uninstallation. The program call under Install is executed during installation, and the program call under Deinstall is executed during uninstallation of the product. If the installation is incorrect, the program specified through ErrInstall is executed.
    Both 64-bit and 32-bit programs can be launched from the original.sxp archive file.
For further information and an example see Structure of the Original.sxp File and Example of How to Use Original.sxp.
Structure of the Original.sxp File
The structure of the original.sxp archive file is as follows:
#ResponseFiles#
optional
 
 
 
#ScriptFiles#
optional
 
 
 
#Actions#
optional
 
 
 
The absolute path names you specify for all program calls must begin with the internal $(SxpSrvRelDir) parameter. These path names must not contain any blanks.
ResponseFiles Section of Original.sxp
The ResponseFiles section specifies the absolute file paths of the response files. The entries enables the Installer to process client parameters included in the response files.
The ResponseFiles section can have the following entries:
Rfile1=
response_file_1
optional
:
 
Rfile
n
=
response_file_n
optional
 
 
  • RFile
    n
    Specifies the absolute file path of the nth response file.
Example
The Microsoft Office product can be installed unattended, if you provide a response file, such as MySetup.stf, as a parameter when Setup is called. This response file contains information such as the root directory in which the product is to be installed, and must be included with the product.
You can write a script that modifies the response file for a specific target computer.
If you copy the response file directly into the version directory, you must insert the following lines in the ResponseFiles section:
#ResponseFiles#
Rfile1="$(SxpSrvRelDir)\MySetup.stf"
On the target computer, the internal $(SxpSrvRelDir) parameter refers to the path on the manager where the product to be installed is stored.
After being modified by the associated script file, the response file is saved by the Installer in a temporary directory. The path of this locally modified file is supplied by the internal $(SxpRFile1) parameter.
ScriptFiles Section of Original.sxp
The ScriptFiles section contains the absolute file paths of the scripts that modify the corresponding response files. SFile
n
 modifies RFile
n
. For example, SFile1 modifies RFile1.
For a description of the Packager-specific scripting language see Packager Scripting Language.
The ScriptFiles section can have the following entries:
Sfile1=
script_file_1
optional
:
 
Sfile
n
=
script_file_n
optional
 
 
  • Sfilen
    Specifies the
    n
    th script file. This entry contains the absolute file path of the script and modifies the
    n
    th response file.
Example
The Microsoft Office product can be installed unattended, if you provide a response file, such as MySetup.stf, as a parameter when Setup is called (see the description in the ResponseFiles section of the original.sxp file).
To adapt this response file for a specific target computer, you can write a script in the internal script language, that modifies the response file prior to installation on the target computer. For example, the script file could change the root directory for Microsoft Office specified in MySetup.stf.
You can save the script in the MyScript.scr file and copy this file to the version directory of the product. Then insert the following lines in original.sxp:
#ScriptFiles#
Sfile1="$(SxpSrvRelDir)\MyScript.scr"
The script is used on the target computer for the file entered in the ResponseFiles section of original.sxp in the line starting with 'Rfile1='.
The Installer saves the response file that is modified by the associated script in a temporary directory. The path of this locally modified file is supplied by the internal $(SxpRFile1) parameter.
Actions Section of Original.sxp
The Actions section contains program calls for installation and uninstallation (removal).
The Actions section can have the following entries:
Install=
Program_call
[,
Return_code
[,
Timeout
]]
 
ErrInstall=
Program_call
 
Deinstall=
Program_call
[,
Return_code
[,
Timeout
]]
 
You can enter only one program call per line. To call more than one program, enter these programs in the corresponding section of actions.sxp.
  • Install
    Specifies the program call that is executed during product installation.
    If you define an Install action, then you must also define a Deinstall action. The Deinstall action can be a dummy action such as the following:
    cmd.exe /c echo deinstall
  • ErrInstall
    Specifies the program call that is executed if the product installation is faulty.
  • Deinstall
    Specifies the program call that is executed during product uninstallation.
    • When an uninstall routine is called, $(SxpSrvRelDir) is resolved with the path name to the source of the installation files, which are only available temporarily. Therefore, the Deinstall routine is copied to the target computer $(SxpLocRelDir) and invoked as required.
    • If the uninstallation requires additional files, such as DLL or response files, that reside in the $(SxpSrvRelDir) directory or its subdirectories, you must use the post-program batch file to copy these files to the $(SxpLocRelDir) directory or the appropriate subdirectories on the target computer.
    • If the Actions section contains a Deinstall= entry and the program is called using the internal parameter $(SxpSrvRelDir), then the program path must not contain any blanks.
  • Program_call
    Specifies the absolute program path for the program call (including file name extension *.exe, *.bat, *.com). Since the path may contain Blanks (spaces), you need to enclose it in quotation marks!
  • Return_code
    Specifies the expected return code for a successful installation or uninstallation. This value is compared with the actual return code from the installation (or uninstallation) program of the product being installed (or uninstalled).
    If the expected return code is not identical to the actual return code, the Installer aborts the job and reports an error.
    If you do not specify the return code, the Installer will not be able to compare the actual and expected return codes and therefore is not able to report errors during the execution of the Install and Deinstall commands.
    You should always specify the return code, because the Installer assumes that the installation or uninstallation is successful if the timeout expires and no return code was specified.
  • Timeout
    Indicates the number of minutes that can elapse without the started program terminating. If the program continues running, an attempt is made to stop this program. The stop process results in a procedure error.
    Default:
     60.
    You should always use this parameter together with the return code parameter (described above) to help detect faulty installations or uninstallations.
Example How to Use Original.sxp
The Microsoft Office product can be installed in unattended mode, if you provide proper options and a response file as a parameter when Setup is called.
The Installer stores the modified response file (Rfile1 in the ResponseFiles section of original.sxp) in a temporary directory. The path of this modified file is supplied by the internal $(SxpRFile1) parameter.
Let us assume you copied the contents of the installation CD for Microsoft Office to the MSOFF_CD subdirectory of the version directory and created a MSOInsPath client parameter for the root directory of the product.
Insert the following lines in the Actions section of the original.sxp file:
#Actions#
Install="$(SxpSrvRelDir)\MSOFF_CD\setup.exe" /t $(SxpRFile1) /q1
Deinstall="$(MSOInsPath)\office\setup\acme.exe" /w offpro.stf /u /q1
Even if uninstallation is not required, enter a dummy entry in the Actions section, to ensure that it contains at least one entry. Otherwise, the Installer reports an error code when the product is installed on any target computer. A sample dummy entry follows:
Deinstall="$(SxpWinDir)\cmd.exe" /c echo deinstall
Specifying Calling Commands for Windows NT Technology
For Windows NT Technology to invoke any operating system commands, such as copy or del, in a pre-program or post-program, you must enter a line like the following in the Actions section of the original.sxp file:
"$(SxpWinDir)\cmd.exe" /c copy c:\temp\*.tmp
Sample Program Call
A sample install program call will look like this:
Install="setup.exe",0,20
Permis.sxp Archive File
(Windows NT Technology only)
The permis.sxp archive file can be used to set access rights for the objects of a product (that is, files, directories, and registry keys), for specific users or groups, on NTFS partitions. Other files, directories, and registry keys of the target computer can also be edited. Changed access rights are kept, that is, they are not reset when deinstalling the product.
You must create the permis.sxp file manually.
To process the permis.sxp file, the Installer requires that the user who installs the product on the target computer must have administrator rights.
The permis.sxp archive file contains the following sections:
  • Contains one or more sections named Permis1 to Permis
    n
    . These sections assign access rights for the product files, directories, and registry keys to each user defined on the target computer.
    You create a new Permis
    n
     section when you want to use different entries for the keywords 'type,' 'object,' or 'file masks.' The Permis
    n
     sections must be numbered sequentially in ascending numeric order.
For further information and examples see Structure of the Permis.sxp File and Example How to Use Permis.sxp.
Structure of the Permis.sxp File
The structure of the permis.sxp archive file is as follows:
#Permis1#
optional
 
:
 
#Permis
n
#
optional
 
 
 
Permis Sections of Permis.sxp
In the Permisn sections you set the access rights for an object. Each object is specified by the entries Type, Object, and (optional) FileMask.
Each of the Permis
n
 sections can have the following entries:
Type=
Type
 
Object=
Object
 
FileMask=
File_mask
optional
AddToACL=
Value
optional
Aace1=
Account_name_1
,
Access_mask_1
optional
:
 
Aace
n
=
Account_name_n
,
Access_mask_n
optional
Dace1=Account_name_1
optional
:
 
Dace
n
=
Account_name_n
optional
 
 
  • Type
    Specifies the type of the object. The value of
    type
     can be one of the following:
File
A file
Dir
A directory with files
RDir
A directory with files and subdirectories
Key
A key
RKey
A key and subkeys
  • Object
    Specifies the object including its path name. The type of the object determines the structure of the object. The types and associated structures are listed following:
File
A file path
Dir
A directory path
RDir
A directory path
Key
A root_key\key structure
RKey
A root_key\key structure
  • File_mask
    Specifies a file mask. All files corresponding to this
    file_mask
     are assigned the access rights. The
    file_mask
     can be specified only if the object type is Dir or RDir. You can specify file extensions only, such as *.doc. No path details can be specified.
  • AddToACL
    Specifies how to deal with the current access control list (ACL).
    • yes
      The access control elements (AAce and Dace) should be added to the object's access control list.
    • Any other value and default
      The access control elements (AAce and Dace) should replace the object's access control list.
  • Aacen
    Sets the access right (Allowed ACE) for the
    account_name
     specified in the line to the specified access mask.
  • Dacen
    Denies access (Denied ACE) for the
    account_name
     specified in the line. Note that deny entries take priority over allow entries. Use them very carefully!
  • Account_name
    Specifies the user or group name.
    The
    account_name
     can be qualified by a domain prefix, such as domain\account. domain is the name of the Windows domain this system is part of or of a trusted domain.
    If
    account_name
     is not qualified, it is mapped to the local account of the same name. If this local account does not exist,
    account_name
     is mapped to the domain account or any trusted domain account of the same name.
    Examples:
MyAccount
The given account name
MySystem
The name of the local system
MyDomain
The system is part of this Windows domain
If
MyAccount
 is an account defined on the local system, the access control is set for this account. If
MyAccount
 is not an account of the local system, but it is an account of
MyDomain
, the access control is set for
MyDomain
\MyAccount.
There are several well-known security identifiers that map to predefined accounts, which are however localized.
For example, on an U.S. English system, the account of the local group of administrators is Administrators, whereas on a German system it is called Administratoren.
These accounts can be specified independent of their localization as follows:
    • \MyDomain\RIDAlias
      Usd for a predefined Windows domain-specific account. MyDomain is the Windows domain the system is part of. The domain-related RIDAlias can have one of the values listed under List of RIDAlias Values. Note that only a subset of these accounts may exist on a single system.
    • \SIDAlias
      Used for a predefined built-in account or special account. SIDAlias can have one of the values listed under List of SIDAliassidalias Values.
      Hint: You can use parameters when defining an account. For example, define the PrimaryDomain parameter as follows:
      PrimaryDomain=&HKLM\software\microsoft\windows nt\CurrentVersion\Winlogon\CachePrimaryDomain
    • \$(PrimaryDomain)\Domain Users
      Will be resolved to the predefined global domain users account of the Windows domain the target computer is a part of.
    • \$(%COMPUTERNAME%)\Administrator
      Will be resolved to the target computer’s predefined local administrator account.
    • Access_mask
      Specifies the access in hexadecimal format (eight positions). The critical values for the access masks are:
10000000
Full access
20000000
Execute access
40000000
Write access
80000000
Read access
00010000
Permission to delete
00020000
Permission to read the Access Control List (ACL)
00040000
Permission to read and write to the Access Control List (ACL)
00080000
Permission to change the owner name
For example, C0000000 specifies Read and Write access.
  • Key
    Specifies the name of key in the format SubKey1\ ...\SubKeyn
  • Root key
    Specifies the root keys predefined by Windows NT Technology. You can assign the following root keys:
    • HKEY_CLASSES_ROOT
    • HKEY_LOCAL_MACHINE
    • HKEY_USERS
Example How to Use Permis.sxp
For this example we assume that the system is part of the Windows domain called MyDomain. TrustedDomain is assumed to be a trusted domain of MyDomain.
Used accounts that have to be created first include:
  • The MyProductUsers group of MyDomain:
    MyDomain\MyProductUsers
  • The MyRestrictedUsers group of MyDomain:
    MyDomain\MyRestrictedUsers
  • The Unwanted user of TrustedDomain:
    TrustedDomain\Unwanted
  • Files and directories to be created include:
$(SxpRootDir1)\bin\ReadMe.txt
$(SxpRootDir1)\bin\NOTEPAD.EXE
$(SxpRootDir1)\MyLogfile.log
$(SxpRootDir1)\withoutextension
  • Registry keys and values to be created include:
[HKEY_LOCAL_MACHINE\Software\MyCompany]
[HKEY_LOCAL_MACHINE\Software\MyCompany\MyProduct]
"Entry"="any"
[HKEY_LOCAL_MACHINE\Software\MyCompany\MyProduct\MySubkey]
"SubkeyEntry"=dword:00000000
Step 1: Replace the current access control list:
Grant full access for members of the local Administrators group on the root directory of the product, all its subdirectories and files. Grant read, write, and execute access for all members of the MyProductUsers group.
Note that all other permissions are removed.
#Permis1#
Type=RDir
FileMask=*.*
Object=$(SxpRootDir1)
AddToACL=yes
Aace1=\Administrators,10000000
Aace2=MyDomain\MyProductUsers,E0000000
Step 2: Add to the current access control list
Grant read and execute permission on the $(SxpRootDir1)\bin directory and all its executables for everyone, except the members of the MyDomain\MyRestrictedUsers group and the TrustedDomain\Unwanted user.
Note that deny entries takes priority over allow entries.
#Permis2#
Type=Dir
Object=$(SxpRootDir1)\bin
FileMask=*.exe
AddToACL=yes
Aace1=\Everyone,A0000000
Dace1=MyDomain\MyRestrictedUsers
Dace2=TrustedDomain\Unwanted
Step 3: Add to the current access control list
Grant full access for everyone on the $(SxpRootDir1)\MyLogfile.log file. Deny access for the TrustedDomain\Unwanted user.
#Permis3#
Type=File
Object=$(SxpRootDir1)\MyLogfile.log
AddToACL=yes
Aace1=\Everyone,10000000
Dace1=TrustedDomain\Unwanted
Step 4: Replace the current access control list
Grant full access for members of the local Administrators group and the local system account on the HKEY_LOCAL_MACHINE\Software\MyCompany\MyProduct registry key and all its subkeys.
Note that all other permissions are removed.
#Permis4#
Type=RKey
Object=HKEY_LOCAL_MACHINE\MyCompany\MyProduct
Aace1=\Administrators,10000000
Aace2=\Local System\,10000000
Step 5: Add to the current access control list
Grant read and write access for members of the Windows domain users group of the primary domain (MyDomain) and for the domain users group of the trusted domain (TrustedDomain) on the HKEY_LOCAL_MACHINE\Software\MyCompany\MyProduct\MySubkey registry key. Deny access for the TrustedDomain\Unwanted user.
A Windows domain-related predefined account, like domain users, can be used only with the primary domain. For example, it is not possible to set permissions for the global group of domain users of TrustedDomain by using the predefined account. However, you can use the localized name, TrustedDomain\domain users, instead.
#Permis5#
Type=Key
Object=HKEY_LOCAL_MACHINE\MyCompany\MyProduct\MySubkey
AddToACL=yes
Aace1=\MyDomain\Domain Users,C0000000
Aace2=TrustedDomain\Domain Users,C0000000
Dace1=TrustedDomain\Unwanted
Services.sxp Archive File
The services.sxp archive file controls the installation and uninstallation of services. Services are programs that run unnoticed in the background, such as virus scanners. Services can be started under a particular service account, only if they receive the proper access rights. You can define the account and password for such services in the services.sxp file.
The services.sxp archive file can contain the following sections:
  • This section is created by the Packager for every service to be installed by the Installer during installation.
  • Specifies the names of all services that are to be started by the Installer during installation.
     
     To edit the InsStartService section correctly, you must have expert system knowledge of the platform on which the target computer is running.
  • Specifies the names of all services that are to be stopped by the Installer during installation.
     
     To edit the InsStopService section correctly, you must have expert system knowledge of the platform on which the target computer is running.
  • Specifies the names of all services that are to be uninstalled by the Installer during installation.
  • Specifies the names of all services that are to be started by the Installer during uninstallation of the product.
    You must ensure that the binary file for the service (.exe file) still exists on the target computer under the same name and the same path.
  • Specifies the names of all services that are to be stopped by the Installer during uninstallation of the product.
  • Specifies the names of all services that are to be uninstalled by the Installer during uninstallation of the product.
For further information and an example see Structure of the Services.sxp File and Example of Services.sxp.
Structure of the Services.sxp File
The structure of the services.sxp archive file is as follows:
#InsCreateService1#
optional
 
:
 
#nsCreateService
n
#
optional
Entries for this section
 
 
 
#InsStartService#
optional
 
 
 
#InsStopService#
 
 
 
 
#InsDelService#
 
 
 
 
#DeiStopService#
optional
 
 
 
#DeiDelService#
optional
 
 
 
#DeiStartService#
optional
 
 
 
 
InsCreateService Section of the Services.sxp File
The InsCreateService sections can have the following entries:
ServiceName=
Service_name
optional
DisplayName=
Display_name
optional
ServiceType=
Service_type
optional
StartType=
Start_type
optional
ErrorControl=
Error_control
optional
BinaryPathName=
Binary_path
optional
LoadOrderGroup=
Load_order_group
optional
TagId=
Tag_id
optional
Dependencies=
Service_name_1
[,
Service_name_n
]
optional
ServiceStartName=
Account
reserved
Password=
Encrypted_password
reserved
  • ServiceName
    Specifies the name of the service.
  • DisplayName
    Specifies the name of the service to be displayed under Services in the Control Panel in the Settings menu.
  • ServiceType
    Specifies the type of service. Valid values are:
 
1
(SERVICE_KERNEL_DRIVER)
Describes a driver service.
2
(SERVICE_FILE_SYSTEM_DRIVER)
Describes a driver service for file systems.
16
(SERVICE_WIN32_OWN_PROCESS)
Describes a 32-bit service with its own process.
32
(SERVICE_WIN32_SHARE_PROCESS)
Describes a 32-bit service that shares a process with other services.
 
If you specify 16 or 32 as type of service, you can combine that specification with the SERVICE_INTERACTIVE_PROCESS specification, by adding the value 256 to 16 or 32 (for example, ServiceType=272 is a valid entry in the InsCreateService section.)
256
(SERVICE_INTERACTIVE_PROCESS)
Indicates that a 32-bit service is enabled to interact with the desktop.
 
 
  • StartType
    Specifies when the service should be started. Valid values are:
 
0
(SERVICE_BOOT_START)
Describes a device driver that was started by the boot loader. This value is valid for device drivers only.
1
(SERVICE_SYSTEM_START)
Describes a device driver that was started by the IoInitSystem function. This value is valid for driver services only.
2
(SERVICE_AUTO_START)
Describes a service that is started automatically by the service control manager during system startup.
3
(SERVICE_DEMAND_START)
Describes a service that is started automatically by the service control manager if a process invokes the StartService function.
4
(SERVICE_DISABLED)
Describes a service that can no longer be started.
  • ErrorControl
    Specifies the reaction to an error during startup. Valid values are:
 
0
(SERVICE_ERROR_IGNORE)
Specifies that the boot loader logs the error but the start process is continued nonetheless.
1
(SERVICE_ERROR_NORMAL)
Specifies that the boot loader logs the error and outputs an error message as a pop-up, but the start process is continued nonetheless.
2
(SERVICE_ERROR_SEVERE)
Specifies that the boot loader logs the error and the start process is continued when the last functional configuration is started. Otherwise, the system is restarted with the last functional configuration.
3
(SERVICE_ERROR_CRITICAL)
Specifies that the boot loader logs the error, if possible, and the start process aborts when the last functional configuration is started. Otherwise, the system is restarted with the last functional configuration.
  • BinaryPathName
    Specifies the name and path of the service's binary file.
  • LoadOrderGroup
    Specifies the name of the load order group to which the service belongs.
  • TagId
    Indicates the position in the load order group
  • Dependencies
    Specifies the names of services or load order groups that must be started before the service.
  • ServiceStartName
    Reserved for future use.
  • Password
    Reserved for future use.
InsStartService Section of the Services.sxp File
This section is recorded by the reference installation. The section can be deactivated by inserting comment symbols (;) at the beginning of the line.
The activation of start of services on a running operating system should be used very carefully. The services in question will be started automatically after restarting the target computer.
The InsStartService section can have the following entries:
ServiceName1=
Service_name_1
optional
:
 
ServiceName
n
=
Service_name_n
optional
 
 
  • ServiceName
    Specifies the name of the service.
DeiStopService Section of the Services.sxp File
This section is recorded by the reference installation. The section can be deactivated by inserting comment symbols (;) at the beginning of the line.
The activation of stop of services on a running operating system should be used very carefully. The services in question will be stopped automatically after restarting the target computer.
The DeiStopService section can have the following entries:
Service_name_1
optional
:
 
Service_name_n
optional
 
 
  • Service_name
    Specifies the name of the service.
InsStopService, InsDelService, DeiStopService, DeiDelService, DeiStartService Sections of the Services.sxp File
Each of these sections can have the following entries:
Service_name_1
optional
:
 
Service_name_n
optional
 
 
  • Service_name
    Specifies the name of the service.
Example of Services.sxp
Following is an example of a services.sxp archive file:
#Sign#
ArchiveName=ie5
Release=1000
SXP=1.0
#InsStartService#
ServiceName1=ProtectedStorage
#InsCreateService1#
ServiceName=ProtectedStorage
DisplayName=Protected Storage
ServiceType=272
StartType=2
ErrorControl=1
BinaryPathName=$(SxpWinSysDir)\pstores.exe
LoadOrderGroup=
TagId=0
Dependencies=RpcSs
ServiceStartName=LocalSystem
Password=
#DeiStopService#
ProtectedStorage
#DeiDelService#
ProtectedStorage
Sreg.sxp Archive File
The sreg.sxp archive file specifies system-specific modifications to the registry in the HKEY_LOCAL_MACHINE tree. The sreg.sxp file is generated automatically.
For detailed information about the contents of the sreg.sxp file see Structure of the Sreg.sxp File.
Structure of the Sreg.sxp File
The structure of the sreg.sxp archive file is as follows:
[Root_key_1\Key_1]
Value_name_1=Data_1
:
Value_name_m=Data_m
:
:
:
[
Root_key_n\Key_n
]
Value_name_1=Data_1
:
Value_name_m=Data_m
 
  • Root_key
    Specifies the root key assigned by Windows. Valid root key specifications are:
    • HKEY_CLASSES_ROOT
    • HKEY_CURRENT_USER
    • HKEY_LOCAL_MACHINE
    • HKEY_USERS
  • Key
    Specifies the name of a key in the following format:
    SubKey_1
    \.....\
    SubKey_n
  • Value_name
    Specifies the name of a value. The name of the value must be enclosed in quotation marks. The assignment of the default value for the key is predefined as follows:
    @="data"
  • Data
    The data which is specified at this location in the sreg.sxp file can be of the following types:
 
string
Character string
dword
dword: 8 hex characters
binary
hex: 2 hex characters,2 hex characters,...
expand string
hex(2): character string.
 
The registry values, that are specified in the Expandable Registry Values tab, are interpreted as expandable values. This means, that the Packager only records the expanded part. When the Packager finds the value types REG_SZ and REG_EXPAND_SZ, it assumes that the strings are partial strings, which are separated by means of a separator sign. This separator sign must be entered in the tab when specifying the registry value. For the value type REG_MULTI_SZ, you do not have to specify a separator because this value is a string array.
multi string
Hex(7): 2 hex characters,2 hex characters,...
multi string prepend
Hex(94): The registry value must be expanded by the part specified in sreg.sxp. This part must come first. The source type of this registry value is REG_MULTI_SZ.
multi string append
Hex(95): The registry value must be expanded by the part specified in sreg.sxp. This part must be appended. The source type of this registry value is REG_MULTI_SZ.
string append
Hex(96): The registry value must be expanded by the part specified in sreg.sxp. This part must be appended. The values must be separated by a separator sign. The source type of this registry value is REG_SZ.
string prepend
Hex(97): The registry value must be expanded by the part specified in sreg.sxp. This part must come first. The values must be separated by a separator sign. The source type of this registry value is REG_SZ.
expand string append
Hex(98): The registry value must be expanded by the part specified in sreg.sxp. This part must be appended. The values must be separated by a separator sign. The source type of this registry value is REG_EXPAND_SZ.
expand string prepend
Hex(99): The registry value must be expanded by the part specified in sreg.sxp. This part must come first. The values must be separated by a separator sign. The source type of this registry value is REG_EXPAND_SZ.
(Hex character means a hexadecimal character in the range 0 - F.)
If the value relates to a number of consecutive lines, the previous line is terminated with the character string ,\ (comma and backslash).
If you change any keys on the Expandable Registry Values tab during the reference installation, the following entries will be created:
    • string append
    • string prepend
    • expand string append
    • expand string prepend
Sregdel.sxp Archive File
The sregdel.sxp file specifies registry keys or values that are deleted during the installation of a certain product on a target computer so that these items can be restored as soon as the product is uninstalled from the target computer.
For details and an example of the sregdel.sxp archive file see Structure of the Sregdel.sxp File, Parameters of the Sregdel.sxp Archive File and Example of Sregdel.sxp.
Structure of the Sregdel.sxp Archive File
The structure of the sregdel.sxp archive file is as follows:
RFlag_1
,
Flag_1
,[
Root_Key1
\
Key_1
]
RFlag_11
,
Flag_11
,
Value_name_1
=
Data_1
 or
RFlag_11
,
Flag_11
,
Value_name_1
:
RFlag_1m
,
Flag_1m
,
Value_name_m
=
Data_m
 or
RFlag_1m
,
Flag_1m
,
Value_name_m
:
RFlag_n
,
Flag_n
, [
Root_Key_n
\
Key_n
]
RFlag_n1
,
Flag_n1
,
Value_name_1
=
Data_1
 or
RFlag_n1
,
Flag_n1
,
Value_name_1
:
RFlag_nm
,
Flag_nm
,
Value_name_m
=
Data_m
 or
RFlag_nm
,
Flag_nm
,
Value_name_m
For detailed information and an example see Parameters of the Sregdel.sxp Archive File and Example of Sregdel.sxp.
Parameters of the Sregdel.sxp Archive File
The following parameters apply to sregdel.sxp:
  • RFlag
    Indicates a restore flag
    Default:
     0x00000000
    0x00000010Reference counters are considered. At installation time, the reference counter for this key or value is decreased. The key/value is only deleted, if the reference counter is 0 or does not exist.
    At uninstallation time, the reference counter for this key/value is increased (if it exists).
  • 0x00000020
    The value or key is saved on installation and restored on uninstallation.
    Important! In case of a key just the key name is saved. Any subkeys or values will not be restored unless they are explicitly listed in the sregdel.sxp.
  • 0x00000040
    The value is only restored (using the value saved on installation), if it does not exist during uninstallation. This flag is only valid, if 0x00000020 is also set.
  • Flag
    Indicates a delete flag
    Key n N or D as follows.
N
Deletes key and subkeys if the key and the subkeys are empty.
D
Deletes key, all values in the key, as well as the subkeys. The specified key is deleted completely.
-
Key not deleted; it is just used to specify the following values.
  • Root_key
    Indicates the root key assigned by Windows.
    The following root keys are permitted:
    • HKEY_CLASSES_ROOT
    • HKEY_CURRENT_USER
    • HKEY_LOCAL_MACHINE
    • HKEY_USERS
  • Key_
    n
    Specifies the key, N or D, as follows:
N
Deletes key and subkeys if the key and the subkeys are empty.
D
Deletes key, all values in the key as well as the subkeys.
The specified key is deleted completely.
-
Key not deleted, it is just used to specify the following values.
  • Key
     Specifies a key name in the form SubKey 1\...\SubKey n
  • Value_name_n
    Specifies the delete action, N or X, as follows.
 
N
Deletes key and subkeys if the key and the subkeys are empty.
x
Deletes the substring given through the Data parameter from the registry entry referred to by Value_name. This flag is only applicable to registry entries of type hex(7) and hex(96) to hex(99).
  • Value_name
    Specifies the name of the value. The assignment of the default value for the key is pre-defined as follows:
    @=data
  • Data
     (Only valid if the delete action is specified as X.)
    Specifies the type of data. The following types of data can be specified here:
    multi string
    hex(7): 2 hex characters,2 hex characters,...
    multi string prepend
    hex(94): The registry value must be expanded by the part specified in sreg.sxp. This part must come first. The source type of this registry value is REG_MULTI_SZ.
    multi string append
    hex(95): The registry value must be expanded by the part specified in sreg.sxp. This part must be appended. The source type of this registry value is REG_MULTI_SZ.
    string append
    hex(96): The registry value must be expanded by the part specified in sreg.sxp. This part must be appended. The values must be separated by a separator sign. The source type of this registry value is REG_SZ.
    string prepend
    hex(97): The registry value must be expanded by the part specified in sreg.sxp. This part must come first. The values must be separated by a separator sign. The source type of this registry value is REG_SZ.
    expand string append
    hex(98): The registry value must be expanded by the part specified in sreg.sxp. This part must be appended. The values must be separated by a separator sign. The source type of this registry value is REG_EXPAND_SZ.
    expand string prepend
    hex(99): The registry value must be expanded by the part specified in sreg.sxp. This part must come first. The values must be separated by a separator sign. The source type of this registry value is REG_EXPAND_SZ.
    If the value relates to a number of consecutive lines, the previous line is terminated with the following character sequence: ,\
  • Hex character
     Is a character with values 0 - F
  • Separator
    Indicates a separator character for substrings
Example of Sregdel.sxpKey
Following is an example of an sregdel.sxp archive file:
#Sign#
ArchiveName=ie5
Release=1000
SXP=1.0
0x00000000,N,[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RenameFiles\WordPadAttribSet]
0x00000000,N,"@"
0x00000000,N,"mswd6_32.wpc"
0x00000000,N,"write32.wpc"
....
0x00000000,-,[HKEY_LOCAL_MACHINE\Software\testkey]
0x00000000,N,"MultiStringEntry"=hex(95):"alpha"
0x00000000,N,"StringEntry1"=hex(96), :"beta"
0x00000000,N,"StringEntry2"=hex(96),!:"gamma"
In the last two lines, the character between (96) and
:
 specifies the separator:
    • In the line ending with "beta", it is the BLANK (space).
    • In the line ending with "gamma", it is the exclamation mark (!).
The Packager always sets 95 for multi-string values and 96 for strings. If you want a different setting, you must modify this setting manually.
Uactions.sxp Archive File
The uactions.sxp archive file lets you define programs belonging to a product, which are supposed to run under a certain user. It is possible to run a program only once for a user (at installation or uninstallation time) or regularly at every logon of the user.
The file contains the following sections:
  • These sections refer to programs that are to be run once after installing a product.
  • These sections refer to programs that are to be run at every logon of the user.
  • These sections refer to programs that are to be run once after uninstalling a product.
The structure of the uactions.sxp archive file is described in Structure of the Uactions.sxp File.
Structure of the Uactions.sxp File
The structure of the uactions.sxp archive file is as follows:
#InsUserActions1#
optional
 
:
 
#InsUserActions
n
#
optional
 
 
 
#RepeatUserActions1#
optional
 
:
 
#RepeatUserActions
n
#
optional
 
 
 
#DeiUserActions1#
optional
 
:
 
#DeiUserActions
n
#
optional
 
:
 
:
 
InsUserActions, RepeatUserActions, and DeiUserActions Sections of Uactions.sxp
The InsUserActions, RepeatUserActions, and DeiUserActions sections can have the following entries:
Program_call_1
optional
:
 
Program_call_m
optional
Account1=
AFlag_1
[,
Account_name_1
]
 
:
 
Account
n
=
AFlag_n
[,
Account_name_n
]
 
All programs listed in the sections must be available at the time of execution!
  • Program_call
    Specifies a program path with parameters. Only *.exe, *.com, and *.bat files can be called.
    The sequence is 1-m. Since the path may contain Blanks (spaces), enclose it in quotation marks!
  • AFlag
    Specifies the account flag. AFlag can have one of the values A, G, S, or U.
    All account flags refer to the start of a program. Each group of programs has a group of accounts. For these accounts only, the programs are executed.
  • Account_name
    Indicates the user or group name.
Udirs.sxp Archive File
This archive file contains information on the user-specific directories of a generated product. For all user-specific directories which are being created during reference installation (these are all directories under the home directory of a user or a user profile), the archive file udirs.sxp will be created automatically. The file udirs.sxp may later be edited manually in order to specify which user-specific directory is to be installed for which user.
The default setting is: For all users
The file contains the following sections:
  • The directories listed here are created during installation.
  • These directories are removed during uninstallation if certain conditions are met. Using so-called flags can specify these conditions.
  • These directories and their subdirectories are removed during uninstallation if certain conditions are met. Using so-called flags can specify these conditions.
  • Specifies attribute information for directories to be set during product installation.
For details and an example of the udirs.sxp archive file see Structure of the Udirs.sxp File and Example of Udirs.sxp.
Structure of the Udirs.sxp File
The structure of the udirs.sxp archive file is as follows:
#InsAddDirs1#
optional
optional
:
 
#InsAddDirs
n
#
optional
:
 
#DeiDelDirs1#
optional
optional
:
 
#DeiDelDirs
n
#
optional
:
 
#DeiDelDirsWithSubs1#
optional
optional
:
 
#DeiDelDirsWithSubs
n
#
optional
:
 
#InsSetDirAttr1#
optional
optional
:
 
#InsSetDirAttr
n
#
optional
:
 
 
InsAddDirs Section of Udirs.sxp
The InsAddDirs section can have the following entries:
Directory_path_1
optional
:
 
Directory_path_m
optional
Create1=
AFlag_1
[,
Account_name_1
]
optional
:
 
Create
n
=
AFlag_n
[,
Account_name_n
]
optional
 
 
These directories are created during installation.
  • Directory_path
    Specifies the absolute directory path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory, must be used.
  • AFlag
    Specifies the account flag. AFlag can have one of the values A, G, S, or U. Default setting is Create1=S, Create2=A.
  • Account_name
    Indicates the user or group name.
DeiDelDirs Section of Udirs.sxp
The DeiDelDirs section can have the following entries:
Flag_1
,
Directory_path_1
optional
:
 
Flag_m
,
Directory_path_m
optional
Delete1=
AFlag_1
[,
Account_name_1
]
optional
:
 
Delete
n
=
AFlag_n
[,
Account_name_n
]
optional
 
 
The DeiDelDirs section specifies directories that are removed during uninstallation of the product, if certain conditions are met. These conditions are specified through the Flag parameter.
The recording procedure generates the reference to the DeiDelDirsn section and the flags depending on the uninstallation options specified.
  • Flag
    Specifies the removal of a directory.
    • N
      The directory is deleted only if it does not contain any subdirectories or files.
    • D
      The directory and all its files are deleted only if the directory has no subdirectories.
  • AFlag
    Specifies the account flag. AFlag can have one of the values A, G, S, or U. Default setting is Delete1=S, Delete2=A.
  • Account_name
    Indicates the user or group name.
DeiDelDirsWithSubs Section of Udirs.sxp
The DeiDelDirsWithSubs sections can have the following entries:
Flag_1
,
Directory_path_1
optional
:
 
Flag_m
,
Directory_path_m
optional
Delete1=
AFlag_1
[,
Account_name_1
]
optional
:
 
Delete
n
=
AFlag_n
[,
Account_name_n
]
optional
 
 
The DeiDelDirsWithSubs section specifies directories and their subdirectories that are removed during uninstallation of the product, if certain conditions are met. These conditions are specified through the Flag parameter.
The recording procedure generates the reference to the DeiDelDirsWithSubs section and the flags depending on the uninstallation options specified.
  • Flag
    Specifies the removal of a directory.
    • N
      The directory is deleted only if it does not contain any subdirectories or files.
    • D
      The directory and all its files are deleted only if the directory has no subdirectories.
  • Directory_path
    Specifies the absolute directory path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory, must be used.
  • AFlag
    Specifies the account flag. AFlag can have one of the values A, G, S, or U. Default setting is Delete1=S, Delete2=A.
  • Account_name
    Indicates the user or group name.
InsSetDirAttr Sections of Udirs.sxp
The InsSetDirAttr section can have the following entries:
attribute_1
,
directory_path_1
optional
:
 
attribute_m
,
directory_path_m
optional
Create
1=AFlag_1
[
,Account_name_1
]
optional
:
 
Create
n=AFlag_n
[
,Account_name_n
]
optional
 
 
The InsSetDirAttr section contains file attribute information for directories, which is applied when the product is installed.
  • attribute
    Specifies the File attribute.
    During the reference installation, the Packager automatically records the attribute information for each directory created. Note that only the R (Read-only), H (Hidden), and S (System) file attributes are automatically recorded. For each directory, one entry is generated in the InsSetDirAttr section.
  • Directory_path
    Specifies the absolute directory path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory, must be used.
  • AFlag
    Specifies the account flag. AFlag can have one of the values A, G, S, or U. Default setting is Create1=S, Create2=A.
  • Account_name
    Indicates the user or group name.
Example of Udirs.sxp
Following is an example of a udirs.sxp archive file:
#Sign#
ArchiveName=WinAmp
Release=2600
SXP=1.0

#InsAddDirs1#
$(SxpUsrProgramsDir)\1\Winamp
Create1=S
Create2=A

#DeiDelDirsWithSubs1#
N,$(SxpUsrProgramsDir)\1\Winamp
Delete1=S
Delete2=A
Ufiles.sxp Archive File
This archive file contains information on the user-specific files of a generated product. For every user-specific file that has been created during reference installation (these are all files in the home directory of a user or a user profile) the archive file ufiles.sxp is created automatically. The file ufiles.sxp can be edited manually to specify which user-specific file to install for which user.
The default setting is: For all users
The file contains the following sections:
  • Specifies cmp archive files (*.cmp)
    .
    During product generation, the CMP File ufiles.cmp is generated for user-specific files.
  • Specifies file paths in the CMP File.
  • Specifies product files where parameters can be used. It is possible to use parameters in the files belonging to a product
    . I
    nternal user-specific parameters and parameters for user-specific special folders cannot be used here.
The structure of the ufiles.sxp archive file is described in Structure of the Ufiles.sxp File; an example can be found under Example of Ufiles.sxp.
If you want to change properties of a file, for example, FAT attributes or installation options, edit the CMP file using the built-in CMP Editor.
Structure of the Ufiles.sxp File
The ufiles.sxp archive file has the following structure:
#CmpArchives#
optional
 
#FilesInArchives1#
optional
 
:
 
#FilesInArchives
n
#
optional
 
#ReplaceParams#
optional
 
 
CmpArchives Section of Ufiles.sxp
The CmpArchives section lists the CMP files (*.cmp)
.
During product generation, the CMP File ufiles.cmp is generated for user-specific files.
The CmpArchives section can have the following entries:
Archive_file_name_1
optional
:
 
Archive_file_name_1
optional
  • Archive_file_name
    Specifies the name of the compressed archive file, which must be in the same directory as the product files.
FilesInArchives Sections of Ufiles.sxp
The FilesInArchives section can have the following entries:
OFlag
,
File_path_1
optional
:
 
OFlag
,
File_path_m
optional
Create1=
AFlag_1
[,
Account_name_1
]
optional
:
 
Create
n
=
AFlag_n
[,
Account_name_n
]
optional
  • OFlag
    Specifies a flag that can have the following values or a combination of them:
    0x00000004  File is only to be installed if it does not yet exist.
    0x00000008  File is not to be deleted during uninstallation.
    Example:
    To preserve a user file during reinstall, set this flag to 0x0000000C.
  • File_path
    Specifies the absolute file path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory must be used.
    If you edit the ufiles.cmp file using the CMP Editor, all modified files will be written to the section FilesInArchives in the ufiles.sxp. You must then copy these entries to the corresponding FilesInArchives
    n
     section for each user.
  • AFlag
    Specifies the account flag. AFlag can have one of the values A, G, S, or U. Default setting is Create1=S, Create2=A.
  • Account_name
    Indicates the user or group name.
ReplaceParams Section of Ufiles.sxp
It is possible to use parameters in the files belonging to a product
.
These product files must be entered manually in this section.
The ReplaceParams section can have the following entries:
File_path_1
optional
:
 
File_path_n
optional
 
 
  • File_path
    Specifies the absolute file path. To build this path, the user-specific internal parameters (SxpHomeDir, SxpUsrProgramsDir, SxpProfileAppsDir, and so on), as well as the instance directory must be used.
    If you edit the ufiles.cmp file using the CMP Editor, all modified files will be written to the section FilesInArchives in the ufiles.sxp. You must then copy these entries to the corresponding FilesInArchives
    n
     section for each user.
Example of Ufiles.sxp
Following is an example of a ufiles.sxp archive file:
#Sign#
ArchiveName=UserFile
Release=1001
SXP=1.0

#FilesInArchives1#
0x00000000,$(SxpProfileAppsDir)\1\user.txt
0x00000000,$(SxpWinProgDir)\1\i_sub.dll
Create1=S
Create2=A
0x00000000,$(SxpProfileAppsDir)\2\user.txt
Create1=U,UserTest

#CmpArchives#
ufiles.cmp

#FilesInArchives#
$(SxpProfileAppsDir)\1\user.txt
Uininnnn.sxp Archive Files
The uini
nnnn
.sxp archive files contain information about the user-specific ini files (*.ini)
.
For all user-specific ini files being created during reference installation (these are all ini files under the home directory of a user or a user profile), an archive file uini
nnnn
.sxp is created automatically
.
The file uini
nnnn
.sxp can later be edited manually to specify which user-specific ini file to install for which user.
The default setting is: For all users
If you create uini
nnnn
.sxp files manually or delete automatically created files please note that these files must be numbered in continuous ascending order!
The file contains the following sections:
  • Specifies the file path of the user-specific ini file, which is to be modified.
  • Specifies sections of the ini file that are deleted during installation.
  • (Optional
    .)
    Contain entries of the ini file, which are deleted during installation if certain conditions are met
    .
    Using so-called flags can specify these conditions.
  • (Optional.) Contain entries of the ini file, which are added during installation if certain conditions are met
    .
    Using so-called flags can specify these conditions.
  • Specifies sections of the ini file that are deleted during uninstallation.
  • (Optional
    .)
    Contain entries of the ini file, which are deleted during uninstallation if certain conditions are met
    .
    Using so-called flags can specify these conditions.
  • (Optional
    .)
    Contain entries of the ini file, which are added during uninstallation if certain conditions are met
    .
    Using so-called flags can specify these conditions.
For detailed information about the entries of the uininnnn.sxp archive files see Structure of the Uininnnn.sxp Files.
Structure of the Uininnnn.sxp Files
The structure of the uini
nnnn
.sxp archive files is as follows:
#Info#
 
 
:
 
#InsDelSections1#
optional
optional
:
 
#InsDelSections
n
#
optional
:
 
#InsDelEntries1#
optional
optional
:
 
#InsDelEntries
n
#
optional
:
 
#InsAddEntries1#
optional
optional
:
 
#InsAddEntries
n
#
optional
:
 
#DeiDelSections1#
optional
optional
:
 
#DeiDelSections
n
#
optional
:
 
#DeiDelEntries1#
optional
optional
:
 
#DeiDelEntries
n
#
optional
:
 
#DeiAddEntries1#
optional
optional
:
 
#DeiAddEntries
n
#
optional
:
 
Info Section of the Uininnnn.sxp Files
The Info section has the following entries:
#Info#
Path=File_path
Attributes=Attribute_value
This section specifies the file path and attributes of the user-specific ini file.
InsDelSections Sections of Uininnnn.sxp
The InsDelSections
n
 sections can have the following entries:
#InsDelSections1#
optional
Section_1
optional
:
 
Section_m
optional
Delete1=
AFlag_1
[,
Account_name_1
]
optional
:
 
Delete
n
=
AFlag_n
[,
Account_name_n
]
optional
:
 
The sections specified in the InsDelSections sections are deleted during installation of the product.
  • Account_name
    Indicates the user or group name.
  • AFlag
    Indicates the account flag. AFlag can have one of the following values: A, G, S, U. Default setting is Delete1=S, Delete2=A.
InsDelEntriesn Sections of Uininnnn.sxp Files
The InsDelEntries sections can have the following entries:
#InsDelEntries1#
optional
Flag_1
,
Separator_1
,
Section_1
,
Entry_1
optional
:
 
Flag_m,
Separator_m
,
Section_m
,
Entry_m
optional
Delete1=
AFlag_1
[,
Account_name_1
]
optional
:
 
Delete
n
=
AFlag_n
[,
Account_name_n
]
optional
:
 
  • Flag
    Specifies one of the following flags:
    • N (Normal entry)
      Indicates that this entry of the section will be added or deleted, depending on the context.
    • M (Multiple entry)
      Specifies that all entries matching the entry specification in this section are added or deleted, depending on the context.
    • X (Extended entry)
      Specifies that this entry of the section is modified by adding or deleting (depending on the context) a partial string from the value. The separator marks the partial string.
  • Separator
    Is an arbitrary character, which is valid for an extended entry (flag=X) only, and serves as a separator between the partial strings of (individual) values of an entry. Default is Blank.
    Example: The Separator is the comma (,).run=c:\win\start,c:\winchk\winchk.exe
  • Account_name
    Indicates the user or group name
    .
  • AFlag
    Indicates the account flag. AFlag can have one of the following values: A, G, S, U. Default setting is: Delete1=S, Delete2=A.
InsAddEntriesn Sections of Uininnnn.sxp
The InsAddEntries sections can have the following entries:
#InsAddEntries1#
optional
Flag_1
,
Separator_1
,
Section_1
,
Entry_1
optional
:
 
Flag_m
,
Separator_m
,
Section_m
,
Entry_m
optional
Create1=
AFlag_1
[,
Account_name_1
]
optional
:
 
Create
n
=
AFlag_n
[,
Account_name_n
]
optional
:
 
  • Flag
    Specifies one of the following flags:
    • N (Normal entry)
      Indicates that this entry of the section will be added or deleted, depending on the context.
    • M (Multiple entry)
      Specifies that all entries matching the entry specification in this section are added or deleted, depending on the context.
    • X (Extended entry)
      Specifies that this entry of the section is modified by adding or deleting (depending on the context) a partial string from the value. The separator marks the partial string.
  • Separator
    Is an arbitrary character, which is valid for an extended entry (flag=X) only, and serves as a separator between the partial strings of (individual) values of an entry. Default is Blank.
    Example: The Separator is the comma (,).run=c:\win\start,c:\winchk\winchk.exe
  • Account_name
  • Indicates the user or group name.
  • AFlag
    Indicates the account flag. AFlag can have one of the following values: A, G, S, U. Default setting is Create1=S, Create2=A.
DeiDelSectionsn Sections of Uininnnn.sxp Files
The DeiDelSections sections can have the following entries:
#DeiDelSections1#
optional
Section_1
optional
:
 
Section_m
optional
Delete1=
AFlag_1
[,
Account_name_1
]
optional
:
 
Delete
n
=
AFlag_n
[,
Account_name_n
]
optional
:
 
The sections specified in the DeiDelSections sections are deleted during uninstallation of the product.
  • Account_name
    Indicates the user or group name.
  • AFlag
    Specifies the account flag. AFlag can have one of the following values: A, G, S, U. Default setting is: Delete1=S, Delete2=A.
DeiDelEntries Sections of Uininnnn.sxp Files
The DeiDelEntries sections can have the following entries:
#DeiDelEntries1#
optional
Flag_1
,
Separator_1
,
Section_1
,
Entry_1
optional
 
 
Flag_m
,
Separator_m
,
Section_m
,
Entry_m
optional
Delete1=
AFlag_1
[,
Account_name_1
]
optional
:
 
Delete
n
=
AFlag_n
[,
Account_name_n
]
optional
:
 
  • Flag
    Specifies one of the following flags:
    • N (Normal entry)
      Indicates that this entry of the section will be added or deleted, depending on the context.
    • M (Multiple entry)
      Specifies that all entries matching the entry specification in this section are added or deleted, depending on the context.
    • X (Extended entry)
      Specifies that this entry of the section is modified by adding or deleting (depending on the context) a partial string from the value. The separator marks the partial string.
  • Section
    Specifies the name of section enclosed in square brackets ([ ]).
  • Separator
    Is an arbitrary character, which is valid for an extended entry (flag=X) only, and serves as a separator between the partial strings of (individual) values of an entry. Default is Blank.
    Example: The Separator is the comma (,).run=c:\win\start,c:\winchk\winchk.exe
  • Account_name
    Indicates the user or group name.
  • AFlag
    Specifies the account flag. AFlag can have one of the following values: A, G, S, U. Default setting is: Delete1=S, Delete2=A.
DeiAddEntries Sections of Uininnnn.sxp Files
The DeiAddEntries sections can have the following entries:
#DeiAddEntries1#
optional
Flag_1
,
Separator_1
,
Section_1
,
Entry_1
optional
 
 
Flag_m
,
Separator_m
,
Section_m
,
Entry_m
optional
Create1=
AFlag_1
[,
Account_name_1
]
optional
:
 
Create
n
=
AFlag_n
[,
Account_name_n
]
optional
:
 
The DeiAddEntries sections contain the entries, which are added during uninstallation of the product.
  • Flag
    Specifies one of the following flags:
    • N (Normal entry)
      Indicates that this entry of the section will be added or deleted, depending on the context.
    • M (Multiple entry)
      Specifies that all entries matching the entry specification in this section are added or deleted, depending on the context.
    • X (Extended entry)
      Specifies that this entry of the section is modified by adding or deleting (depending on the context) a partial string from the value. The separator marks the partial string.
  • Section
    Specifies the name of a section enclosed in square brackets ([ ]).
  • Separator
    Is an arbitrary character, which is valid for an extended entry (flag=X) only, and serves as a separator between the partial strings of (individual) values of an entry. Default is Blank.
    Example:
     The Separator is the comma (,).
    run=c:\win\start,c:\winchk\winchk.exe
  • AFlag
    Specifies the account flag. AFlag can have one of the values A, G, S, or U. Default setting is Create1=S, Create2=A.
  • Account_name
    Indicates the user or group name.
Ulinks.sxp Archive File
The ulinks.sxp and links.sxp archive files describe the links (that is, shortcuts) to be installed, modified or deleted within the Windows Explorer. Links that are found in user-specific folders are written to ulinks.sxp. Links that are found in common folders are written into links.sxp.
The file contains the following sections:
  • Specifies links to be added during installation.
  • InsAddWILink
    n
    Reserved for internal use. Do not edit!
  • InsAddWILinkEx
    n
    Reserved for internal use. Do not edit!
  • Specifies links to be changed during installation.
  • Specifies links to be deleted during installation.
  • Specifies links to be added during uninstallation.
  • Specifies links to be changed during uninstallation.
  • Specifies links to be deleted during uninstallation.
These sections are optional and may occur several times each. A section defines a link. The number
n
 is used to distinguish between sections of the same name.
The structure of the ulinks.sxp archive file is described in Structure of the Ulinks.sxp File.
An example can be found under Example of Ulinks.sxp.
Structure of the Ulinks.sxp File
The ulinks.sxp archive file has the following structure:
#InsAddLink1#
optional
 
:
 
#InsAddLink
n
#
optional
 
#InsChgLink1#
optional
 
:
 
#InsChgLink
n
#
optional
 
#InsDelLink1#
optional
 
:
 
#InsDelLink
n
#
optional
 
#DeiAddLink1#
optional
 
:
 
#DeiAddLink
n
#
optional
 
#DeiChgLink1#
optional
 
:
 
#DeiChgLink
n
#
optional
 
#DeiDelLink1#
optional
 
:
 
#DeiDelLink
n
#
optional
 
 
InsAddLink, InsChgLink, DeiAddLink, and DeiChgLink Sections
The InsAddLink, InsChgLink, DeiAddLink
,
 and DeiChgLink sections of the ulinks.sxp archive file can have the following entries:
LnkPath=
Link_name
mandatory
Path=
Program_path
mandatory
Arguments=
Call_arguments
 
Symbol=
Item_path
,
Item_index
 
WorkDir=
Working_directory
 
Description=
Description
 
HotKey=
Hotkey
 
Show=
Display_options
 
Create1=
AFlag_n
[,
Account_name_n
]
mandatory
:
 
Create
n
=
AFlag_n
[,
Account_name_n
]
mandatory
  • LnkPath
    Specifies the complete path of the link file.
  • Path
    Specifies the complete path of the file to which the link file is linked.
  • Arguments
    Lists arguments of the program to which a link is to be established.
  • Symbol
    Specifies item path and index.
  • WorkDir
    Indicates the working directory of the application.
  • Description
    Describes the link.
  • HotKey
    Specifies the Hotkey used for starting the application.
  • Show
    Specifies display options, as follows:
    • 1
      The application starts with the window in its original size and position. The window is activated.
    • 3
      The application starts with the window maximized. The window is activated.
    • 7
      The application starts with the window minimized. The window is not activated.
  • Create
    n
    Indicates users for whom the link is created.
  • AFlag
    Specifies the account flag. AFlag can have one of the values A, G, S, or U. Default setting is Create1=S, Create2=A.
  • Account_name
    Indicates the user or group name.
InsDelLink and DeiDelLink Sections of Ulinks.sxp
The InsDelLink and DeiDelLink sections of the ulinks.sxp archive file must have the following entries:
LnkPath=
Link_name
mandatory
Create1=
AFlag_n
[,
Account_name_n
]
mandatory
:
 
Create
n
=
AFlag_n
[,
Account_name_n
]
mandatory
  • LnkPath
    Specifies the complete path of the link file.
  • Create
    n
    Indicates users for whom the link is created.
  • AFlag
    Specifies the account flag. AFlag can have one of the values A, G, S, or U. Default setting is Create1=S, Create2=A.
  • Account_name
    Indicates the user or group name.
Example of Ulinks.sxp
Following is an example of a ulinks.sxp archive file:
#InsAddLink1#
LnkPath=$(SxpUsrDesktopDir)\WINAMP.LNK
Path=$(SxpWinProgDir)\Winamp\Winamp.exe
Arguments=
Symbol=$(SxpWinProgDir)\Winamp\Winamp.exe,0
WorkDir=
Description=
Hotkey=0
Show=1
Create1=A
Create2=S

#DeiDelLink1#
LnkPath=$(SxpUsrDesktopDir)\WINAMP.LNK
Create1=A
Create2=S
Ureg.sxp Archive File
The ureg.sxp file specifies user-specific modifications to the registry in the HKEY_CURRENT_USER tree. The ureg.sxp file is generated automatically by the reference installation (automatic method.)
The user-specific modifications are performed by the Installer’s logon service while the user is logging on. If the user is already logged on, the modifications are performed immediately after the installation, if the Show parameter is set to 32 in the Installer’s SxpEngxx.ini configuration file.
If the product is valid for and packaged for Windows NT, the following entry in the ureg.sxp file is generated as the default:
Create1=A
This entry specifies that the entries are valid for all users. You can change or extend the Create entries manually.
The ureg.sxp file has the same format as the sreg.sxp file. User-specific information, specified within a key, has been added to this file.
For detailed information about the contents of the ureg.sxp file see Structure of the Ureg.sxp File.
Structure of the Ureg.sxp File
The structure of the ureg.sxp archive file is as follows:
[Root_key_1\Key_1]
Value_name_1=Data_1
:
Value_name_m=Data_m
Create1=
AFlag_1
[,
account_name_1
]
:
Create
n
=
AFlag_n
[,
account_name_n
]
 
  • Root_key
    Specifies the root key determined by Windows. The permitted root key specification is:
    • HKEY_CURRENT_USER
  • Key
    Specifies the name of a key in the following format:
    SubKey_1
    \.....\
    SubKey_n
  • Value_name
    Specifies the name of a value. The assignment of the default value for the key is predefined as follows:
    @Data
  • Data
    The data which is specified at this location in the ureg.sxp file can be of the following types:
 
string
Character string
dword
dword: 8 hex characters
binary
hex: 2 hex characters,2 hex characters,...
expand string
hex(2): character string.
 
The registry values, that are specified in the Expandable Registry Values tab, are interpreted as expandable values. This means, that the Packager only records the expanded part. When the Packager finds the value types REG_SZ and REG_EXPAND_SZ, it assumes that the strings are partial strings, which are separated by means of a separator sign. This separator sign must be entered in the tab when specifying the registry value. For the value type REG_MULTI_SZ, you do not have to specify a separator because this value is a string array.
multi string
Hex(7): 2 hex characters,2 hex characters,...
multi string prepend
Hex(94): The registry value must be expanded by the part specified in ureg.sxp. This part must come first. The source type of this registry value is REG_MULTI_SZ.
multi string append
Hex(95): The registry value must be expanded by the part specified in ureg.sxp. This part must be appended. The source type of this registry value is REG_MULTI_SZ.
string append
Hex(96): The registry value must be expanded by the part specified in ureg.sxp. This part must be appended. The values must be separated by a separator sign. The source type of this registry value is REG_SZ.
string prepend
Hex(97): The registry value must be expanded by the part specified in ureg.sxp. This part must come first. The values must be separated by a separator sign. The source type of this registry value is REG_SZ.
expand string append
Hex(98): The registry value must be expanded by the part specified in ureg.sxp. This part must be appended. The values must be separated by a separator sign. The source type of this registry value is REG_EXPAND_SZ.
expand string prepend
Hex(99): The registry value must be expanded by the part specified in ureg.sxp. This part must come first. The values must be separated by a separator sign. The source type of this registry value is REG_EXPAND_SZ.
 
 
(Hex character means a hexadecimal character in the range 0 - F.)
If the value relates to a number of consecutive lines, the previous line is terminated with the character string ,\ (comma and backslash).
  • Create
    n
    Specifies a user or group the entries are valid for.
  • AFlag
    Specifies the account flag. AFlag can have one of the values A, G, S, or U. Default setting is Create1=S, Create2=A.
  • Account_name
    Indicates the user or group name.
Uregdel.sxp Archive File
The uregdel.sxp file specifies user-specific registry keys or values that are deleted during the installation of a certain product on a target computer.
The archive file uregdel.sxp has the same structure as sregdel.sxp, except that each subkey is followed by one or more Create entries. These Create entries define the accounts for which the registry entry or key is to be deleted. For the description of these Create entries see Ureg.sxp Archive file.
RFlag is ignored, that means that user-specific registry keys and values that have been deleted are not restored during uninstallation.
        For details about the parameters used in uregdel.sxp and an example see Structure of the Uregdel. sxp File and Example of Uregdel.sxp.
Structure of the Uregdel.sxp File
The structure of the uregdel.sxp archive file is as follows:
RFlag_1,Flag_1,[Root_key1\Key_1]
RFlag_11,Flag_11,Value_name_1=Data_1 or
RFlag_11,Flag_11,Value_name_1
:
RFlag_1m,Flag_1m,Value_name_m=Data_m or
RFlag_1m,Flag_1m,Value_name_m
 
Create
1=AFlag_1[,Account_name_1]
:
Create
n=AFlag_n[,Account_name_n]
:
:
RFlag_n,Flag_n,[Root_key_n\Key_n]
RFlag_n1,Flag_n1,Value_name_1=Data_1 or
RFlag_n1,Flag_n1,Value_name_1
:
RFlag_nm,Flag_nm,Value_name_m=Data_m or
RFlag_nm,Flag_nm,Value_name_m
 
Create
1=AFlag_1[,Account_name_1]
:
Create
n=AFlag_n[,Account_name_n]
Parameters of the Uregdel.sxp Archive File
The following parameters apply to uregdel.sxp:
  • RFlag
    Indicates a restore flag
    default:
     0x00000000
    • 0x00000010
      Reference counters are considered. At installation time, the reference counter for this key or value is decreased. The key/value is only deleted, if the reference counter is 0 or does not exist.
      At uninstallation time, the reference counter for this key/value is increased (if it exists).
    • 0x00000020
      The value or key is saved on installation and restored on uninstallation.Important! In case of a key just the key name is saved. Any subkeys or values will not be restored unless they are explicitly listed in the sregdel.sxp.
    • 0x00000040
      The value is only restored (using the value saved on installation), if it does not exist during uninstallation. This flag is only valid, if 0x00000020 is also set.
  • Flag
    Indicates a delete flag
  • Root_key
    Indicates the root key assigned by Windows.
    The following root keys are permitted:
    • HKEY_CLASSES_ROOT
    • HKEY_CURRENT_USER
    • HKEY_LOCAL_MACHINE
    • HKEY_USERS
  • Key_
    n
    Specifies the key, N or D, as follows:
 
N
Deletes key and subkeys if the key and the subkeys are empty.
D
Deletes key, all values in the key as well as the subkeys.
The specified key is deleted completely.
-
Key not deleted, it is just used to specify the following values.
  • Key
    Specifies the key name in the form
    SubKey 1\...\SubKey n
  • Value_name_
    n
     Specifies the delete action, N or X, as follows.
    N
    Deletes registry entry referred to by Value Name
    X
    Deletes the substring given through the Data parameter from the registry entry referred to by Value_name. This flag is only applicable to registry entries of type hex(7) and hex(96) to hex(99).
  • Value_name
     Specifies the name of the value. The assignment of the default value for the key is pre-defined as follows:
    @=data
  • Data
    (Only valid if the delete action is specified as X.)
    Specifies the type of data. The following types of data can be specified here:
    multi string
    hex(7): 2 hex characters,2 hex characters,...
    multi string prepend
    hex(94): The registry value must be expanded by the part specified in sreg.sxp. This part must come first. The source type of this registry value is REG_MULTI_SZ.
    multi string append
    hex(95): The registry value must be expanded by the part specified in sreg.sxp. This part must be appended. The source type of this registry value is REG_MULTI_SZ.
    string append
    hex(96): The registry value must be expanded by the part specified in sreg.sxp. This part must be appended. The values must be separated by a separator sign. The source type of this registry value is REG_SZ.
    string prepend
    hex(97): The registry value must be expanded by the part specified in sreg.sxp. This part must come first. The values must be separated by a separator sign. The source type of this registry value is REG_SZ.
    expand string append
    hex(98): The registry value must be expanded by the part specified in sreg.sxp. This part must be appended. The values must be separated by a separator sign. The source type of this registry value is REG_EXPAND_SZ.
    expand string prepend
    hex(99): The registry value must be expanded by the part specified in sreg.sxp. This part must come first. The values must be separated by a separator sign. The source type of this registry value is REG_EXPAND_SZ.
  • Hex character
     Is a character with values 0 - F
  • Separator
    Indicates a separator character for substrings
  • Create
    n
    Specifies for which operating environment the product entries are valid. If the product is permitted for Windows NT/2000/XP, the following entry is generated as the default:
    Create1=A
    This entry specifies that the entries are valid for all users.
    You can change or extend the Create
    n
     entries manually.
Example of Uregdel.sxp
Following is an example of a uregdel.sxp archive file:
#Sign#
ArchiveName=regtest
Release=1002
SXP=1.0
0x00000000,N,HKEY_CURRENT_USER\\Network\\H
0x00000000,N,"RemotePath"
0x00000000,N,"UserName"
0x00000000,N,"ProviderName"
0x00000000,N,"ProviderType"
0x00000000,N,"ConnectionType"
Create1=S
Create2=A
0x00000000,-,HKEY_CURRENT_USER\\Software\\TestKey
0x00000000,N,"ustr"=hex(96),,:"two"
0x00000000,N,"uMultiStr"hex(95):"before"
Create1=S
Create2=A
Other Archive Files
Unlike the .sxp archive files, other archive files are files that belong to a version of a product but do not need a structure specified by the Packager. These files can be text or binary files.
They are located directly in the version directory or in one of the subdirectories. The Packager provides an editor for text files, which is the same one used to edit the general archive files.
These other archive files include the scripts that accompany the version or the original files of a product to be installed with its original setup on the target computer.
Desktop.sxp Archive File
The desktop.sxp file is obsolete!
For detailed information about the contents of the desktop.sxp archive file see Structure of the Desktop.sxp File.
Sign Section of an SXP Archive File
Each SXP archive file starts with the Sign section, which contains general information about the archive file. The Sign section is generated automatically. This section is not displayed by the archive file editor and must not be changed.
If an SXP archive file is copied from another product or another version, it will be adapted to the name and version of the current product when it is registered to the Software Package Library.
The structure of the Sign section and the possible entries are as follows:
#Sign#
mandatory
ArchiveName=
Archive_name
 
Release=
Archive_version
 
SXP=
File_format_version
 
  • ArchiveName
    Specifies the name of the SXP package. This name will appear in the Packager's product archive. The archive name can consist of 32 bytes.
  • Release
    Specifies the version of the SXP package. This version number will appear in the Packager's product archive. Archive_version is a value in the range 1000 - 9999.
  • SXP
    Specifies the version of the SXP archive file format. Currently only version 1.0 is available.
Example of a Sign section:
#Sign#
ArchiveName=40agent
Release=1000
SXP=1.0
Edit Client Parameters
You can add, delete, or edit client parameters using the Client Parameters dialog which opens when you select Edit, Client Parameters from the Packager main menu. You can modify the defaults to create specific values for all computers, PC groups, and individual PCs. The parameters you define, including their values, types, and ranges, are stored in the Parameter archive.
To install client parameters on a target computer, you must package the parameter files, independently of any product you have packaged. The packaged parameter files are called a parameter product.
The parameters, their values, types, and ranges are stored in the following files:
  • default.ini -- Contains the general defaults for the PCs and PC groups
  • group.ini -- Stores the parameters for any PC groups that contain deviations from the defaults in the default.ini file
  • pc.ini -- Contains the parameter deviations between each PC and its PC group
    • tree.ini -- Contains the assignment of PCs to PC groups
Client Parameters Archive Tree
The Client Parameters archive tree mirrors the structure of the parameter archive. The parameter archive consists of all defined client parameters. Client parameters can be inserted, deleted, or modified at root level. The value range of a parameter and the preset value are defined here.
The groups of PCs are located at the next level, as are the PCs that do not belong to any group. The groups and PCs automatically inherit all of the client parameters at root level, including their defaults. The inherited parameter values can be modified individually at this level for a group or a PC.
In conclusion, the last level contains the PCs that are allocated to a group. All PCs in a group automatically inherit the parameters with the group values. The value of a parameter for an individual PC can be set differently than for a group.
If an object is selected in the Client Parameters archive tree (in a group, a PC, or the default object), the parameters for this object are displayed in the right pane of the Client Parameters window.
You close the Client Parameters window by clicking the smaller Close button (in the second row) in the upper right corner.
Client Parameters
The client parameters of the objects selected in the Client Parameters archive tree are shown in the right pane of the Client Parameters window.
The following list describes the buttons that display in front of each client parameter:
  • Icon for default parameter value
    This parameter has the default value.
  • Icon for a group-specific parameter value
    The value of this parameter is set individually for the group.
  • Icon for a PC-specific parameter value
    The value of this parameter is set individually for the PC.
Follow these steps:
  1. Right-click in the Client Parameters window and select Add Parameter, Edit Parameter, Delete Parameter or Create Parameter from the context menu.
    A dialog appears.
  2. Enter parameter values.
  3. Select appropriate action to complete.
You close the Client Parameters window by clicking the smaller Close button (in the second row) in the upper right corner.
Add Parameter
You can add a parameter by entering its name and type. We recommend that you assign the parameter name on a product-specific basis. For example, do not specify InsDir, but ProductA.InsDir. Such naming conventions allow you to distinguish between the individual parameters, and reduce the risk of a parameter being overwritten by a parameter with the same (simple) name.
  • Parameter name
    Specifies the unique name for the parameter.
  • Parameter type
    Specifies the type of the parameter. The following types of parameters are supported:
    • Numeric
    • Alphanumeric
    • Selection list
      The list contains a range of alphanumeric parameter values.
When you click OK on this dialog, further parameter type-specific dialogs open where you enter the definitions for the parameter.
All groups and PCs in the archive automatically accept the added parameters with their default values.
Edit the Definition for a Numeric Parameter
This dialog lets you modify the description, the default value, and the minimum and maximum value for the selected numeric parameter.
To change either of these values, overwrite the content of the appropriate input field and click OK.
Only integers are allowed as numeric values.
These modifications can be evaluated only at the root level of the client parameters archive tree (Default).
If the default value of a parameter is changed, the modification automatically affects the groups and PCs that have accepted this parameter, including its default.
Edit the Definition for an Alphanumeric Parameter
This dialog lets you modify the description, the default value, and the maximum length, that is, the maximum number of characters, for the selected alphanumeric parameter.
To change either of these values, overwrite the content of the appropriate input field. After you have completed your changes, and click OK.
These modifications can be evaluated only at the root level of the client parameters archive tree (Default).
If the default value of a parameter is changed, the modification automatically affects the groups and PCs that have accepted this parameter, including its default.
Edit the Definition for a Selection List
This dialog lets you add, change, or remove elements from the selection list, or change the default value for the selection list.
These modifications can be performed only at the root level of the client parameters archive tree (Default).
If the default value of a parameter is changed, the modification automatically affects the groups and PCs that have accepted this parameter, including its default.
To change the description of the parameter, overwrite the contents of the Description field.
To add a value to the selection list
  1. Enter the desired value in the one-line input field in the List elements area.
  2. Click Add.
To change an existing value of the selection list
  1. Select the element in the List elements area.
  2. Click Edit.
    The selected value appears in the one-line input field in the List elements area.
  3. Edit the value.
  4. Click Change.
To change the default value for the selection list
  1. Select a value other than the current default value in the List elements area.
  2. Click Set to default.
    The selected value appears in the Default value field.
To remove an existing element from the selection list
  1. Select the element in the List elements area.
  2. Click Remove.
After clicking OK, the new settings are displayed in the Client Parameters window. The selection list is shown as a comma-separated list in the Range column.
If an element of the selection list contains a comma (,), this comma is preceded by a doublequote in the Range column.
Convert into MSI
Converts the selected SXP product version into an MSI product (for the Microsoft Installer).
Check Parameters
To ensure that all external parameters used in a package can be resolved during installation, a set of these parameters together with their default values is part of the product package. The external parameters can be resolved even if they are not defined through any parameter product installed on the target computer.
Check Parameters scans the archive files of the selected SXP product version and creates the file sxpparam.ini, which contains all external parameters used. The default values for these parameters are automatically fetched from the current parameter archive. If a parameter has not been defined yet, the SXP default values dialog pops up to edit undefined parameters.
The Check Parameters function is automatically executed when a product is registered.
Check Properties
This function, available from the Packager's Tools menu, checks a selected MSI product for undefined properties. If at least one undefined property is found, an MSI property editor is started to set properties.
Create Directory
You can create subdirectories in the current version directory or in another subdirectory.
Follow these steps:
  1. Enter the name of the subdirectory in the input field
  2. Click Create.
Product archive
The Packager manages the software products in the product archive. When you start the Packager, the product archive window appears. The product archive is organized on a hierarchical basis and is represented by an archive tree. The location of the archive tree home directory is configurable.
Product Archive Window
When no product version has yet been created, the Packager immediately offers the Create Product Version dialog box after being started. The archive tree window is empty, except for the Archive icon.
If the product archive already contains products, and you want to create a new product version, select File, Create Product Version from the Packager main menu.
The created objects can be edited and displayed in the Product archive window. These objects include the following:
  • Products
    Open a product by double-clicking its icon in the archive tree window.
  • Versions
    Open a version by double-clicking its icon in the archive tree window.
  • Subdirectories of the version directory (optional)
    Open the subdirectory of a version directory by double-clicking its icon in the archive tree window.
  • Archive files
    Open an archive file by double-clicking its icon in the archive file window.
Context menus display when you right-click any of the folders (Archive, product, version, or subdirectory) in the product archive tree.
Product Archive Tree
The product archive tree mirrors the structure of the product archive. The product names are located at the first level of the tree.
The Packager can manage several versions of a product. For every version an individual version directory is created in the product directory. This version directory contains the archive files for that version.
Further subdirectories may be created for a version directory, or a subdirectory.
You can choose if only SXP products, only MSI products, or all products should be displayed in the product archive tree, Select the appropriate option under View in the Packager main menu.
Information on Root Directories
For the selected product version, you can edit information on the root directories, which is stored in the RootDirs section of the Info.sxp archive file.
An example for an entry line is:
SxpRootDir1=$(LocalMSOfficePath)
Information on Product Dependencies
For the selected product version, you can edit information on internal and external product dependencies, which is stored in the InternalDependence and ExternalDependence sections of the Info.sxp archive file.
Description of the Product
Created by
Indicates the name of the person who packaged the product.
  • Creation date
    Indicates the date when the product was created.
  • Created on
    Indicates the operating system on which the product was packaged.
  • Created with
    Indicates the Packager version used to package the product.
  • Descriptive text
    Provides a text area where you can write and edit any descriptive text and comments for the selected product version. This text is stored in the Description section of the Info.sxp archive file. The first 127 bytes are used as comment in the SXP Product Explorer.
If you want to describe any used parameter avoid using the form: $(
parameter
). If you use this form, the Installer automatically replaces the parameter string. We recommend to use either $$(
parameter
) or substitute the Dollar sign ($), for example, with the Section sign (§), and type: §(
parameter
).
Minimum Set of Properties in an MSI Package
The minimum set of properties created for converted MSI packages is listed in the following table. Some of the properties are reserved and must not be modified.
Property
Description
ProductLanguage
Specifies the language the Installer should use for any strings in the user interface that are not authored into the database. This property must be a numeric language identifier (LANGID).
Manufacturer
Indicates the name of the manufacturer for the product. It is advertised as a product property. It is initialized with the Created By value of the info.sxp.
ARPHELPLINK
Indicates the Internet address for technical support. Product maintenance applets display this value.
PROMPTROLLBACKCOST
Specifies the action the installer takes if rollback installation capabilities are enabled and there is insufficient disk space to complete the installation:
D = Disable rollback and continue without asking user.
F = Fail with the out-of-disk-space error prompt.
REBOOTPROMPT
If set to Suppress (or S) specifies that any reboot performed by the Windows Installer happens automatically without interaction from the user. Setting this property does not initiate a reboot if one is not needed; it only suppresses the display of any prompts for reboots to the user.
_SXPROOTDIR1
:
_SXPROOTDIR
n
Generates an associated property for each SxpRootDir
n
 listed in info.sxp.
ProductCode
reserved
ProductName
reserved
ProductVersion
reserved
ARPSYSTEMCOMPONENT
reserved
INSTALLLEVEL
reserved
ARPNOREMOVE
reserved
SxpMsiUSName
reserved
Is only created if a user-specific subpackage exists.
Manual Supplements to the Automatic Method
The automatic method creates most of the SXP archive files for a product, and the majority of required entries in those archive files, automatically. However, some features of the Packager and Installer can be used only if you create entries manually in the appropriate SXP archive files, after you generate the initial product. You can open and edit the archive files from the product archive window.
The following list contains a general description of the entries that you can create manually. More detailed information can be found in the descriptions of the individual SXP archive files.
  • Dependencies between Archive Products
    The dependencies discussed here do not apply to updates (delta versions) or predecessors.
    You must specify the dependency of an archive product on another archive product in the info.sxp file. There are two types of dependencies:
    • Internal Dependency
      The product to be installed requires, that one or more other products must already be installed on the same target computer.
    • External Dependency
      The product to be installed requires, that one or more other products are already installed on another computer.
  • Pre- and Post-install tasks
    To use the functions of pre- and post-install tasks, you must manually create the actions.sxp file. To create this file, right-click an empty place in the archive file window, in the Product archive. Choose the Create archive file option, and select actions.sxp from the displayed list of archive files.
    To add the pre-and post-install tasks to the product, right-click an empty place in the archive file window, in the Product archive. Choose the Import archive file option, and browse for the file to import. See Importing Archive Files.
  • Modifying ASCII Files using Scripts
    When you use the automatic method of packaging, the Packager creates an asc
    nnnn
    .sxp archive file for each ASCII file that was specially labeled during the configuration of the reference system, if the installation causes any changes in this file.
    In addition, the Packager creates two scripts (asc
    nnnn
    .ins and asc
    nnnn
    .dei) to modify the ASCII file during the installation or removal of the product. Such scripts are created for each ASCII file specified during configuration of the reference system ASCII files tab), except for the autoexec.bat and config.sys files. These files are treated differently, as described in Structure of the Ascnnnn.sxp Archive File.
    By default, all these modifications are appended to the ASCII file on the target computer.
    When you use the manual method, you can manually create and fill in an SXP archive file, such as asc
    nnnn
    .sxp as follows. Right-click an empty place in the archive file window, in the Product archive. Choose the Create archive file option, and select the desired file from the displayed list of archive files. For important instructions, see asc
    nnnn
    .sxp.
  • User- and Group-specific Entries for Registry, Desktop, Files and Directories
    When you are using the automatic method, and a product makes user- or group-specific entries in the registry, modifies the desktop, or adds user-specific files and directories, the following SXP Archive files are created automatically:
    ureg.sxp, ulinks.sxp, ufiles.sxp, udirs.sxp, and uininnnn.sxp.
    Default entries are created in these files, allowing the product to be accessed by all target computer users. To restrict one or more users from accessing the product, you must edit these files manually after the product has been packaged.
  • User- and Group-specific Entries for Access Rights
    If you want to restrict the access rights for files and directories (NTFS only) or Registry keys for specific users or groups, you must manually create and fill in the permis.sxp archive file.
  • Using Parameters
    To specify values used for only a specific target computer or group of target computers, such as the product root directory, you can use parameters to specify variables for entries in all archive files.
    Normally, you enter parameters manually in SXP archive files and scripts. However, you can also use parameters in other archive files within .cmp files, and in actions. If you do so, you must specify the path name of the file in the ReplaceParams section of the files.sxp or actions.sxp archive file. See How Client Parameters are Stored.
    If you want to use environment variables, you need to reference them using the syntax as follows:
    $(%environment_variable%)
    You can also use registry entries, as described in Using Client Parameters to Access System-specific Registry Values.
Reference System
When you install a product using the automatic method of packaging, several changes are made to the reference system on the Packaging Computer: that is, to its file system, installed services, and registry. The Packager checks for and records all changes made to the reference system. Normally, you configure the reference system once before packaging the first product. This protects the reference system from unwanted changes when a product is packaged. It also increases the efficiency of the packaging process.
You must account for the following factors when you configure the reference system:
  • Performance
    The greater the volume of data in the reference system the longer the time required to check for changes. Therefore, it can be useful to exclude certain drives from the checking process.
  • Changes that do not directly affect the installed product
    The reference system itself causes modifications to the file system during the creation of products when it generates SXP archive files. These changes must be excluded when you use the automatic method.
  • Overwriting of system files
    To maintain the consistency of the reference system, you can create backups of system files. If, for example, a product includes another version of a system DLL (for example, if the original DLL is overwritten during the installation of the product), it must be possible to restore this DLL after the product has been installed and the package has been created; otherwise, the reference system will have been permanently modified. If the backed up files are to be permanently replaced later, you can do so through the Backup System Files dialog.
  • Partial modification of ASCII files
    If partial changes are made to existing ASCII files on the Packaging Computer during product packaging, only these partial changes are reproduced in the ASCII file of the same name when the product is installed on the target computer.
    These ASCII files must be identified so that the reference system can treat them differently. Otherwise, the complete ASCII file (including the modifications) is added to the product by default and the existing ASCII file of the same name on the target computer is completely replaced. The path names of the ASCII files to be monitored by the Packager for partial changes, are entered on the ASCII files tab of the Configure reference system dialog. You can specify nonexisting ASCII files.
Importing Archive Files
The Importing Archive Files dialog lets you select existing archive files that you want to import into the current version directory or subdirectory.
You have the following options:
  • Import an entire directory; if the Recursively option is selected, all subdirectories are also imported.
  • Import individual files from the directory specified in the left pane by selecting the files (and deselecting all others) in the right pane of this dialog, or by defining a suitable filter in the Filter box.
Packager archives
With the Packager you create and manage archive files of the software products and parameters to install on target computers. The Packager includes two types of archives:
Recording of FAT File Attributes
When packaging a product, the Packager automatically records the FAT file attributes for all files and directories of the product. The FAT file attributes include:
    • System (S)
    • Hidden (H)
    • Read-only (R), .
You can modify directory attributes by editing the dirs.sxp or udirs.sxp archive file.
The file attributes System (S), Hidden (H), and Read-only (R) can be modified by editing the files.sxp archive file, using the CMP Editor.
Files and directories are not recorded, if only their attributes have been changed.
List of RIAD Alias Values
Only a subset of these accounts may exist on a single system.
For a detailed description of the terms used refer to the Microsoft MSDN documentation.
  • Administrator
    A user account for the system administrator. This account is the first account created during operating system installation. The account cannot be deleted or locked out. It is a member of the Administrators group and cannot be removed from that group. Note that the local administrator of a system that is part of a Windows domain can be addressed by the expression.
    \$(%COMPUTERNAME%)\Administrator
  • Guest
    A user account for people who do not have individual accounts. This user account does not require a password. By default, the Guest account is disabled. Note that the local guest account of a system that is part of a Windows domain can be addressed by the expression
    \$(%COMPUTERNAME%)\Guest
  • Domain Admins
    A global group whose members are authorized to administer the Windows domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined a domain, including the domain controllers. Domain Admins is the default owner of any object that is created in the domain's Active Directory by any member of the group. If members of the group create other objects, such as files, the default owner is the Administrators group.
  • Domain Users
    A global group that, by default, includes all user accounts in a Windows domain. When you create a user account in a domain, it is added to this group automatically.
  • Domain Guests
    A global group that, by default, has only one member, the Windows domain's built-in Guest account.
  • Schema Admins
    A group that exists only in the root domain of an Active Directory forest of Windows domains. It is a universal group if the domain is in native mode, a global group if the domain is in mixed mode. The group is authorized to make schema changes in Active Directory. By default, the only member of the group is the Administrator account for the forest root domain.
  • Enterprise Admins
    A group that exists only in the root domain of an Active Directory forest of Windows domains. It is a universal group if the domain is in native mode, a global group if the domain is in mixed mode. The group is authorized to make forest-wide changes in Active Directory, such as adding child domains. By default, the only member of the group is the Administrator account for the forest root domain.
  • Policy Admins
    A global group that is authorized to create new Group Policy objects in Active Directory. By default, the only member of the group is Administrator. The default owner of a new Group Policy object is usually the user who created it. If the user is a member of Administrators or Domain Admins, all objects created by the user are owned by the group. Owners have full control of the objects they own.
List of SIAD Alias Values
For a detailed description of the terms used, refer to the Microsoft MSDN documentation.
  • Everyone
    A group that includes all users, even anonymous users and guests. Membership is controlled by the operating system.
  • Creator Owner
    A placeholder in an inheritable access control entry (ACE). When the ACE is inherited, the system replaces this SID with the SID for the object's current owner.
  • Creator Group
    A placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the primary group of the object's current owner. The primary group is used only by the POSIX subsystem.
  • Creator Owner Server
    SID not used in Windows 2000.
  • Creator Group Server
    SID not used in Windows 2000.
  • Dialup
    A group that implicitly includes all users who are logged on to the system through a dial-up connection. Membership is controlled by the operating system.
  • Network
    A group that implicitly includes all users who are logged on through a network connection. Membership is controlled by the operating system.
  • Batch
    A group that implicitly includes all users who have logged on through a batch queue facility such as task scheduler jobs. Membership is controlled by the operating system.
  • Interactive
    A group that includes all users who have logged on interactively. Membership is controlled by the operating system.
  • Service
    A group that includes all security principals that have logged on as a service. Membership is controlled by the operating system.
  • Anonymous
    A user who has logged on anonymously.
  • Proxy
    SID not used in Windows 2000.
  • Self
    A placeholder in an ACE on a user, group, or computer object in Active Directory. When you grant permissions to Principal Self, you grant them to the security principal represented by the object. During an access check, the operating system replaces the SID for Principal Self with the SID for the security principal represented by the object.
  • Authenticated Users
    A group that includes all users whose identities were authenticated when they logged on. Membership is controlled by the operating system.
  • Terminal Server Users
    A group that includes all users who have logged on to a Terminal Services server. Membership is controlled by the operating system.
  • Local System
    A service account that is used by the operating system.
  • Administrators
    A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a Windows domain, the Domain Admins group is added to the Administrators group. When a manager becomes a domain controller, the Enterprise Admins group also is added to the Administrators group. The Administrators group has built-in capabilties that give its members full control over the system. The group is the default owner of any object that is created by a member of the group.
  • Users
    A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group. When a computer joins a Windows domain, the Domain Users group is added to the Users group on the computer. Users can perform tasks such as running applications, using local and network printers, shutting down the computer, and locking the computer. Users can install applications that only they are allowed to use if the installation program of the application supports per-user installation.
  • Guests
    A built-in group. By default, the only member is the Guest account. The Guests group allows occasional or one-time users to log on with limited privileges to a computer's built-in Guest account.
  • Power Users
    A built-in group. By default, the group has no members. This group does not exist on domain controllers. Power Users can create local users and groups; modify and delete accounts that they have created; and remove users from the Power Users, Users, and Guests groups. Power Users also can install most applications; create, manage, and delete local printers; and create and delete file shares.
  • Account Operators
    A built-in group that exists only on domain controllers. By default, the group has no members. By default, Account Operators have permission to create, modify, and delete accounts for users, groups, and computers in all containers and organizational units (OUs) of Active Directory except the Builtin container and the Domain Controllers OU. Account Operators do not have permission to modify the Administrators and Domain Admins groups, nor do they have permission to modify the accounts for members of those groups.
  • Server Operators
    A built-in group that exists only on domain controllers. By default, the group has no members. Server Operators can log on to a manager interactively; create and delete network shares; start and stop services; back up and restore files; format the hard disk of the computer; and shut down the computer.
  • Print Operators
    A built-in group that exists only on domain controllers. By default, the only member is the Domain Users group. Print Operators can manage printers and document queues.
  • Backup Operators
    A built-in group. By default, the group has no members. Backup Operators can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators also can log on to the computer and shut it down.
  • Replicators
    Not used in Windows 2000. In Windows NT domains, it is a built-in group used by the File Replication service on domain controllers
Product Version Information
When you select a product version in the archive tree window, information about the version is shown in the upper-right pane of the product archive.
Create Templates for Archive Files Dialog
When you are packaging a product using the manual method, the Create Templates for Archive Files dialog asks you to select the SXP archive files to create. For a detailed description of each file, see SXP archive files. For the ascnnnn.sxp, ininnnn.sxp and uininnnn.sxp files you can specify the number of files to create.
When you click Continue, the archive files are created and are displayed in the archive files window.
Installing a Version
The actual reference installation begins now, which means that all changes to the reference system performed while this dialog is active are recorded in the packaged product.
When you are installing an MSI product during the reference installation, you must ensure that all features (and their subfeatures) of the MSI product are completely installed and stored on the hard disk of the Packaging Computer. Advertised features cannot be captured by the Packager. Use the install option "Complete" when installing the MSI product, or, if you use the "Custom" install option to select single features to install, choose the Run all from My Computer installation method for each feature selected. No feature must be installed with the Installed on First Use option!.
During installation, you may be requested to log off and on again or to reboot the system. Such requests appear only if certain changes are performed on the system during installation. If you must log off or reboot, the loader module automatically re-starts the Packager at the point where it was stopped.
The Using the Software dialog appears if you click Continue, after you finish installing the product using the automatic method.
Using the Software
The Using the Software dialog displays when you use the automatic method (Custom or Standard mode), and click Continue from the Installing Software dialog.
The Using the Software dialog prompts you to start and stop the software programs you have just installed once before the reference system creates the archive files. (Many applications create their entries in the registry only when they are started for the first time.) If these registry entries are not recorded now with the reference installation, they cannot be deleted later when the product is removed on the target computer.
Before you record the changes made by the programs at the initial startup, you must start and close the software programs you have just installed.
Before you click Continue to start recording, you can make additional changes to the product you are installing. Optionally, you can:
  • Add or delete files and directories or modify the reference system manually.
  • Insert parameters in product-specific files (as desccribed under Manual Supplements to the Automatic Method). You can also specify these supplements later after you finish the packaging process.
When you are ready to record the installation data, click Continue.
When the Analyzing System process is finished, and you are using the Automatic Method in the Custom mode, the List of File System Changes dialog appears.
Analyzing System
The Analyzing System dialog appears while the Packager compares the last saved system state (before the reference installation) with the current system state (after the reference installation). The differences between these two states make up the data from which the SXP archive files are created. Analyzing the system can take several minutes.
Install Previously Created Products
When you use the automatic method (custom mode) the Install Previously Created Products dialog appears. This dialog allows you to install the previously archived products, which are required to create the combined or delta product on your reference system.
If you select an archived version of a delta product, the Packager automatically installs all required files, including the version you selected and the product on which it is based.
  • Account for Dependencies Before Installing the Archived Version
    Select the desired version from the list on this dialog, and then click the Install button. You can install any of the versions listed; however, before continuing, you must account for any dependencies of the version on any other products that may or may not be included in the list. For example, if the version you want to install requires a software product named XYZ 5000 as an installation prerequisite, before continuing you must make sure XYZ 5000 is installed on your Packaging Computer.
    During this installation of the archive version, you may be asked to log off and on again or to restart the computer if changes have been made to the system. In such situations, the Packager ensures that when the system restarts, you can resume the packaging process exactly where you stopped.
    The actions.sxp, original.sxp and permis.sxp archive files are not evaluated during installation of an archive version. The pre- and post-install tasks are not executed, and the installation is not performed using the original setup program.
  • Resolving Parameters of Previously Archived Products
    When previously archived products are installed, their parameters are evaluated. Parameterized installation paths are installed under the SxpCuDir directory if the parameters cannot be evaluated. For example, the $(ProductXRoot) parameter is not resolved, rather the product X is installed under the SxpCuDir\$(ProductXRoot) directory on the reference system. Consequently, the newly installed archive product may not be able to run on the Packaging Computer.
    If it is required that the archived product be able to run on the Packaging Computer, do one of the following:
    • Install a product package that does not have parameters.
    • Specify the required parameters in the [Admin] section of the param.ini file in the Packager installation directory. This specification ensures that the parameters will be resolved and replaced as required during the packaging process.
  • Finishing
    After all archived products are installed, the Product Type dialog appears, prompting you to choose to create either a delta product or a combined product.
Product Type
When you are using the automatic method (Custom mode), the Product Type dialog appears after all archived products have been installed from the Install Previously Created Products dialog. This dialog prompts you to choose to create a delta product or a combined product.
When archived products are installed with the automatic method, manual entries in the SXP archive files of the archived products must be re-applied to the product being packaged. Such manual entries include details of user rights, pre- and post-install tasks, and any other changes made with a text editor.
  • Saving System State (Delta Products Only)
    When creating a delta product, the Packager backs up the configured reference system (all files and configuration data) a second time, so that only the differences from this second backup are used later for creating the SXP archive files. During this time, the system displays the processing status message, Saving system state.
If you are packaging a delta product, review the following section, Considerations for Delta Products Only, before completing that dialog.
  • Considerations for Delta Products Only
    Carefully consider the following points before completing the Information about the Version dialog:
    • If you are packaging a delta product, you must enter the version number of the predecessor on this dialog. Four zeros (0000) for the predecessor version number specify a (complete) product.
    • A delta product is not required to have a predecessor. A product can be considered a delta product because it has dependencies, that is, the product is packaged with dependencies on other products included by the reference installation. Therefore, you must manually enter these dependencies in the InternalDependence section of the info.sxp file.
Align Product Version
Align Product Version resets all headers of the SXP archive files for the specified version, to the name and version of the current product, in case the SXP files were copied from another product, or the headers were modified manually.
Align Product Version also checks, whether SXP files start with binary data, which has to be removed.
Delete a Product or Version
Using the Delete Product/Version dialog from the Packager's File menu you delete the selected product or version of a product, including all archive files.
If you click the Delete button, the selected product or version is immediately removed from the product archive. All related versions of the product are also deleted.
Selecting Special Folders
Folders available for selection are listed in the left-hand pane of the Special folder selection dialog. Special folders already selected are displayed in the right-hand pane.
Select a folder and use the two-arrow buttons (>> or <<) to move the folders between available folders and special folders.
See: Parameters for System-specific Special Folders and Parameters for User-specific Special Folders
Backup System Files
The Backup System Files dialog updates system files on the Packaging Computer.
By creating backups of specific system files, the reference system is protected against permanent changes resulting from the installation of products. However, if you want to permanently replace a backed up system file with a new version, for example, after installing a service pack, you can update the reference system by using the Backup System Files dialog.
Select File, Backup System Files, and click Backup to create backup.
Searching for a Registry Key
Lets you browse for registry keys. A green folder symbol indicates those registry keys that are already specified on the Keys to Scan tab. A yellow folder symbol indicates those registry keys that are available for selection.
Follow these steps:
  1. Select a registry key
  2. Click OK
    The selected key appears in the Key field on the Keys to scan tab.
  3. Click Add
The registry key is added to the scan area.
Product Version
Create
Opens the Create Product Version dialog.
Delete
Opens the Delete Product/Version dialog.
Format
Enables you to select a font for editing in the archive files. This menu item is only available when an archive file is selected.
Change to Next Archive File
Switches to the next open archive file in the editor, or returns to the product archive window if there are no more archive files available.
Searching for a path
To specify a path in the file system, follow these steps:
  1. Select the desired directory in the file system tree
  2. Click OK
Searching for a file
To specify a file in the file system, follow these steps:
  1. In the left pane, select the directory where the file is located.
  2. In the right pane, select the file. You can select more than one file, or define a filter. In this case, all files in the directory that match the filter are selected.
Edit the Value of a Parameter
This dialog lets you modify the value of a parameter individually for the group or PC object selected in the Client Parameters archive tree. You can choose a new value from within the specified range of values.
If desired, you can reset the parameter to its default value, or to the group value if you are editing a PC parameter.
Group-Specific modification of client parameter values
This function sets the value of a client parameter for the selected group of target computers.
The new value applies to all PCs in the group that have not had a PC-specific value assigned for this parameter.
Add and Delete a Group
When you create a new group of target computers in the Client Parameters archive, it automatically inherits all client parameters and their default values from the default group. You can change any of those values, within the permitted range of values, by editing the parameters at group level.
Follow these steps:
  1. Click Default and select Edit, Group, Add from the menu bar to add a group.
  2. Enter the name of the new group in the field provided and click OK.
  3. Select a group in the client parameters archive tree and select Edit, Group, Delete from the menu bar to delete a group.
  4. Click OK.
Add and Delete a PC Object
For each target computer that will have unique parameter values you must create a PC object for the computer in the Client Parameters archive tree.
You can create the PC object directly beneath the root of the archive tree, or in a specific group in the Client Parameters archive. In the first case, the PC object inherits all client parameters with the default values. In the second case, the PC object inherits all client parameters with the values set for the specific group.
Follow these steps:
  1. Click Default, or the desired group object in the Client Parameters archive, and select Edit, PC, Add from the menu bar.
  2. Enter the name of the new PC in the field provided, and click OK.
  3. Click the PC in the Client Parameters archive, and select Edit, PC, Delete from the menu bar.
  4. Click OK.
PC-Specific modification of client parameter values
This function sets the value of a client parameter for the selected target computer only.
Specify Client Parameter Archive
Opens the Parameter Archive dialog.
Specify Client Parameter Product Name
Opens the Create Parameter Product dialog.
Parameter Archive
The Parameter Archive dialog lets you specify the path of the parameter archive.
Follow these steps:
  1. Click Browse
    Another window opens.
  2. Specify an existing path in the file system, or enter a path name in the input field.
    If you enter the name of a directory that does not exist, it is created.
Specify Property Values
In the Property column all properties are listed in alphabetical order. All parameters of the SXP product are taken over as properties. Note that the SXPROOTDIR parameter is displayed with a leading underscore.
The Value column displays the current default values of the parameters. These default values are used to install the MSI product on the target computer. In the case you have installed a parameter product on the target computer before, the values of the parameter product are of higher priority, and will overwrite these default property values.
To edit a property value, double-click it. Edit the desired property values, and click OK.
Specify Parameter Default Values
In order to ensure that all external parameters used in a package can be resolved during installation, even if they are not defined through any parameter product installed on the target computer, a set of these parameters together with their default values is part of the SXP product. The Check Parameters function detects undefined external parameters.
All currently undefined external parameters are listed.
To edit the default value, double-click the value of the parameter. Double-clicking the name of the parameter starts the editor, with the file where the parameter has been found first. The parameter type is Alphanumeric.
Packager Scripts
Packager scripts contain statements for modifying text files. Generally, scripts are executed when the product is installed or removed.
Scripts are used to adapt SXP products for specific target computers. In the scripts, parameters can be used as placeholders for target computer-specific values. The Installer replaces these parameters with the client-specific values before applying the script to a text file.
For an SXP product, you can specify names of scripts in the ScriptFiles sections of the two archive files, original.sxp and asc
nnnn
.sxp.
  • original.sxp
    A product to be installed unattended on the target computer, using the original setup function, must have a response file. You can create a script to adapt the response file to the target computer, for example, to set the installation path of the product in the response file to a value valid for this PC.
    If you use a script, you must specify the response file on which the script is to work in the ResponseFiles section of the original.sxp file.
  • asc
    nnnn
    .sxp
    When a product is being installed, the script specified in the ScriptFiles section of asc
    nnnn
    .sxp will be executed on the text file specified in the Info section of the same
    ascnnnn
    .sxp archive file.
    Similarly, you can specify a script for removing the product. The text file on which the script is executed can be either a file that accompanies the product, or a file that already exists on the target computer. Thus, scripts can also be used to modify existing text files, and consequently to prepare the target computer for the installation of a product.
A script can be contained in a product and distributed with it. However, you can also share a script for two or more products, and modify the script independently of any product.
Edit Archive Files
An internal archive file editor lets you modify or change contents of the archive file. We strongly recommend that you use this internal editor when editing archive files. Manually editing archive files is necessary when you are creating archive files using the manual method of packaging.
The editor presents the archive file in sections. Therefore, select the section you want to edit from the drop-down list box.
  • CmpArchives
    Lists all compressed archive files of the product in the Contents field. When you double-click one of the .cmp files listed, the CMP Editor opens this file and modifies its contents.
  • FilesInArchives
    Lists all files in all archive files of the product.
  • InsDelFiles
    Lets you enter file names that should be deleted during product installation.
  • ReplaceParams
    Lets you enter names of files where parameters are replaced during product installation.
Most SXP archive files are automatically created by the automatic method of packaging. Therefore, it makes no sense to edit all SXP archive files. For further information, see Manual supplements to automatic method.
Delete Archive Files
With the exception of info.sxp, all archive files in the archive file window can be deleted.
Follow these steps:
  1. Open Archive files window of the Packager main window:
  2. Right-click the archive file icon to delete, and select Delete archive file from the context menu.
  3. Confirm the deletion when prompted.
Create a Product Version
Follow these steps:
  1. In the Product archive tree window, click the Archive heading, click the Create Product Version icon SXP Packager GUI icon for Create new product version in the toolbar.
    The Create Product Version dialog opens.
  2. Enter the name and the version number of the new product.
  3. For the name, you can enter a maximum of 32 characters. The version number is a four-digit decimal number.
  4. (Optional) To create the product by the automatic method, check Standard mode (minimal user interaction), or Custom mode and Use reference installation.
  5. (Optional) To create the product by the manual method, check Custom mode and Create templates to be edited manually.
  6. If you choose Custom mode and Use reference installation, you can click the Configure Reference System button to display the Configure Reference System dialog.
  7. Click Continue.
To create a new version for an existing product
  1. In the Product archive tree window, select the product, click the Create Product Version icon SXP Packager GUI icon for Create new product version in the toolbar.
    The Create Product Version dialog opens.
  2. By default, the subsequent version number of the product displays in the Create Product Version dialog. Alternatively, you can enter another version number greater than each of the existing version numbers of the product.
  3. (Optional) If you want to create the product by the automatic method, check Standard mode (minimal user interaction), or Custom mode and Use reference installation.
  4. (Optional) If you want to create the product by the manual method, check Custom mode and Create templates to be edited manually.
  5. If you choose Custom mode and Use reference installation, you can click the Configure Reference System button to display the Configure Reference System dialog.
  6. Click Continue.
Configure Reference System Button
Clicking the Configure Reference System button displays the Configure Reference System dialog, which lets you view the current configuration of the monitored reference system and make any changes. This is your last opportunity to change the reference system for the product being packaged.
The reference system is not relevant when you use the manual method since you must manually enter all required data in the SXP archive files. The manual method is primarily intended for products that are to be installed on the target computer using their original setup program. However, the manual method can be used for all products, which means that you can even use the manual method to package products that have already been packaged with the automatic method. Note that you still need to manually enter all required data in the SXP archive files, however.
Backup System Files
If you use the Packager to create a product for the first time, the Packager automatically updates the reference system and displays the Backup System Files message.
This process can take several minutes, depending on the processing speed and the amount of files on the computer. In the course of this update, all files belonging to the clean reference system are backed up to enable the Packager to restore the computer's original state after an automatic package recording.
The files to be saved are listed in the Backup files tab. This process must be re-initiated when the reference system has changed permanently; for example, by applying Service Packs.
Account Flags
All account flags relate to the creation of items like a key, shortcut, folder, or value.
Possible values of an account flag (AFlag) are as follows:
  • A (All)
    (Windows NT Technology only)
    The item is valid for all users. An account name is not specified.
  • C (Common)
    (Windows NT Technology only)
    The itemis valid for all users (desktops). An account name does not need to be specified. In contrast to the All flag, the shortcuts and folders are stored on the common desktop and not on the user desktop. The C flag is set by default when you use the automatic method.
  • G (Group)
    (Windows NT Technology only)
    The itemis valid for all desktop users who belong to the group specified by the Account Name parameter. The account name must be specified.
  • S (Single)
    (Windows 9x/Me only)
    There is only one desktop user for whom the item is valid. No account name needs to be specified. The reference installation sets the S flag as default.
  • U (User)
    (Windows NT Technology only)
    The item is valid for the user specified by the Account Name parameter. The account name must be specified.
File Attributes
A file attribute is a hexadecimal value of the format 0x
nnnnnnnn
. The value may be combined from multiple attributes from the list below.
0x00000001 FAT file attribute Read-only (R).
0x00000002 FAT file attribute Hidden (H)
0x00000004 FAT file attribute System (S)
0x00000020 FAT file attribute Archive
0x00000080 FAT file attribute Normal
0x00000100 File attribute Temporary
0x00002000 File attribute Not content indexed (Windows 2000 NTFS)
Example: File attribute 0x00000005
This is the sum of the file attributes "System" (0x00000004) and "Read-only" (0x00000001)
Instance Directory
To be able to work with different instances of a file (that is, several files having the same name but different contents), the absolute file paths entered in the ufiles.sxp, ufiles.cmp, and udirs.sxp archive files are extended by a so-called instance directory:
The Packager's recording procedure defines a recorded user-specific file to be the first instance of this file. The absolute path of this file then gets the subdirectory 1 assigned.
Example illustrating the creation of an instance directory by the recording procedure:
SxpHomeDir:
D:\USERS\HUGO
Recorded user-specific file:
D:\USERS\HUGO\dictionaries\german.dic
Resulting file path in ufiles.sxp, ufiles.cmp, udirs.sxp:
$(SxpHomeDir)\1\dictionaries\german.dic
Packaging Programs that Write Hardware Configuration Data
Some software programs write hardware configuration data into the binary files of the application. Generally, this information cannot be modified on the target computer.
If you are going to package such a program, choose one of the following options:
  • Package the program on a reference system with the same hardware configuration as the target computer.
  • Use the manual method of packaging.
Archives on the Packaging Computer
The Packaging Computer is a separate computer system, on which the Software Packager for Windows is installed. The Packaging Computer must be a Windows NT Technology computer.
Only the following software must be installed on the Packaging Computer:
  • Operating system.
  • Software Packager software.
When you install the Packager software, a special API component is automatically installed on the Packaging Computer, to enable communication between the Packager and the manager system.
The Packager uses two archives located on the Packaging Computer:
  • Product Archive
    The product archive is used to store and manage packaged products. The product archive is organized hierarchically, and is mapped to a directory tree. The product directories are located at the first level. The Packager is able to manage several versions of a product. For each product version a subdirectory is created in the product directory. This subdirectory is called the version directory.
    The archive files are stored in the SXP format and define the interface between the Packager and Installer components. The archive files consist of:
    • Compressed product files
    • Installation, removal, and configuration specifications for a product version
    • All other files to be distributed with the version, such as scripts or the original product files, which can be installed in unattended mode with their original setup.
  • Parameter Archive
    On the Packaging Computer, all client parameters are stored in several .ini files collectively called the parameter archive. The information in the .ini files is mirrored in the objects on the Parameter archive window, where you create and modify parameters by creating and editing the objects on that window. On the target computer the parameters are stored in the param.ini file.
The Software Delivery agent functionality is not installed on the Packaging Computer.
Software Management Features
Software Management enables you to install, configure and remove software throughout a complex environment in a controlled and standardized way, and to maintain large infrastructures. Networks with various Windows PCs and Windows NT Technology servers are optimally integrated and offer special features such as:
  • Unattended installation and removal of products.
  • Easy administration, delivery, and maintenance of different archive versions: products, delta products and combined products.
  • Defining installation requirements.
  • Preparing software for registration and installation, quickly and easily, by using the automatic method of packaging.
  • Reducing transmission costs through single transfer of volume data, that is the packaged software, from the Packaging Computer to the manager system during registration.
  • Custom installations of software packages on PCs running Windows NT Technology, even when users are logged off.
  • Defining PC and group configurations to best match your software distribution needs.
  • Automatical reset of the computer to its previous system state in the case of faulty installations on a target computer.
  • Users created retrospectively on a Windows NT Technology computer (after the computer has been receiving and installing packages) automatically receive all software products intended for the group to which the users belong.
Create Parameter Product
When you have defined all desired client parameters, you create a parameter product to register and distribute the current parameter files. After you create the parameter product, you must register it in the Software Package Library on the manager or scalability server to which your Packaging Computer is connected.
Follow these steps:
  1. Enter the desired name and version of the parameter product
  2. Click OK.
Product Distribution
Any product must be registered in the software package library on a manager before you can distribute it to target computers.
Products registered in the software package library on an enterprise manager can be distributed to computer groups only, while products registered in the software package library on a domain manager can be distributed to both computer groups and individual target computers.
If your Packaging Computer is coupled to an enterprise manager, this procedure of sending packages from the enterprise manager to the domain manager lets you distribute install and uninstall orders to individual target computers. If permitted by your site standards, you can couple your Packaging Computer to the appropriate domain manager rather than the enterprise manager.
Automatic Method
In this packaging mode, the Packager on the dedicated Packaging Computer will be used to monitor changes applied to the packaging system by either running a setup or manual changes. The detected changes will be packaged as a software package in the SXP format.
To retain the integrity of the packaging system and to preserve the identical environment for all subsequent recordings the Packager takes care to roll back applied changes after the package creation. For the file system, this is performed by removing added files and restoring changed files by use of a set of backup files. This set of backup files is created the first time the Packager is started based on the settings listed under Backup Files. This set is also called Ground.
If the menu item Update Reference System is used, the creation of the backup set is also initiated. Depending on the amount of data to be saved, and the performance of the system, this step may take 10 to 20 minutes.
The Packager cannot access files that are locked by programs. Log files are typical items of this category. To avoid unnecessary messages concerning locked files, the Packager will add those identified files automatically to an ignore list. These files will no longer be monitored for changes.
After the backup set has been created, an initial state of the file system is recorded. This means, that information like file size, creation date, directory contents, INI files, links, and so on, is put aside. This recorded first system state is the reference for subsequent installs.
Since a system restart will change some file dates, and create new log files or add performance data, we recommend to boot the system once the first system state has been created. The next time the Packager is used in for reference installation, the current system state is compared to the first system state, and any interim changes are automatically added to the list of ignored files. The members of this list are ignored for package creation, because this is dynamic data and independent of the monitored setup. These changes are also not rolled back.
When changes have been applied to the settings, which describe the monitored reference system, the affected components of the first system state are recreated again.
When an SXP package is going to be created, a product name and version has to be chosen first. Next the system will compare the current state and the saved first system state. Any interim changes are added to the list of ignored files. The current state of the registry is recorded and saved.
Now the setup program, which shall be monitored, can be launched. Setup will apply all necessary changes to the system. Additionally, the user can modify the system. Special care has to be taken to start and use the program. This will create additional files and registry entries, or launch new services.
When continuing the packaging process, the new system state is compared to the saved first system state. Identified changes will become part of the new package, and the compressed archive is created. Based on the package contents the changes to the packaging system are rolled back. If needed, system files are replaced with saved copies from the backup set. Because some restore procedures can be carried out during system restart only, the Packager may notify about the need to restart the system.
Files that could not be added to the backup set of saved system files are listed in:
\PackagerInstallDirectory\ground\FilesNotInGround.log
Files that could not be added to the product's archives are listed in:
\PackagerInstallDirectory\files.log
\PackagerInstallDirectory\ufiles.log
Files that could not be restored to the previous state because they are not in a backup set are listed in:
\PackagerInstallDirectory\restore.log
Most Important Changes in the Packager Behavior
Setting: "Paths to exclude" is no longer observed for backup set Ground.
First system state is now recorded only once, or on demand, instead of every time.
Locked files are now excluded automatically, instead of manually.
Files changed during end of last recording and new recording are excluded automatically, avoiding locked file situations.
Even excluded paths are monitored for changes and restored. Formerly, accidentally changes were not detected nor cured.
All ignored files are displayed on the Paths to exclude tab. These entries are grayed out, and cannot be edited.
Parameters in SXP Packages
A parameter is a variable in archive files and scripts. The Installer replaces these variables with target computer-specific values when the product is installed.
Parameters can be used to standardize target computers, such as a consultant workstation or a point-of-sale system, or to replace computer parameters, such as an IP address or a host name. To enter and manage parameters, use the Product Archive window on the Packager GUI.
Each SXP package generated with the Software Management Packager contains a file, sxpparam.ini, which contains default values for all external (client) parameters used in the product. This ensures that the product can be installed without any parameter product being installed on the target computer before.
Parameter Files in SXP Packages
Parameter files contain external parameters (client parameters). Parameter files are also known as .ini files. Parameter files that have been packaged are called a parameter product.
The following parameter files are currently used in SXP packages:
  • default.ini
    Contains the general defaults for all PC groups and individual PCs. In the [default] section of this file, all client parameters are entered, along with their type, default value, range of values, and description. There are three types of parameters: numeric, alphanumeric, and selection list.
  • group.ini
    Stores the parameters for any PC groups that deviate from the defaults in the default.ini file. Each section in this file has the same name as the PC group to which its parameters apply.
  • pc.ini
    Contains the parameter deviations between each PC and the PC group to which it belongs.
  • tree.ini
    Contains the assignment of individual PCs to PC groups. This file includes a section named for each group. The section includes the names of all PCs in the group.