Product Documentation

Managing Isolation Environment Rules

Dec 17, 2015

The Offline Plug-in uses isolation environments to control application compatibility and accessibility. The Plug-in creates isolation environments by defining a set of rules that specify how an application functions within its confines. The default rules for isolation environments are adequate for most environments. However, alter the default set of rules, as needed, to exert control over application interactions with operating system resources on the user device.

A rule for an isolation environment is based on a specific location: either a file path or a registry key path.

Rules are matched by the most specific path to the resource being accessed. A rule applies to the object (file, registry, or named object) specified and all the children of the specified object, unless a more specific rule exists.

Types of Isolation Environment Rules

Use isolation environment rules to improve application compatibility when users stream applications to their user devices. Rules can reduce conflicts between the streamed application and other locally installed, hosted, or streamed applications.

Choose from isolate, strictly isolate, ignore, and redirect rules, as needed.

Isolate Rule

This is the default behavior while profiling applications in the Streaming Profiler. The Isolate rule assures that a streamed application cannot affect locally installed components of the operating system or other applications. When user devices create a new isolation environment, its default behavior is to isolate everything with a few exceptions. When an application requests access to a system resource (such as a file, registry, or named object), a per-user version of the file or key is created as required. This behavior relieves most application conflicts and allows applications to run correctly.

Isolation rules ensure that per-user level versions of files and keys are created. This creates an individual copy of each resource that a particular user accesses.

Add this rule to ensure that there is one copy of a resource per isolation environment. For example, create a rule that isolates the registry hive, HKEY_LOCAL_MACHINE\SOFTWARE\classes, when you install Microsoft Office. Because each user does not require a separate version of this hive, create a rule that isolates this particular registry hive for the isolation environment.

Strictly Isolate Rule

This rule prevents the application from accessing the objects in the physical layer. The application never sees an object that is defined to be covered by this rule unless it was created within the isolation environment.

This rule is commonly used to support multiple versions of an application running on the user device. The existing Isolate rule prevents an application from making changes in the global system, which might affect other applications running in the system. However, system changes made by other applications running on the system cannot be hidden from view of the isolated application.

Sometimes, such changes may need to be hidden from the application view for its proper functioning or for installation of an application in the sandbox. The Strictly Isolate rule allows the sandbox to hide selective changes made in the system from the view of the virtualized application.

Ignore Rule

The Ignore rule allows the rules engine to define “holes” in the isolation environment so that an application can write to the underlying system. Note that the Isolate rule is still the default behavior while profiling applications in the Streaming Profiler.

This rule allows a streamed application running inside an isolation environment to share data with an application outside the isolation environment. For example, if you try to open a file from streamed application A to use in locally installed application B, the applications can communicate normally, as though they are both locally installed.

Also, in a scenario where users can print to network printers available within a streamed-to-client session, these printers are created automatically when the user connects to a published application.

Redirect Rule

A Redirect rule redirects an application request for a file or registry key to a specified location. For example, if an application creates the file, c:\temp\data.txt, this rule can redirect those files to c:\guidtemp\%USERNAME%, regardless of the user.

For example, if UserA runs the application in an isolation environment, c:\temp\data.txt is created in c:\guidtemp\UserA\data.txt.

In this example, the administrator might choose to clean up the \temp directory each time the system starts up. By redirecting all access of c:\temp directory to c:\guidtemp on a per-user basis, the administrator can clean up the temporary data easily at startup.

Examples

Consider the effects of the following rules:

  • An Ignore rule for the file path: C:\Documents and Settings\%USERNAME%

    Every file and directory created under C:\Documents and Settings\%USERNAME% is created in the system location because you specified, through the Ignore rule, that this directory location is not isolated. If an application opens the file C:\Documents and Settings\%USERNAME%\ ApplicationData\CompanyA\foo.txt, the Ignore rule for C:\Documents and Settings\%USERNAME% applies.

  • A per-user Isolate rule for: C:\Documents and Settings\%USERNAME%\Windows

    This rule isolates the per-user Windows directory, C:\Documents and Settings\%USERNAME%\Windows. If an application opens C:\Documents and Settings\%USERNAME%\Windows\Win.ini, the isolate per-user rule for C:\Documents and Settings\Windows applies.

