In the “next” release of Citrix Application Streaming, the execution content that is today stored in a CAB file will instead be stored in a decompressed “directory” format.   This post discusses the rationale for the change and how this helps deliver applications to XenDesktop in a layers of cake model.

Some background:

  • What is the Application Hub?
  • What is an execution target and how does it differ from a profile? ( link )

In the beginning, …

During the early development of Project Tarpon we were writing neat things like the streaming profiler, the streaming client, the NT service that governs it all and the file system filter driver that does the disk layers.  When discussing ideas like “streaming” and “offline”, interesting questions come up on how application content is accessed and copied from the Application Hub.

  • How can you enable offline execution by copying the App Hub contents to the execution machine?
  • How do you know when the pre-deploy activity has finished copying?
  • How do you make the execution “Target” easy to transport between App Hubs?

Using a SINGLE file to represent a “Target” makes this all easier.  At least that was the theory; it makes for an atomic test of presence.  If the file exists – it’s complete!  If the file does not exist, the copy isn’t finished and the “Deploy” has not finished.  In reality, the streaming client has other means of knowing the answer to these questions, but we still stuck with the container file as a design goal.

We considered ZIP files, CAB files, RAR files, unzipped directories and even UNIX Tar Balls.

We CODED solutions for ZIP, CAB and unzipped directory storage, tested them a bit and discussed the advantages of each and … settled on Microsoft CAB files as the storage format for Application Streaming execution targets.  The primarily winning reason for CAB was universal availability of the CAB file libraries on all versions of the OS that we had to support and Windows explorer ability to open CAB files and show the administrator what’s inside without us having to write any code.  I should note that while those other formats were coded, they were not productized and were not present in the App Streaming releases to date.

Interestingly, we DID NOT store CAB files in the “default form”.  With guidance from our compression expert friends at Citrix WanScaler, we optimized the storage of files into the cab in a manner that would make them efficient for “random access” single file removal while still letting them be accessed from standard cab extraction and viewer utilities.  That’s a good topic for another post, so I’ll get back to this one.

The winner was CAB files and … CAB files have been a love/hate relationship ever since.

Deploy space vs. RadeCache

When you want to take a streamed application “offline”, it is necessary to COPY the Application Hub contents onto the local machine to support “streaming” at runtime even when the App Hub is not available.

Here’s the Deploy directory for streamed MS Office 2007 on the notebook I am using to write this post.

Notice that the Deploy location on the execution machine looks “really similar” to the Application Hub contents on the file share.  The deploy space just has fewer files, one CAB file – it will always have only ONE execution target by GUID.  It may have multiple versions, but it will only ONE execution target regardless of how many are present on the App Hub and described in the profile.

Here’s the App Hub location for the same profile.

On the App Hub, notice that there are a BUNCH more CAB files than there are in the local deploy space.  There are multiple versions of each of the cab files on the Application Hub and only the latest is really needed for running the application or performing “Deploy”, so the streaming client only deploys the “latest”.  There can and in this case ARE multiple execution targets for the single profile.  One is correct for 32-bit Windows Vista and Windows 7 and another is correct for 64-bit systems.  Only ONE execution target is “correct” for any given execution machine, so only THAT execution target CAB file is copied onto the execution machine’s deploy space.  In my case, it’s the one that starts with “1B3”.  I’ve learned to decode these by looking, but for better conversion of GUIDs to profile names, see this previous post.

Once the streaming Target is present in the Deploy space, the Application Hub is no longer needed.  It is consulted on App Launch to look for updates to the application.  This is RADE = Rapid Application DElivery,  but other than that, all streaming is from the Deploy space to the RadeCache execution land and this happens whether the machine is presently “online” or “offline”.

If the application is published to the user to run offline, then it is deployed and run from the deploy space – or more accurately, it is deployed and run from the RadeCache space in the same manner as for “online”, but for “offline”, the source for cache fill operations is the Deploy space rather than the App Hub.  I call this “streaming from one side of the hard disk to the other”.

Notice that the execution target is stored twice for the offline case, once in the deploy space where it is compressed and then again a PORTION of the target is stored in the RadeCache space where it is in de-compressed form.  For a detailed look at the numbers behind this, see my earlier post on RadeCache execution space

The execution layer of the layers of cake

The layers of glass has execution occurring from the execution layer of the layer of glass.  This is the “middle” layer in the 3 layer view of isolation.  This layer is present on the execution machine in the RadeCache space, which can be moved, but which is normally located close to the installation directory for the streaming client.   It should be a directory level deeper than it is, but that’s a different subject.

Here’s the RadeCache space on my notebook, again for MS Office 2007 from the Citrix showcase farm.

Notice that there are no CAB files here.  The execution space is similar to the App Hub space, but the execution content has to exist in decompressed form so that it be be layered into the layers of glass.

The “Device” item above is a DIRECTORY and below there is a C directory for drive C: and below that are a bunch of other directories that are the backing material for the isolation layers of glass that represent their equivalent location on the real C: drive.  I was going to show an expanded listing of all of the directories, but it’s 127 directories and I think I’d be lost before I found the top again.


The Deploy space just serves as backing material to fill in the RadeCache space when needed just as the App Hub serves as backing material to fill the RadeCache in an “online” scenario.

Okay, good introduction – why are you moving away from CAB files? Finally onto the meat of this post…

When taking application streaming from “stream to server” or “stream to client” and starting to look at “stream to desktop”, the needs of deploy space and the central Application Hub start to change.

Some definitions are needed.

  • stream to client” equals stream to a real physical machine such as this notebook I carry to and from work every day.
  • “stream to desktop” refers to streaming to a XenDesktop provided machine, which generally speaking will be a virtual desktop, hosted in the data center.

In the stream to desktop case, CAB files start to become a hindrance rather than an assist and they need to go away to help solve the layers of cake for virtual machine application delivery.

Consider the “layers of cake”, the execution content is brought into the execution environment at runtime.

Wearing your App Streaming developer hat, how do you EFFICIENTLY move the application content from the Application Hub into the execution machine?

Answer: You don’t.  You don’t copy anything, EVER!

Instead, you replace the CAB files on the network server (Application Hub) with an unzipped representation of what is inside the CAB files and then DIRECTLY MOUNT the Application Hub contents into the execution environment.

This provides a mechanism for executing the applications in a RADE environment where the applications are delivered to the machine at runtime, but it also prevents most disk WRITES that would occur in a normal ONE to MANY shared image mode XenDesktop farm.

Disk writes in a virtualized world are maintained by the virtualization back-end on a per-machine basis.  This occurs even though the write back cache is thrown away when the machine shuts down.  Without “mounting”, the RadeCache starts empty and gets written to at application launch, which is a first time launch from a streaming view, which is slower than a second time launch.   Once full, execution is happy, but when the machine is powered off (logoff) and then powered on again (logon), the whole process would repeat and writing large amounts of data to per-machine write back cache is inefficient and needs to be avoided.

The solution is to NEVER copy onto the machine; instead MOUNT the content so that the execution machine views everything as “already present” and the streaming system has no need to perform a “write”.  This keeps the per-machine write back store to a small size, permitting large machine count implementations at the minimum size of write back cache.

With mounted space, ONE to MANY is achieved.  ONE image of the Operating System is maintained and ONE image of the application image is maintained, while running with a minimal write back cache.

You have your “cake” and get optimal performance too!

Step 1 in achieving a MOUNT of the Application Hub is eliminating container files.


  1. Get rid of the container files and replace with directories
  2. Directly MOUNT the App Hub contents into the execution space.
  3. Tell the Streaming Client to NEVER cache fill and never do cache house cleaning

The Streaming aspects of Application Streaming are overstated

In this scenario, the “streaming” aspects of Application Streaming are relegated to the disk system, where “App Streaming” then benefits from BLOCK based fills rather than file based and where the streaming client can then focus on application delivery and isolation and completely ignore cache fills / streaming.

There are several steps to get there, step 1 was getting rid of the container files and this is covered in the “next” release of App Streaming.   It wasn’t a dislike of CABs to make it go away, the content just needs to be easily accessible and getting rid of the container format makes that easier to achieve.

Let’s get into steps 2 and 3.  Some of these are administrator things and some are future client things.

End goal is to MOUNT the Application Hub into the execution machine and have the streaming client “notice” that the App Hub is local storage.  Given that the App Hub and the RadeCache space are now “consistently” formatted (cab to dir), with the App Hub “Local”, the streaming system could “skip” the RadeCache space in it’s entirety and instead mount the App Hub space into the layers of glass.   This will NOT happen in this release!

Until the App Hub can be mounted, the optimal answer is to have the RadeCache space directories be administrator defined junctions which point into the mounted App Hub.  There are numerous methods to pull this off and based on the tools that the administrator has available with disk tools, the optimal answer may vary.  Since the cab to dir is “fresh” as in not yet released, the later steps are still being worked.  I hope this post brings some vision to the goal and helps administrators efficiently solve the layers of cake.

As for having the streaming client “notice” that the App Hub is local, there are some product level headaches to achieving this goal.  Example is ensuring digital signatures are verified before execution content gets into execution space.  This is only needed for digitally signed profiles and … not everyone is using those, but they exist and customers are using them, so we have to sort this through before the RadeCache space can be bypassed.

How about some alternate thoughts…

VHD Files

Why not store the execution targets in a VHD file on the Application Hub and then MOUNT the execution target VHD directly.  Here, you retain the ability to have a container, but you still get unzipped via of the contents. Answer: This would work.

We went with the simple approach of using decompressed DIRECTORY format on the theory that this gives administrators the most flexibility on how to deliver the contents.  Notice that just because the streaming and isolation system BELIEVES that the App Hub contents are in de-compressed directory form does not mean that the contents are not REALLY stored inside of a VHD file mounted into it’s view as a directory form.

Lying to the the Lying system!  Gotta love it.

What about backward compatibility

The “next” streaming client will still load things from streaming profiles created by earlier versions of the streaming profiler.  Here, cab files are the only storage and where the unzipped directory contents do not exist, the “new” streaming client will load the contents from the existing form.   In a “Deploy” operation, the CAB file on the App Hub will be moved to unzipped structure in the deploy space.  In theory, administrators don’t need to care about the format of the data in the DEPLOY space, but if you’ve been doing Deploy using your own techniques outside of RadeDeploy.exe, then you should be aware of this change.

When looking at the App Hub, the streaming client will look first for directory – and if found, use it.  If not found, it will look for cab file and if found, use it.   This will happen for both Application Hubs on network servers as well as Application Hubs on web servers.

When will CAB to DIR happen?

In the “next” streaming client; the one that will accompany the next major XenApp release.  The Streaming Client version number will be larger than 5.2.

Joe Nord

Citrix Systems Product Architect – Application Streaming.