Does my per-user RadeCache content for Application Streaming follow me from machine to machine?  Given you are using Roaming Profiles, Flex or even … Citrix User Profile Manager, this is an important question for administrators. 

The answer is more complicated than a single sentence.  Here’s a shot at it from a few paragraphs.

Consider the “layers of glass” with Application Streaming and Isolation.  The “per-user level” physically resides in a per-user space of the true disk.  It is here, on purpose so that it can roam with the user from machine to machine.  The details though are more involved.

The user content for any given user consists of two components, the files and the registry.  They exist at these locations.

  • Files:         %APPDATA%\Citrix\Citrix\RadeCache\GUID * (not really, read on)
  • Registry:    HKCU\Software\Citrix\RadeCache\GUID

NOW – The above is not the whole story.  The above USED TO BE the whole story, but we’ve changed it for Vista and in Streaming Client 1.2, for Windows XP and 2003 also.

Some customers like to redirect APPDATA to network servers and since the isolated disk top layer is accessed “alot”, as Streaming folks, we don’t want anything in the isolation stacks to actually be redirected off of the local machine.   Does the isolation system support redirecting to a network server, sure.  Do we want that to actually happen?  No.  Doing such would have bad effects on performance of the app, not to mention being a good network citizen to avoid putting all that file traffic onto the network server.

With Streaming Client 1.2 (XenApp 5.0), the location of per-user disk storage is moved; the registry location is left alone.

New locations are:

  • Files:         %LOCALAPPDATA%\Citrix\RadeCache\GUID *
  • Registry:    HKCU\Software\Citrix\RadeCache\GUID

But wait, there’s more.  While LOCALAPPDATA exists in Vista, it doesn’t exist in Windows XP. The directory space however does and is accessed in the same location for both XP/2003 and Vista/2008.

Notice that when you go look on your own machine, the expanded %LOCALAPPDATA% has hidden parts.  Example: “%USERPROFILE%\Local Settings\Application Data”.  The last two directory levels here are HIDDEN, so they don’t show up with the default Windows Explorer.
Here’s the per-user DISK storage on my notebook:

Each of the listed GUIDs represents the disk storage for the per-user applications (profiles) of whatever applications my administrator has published to me.  


The per-user disk files are no longer part of the default roaming profile and this means that there is a window of trouble.  The per-user registry IS part of the roaming profile, but the per-user FILES are not.  AHH!  I see trouble on the horizon batman!

Notice that this is done to allow redirect of APPDATA while keeping the RadeCache data from being accessed across the network.  The downside is that now, without a little work, the per-user file storage will not be carried as payload during roaming.  A necessary evil. 

Solution is to manually add the App Streaming per-user RadeCache location to the list of directories that should be roamed for users during logoff/logon.


Each time an isolated application accesses a file from an isolated location (Say \Windows\System32), the isolation system has to first check if that file exists in the higher layers of glass.  It starts with the per-user space and the answer is almost always that the file is not there.  Still, it looks.  This act of “looking” is cheap on a local hard disk, but it is dreadfully expensive if the per-user layer of isolation is redirected to a network. 

Generally speaking, executable content shouldn’t be in the per-user space and you as an admin can even enable settings during publishing to completely prevent this (user profile security).  Still, the disk accesses will be occuring and chewing up performance. 

The less of the available evils was to keep the per-user file space from being redirected to network and this means using LOCALAPPDATA rather than APPDATA for per-user file cache storage.  This allows APPDATA to be redirected, while retaining performance for isolated applications.  The downside is that there is a new directory that has to be added to the sync list when logoff/logon.  Please do that last part…

Joe Nord