VMware ThinApp Blog

Normally Windows OS only allows you to run one instance of explorer.exe. This makes it a little more complicated to add an entry point to Explorer and launch it inside the bubble.

Here are step-by-step instructions on how to install, configure, and capture JAVA Runtime version 1.3.1.20 as a ThinApp Package. These instructions are provided "as is".

It's not uncommon to use a local copy of Internet Explorer (IE) as a way to present virtual applications to the desktop. The most common example is a virtual package of Java that is then launched with the local Internet Explorer. As such, this normally works without any modification. However, in a Vista environment, you can run into a unique circumstance.

• The .asd file is used for keeping track of when last checked the AppSync location

• The .asl file is used to keep track of how much we downloaded and it contains a list of block signatures for the new file (we use these block signatures to find blocks that we can copy from the existing old file)

• The .ase is the complete new updated file waiting to be applied as the .exe file (contains blocks both from the old .exe file and from the update file)

If a download is interrupted during AppSync it continues where it left of the next time the user launches the application.

The location of the AppSync log and cache files can be specified within package.ini and with the parameter "UpgradePath=".

UpgradePath is also used for specify the location for integer updates.

Check out the August 27^th Podcast from the VMware Communities team.

http://blogs.vmware.com/vmtn/2008/08/thinapp-for-vi.html

Do you have a ThinApp packaged application that doesn't like to shut down because it launches CTFMON.EXE (either from the local system or the virtual package)? This is a common issue with Office 2003, Office 2007, and Internet Explorer type packages. The provided instructions below, will walk you through how to disable CTFMON.EXE for a ThinApp packaged application.

AppSync allows you to update your ThinApp applications via http or https. However, we don't always have a web infrastructure to use or perhaps we would rather use a file share or replicated share like DFS or a NAS device. With AppSync, you can use these types of locations for the AppSyncURL= field. Remember, all we need is a URL location specified for the feature to work, so if you want to use a file share, follow these guidelines for your configuration of choice.

For a UNC:

\\server\share\path\to\file "convert this to" file://server/share/path/to/file

For a Local path:

c:\path\to\local\file "convert this to" file:///c:/path/to/local/file (note there are 3 slashes following file: here)

Recently, I've been asked on how one would use THINREG in a login script to auto-register network based ThinApp packaged applications to a workstation. While this question was asked in the context of VDI workstations, it could very easily be used outside a VDI implementation (on physical workstations attached to a network) as well.

There are two scenarios to consider with AV.

1. Files you packaged yourself and are delivering to end-users
2. Files the end user or app might try to create/modify at runtime.

AV systems cannot scan inside of a Thinstalled EXE.    You can protect against this by making sure your packaging computer has AV installed and up-to-date before you build into an EXE file, since the ThinApp project structure is just normal files on the filesystem your AV should scan these.   

If you inadvertently package a virus/Trojan inside of one of your packages, then two things are true:

1. The virus Trojan will be largely unable to spread to the rest of the system.  For example, viruses and Trojan typically to spread by writing to HKLM\...\Run, the Startup folder, or overwriting system32 files.  In all of these cases ThinApp will sandbox those changes, so when the computer restarts or the user logins in again – the Trojan will not run again because those changes haven't occurred.   One exception is that by default we don't sandbox writes to network shares, so if you have exposed writable network shares a Trojan could spread through this.
2. If the app tries to copy files from inside the package to the system or makes a network connection and tries to download new content (usually EXE files), ThinApp will write these files to the sandbox.  The sandbox is just normal plain files on the filesystem, and your AV system will definitely scan and quarantine anything detected as malicious.

Because ThinApp doesn't use any device drivers it is compatible with all AV solutions.  The only issue we have is the occasional false-positive, but that happens with everyone and this usually gets correct by AV vendors within a few days.