Printable View
Can anybody enlighten me on how a CC3 package goes together? I haven't found anything on previous posts or the wiki, but if I've missed something my apologies.
I've had a nose around and I know I need an ini file in the package directory, but I can't find any definitive list of what should be in it.
Cheers.
Hi
The info on cc3 package files us at: -
Log In
CC4 uses xml file and not got anything in detail on that yet..
Russ
Ah, I don't have an RM login, that's the problem I've hit :(
I can probably obtain one, but if anyone's got anything outside of it that would be easier...
Get a login (let me know if need help with that) but for know will post it here don't think RM will mind ;)
Quote:
his article is for background information only and does not specify a supported interface to Community Connect 3™ and RM Smart-Tools 3. Features described here may be modified or withdrawn in later releases.
Important
There are very few occasions when there is any need to modify the contents of a package INI file. In particular, you should never modify the INI file for a package created by RM unless specifically advised to do so by an RM support engineer. You are strongly advised to read the whole of this article before attempting to make use of the information provided here.
For specific examples of amending package INI entries please refer to the relevant articles in the Other Useful Articles section below.
The package INI file
Each package has an associated package INI file, located in the same folder at the server as the MSI or installation EXE for the package. The name of the package as listed in the RM Management Console is actually the name of the INI file.
The package INI file potentially contains a number of sections of which the only one used by RM AppAgent is the [Package] section.
There are now some 20 possible entries in the [Package] section of which most are optional. Some entries are applicable only to certain types of package. All the entries are described below.
Compulsory entries for all packages
OS
The only compulsory entry for all packages is the OS entry that specifies which operating system(s) the package is suitable for. Currently this entry may specify one of the following:
5.WS - suitable for Microsoft® Windows® 2000 Pro or Microsoft® Windows® XP Pro.
5.1WS - suitable only for Windows® XP Pro. (any Service pack).
5.1.1WS - suitable for Windows® XP Pro SP1 only.
5.1.2WS - suitable for Windows® XP Pro SP2 only.
Entries for a Windows Installer package
WIPackage
This entry is compulsory for a Windows Installer package. It specifies the name of the MSI file for the package (which is assumed to be in the same folder as the package INI file). It is the presence of this entry which marks the package as being a Windows Installer package.
All other entries are optional for this type of package. A minimal INI file for a Windows Installer package would thus have the form:
[Package]
OS=5.WS
WIPackage=Information Magic.msi
WITransform
This entry is optional and is used only during install operations. If present it supplies the name of the MSI transform file (which is assumed to be in the same folder as the package INI file).
Logging
If this entry is present, it sets the level of MSI logging to be carried out for operations (install or remove) involving this package. Valid values (case insensitive) are "Yes" and "Verbose" with any other value being interpreted as "None". The log file used, if logging is enabled, will be C:\Program Files\Research Machines\Network Management\AppAgent\MSI.LOG. This file is cumulative and may be deleted when no longer required.
MsiUiLevel
If this entry is present it controls the level of user interface to be displayed during installation or removal by the MSI itself. If the entry is not present a default value will be read from the registry (normally set to "None"). Valid values (case insensitive) for this entry are:
"ProgressOnly"
"None"
"Basic"
"Reduced"
"Full"
"NoneEnd"
"BasicEnd"
"ReducedEnd"
"FullEnd"
Any other value will result in a default to "None"
AddCommand
If provided, this entry will provide a set of default parameters for an INSTALL operation. Before use an entry "ALLUSERS=1" will be added unless "ALLUSERS" is already specified, "REBOOT=SUPPRESS" will be added unless a "REBOOT" command is already specified and, if a transform file was specified, "TRANSFORM=transformfile" will be added.
Note that this entry cannot be used for setting msiexec.exe command line switches. It serves only to set MSI properties.
UninstallCommand
If provided this entry will provide a set of default parameters for a REMOVE operation. Before use a "REMOVE=ALL" entry will be added and a "REBOOT=SUPPRESS" entry will be added unless a "REBOOT" command is already specified.
Entries for an EXE package
EXEFile
This entry is compulsory for an EXE package and specifies the name of the EXE to be used when installing the package and, unless there is an UninstallEXEFile entry, removing the package. The file specified is assumed to be in the same folder as the package INI file.
Note that if a WIPackage entry is also present this will take precedence and the package will be treated as a Windows Installer package.
UninstallEXEFile
This entry is optional and specifies the EXE file to be used during package removal. If this entry is not present then the EXEFile entry will be used instead. If the entry specifies simply a filename (ie contains no backslashes) then the file is assumed to be in the same server folder as the package INI file.
If the entry does contain a backslash, however, then it is assumed to be a full path to an EXE on the workstation. The entry can contain environment substitution strings such as %ProgramFiles% and any such strings will be expanded. This permits uninstallation to be performed by a custom EXE installed with the product.
ProcessReturnCode
The return code from an EXE may or may not be meaningful. For an InstallShield-generated Setup EXE it is, but for some other types of EXE it probably will not be.
By default RM AppAgent will assume that the return code from an EXE is meaningful and should be acted upon. However, if an UninstallEXEFile entry is also present, the default is to ignore return codes from both EXEs and assume success. These defaults can, however, be over-ridden by providing a "ProcessReturnCode" entry. If the value is present and set to True (case insensitive) the return code will be treated as valid, if it is set to False the return code will be treated as invalid. Any other value will be ignored.
AddCommand
As for a Windows Installer package, this specifies the command line parameters to be used when installing the package. Unlike the Windows Installer case however, the value will be used unmodified and may specify any arguments or switches whatsoever that the executable accepts.
UninstallCommand
As for a Windows Installer package, this specifies the command line parameters to be used when removing a package. Unlike a Windows Installer package however the value will be used unmodified.
Other Entries (both types of package)
Description
An optional string describing the package. This will be visible in the RM Management Console when the package is selected for allocation or deallocation.
Here the rest..
RussQuote:
Version
The version number in the package ini file is purely documentary. It is not used by AppAgent, AppAssign or the RM Management Console.
Reboots
This optional parameter should have a numeric value, with values of 0 or less having no effect. It indicates the number of reboots that must be performed (at some stage) to complete installation of the package. After successful execution of the MSI or EXE which performs the installation, the value will be compared with the number of reboots already requested by any previous package and the larger value adopted. If no subsequent package forces an immediate reboot on installation, these reboots will be performed at the very end of the installation sequence.
If an immediate reboot is forced, whether by this or a subsequent package, and whether by an MSI itself or through the use of the ImmediateReboot entry (see below), the count of outstanding reboots is immediately decremented by 1. If, upon re-starting, AppAgent finds this count to be still > 1, additional reboots are performed immediately. (This is a rare occurrence; historically, only one package (VCDROM) has required multiple reboots and this no longer does so.)
This parameter is only significant on installation. To request a reboot after uninstallation, the following entry may be used (for Windows Installer packages only):
UninstallCommand=REBOOT=FORCE
This will, however, cause an immediate reboot. There is no mechanism for requesting a deferred reboot.
RebootDelay
This optional parameter specifies a delay (in seconds) which should be inserted immediately before the second and subsequent reboots specified by the Reboots parameter. (Again, as no package is currently known to require > 1 reboot, this value will rarely be used.)
ImmediateReboot
This optional parameter, if set to any value greater than 0, will cause AppAgent to trigger an immediate reboot after installing the package, provided the MSI or EXE which performs the installation reports success. It may be used in conjunction with the Reboots parameter but using "Reboots=1" would not alter the behaviour since the count would immediately be decremented to zero and a single, immediate reboot would ensue in any case.
This parameter is only significant on installation. To request an immediate reboot after uninstallation, an UninstallCommand entry may be used (for Windows Installer packages only) as described above.
WriteAccess
Specifies an alternate name for the WriteAccess.ini file. This must have a .ini extension. This is useful where multiple packages are to be placed in the same subfolder of the RMPackages share (because they have significant files in common). If these packages have differing security exemption needs, their WriteAccess files can be uniquely named by this means.
Note: This entry is optional if the default name is used, ie specifying "WriteAccess=WriteAccess.ini" is not required.
OrigIniPath
From Service Release 4, package INI files may be cached locally on workstations to improve performance. In cached files only the OrigIniPath entry will be found to contain the UNC path to the server folder from which the file was copied. This allows AppAgent to locate the associated MSI or EXE easily. Note:This entry must not be created or modified by hand.
Package ordering (both types of package)
Prior to Service Release 3, the installation order for packages was as follows:
All RM System packages ('Tools') are installed before any Applications.
Within either Tools or Applications, uninstalls are processed first, followed by upgrades (an uninstall followed by an immediate install of a newer version), and finally installs.
HFXCC3035 (included in Service Release 4) added two new mechanisms to help to control the install phase for both Tools and Applications. These are not intended to provide a full solution for managing package ordering and interdependency, they are just some basic facilities. They must be used very circumspectly as there are a number of pitfalls for the unwary. Note:Be sure to read the Pitfalls and Limitations section below before modifying package INI files.
Both mechanisms are governed by entries in the [Package] section of the INI file. The entries are case-insensitive and white-space insensitive.
First mechanism: To express a specific dependency of one package upon others, or an incompatibility with others, an entry of the following form may be used:
Dependencies= Pack1, Pack2, NOT Pack3
where ',' is interpreted as Boolean AND. Package names must be specified exactly as they appear in the RM Management Console. This example specifies that the package requires both Pack1 and Pack2 but is incompatible with Pack3.
When a dependency is not satisfied, the status of the package will appear as "NOT_INSTALLED (DEPENDENCY)" in the station INI file and in the RM Management Console. When the required package is subsequently installed, the dependent package must be reallocated, ie it will not automatically be installed.
Second mechanism: To install a package before or after all (or most) others using the Dependencies mechanism would be very cumbersome. Instead use one of the following entries:
InstallGroup=Early
InstallGroup=Late
If neither entry is specified, the package is placed in a default "middle" group.
These two mechanisms can be employed independently or jointly. For example, multiple packages may be placed in the Early group with the very first to be installed being determined by the interdependencies within that group.
Both mechanisms are subordinate to the overall ordering of Tools before Applications and, within that, of ordering by uninstall, update, install. In summary, the order of package installation is now controlled by the following factors, in order of precedence:
Tools precede Applications.
Uninstall precedes Update which precedes Install.
Within the Install phase only, Early group precedes unspecified group which precedes Late group.
Inter-package dependencies within a group.
Pitfalls and limitations
Beware of creating circular dependencies, eg A depends on B, B on C and C on A, which will prevent any of A, B or C ever being installed.
Note that a summary of unsatisfied dependencies appears in the workstation logfile generated by AppAgent:
C:\Program Files\Research Machines\Network Management\Logfiles\InstallRMerrNN.html
which can aid in the diagnosis of such situations.
Where used together, inconsistencies can arise between the two mechanisms. For example, suppose Pack1 is made dependent on Pack2 but Pack1 is in the Early group and Pack2 in a later group. No attempt will be made to resolve this situation and Pack1 will not be installed. It will then be necessary to re-assign Pack1 using the RM Management Console and reboot the workstation. Pack1 will now be installed (assuming Pack2 was successfully installed last time).
For similar reasons, do not make a Tool (RM System package) dependent on an Application package.
Deallocating a package on which another package depends will not automatically deallocate the dependent package which will therefore remain installed but broken.
Remember that some packages are also dependent on the OS version (including Service Pack) of the target computer. In general, avoid making a package with few OS constraints (eg OS=5.WS) dependent on one with tight constraints (eg OS=5.1.2WS).
There is no support for Boolean OR in the Dependencies mechanism, ie it is not possible to make a package dependent on either A or B.
The RM AppAgent progress bar may appear to jump multiple steps where dependency failures occur.
In conclusion, it will be seen that liberal use of these mechanisms can soon create a complex web of interdependencies, resulting in installation failures which are difficult to unravel. It is strongly recommended that these features be used sparingly. Only use the InstallGroup= or Dependencies= settings to modify the relevant packages appropriately if it has been proven that package dependency is the issue. Note: You should not unnecessarily set package dependencies and should keep records of any changes made.
How excellent, cheers
(I'll bar the door now, in case they come looking for the missing article.)