The following examples illustrate some uses of system variables:
Specifying Paths and Filenames in Actions: When you create an Edit INI File action, for example, you specify a .ini file and configure the changes to be performed on that file. During the creation process, you can specify the full path to the file (for example, C:\Program Files\OpenOffice.org 2.0\program\setup.ini).
Instead of specifying the entire path and filename, you can create a system variable. For example, the name of the variable can be OpenOffice INI and the value can be the full path to the file. Now, instead of specifying the full path and filename when you create the action, you can type ${OpenOffice INI} in the field.
An advantage of using a system variable rather than typing the full path and filename is that you can specify this particular .ini file in many different types of actions. Suppose that the location of the .ini file changes. Instead of editing the path in each action, you can edit the path in the system variable and all the actions still point to the correct path.
You can generalize the path even more by creating a system variable named ProgramFiles with the value of C:\program files. In the future, when you specify a path, you can type ${ProgramFiles} and then specify the remaining path to the specific file. For example, ${ProgramFiles}\OpenOffice 2.0\program\setup.ini. Again, if the path to the C:\program files directory changes in the future, you only need to change the path in the system variable, rather than in each bundle that uses that location in a path.
Overriding Inherited Settings: When configuring system variables for a folder, device, or bundle, you can override an inherited variable by defining a new variable with the same name but a different value. For example, if ProgramFiles=C:\ is defined at the Management Zone, you can override it by defining ProgramFiles=D:\ at the device folder level or at the device or bundle.
You can use a system variable when creating a bundle. Depending on the location of the targeted device object in the folder hierarchy, the value can be different.
For example, suppose that all of your applications are installed in C:\program files except for specific applications used by the accounting department, which are installed in D:\program files. You define the ProgramFiles variable at the Management Zone level to point to C:\program files. For the accounting applications, you create a device folder called Accounting Department to contain the devices in the accounting department. You can set the value for the ProgramFiles variable to D:\program files on the Accounting Department device folder level. When the same bundle is applied to devices, the path to the program files directory is on the C:\ drive for all targeted devices except for those contained in the Accounting Department device folder. For those devices, the program files directory points to the D:\ drive.