or option A you'll need to consider the specifics of the desktop pool, specifically the template that the VM's are based off of if you're using View Composer and whether this is a persistent or non-persistent pool.  When using View Composer its likely you'll be doing a recompose and refresh operation periodically which will affect the linked clones off of the C: drive.  You can use that to your advantage because it is an opportunity to not just patch the OS but update the thinapp applications on the C: drive.  Consult the View Admin guide for the details of View Composer, but basically you are going to power on the VM that the other desktops are based off of, patch it, put some new thinapps in, and then take a snapshot.  At that point, you go to the View Administrator and say that you'd like for the desktop pool to now be based on that new snapshot.  In one fell swoop you've updated the OS and Applications.  For thinapps that you deploy in the vm its hard to beat this and there are very few downsides.  The limitation you do get is that updating only the thinapps has to be done using some other process, like a script that pushes the.exe's out to a certain directory, or configuring the packages to use an AppSync url, or use a sw distribution tool to do the work for you.  So go through the process of a View Composer refresh and weigh that against the effort to update via the other methods discussed in Question 3.  Summary - View Composer + C:\ThinApps = very efficient OS and App management

Option B is slightly different in that it utilizes User Data Disks.  UDD's are basically a separate vmdk (virtual disk file) that is logically attached to a virtual desktop.  I tend to think of them as the equivalent of USB drives as they are a different drive letter, can be moved between vm's, and maintain more of the personal data such as profile, my documents, and typically user data.  (profile and my documents are automatically redirected here from the C drive)  So there is more of a separation between this location and the C:\ of the vm which is maintained by the Administrator.  The advantage of that is that users can have their own directory of ThinApps which can either be populated by the Administrator or they can drag over from a central location.  This gives the user some control over which applications they want to use but Administators will need to create a central directory of ThinApps for them to choose from.  So it's not truly user installable apps because the administrator has to prepackage the app and virtualized apps are never installed anyway.  Summary - UDDs (D:\ThinApps) provide a location with a little bit more user liberty that is not affected by View Composer ‘Refresh' or ‘Recompose' operations on the template VM. 

Option C is for those apps that you have decided should be streamed.  A fileshare location is all that's required but I'm a big proponent of DFS for this as a simple way to provide a logical link between your desktops and your virtualized applications.  When we get to Part 3 or Part 4 of this series we will get into the details of application registration, but at this point just know that it's handy to be able to reference an entire directory of applications without putting in a server specific share.  Its probably reason enough to just mention that to provide a redundant fileshare is important and DFS is a simple means to do that.  The fileshare should be redundant and have plenty of bandwidth and locked down to read-only for users of course.  Summary:  Streaming Apps need to live on a highly avail fileshare with plenty of network throughput

Now for Question 3.  How do I manage updates to virtualized applications?  There are two methods of updating thinapp packages - Side-by-Side or Appsync. 

Source: http://blogs.vmware.com/thinapp/2009/10/integrating-thinapp-packages-with-vmware-view-part-2.html