Application Isolation Environments
Overview of Feature
Prior to the release of Citrix Presentation Server 4.0, the only option for deploying applications that could not be installed on the same server was to incorporate load managed groups into the environment. Technically, this was because on the same server it was not inherently possible to run multiple versions of the same application or applications that leveraged the same operating system .dll files. The latter was most common with applications that were not Terminal Services aware and installed files into the \System32 directory. Application isolation will allow many previously incompatible applications to run within a segregated environment on the same server.
An application running within an application isolation environment is segregated or “sandboxed.” This consists of two distinct processes:
• Specifying an application isolation environment and related options within the Presentation Server console, similar to creating a “virtual sandbox.”
• Installing an application into an application isolation environment on a server, similar to creating a “physical sandbox.”
These processes are demonstrated below:
Application Sandboxing
Virtual Physical
Behind the scenes…
Here an administrator creates an application isolation environment. Specifying an isolation environment can be done either through the properties of the application isolation
environment or as a configurable option when publishing an application.
Behind the scenes…
Here an administrator installs an application into an application isolation
environment. This is possible via Installation Manager or by using aiesetup.exe at the command prompt. In the actual file system structure, the application will be installed to the following path by default:
%systemroot%\Program Files\Citrix\AIE\[AIE Name]/[Designated App Path] where all operating system resources specific to the application will be managed. However, in the application isolation view, the installation process will appear is if the application was installed normally.
For more information on installing, configuring, and deploying an application into an application installation environment, please see the Application Isolation Environment Run Book.
As shown above, the entire application is installed into the application isolation environment; all application binaries are “sandboxed” into that location, which is distinct from the standard file path. Registry settings are also isolated into the location specified in the properties. The application isolation file path and registry path can be modified within the application isolation environment properties. By default, the application installation and registry locations are:
• C:\Program Files\Citrix\AIE\<aiename>). • HKLM\Software\Citrix\AIE\<aiename>).
Dependent or helper applications can be associated with an application that has been installed into an application isolation environment so that these can be accessed without issue. This is configured within the Presentation Server Console. Within the properties of the desired application isolation environment, additional executables can be associated.
For a Presentation Server environment to provide an application isolation environment, it must “virtualize” operating system resources to create a compatible application environment, which includes:
• File System. The files and directories an application uses can cause conflicts; such applications may not be designed for multi-user environments.
• Registry. Applications store configuration information in the system registry.
• HKEY_Local_Machine. System information pertaining to the application is stored here. This includes installation and load application components as well as potentially the path to a shared database.
• HKEY_Current_User. User-specific information, such as user profiles which store paths to custom directories and per-user preferences are stored here.
• Named Objects. Windows applications can create objects which are used to communicate with other applications. Each object has a name that is globally visible on the system. This can cause conflicts if two instances of an application reference the same object.
When an application running in an application isolation environment attempts to access any of the above system resources, the request is then redirected to an alternate location, as noted in the table above, based on a set of rules. This redirection is managed and executed by Presentation Server without any change to the application binaries of the operating system. Application isolation technology was not licensed from a third-party vendor; it was developed by Citrix Systems, Inc.
Impact to Architectural Designs
Published applications launched from application isolation environments will launch slightly slower than applications installed in the regular fashion. This is because additional processing steps are required.
This new feature can have a profound effect on whether or how load managed groups are incorporated into an environment. Prior to Presentation Server 4.0, the only way to
segregate applications that could not function together was by load managing each application or application set onto a different group of servers. Load managed groups implies a group of servers hosting the same application set within one farm. This concept is also commonly called application silos. With load managed groups, at least one additional server within each group is required for redundancy. Load managed groups would be identified as shown:
• Numerous updates: Frequent updates to one application cause downtime that cannot impact others • Business: Per-server business unit funding
• Back-end data source: Presentation Servers with client application located closest to databases in distinct data centers
• Mission-critical application: One application can’t be down due to another
• Virtual IP: Designate virtual IP for specific servers instead of all servers to minimize number of IP addresses However, now that application isolation is an embedded feature of Presentation Server 4.0, there are sound business and technical reasons for deploying applications in this fashion. Application isolation will frequently be used to address the following requirements:
• Application conflicts: .dll files are installed into a unique location
• Multiple versions: Each application being installed into a unique location eliminates upgrade overwrites • Different languages: Older applications didn’t permit multiple language versions
• Hard-coded file paths: Typically addressed by the revised file path below the AIE directory
To ensure full functionality of applications installed using the application isolation feature, thorough testing is required. Consider the following example:
Customer has a CTI application that requires a unique IP address for each connection. Virtual IP will be
implemented but not enough IP addresses can be allocated to support the total number of concurrent connections in the farm. Because every connection to a server enabled for virtual IP is assigned a virtual address, segregating the CTI application into its own load managed group and configuring virtual IP for only those servers would ensure that just those connections are assigned virtual IP addresses.
Load managed groups would be the valid choice in this situation.
Considerations
Published Desktop. In the case where the customer insists on a published desktop, consider using the AIERUN command or creating a desktop shortcut icon for applications that have been installed into an isolation environment. The use of AIERUN is detailed in the Presentation Server 4.0 Administrator’s Guide. Creating a desktop shortcut will function only for simple executables and should be thoroughly tested. If a desktop shortcut is used, it will need to be made available under Start Menu\Programs for All Users and permissions will need to be granted. However, please note that published
applications are the recommended means for accessing applications.
Resources. Maintaining many application isolation environments may become an administrative burden. In addition, some applications that serve as helper applications may not be discoverable by the core application. As such, it is recommended that only applications that require isolation environments be sandboxed in this manner.
Removing an Application Installed in an Application Isolation Environment. Because applications installed into an isolation environment are not installed with Add/Remove Programs, uninstallation via this mechanism is not possible. An application installed within an application isolation environment can be removed by deleting the following:
• All the files that reside in the installation root location of the isolation environment (default: C:\Program Files\Citrix\AIE\<aiename>)
• The registry entries under installation root (default: HKLM\Software\Citrix\AIE\<aiename>).
In cases where a customer is running MetaFrame Presentation Server 3.0 and is planning to upgrade to Citrix Presentation Server 4.0 to take advantage of this feature, thorough testing is still required. First test the applications in a pristine
Presentation Server 4.0 environment using application isolation. If successful, the applications should be included in the upgrade strategy.
Notice
The information in this publication is subject to change without notice.
THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT. CITRIX SYSTEMS, INC. (“CITRIX”), SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR DIRECT, INCIDENTAL, CONSEQUENTIAL OR ANY OTHER DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS PUBLICATION, EVEN IF CITRIX HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE.
This publication contains information protected by copyright. Except for internal distribution, no part of this publication may be photocopied or reproduced in any form without prior written consent from Citrix.
The exclusive warranty for Citrix products, if any, is stated in the product documentation accompanying such products. Citrix does not warrant products other than its own.
Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies.
Copyright © 2005 Citrix Systems, Inc., 851 West Cypress Creek Road, Ft. Lauderdale, Florida 33309-2009 U.S.A. All rights reserved.
851 West Cypress Creek Road Fort Lauderdale, FL 33309 954-267-3000 http://www.citrix.com