System Variables

The System Variables panel lets you define variables that can be used to replace paths, names, and so forth as you enter information.

You can define system variables at three levels:

The following table lists the tasks you can perform to manage the system variables:

Task

Steps

Additional Details

Add a variable

  1. If you are configuring system variables for an object (not for the entire Management Zone), click Override settings to activate the System Variables panel.

  2. Click Add, provide the name and value for the variable, then click OK.

  3. Click Apply.

When configuring system variables for an object, you can override an inherited variable by defining a new variable with the same name but a different value. For example, if Var1=c:\ is inherited, you can override it by defining Var1=d:\.

Variable names cannot include spaces and must be unique at the level where they are defined. For example, you cannot have two variables named Var1 defined at the device level (unless one is inherited, in which case the device level variable overrides the inherited variable).

Variable values cannot include the characters & and <.

Remove a variable

  1. Select the check box next to the variable (or variables).

  2. Click Remove.

  3. Click Apply.

 

Edit a variable

  1. Select the check box next to the variable.

  2. Click Edit.

  3. Modify the Name and Value fields as desired, then click OK.

  4. Click Apply.

Variable names cannot include spaces and must be unique at the level where they are defined. For example, you cannot have two variables named Var1 defined at the device level (unless one is inherited, in which case the device level variable overrides the inherited variable).

Variable values cannot include the characters & and <.

Use a variable

  1. Use the following syntax:

    ${VAR_NAME}

    Replace VAR_NAME with the name of the variable.

 

Using System Variables

The following examples illustrate a few 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 could create a system variable. For example, the name of the variable could be “OpenOffice INI” and the value could be the full path to the file. Now, instead of specifying the full path and filename when you are creating the action, you could type ${OpenOffice INI} in the Filename field.

An advantage of using a system variable rather than typing the full path and filename is that you could 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 would still point to the correct path.

You could 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 an object (folder, device, 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 could use a system variable when creating one bundle, and depending on the location of the targeted device object in the folder hierarchy, the value could 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 could define the “ProgramFiles” variable at the Management Zone level to point to C:\program files. For the accounting applications, you could create a device folder, called Accounting Department, to contain the devices in the accounting department. You could 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 would be 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 would point to the D:\ drive.

For trademark and copyright information, see Legal Notices.