There’s now many different application virtualization technologies on the market. It appears currently that Microsofts App-V is the market leader with VMWare ThinApp the second most widely used solution. A few years ago the feather in the cap for VMWare with ThinApp was how portable the applications can be. This is still a major selling point, however the product has also progressed significantly over the last 2 to 3 years. VMWare achieve portability by removing the requirement for a client software to be on an end user device in order to run a virtualized application, this certainly set it apart from other solutions such as App-V. Application installs are simply captured with very little input required during the process. The Capture tool can also output ‘standalone’ .exe files that serve as entry points for the application. So as an example, you could capture an application and grab the .exe say for, Skype and put this on a USB key so no matter where you go you have it available and you can even execute it from your USB key. This coupled with the advantages shared with all other virtualization technolgies such as isolation mark ThinApp as a very attractive option for any IT shop! This is not the only option, however as you can also generate an MSI wrapper to deploy your virtual ThinApp application via your traditional Distrubution System, as well as using the new App Sync option which enables you to stream your application from a central point, similar to Microsofts App-V. Also similar to App-V you can allow isolated application to see each other, incase of application dependencies by using App Links. It’s funny but with the newer versions of ThinApp, it seems to become more and more like App-V. Likewise with the newer version of App-V, it seems to become more like ThinApp in it’s simplicity, flexibility and scalability.
VMWare ThinApp is configured to save user settings to a Sandbox environment. You can configure where this sandbox lives and also what level of data can be written to this sandbox which we will cover further down. As stated in the previous paragraph, the capture process is very straight forward, requiring very little input. This can be automated through scripting or by using third party tools such as Flexera’s Virtualization Pack. To illustrate this I will go through the capturing steps and options.
The Welcome screen is pretty standard and includes useful info and help tips as well as links to a video and community site.
In the prescan dialog you can view the locations the snapshot or capture you are about to carry out of your applications install, will monitor for changes. Anything changed, added etc. within these directories and reg hives will be captured and put in our virtual app. Pre-Scan will take a before ‘snapshot’ which is analysis the current state of these directories and reg hives so it can detect what has been changed once we finish the capture process.
Above we can see that tool is scanning these locations during the Pre-scan
All shortcuts or probably more accurately, entry points for your application will be listed here. Depending on your capturing VM, this may return many detected entry points on the machine. It should have any unrelated entry point to the application left in an unchecked state. You will want to ensure anything valid for your application is left checked. This will dictate what shortcuts are created in your generated MSI, as well as what ‘standalone’ entry points get created in order for you to use these in a portable fashion as stated earlier e.g. on a USB key or possibly a File Share or whatever….
ThinApp has native integration into VMWare Horizon. You can point your applications for use in this environment by configuring this here.
The Groups Dialog allows you the ability to lock down the application for use by only certain approved groups. Or you could leave it open to everyone but this is likely not a very secure solution when considering company security and also licensing.
The Isolation dialog allows you to set the exact level of isolation. In this sense you can set whether your application can write to the local machine if required or you can select to only allow the application to write to the pre-defined user writable locations. This sets the amount of data which will be written to the sandbox versus the local machine.
In the above dialog you can set where the sandbox should live. You can configure this to the default which is the AppData location. You could allow ThinApp to write the sandbox to the same location as the application which is great for USB as the application will not require to write anything to the local machine. Finally you could choose to write the Sandbox to a custom location such as a User Drive e.g. H:\, U:\
Next is the usual schtick with whether or not you would like to allow VMWare info which can help with their quality research.
The next dialog sets both the project name and the location where the virtual application will be outputted to for building.
Next dialog is one of the more important. You can set the primary data container which will store the main information required for the virtual application. This can be included in one of your entry points .exe file or you can set this in a .dat file which will live alongside the entry points and leveraged upon launching. You can also create an MSI for deploying via your favorite Software Distribution system. You can also set whether or not compression is applied during the build. This can slow first launch slightly or general performance if using the entry points ‘standalone’ you could use this for larger applications to save on disk space.
Next you can save your project
This dialog allows you to edit your Package.ini file which is like your main project file. You can use this file for manually configuring certain settings such as Permitted Groups for Again setting who can access the applications. Also for setting app links to allow isolated apps to access one another. Also for App Syncing capabilties. And also what level of Isolation the application can have which was also set via the GUI as seen above. You can select to build the application.
That is the capture process complete. You will then get the output. You will notice variablized folder names representing a mirror of a Windows File System but this is the virtual file system. You will also notice text files that contain the captured registry. There will be a bin folder containing your .dat file if you chose that earlier alongside all of your entry points and your generated MSI if you selected this. If you browse through the virtual file system folders you will notice an .ini file on every directory level, you can modify these as desired. You can change these to change the isolation level of an individual path rather than for the entire application as we had covered earlier.
You can script around virtual applications. Why may you want to script with a virtual application. For example you may want to set something with a text file in the virtual environment based on the usersname. In which case you could write a vbscript which will execute when the sandbox is opened as the app launches. Or you could use several other trigger points as per the VMWare Template which you can fine HERE.
To get this into your application for use. You simply place the script in the root level and then run the bat file to run the build again. Similarly if you change any of the .ini files for isolation or the Package.ini file to apply the changes you need to run the .bat file to build again.
Upgrading a virtual application is very simple also and requires setting a few manual changes to the .ini file and .exe file name. For more you can check that out HERE
