In building the layers of cake for XenDesktop, a primary goal is the separation of the base machine OS image from the application images which get layered on top.  Historically, the best way to accomplish this has limitations, requiring pollution of the base image to hold streaming execution content that is really application level.  Good news!  The “next” version of the Application Streaming system will enable MOUNTING of execution content.

App Streaming refresher: The RadeCache directory on the system drive holds the application content to support execution under the application virtualization.  This provides the middle layer of the layers of glass and provides the “large” execution content that defines applications.  The challenge then becomes with pooled images, that if this content has to be “streamed” or copied into the machine at runtime, disk writes occur at runtime, which are costly, and then they all get thrown away when the machine is destroyed at logoff.  With pooled, the choices then are to pre-populate the streaming content into the base or to somehow enable mounting.  Pre-population is the standard procedure in the 6.0.2 time frame; coming soon, there are better answers and this is the focus of today’s post.

Disk writes are evil

Quote me on that!  It’s the key thing to know for pooled delivery.  All disk writes are … bad.  A superior solution will redirect the execution content to some other disk system, where “everything is there”.  In the App Streaming client now in tech preview, the system will MOUNT execution content where that content is available in VHD files.

More App Streaming refresher: In the beginning, we stored execution content on the App Hub in CAB files.  Everything all wrapped up in one place and this has been a love/hate relationship for a long time.  In 6.0 we moved from CAB files into uncompressed DIR format.  Its the same content, just stored unzipped.  This caused headaches in some cases and made headaches go away in other.  The key thing to know is that the move to DIR format was done primarily as a means of moving toward a MOUNTABLE backing store for the streaming RadeCache\GUID_V subdirectories.

With the coming code, the DIR format still exists, but the streaming profiler will also and optionally, generate a VHD file that has the exact same contents.  At profiling time, this creates a double storage of the generated image, but stick with me on the VHD.

On the client, if there’s a VHD available, and if the machine would benefit from virtualized execution MOUNTING of the content, the streaming client will MOUNT the VHD into the RadeCache instead of creating a directory and writing application bits into the directory.  Notice, writes go away and the cache is “always full”.  The App Streaming client gets out of the “streaming” business and relegates this to the block driver behind the VHD mount.  The important part – huge percentage of the disk writes that would exist, go away.

Here’s what it looks like.  The application names in the below graphic are made up just to convey the point.

Mounting App Streaming content into the RadeCache

In the profiler, the admin tells the profiler to create a VHD on the save.  There’s a new panel for that.  On the client, the streaming system CAN mount the execution content rather than populate it into the cache.

When would it be a good idea to mount?

Answer: Hosted XenDesktop pooled environments.  The streaming system attempts to auto-detect when it is running in this configuration and then if it sees the VHD, uses that VHD instead of creating a directory and populating it.

On physical hardware, like traditional XenApp servers, it is preferable to actually POPULATE the physical cache.  It will survive reboot and this provides most efficient delivery.  So, here using the VHD would not be desired.

We put in the auto detect stuff, but here’s the kicker, we’re DOOMED to get this wrong.  As the admin, you can control your own destiny and there are two registry items added to the streaming space where you can instruct the streaming client on what to do.  Those two registry items are UseVHD and VHDErrorFallback. First, odds are really good that this is documented in even more detail in edocs.  I write it here anyway.


  • Omitted = autodetect
  • 0 = Don’t even think about mounting VHDs
  • 1 = If you see one do your best to mount it no matter what you see


  • 2 (default) – Fall back to DIR if VHD mount fails.
  • 1 fall back to DIR only if VHD does not exist.
  • 0 Never physically populate the cache. Fail the app launch if you didn’t find a VHD.

Both of these are in HKLM\Software\Wow6432Node\Citrix\Rade.   Here’s a screen grab from my notebook.

You can get the App Streaming tech preview bits off of the XenApp or Iron Cove present tech previews.  This is on   Let me know how it goes…

Joe Nord