Can AIE be used for drag and drop application deployments to Citrix servers?

Rodney Medina from Login Consultants wrote a great article last week introducing the new Application Isolation Environment functionality in Citrix Presentation Server 4.0. These new AIE capabilities have gotten a lot of people thinking about creative ways they can be used.

Rodney Medina from Login Consultants wrote a great article last week introducing the new Application Isolation Environment functionality in Citrix Presentation Server 4.0. These new AIE capabilities have gotten a lot of people thinking about creative ways they can be used. For instance, Daniel Wipperfuerth from ADN in Germany has proposed that AIE could be used for “file copy”-based application distribution to Citrix servers. In a nutshell, why not install an application into an isolation environment and then just copy the files and registry keys from server to server?

To see what we’re talking about, let’s walk through an example of how you’d do this with WinZip and a PS4 farm with at least two servers.

  1. Use the Presentation Server Console (PSC) to create a new isolation environment on Server A.
  2. Use the AIE setup utility to start the installation WinZip. (This would be something like “aiesetup your-isolation-environment-name setup-filename-of-wizip.exe"
  3. Use the PSC to publish the application from its isolation environment.
  4. To “deploy WinZip to Server B, simply copy the local sandbox files and directories from Server A to Server B. Also copy the isolation environment’s registry keys from Server A to Server B. (Check out last week’s article for details about the isolation environment’s files and registry keys.)
  5. When you’re done, use the PSC to add Server B to the list servers that WinZip is available on.

That’s it! You can now run WinZip from either of these two servers. The application’s files and registry values remain in the isolation environment’s sandbox and can be copied to any machine you want.

This technique has several benefits, including:

  • It works “after” the application’s installation routine has been run, which means that it doesn’t matter what type of installation technology is used. (MSI, batch file, InstallShield, etc.)
  • It can be used to “deploy” applications to running servers using simple batch files with xcopy.exe and reg.exe.
  • It can be used to update existing applications by using a tool like rsync that will only transfer the changed bits.
  • It’s much easier than doing “real” installations to each server.

With all these advantages, there is one major disadvantage—AIE does not support application components outside of file and registry locations. So this technique is a “no go” for most applications since they require advanced components such as COM objects. Other than that though this could be an interesting deployment solution in limited cases.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

The link "great article last week" appears to be broken.

I think you forget ":" in the URL.

(apparently this has the abbility in firefox to send me to the "I am feeling lucky" link with that test ;-) )
You can use Installation Manager to distribute applications that are installed into AIE's - hence you install it once and then push it out to what ever server you need.
I think another disadvantage using this way of "distribution" is, that the security settings on either the files nor the registry settings are copied as well... Means just "copy and paste" from server-A to server-B; you will loose your security-settings on server-B... Isn't it?

Wolfgang Mundt, CEMA GmbH
that just depends on *how* you implement the copy job. For the file-based part of this, xcopy /o should do the job, as does robocopy /datsou. I'm sure, there is a way to do this stuff for the registry part as well.

It is to be seen, wether this suggestion is appropriate in one setting or the other. There are certainly some szenarios which will not benefit from this method but there might be others who will.
If Group Policies are enforced on the server the security settings will be replicated down onto the Keys in the registry if copied.
As we all live and breathe for performance as that is what the key issue is when doing SBC. What impact would this have on the performance of a server. As far as i have been able to work out, using AIE does have a price in performance as the translation to the AIE does take machine power.

I think in any case it would be worth taken into consideration before we all decide to use AIE to distribute software to servers that could actually run on the server without using AIE :)

As for the general idea i love the thought that when we do make an AIE we are able to distribute it to several servers. Just think we need to think twice before we use it an Application Deployment tool :)

P.S i could be wrong, havnt had experience with AIE on heavily loaded servers yet, so my concerns about performance loss comes only from what i read. Does any of you have any experience with AIE on heavily loaded servers?
I think this is a great idea. I did this simple robocopy/reg script for AIE sync. It's based on the Robocopy.exe from the windows resourcekit and reg.exe builtin to Windows XP/2003.

It still does not handle removal of AIE registry and files but it's a start. Im testing this in a lab environment now.

The script mirrors AIE environments from a source server to local machine. You can schedule the script using AT commands or run as a startup script on AIE servers.

You must specify source server, and path to AIE file and registry location.

SOURCESRV=Name of Source server (SERVER01)
DESTSRV=Name of local server (LOCALHOST)
AIEREG=Path to AIE registry key (HKLM\software\Citrix\AIE)
AIEFOLDER=Path to AIE folder (m$\Program Files\Citrix\AIE)

*************Script start**************************



SET AIEREG=HKLM\software\Citrix\AIE
SET AIEFOLDER=m$\Program Files\Citrix\AIE
SET _options=/R:0 /W:0 /LOG:AIESYNC.LOG /NFL /NDL

ECHO Synchronizing AIE files from %SOURCESRV% to %DESTSRV%...
ROBOCOPY %_source% %_dest% %_what% %_options%
ECHO Synchronizing AIE registry from %SOURCESRV% to %DESTSRV%...
Forgot to login before posting this. Just if you wondered who posted this topic.
I was testing a little tool for AIE browsing. When browsing registry in an AIE environment the registry enumeration were slower than browsing it outside AIE. I did the test on a overloaded vmware server so the difference were quite big, on a production server I guess the difference is a bit smaller, but still there is a performance issue running applications in AIE.
The idea behind this is good, the script above will do the file/registry replication between the servers, however it will still not work for drag/drop deployement. AIE only filters file/registry api. Many installers uses other api's to do different task, for instance creating odbc sources. When using the api to create odbc sources, the api is bypassing the AIE filter, and the registry values for the ODBC source will not be replicated. If you use the IM to deploy, it's gonna work, but the AIE file/reg replication method, only works for pure file/registry based installers. You can fix this by moving the neccessary files and registry values into the AIE path. But then it's no longer a drag'n drop deployement.