Capturing Applications with the Setup Capture Wizard
The capture process packages an application and sets initial application parameters. If you use a virtual machine, consider taking a snapshot before you run the wizard. A snapshot of the original clean state enables you to revert to the snapshot when you want to capture another application.
This information uses Mozilla Firefox as a key example for application capture.
Create a System Image Before the Application Installation
The Setup Capture wizard starts the capture process by scanning the system to assess the environment and create a baseline system image.
Create a system image before the application installation
1
For example, download Firefox Setup 2.0.0.3.exe and copy it to the clean computer you are working with.
2
3
From the desktop, select Start > Programs > VMware > ThinApp Setup Capture.
4
(Optional) In the Ready to Prescan dialog box, click Advanced Scan Locations to select the drives and registry hives to scan.
You might want to scan a particular location other than the C:\ drive if you install applications to a different drive. In rare cases, you might want to avoid scanning a registry hive if you know that the application installer does not modify the registry.
5
Click Prescan to establish a baseline system image of the hard drive and registry files.
The scanning process takes about 10 seconds for Windows XP.
Rescan the System with the Installed Application
You can install the application to virtualize before the Setup Capture wizard rescans the system and assess changes from the initial system image.
Install the application and rescan the system
1
When the Install Application page appears, minimize the Setup Capture wizard and install the applications to capture.
For example, double-click Firefox Setup 2.0.0.3.exe to install Firefox. If the application needs to restart after the installation, restart the system. The process restarts the Setup Capture wizard.
2
(Optional) If you are capturing Internet Explorer, in the Install Application page, click Internet Explorer, to complete additional steps before installing the browser.
If you are capturing Internet Explorer 6 on Windows XP, see Capturing Internet Explorer on Windows XP.
For more information about entry points, see Defining Entry Points as Shortcuts into the Virtual Environment.
3
If you do not make configuration changes at this time, each user must make changes.
4
If you do not respond to any messages at this time, each user who uses the application must do so during the initial start.
5
6
Maximize the Setup Capture wizard, click Postscan to proceed with another scan of the computer, and click OK to confirm the postscan operation.
ThinApp stores the differences between the first baseline image and this image in a virtual file system and virtual registry.
Defining Entry Points as Shortcuts into the Virtual Environment
Entry points are the executable files that act as shortcuts into the virtual environment and start the virtual application. The entry points you can choose from depend on the executable files that your captured application creates during installation.
For example, if you install Microsoft Office, you can select entry points for Microsoft Word, Microsoft Excel, and other applications that are installed during a Microsoft Office installation. If you install Firefox, you might select Mozilla Firefox.exe and Mozilla Firefox (SafeMode).exe if users require safe mode access.
During the build process that occurs at the end of the Setup Capture wizard, ThinApp generates one executable file for each selected entry point. If you deploy the application as an MSI file or use the thinreg.exe utility, the desktop and Start menu shortcuts created on user desktops point to these entry points.
Entry Points for Troubleshooting
ThinApp provides entry points to troubleshoot your environment.
Debugging an application might involve the following entry points:
cmd.exe – Starts a command prompt in a virtual context that enables you to view the virtual file system.
regedit.exe – Starts the registry editor in a virtual context that enables you to view the virtual registry.
Entry points start native executable files in a virtual context. Entry points do not create virtual packages of cmd.exe andregedit.exe.
If you cannot predict the need for debugging or troubleshooting the environment, you can use the Disabled parameter in the Package.ini file at a later time to activate these entry points.
Set Entry Points
You can designate the executable files that make up the list of entry points. ThinApp installs the executable files during the capture process.
Set entry points in the Setup Capture wizard
1
On the Entry Points page, select the check boxes for user-accessible entry points.
The wizard displays the executable files that were directly accessible through the desktop or Start menu shortcuts.
2
(Optional) To debug your environment, select the Show entry points used for debugging check box to display the regedit.exe, and cmd.exe troubleshooting options.
Manage with VMware Horizon Application Manager
You can use VMware Horizon Application Manager to manage the deployment and entitlement of ThinApp packages. See Using VMware Horizon Application Manager to Manage the Deployment and Entitlement of ThinApp Packages, available from the ThinApp download site.
Set User Groups
ThinApp can use Active Directory groups to authorize access to the virtual application. You can restrict access to an application to ensure that users do not pass it to unauthorized users.
Active Directory Domain Services define security groups and distribution groups. ThinApp can only support nested security groups.
Set user groups in the Setup Capture wizard
1
On the Groups page, limit the user access to the application.
a
Select Only the following Active Directory groups.
b
Click Add to specify Active Directory object and location information.
Common Queries (under Advanced)
2
Defining Isolation Modes for the Physical File System
Isolation modes determine the level of read and write access to the native file system outside of the virtual environment. You might adjust isolation mode settings depending on the application and the requirements to protect the physical system from changes.
The selection of isolation modes in the capture process determines the value of the DirectoryIsolationMode parameter in the Package.ini file. This parameter controls the default isolation mode for the files created by the virtual application except when you specify a different isolation mode in the ##Attributes.ini file for an individual directory.
The selection of a directory isolation mode does not affect the following areas:
ThinApp treats write operations to network drives according to the SandboxNetworkDrives parameter in the Package.ini file. This parameter has a default value that directs write operations to the physical drive. ThinApp treats write operations to removable disks according to the SandboxRemovableDisk parameter in the Package.ini file. This parameter has a default value that directs write operations to the physical drive.
If you save documents to the desktop or My Documents folder, ThinApp saves the documents to the physical system. ThinApp sets the isolation mode in the ##Attributes.ini files in %Personal% and %Desktop% to Merged even when you select WriteCopy isolation mode.
Applying Merged Isolation Mode for Modifications Outside the Package
With Merged isolation mode, applications can read and modify elements on the physical file system outside of the virtual package. Some applications rely on reading DLLs and registry information in the local system image.
The advantage of using Merged mode is that documents that users save appear on the physical system in the location that users expect, instead of in the sandbox. The disadvantage is that this mode might clutter the system image. An example of the clutter might be first-execution markers by shareware applications written to random computer locations as part of the licensing process.
When you select Merged isolation, ThinApp completes the following operations:
Sets the DirectoryIsolationMode parameter in the Package.ini file to Merged.
ThinApp retains Merged isolation mode for the %SystemSystem%\spool subdirectory by creating an exception to the %SystemSystem% parent directory isolation mode.
Between the prescan and postscan capture operations, assigns Full isolation mode to any directories that the application creates during the installation. This process is unrelated to the isolation mode of any new directories that the running virtual application creates.
Merged isolation mode in the Setup Capture wizard has the same effect as Merged isolation mode in the Package.ini file, including the directory exceptions that specify WriteCopy isolation mode. The Setup Capture wizard and manual capture process with the snapshot.exe utility configure the directory exceptions for you with the ##Attributes.ini files within the directories.
Applying WriteCopy Isolation Mode to Prevent Modifications Outside of the Package
With WriteCopy isolation mode, ThinApp can intercept write operations and redirect them to the sandbox.
You can use WriteCopy isolation mode for legacy or untrusted applications. Although this mode might make it difficult to find user data files that reside in the sandbox instead of the physical system, this mode is useful for locked down desktops where you want to prevent users from affecting the local file system.
When you select WriteCopy isolation in the Setup Capture wizard, ThinApp completes a number of operations.
Sets the DirectoryIsolationMode parameter in the Package.ini file to WriteCopy.
Between the prescan and postscan capture operations, assigns Full isolation mode to any directories that the application creates during the installation. This process is unrelated to the isolation mode of any new directories that the running virtual application creates.
WriteCopy isolation mode in the Setup Capture wizard has the same effect as WriteCopy isolation mode in the Package.ini file, including the directory exceptions that specify Merged isolation mode. The Setup Capture wizard and snapshot.exe utility configure the directory exceptions for you with the ##Attributes.ini files within the directories.
Set File System Isolation Modes
The capture process sets the level of read and write access to the physical file system to determine which directories are visible and writable by the virtual application.
For information about Full isolation and registry isolation that are available only outside of the Setup Capture wizard, see “DirectoryIsolationMode” and “RegistryIsolationMode” in ThinApp Package.ini Parameters Reference Guide.
Set file system isolation modes in the Setup Capture wizard
On the Isolation page, select the isolation mode for the physical file system.
ThinApp copies file system changes to the sandbox to ensure that ThinApp only modifies copies of files instead of the actual physical files.
Storing Application Changes in the Sandbox
The sandbox is the directory where all changes that the captured application makes are stored. The sandbox is runtime modification storage and is not a cache. The next time you open the application, those changes are incorporated from the sandbox.
When you delete the sandbox directory, the application reverts to its captured state. You might delete a sandbox when an application has a problem and you want to revert the application back to the working original state.
Customize the Sandbox Location
You can deploy the sandbox to a local user machine, carry it on a mobile USB device, or store it in a network location.
If you deploy the sandbox to a local machine, use the user’s profile as the sandbox location. The default location of the sandbox for Firefox might be %AppData%\Thinstall\Mozilla Firefox 3.0. The typical %AppData% location is C:\Documents and Settings\<user_name>\Application Data. The user’s profile is the default location because of the write access.
A network location is useful for backing up the sandbox and for users who log in to any computer and keep their application settings. Use the absolute path to the location, such as \\thinapp\sandbox\Firefox. You can select a network location even if an application is installed on a local machine.
A portable device location is useful to keep the sandbox data on the device where the application resides.
Customize the sandbox location in the Setup Capture wizard
On the Sandbox page, select the user’s profile, application directory, or custom location for the sandbox.
Send Anonymous Statistics to VMware
To improve ThinApp support for applications, VMware uses the capture process to confirm whether to collect anonymous data about deployed ThinApp packages. The data includes the application start time, total running time, and number of runs for the application.
Send anonymous statistics to VMware
On the Usage Statistics page, click the Yes - Send anonymous usage statistics to VMware option button to confirm the data collection status.
Customize ThinApp Project Settings
A project is the data that the capture process creates. You cannot run or deploy the captured application until you build a package from the project files.
Setting up the project involves determining the inventory name and the project location. The inventory name facilitates internal tracking of the application and determines the default project directory name.
Customize project settings in the Setup Capture wizard
1
On the Project Settings page, change the inventory name.
Using the thinreg.exe utility or deploying the captured application as an MSI file causes the inventory name to appear in the Add or Remove Programs dialog box for Windows.
2
If you keep the default directory and capture Firefox 2.0.0.3, the path might appear as C:\Program Files\VMware\VMware ThinApp\Captures\Mozilla Firefox (2.0.0.3).
Defining Package Settings
A package is the executable file or MSI file with executable files that you use to run or deploy a captured application. You build a package from the project files.
Setting up the package during the capture process involves specifying information about the main virtual application file that serves as the primary data container, MSI generation, and compression.
Defining the Primary Data Container
The primary data container is the main virtual application file that includes the ThinApp runtime and the read-only virtual file system and virtual registry. The primary data container file is a .exe or a .dat file that resides in the same /bin directory with any subordinate application executable files. Entry points reference the information in the primary data container.
To identify the primary data container after you capture an application, check the ReadOnlyData parameter in the Package.ini file.
Generating MSI Packages in the Capture Process
You can capture an application and deploy it as an MSI Windows installation package. The MSI installation places the application in the C:\Program Files directory.
A typical Firefox application does not require an MSI installation. Other applications, such as Microsoft Office, that integrate with application delivery tools, work well as an MSI package. MSI generation requires you to install the MSI on the target device before you can use the application package.
MSI packages automate the process of registering file-type associations, registering desktop and Start menu shortcuts, and displaying control panel extensions. If you plan to deploy ThinApp executable files directly on each computer, you can accomplish the same registration by using the thinreg.exe utility.
Compressing Packages in the Capture Process
Compressing a package in the capture process decreases the size of an executable package but does not affect MSI packages.
Compression can reduce the on-disk storage requirement by 50 percent but slows the application performance when ThinApp uncompresses initial blocks that start the application. VMware does not recommend compression for test builds because compression increases the build time.
Customize Package Settings
The capture process includes initial settings for the primary data container, MSI packages, and executable package compression.
Customize package settings in the Setup Capture wizard
1
On the Package Settings page, select the primary data container from the list that is based on your executable file entry points.
If the size of the primary container is smaller than 200MB, ThinApp creates a .exe file as the primary container. For a small application such as Firefox, any .exe file can serve as the main data container.
If the size of the primary container is larger than 200MB, ThinApp creates a separate.dat file as the primary container because Windows XP and Windows 2000 cannot show shortcut icons for large .exe files. Generating separate small .exe files together with the .dat file fixes the problem.
If the size of the primary container is between 200MB and 1.5GB, ThinApp creates the default .dat file unless you select a .exe file to override the default .dat file.
2
(Optional) If you select a .exe file to override the default .dat file when the size of the primary container is between 200MB and 1.5GB, ignore the generated warning.
Selecting a .exe file enables all applications to work properly but might prevent the proper display of icons.
3
If you plan to use the Application Sync utility to update a captured application, ThinApp uses the primary data container name during the process. You must use the same name across multiple versions of the application. You might not be able to select the same primary data container name from the list. For example, Microsoft Office 2003 and Microsoft Office 2007 do not have common entry point names.
4
(Optional) Select the Generate MSI package check box and change the MSI filename.
5
6
Click Save.
Opening Project and Parameter Files
The capture process provides an opportunity to review the project files to update settings before building the executable package or MSI package.
For example, if you capture Firefox 2.0.0.3, you might browse the C:\Program Files\VMware\VMware ThinApp\Captures\Mozilla Firefox 2.0.0.3 directory to update a setting, such as an Active Directory specification, in the Package.ini file that contains the parameters set during the capture process. For information about updating settings, see Advanced Package Configuration.
The project includes folders, such as %AppData%, that represent file system paths that might change locations when running on different operating systems or computers. Most folders have ##Attributes.ini files that specify the isolation mode at the folder level.
Build Virtual Applications
You can adjust project files and build the application for deployment.
Build virtual applications in the Setup Capture wizard
1
(Optional) On the Ready to Build page, scan or change the project files.
2
You can build the package at a later time with the build.bat file in the virtual application folder. For example, a Firefox 2.0.0.3 path to the build.bat file might be C:\Program Files\VMware\VMware ThinApp\Captures\Mozilla Firefox 2.0.0.3\build.bat.
3
Click Build to build an executable package or MSI package containing the files you installed during the capture process.
4
(Optional) Deselect the Open folder containing project executables after clicking Finish check box to view the executable files and MSI files at a later time.
5
Click Finish.
You can rebuild the package at any time after you click Finish to make changes.