Application virtualisation has become an important part of desktop virtualisation strategies. Tools like VMware’s ThinApp 4.7 allow organisations to deploy a single application across hundreds (even thousands) of desktops without having to install or maintain separate instances. But configuring an application for a virtual environment can be troublesome and time-consuming.
In this tip, VMware expert Mike Laverick explains the process for configuring a common application such as Adobe Reader X.
Over the last couple of weeks, I’ve been looking at VMware’s View 5.0 and ThinApp 4.7 technologies with the goal of virtualising applications. It should be a relatively easy task, I thought. But, I quickly learned that
This all became apparent when I tried to configure Acrobat Reader X as a desktop virtualisation app. After outputting the ThinApp, I was getting all types of errors and references to lost .DAT files.
Acrobat Reader X is a popular application, and if you’re embarking on a Virtual Desktop Infrastructure (VDI) project, you should use application virtualisation to deliver as many apps as you can.
Understanding the Setup Capture component with ThinApp
First users need to “sequence” any application for virtualisation. It is a process by which the application virtualisation software "captures" the installation of your software. Although there are different ways of sequencing and there is how-to documentation for each of these ways, the process isn’t always easy.
Sequencing or recording can be achieved by pre-scanning a clean system and then monitoring the changes occurring to the file system and Windows register. Once the software is installed, a post-scan identifies what has changed during the installation to the operating system and compiles those changes or deltas into a virtualised application.
Default settings will work in many cases, but there will always be an annoying 5% of the settings that will not work “out of the box”. That’s where I stood with Acrobat Reader X.I went through nearly a dozen captures using different settings. For example, most application virtualisation software detects the .EXEs loaded and copied to the virtual machine during the recording process. In the world of ThinApp, these are called entry points, but it’s not often clear what counts as a valid entry point. After all, many times even the application owner or creator doesn’t know the purpose of every file in an application.
Figure 1: This screenshot shows the Capture entry points discovered during the recording process. Good application virtualisation software knows to ignore the executable files that make up the software installer.
Typically, not all entry points are selected, and frequently it’s not clear from the application virtualisation vendor or the original application whether or not these should be included. That can leave the application packager in doubt about which entry point to use later in the process.
Figure 2: You must enable the “Generate MSI” Package if you want to stream your ThinApps. The Compression option is useful in streaming the ThinApp as it reduces the bandwidth required to bring it down from a shared location to the end user’s machine.
Most application virtualisation vendors are able to adjust the level of isolation for the resultant virtual application. Many application virtualisation vendors also have a concept of sandbox (an isolated area where the application executes), but sometimes this concept can break legacy applications (see Figure 3).
Figure 3: This screenshot illustrates the file system isolation modes.
Depending on how they were written, different applications need higher or lower privileges to the files system. Modern, well-behaved applications work well with basic setting. Older legacy applications might need a different level of isolation represented by "WriteCopy Isolation Mode".
At the back of my mind was a niggling doubt that maybe, just maybe, if you combined some of these different levels of settings together (basic and various levels of isolation), then it might just work. I tried a combination of some settings in ThinApp with Acrobat Reader X and sadly none of them worked. I even tried changing the source operating system for creating the ThinApp from Windows 7 to Windows XP. Still no luck.
At this stage, I consulted the VMware Forums and found the basis for a solution to my problem around application virtualisation.
Application virtualisation tips and tactics
Acrobat Reader X has its own isolation layer called protected mode which “opens a PDF file in a read-only, sandboxed environment until you determine that the document is safe”. The feature aims to protect the user from a range of attacks using controls to do the following:
- stop malicious code that deletes files or modifies system information;
- stop data with dangerous code from entering into memory locations that are defined as protected by the operating system;
- make it difficult for attackers to find and target system components; and
Administrators can use the Adobe cross-domain specification to create policy files that allow them to manage cross-domain access at the server level. They can enable or disable cross-domain access as required.
Figure 4: The "Protected Mode" error message is caused by the conflict between Acrobat Reader’s sandbox and the ThinApp sandbox.
If the “protected mode” is enabled, the default entry point in ThinApp called “Acrobat Reader X (10.1.1).dat” generates an error message, and depending on the operating system will either constantly load with this error or not start at all (see Figure 4).
Users can get around this problem by disabling the protected mode feature during the recording phase, before starting the post-scan phase, which typically takes place after the application has completed installs. It is possible to open applications during the recording phase and make changes, which then become the defaults for all users.
This problem with virtualising Acrobat Reader X will probably affect App-V,
InstallFree and Spoon,
and you might want to use the same strategy you used to get around the hurdles of application
Application virtualisation depends on a number of requirements for it to be successful. Patience and learning from the mistakes of others are just as important as understanding how your application virtualisation technology and source application works. Be aware that you may have to arrange some trade-offs and compromises to make your virtual applications work the way you want them to.
Mike Laverick is a former VMware instructor with 17 years of experience
in technologies such as Novell, Windows, Citrix and VMware. Since 2003, he has been involved with
the VMware community. Laverick is a VMware forum moderator and member of the London VMware User
Group. He is also the man behind the virtualisation website and blog RTFM Education, where he publishes free guides and
utilities for VMware customers. Laverick received the VMware vExpert award in 2009, 2010 and
Since joining TechTarget as a contributor, Laverick has also found the time to run a weekly podcast called the Chinwag and the Vendorwag. He helped found the Irish and Scottish VMware user groups and now speaks regularly at larger regional events organised by the global VMware user group in North America, EMEA and APAC. Laverick published books on VMware Virtual Infrastructure 3, vSphere4, Site Recovery Manager and View.
This was first published in December 2011