Many people know that an early codename for Application Streaming was “Project Tarpon”.  What they often don’t know is that the original codename was “RADE”, which stood for “Rapid Application DElivery”.  The design goal was to provide the administrator an ability to rapidly update applications, to an entire farm of XenApp servers without having to kick users off of the server, or even kick them off the application.  The foundations of RADE are still present in Application Streaming though elegant concepts have been added including “offline” and “streaming”.   The centralized publishing here is also key because a streamed application never has to be “installed” onto a server.  You just tell the Access Management Console, which servers should get the streamed application and you’re done.

The reason this is important is that the stream to server case for rapid application update remains one of the most important use-cases for Application Streaming.  This post describes the “RadeCache” directories and attempts to provide a clear description of what “stuff” goes in what place and how this all leads to a world where user settings can follow a user from machine to machine as “payload” of a user profile system such as Roaming Profiles or Citrix User Profile Manager.

History

Citrix AIE technology in Presentation Server 4.0 provided the foundation of isolated application execution, but it did not provide a mechanism for updating an “in use” application.  While the 3 layers of isolation still existed, the ability to replace the execution image at runtime was still impossible because there may still be users on that server, using the application binaries that you are trying to replace.

With RADE (aka Application Streaming), the execution image for an application is versioned.  Rather than a single directory holding the execution image, each version of the application image gets its own directory.  By updating the application, the administrator tells the isolation system that for new launches, use the new version of the application.  All presently running instances of the application continue to use the already running image, but new launches get the new version of the applications.  Awesome stuff and it is very RAPID!   Notice that the administrator updated the application in one place, on the Application Hub.  It then automatically gets distributed to all of the servers in the farm!  Update once, deliver the application to all the servers!

Here’s a picture of the layers of isolation showing the versioning.  Noting that execution images (Targets) are identified by a GUID, pay attention to the underbar and integer that follow the GUID.

Notice above that the execution space (the part that holds the image of the “installed application”) is versioned.  The first version of a Target gets “_1”, and from there, the right hand part bumps by 1 forever.  When an update is applied to the profile, the new image is immediately available.  Every time the streaming client launches an application, it checks the Application Hub to see if the administrator has updated the application.   Usually, the answer is no, but occasionally, the answer is yes and if “yes” happens, the streaming system builds a new RadeCache directory to support the new version of the application.   Notice that this behavior is 100% exactly the same whether the operation is stream to desktop or stream to server.  The streaming client is the same and does the same actions in both cases.

Just with the above, the application can be updated rapidly!

Here’s a picture of the RadeCache, middle layer of isolation for the computer I’m using to write this post.

Yes, there are a bunch of GUIDs in there.  I’m not even sure what they all are though I do know that the top one is MS Office 2007.   Seems the internal farm is up to the 6th version of profiling MS Office and my administrator has happily done some network magic to erase the preceeding 5 versions.  Nice of them.  That the streaming client should manage this itself is a topic I will save for a future post.

To observe in the above, the GUID’s have a number after them.  That number is the versioning.

Per-user cache

About once a month, I get asked what happens to per-user application settings on a Target upgrade.  Answer: They are maintained.  A corolary to the same question is “how do the per-user application settings get referenced for use on a next execution machine?”  Answer: The streaming content is “payload” for the user profile solution.

Here’s a picture of the per-user space (files) for the machine I’m typing this on.

Notice these also have a GUID per-Target, but that they do not have versioning.  In the early days, we actually considered versioning this space as well, but ultimately concluded that handling old user data in new versions of applications is something that applications just have to be able to handle, with or without isolation.  Decided not to version it and a few years in the field says that we made the correct choice.

Since the per-user RadeCache is located somewhere beneath %USERPROFILE%, well is supposed to be.  See here for details.  Stick with me on the concept.  Since the per-user RadeCache is in user profile space, the user profile solution will copy it from execution machine (XenApp Server included) to a future execution machine where the streaming system will find it for use in running the application.  The end result is that the user settings stick with them.

There are some limitations such as replacing a profile with a fresh profile generating fresh GUIDs and this makes the per-user space empty on first execution.   For this, the administrator should “upgrade” profiles rather than replacing them.  Upgraded execution targets retain their GUID, while new execution targets get fresh GUIDs.

Joe Nord

Product Architect – Application Streaming and User Profile Manager

Citrix Systems, Fort Lauderdale, FL