Today I was at the “ThinApp – going deep on capturing applications” session. I expected a real technical session about how to tweak a captured application and maybe some best practices. It was a little bit of a soft presentation until one of the presenters showed something used in R&D at the moment: ThinApps that run in a second (virtual) desktop.

It started of kind of slow, because the presenter started of with explaining what ThinApp was and what the advantages where. I guess when 90% raises their hand when you ask who worked with ThinApp before, you can skip the basic explanation (assuming the other 10% already knows what ThinApp can do, otherwise they wouldn’t be in a session for advanced audience).

After the slow start, he went further with a short video of automating the capture and build of ThinApps (which can be accomplished just by using batch-file, VMware Workstation and the ThinApp runtime).

MSI building and thinreg were also discussed. Both can handle shell integration, but only limited. This will be improved in the future:

– rightclick
– dde
– mime types
– limited support for com objects
– support for protocol: http, mailto

And out of nowhere there it  was: ThinApps that will start in a second (virtual) desktop. The guy said they use it currently as R&D prototype and it isn’t even sure if this ever will be available. But this feature is way too cool. Because what happens is (and correct me if I’m wrong, because it’s a few hours ago) you start the ThinApp application and the desktops switches to a second (virtual) desktop. This virtual desktop has full shell integration. The user can also install their own applications in this second desktop. You had to be there to see how it actually worked, but it looked pretty cool.

Overall, the session was not that technical deep dive at all. I guess ThinApp is not that hard to master ;-).

Earlier today I had another session about ThinApp, here are my quick notes:

Planning and designing ThinApp implementation

in memory and compressed

licenses can be audited with 3th party tools

MSI will create file accociation ad add/remove program.

best practice capturing:
– clean PC
– use oldest os in environment
– Leverage VMware workstation an snapshots
– Add the VMware workstation VM to AD to enable AD security group assignment
 – disable dynamic machine account password rest

– source – storage of ThinApp project folders
– UAT – used to stage ThinAppp packages for user acceptance testing (UAT)
 – use a subfolder of UAT for Applink-accessible plugins
– PROD – High available and load balanced distr. point
 – use a subfolder of PROD for Applink-accessible plugins

Good practices:
– backup source and prod

package naming conventionL
– vendor_appname_appversion_packageversion

AD groups:
– make group name the same as application name
– exclude version number from group name
– use dedicated OU to store the package groups
– create a seperate group for containing user objects, and add this group the application’s  dedicated group

Logon script:
-Thinreg in login script