- Targets Overview
- Isolating Services
- Managing Isolation Environment Rules
- Preparing a Workstation for Profiling Applications
- Profile Contents on the Server
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.
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.
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.
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.
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.
Consider the effects of the following rules:
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.
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.
Consider the following restrictions and limitations when constructing or altering the rules for your isolation environment:
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:
The Rules list shows the existing rules for the target and for each rule identifies:
The Rule Description box at the bottom shows the command represented by the currently selected 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.
If for the action, you choose Ignore, Isolate, or Strictly Isolate:
If for the action, you choose Redirect, specify the source path, registry entry, or named object and its destination.
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 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.
If the selected action is Redirect, specify the source path, registry entry, or named object and its destination.
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:
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.
Environment variables available for isolation environments: