Inside Citrix Presentation Server’s Application Isolation Environments


Citrix Brings New Technologies to the Table


In a previous article, I identified three key technologies that Citrix was employing with their release of Presentation Server 4.0. They are CPU Utilization Management, Virtual Memory Management, and the Application Isolation Environment features. Together these features are intended to provide administrators with flexibility in application placement and managing user load on servers. We briefly went over the merits of each technology and the limitations behind them in the previous article. This time we will go in depth with what is potentially the most exciting of these technologies, Application Isolation.


Application Silos


Every Citrix administrator will be faced with the same dilemma one day, whether you have 3 servers or 300: I’ve got 2 versions of the same application and need to run them on the same server. For some administrators it will be a matter of budget. After all, convincing your manager to spend thousands of dollars on a new server to support a three-user application isn’t going to be an easy task. For others it might be a matter of space. So many environments are working to scale down the number of physical boxes these days and adding another server for a small user base might not fly. 


In the “old days” we dealt with the problem of multiple application versions or conflicting applications by application siloing. Put simply, you used different servers for different versions. Each server or group of servers that hosted an application was referred to as a silo. It was an effective technique as long as you planned appropriately and had a good hardware budget. It could also be a management nightmare. I have run environments with three different Oracle client versions, multiple Java requirements, and countless applications that just didn’t play nice with each other. Each new application that you introduce becomes a juggling act to find space and appropriate hosting. 


The problems with siloing are obvious. It can require a lot of hardware, and does not make full use of the hardware you might already have available. Server utilization becomes a less useful criterion for determining new application space than compatibility, which means that one of the primary benefits of using application servers is rendered obsolete. I have been to environments where there were literally 40 application servers in the environment hosting 40 applications, and all running at perhaps 5 percent load. They just did not want the headache of trying to manage multiple, possibly conflicting, applications on the same servers. Obviously this is a tremendous waste of space, resources, and even administrative time. While it is true that you eliminate the hassle of application conflicts, you have also increased the amount of hardware to monitor and replace when it fails.


Enter Application Isolation


Third party vendors have long realized that the weakness of application silos. There have been several products over the last few years that have provided isolation functionality to administrators, and Citrix has finally taken steps to include it in the their own product line. It is very important to note that the Application Isolation functionality is only included with the Enterprise Edition of Presentation Server. Earlier product literature had indicated that it would be available with Advanced Edition, and more than one administrator found to their dismay that the Subscription Advantage they had just re-upped wasn’t going to include this feature. To this day there are still product notes that say Application Isolation is included with Advanced Edition and not just Enterprise Edition. So check those licenses carefully!


Citrix accomplishes their Application Isolation Environment through the use of resource virtualization. A “virtualization layer” is placed between the application and physical resources, and redirects the virtual resources to the physical ones. Resources are presented virtually to the application and any modifications requested to the resource take place in the virtual layer instead. The application is unaware of the interception and (we hope!) continues to perform exactly like normal. Resource mapping between the physical and virtual resources is dependent on a flexible rules engine, which allows the administrator to accurately define what they want redirected.


That all sounds great on paper, but what does it really mean? Realistically you can remap file system calls, registry calls, and named object calls including COM objects. File system mapping is very useful for applications that use a common INI file for user settings, but that you want to let each user customize. While Terminal Services handles basic redirection through the use of individualized Windows directories for each user, file system mapping and redirection gives you a much greater range of control over INI files located in other directories. In addition to providing individual user customization, it also provides a level of protection from file corruption. Changes that a single user makes to the file no longer will affect every user of that application.


The benefits to remapping registry calls should be obvious. Applications that are already Terminal Services aware may not gain a significant benefit from this type of redirection because they perform it by default already. Calls made to HKLM and HKCU are redirected to virtual resources instead. Unfortunately most applications are NOT Terminal Services aware, and these are inevitably the applications you will be asked to install. Registry remapping gives the same flexibility to single user applications that you enjoy with Terminal Services aware ones. This can prevent a lot of the problems normally seen with single user applications in a multi-user environment.


The final component of Application Isolation is Named Objects. These can be anything from Events to COM objects that Windows creates and uses as part of the application process. Often single user applications will require exclusive access to these resources, and multiple instances attempting access to the same resource can cause application and even system instability. Named objects include Windows COM objects, commonly used to integrate application data. They allow users to embed data from one program within another for instance. 


Installing Applications in an Isolation Environment


From an administrator’s point of view, application installation is a relatively simple matter in an Isolation Environment. You can even use Installation Manager for simple deployment into your infrastructure, and using the command line utilities that are a part of the Application Isolation suite you can even use 3rd party packaging tools such as SMS for application deployment. So how do you know what to isolate? That’s the complicated question. When you create new application environment, Citrix gives you a default set of rules as well. This default ruleset utilizes the maximum amount of isolation rules, maximizing the compatibility with most applications. The downside, of course, is that you will also utilize far more system resources using the default ruleset than you will with a set of isolation rules specifically tuned to your applications.


My recommendation if your application requires an Isolation Environment is to understand your application and its requirements. There are numerous free tools out there that will really let you get to the nuts and bolts of an application. Sysinternals (www.sysinternals.com) makes several extremely handy tools for analyzing your application and the various calls it makes. Study the application with Regmon, Filemon, and even Process Explorer. Once you know what the application depends on and where it wants to find it, you can tune your Isolation rules and include only the rulesets you require.


So why not Always Use It?


If Application Isolation is so great, why not just use it all the time? There are some very valid concerns to application isolation. The most obvious is the increase in required resources. If you are striving for maximum user density on your servers, keeping Application Isolation to a minimum is probably a good idea. Because each isolated application now has a virtual layer associated with it, system resources are being consumed at a faster rate. Make sure to test each application and understand the resource impact before deploying it to your servers. 


Besides the resource impact, there are some application types ill suited for application isolation. If you have conflicts due to Windows Services, Device Drivers, DCOM, Windows Class Names, or any application executables that do not link to USER32.DLL. Because Application Isolation uses both Kernel Mode and User Mode drivers and a Microsoft approved filter driver framework, all application hooking is done in user mode to avoid the instability that Kernel Mode hooking can cause.


Application Isolation isn’t the solution to all of your compatibility problems, but it is undoubtedly a start. And of course if you have Enterprise Edition, it’s bundled as part of the software. It’s hard to argue against free! The flexibility of the rulesets that Citrix has provided is fairly significant, and with careful planning you can reduce the impact on your system resources to negligible levels and minimize user impact. Simply turning on the default rules will certainly give you a more compatible environment for single user applications, and is hardly taxing on your administrative skills. However, the real value lies in customizing and tuning the application environment for your specific needs. Spending that time up front can save you wasted time and resources later.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top