Restrictions and Limitations for Rules

Consider the following restrictions and limitations when constructing or altering the rules for your isolation environment:

  • Do not modify or delete the default rules available for an isolation environment. If you modify these rules, the isolation environment might be unable to run applications correctly.
  • Use an asterisk (*) as a wildcard character only at the end of an ignore named object rule. For example, the rule ignore object* ignores all named objects with a name starting with object. Use of an asterisk is not allowed in isolate or redirect object rules.
    Important: Do not use the wildcard in a rule that applies to a file system or registry key. By definition, the rule applies to all the children of a path name.
  • File system rules can apply to either files or directories. Create a rule to alter the behavior of individual files or of directories and all of the files within them. For example, you might have a Redirect rule for C:\temp\fileA.txt, as well as one for C:\temp\subdir1.
  • Rules that specify a registry object apply only to registry keys. They do not apply to registry values.
  • Rules for an isolation environment are interpreted at run time. Any modifications to existing rules are interpreted the next time you launch an application associated with, or installed in, an isolation environment. If you are executing an isolated application and modify the rule definitions, these changes do not affect running applications. The modified rules are interpreted and take effect the next time the application is executed.
  • A rule must be specified in terms of a full directory or key level. Matches are performed on the full name of a given hierarchy level. For example, if you create a Redirect rule for C:\temp\file, the rule applies only to a file or directory called c:\temp\file. The rule does not apply to any files or directories that have c:\temp\file as part of their name. For example, this rule does not apply to the file C:\temp\fileA.txt, the directory c:\temp\filledWithFiles\, or any files under that directory. The same principle applies for the file system, registry, and named objects (with the exception of wildcards and named object rules).

Creating Isolation Environment Rules for a Target

Use the Rules page of Target Properties to modify the isolation environment rules. The list of rules on the Rules page displays for each rule its name, the action to perform, and the object on which to perform the action.

To display more detailed information about a rule, select it in the list and Rule Description identifies the named object on which the rule operates.

After testing a profile, if you determine that your users might experience conflicts when running applications in their isolation environments, modify the isolation environment rules for the target.

Some of the indications that you may want to modify the isolation rules are:

  • If an application creates a directory for per-user data that is stored in a nonstandard location (Ignore rule)
  • If the profiler workstation has extra drive volumes and an installer writes to those drives while installing in a target (Ignore rule)
  • If your file share volume is on your profiler workstation (Ignore rule)
  • If you must isolate a subdirectory of an ignored directory on the user device (Ignore and Isolate rules)
  • If you must support multiple versions of an application running on the user device (Strictly Isolate rule)

The Rules list shows the existing rules for the target and for each rule identifies:

  • Arbitrary name for the rule
  • Action, which is the isolation environment rule that is being called
  • Object on which the action performs

The Rule Description box at the bottom shows the command represented by the currently selected rule.

To create an isolation environment rule

To add a rule to the currently defined set of rules, from the Profiler, select the target, and from the Edit menu, select Target Properties. From the Rules tab, click Add. Use the New Rule wizard to define the new rule.

  1. Select an action and the type of object on which you want the action to operate.
  2. On the Select Objects page, click Add.

    If for the action, you choose Ignore, Isolate, or Strictly Isolate:

    • If you selected Files and Folders as the object type, use the file browser to select the files and folders on which you want the rule to operate
    • If you selected Registry Entries as the object type, use the Choose Registry Entry dialog box to select a hive and type a key on which you want the rule to operate
    • If you selected Named Objects as the object type, use the Choose Named Object dialog box to type the name of the object on which you want the rule to operate

    If for the action, you choose Redirect, specify the source path, registry entry, or named object and its destination.

  3. If necessary, modify the default name of the rule. By default, the New Rule wizard creates a rule name consisting of the name of the action and the name of the object.

To copy a rule in the currently defined set of rules, from the Rules tab of Target Properties , select the rule and then click Copy. The copy operation adds the copied rule to the top of the list of rule set members. Use the property also to modify the name, action, or object of the rule.

To modify a rule

