One of the new features in Citrix Presentation Server 4 is AIE (“Application Isolation Environments”), which makes it possible to install and/or run applications in a so called “Isolation Environment.”
How does AIE work?
A standard Windows application consists of many parts that normally would spread across your system in places like C:\Program Files, C:\Windows, C:\Windows\System32, as well as the HKCU and HKLM registry hives. In a nutshell, AIE redirects the files and registry values of an application installation to an “Isolation Environment” which is managed through the Presentation Server Management Console. Then when the application is run, AIE makes the application believe it’s running from the location you entered at installation time like “C:\Program Files\Application Name” when in fact the complete application code is actually in “C:\ProgramFiles\Citrix\AIE\Application Name.”
A similar process is used to redirect the application’s registry settings. An application installation that would normally create settings in a registry key like “HKLM\Software\Your App Vendor” and “HKCU\Software\Your App Vendor.” Using AIE it’s now redirected to “HKLM\Citrix\AIE\Your App Vendor” and “HKCU\Citrix\AIE\Your App Vendor.” Again AIE makes the application believe its registry keys are in HKLM\Software\Your App Vendor and HKCU\Software\AIE\Your App Vendor.
The AIE feature of PS4 can be used in two ways:
- You can Install and then Run an application in AIE
- You can run a “normally” installed application in an AIE.
In both cases the first thing you need to do is create an AIE.
Creating an AIE
For each application you want to isolate you need to create a separate Isolation Environment. This is done from “Isolation Environments” node in the Presentation Server Management Console. Right click it, choose “New” and type in a name for your AIE. This only needs to be done once for each Server Farm.
You are now ready to either install or run an application in the AIE.
Installing into and Running from an AIE
There are two ways to install an application into an AIE. This can be done in an automated way via Installation Manager or manually using the AIESETUP executable with the appropriate parameters.
Installing to an AIE through Installation Manager is pretty easy. Simply select the .MSI of .WFS file like you would normally do and in the “Schedule Job” screen you now have the option to select in which “Isolation Environment” you want to install the application to.
Using the AIESETUP command is a little more work but is the best way to really get familiar with AIE. The syntax of this command is pretty easy. (Type AIESETUP /? to see the options.) In the following example I will install Acrobat Reader into an AIE called “Acrobat Reader” with an Installer named “c:\AdbeRdr70_enu.exe”.
AIESETUP "Acrobat Reader" c:\AdbeRdr70_enu.exe
The setup starts and I decide to install to C:\Program Files\Adobe\Acrobat 7.0\
I’m actually monitoring the C:\Program Files\ folder while the installation is taking place. I don’t see an Adobe folder appearing. Also after the installation finishes successfully no Adobe folder is present under C:\Program Files\. All Files and Registry have been redirected. Here’s the folder where the application files actually are present:
The reason you see 3 folders here is because this application installs files outside the entered installation path. This includes Shortcuts, Common Files, a couple of DLL’s in the Windows Folder, etc. This is proof that everything an application tries to do is redirected and not only the installation path of an application.
Now that the application has been installed, you need to run it. There are two ways this can be done:
- You can publish AIE applications
- You can run them via a special command line
Publishing an AIE application is fairly straightforward. You simply publish it through the Presentation Server Console and in the “Specify what to publish” screen select “Isolate Application.” Then click on settings, select the correct AIE, select “Application was installed into environment” and select the appropriate shortcut from the dropdown menu. The rest is the same as “normal” application publishing. Now you can run the application from a Citrix client.
The second way of running the application is through the AIERUN executable command. This is the way you would run an AIE application from the console or from a published desktop .
To do this I run the application using the AIERUN executable command with a very long parameter:
AIERUN.EXE “Acrobat Reader” “C:\Program Files\Citrix\AIE\Acrobat Reader\Device\C\Program Files\Adobe\Acrobat 7.0\Reader\Acrord32.exe”
If you want to provide your users access to this application from a published desktop then simply create a shortcut to the AIERUN command as shown above.
The application starts. Now from within the application I browse (through File -> Open) to C:\Program Files\ and here I see the Virtualized (redirected) folder Adobe.
From the regular Windows Explorer I still don’t see the Adobe folder under C:\Program Files\.
The Isolation Environment is actually a basic form of application virtualization since the AIE makes the OS and the application executable think it’s running from its native location. (Notice I say it’s a “form” of virtualization. It’s actually very different than “true” virtualization that companies like Softricity provide.)
Running a “normally” installed application in an AIE
The second way of working with AIE is to run a “normally” installed application in AIE. This can solve a lot of multi-user application issues such as when an application stores user-specific settings in Local Machine registry. AIE really can help you with these kinds of situations.
First of you have to create an AIE in the Presentation Server Console as mentioned earlier in which you won’t install any application code. Then you can either publish the application or run it with the AIERUN command. When publishing through the PSC in the “Specify what to publish” screen simply browse to the already installed executable and then select in which AIE you want it to run.
For demonstration purposes I created an AIE named “User Settings Demo.” I published regedt32.exe and selected the AIE “User Settings Demo.” Now I run the published application with an ICA Client from the server console. I also start regedt32.exe from the server console. (Keep in mind that the Local Machine registry is the same from the server console as from within a published application as long you’re running on the same server, which I am.) During the logon script for the published application I create two empty subkeys under HKLM\Software named “usersetting1” and “usersetting2”. This is what a “bad” application could do during startup or while working with the application. The following is the result:
The left is the registry editor running on the server console. The right is the registry editor running through a published application on the same server at the same time .
The new registry keys I just created are actually saved in the user’s registry under HKCU\Software\Citrix\AIE\%AIENAME% even though for the application they appear to be under the HKLM\Software registry. This means machine settings are saved per user from now on and multiple concurrent users on the same server can have different machine settings.
What will not work with AIE?
AIE is great, but of course there are limitations. (I think we will find out in the field the hard way what the “real” limitations are.)
OS patches, drivers, and really deeply integrating applications probably won’t work, especially installing into an AIE. (Although all application isolation, virtualization, and redirection software I’ve come across have some sort of limitations like these.)
What can AIE solve?
- Run multiple version of the same application
- Run multiple version of the same DLL
Multi User Issues
- Solves configuration issues with hard coded path to .INI files
- Solves configuration issues with HKLM registry keys
Give users more “virtual” rights to an application
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.