Have you ever looked into the App Streaming execution cache and said, “good grief! What are all those GUIDs!”? GUIDs are great, for the programmer. For the administrator, they can be a bit more mysterious.
I recently wrote a utility to decode the GUID data of the Application Streaming execution cache, displaying the decoded information to the console, but neater than TTY, it also updates the Windows Explorer display of that space so the “secret” information is exposed in permanent fashion and via the GUI, which is good stuff. The utility is released to the Citrix Developer Network, in source code form so you can tweak it if you’d like.
Download from here, look for the “Rade Cache Decode” link at the bottom of the page.
For background, I have written about the GUIDs before and how they are key to the streaming system maintaining the separation between “profiles” that you can publish and execution “targets” that the streaming system uses to actually use to run stuff. There is more on this in this post.
The idea for this tool actually came from very smart people at Sepago, Sascha Juch and Helge Klein, who I work with on Citrix Profile Management (the artist formerly known as Sepago Profile). They also clarified for me that despite MSDN documentation claiming “system” attribute is necessary for this explorer magic to work, marking the directories read-only gets the job done. Tested and true! Thank you guys.
Update: Dieter Schmitz at Sepago is the gentleman who came up with the idea. Thank you Dieter.
What does RadeCacheDecode do?
Application Streaming can store one or more execution Targets for each App Streaming profile. This level of indirection allows a single set of “Applications” and icons to be published even if more than one execution image is required. This is common for a profile that supports both 32-bit and 64-bit operating systems. While the application is profiled twice to create two targets, there is only ONE profile to publish and only one set of “applications” from an Access Management Console perspective.
A necessary consequence of this is that the execution targets have names that don’t necessarily have any resemblance to the name of the profile from which they came. Targets can be associated with execution systems for a variety of configurable options and these can change from version to version of the profile.
That is, just because a specific target was right for Windows XP German yesterday doesn’t mean that it won’t also be right for English AND German tomorrow. Even ignoring “one to many” advantages of execution targets to profiles, the streaming system STILL would use some abstract term to keep track of the execution targets.
If you’re editing a profile in the Streaming Profiler and you SAVE, all the identifiers of the execution units remain unchanged. BUT – If you Save-As, you’ll get new identifiers. “By spec”, the thing that was “saved as” is a New profile and will mature separately from the original – even if the before and after profiles have the same name. Putting it a bit differently: Two profiles with the same name are not necessarily the same profile, the unique identifiers in the profile define the uniqueness of the execution units and in theory, or the profile itself. The studious reader will see below where at least parts of this break down.The short version: Thanks to the use of GUIDs, the streaming cache manager will never confuse two execution targets, even if they come from different profiles that have the same name.
*What about the administrator?*GUIDs are there just to make the RadeCache space hard to digest. After enough time looking at the Citrix internal showcase farm, you get used to the idea that the execution Target that starts with “1B3” is the MS Office 2007 profile execution target that is used for Windows Vista and Windows 7. Type 1b3, hit tab and you get the right one. Not ideal. Here’s what it looks like in the Windows explorer.
Okay, we know that 1B3* is the MS Office 2007 execution target for Windows Vista and Windows 7. What are the other 5 execution targets?
What you need is something to look up each GUID and to TELL YOU which profile it came from. Yes, it would be BETTER if the streaming client itself had left you a clue, but it doesn’t. Notice that when the streaming client created these directories it KNEW what profile it came from and there can be at most ONE profile in the entire globe that has that GUID. Did it leave you a hint, a small hint? NOPE!.
Ahh, the fun life of being a XenApp adminstrator.
HELP IS ON THE WAY!
The location of the application hub is generally “known” to the admin, but to know which GUID is associated with which profile, takes some work. Once the running application terminates, not even the streaming client knows where the GUID came from. It’s just a directory that exists in the right place, but the link that says that the “1b3” target is somehow related to MS Office is gone, there’s nothing there.
Making it easier
For offline execution, the streaming system stores information that provides the secret decoder information required to convert GUIDs to profiles. The Deploy space holds a copy of the Application Hub content and stores it in a place that has a fixed location (registry configurable and readable from the utility). The RadeCacheDecode utility looks at the Deploy space, sees what execution targets exist for which profiles and uses this information to “decode” the GUID entries in the RadeCache. This should make more sense by example.
Command line execution (readonly)
If RadeCacheDecode is run with the -r (readonly) switch, the utility processes the subdirectories of the RadeCache space, and for each tries to figure out what Deployed profile goes with that execution target.
Example output:RadeCacheDecode -r092b3450-e543-4541-837a-c374cc4e73cc_1 (GoView1067)
Okay, we have now decoded the 4 of the 5 remaining execution Targets on my notebook.
Making it really useful!
Consider the technique that the Windows Explorer uses change each user’s “Documents” directory into “My Documents”. This same activity can be used to permanently improve the readability of the RadeCache space.
When thinking this was a good idea, I tried it out by manually creating files and while I was initially intrigued, my first conclusion was that it had negatives that outweighed the positives. If you read the MSDN docs on the desktop.ini, it leads you to believe that the directories have to be marked “System” for this Desktop.ini stuff to work. It isn’t so. Marking the directory readonly will do the job and with that, we have a solution! Why is “system” bad? Answer: it makes directories disappear from normal directory searches
“readonly” works, so we have a solution.
This time, run the utility without the -r (readonly) switch and it will WRITE to the RadeCache space to mark all of it’s subdirectories with “decoded” versions of the GUIDs. The directories are marked readonly so the desktop.ini stuff comes into play with Windows Explorer and a file named “desktop.ini” is added to each execution Target’s directory to create a “friendly name” to go with the mysterious true GUID_ver name.
The end result is that the next time the Windows Explorer browses to this space, you will see a nice version of the GUIDs – with the name of the profile placed in parens after the GUID. Sometimes it is necessary to force a refresh in Windows explorer to get it to reload the friendly names.
Here’s a picture of the output
We’re making good progress. It is much easier to see these profile hinting entries than just plain GUIDs.
How does it work?
The entry above that says “not deployed” is the hint. Since the Deploy space is at a known location, the decoder utility KNOWS where to look up the execution target GUIDs. While the streaming client doesn’t know what guid goes with what once the applications terminate, the DEPLOY space knows! The Application Hub also knows, but unfortunately, the decoder utility doesn’t know where THE (think plural) Application Hubs are located. The Deploy space is fixed and given large offline streaming usage, this becomes pretty easy to inspect.
The utility loops through the subdirectory space of RadeCache. For all directories that look like a GUID_v entry, it considers them an execution target and then goes looking for GUID_v content in the Deploy space. When it finds a hit, the name of the containing directory in the Deploy space tells the decoder utility the name of the profile from which the GUID_v came.
Awesome! Works good.
What’s wrong with this picture
The studious reader will notice that the Deploy space is named based on the NAME of the profile that is deployed. The Decode utility leverages this fact to figure out what profile a given GUID came from.
This naming in the Deploy space violates the premise that two profiles with the same name, but with different GUIDs are different profiles! Dig into the internals of a .profile file (it is XML) and you will see that the profile also has a GUID. GUIDs aren’t just for guaranteeing uniqueness of the execution targets, they also guarantee the uniqueness of the profile layer.
Good news: the caching system is correctly using GUIDs and will “never” get confused.
The Deploy space SHOULD be done based on the GUID of the profile and all the sub-directories below the Deploy space SHOULD be GUIDs (with no version). They SHOULD be, but they AREN’T and this means that the premise of two profiles with the same name, but different GUIDs are different is somewhat not precisely correct when considering offline content.
In reality, this doesn’t come up because admins tend to stick all of their profiles onto a single Application Hub and this means that the name of the profile is a unique key. Still, know that this isn’t right and know that I’ve been chasing a “fix” for this for over 2 years – so far, with no fruit. The App Hub side is fine based on name. The Deploy space should be GUID based. Okay, I’m off my soapbox.
Good enhancements to RadeCacheDecode would expand the profile search to go beyond the Deploy space and also consult the network Application Hub. The utility should also use the COM based SDK whose webpage it is posted in. That is, the utility looks in subdirectories of the Deploy space to figure out which profile holds a file with the right name. This breaks the separation of the profile as a programatic thing from looking behind the curtain. I could have coded it that way, but it just seemed like a lot of work to open up a bunch of XML files to peek for GUIDs, when all I wanted to know was presence (is it there, or not?).
The “ultimate” enhancement to RadeCacheDecode is to change the streaming service itself so that when it creates RadeCache directories, it creates the desktop.ini file directly. As of Streming Client version 5.2 (XenApp 5 Feature Pack 2), this does not happen – but now we know how…
To achieve almost the same thing, you could run RadeCacheDecode on a timer via some automated means. It needs to be run with power so it can see and write to the RadeCache space, but if you do this, your desktop.ini entries should always be pretty much correct. I coded the utility to WRITE only if the existing stuff is not “correct”, so you can run it repeatably and the desktop.ini files will only be written occasionally. This was probably overkill.
If you find it useful, let me know…
Citrix Systems Product Architect – Application Streaming