To modify a rule in the currently defined set of rules, from the Rules tab of Target Properties, select the rule and click Modify. Use the New Rule wizard to define the new rule. Modifying a rule lets you modify the action and objects, but not the object type.

  1. Select the action.
  2. On the Select Objects page, add or modify objects.
    • If Files and Folders is the object type, use the file browser to select the files and folders on which you want the rule to operate
    • If Registry Entries is the object type, use the Choose Registry Entry dialog box to select a hive and type a key on which you want the rule to operate
    • If Named Objects is the object type, use the Choose Named Object dialog box to type the name of the object on which you want the rule to operate

    If the selected action is Redirect, specify the source path, registry entry, or named object and its destination.

  3. If necessary, modify the name of the rule.

Using Environment Variables to Construct Rules

Use environment variables to construct rules that contain references to path locations that can change at run time. For example, an application data path can change depending on the language selected. This can lead to errors if you use the default rules for an isolation environment. Using an environment variable to construct path-specific segments (such as a language-specific application data location, AIE_COMMONAPPLICATIONDATA) ensures that an explicit rule is created for the selected language. At run time, AIE_COMMONAPPLICATIONDATA is substituted with the language-specific application data location such as C:\Documents and Settings\All Users\Application Data.

Citrix recommends that you use an environment variable to ensure universality of a rule when any of the following conditions are true:

  • Path location contains a user name
  • Translation issues can occur with standard application locations
  • Relative locations can change; for example, the location where you install XenApp

Environment variables can also quickly check where certain paths are within a script. For example, to find out what the file system installation root for an isolation environment is, use AIE_FSINSTALLROOT.

All environment variables for isolation environments are prefixed with AIE_. When you create a new isolation environment, a number of default rules apply. These default rules use the environment variables listed in the following table to make the rules universally applicable. To view the default rules for application isolation environments, refer to the list in the Rules wizard.

Note: Exercise caution when using backslash characters (\) with these environment variables. Ensure that you insert a backslash (\) after an environment variable before adding additional path information; for example, AIE_USERAPPLICATIONDATA\MyData\Mine.

Environment variables available for isolation environments:

  • AIE_COMMONAPPLICATIONDATA
    • Description: Common application data location
    • Example: C:\Documents and Settings\All Users\Application Data
  • AIE_COMMONDESKTOP
    • Description:Common desktop location
    • Example: C:\Documents and Settings\All Users\Desktop
  • AIE_COMMONSTARTMENU
    • Description: Common Start menu location
    • Example: C:\Documents and Settings\All Users\Start Menu
  • AIE_FSINSTALLROOT
    • Description: File system install root
    • Example: C:\Program Files\Citrix\RadeCache\MyAIE
  • AIE_FSUSERROOT
    • Description: File system user root
    • Example: C:\Documents and Settings\Administrator\ Application Data\Citrix\RadeCache\MyAIE
  • AIE_METAFRAME
    • Description: Installation location
    • Example: C:\Program Files
  • AIE_NAME
    • Description: Isolation environment name
    • Example: MyAIE
  • AIE_REGINSTALLROOT
    • Description: Registry install root
    • Example: HKEY_LOCAL_MACHINE \SOFTWARE\CitrixRade Cache\MyAIE
  • AIE_REGUSERROOT
    • Description: Registry user root
    • Example: HKEY_CURRENT_USER \SOFTWARE\CitrixRade Cache\MyAIE
  • AIE_USERAPPLICATIONDATA
    • Description: User global application data location
    • Example: C:\Documents and Settings\Administrator\ Application Data
  • AIE_USERLOCALDATA
    • Description: User local application data location (including temporary files)
    • Example: C:\Documents and Settings\Administrator\Local Settings\Application Data
  • AIE_USERDESKTOP
    • Description: User desktop location
    • Example: C:\Documents and Settings\Administrator \Desktop
  • AIE_USERSID
    • Description: Unique security identifier for the current user; it is used extensively internally for security checking.
    • Example: S-1-5-2001-……
  • AIE_USERSTARTMENU
    • Description: User Start menu location
    • Example: C:\Documents and Settings\Administrator\Start Menu