The version number in the package ini file is purely documentary. It is not used by AppAgent, AppAssign or the RM Management Console.
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):
This will, however, cause an immediate reboot. There is no mechanism for requesting a deferred reboot.
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.)
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.
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.
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:
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.