To give a simple answer do the products work together, yes. ThinApp will work a couple different ways you can have just a short cut to the executable and have it run from a file share, integrate it into your base image using a virtual registry and file structure and you can do app streaming, but this will defeat you purpose to keep master image small as streaming will download the blocks of data reqiured start the application and then blocks reqiured to run different components of the application.
ThinApp can run a lot of applications, but not all applications can or should be virtualized and they will degrade in performance. You can deploy the virtual applications a few ways, 3rd Party management programs (such as AppSense), Group Policies using VBScripts and by creating a shortcut on the desktop and putting all applications in a folder. That is just 3 ways, and I will bet many people have other ways of deploying the applications. By reading your post it seems you may be fimiliar with App-V from Microsoft, if that is so I would not really compare these two products as they really deliver the applications differently. App-V only does Application Streaming so you lose your thin storage.
Where you say the following
"integrate it into your
base image using a virtual registry and file structure and you can do
app streaming, but this will defeat you purpose to keep master image
small as streaming will download the blocks of data reqiured start the
application and then blocks reqiured to run different components of the
Would this only affect the linked clones and not the master? Given it does I assume it does increase the size of the clone differential thus increasing the overall footprint? But then I guess you get the benefit of application virtualisation as opposed to mutliple larger master images?
If you run all apps off a central fileshare (i.e storage mount point) via a desktop folder, I assume this executes the app locally (i.e no local registry settings via local install). The concern I would have there is performance, same as with standard SBC?
You've got the right idea. Find the most common denominator base image and then thinapp everything else you can.
With thinapp you can limit execution. So you can set the thinapp to only allow use by the a certain AD group. You can create an msi file as part of the thinapp build. With group policy you can turn around and push this msi file to the users of the AD group. This will then register the app and allow it to run properly on login.
Here are some how-to's on the AD deployment option
Another typical option is to deploy the apps with login scripts that are tailored to deliver the proper apps to the proper user groups.
In your experience how does this impact the storage footprint on the linked clones?
Everything you thinapp & distribute by other means, even just file shares & ACLs come out of the base image. If you run the thinapps from a fileshare and the .msi is only for thinreg and shortcuts you're talking a few kB/app for the deltas.
Since I posted AD links, here's some newish links using login scripts: