Packaging non-executable files as VMWare ThinApps

We are running a VMware Horizon/vSphere environment with a number of virtual desktops. And because I do not want to have all software available on all desktop pools nor do I want to maintain a stupid amount of golden images I was looking into how to create virtual applications using VMWare ThinApp and linking these to specific desktop pools.

And since Murphy likes to make my day miserable I obviously started with the worst application of them all.


VMWare ThinApp allows you to virtualize and create portable versions of applications. It was previously known as "Thinstall" and was bought by VMWare back in 2008.

VMWare ThinApp takes a snapshot of the system prior to the installation of an application, then the application is installed and after the installation another snapshot of the system is taken.

The differences between those two snapshots are then packaged into an executable file.

To make this work VMWare ThinApp provides virtualized system resources such as environment variables, files and registry keys. Upon execution of the virtualized application the application is presented with a merged view of the physical and virtual resources, fooling the application into thinking it was properly installed.

Usually a virtualized application is linked to an actual executable file such as an .exe file which will be started when you execute the virtualized package. For applications like Adobe Reader or any other application that gets fully installed on a system this works fairly well.

But in my case the application I wanted to package consisted of an installer that only provided the files necessary to run the application (which is hosted on a server share). And in addition to that I had to deploy documentation (.pdf files) and internet links (.url files).

I had quite a hard time figuring out how to do this because the documentation is severely lacking for such a use-case. (Probably since this is not really a use-case for this software.)

After preparing the system and installing the VMWare ViewAgent and VMware ThinApp Enterprise software I let the ThinApp software take the snapshot prior to installing the application with the default settings selected.

Once that was done and the software was telling me to now install the application I did exactly that and also imported all the required registry settings and copied all additional files (the .pdf and .url files) to their destination folders.

After all the required configuration for the application was done I let the ThinApp software take the second snapshot.

After the second snapshot was done I had to select a so-called "Entry Point", the executable file that is going to be started when the packaged application is executed.

Here I simply selected any one file. It did not really matter much which because I had to edit the package definition anyway. For the remaining options until the "Isolation" configuration I used the defaults.

Because the application I am trying to package (or rather the users using the application) requires write-access to the local file system I had to select the "Merged" isolation mode for the file system. More on isolation modes can be found in the VMWare knowledge base.

Except for taking part in the "Quality Assurance Statistics" (which I declined to take part in), giving the packaged application a descriptive "Inventory Name" and at the end enabling the option to also create an MSI package I left the default settings for all the other options.

Upon completion of the wizard (without actually building the virtualized application yet) all changes to the system between the two snapshots were saved to "C:\Program Files (x86)\VMware\VMware ThinApp\Captures\<application name>", which you can access by clicking "Open Project Folder" in the wizard.

In this folder you will find a number of folders as seen above. These folders will contain various files and folders you can delete because they serve no purpose for the application you are packaging. Windows Update logs, other log files, temporary files, and so on. Also the three files "HKEY_CURRENT_USER.txt", "HKEY_LOCAL_MACHINE.txt" and "HKEY_USERS.txt" will contain a number of registry keys you can safely remove from the files. But be careful not to delete too much.

In e.g. the folder "%Common Desktop%" you will find all files you copied to the common desktop between the two snapshots. In my case the .lnk file, the two .url files and three .pdf files.

But the really interesting file is "Package.ini" which contains all the configuration options for the package.

In my case the file contained the following entries at the very bottom (shortened to just include one of each type):

[Start Application.exe]

Source=%Common Desktop%\Start Application.lnk

ReadOnlyData=Package.ro.tvr

Shortcuts=%Desktop%

[Internet Link 1.exe]

Shortcut=Start Application.exe

Source=%Common Desktop%\Internet Link 1.url

Shortcuts=%Desktop%

[Documentation 1.exe]

Source=%Common Desktop%\Documentation 1.pdf

Shortcut=Start Application.exe

Shortcuts=%Desktop%

After cleaning up the files and folders in the build folder I ran the build process by executing the "build.bat" script with admin privileges.

I then linked the resulting .exe and .msi files to a desktop pool in our VDI environment and was severely disappointed. Executing the resulting .exe files (even the ones that were supposed to contain nothing more than an internet shortcut) was extremely slow.

After much back and forth and at least a dozen test builds I finally found a way to make the start of both the .url and .pdf files as quick as starting any other regular files of these types. In fact, I even made the .url files obsolete in the process.

VMWare ThinApp allows for a very poorly documented feature where you do not actually make the file itself an executable with the whole virtual file system attached but you package a shortcut to an existing application with your file or url as a parameter (as long as that application supports this).

To achieve this I modified the "Package.ini" file to contain the following lines, replacing the lines above:

[Start Application.exe]

Source=%Common Desktop%\Start Application.lnk

ReadOnlyData=Package.ro.tvr

Shortcuts=%Desktop%

[Internet Link 1.exe]

;ReadOnlyData=Package.ro.tvr

Shortcut=Start Application.exe

Source=%ProgramFilesDir%\Internet Explorer\iexplore.exe

CommandLine=%ProgramFilesDir%\Internet Explorer\iexplore.exe http://www.google.com

Shortcuts=%Desktop%

RetainAllIcons=1

[Documentation 1.exe]

;ReadOnlyData=Package.ro.tvr

Shortcut=Start Application.exe

Source=%ProgramFilesDir%\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe

CommandLine=%ProgramFilesDir%\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe "%Common Desktop%\Documentation 1.pdf"

Shortcuts=%Desktop%

RetainAllIcons=1

The .url files were now obsolete because the resulting .exe files already contained the URLs in the shortcuts. The .pdf files still had to be present in the "%Common Desktop%" folder though.

And after figuring out that it worked like this I could even get rid of the .lnk file by simply pointing the "Source" and "CommandLine" parameters of the "[Start Application.exe]" section to the same destinations as the .lnk file.

With this starting the application and opening the internet links and documentation files were as quick as on any other system with comparable specs.