A couple days ago, I wrote a blog describing how the next version of App Streaming will enable MOUNTING the RadeCache\GUID_V directories rather than populating with file copies.  This mounting of application content does wonderful things to enable separation of maintenance for the base operating system and for Application images as well as making the “disk writes go away”.

Received an interesting inquiry today from our internal Citrix farm Admins.

Can you tell me which VHD file is the backing store for a streamed application VHD based launch?  The GUID matches, but how do I KNOW it got the right VHD file?

The premise is there there are multiple Application Hubs scattered around the companies networks, all with identical contents, and the admin wants to make sure the user was connected to the App Hub closest to their execution machine.   The user is in London – is the VHD file supporting application execution located London, or possibly Fort Lauderdale?

Citrix has good networks, but we don’t want to hop the pond that many times!  Side note is that the answer for the suspect user turned out to be that “its wrong” and this will presumably be solved via “alternate profiles” in publishing the streamed apps and listing the UK ranges.

Back to the subject of this post.

Admin wants to look at the mount point for the RadeCache and see where it is mounted.  There are likely easier ways to accomplish this, but I put one out in the pages that follow.

Where the VHDs are

Step 1: Never trust a GUI!  Use Explorer to look at the \Program Files\Citrix\RadeCache and you can be easily lead to believe that the mount point is a directory.  IMO – the differences in the icons just don’t get the point across.

Step 2: Administrator rights command prompt.  Will actually need power a bit later in this post.

  • CD “\Program Files\Citrix\RadeCache”
  • DIR

What you will see is a directory listing of the GUID_V directories and a note from the command output that the “directory” we are interested in, is actually a ” junction”.  So far, so good.  In this case, the output was

21/06/2011  12:02    <JUNCTION>     f72469ad-feb7-4d05-9270-cf920c2e738b_1 [\??\
Volume{798d63d1-9c1e-11e0-8838-5a994e923301}\]

Things to observe.

  1. Date formatting has days and months backwards, but for today’s discussion, we’ll go with it because while I’m in the USA, the machine is in the UK and solving this has nothing to do with where the VHD came from.
  2. The GUID_v matches the profile for the Microsoft Office 2010 package which is running on this machine.  Here’s a nice post that describes running Microsoft Office streamed in much detail.
  3. The volume ID is also listed, starting with “79”.
  4. Notice, nothing displayed by the directory enumeration tells where this JUNCTION points.

“diskmgmt.msc”

First instinct is that disk management in windows will unravel the mystery.  It won’t, but it’s a good exercise.

The “disk” we care about is that 1.72 GB one at the bottom, this is the captured application content holding Microsoft Office 2010.

Side thought: are disk volumes for all streaming packages really titled “New VhdDisk”?

Point at the disk we want to inspect, right mouse button, properties.

Only thing here of use is the volume ID starting with “79” (it’s a match), but we already knew this from the directory enumeration.  We did learn that it is “Disk 2”.

Bottom line – diskmgmt.msc wasn’t any help.

Break out higher power tools – diskpart.exe

Using diskpart, only one command is needed: “list vdisk”.  The other important command is “exit”.

We have a winner!  The backing store for the GUID_V RadeCache JUNCTION is listed in the command output.  In this case, it says that the file server for the VHD is located in “uk” and since the machine I’m running on is also in the UK, this is … “correct”.

I should add that admins will solve variable App Hub location via a number of mechanisms.  “Alternate profiles” in XenApp publishing is the one being used by this administrator.  This has the publishing system provide different App Hub locations (different .PROFILE file locations) to the execution machine based on the user’s (XenDesktop machine’s) IP address.  Other admins use NetScaler’s or DNS lying to make the same DNS name point to a local solution no matter where the machine is located while using the same “name” for publishing world wide.

Joe Nord