We have a guest post today from Jason Bassford, VCP, a Senior Technical Support Engineer in our Burlington Ontario office, who asks: What's the definition of a ThinApp "clean machine"?
First, a little bit of background on the process of capturing an application. You take a prescan, which records all of the files and registry settings of an operating system prior to installing the application. Then you install the application and take a postscan – which records all of this information again. The prescan is compared to the postscan and anything that is different is added into the project from which the virtual application is compiled.
If the application installs a set of files that are required for it to work, but the capture machine already has those files, the comparison of the prescan and postscan will pick up no change and those files will not be included in the project. When the virtual application is compiled, if it is then deployed to another computer that does not have those files, it will fail to work – because the files will not be found on either the deployment machine or in the compiled application itself. For this reason, it is always best practice to capture everything that the application needs to work. Don’t ever assume that something will always be present on every deployment OS.
When we say a "clean machine" we are saying a few different things. The simplest (and most often correct) answer is that the machine has a default installation of an operating system, a service pack, and ThinApp itself. Nothing else. In other words, it has the very least amount of software that’s possible to have installed but still function. In this way, there’s the greatest chance that everything that an applications needs to run will be captured during its installation. This definition accounts for about 95% of the problems we see with users where we are unable to reproduce their problem in-house: because we always work with a baseline image of a clean machine, and we find that often isn't the case with the support calls we get. Before contacting Support, first make sure that you're using a truly stock operating system.
However, there are some circumstances where this won’t be sufficient. For example, your deployment machines are in an environment where they have some type of software or operatings system patch installed that changes the way in which an application installs itself. During the application installation, it sees this in place and installs different files than if it were not in place. So – if you capture an application on a traditional clean machine, that does not have this software, it will fail to include the components in the installation that are required for it to work on the deployment machines that do have this software. In this scenario, we need to redefine "clean machine" to mean an operating system that also has this software component prior to the prescan.
A good rule of thumb for when you can use a non-stock OS as a capture machine (and only if a stock OS fails to produce a working virtual application) is if there is a corporate image of some type involved where everybody always gets the same set of software beyond the normal stock OS. We saw one where no matter what the user did he was unable to get a ThinApp package to function on a View desktop. Rather than troubleshoot what it was that was different between his capture machine and these desktops, we had him install ThinApp onto one of these desktops and then capture the application from there. That fixed his problem.
In short, always first try getting back to a stock OS for your capture machine – make sure that nothing else is installed. If, and only if, that fails then make the capture machine a baseline corporate image that everybody uses.