Page 1 ThinApp User’s Guide ThinApp 4.6 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition. To check for more recent editions of this document, see http://www.vmware.com/support/pubs. EN-000400-00...
Page 2 VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.
Page 3: Table Of Contents
Capturing Applications with the Setup Capture Wizard 16 Create a System Image Before the Application Installation 16 Rescan the System with the Installed Application 16 Defining Entry Points as Shortcuts into the Virtual Environment 17 Set Entry Points 17 Set User Groups 18 Defining Isolation Modes for the Physical File System 18 Set File System Isolation Modes 20 Storing Application Changes in the Sandbox 20 Customize the Sandbox Location 20 Send Anonymous Statistics to VMware 20 Customize ThinApp Project Settings 21 Defining Package Settings 21 Customize Package Settings 22 Opening Project and Parameter Files 22 Build Virtual Applications 23 Advanced Package Configuration 23 Modifying Settings in the Package.ini File 23 Modifying Settings in the ##Attributes.ini File 24 Guidelines for Packaging Microsoft Office 2007 24 Requirements for Packaging Microsoft Office 2007 25...
Page 4 ThinApp User’s Guide Deploying Applications 39 ThinApp Deployment Options 39 Deploying ThinApp with Deployment Tools 39 Deploying ThinApp in the VMware View Environment 39 Deploying ThinApp on Network Shares 40 Deploying ThinApp Using Executable Files 40 Establishing File Type Associations with the thinreg.exe Utility 40 Application Sync Effect on the thinreg.exe Utility 40 Run the thinreg.exe Utility 41 Optional thinreg.exe Parameters 41 Building an MSI Database 43 Customizing MSI Files with Package.ini Parameters 43 Modify the Package.ini File to Create MSI Files 43 Controlling Application Access with Active Directory 45 Package.ini Entries for Active Directory Access Control 45 Starting and Stopping Virtual Services 46 Automatic Startup for Virtual Services 46 Using ThinApp Packages Streamed from the Network 47 How ThinApp Application Streaming Works 47 Requirements and Recommendations for Streaming Packages 48...
Page 5 SandboxCOMObjects 77 VirtualizeExternalOutOfProcessCOM 78 Configuring File Storage 78 CachePath 78 UpgradePath 79 VirtualDrives 79 Configuring Processes and Services 81 AllowExternalKernelModeServices 81 AllowExternalProcessModifications 81 AllowUnsupportedExternalChildProcesses 82 AutoShutdownServices 82 AutoStartServices 82 ChildProcessEnvironmentDefault 82 ChildProcessEnvironmentExceptions 83 Configuring Sizes 83 BlockSize 83 CompressionType 83 MSICompressionType 84 OptimizeFor 85 VMware, Inc.
Page 6 AppSyncWarningPeriod 95 Configuring MSI Files 96 MSIArpProductIcon 96 MSIDefaultInstallAllUsers 96 MSIFilename 97 MSIInstallDirectory 97 MSIManufacturer 97 MSIProductCode 98 MSIProductVersion 98 MSIRequireElevatedPrivileges 99 MSIUpgradeCode 99 MSIStreaming 99 Configuring Sandbox Storage and Inventory Names 100 InventoryName 100 RemoveSandboxOnExit 100 SandboxName 101 SandboxNetworkDrives 101 SandboxPath 101 SandboxRemovableDisk 102 VMware, Inc.
Page 7 Stopping a Service Example 117 Copying a File Example 117 Add a Value to the System Registry 118 API Functions 119 AddForcedVirtualLoadPath 119 ExitProcess 119 ExpandPath 120 ExecuteExternalProcess 120 ExecuteVirtualProcess 121 GetBuildOption 121 GetFileVersionValue 121 GetCommandLine 122 GetCurrentProcessName 122 GetOSVersion GetEnvironmentVariable 124 RemoveSandboxOnExit 124 SetEnvironmentVariable 124 SetfileSystemIsolation 125 SetRegistryIsolation 125 WaitForProcess 125 VMware, Inc.
Page 8 ThinApp User’s Guide Monitoring and Troubleshooting ThinApp 127 Providing Information to Technical Support 127 Log Monitor Operations 127 Troubleshoot Activity with Log Monitor 128 Perform Advanced Log Monitor Operations 128 Log Format 130 Troubleshooting Specific Applications 134 Troubleshoot Registry Setup for Microsoft Outlook 134 Viewing Attachments in Microsoft Outlook 134 Starting Explorer.exe in the Virtual Environment 135 Troubleshooting Java Runtime Environment Version Conflict 135 Glossary 137 Index 141 VMware, Inc.
Page 9: About This Book
About This Book The ThinApp User’s Guide provides information about how to install ThinApp™, capture applications, deploy applications, and upgrade applications. You can refer to this guide to customize parameters and perform scripting. Intended Audience This book is intended for anyone who installs ThinApp and deploys captured applications. Typical users are system administrators responsible for the distribution and maintenance of corporate software packages. VMware ThinApp Documentation The complete documentation set for VMware ThinApp consists of the following documents.  ThinApp User’s Guide. Conceptual and procedural information to help you complete a task.  ThinApp 4.6 Release Notes. Late‐breaking news and descriptions of known issues and workarounds.  Migrating Applications with ThinApp During an Upgrade from Microsoft Windows XP to Windows 7. Procedural information for using ThinApp to migrate applications from Windows XP to Windows 7. Document Feedback VMware welcomes your suggestions for improving our documentation. If you have comments, send your feedback to docfeedback@vmware.com. Technical Support and Education Resources The following sections describe the technical support resources available to you. To access the current version of this book and other books, go to http://www.vmware.com/support/pubs. Online and Telephone Support To use online support to submit technical support requests, view your product and contract information, and register your products, go to http://www.vmware.com/support.
Page 10 ThinApp User’s Guide VMware Professional Services VMware Education Services courses offer extensive hands‐on labs, case study examples, and course materials designed to be used as on‐the‐job reference tools. Courses are available onsite, in the classroom, and live online. For onsite pilot programs and implementation best practices, VMware Consulting Services provides offerings to help you assess, plan, build, and manage your virtual environment. To access information about education classes, certification programs, and consulting services, go to http://www.vmware.com/services. Legal Notice ThinApp uses the regular expression library originally written by Henry Spencer. Copyright (c) 1986, 1993, 1995 by University of Toronto. Written by Henry Spencer. Not derived from licensed software. Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it in any way, subject to the following restrictions: The author is not responsible for the consequences of use of this software, no matter how awful, even if they arise from defects in it. The origin of this software must not be misrepresented, either by explicit claim or by omission. Altered versions must be plainly marked as such, and must not be misrepresented (by explicit claim or omission) as being the original software. This notice must not be removed or altered. VMware, Inc.
Page 11: Installing Thinapp
Operating Systems, Applications, and Systems That ThinApp Supports ThinApp supports various operating systems, applications, and systems.  32‐bit platforms include Windows NT, Windows 2000, Windows XP, Windows XPE, Windows 2003 Server, Windows Vista, Windows Server 2008, Windows 7  64‐bit platforms include Windows XP 64 bit, Windows 2003 64 bit, Windows Vista 64 bit, Windows Server 2008 64 bit, Windows Server 2008 R2 64 bit, Windows 7 64 bit  16‐bit applications running on 32‐bit Windows operating systems  32‐bit applications running on 32‐bit and 64‐bit Windows operating systems  Terminal Server and Citrix Xenapp ThinApp supports Japanese applications captured and run on Japanese operating systems. Certain operating systems and applications are not supported by ThinApp.  16‐bit or non x86 platforms such as Windows CE  64‐bit applications running on 32‐bit or 64‐bit Windows operating systems  16‐bit applications running on 64‐bit Windows operating systems VMware, Inc.
Page 12: Applications That Thinapp Cannot Virtualize
Shell Integration Some applications that provide shell integration have reduced functions when they exist in a ThinApp package. For example, a virtual application that integrates with Windows Explorer cannot add specific entries to the Windows Explorer context menus. DCOM Services that are Accessible on a Network ThinApp isolates COM and DCOM services. Applications that install DCOM services are accessible on the local computer only by other captured applications running in the same ThinApp sandbox. ThinApp supports virtual DCOM and COM on the same computer but does not support network DCOM. Global Hook Dynamic Link Libraries Some applications use the SetWindowsHookEx API function to add a DLL file to all processes on the host computer. The DLL intercepts Windows messages to capture keyboard and mouse input from other applications. ThinApp ignores requests from applications that use the SetWindowsHookEx function to try to install global hook DLLs. ThinApp might reduce the application functions. Recommendations for Installing ThinApp When you install ThinApp, consider the recommendations and best practices for the software. Using a Clean Computer VMware recommends using a clean computer to install ThinApp because the environment affects the application capture process. A clean computer is a physical or virtual machine with only a Windows operating system installed. In a corporate environment where you have a base desktop image, the base desktop image is your clean computer. The desktop computer might already have some components and libraries installed. VMware, Inc.
Page 13: Using The Earliest Operating System Required For Users
After you create a ThinApp application package, you can overwrite files in the package with updated versions and rebuild the application without the capture process. Install ThinApp Software Use the ThinApp executable file to install ThinApp. Install ThinApp software Download ThinApp to a clean physical or virtual Windows machine. Double‐click the ThinApp executable file. In the Patent Lists dialog box, click Next. Accept the license, type the serial number, and type a license display name that appears when you open applications that ThinApp captures. Click Install. ThinApp is installed. Checking ThinApp Installation Files The ThinApp installation generates the VMware ThinApp directory in C:\Program Files\VMware. You might check the files in this directory to perform operations such as starting the Log Monitor utility to view recent activity. The following key files in the VMware ThinApp directory affect ThinApp operations:  AppSync.exe – Keeps captured applications up to date with the latest available version.  logging.dll – Generates .trace files.  dll_dump.exe – Lists all captured applications that are currently running on a system.  log_monitor.exe – Displays the execution history and errors of an application.  relink.exe – Updates existing packages to the latest ThinApp version installed on the system. VMware, Inc.
Page 14 ThinApp User’s Guide  sbmerge.exe – Merges runtime changes recorded in the application sandbox with the ThinApp project and updates the captured application.  Setup Capture.exe – Captures and configures applications through a wizard.  snapshot.exe – Compares the preinstallation environment and postinstallation environment during the application capture process. ThinApp starts this utility during the setup capture process.  snapshot.ini – Stores entries for the virtual registry and virtual file system that ThinApp ignores during the process of capturing an application. The snapshot.exe file references the snapshot.ini file. Advanced users might modify the snapshot.ini file to ensure that ThinApp does not capture certain entries when creating an application package.  template.msi – Builds the MSI files. You can customize this template to ensure that the .msi files generated by ThinApp adhere to company deployment procedures and standards. For example, you can add registry settings that you want ThinApp to add to client computers as part of the installation.  thinreg.exe – Registers captured applications on a computer. This registration includes setting up shortcuts and the Start menu and setting up file type associations that allow you to open applications.  tlink.exe – Links key modules during the build process of the captured application.  vftool.exe – Compiles the virtual file system during the build process of the captured application.  vregtool.exe – Compiles the virtual registry during the build process of the captured application. VMware, Inc.
Page 15: Capturing Applications
“Capturing Applications with the Setup Capture Wizard” on page 16  “Advanced Package Configuration” on page 23  “Guidelines for Packaging Microsoft Office 2007” on page 24  “Capturing Internet Explorer 6 on Windows XP” on page 28  “Capturing Multiple Application Installers with ThinApp Converter” on page 29 Phases of the Capture Process Capturing an application involves system scans, application configuration, package configuration, and generation of the virtual application for distribution. The Setup Capture wizard sets initial parameters for the application. You can customize the full set of parameters outside of the wizard. Preparing to Capture Applications Preparing for the capture process involves understanding the needs and dependencies of the application. For target applications that have dependencies on other applications, libraries, or frameworks, you can capture the dependencies or use the Application Link utility to link separate virtual applications at runtime. For information about the Application Link utility, see “Application Link Updates” on page 56. For target applications that require locale formats, such as a specific date format, you can capture them in an environment with the required locale setting. ThinApp runs virtual applications according to the regional and language settings on the capture system rather than the settings on the system that runs the application. Although you can modify the default locale setting by commenting out the LocaleIdentifier parameter in the Package.ini file and rebuilding the application, you can avoid complications in the capture environment. For information about the LocaleIdentifier parameter, see “LocaleIdentifier” on page 87. VMware, Inc.
Page 16: Capturing Applications With The Setup Capture Wizard
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. 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 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. (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 6 on Windows XP” on page 28. For more information about entry points, see “Defining Entry Points as Shortcuts into the Virtual Environment” on page 17. (Optional) Make any necessary configuration changes to comply with your company policies, such as using specific security settings or a particular home page. If you do not make configuration changes at this time, each user must make changes. VMware, Inc.
Page 17: Defining Entry Points As Shortcuts Into The Virtual Environment
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.  iexplore.exe – Starts iexplore.exe in a virtual context that enables you to test virtualized ActiveX controls. Entry points start native executable files in a virtual context. Entry points do not create virtual packages of cmd.exe, regedit.exe, or iexplore.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 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. (Optional) To debug your environment, select the Show entry points used for debugging check box to display the iexplore.exe, regedit.exe, and cmd.exe troubleshooting options. VMware, Inc.
Page 18: Set User Groups
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. VMware, Inc.
Page 19 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.  Sets up exceptions that apply Merged isolation to these directories  %Personal%  %Desktop%  %SystemSystem%\spool  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. VMware, Inc.
Page 20: Set File System Isolation Modes
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. VMware, Inc.
Page 21: Customize Thinapp Project Settings
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 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. Change the directory where you want to save the ThinApp project. 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.
Page 22: Customize Package Settings
.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. (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. (Optional) If you cannot select a primary data container, type a primary data container name to generate a .dat file. 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. (Optional) Select the Generate MSI package check box and change the MSI filename. (Optional) To create a smaller executable package for locations such as a USB device, select the Compress virtual package check box. 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” on page 23. 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. VMware, Inc.
Page 23: Build Virtual Applications
Files\VMware\VMware ThinApp\Captures\Mozilla Firefox 2.0.0.3\build.bat. Click Build to build an executable package or MSI package containing the files you installed during the capture process. (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. Click Finish. You can rebuild the package at any time after you click Finish to make changes. Advanced Package Configuration Advanced users might modify configuration files, such as the Package.ini or ##Attributes.ini files, before building the package during the capture or after the initial build of the package. Modifying Settings in the Package.ini File You can modify the Package.ini file to update the overall package. The file resides in the captured application folder. A Firefox 2.0.0.3 path might be C:\Program Files\VMware\VMware ThinApp\Captures\Mozilla Firefox 2.0.0.3\Package.ini. The following parameters are a few examples of settings that you might modify:  DirectoryIsolationMode – Sets the isolation mode to Merged, WriteCopy, or Full.  PermittedGroups – Restricts use of an application package to a specific set of Active Directory users.  SandboxName – Identifies the sandbox. You might keep the name for incremental application updates and change the name for major updates.  SandboxPath – Sets the sandbox location.  SandboxNetworkDrives – Specifies whether to direct write operations on the network share to the sandbox.
Page 24: Modifying Settings In The ##Attributes.ini File
ThinApp User’s Guide Modify the Package.ini File Use a text editor to modify the Package.ini file. Modify the Package.ini file Open the Package.ini file located in the captured application folder. For example, a Firefox 2.0.0.3 path might be C:\Program Files\VMware\VMware ThinApp\Captures\Mozilla Firefox 2.0.0.3\Package.ini. Activate the parameter to edit by removing the semicolon at the beginning of the line. For example, activate the RemoveSandboxOnExit parameter for Firefox. RemoveSandboxOnExit=1 Delete or change the value of the parameter and save the file. Double‐click the build.bat file in the captured application folder to rebuild the application package. 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. Modifying Settings in the ##Attributes.ini File The ##Attributes.ini file exists in the folder macros of the project folder and applies configuration settings at the directory level. The Package.ini file applies settings at the overall application level. You can use the DirectoryIsolationMode, CompressionType, and ExcludePattern parameters in an ##Attributes.ini file to override the Package.ini settings at the directory level. For example, you can set the isolation mode at the directory or application level to determine which files and registry keys are visible and written by the virtual application you create. The detailed setting in the ...
Page 25: Requirements For Packaging Microsoft Office 2007
The key differences between capturing Microsoft Office 2007 and capturing basic applications involve modifying Microsoft Office and blocking child processes. The capture process for Microsoft Office 2007 involves these steps. “Customize Microsoft Office 2007 Installation Options” on page 25 “Disable Child Processes for Microsoft Office 2007” on page 26 “Set Capture Options for Microsoft Office 2007” on page 26 This process assumes that you are familiar with the Setup Capture wizard. You can modify the process according to your environment. Customize Microsoft Office 2007 Installation Options Starting the capture process for Microsoft Office 2007 involves customizing the Microsoft Office installation. Customize the installation of Microsoft Office 2007 Copy Microsoft .NET 2.0, Windows Installer 4.5, and ThinApp installation files to the virtual machine. Copy the Microsoft Office 2007 installation files to the virtual machine or load the Microsoft Office 2007 ISO to the virtual machine. Install Windows Installer 4.5 and restart the system. Install ThinApp. (Optional) Install a required printer, such as a corporate printer. Run the Setup Capture wizard until you complete the prescan operation. On the Install Application page of the Setup Capture wizard, minimize the wizard and install Microsoft .NET 2.0. (Optional) If the Microsoft .NET installation generates the mscorsvw.exe process that continues for an extended period, stop the process with the ngen.exe tool. C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe executequeueditems VMware, Inc.
Page 26 Disable child processes for Microsoft Office 2007 Disable the ctfmon.exe process to prevent child processes from preventing you from closing the sandbox. In the Windows control panel, select Regional and Language Options. On the Languages tab, click Details. On the Advanced tab, select the Turn off advanced text services check box. From the desktop, select Start > Run and run the Regsvr32.exe /u msimtf.dll command. From the desktop, select Start > Run and run the Regsvr32.exe /u Msctf.dll command. Disable the mdm.exe process to prevent an issue with child processes that prevent you from closing the sandbox. In Internet Explorer, select Tools > Internet Options. On the Advanced tab, select the Disable Script Debugging (Other) check box and the Disable Script Debugging (Internet Explorer) check box. (Optional) Use VMware Workstation to take a snapshot of the virtual machine. This feature creates an image that you can revert to when you add plug‐ins or updates. Set Capture Options for Microsoft Office 2007 The final phase of the capture process for Microsoft Office 2007 involves the ThinApp postscan operation and Setup Capture wizard options to create the package. The following examples for options might apply to Microsoft Office 2007:  The location of the entry points is %ProgramFilesDir%\Microsoft Office\Office12.  The primary data container name is Microsoft Office 2007.dat. VMware, Inc.
Page 27: Configure Microsoft Office 2007
Configure Microsoft Office 2007 Configuring Microsoft Office 2007 outside of the capture process involves deleting directories and updating project files. You can make configuration changes to the Microsoft Office 2007 package when the changes are appropriate for your environment. Configure Microsoft Office 2007  (Optional) To save space, delete the following directories and files that Microsoft Office does not require:  %COOKIES%  %HISTORY%  %INTERNET CACHE%  %PROFILE%  %COMMON APPDATA%\VMware  .msi and .msp files in %SystemRoot%\Installer  (Optional) If you do not want to modify your Office 2007 package with customizations involving user names or company names, delete the contents of the %APPDATA% directory except the ##Attributes.ini file. This deletion enforces a clean configuration for the user.  (Optional) In the HKEY_CURRENT_USER.txt file in the project files, add the isolation_full HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Security entry anywhere in the file if it does not exist.  (Optional) Add these entries below the isolation_full HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Security entry. Value=OutlookSecureTempFolder REG_SZ~%Profile%\Local Settings\OutlookTemp#2300 ...
Page 28: Capturing Internet Explorer 6 On Windows Xp
Capture Internet Explorer 6 on Windows XP by Using the Setup Capture Wizard Capturing Internet Explorer 6 using the Setup Capture wizard is similar to that of capturing other applications. There are two key differences. When you use the Setup Capture wizard to capture Internet Explorer 6 on Windows XP, you define an entry point to Internet Explorer. You also use ThinDirect to specify URLs that will be redirected to the virtualized Internet Explorer 6 browser. See “Capturing Applications with the Setup Capture Wizard” on page 16 for a full overview of the standard Setup Capture process. Run setup capture on a machine running Windows XP with Service Pack 3, and with the .NET framework installed. Capture Internet Explorer 6 on Windows XP Create a system image using the Prescan process of the Setup Capture wizard. In the Install Application dialog box, click Internet Explorer. Select Include entry point for vitualized Internet Explorer 6 in the virtual package and click OK. This option captures both the files that changed during setup capture and other required files and registry settings. Install any plug‐ins for Internet Explorer that you want to be included in the package. Rescan the system using the Postscan process of the Setup Capture wizard. In the Setup Capture – Entry Points dialog box, select the default, VirtIE6.exe. Follow the prompts until the Native Browser Redirect dialog box appears. Create a list of the Web sites and pages that you want to redirect to the virtual Internet Explorer 6 package. Each entry must be on a separate line.  You can use wildcards, for example *.example.com.  You can specify a site so that all pages on that site are redirected, for example, www.example.com.  You can specify a site name followed by a page name, so that the specific page is redirected, for example javatester.org/version.html. VMware, Inc.
Page 29: Extracting And Registering Thindirect
The redirection list is located in %appdata%\roaming\Vmware\VMware Thinapp\Thindirect. 10 Follow the prompts to build the project. The ThinDirect.exe file is embedded in the package, with the plug‐in ThinDirect.dll and plug‐in launcher ThinDirectLauncher.exe files. Extracting and Registering ThinDirect After you have built the Internet Explorer 6 package, you need to extract and register the ThinDirect plug‐in on the test machine. The ThinDirect plug‐in must be installed as part of the virtual package. The plug‐in is installed in your native browser during the registration process. Extract and register ThinDirect In the console, run the thinreg /a VirtIE6.exe command to extract the ThinDirect application, and extract and register the ThinDirect library. The ThinDirect application is installed in the Program Files/VMware/VMware ThinApp/ThinDirect directory. You can have multiple ThinDirect text files in the ThinDirect directory, if they all have unique names. The ThinDirect plug‐in then reads all files. In addition to individual machine registration, you can register Web page redirects on a individual user basis by omitting the /a switch. To achieve individual‐user redirects requires that the ThinDirect plug‐in be installed as a separate step from an Administrator account. If you do not install the ThinDirect plug‐in as a separate step, Thinreg displays an error. You can push additional Web page redirect to end‐user computers by copying files with a specific format to specific individual‐machine or individual‐user locations. Capturing Multiple Application Installers with ThinApp Converter On virtual machines running a Windows operating system, you can use ThinApp Converter to convert ...
Page 30: System Requirements For Running Thinapp Converter
System Requirements for Running ThinApp Converter ThinApp Converter requires one of the following virtual machine environments:  VMware ESX Server 4.0, or later  VMware vCenter Server 4.0, or later  VMware Workstation 7.0, or later The virtual machines that are used in the conversion process must have the following items installed:  Windows XP with Service Pack 3, Windows Vista, or Windows 7  The latest version of VMware Tools ThinApp Converter includes a private copy of the VMware VIX API library. If a more recent version of the library already exists on the host machine, ThinApp Converter tries to use the newest version. VMware recommends that you use Windows 2003 or Windows 2008 as a file server for network share. The file server needs to have sufficient system resources to handle a large quantity of file operations. Do not use the host machine that runs the ThinApp Converter executable file as the file server for the network share. When using a VMware Workstation environment, ensure that the network settings are in bridged mode. Preparing the Configuration File for ThinApp Converter A sample configuration file, ThinAppConverter.ini, is included in the ThinApp installation. The file is generally located in C:\Program Files\VMware\VMware ThinApp. Modify or create a copy of this file to suit your requirements. Use UTF‐8 encoding when you specify parameter values. The ThinAppConverter.ini configuration file includes the following section headings:  [HostEnvironment] contains virtual machine hosting parameters.  [VirtualMachineN] contains virtual machine‐specific parameters. VMware, Inc.
Page 31 Chapter 2 Capturing Applications  [Settings] contains parameters that provide global control of the capture process.  [AppSettings:AppName] contains optional application‐specific parameters. HostEnvironment The HostEnvironment section of the configuration file contains the connection parameters for connecting to VMware ESX Server, VMware vCenter Server, or VMware Workstation on a local machine. [HostEnvironment] parameters are mandatory.  You can only specify a single endpoint at a time in the configuration file. For example, if you plan to use a single VMware ESX Server, you can have ThinAppConverter.exe directly connect to that server.  You cannot specify more than one ESX server. To use more than one ESX server, configure ThinAppConverter.exe to connect to VMware vCenter Server, which manages multiple ESX servers.  You can use a locally installed VMware Workstation. VirtualMachineHost The name of the virtual machine to which ThinApp Converter is to connect.  To connect a single VMware ESX Server, use the IP address or host name of the ESX server.  To connect to VMWare vCenter Server, use the IP address or name of the vCenter server.  To connect to a local VMware Workstation instance, use localhost.  For VMware ESX Server or VMware vCenter Server, if you are not using standard HTTPS with port 443, you can specify the entire URL. Examples The following example shows a virtual machine specified by ESX server hostname. [HostEnvironment] VirtualMachineHost=MyEsx.vmware.com The following example shows a virtual machine specified by IP address. [HostEnvironment] VirtualMachineHost=10.13.11.23 The following example shows a local machine specified as localhost.
Page 32 [VirtualMachine ] parameters are mandatory. VmxPath Specify the configuration path of the virtual machine. For ESX Server or vCenter Server, you can identify the virtual machine configuration file path using the vSphere Client. Identify the virtual machine configuration path using the vSphere Client Right‐click the virtual machine and select Edit Settings. Click the Options tab, and copy the string from the Virtual Machine Configuration File field. Use this string as the virtual machine configuration file path. For Workstation, specify the entire file path on the host on which the VMX configuration file resides. For example, C:\MyVMs\Windows XP\Windows XP.vmx. Do not place the path in quotation marks, even if the path contains a space. UserName A valid user name for the virtual machine guest operating system. The user must have administrator privileges for the virtual machine guest operating system. You can use UPN format when you specify a user name. For example, user@domain.com. Password or PasswordBase64 A valid password for the virtual machine guest operating system. You have the following options when you specify passwords:  You can enter clear text.  You can specify a base64 encoded password for the PasswordBase64 parameter. Specifying an encoded password does not increase security strength. You need to protect the actual INI file. All passwords are handled in the same way. VMware, Inc.
Page 33 PasswordPrompt has been set to true. The user will be prompted for a password even though a password has been specified in the configuration. [VirtualMachine1] VmxPath=C:\MyVMs\Windows XP\Windows XP.vmx UserName=administrator Password=secret PasswordPrompt=true [VirtualMachine2] VmxPath=C:\MyVMs\Windows 7\Windows 7.vmx UserName=adminuser@mydomain.com Password= PasswordPrompt=true Do not place the path in quotation marks, even if the path contains a space. Settings The Settings section of the configuration file contains the parameters for the application installation directory and ThinApp project output directory, in the form of UNC. It also contains several parameters controlling the conversion process behavior. ThinApp Converter only requires read‐only permissions for the network share that contains the application installers. It requires read/write permissions for the network share that contains the ThinApp projects. If input and output directories are on the same file server, you must use the same user account to connect them. InputUncPath Specify the network share UNC path for the application installers. For example: \\fileserver\sharename, or \\fileserver\sharename\dirname. InputMountUserName Specify the user name used for connecting to that network share. UPN format can be used when you specify a domain user, for example user@domain.com InputMountPassword or InputMountPasswordBase64 Specify the password for connecting to the network share. You have the following options when you specify passwords:  You can enter clear text.  You can specify a base64 encoded password for the PasswordBase64 parameter. VMware, Inc.
Page 34 You can enter clear text.  You can specify a base64 encoded password for the PasswordBase64 parameter. OutputMountPasswordPrompt Specifies that the user be prompted to enter a password. If you do not want to store the network share password in the configuration file, specify the value as true. When set to true, a prompt always appears, even if a password is specified in the configuration file. Example Following is an example of network share specifications.The user for the application installation directory has only read permissions. For both the input and output network shares, a prompt will display, requiring a user to enter a password. [Settings] InputUncPath=\\AppInstallerServer\AppInstallers\ThinAppMigration InputMountUserName=readonlyUser InputMountPassword=secret InputMountPasswordPrompt=true OutputUncPath=\\DeploymentServer\ThinAppProj OutputMountUserName=readwriteUser OutputMountPassword=secret OutputMountPasswordPrompt=true ThinApp Converter Logic for Detecting the Application Installation Processes For the application installer’s network share, ThinApp Converter examines all subdirectories under the specified UNC path recursively, including their subdirectories. For each subdirectory, it determines which command to run for silent application installation using the following logic: Attempts to find a value for InstallationCommand in the [AppSettings:AppName] section of the configuration file. If successful ThinApp Converter uses that value. Attempts to find a file named install.cmd or install.bat. If successful, ThinApp Converter runs that file. If ThinApp Converter finds a single .cmd or .bat file, it runs that file. If ThinApp Converter finds a single .exe file, it runs that file. VMware, Inc.
Page 35 Specify the file path to the global Package.ini override file. This optional parameter enables you to specify a global override file for Package.ini that is generated for each ThinApp project. The values in the override file are merged into Package.ini in the ThinApp project that is generated for each application. Global overrides are useful when you have a global policy setting, for example, PermittedGroup in Package.ini. A Package.ini override file is formatted like a standard Windows INI file. You can add INI parameters and values that are relevant to the Package.ini file. The path is relative to the application installer’s network share. Using the example for specifying the network shares for the application installers and ThinApp projects, if you specify PackageIniOverrideFile=override.ini, ThinApp Converter will try to find the file under \\AppInstallerServer\AppInstaller. You can provide a more explicit value by using predefined variables. For more information, see “Predefined Environment Variables” on page 37. You can specify a Package.ini file for each application. This process is described as part of the [AppSettings:AppName] section. ExclusionList Specify a comma‐ or semicolon‐separated list of application directories that ThinApp will skip when searching for application installers. The list is case insensitive. You can specify wildcards for DOS‐style file names. For example, Microsoft*. ? and * are supported. Example Following is an example of an exclusion specification using a wildcard. [Settings] ExclusionList=App?.old;FireFox1.0 ProjectPostProcessingCommand Specify the file path to the project post processing command. The file path is relative to the application installer’s network share. Using the example for specifying the network shares for the application installers and ThinApp projects, if you specify ProjectPostProcessingCommand=addscript.bat, ThinApp Converter will try to find the file under \\AppInstallerServer\AppInstaller. You can provide a more explicit value by using predefined variables. For more information, see “Predefined Environment Variables” on page 37. StopOnError Specify whether ThinApp Converter should stop converting an application if it encounters an error, or continue with the other applications. The default value is false. VMware, Inc.
Page 36 Specify whether ThinApp Converter should try to detect if an application installer is stalled, for example when the application is waiting for user input on the guest virtual machine because incorrect silent installation switches were specified. The default value is true. ThinApp Converter might not be able to detect all situations in which the installer is idle. InstallerTimeout Specify how long ThinApp Converter should wait for an application installer to finish before it quits. By default, the value is 7200 seconds. AppSettings:AppName This optional section provides parameters that you can use to add settings that are specific to an application. AppName is the actual name of the subdirectory that contains the application installer. These parameters can be added to each AppSettings section. In most circumstances, you will not need to configure this section. InstallationCommand Specify how ThinApp Converter should start the application installer. If there is no value, ThinApp Converter attempts to select one installation command using the logic described in “ThinApp Converter Logic for Detecting the Application Installation Processes” on page 34. PackageIniOverrideFile The Package.ini override file that is applied to a single application installer. When this parameter has a value, the global override file is processed first, followed by this application‐specific override file. The file path is relative to the application installer subdirectory. Using the example at the bottom of this section, if you specify PackageIniOverrideFile=override.ini, ThinApp Converter will try to find the file under \\AppInstallerServer\AppInstaller\Adobe. You can provide a more explicit value by using predefined variables. For more information, see “Predefined Environment Variables” on page 37. ProjectPostProcessingCommand Specify the project post processing command for the specific application. When this parameter has a value, the global override file is processed first, followed by this application‐specific post processing command. Example Following is an example of how to apply an application‐specific override during post processing. [AppSettings:Adobe] InstallationCommand=AdbeRdr920_en_US.exe /sAll PackageIniOverrideFile=override.ini [AppSettings:TextPad] InstallationCommand=silent_install.bat ProjectPostProcessingCommand=%AppInstallerDir%\addscript.bat VMware, Inc.
Page 37: Predefined Environment Variables
Chapter 2 Capturing Applications Predefined Environment Variables The values for PackageIniOverrideFile (global and per application), ProjectPostProcessingCommand (global and per application), and InstallationCommand can contain environment variables. ThinApp Converter expands the value before using it. ThinApp Converter adds these variables as predefined environment variables:  %AppInstallersRootDir% ‐ The UNC path of the application installers that is specified in InputUncPath in the [Settings] section.  %AppInstallerDir% ‐ The subdirectory under %AppInstallersRootDir% for the relevant application.  %ThinAppProjectsRootDir% ‐ The UNC path for the generated ThinApp projects that is specified in OutputUncPath in the [Settings] section.  %ThinAppProjectDir% ‐ The subdirectory under %ThinAppProjectsRootDir% for the relevant application. Example Following is an example of how predefined variables can be used in the PackageIniOverrideFile, ProjectPostProcessingCommand, and InstallationCommand parameters. [Settings] PackageIniOverrideFile=%AppInstallersRootDir%\AppSyncSettings.ini ;will resolve to \\AppInstallerServer\AppInstaller\AppSyncSettings.ini [AppSettings:Adobe] InstallationCommand=AdbeRdr920_en_US.exe /sAll PackageIniOverrideFile=%AppInstallerDir%\override.ini ;will resolve to \\AppInstallerServer\AppInstaller\Adobe\AppSyncSettings.ini VMware, Inc.
Page 38 ThinApp User’s Guide VMware, Inc.
Page 39: Deploying Applications
 “Using ThinApp Packages Streamed from the Network” on page 47  “Using Captured Applications with Other System Components” on page 49  “Sample Isolation Mode Configuration Depending on Deployment Context” on page 51 ThinApp Deployment Options You can deploy captured applications with deployment tools, in a VMware View™ environment, on a network share, or as basic executable files. Deploying ThinApp with Deployment Tools Medium and large enterprises often use major deployment tools, such as Symantec, BMC, and SMS tools. ThinApp works with all major deployment tools. When you use any of these tools, you can create MSI files for the captured applications and follow the same process you use to deploy native MSI files. See deployment instructions from the tool vendors. For information about MSI files, see “Building an MSI Database” on page 43. Deploying ThinApp in the VMware View Environment You can use VMware View to distribute ThinApp packages. The workflow for deploying packages might involve the following tasks:  Creating executable files for the captured applications.  Storing the executable files on a network share. VMware, Inc.
Page 40: Deploying Thinapp On Network Shares
Establishing File Type Associations with the thinreg.exe Utility If you create executable files instead of MSI files during the capture process, you must run the thinreg.exe utility to open files, such as a .doc document or an .html page. For example, if you click a URL in an email message, ThinApp must be set to start Firefox. You do not have to run the thinreg.exe utility for MSI files because MSI files start the utility during the application installation. The thinreg.exe utility creates the Start menu and desktop shortcuts, sets up file type associations, adds deinstallation information to the system control panel, and unregisters previously registered packages. The utility enables you to see the control panel extensions for applications, such as Quicktime or the mail control panel applet for Microsoft Outlook 2007. When you right‐click a file, such as a .doc file, the thinreg.exe utility enables you to see the same menu options for a .doc file in a native environment. If an application runs SMTP or HTTP protocols, such as an email link on a Web page that needs to open Microsoft Outlook 2007, the thinreg.exe utility starts available virtual applications that can handle those protocols. If virtual applications are not available, the thinreg.exe utility starts native applications that can handle those protocols. The default location of the utility is C:\Program Files\VMware\VMware ThinApp. Application Sync Effect on the thinreg.exe Utility The Application Sync utility affects the thinreg.exe utility during the update process. If you add, modify, or remove executable files, the thinreg.exe utility reregisters the file type associations, shortcuts, and icons. If you install protocols, MIME types, control panel applets, and templates other than executable files, the thinreg.exe utility reregisters these elements. VMware, Inc.
Page 41: Run The Thinreg.exe Utility
Run the thinreg.exe utility Determine the executable files that ThinApp must register with the local environment. From the command line, type the thinreg.exe command. thinreg.exe [<optional_parameters>] [<package1.exe>][<package2.exe>][<packages_by_wildcard>] If the server name is DEPLOYSERVER and the share is ThinApps, use the following example to register Microsoft Word for the logged‐in user. ThinReg.exe "\\DEPLOYSERVER\ThinApps\Microsoft Office 2007 Word.exe" Use the following example to register all Microsoft Office applications in the specified directory for the logged‐in user. ThinReg.exe "\\DEPLOYSERVER\ThinApps\Microsoft Office *.exe" Optional thinreg.exe Parameters The thinreg.exe utility monitors the PermittedGroups setting in the Package.ini file, registering and unregistering packages as needed. When the thinreg.exe utility registers a package for the current user, the utility creates only the shortcuts and file type associations that the current user is authorized for in the PermittedGroups setting. If this setting does not exist, the current user is authorized for all executable files. When the thinreg.exe utility registers a package for all users with the /allusers parameter, ThinApp creates all shortcuts and file type associations regardless of the PermittedGroups setting. When you double‐click a shortcut icon that you are not authorized for, you cannot run the application. If the package name you want to register or unregister contains spaces, you must enclose it in double quotation marks. For information about the PermittedGroups setting and support for Active Directory groups, see “PermittedGroups” on page 73. Table 3‐1 lists optional parameters for the thinreg.exe utility. Any command that uses the /a parameter requires administrator rights. VMware, Inc.
Page 42 ThinApp stores authorization information in the PermittedGroups parameter of the Package.ini file. /noarp Prevents the creation of an entry in the thinreg.exe /q /noarp Add/Remove Programs control panel "\\<server>\<share>\Microsoft Office applet. 2007 Word.exe" /norelaunch Starts the thinreg.exe utility on thinreg.exe /q /norelaunch Microsoft Vista without elevated "\\<server>\<share>\Microsoft Office privileges. Standard users can start the 2007 Word.exe" utility without a user account control (UAC) pop‐up window. When the thinreg.exe utility detects a need for more privileges, such as the privileges required for the /allusers parameter, the utility restarts itself as a privileged process and generates a UAC pop‐up window. The /norelaunch option blocks this restart process and causes the registration to fail. VMware, Inc.
Page 43: Building An Msi Database
44.  The MSIFileName parameter names the package. For example, include MSIFilename=Firefox30.msi in the Package.ini file.  The MSIRequireElevatedPrivileges parameter indicates whether an installer needs elevated privileges for deployment on Microsoft Vista. Installations for individual users do not usually need elevated privileges but per‐machine installations require such privileges. For example, include MSIRequireElevatedPrivileges=1 in the Package.ini file.  The MSIProductCode parameter makes it easier to install a new version of the application. An MSI database contains a product code and an upgrade code. When you update a package, keep the original value of the MSIUpgradeCode parameter. If the parameter value of the new version is the same as the value of the old version, the installation prompts you to remove the old version. If the values for the parameter are different, the installation uninstalls the old version and installs the new version. VMware recommends that you avoid specifying an MSIProductCode value and allow ThinApp to generate a different product code for each build. Regardless of the parameter values specified at build time, you can override the settings at deployment time. See “Force MSI Deployments for Each User or Each Machine” on page 44. For more information about MSI parameters, see “Configuring MSI Files” on page 96. Modify the Package.ini File to Create MSI Files For more information about MSI parameters, see “Customizing MSI Files with Package.ini Parameters” on page 43 and “Configuring MSI Files” on page 96. Before you can modify MSI parameters, you must add an entry for the MSIFilename parameter to generate MSI files. VMware, Inc.
Page 44 (Optional) From the command line, type the msiexec /i <database>.msi ALLUSERS="" command to force deployments for individual users.  (Optional) From the command line, type the msiexec /i <database>.msi ALLUSERS=1 command to force deployments for all users on a machine. Override the MSI Installation Directory You can use the msiexec command to override the default MSI installation directory. When ThinApp performs an individual machine MSI deployment, the default installation directory is the localized equivalent of %ProgramFilesDir%\<inventory_name> (VMware ThinApp). If you install a Firefox package for each machine, the package resides in %ProgramFilesDir%\Mozilla Firefox (VMware ThinApp). When ThinApp performs an MSI deployment for individual users, the default installation directory is %AppData%\<inventory_name> (VMware ThinApp). In both cases, you can override the installation directory by passing an INSTALLDIR property to the msiexec command. Override the MSI installation directory From the command line, type the msiexec /i <database>.msi INSTALLDIR=C:\<my_directory>\<my_package> command. VMware, Inc.
Page 45: Controlling Application Access With Active Directory
 If you delete a group and re‐create it, the SID might change. In this case, rebuild the package to authenticate against the new group.  When users are offline, ThinApp can authenticate them using cached credentials. If the users can log into their machines, authentication still works. Use a group policy to set the period when cached credentials are valid.  Cached credentials might not refresh on clients until the next Active Directory refresh cycle. You can force a group policy on a client by using the gpupdate command. This command refreshes local group policy, group policy, and security settings stored in Active Directory. You might log out before Active Directory credentials are recached.  Certain groups, such as the Administrators group and Everyone group, have the same SID on every Active Directory domain and workgroup. Other groups you create have a domain‐specific SID. Users cannot create their own local group with the same name to bypass authentication.  Active Directory Domain Services define security groups and distribution groups. If you use nested groups, ThinApp can only support nested security groups. Package.ini Entries for Active Directory Access Control ThinApp provides the PermittedGroups parameter in the Package.ini file to control Active Directory access. When you start a captured application, the PermittedGroups parameter checks whether a user is a member of a specified Active Directory group. If the user is not a member of the Active Directory group, Thinapp does not start the application. For information about restricting packages to Active Directory groups, see “PermittedGroups” on page 73. In the following Package.ini entry, App1 and App2 inherit PermittedGroups values. [BuildOptions] PermittedGroups=Administrators;OfficeUsers [App1.exe] [App2.exe] VMware, Inc.
Page 46: Starting And Stopping Virtual Services
 Registering the service on the physical machine by using ThinReg Create a virtual service for automatic startup On a clean local machine, use ThinApp to capture the service. After the postscan process is complete, in the Setup Capture ‐ Ready to Build dialog, click Edit Package.ini. The Package.ini file opens in a text editor. Search for the services entry. The entry is followed by the name of the service that you captured. By default, the entry is commented out. Remove the semicolon (;) from the start of the line. Save the Package.ini file. Build the ThinApp project. You can now register your virtual service so that it can be managed by using the native services management tools. Register the virtual service on a physical machine Run the ThinReg.exe application. At the command line, type C:\Program Files\VMware\VMware ThinApp\ThinReg /a *.exe. You must use /a to register services. If you run ThinApp without this option, the service is not registered. You can change the path, if required for your system. VMware, Inc.
Page 47: Using Thinapp Packages Streamed From The Network
Figure 3-1. Data Block Streaming over a Network Share Jill’s Sandbox Sam’s shared folder Sandbox Joe’s Sandbox On the end‐user desktop, you can create shortcuts that point to the centrally hosted executable file packages. When the user clicks the shortcut, the application begins streaming to the client computer. During the initial streaming startup process, the ThinApp status bar informs the user of the progress. How ThinApp Application Streaming Works When you place compressed ThinApp executable files on a network share or USB flash drive, the contents from the executable file stream to client computers in a block‐based fashion. As an application requests specific parts of data files, ThinApp reads this information in the compressed format over the network using standard Windows file sharing protocol. For a view of the process, see Figure 3‐2. After a client computer receives data, ThinApp decompresses the data directly to memory. Because ThinApp does not write data to the disk, the process is fast. A large package does not necessarily take a long time to load over the network and the package size does not affect the startup time of an application. If you add an extra 20GB file to a package that is not in use at runtime, the package loads at the same speed. If the application opens and reads 32KB of data from the 20GB file, ThinApp only requests 32KB of data. The ThinApp runtime client is a small part of the executable file package. When ThinApp loads the runtime client, it sets up the environment and starts the target executable file. The target executable file accesses other parts of the application stored in the virtual operating system. The runtime client intercepts such requests and serves them by loading DLLs from the virtual operating system. The load time of the runtime client across a network is a few milliseconds. After ThinApp loads the runtime client to memory on the client computer, the end‐user computer calculates which blocks of data are required from the server and reads them based on application activity. When the application makes subsequent read requests for the same data, the Windows disk cache provides data without requiring a network read operation. If the client computer runs low on memory, Windows discards some of its disk cache and provides the memory resource to other applications. VMware, Inc.
Page 48: Requirements And Recommendations For Streaming Packages
ThinApp User’s Guide Figure 3-2. Application Streaming packaged executable VMware ThinApp VOS local PC 128KB read request virtual registry compressed file decompressed (Block 1) 64KB (Block 1) Ethernet 64KB (Block 2) decompressed (Block 2) 64KB (Block 3) 64KB (Block 4)
Page 49: Stream Thinapp Packages From The Network
Captured applications and applications installed on the physical system have the same relationship with device drivers. If an application requires a device driver, you must install the driver separately from the ThinApp package. Sometimes, an application without an associated driver might function with some limitations. For example, Adobe Acrobat installs a printer driver that enables applications system wide to render PDF files using a print mechanism. When you use a captured version of Adobe Acrobat, you can use it to load, edit, and save PDF files without the printer driver installation. Other applications do not detect a new printer driver unless the driver is installed. Accessing the Local Disk, the Removable Disk, and Network Shares When you create a project structure, ThinApp configures isolation modes for directories and registry subtrees. The isolation modes control which directories the application can read and write to on the local computer. Review the default configuration options described in Table 3‐2. Table 3-2. Default Configuration Options Component Description Hard disk An example of a hard disk is C:\. Isolation modes selected during the capture process affect access. Users can write to their Desktop and My Documents folders. Other modifications that the application makes go into the user sandbox. The default location of the sandbox is in the Application Data directory. Removable disk By default, any user who has access rights can read or write to any location on a removable disk. VMware, Inc.
Page 50: Accessing The System Registry
Accessing Networking and Sockets Captured applications have standard access to networking features. Captured applications can bind to local ports and make remote connections if the user has access permissions to perform these operations. Using Shared Memory and Named Pipes Captured applications can interact with other applications on the system by using shared memory, named pipes, mutex objects, and semaphores. ThinApp can isolate shared memory objects and synchronization objects. This isolation makes them invisible to other applications, and other application objects are invisible to a captured application. Using COM, DCOM, and Out-of-Process COM Components Captured applications can create COM controls from the virtual environment and the system. If a COM control is installed as an out‐of‐process COM, the control runs as a virtual process when a captured application uses it. You can control modifications that the captured applications make. Starting Services Captured applications can start and run system‐installed services and virtual services. System services run in the virtual environment that controls the modifications that the services can make. Using File Type Associations Captured applications can run system‐installed applications by using file type associations. You can add file type associations to the local computer registry to point to captured executable files for individual users and machines. VMware, Inc.
Page 51: Sample Isolation Mode Configuration Depending On Deployment Context
View of Isolation Mode Effect on the Windows Registry Figure 3‐3 shows a section of the Windows registry for a computer that has older Microsoft Office applications installed. Microsoft Office 2003 creates the HKEY_LOCAL_MACHINE\Software\Microsoft\Office\11.0 registry subtree. Figure 3-3. Windows Registry as Seen by Windows Regedit ODBC Office 10.0 11.0 Common Delivery Live Meeting Outlook PowerPoint Visio When ThinApp runs a captured version of Microsoft Visio 2007, ThinApp sets the HKLM\Software\Microsoft\Office registry subtree to full isolation. This setting prevents Microsoft Visio 2007 from failing because of registry settings that might preexist on the host computer at the same location. VMware, Inc.
Page 52 ThinApp User’s Guide Figure 3‐4 shows the registry from the perspective of the captured Microsoft Visio 2007. Figure 3-4. Windows Registry as Seen by the Captured Microsoft Visio 2007 Office 12.0 Access Connectivity Common Registration User Settings Visio 10.0 11.0 Common Delivery Live Meeting Outlook PowerPoint Visio VMware, Inc.
Page 53: Updating And Linking Applications
Application Updates That the End User Triggers ThinApp provides the Application Sync and Application Link utilities to update applications with new versions or new components. The Application Sync utility updates an entire application package. The Application Link utility keeps shared components or dependent applications in separate packages. Application Sync Updates The Application Sync utility keeps deployed virtual applications up to date. When an application starts with this utility enabled, the application queries a Web server to determine if an updated version of the executable file is available. If an update is available, the differences between the existing package and the new package are downloaded and used to construct an updated version of the package. The updated package is used for future launches. The Application Sync utility is useful for major configuration updates to the application. For example, you might update Firefox to the next major version. Remote users or users who are not connected to the corporate network can make use of the Application Sync utility by embedding update settings within the package and using any Web server to store the updated version of the package. Using Application Sync in a Managed or Unmanaged Environment If you use virtual applications that update automatically in a managed computer environment, do not use the Application Sync utility because it might clash with other update capabilities. If an automatic update feature updates an application, the update exists in the sandbox. If the Application Sync utility attempts to update the application after an automatic application update, the version update stored in the sandbox take precedence over the files contained in the Application Sync version. The order of precedence for updating files is the files in the sandbox, the virtual operating system, and the physical machine. If you have an unmanaged environment that does not update applications automatically, use the Application Sync utility to update applications. VMware, Inc.
Page 54 93. Update Firefox 2.0.0.3 to Firefox 3 Capture Firefox 2.0.0.3 and Firefox 3 into separate packages. Verify that the primary data container name is the same for both packages. The primary data container, determined during the setup capture process, is the file that contains the virtual file system and virtual registry. If you have a Firefox 2.0.0.3 package that has Mozilla Firefox 2.0.0.3.exe as the name of the primary data container, and you have a Firefox 3 package that has Mozilla Firefox 3.dat as the name of the primary data container, change the name in the Shortcut parameter to a common name. For example, you can use Firefox.exe as a name. Modify the Package.ini file in each package. Open the Package.ini file located in the captured application folder. For example, a Firefox 2.0.0.3 path to the Package.ini file might be C:\Program Files\VMware\VMware ThinApp\Captures\Mozilla Firefox 2.0.0.3\Package.ini. Uncomment the Application Sync parameters you want to edit by removing the semicolon at the beginning of the line. You must uncomment the AppSyncURL parameter to enable the utility. Change the value of the parameters and save the file. For example, you can copy an executable file of the latest Firefox version to a mapped network drive and type a path to that location as the value of the AppSyncURL parameter. If Z: is the mapped drive and Firefox is the name of the directory that stores the executable file, a sample path is file:///Z:/Firefox/Firefox.exe. Make sure that the AppSyncURL path is the same in both Package.ini files and points to the updated version. In the captured application folder, double‐click the build.bat file to rebuild the application package. 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.
Page 55 Microsoft Office 2007 package that does not include Microsoft PowerPoint. The Microsoft Office PowerPoint 2007.exe entry point does not exist for the original package. If you rebuild the Microsoft Office 2007 package to include Microsoft PowerPoint, and you use the Application Sync utility to update client machines, the end users can access an entry point executable file for Microsoft PowerPoint. Updating thinreg.exe Registrations with Application Sync If you register virtual applications on the system using thinreg.exe and update applications with the Application Sync utility, you can update registrations by placing a copy of thinreg.exe, located in C:\Program Files\VMware\VMware ThinApp, alongside the updated package on the server. Maintaining the Primary Data Container Name with Application Sync The Application Sync utility requires that the name of the primary data container, the file that stores virtual files and registry information, is the same for the old and new versions of an application. For example, you cannot have an old version with Microsoft Office Excel 2003.exe as the primary data container name while the new version has Microsoft Office 2007.dat as the primary data container name. To verify the name of the primary data container, see the ReadOnlyData parameter in the Package.ini file. For more information about the primary data container, see “Defining Entry Points as Shortcuts into the Virtual ...
Page 56: Application Link Updates
Click OK in all the open dialog boxes and leave the Windows command processor open. Unregister the MSIMTF.dll and MSCTF.dll files with the REGSVR32.EXE/U <DLL_file> command. See knowledge base article 282599 in the Microsoft Web site. Close the Windows command processor. 10 If the virtual machine does not reside on the same machine where ThinApp is installed, copy the sandbox from the package to the packaging system. The default sandbox location is %APPDATA%\Thinstall. 11 From the standard command prompt on the packaging system, use the sbmerge.exe utility to merge the updated sandbox with the package. A sample command is SBMERGE APPLY –ProjectDir "C:\Program Files\VMware \VMware ThinApp\Captures\Microsoft Office Professional 2007" –SandboxDir "%APPDATA%\Thinstall\Microsoft Office Pro 2007". 12 Rebuild the package and test the package on a clean virtual machine to confirm that the ctfmon.exe process no longer exists. Application Link Updates The Application Link utility connects dependent applications at runtime. You can package, deploy, and update component pieces separately rather than capture all components in the same package. ThinApp can link up to 250 packages at a time. Each package can be any size. The Application Link utility is useful for the following objects:  Large shared libraries and frameworks – Link runtime components, such as .NET, JRE, or ODBC drivers, ...
Page 57 Program Files System Files Base Application + Base Application + Component Package Common Files ComPlus Applications Component1 Link a Base Application to the Microsoft .NET Framework Review this sample workflow to link a base application, MyApp.exe, to a separate package that contains the Microsoft .NET 2.0 Framework. Make sure that the base application capture process does not include the Microsoft .NET 2.0 Framework. For information about the process of capturing an application, see Chapter 2, “Capturing Applications,” on page 15. For information about required and optional Application Link parameters and formats in the Package.ini file, see “Configuring Dependent Applications with Application Link” on page 91. VMware, Inc.
Page 58 Rebuild the .NET 2.0 and base application packages. Double‐click the build.bat file in C:\Captures\MyApp. Double‐click the build.bat file in C:\Captures\dotnet. Running these batch files builds separate ThinApp packages. Deploy the applications to an end‐user desktop in C:\Program Files\MyApp. Copy C:\Captures\MyApp\bin\MyApp.exe to \\<end_user_desktop>\<Program_Files_share>\MyApp\MyApp.exe. Copy C:\Captures\dotnet\bin\cmd.exe to \\<end_user_desktop>\<Program_Files_share>\MyApp\dotnet.dat. Set Up Nested Links with Application Link ThinApp supports nested links with the Application Link utility. For example, if Microsoft Office links to a service pack, and the service pack links to a hot fix, ThinApp supports all these dependencies. This procedure refers to AppA, which requires AppB; and AppB, which requires AppC. Assume the following folder layout for the procedure:  C:\AppFolder\AppA\AppA.exe  C:\AppFolder\AppB\AppB.exe  C:\AppFolder\AppC\AppC.exe For information about setting up required and optional Application Link parameters in this procedure, see “Configuring Dependent Applications with Application Link” on page 91. Set up nested links Capture Application A. In the Package.ini file, specify Application B as a required or optional application link. For example, add RequiredLinks=\AppFolder\AppB\AppB.exe to the file. VMware, Inc.
Page 59 Sandbox Changes for Standalone and Linked Packages Sandbox changes from linked packages are not visible to the base executable file. For example, you can install Acrobat Reader as a standalone virtual package and as a linked package to the base Firefox application. When you start Acrobat Reader as a standalone application by running the virtual package and you change the preferences, ThinApp stores the changes in the sandbox for Acrobat Reader. When you start Firefox, Firefox cannot detect those changes because Firefox has its own sandbox. Opening a .pdf file with Firefox does not reflect the preference changes that exist in the standalone Acrobat Reader application. Import Order for Linked Packages ThinApp imports linked applications according to the order of applications in the RequiredAppLinks or OptionalAppLinks parameter. If either parameter specifies a wildcard character that triggers the import of more than one file, alphabetical order determines which package is imported first. The OptionalAppLinks parameter might appear as OptionalAppLinks=a.exe;b.exe;plugins\*.exe. Using a.exe and b.exe as sample executable files, ThinApp imports linked packages in the order described in Table 4‐1. Table 4-1. Imported Linked Packages Import Order Linked Package Base application a.exe b.exe Plug‐ins loaded in alphabetical order Nested plug‐ins for a.exe Nested plug‐ins for b.exe Nested plug‐ins for the first set of plug‐ins in this list For information about nested links, see “Set Up Nested Links with Application Link” on page 58. VMware, Inc.
Page 60: Application Updates That The Administrator Triggers
Storing Multiple Versions of a Linked Application in the Same Directory If the directory holds a linked package, and you add an updated version of the linked package in the same directory, the Application Link utility detects and uses the updated version. Using Application Sync for a Base Application and Linked Packages If you use Application Link to link packages to a base package, and you start the base package, Application Sync can update only the base package. For example, if you build a Microsoft Office 2007 package with Application Sync entries in the Package.ini file, build an Adobe Reader package with Application Sync entries in the Package.ini file, use Application Link to link the two packages, and start Microsoft Office 2007, Application Sync only updates Microsoft Office 2007. You can update both Microsoft Office 2007 and Adobe Reader by starting each application separately. If you do not update all the applications and link a base application to an expired plug‐in, the base application can still load and use the plug‐in. Application Updates That the Administrator Triggers ThinApp provides the AppSync.exe and sbmerge.exe utilities for administrators. The AppSync.exe utility forces an Application Sync update on a client machine. The sbmerge.exe utility make incremental updates to applications. For example, an administrator might use the utility to incorporate a plug‐in for Firefox or to change the home page of a Web site to point to a different default site. VMware, Inc.
Page 61: Forcing An Application Sync Update On Client Machines
Merge Sandbox Changes with Firefox This procedure for the sbmerge.exe utility uses Firefox 2.0.0.3 as an example of a captured application. Merge sandbox changes with Firefox 2.0.0.3 Capture Firefox 2.0.0.3. Double‐click the build.bat file in the captured application folder to rebuild the application package. 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. Create a Thinstall directory in the bin directory for the sandbox location. Start Firefox and make a change to the settings. For example, change the home page. From the command line, navigate to the directory where the ThinApp project folder resides. For example, navigate to C:\Program Files\VMware\VMware ThinApp\Captures\Mozilla Firefox 2.0.0.3. From the command line, type the "C:\Program Files\VMware\VMware ThinApp\sbmerge" Print command. ThinApp prints the changes that affected the sandbox folder when using the captured application. From the command line, type the "C:\Program Files\VMware\VMware ThinApp\sbmerge" Apply command. ThinApp empties the Thinstall folder and merges the sandbox changes with the application. VMware, Inc.
Page 62: Automatic Application Updates
ThinApp User’s Guide sbmerge.exe Commands The sbmerge.exe Print command displays sandbox changes and does not make modifications to the sandbox or original project. The sbmerge.exe Apply command merges changes from the sandbox with the original project. This command updates the project registry and file system to reflect changes and deletes the sandbox directory. Usage "C:\Program Files\VMware\VMware ThinApp\sbmerge" Print [<optional_parameters>] "C:\Program Files\VMware\VMware ThinApp\sbmerge" Apply [<optional_parameters>] Optional Parameters The optional sbmerge.exe parameters specify project and sandbox paths and block progress messages and merging of sandbox files. Table 4-2. Optional sbmerge.exe Parameters Parameter Description -ProjectDir <project_path> If you start the sbmerge.exe command from a location other than the application project folder, use the absolute or relative path to the project directory using the -ProjectDir <project_path> parameter. A sample command is "C:\Program Files\VMware\VMware ThinApp\sbmerge"...
Page 63: Dynamic Updates Without Administrator Rights
In the captured project. If you must update a small set of files or registry keys, replace the files in the captured project. This approach is useful for software developers who integrate ThinApp builds with their workflow. Upgrading Running Applications on a Network Share ThinApp allows you to upgrade or roll back an application that is running on a network share for multiple users. The upgrade process occurs when the user quits the application and starts it a second time. In Terminal Server environments, you can have multiple users executing different versions at the same time during the transition period. File Locks Starting an application locks the executable file package. You cannot replace, delete, or move the application. This file lock ensures that any computer or user who accesses a specific version of an application continues to have that version available as long as the application processes and subprocesses are running. If you store an application in a central location for many users, this file lock prevents administrators from replacing a packaged executable file with a new version until all users exit the application and release their locks. Upgrade a Running Application You can copy a new version of an application into an existing deployment directory with a higher filename extension, such as .1 or .2. This procedure uses Firefox as a sample application. You do not have to update shortcuts. Upgrade a running application Deploy the original version of the application, such as Firefox.exe. Copy the application to a central share at \\<server>\<share>\Firefox.exe. A sample location is C:\Program Files\Firefox\Firefox.exe. VMware, Inc.
Page 64: Sandbox Considerations For Upgraded Applications
Updating the ThinApp Version of Packages You can use the relink.exe utility to update an existing package or tree of packages to the latest version of ThinApp. Although you can install the latest version of ThinApp and run the build.bat utility to rebuild each target package with the latest ThinApp version, the relink.exe utility is a faster method to upgrade the ThinApp version of existing packages. You might want to update your package to benefit from the latest ThinApp features or support enhancements. relink Examples The relink.exe utility has an optional -Recursive flag and can target a single package or multiple packages. relink [-Recursive] <target> [<target> ...] For example, you can update an Adobe Reader package to the latest installed ThinApp version. relink AdobeReader.exe The relink.exe utility can use a wildcard pattern. relink *.exe *.dat The relink.exe utility can use directory names to process all ThinApp files in that directory. relink C:MyPackages If you specify the -Recursive flag, the relink.exe utility processes all ThinApp files in the directory and all subdirectories. This flag is intended for use only with directory names. If the target name contains spaces, you must use double quotes. relink "Microsoft Office Professional 2007.dat" VMware, Inc.
Page 65: Configuring Package Parameters
“Configuring Permissions” on page 72  “Configuring Objects and DLL Files” on page 74  “Configuring File Storage” on page 78  “Configuring Processes and Services” on page 81  “Configuring Sizes” on page 83  “Configuring Logging” on page 85  “Configuring Versions” on page 86  “Configuring Locales” on page 87  “Configuring Individual Applications” on page 88  “Configuring Dependent Applications with Application Link” on page 91  “Configuring Application Updates with Application Sync” on page 93  “Configuring MSI Files” on page 96  “Configuring Sandbox Storage and Inventory Names” on page 100 VMware, Inc.
Page 66: Package.ini File Structure
Parameters that do not apply to the standard sections can reside under any heading. Parameters do not have to appear in alphabetical order. Parameters That Apply to Package.ini or ##Attributes.ini Files You can apply certain parameters to the Package.ini file or the ##Attributes.ini file, depending on the requirements, to override the Package.ini settings at the directory level. You can use the DirectoryIsolationMode, CompressionType, and ExcludePattern parameters in an ##Attributes.ini file. The ##Attributes.ini file exists in the folder macros of the project folder. For more information about the ##Attributes.ini file, see “Modifying Settings in the ##Attributes.ini File” on page 24. Configuring the ThinApp Runtime You can modify ThinApp parameters for runtime configuration tasks that affect application startup performance and virtual computer names. NetRelaunch The NetRelaunch parameter determines whether to restart an application from the local disk when you run the application from a network share or removable disk, to address the slow startup of applications. ThinApp sets an initial value of the NetRelaunch parameter that detects whether an application runs from a network drive or a removable disk, and uses a stub executable file on the local hard disk to restart the application. This process addresses performance problems that Symantec AntiVirus generates when it tries to do a complete scan of executable files that open from a network share or removable disk, and on executable files that make the initial network connections. The scan can affect start times for large executable files. Because a large number of desktops have Symantec AntiVirus, ThinApp enables applications to open from a network share without incurring lengthy scan times. When the application runs from a network share or removable disk, ThinApp creates a stub executable file in the directory that the CachePath parameter sets on the local disk and restarts the application from this stub executable file. The stub executable file can load the runtime from the large package and read the rest of the application from its original location on the network. Symantec AntiVirus perceives that the application is local and does not scan the larger executable file on the network share or removable disk. VMware, Inc.
Page 67: Runtimeeula
Chapter 5 Configuring Package Parameters Examples If your application is small or you know that Symantec AntiVirus is not installed on the desktops to which you are deploying the application, you can modify the NetRelaunch parameter for stronger initial startup performance. [BuildOptions] NetRelaunch=0 RuntimeEULA The RuntimeEULA parameter controls the End‐User License Agreement display for the package. This parameter addresses legacy End‐User License Agreement requirements. VMware does not require a runtime EULA for ThinApp packages. Do not modify the value of this parameter. Examples The RuntimeEULA parameter prevents the display of the End‐User License Agreement. [BuildOptions] ;Default: do not show an Eula RuntimeEULA=0 VirtualComputerName The VirtualComputerName parameter determines whether to virtualize the computer name, to avoid naming conflicts between the deployment system and the capture system. Applications can use the name of the computer on which they are installed, or connect to a database and use the name of the computer in the connection string. Because the capture system is different from the deployment system, captured applications that require a computer name must virtualize the computer name to ensure that the application can run on any machine. ThinApp comments out the initial setting of the VirtualComputerName parameter. This parameter uses a string that GetComputerName and GetComputerNameEx API functions return in a virtual application. Examples If the capture system lacks the LOCALHOST name, ThinApp comments out the VirtualComputerName parameter. ;VirtualComputerName=<original_machine_name>...
Page 68: Wow64
You can uncomment the Wow64 parameter to simulate a 32‐bit environment for 32‐bit applications on a 64‐bit operating system. For example, a virtualized 32‐bit Oracle application might not work on a 64‐bit operating system. [BuildOptions] Wow64=0 QualityReportingEnabled The QualityReportingEnabled parameter specifies whether VMware can collect anonymous data on a package to improve ThinApp application support. VMware collects application information such as the version and number of application failures. If you agree to anonymous data collection during the capture process, the QualityReportingEnabled parameter uploads data every ten days. Examples You can modify the QualityReportingEnabled parameter to turn off ThinApp data collection. [BuildOptions] QualityReportingEnabled=0 Configuring Isolation You can modify ThinApp parameters to determine the read and write access to the file system and registry keys. DirectoryIsolationMode The DirectoryIsolationMode parameter specifies the level of read and write access for directories to the physical file system. The capture process sets the initial 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. Any unspecified directories, such as C:\myfolder, inherit the isolation mode from the Package.ini file. ThinApp provides only the Merged and WriteCopy isolation mode options in the capture process. You can use the Full isolation mode outside the wizard to secure the virtual environment. 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. 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. VMware, Inc.
Page 69: Registryisolationmode
18. Examples You can modify the DirectoryIsolationMode parameter with WriteCopy isolation to ensure that the application can read resources on the local machine, but not write to the host computer. This is the default setting for the snapshot.exe utility. You must place the parameter under an [Isolation] heading. [Isolation] DirectoryIsolationMode=WriteCopy You can assign Merged isolation mode to ensure that the application can read resources on and write to any location on the computer except where the package specifies otherwise. This is the default setting for the Setup Capture wizard. [Isolation] DirectoryIsolationMode=Merged RegistryIsolationMode The RegistryIsolationMode parameter controls the isolation mode for registry keys in the package. This setting applies to the registry keys that do not have explicit settings. The capture process does not set the value of this parameter. You can configure the registry isolation mode only in the Package.ini file. ThinApp sets the initial registry isolation mode to WriteCopy. For information about isolation mode options, see “DirectoryIsolationMode” on page 68. Do not use the Full isolation mode in the Package.ini file because that mode blocks the ability to detect and load system DLLs. You can use Full isolation mode as an override mechanism. You can place exceptions to the configured RegistryIsolationMode parameter in the registry key text files in the project directory. An exception might appear in a file, such as HKEY_CURRENT_USER.txt, as isolation_full HKEY_CURRENT_USER\Software\Macromedia. All runtime modifications to virtual files in the captured application are stored in the sandbox, regardless of the isolation mode setting. At runtime, virtual and physical registry files are indistinguishable to an application, but virtual registry files always supersede physical registry files when both exist in the same location. If virtual and physical entries exist at the same location, isolation modes do not affect access to these entries because the application always interacts with virtual elements. If external group policy updates occur separately from the package through the physical registry, you might remove virtual registry files from a package and verify that the parent file of these virtual registry files does not use Full isolation. Because child files inherit isolation modes from parent elements, Full isolation in a parent file can block the visibility of physical child files to an application. Examples You can modify the RegistryIsolationMode parameter to ensure that the application can read keys from the host computer, but not write to the host computer. [Isolation] RegistryIsolationMode=WriteCopy VMware, Inc.
Page 70: Configuring File And Protocol Associations
Microsoft Word 2003 opens .doc files and Microsoft Word 2007 opens .docx files. [Microsoft Office Word 2007.exe] FileTypes=.docx The capture process can create file type associations for .doc and .dot extensions and link them to Microsoft Word. [Microsoft Office Word 2003.exe] ReadOnlyData=bin\Package.ro.tvr Source=%ProgramFilesDir%\Microsoft Office\OFFICE11\WINWORD.EXE FileTypes=.doc.dot Protocols The Protocols parameter specifies the protocols, such as HTTP, that are visible to applications in the physical environment. This parameter is similar to the FileTypes parameter, but deals with applications that handle protocols rather than file types. The capture process generates initial values that you cannot add to. You can remove entries for browsers or other applications. Examples The capture process can specify protocols, such as the mailto protocol for a Microsoft Outlook package, in the Protocols parameter. [Microsoft Office Outlook 2007.exe] Protocols=feed;feeds;mailto;Outlook.URL.mailto;stssync;webcal;webcals Configuring Build Output You can modify ThinApp parameters to specify the location of the build output and the files in the package. ExcludePattern The ExcludePattern parameter excludes files or directories during the application build process. You must add a [FileList] heading before this parameter entry. VMware, Inc.
Page 71: Icon
If you store packages in a version control system and you want to exclude version control information from the virtual file system, you can exclude any directories called .svn or .cvs and all the subdirectories. [FileList] ExcludePattern=\.svn,\.cvs The pattern does not match filenames or directories that contain .svn or .cvs in the middle of the string. You can exclude any path that ends with .bak or .msi. [FileList] ExcludePattern=*.bak,*.msi Icon The Icon parameter specifies the icon file to associate with the generated executable file. This icon appears in the application, such as Microsoft Word, and in the files associated with the application, such as .doc files. Each application includes its own icon stored as a .ico file, within the .exe file of the application, or within a .dll file. The capture process attaches the icons to the executable files. The application uses the main group icon from the executable file in the Source parameter and the individual icon resource that the group icon points to. Examples You can modify the Icon parameter to use an alternative icon by specifying an executable file that is different from the executable file in the Source parameter. Alternative icons might be useful for third‐party companies. [<my_app>.exe] Source=%ProgramFilesDir%\<my_app>\app.exe Icon=%ProgramFilesDir%\<my_app>\app2.exe You can specify an icon set by appending ,1 ,2 to the end of the icon path. [<my_app>.exe] Source=%ProgramFilesDir%\<my_app>\<app>.exe Icon=%ProgramFilesDir%\<my_app>\<app2>.exe,1 You can use a .ico file to specify the application icon. [<my_app>.exe] Source=%ProgramFilesDir%\<my_app>\<app>.exe Icon=%ProgramFilesDir%\<my_app>\<my_icon>.ico OutDir The OutDir parameter specifies the directory that stores the build.bat output. Do not modify the value of this parameter. Examples The static value of the OutDir parameter specifies the bin directory of the project. [BuildOptions] OutDir=bin VMware, Inc.
Page 72: Retainallicons
AccessDeniedMsg=You do not have permission to execute this application, please call support @ 1-800-822-2992 AddPageExecutePermission The AddPageExecutePermission parameter supports applications that do not work in a Data Execution Prevention (DEP) environment. The DEP feature of Windows XP SP2, Windows Server 2003, and later operating system versions protects against some security exploits that occur with buffer overflow. This feature creates compatibility issues. Windows turns off the feature by default on Windows XP SP2 and you can use a machine‐specific opt‐in or opt‐out list of the applications to which to apply DEP protection. Opt‐in and opt‐out policies can be difficult to manage when a large number of machines and applications are involved. The AddPageExecutePermission parameter instructs ThinApp to add execution permission to pages that an application allocates. The application can run on machines that have DEP protection enabled without modifying the opt‐out list. ThinApp sets an initial value of the AddPageExecutePermission parameter that prevents any change to the DEP protections. Examples You can modify the AddPageExecutePermission parameter to add execution permission to pages that an application allocates. ThinApp executes code from memory pages that the application specifies. This is useful for applications that combine the program and its data into one area of memory. [BuildOptions] ;Disable some Data Execution protections for this particular application AddPageExecutionPermission=1 VMware, Inc.
Page 73: Permittedgroups
AccessDeniedMsg=You do not have permission to execute this application, please call support @ 1-800-822-2992 You can specify a user group setting for a specific application that overwrites the global PermittedGroups setting. [App1.exe] PermittedGroups=Guest AccessDeniedMsg=You do not have permission to execute this application, please call support @ 1-800-822-2992 If you do not specify a PermittedGroups setting for an application, the application inherits the global PermittedGroups value in the [BuildOptions] section. [App2.exe] You can mix group names and SID strings in the same entry for the PermittedGroups parameter. PermittedGroups=S-1-5-32-544;Office Users UACRequestedPrivilegesLevel The UACRequestedPrivilegesLevel parameter specifies privileges for programs requiring User Account Control (UAC) information. This parameter affects users working on Windows Vista or later operating system versions. You can use the following values to specify privileges:  asInvoker This value uses the profile in Vista.  requireAdministrator VMware, Inc.
Page 74: Uacrequestedprivilegesuiaccess
[BuildOptions] UACRequestedPrivilegesLevel=requireAdministrator UACRequestedPrivilegesUIAccess The UACRequestedPrivilegesUIAccess parameter specifies user interface access on Windows Vista or later operating system versions. These operating systems protect some elements of the user interface. ThinApp assigns an initial value of the UACRequestedPrivilegesUIAccess parameter to block application access to protected elements. Although you can assign a true or false value to the UACRequestedPrivilegesUIAccess parameter to specify user interface access, the parameter exists to support Microsoft settings. Examples You can keep the initial value of the UACRequestedPrivilegesUIAccess parameter to ensure that the virtual application cannot access protected elements. [BuildOptions] UACRequestedPrivilegesUiAccess=false Configuring Objects and DLL Files You can modify ThinApp parameters to specify COM object access and DLL loading requirements. ExternalCOMObjects The ExternalCOMObjects parameter determines whether Windows creates and runs COM objects in the physical environment rather than the virtual environment to facilitate application compatibility with ThinApp. COM objects that are external to the virtual environment always run in the physical environment. ThinApp sets an initial value of the ExternalCOMObjects parameter that creates and runs the COM objects in the virtual environment. COM supports out‐of‐process executable servers and service‐based COM objects. If an application can create COM objects that generate modifications on the host computer, the integrity of the host computer is at risk. If ThinApp runs out‐of‐process and service‐based COM objects in the virtual environment, ThinApp stores in the sandbox all changes that the COM objects make. The capture process does not generate this parameter. You can add this parameter to the Package.ini file. Examples When you troubleshoot a problem with VMware support and determine that an application implements COM objects that is not compatible with ThinApp, you can modify the ExternalCOMObjects parameter to run the COM objects outside of the virtual environment. You can list the CLSID keys. [BuildOptions] ExternalCOMObjects={8BC3F05E-D86B-11D0-A075-00C04FB68820};{7D096C5F-AC08-4F1F-BEB7-5C22C517CE39} VMware, Inc.
Page 75: Externaldlls
Virtual dictation software is a type of software that might interface with native applications that pass information between DLLs. ThinApp can pass the loading of DLLs in the virtual environment to Windows to ensure that local applications can interface with the DLLs. The ExternalDLLs parameter does not support a DLL file that depends on other DLL files in the virtual file system. In this case, Windows cannot load the DLL file. Examples You can modify the ExternalDLLs parameter to force Windows to load the inject.dll and injectme2.dll files from the virtual file system. [BuildOptions] ExternalDLLs=inject.dll;injectme2.dll ForcedVirtualLoadPaths The ForcedVirtualLoadPaths parameter instructs ThinApp to load DLL files as virtual DLL files even if the files reside outside the package. This parameter is useful when the application must load external system DLL files that depend on DLL files located in the package. The DLL paths can contain macros. Use semicolons to separate multiple paths. This parameter achieves the same result as the AddForcedVirtualLoadPath API function. See “AddForcedVirtualLoadPath” on page 119. Examples You can modify the ForcedVirtualLoadPaths parameter when you have an application that depends on external DLL files. When you capture Microsoft Office without Microsoft Outlook and a native version of Microsoft Outlook exists on the local system, you cannot send email from the virtual version of Microsoft Excel because the native envelope.dll file that is installed with Microsoft Outlook depends on the mso.dll file that ThinApp loads in the virtual environment. You can force ThinApp to load the envelope.dll file in the virtual environment instead of in the native environment. [BuildOptions] ForcedVirtualLoadPaths=%ProgramFilesDir%\Microsoft Office\Office10\envelope.dll IsolatedMemoryObjects The IsolatedMemoryObjects parameter lists the shared memory objects to isolate from other applications or from system objects. Applications that use CreateFileMapping and OpenFileMapping Windows functions create shared memory objects. When you do not isolate memory objects, conflicts can occur between virtual applications and native applications sharing those objects. For example, you might have a two versions of an application with one version in the native environment and one version in the virtual environment. When these application versions use information in the same memory object, the applications can interfere with each other and fail. You might want to isolate shared memory objects to ensure that virtual applications and system objects cannot detect each other. VMware, Inc.
Page 76: Isolatedsynchronizationobjects
IsolatedSynchronizationObjects The IsolatedSynchronizationObjects parameter lists the synchronization objects to isolate from other applications. Synchronization objects coordinate actions between applications. The following Windows synchronization objects might appear in logs for application errors:  OpenMutex  CreateMutex  OpenSemaphore  CreateSemaphore  OpenEvent  CreateEvent If these objects appear in log files, you might isolate the objects in the virtual environment to avoid a collision with synchronization objects that native applications create. You can isolate synchronization objects from applications that do not run in the same virtual namespace. If two applications share the same sandbox path, the applications have the same namespace for isolated synchronization objects. If two applications have the same sandbox name but different sandbox paths, the applications have separate namespaces. The IsolatedSynchronizationObjects parameter does not appear in the Package.ini file but you can add the parameter. ThinApp sets an initial value that makes synchronization objects accessible to other applications. Virtual applications with different sandboxes can detect the synchronization objects. The IsolatedSynchronizationObjects parameter accepts a list of entries that are separated by the semicolon (;). Each entry can use the asterisk (*) and question mark (?) as wildcard characters to match variable patterns. Examples You can modify the IsolatedSynchronizationObjects parameter to isolate the synchronization object with the My Shared Object name and the synchronization object with outlook in the name. [BuildOptions] IsolatedSynchronizationObjects=*outlook*;My Shared Object VMware, Inc.
Page 77: Notificationdlls
If ThinApp cannot load a DLL file, the package generates errors. This parameter does not appear in the Package.ini file. ThinApp SDK users can add this parameter to the file. Examples You can modify the NotificationDLLs parameter to make calls to the First.dll and Second.dll files. [BuildOptions] NotificationDLLs=First.dll;Second.dll NotificationDLLSignature The NotificationDLLSignature parameter works with the NotificationDLLs parameter and verifies that a specified DLL file has a signature. If the DLL does not have a signature, ThinApp does not load the file. Example You can modify the NotificationDLLSignature parameter with an asterisk (*) to ensure that the DLL file is authenticode‐signed. [BuildOptions] NotificationDLLSignature=* You can set an entity to ensure that the DLL is signed by that entity. [BuildOptions] NotificationDLLSignature=VMware, Inc. ObjectTypes The ObjectTypes parameter specifies a list of virtual COM object types that are visible to other applications in the physical environment. You can use scripts, such as VBScripts, to call objects that start captured applications. An object type is registered to only one native or virtual application at a time. If you install Office 2003 on the native machine and want to use a virtual Office 2007 package, you must determine whether to have the virtual or native application handle the object types. If you want the virtual Office 2007 to handle the object types, you can leave the ObjectTypes setting in the Package.ini file, build the package, and register it using the thinreg.exe utility. If you want the native Office 2003 to handle the object types, you must remove the ObjectTypes setting from the Package.ini file before building and registering the package. You cannot add random entries to the ObjectTypes parameter. You can only remove entries generated by the capture process. Examples If a script or a native application creates an Excel.Application COM object or other COM objects listed in the ObjectTypes parameter, ThinApp starts the virtual package. [Microsoft Office Excel 2007.exe] ObjectTypes=Excel.Application;Excel.Application.12;Excel.Chart; Excel.Macrosheet;Excel.Sheet; Excel.Workspace SandboxCOMObjects The SandboxCOMObjects parameter indicates whether applications in the physical environment can access ...
Page 78: Virtualizeexternaloutofprocesscom
This parameter addressed out‐of‐process COM objects that are not part of a ThinApp package and are not registered in the virtual registry. ThinApp sets an initial value of the VirtualizeExternalOutOfProcessCOM parameter to run external out‐of‐process COM objects in the virtual environment to ensure that COM objects cannot modify the host computer. If a compatibility problem exists with an external COM object running in the virtual environment, you can create and run COM objects on the host system. To run only specific COM objects outside of the virtual environment, you can use the ExternalCOMObjects parameter to list the CLSID of each COM object. Examples You can modify the VirtualizeExternalOutOfProcessCOM parameter to run all external out‐of‐process COM objects in the physical environment rather than the virtual environment. For example, you might use virtual Microsoft Access 2003 to send email through a native IBM Lotus Notes session. [BuildOptions] VirtualizeExternalOutOfProcessCOM=0 Configuring File Storage You can modify ThinApp parameters to configure file storage and set up virtual drives. For information about storage related to sandbox configuration, see “Configuring Sandbox Storage and Inventory Names” on page 100. CachePath The CachePath parameter sets the deployment system path to a cache directory for font files and stub executable files. Because of the frequent use of font and stub executable files, ThinApp must extract files in the cache quickly and place them on the physical disk. If you delete the cache, ThinApp can reconstruct the cache. You can use the THINSTALL_CACHE_DIR environment variable to override the CachePath parameter at runtime. If you do not set the THINSTALL_CACHE_DIR environment variable or the CachePath parameter, ThinApp sets an initial value of the CachePath parameter based on the SandboxPath parameter according to the following rules:  If the SandboxPath parameter is present in the Package.ini file and uses a relative path, the CachePath parameter uses the sandbox path and stores the cache at the same directory level as the sandbox.  If the SandboxPath parameter is present in the Package.ini file and uses an absolute path, or if the SandboxPath parameter does not exist in the Package.ini file, the CachePath parameter uses the %Local AppData%\Thinstall\Cache location. This places the cache directory on the local machine, regardless of there the user travels with the sandbox. ThinApp creates a Stubs directory within the cache. VMware, Inc.
Page 79: Upgradepath
When you use a USB device and move the sandbox on to the USB device, you might move the cache to the USB device to avoid interfering with the local machine. In this example, the cache and sandbox exist in the same directory level. CachePath=<sandbox_path> UpgradePath The UpgradePath parameter specifies the location of information and files for Application Sync and integer updates. ThinApp sets an initial value that causes the Application Sync utility to place log and cache files in the same location as the application executable file on the local machine. Integer updates operate in the same way with files. When the Application Sync utility downloads an update from a server, it stores the update with a temporary name in the UpgradePath location. The next time the application starts, ThinApp renames the temporary file with a .1 extension or a .2 extension depending on whether .1 already exists. ThinApp attempts to change the name with the .1 extension to the original name of the file that might reside in another directory. If ThinApp cannot make this change, the file keeps the .1 extension in the UpgradePath location. Running the original application accesses that file. For information about the Application Sync utility, see “Application Sync Updates” on page 53. Examples When the default location has limited space, such as a USB device, or you want to isolate upgrades from the application executable file, you can modify the UpgradePath parameter to specify another location to detect update files. The parameter can include environment variables in the path but cannot support folder macros. [BuildOptions] UpgradePath=C:\Program Files\<my_app_upgrades> VirtualDrives The VirtualDrives parameter specifies additional drive letters that are available to the application at runtime. ThinApp makes the virtual environment resemble the physical capture environment and mimics the physical drives that are available on the capture system. ThinApp represents virtual drives through the VirtualDrives parameter and a project folder, such as %drive_<drive_letter>%, that contains the virtual files on the drive. This project folder can reside in the read‐only file system of the package and in the sandbox when write operations cannot occur on the physical drive. The VirtualDrives parameter presents the drives to the application at runtime. The VirtualDrives parameter displays metadata about the drive, such as a the serial number and type of drive. For example, ThinApp detects the physical C: drive on the capture system and enters it into the parameter as a FIXED type of drive with the serial number. VMware, Inc.
Page 80 Isolation Modes for Virtual Drives Virtual drives are visible only to applications running in the virtual environment. Virtual drives do not affect the physical Windows environment. Virtual drives inherit isolation modes from the default isolation mode of the project unless you override the mode with a ##Attributes.ini file in the drive folder within the project directory. If you copy files to the %drive_D% folder before building the application, you can use Full isolation mode for this drive. The application always reads from the virtual drive and does not try to read from any corresponding physical CD‐ROM drive on the deployment system. If you do not copy files to the %drive_D% folder before building the application, you can use Merged or WriteCopy isolation modes for virtual drive folders depending on whether you want to read from and write to the physical drive on the deployment system. If you assign Merged isolation mode to your virtual drive, any write operations to that drive fail if that drive does not exist on the physical deployment system. ThinApp does not direct changes to the sandbox because Merged isolation mode instructs ThinApp to write to the physical drive. When the application cannot write to the physical drive as directed, the write operations fail. The VirtualDrives parameter does not override isolation mode settings. A virtual application might not detect files on a physical drive because of isolation mode settings. Modify Virtual Drive Isolation Modes You might modify isolation modes for virtual drives when you want to override the default isolation mode of the project. Modify virtual drive isolation modes Add the %Drive_<letter>% directory to your ThinApp project. Create a ##Attributes.ini file that includes an isolation mode entry for the drive letter. [Isolation] DirectoryIsolationMode=<isolation_mode> Place the ##Attributes.ini file in the %Drive_<letter>% directory. VMware, Inc.
Page 81: Configuring Processes And Services
VirtualDrives=Drive=X, Serial=ff897828, Type=REMOVABLE; Drive=D, Type=CDROM; Drive=Z Drive X is a removable disk with the ff797828 serial number. Drive D is a CD‐ROM drive with an assigned serial number. Drive Z is a FIXED disk with an assigned serial number. Configuring Processes and Services You can modify ThinApp parameters to configure processes and services that might specify write access to a native process or the startup and shutdown of virtual services. AllowExternalKernelModeServices The AllowExternalKernelModeServices parameter controls whether applications can create and run native kernel driver services. The service executable file must exist on the physical file system. ThinApp does not display the default parameter in the Package.ini file but assigns an initial value that prevents the application from starting a native Windows kernel driver service. Examples You can add the AllowExternalKernelModeServices parameter to the Package.ini file and modify the default value of 0 to 1 to allow the application to create or open a native Windows kernel driver service. [BuildOptions] AllowExternalKernelModeServices=1 AllowExternalProcessModifications The AllowExternalProcessModifications parameter determines whether captured applications can write to a native process. Some virtualized applications require a method to interact with native applications. ThinApp blocks any attempt by the captured application to inject itself into a native application. The captured application can still inject itself into virtual applications running in the same sandbox. ThinApp does not display the default parameter in the Package.ini file. When ThinApp blocks a captured application from injecting itself into a native application, Log Monitor generates trace logs that refer to the AllowExternalProcessModifications parameter. Examples You can add the AllowExternalProcessModifications parameter to the Package.ini file to support write operations from virtual processes to native processes. For example, a speech recognition application must inject itself into native applications to voice the text. [BuildOptions] AllowExternalProcessModifications=1 VMware, Inc.
Page 82: Allowunsupportedexternalchildprocesses
Examples To protect the physical file system from any changes, you can modify the AllowUnsupportedExternalChildProcesses parameter and block ThinApp from generating 64‐bit child processes outside of the virtual environment. ThinApp cannot run any 64‐bit processes because ThinApp does not support the processes in the virtual environment. [BuildOptions] AllowUnsupportedExternalChildProcesses=0 AutoShutdownServices The AutoShutdownServices parameter controls whether to shut down virtual services when the last nonservice process exits. ThinApp sets an initial value to stop virtual services when the last nonservice process exits. The parameter does not affect services outside the virtual context. Examples You can modify the AutoShutdownServices parameter when you run Apache Web Server and want to keep the virtual service running after the application that starts the service exits. [BuildOptions] AutoShutdownServices=0 AutoStartServices The AutoStartServices parameter controls whether to start the virtual services when the first virtual application starts. ThinApp sets an initial value that starts the virtual services that are installed with the startup type of Automatic. The virtual services start when the user runs the first parent process. Examples When applications install a service but do not use it, you can modify the AutoStartServices parameter to prevent the start of the virtual service and save time. [BuildOptions] AutoStartServices=0 ChildProcessEnvironmentDefault The ChildProcessEnvironmentDefault parameter determines whether ThinApp runs all child processes in the virtual environment. ThinApp creates all child processes in the virtual environment. If the processes are slow, you might want to move child processes to the physical environment. As a child process, Microsoft Outlook might affect performance when it copies the whole mailbox to the virtual environment. You can create specific exceptions with the ChildProcessEnvironmentExceptions parameter. See “ChildProcessEnvironmentExceptions” on page 83. VMware, Inc.
Page 83: Childprocessenvironmentexceptions
The ChildProcessEnvironmentExceptions parameter notes exceptions to the ChildProcessEnvironmentDefault parameter when you want to specify child processes. When you set the ChildProcessEnvironmentDefault parameter to Virtual, the ChildProcessEnvironmentExceptions parameter lists the applications that run outside of the virtual environment. When you set the ChildProcessEnvironmentDefault parameter to External, the ChildProcessEnvironmentExceptions parameter lists the applications that run in the virtual environment. Examples You can specify exceptions to running child processes in the virtual environment. When the virtual application starts a notepad.exe child process, the child process runs outside the virtual environment. [BuildOptions] ChildProcessEnvironmentExceptions=AcroRd.exe;notepad.exe ChildProcessEnvironmentDefault=Virtual Configuring Sizes You can modify ThinApp parameters to compress file and block sizes for applications. BlockSize The BlockSize parameter controls the size of compression blocks only when ThinApp compresses files for a build. A larger block size can achieve higher compression. Larger block sizes might slow the performance because of the following reasons:  The build process slows down with larger block sizes.  The startup time and read operations for applications slow down with large block sizes.  More memory is required at runtime when you use larger block sizes. You can specify the BlockSize parameter in the Package.ini file and in the ##Attributes.ini file. You can use different block sizes for different directories within a single project. Examples You can increase the default size of 64KB in the BlockSize parameter to a supported block size of 128KB, 256KB, 512KB, or 1MB. You can add k after the number to indicate kilobytes or m to indicate megabytes. [Compression] BlockSize=128k CompressionType The CompressionType parameter can compress all files in a package except for Portable Executable files. You can compress files when you have a large package and disk space is a top priority. Compression has a quick rate of decompression and little effect on most application startup times and memory consumption at runtime. Compression achieves similar compression ratios as the ZIP algorithm. VMware, Inc.
Page 84: Msicompressiontype
3 minutes 19 minutes Build time (second build) 2 minutes 1.2 minutes Compression has some performance consequences and can affect the startup time on older computers or in circumstances where you start the application multiple times and depend on the Windows disk cache to provide data for each start. The CompressionType parameter does not affect MSI files. For information about compressing MSI files, see “MSICompressionType” on page 84. Examples ThinApp sets default values for the OptimizeFor parameter and the CompressionType parameter that work together to achieve maximum memory performance and startup time. ThinApp stores all data in uncompressed format. [Compression] CompressionType=None [BuildOptions] OptimizeFor=Memory You can use this configuration when disk space is moderately important. Thinapp stores executable files in uncompressed format but compresses all the other data. [Compression] CompressionType=Fast [BuildOptions] OptimizeFor=Memory You can use this configuration when disk space is the top priority. ThinApp compresses all files. [Compression] CompressionType=Fast [BuildOptions] OptimizeFor=Disk MSICompressionType The MSICompressionType parameter determines whether to compress MSI files for package distribution. Compression improves performance when opening MSI files and using the ThinApp SDK. If you create an MSI file during the capture process, ThinApp adds the MSICompressionType parameter to the Package.ini file and sets the initial value of Fast to compress the file. Decompression occurs at the time of installation. You do not have to set the MSICompressionType parameter to Fast when you set the CompressionType parameter to Fast. Setting both parameters does not increase the amount of compression. VMware, Inc.
Page 85: Optimizefor
When ThinApp loads executable files from compressed format, ThinApp cannot share the file memory across similar suites of applications or with other users in a multiuser environment such as Terminal Server. When you want to compress all the package files except for Portable Executable files, you can leave the default OptimizeFor parameter and only set the CompressionType parameter is Fast. When you want to compress only MSI files, use the MSICompressionType parameter. Examples VMware recommends the default configuration of the OptimizeFor parameter and the CompressionType parameter to maximize performance. ThinApp stores all data in uncompressed format. The OptimizeFor parameter can be in either the Compression section or the BuildOptions section of the Package.ini file. [Compression] CompressionType=None [BuildOptions] OptimizeFor=Memory VMware recommends this configuration when disk space is moderately important. Thinapp stores executable files in uncompressed format but compresses all the other data. [Compression] CompressionType=Fast [BuildOptions] OptimizeFor=Memory VMware recommends this configuration when disk space is the top priority. ThinApp compresses all files. [Compression] CompressionType=Fast [BuildOptions] OptimizeFor=Disk Configuring Logging You can modify ThinApp parameters to prevent logging activity or customize the location of the log files. DisableTracing The DisableTracing parameter prevents .trace file generation when you run Log Monitor for security and resource purposes. You might block standard .trace file generation to hide the application history from a user. In a testing environment, you might turn off tracing for applications that you know work properly. Producing extra .trace files wastes disk space and CPU time. VMware, Inc.
Page 86: Logpath
DisableTracing=1 LogPath The LogPath parameter sets the location to store .trace files during logging activity. The default location is the same directory that stores the application executable file. You might change the default location to find a directory with more space or to redirect the logs from a USB device to the client computer. Unlike most paths in ThinApp, the log path cannot contain macros such as %AppData% or %Temp%. Examples You can set the LogPath parameter to store log files in C:\ThinappLogs. [BuildOptions] LogPath=C:\ThinappLogs Configuring Versions ThinApp parameters provide information about the versions of application executable files and ThinApp. CapturedUsingVersion The CapturedUsingVersion parameter displays the version of ThinApp for the capture process and determines the file system macros that ThinApp must expand. Do not modify or delete this parameter from the Package.ini file. ThinApp uses this parameter for backward compatibility and technical support. Examples The CapturedUsingVersion parameter might display ThinApp version 4.0.0‐2200. [BuildOptions] CapturedUsingVersion=4.0.0-2200 StripVersionInfo The StripVersionInfo parameter determines whether to remove all version information from the source executable file when ThinApp builds the application. The source executable file is the file listed in the Source parameter. Version information for executable files appears in Windows properties. Properties information includes the copyright, trademark, and version number. The StripVersionInfo parameter can remove the Version tab of Windows properties. ThinApp sets an initial value of the StripVersionInfo parameter that copies all version information from the source executable file. Examples In rare cases, you can modify the StripVersionInfo parameter to generate an application without version information. For example, you might want to circumvent version detection scans that compare versions against a database of outdated software. [app.exe] Source=%ProgramFilesDir%\myapp\app.exe StripVersionInfo=1 VMware, Inc.
Page 87: Version.xxxx
Version.Description=This Product is great! Configuring Locales You can use ThinApp parameters to verify locale information. AnsiCodePage The AnsiCodePage parameter displays a numerical value that represents the language of the operating system on which you capture the application. ThinApp uses the value to manage multibyte strings. This parameter does not perform language translation. The value that affects the display of text strings and use of the strings within the application. Examples When the operating systems of the deploy and capture computers have different languages, you might check the AnsiCodePage parameter. [BuildOptions] AnsiCodePage=1252 LocaleIdentifier The LocaleIdentifier parameter displays a numeric ID for the locale that affects layout and formatting. The value locates the correct language resources from the application. ThinApp runs packages according to the regional and language settings of the capture system rather than the settings of the system that runs packages. If you capture an application that requires a locale format, such as a date format, on a system that does not have the required format, you can comment out this parameter to ensure that the application can run on a system that has the supported format. Examples When the regional language of the operating system is U.S. English, the capture process sets the LocaleIdentifier parameter to 1033. [BuildOptions] LocaleIdentifier=1033 LocaleName The LocaleName parameter displays the name of the locale when you capture an application on Microsoft Vista. Examples The LocaleName parameter can display a Japanese locale name. [BuildOptions] LocaleName=ja-JP VMware, Inc.
Page 88: Configuring Individual Applications
Examples You can modify the CommandLine parameter with an entry based on the ʺC:\Program Files\Mozilla Firefox\firefox.exe" -safe-mode Start menu shortcut. CommandLine="C:\Program Files\Mozilla Firefox\firefox.exe" -safe-mode Command‐line arguments can use the /<option> <parameter> format. [<app>.exe] Source=%ProgramFilesDir%\<base_app>\<app>.exe Shortcut=<primary_data_container>.exe CommandLine="%ProgramFilesDir%\<base_app>\<app>.exe" /<option> <parameter> Disabled The Disabled parameter determines whether the application build target is only a placeholder and prevents ThinApp from generating the executable file in the /bin directory. ThinApp enables entry points when the application installer has shortcuts on the desktop and in the Start menu. When you do not select an entry point that appears in the Setup Capture wizard, ThinApp sets an initial value of the Disabled parameter that prevents the generation of that application executable file during the build process. Examples If you do not select the cmd.exe, regedit.exe, or iexplore.exe troubleshooting entry points during the capture process, and you develop a need to debug the environment, you can modify the Disabled parameter to generate these entry points. [app.exe] Source=%ProgramFilesDir%\<my_app>\<app>.exe Disabled=0 ReadOnlyData The ReadOnlyData parameter specifies the name of the read‐only virtual registry file created during the application build and designates the primary data container for an application. Do not modify this parameter. The Package.ini file displays this parameter in case you want to find the primary data container. VMware, Inc.
Page 89: Reserveextraaddressspace
To ensure that the application can start, the shortcut executable file must reside in the directory that stores the primary data container file. For information about the primary data container, see “ReadOnlyData” on page 88. Do not modify the value of the Shortcut parameter. ThinApp detects the primary data container during the capture process. Examples ThinApp can point AcroRd32.exe, the shortcut executable file, to Adobe Reader 8.exe, the primary data container file. [AcroRd32.exe] Shortcut=Adobe Reader 8.exe Source=%ProgramFilesDir%\Adobe\Reader 8.0\Reader\AcroRd32.exe ThinApp can point Microsoft Office Word 2007.exe, the shortcut executable file, to Microsoft Office Enterprise 2007.dat, the primary data container file. [Microsoft Office Word 2007.exe] Source=%ProgramFilesDir%\Microsoft Office\Office12\WINWORD.EXE Shortcut=Microsoft Office Enterprise 2007.dat VMware, Inc.
Page 90: Shortcuts
[Microsoft Office Word 2003.exe] ReadOnlyData=bin\Package.ro.tvr Source=%ProgramFilesDir%\Microsoft Office\OFFICE11\WINWORD.EXE Shortcuts=%Programs%\Microsoft Office Source The Source parameter specifies the executable file that ThinApp loads when you use a shortcut executable file. The parameter provides the path to the executable file in the virtual or physical file system. ThinApp specifies the source for each executable file. If an application suite has three user entry points, such as Winword.exe, Powerpnt.exe, and Excel.exe, the Package.ini file lists three application entries. Each entry has a unique source entry. If ThinApp cannot find the source executable file in the virtual file system, ThinApp searches the physical file system. For example, if you use native Internet Explorer from the virtual environment, ThinApp loads the source executable file from the physical file system. The Source parameter and the /bin directory in the project are not related to each other. The /bin directory stores the generated executable file and the Source path points to the installed executable file stored in the read‐only virtual file system. Do not modify the Source path. The capture process determines the path based on where the application installer places the executable file in the physical file system of the capture machine. ThinApp creates a virtual file system path based on the physical file system path. Examples The Source parameter can point to an entry point in C:\Program Files\<base_app>\<app>.exe. [<app>.exe] Source=%ProgramFilesDir%\<base_app>\<app>.exe WorkingDirectory The WorkingDirectory parameter determines the first location in which an application looks for files and places files. ThinApp does not include this parameter by default in the Package.ini file because Thinapp assumes the working directory is the directory where the executable file resides. The typical location in a ThinApp environment is on the desktop of the deployment machine. You can set the working directory for individual applications. The working directory can exist in the virtual file system, the sandbox, or the physical system depending on the isolation mode setting. You can use folder macros for the pathname conventions. The WorkingDirectory parameter sets the initial value of the working directory but the directory is dynamic as you navigate to other locations. VMware, Inc.
Page 91: Configuring Dependent Applications With Application Link
For more information about the Application Link utility, see “Application Link Updates” on page 56, “OptionalAppLinks” on page 93, and “RequiredAppLinks” on page 92. Application Link Pathname Formats The Application Link utility supports the following pathname formats:  Path names can be relative to the base executable file. For example, RequiredAppLinks=..\SomeDirectory results in C:\MyDir\SomeDirectory when you deploy the base executable file to c:\MyDir\SubDir\ Dependency.exe.  Path names can be absolute path names. An example is RequiredAppLinks=C:\SomeDirectory.  Path names can use a network share or a UNC path. An example is RequiredAppLinks=\\share\somedir\Dependency.exe.  Path names can contain environment variables and dynamically expand to any of the preceding path names. An example is RequiredAppLinks=%MyEnvironmentVariable%\Package.dat. The risk of using environment variables is that a user might change the values before starting the application and create an Application Link dependency other than the one that the administrator set up.  Path names can contain ThinApp folder macros. An example is RequiredAppLinks=%SystemSystem%\Package.dat.  Path names can specify multiple links or dependencies with a semicolon that separates individual filenames. An example is RequiredAppLinks=Dependency1.exe; Dependency2.exe;.  Path names can contain asterisk and query wildcard characters (* and ?) in filenames and path locations. For example, RequiredAppLinks=WildPath*\WildFilename*.dat. If a path containing a wildcard character matches more than one directory in the file system, each matching directory name will be returned, to enable additional path or filename matching. VMware, Inc.
Page 92: Requiredapplinks
Importing packages involves the following operations:  Running VBScripts from imported packages  Starting autostart services from imported packages  Registering fonts from imported packages  Relocating SxS DLL files from Windows XP to Windows Vista You must create a link to the primary data container of a package. You cannot link to other shortcut packages. Path names are on the deployment machine because the linking takes effect at runtime on the client machine. Use semicolons to separate the linked packages. For information about pathname formats, see “Application Link Pathname Formats” on page 91. Examples If you package the .NET framework in the dotnet.exe package and you have a .NET application, you can specify that the application needs to link to the dotnet.exe file before it can start. RequiredAppLinks=C:\abs\path\dotnet.exe You can specify a relative path. RequiredAppLinks=<relative_path>\dotnet.exe You can specify a UNC path. RequiredAppLinks=\\server\share\dotnet.exe You can use ThinApp folder macros in the path value. RequiredAppLinks=%SystemSystem%\Package.dat You can use environment variables in the path value. The risk of using environment variables is that a user might change the values before starting the application and create an Application Link dependency other than the one that the administrator set up. RequiredAppLinks=%MyEnvironmentVariable%\Package.dat You can import a single package located in the same directory as the base executable file. RequiredAppLinks=Plugin.exe You can import a single package located in a subdirectory of the base executable file. RequiredAppLinks=plugins\Plugin.exe You can import all executable files located in the directory for plug‐in files. If ThinApp cannot import any executable file because the file is not a valid Thinapp package or because a security problem exists, the base executable file fails to load. RequiredAppLinks=plugins\*.exe You can import all executable files located at the n:\plugins absolute path. RequiredAppLinks=n:\plugins\*.exe VMware, Inc.
Page 93: Optionalapplinks
AppSyncExpireMessage=This application has been unable to contact its update server for AppSyncExpirePeriod days, so it is unavailable for use. Check your network connection and try again AppSyncUpdatedMessage= AppSyncClearSandboxOnUpdate=0 AppSyncClearSandboxOnUpdate The AppSyncClearSandboxOnUpdate parameter determines whether to clear the sandbox after an update. ThinApp sets an initial value of the AppSyncClearSandboxOnUpdate parameter that keeps the contents of the sandbox. Examples You can modify the AppSyncClearSandboxOnUpdate parameter to clear the sandbox after application updates. AppSyncClearSandboxOnUpdate=1 VMware, Inc.
Page 94: Appsyncexpiremessage
AppSyncExpirePeriod The AppSyncExpirePeriod parameter sets the expiration of the package in minutes (m), hours (h), or days (d). If ThinApp cannot reach the Web server to check for updates, the package continues to work until the expiration period ends and the user closes it. Even after the expiration period ends, ThinApp tries to reach the Web server at each subsequent startup attempt. Examples You can prevent the package from expiring with the default never value. AppSyncExpirePeriod=never AppSyncURL The AppSyncURL parameter sets the Web server URL or fileshare location that stores the updated version of an application. ThinApp checks this location and downloads the updated package. Application Sync works over the HTTP (unsecure), HTTPS (secure), and File protocols. Part of the HTTPS protocol involves checking the identity of the Web server. You can include a user name and a password in the AppSyncURL parameter for basic authentication. ThinApp adheres to the standard Internet Explorer proxy setting. You must uncomment the AppSyncURL parameter to activate all Application Sync parameters. Examples You can assign an HTTP or HTTPS value to the AppSyncURL parameter according to the following format. AppSyncURL=https://<site.com>/<path>/<package_name>.exe You can specify local and network drive paths. file:///C:/<path>/<package_name>.exe You can use a UNC path and access locations of network resources. file://<server>/<share>/<path>/<package_name>.exe AppSyncUpdateFrequency The AppSyncUpdateFrequency parameter specifies how often ThinApp checks the Web server for application updates. You can set the update frequency in minutes (m), hours (h), or days (d). ThinApp sets an initial value of 1d that connects a package to the Web server once a day to check for updates. ThinApp does not check for an update when another running application shares the same sandbox. Examples You can modify the AppSyncUpdateFrequency parameter with a value of 0 to set the application to check for updates every time you start it. AppSyncUpdateFrequency=0 VMware, Inc.
Page 95: Appsyncupdatedmessage
AppSyncWarningMessage=This application will become unavailable for use in %%remaining_days%% day(s) if it cannot contact its update server. Check your network connection to ensure uninterrupted service. The %%remaining_days%% variable is the number of days remaining until the expiration of the package. If the value of the AppSyncWarningPeriod parameter is in hours or minutes, change the message to indicate hours or minutes rather than days. AppSyncWarningPeriod The AppSyncWarningPeriod parameter sets the start of the warning period before a package expires. You can specify minutes (m), hours (h), or days (d). When the warning period starts, ThinApp checks the Web server every time an application starts and sets the value of the AppSyncUpdateFrequency parameter to 0. Examples The default period of the AppSyncWarningPeriod parameter is five days. AppSyncWarningPeriod=5d VMware, Inc.
Page 96: Configuring Msi Files
MSIArpProductIcon=%Program Files Common%\Microsoft Shared\OFFICE12\ Office Setup Controller\OSETUP.DLL,1 The <icon_index_number> entry in this MSIArpProductIcon=<path_to_icon_file>[,<icon_index_number>] format is applicable only when multiple icons are available in a DLL file or executable file. MSIDefaultInstallAllUsers The MSIDefaultInstallAllUsers parameter sets the installation mode of the MSI database. You can install a .msi file for all users on a computer and for individual users. For information about forcing an MSI installation for each user or each machine, see “Force MSI Deployments for Each User or Each Machine” on page 44. The parameter works only when the MSIFilename parameter requests the generation of a Windows Installer database. Examples ThinApp sets an initial value for the MSIDefaultInstallAllUsers parameter that installs the MSI database with shortcuts and file type associations for all users who log in to the computer. The user who installs the database must have administrator rights. You can use this approach to push the application to desktops for all users. [BuildOptions] MSIFilename=<my_msi>.msi MSIDefaultInstallAllUsers=1 An individual user can install the MSI database with shortcuts and file type associations for only that user. You do not need administrator rights for an individual user installation. Use this approach when you want each user to deploy the application separately. [BuildOptions] MSIFilename=<my_msi>.msi MSIDefaultInstallAllUsers=0 An administrator can install the MSI database for all users on a machine or an individual user without administrator rights can install the database for only that user. [BuildOptions] MSIFilename=<my_msi>.msi MSIDefaultInstallAllUsers=2 VMware, Inc.
Page 97: Msifilename
ThinApp comments out the MSIFilename parameter unless you specify MSI generation during the capture process. Examples The inventory name is the default name in the MSIFilename parameter. [BuildOptions] ;MSIFilename=<inventory_name>.msi You can generate an MSI file during the build process and replace the filename with your own filename. [BuildOptions] MSIFilename=<my_msi>.msi MSIInstallDirectory The MSIInstallDirectory parameter specifies the relative path of the MSI installation directory. The path is relative to %ProgramFilesDir% for installations on each machine and relative to %AppData% for installations for each user. When you install the MSI database for all users, ThinApp places applications in the C:\%ProgramFilesDir%\<InventoryName> (VMware ThinApp) directory during the installation on each machine. When you install the MSI database for individual users, ThinApp places applications in the C:\%AppData%\<InventoryName> (VMware ThinApp) directory. The parameter works only when the MSIFilename parameter requests the generation of a Windows Installer database. Examples If you do not want the MSIInstallDirectory parameter to use a location based on the inventory name, you can install a .msi file in the C:\Program Files\<my_application> directory. [BuildOptions] MSIFilename=<my_msi>.msi MSIInstallDirectory=<my_application> MSIManufacturer The MSIManufacturer parameter specifies the manufacturer or packaging company of the MSI database and displays the value in the Windows Add or Remove Programs dialog box. ThinApp sets the initial value of the MSIManufacturer parameter to the name of the company that your copy of Windows is registered to. The parameter works only when the MSIFilename parameter requests the generation of a Windows Installer ...
Page 98: Msiproductcode
You can modify the MSIManufacturer parameter to display the name of a specific department. For example, users can see a department name in the Windows Add or Remove Programs dialog box and contact the help desk for that department. [BuildOptions] MSIFilename=<my_msi>.msi MSIManufacturer=<department_or_company_name> MSIProductCode The MSIProductCode parameter specifies a product code for the MSI database. Windows Installer uses the code to identify MSI packages. The capture process generates a random and unique product code that is not taken from the application. The value must be a valid Globally Unique Identifier (GUID). The parameter works only when the MSIFilename parameter requests the generation of a Windows Installer database. Do not modify the MSIProductCode parameter. Examples The capture process can create an MSI file with 590810CE‐65E6‐3E0B‐08EF‐9CCF8AE20D0E as the product code. [BuildOptions] MSIFilename=<my_msi>.msi MSIProductCode={590810CE-65E6-3E0B-08EF-9CCF8AE20D0E} MSIProductVersion The MSIProductVersion parameter specifies a product version number for the MSI database to facilitate version control. This version number is unrelated to the application version or the ThinApp version. ThinApp assigns an initial version of 1.0. This version appears in the properties of the database. When you deploy a package to a machine that already has the package installed, Windows Installer checks the version numbers and blocks the installation of an older version over an updated version. In this situation, you must uninstall the new version. The MSIProductVersion parameter works only when the MSIFilename parameter requests the generation of a Windows Installer database. Examples You can change the value of the MSIProductVersion parameter when you change the MSI package. A value of 2.0 causes ThinApp to uninstall a 1.0 version of the package and install the 2.0 version of the package. [BuildOptions] MSIFilename=<my_msi>.msi MSIProductVersion=2.0 The format of the MSIProductVersion value is X.Y.Z. The values of X and Y range from 0 to 255, and the value of Z ranges from 0 to 65536. VMware, Inc.
Page 99: Msirequireelevatedprivileges
The parameter works only when the MSIFilename parameter requests the generation of a Windows Installer database. Examples You can modify the MSIRequireElevatedPrivileges parameter to block the UAC prompt and the installation across all computers. [BuildOptions] MSIFilename=<my_msi>.msi MSIRequireElevatedPrivileges=0 MSIUpgradeCode The MSIUpgradeCode parameter specifies a code for the MSI database that facilitates updates. When two packages, such as the version 1.0 package and the version 2.0 package, have the same upgrade code, the MSI installer detects this link, uninstalls the earlier package, and installs the updated package. The capture process generates a random upgrade code based on the inventory name. To ensure that the MSI database versions have the same upgrade code, keep the same inventory name across versions of the MSI wrapper. For information about the inventory name, see “InventoryName” on page 100. The parameter works only when the MSIFilename parameter requests the generation of a Windows Installer database. Do not modify the UpgradeCode value unless the new value is a valid GUID. Examples The capture process can create an MSI file with D89F1994‐A24B‐3E11‐0C94‐7FD1E13AB93F as the upgrade code. [BuildOptions] MSIFilename=mymsi.msi MSIUpgradeCode={D89F1994-A24B-3E11-0C94-7FD1E13AB93F} MSIStreaming The MSIStreaming parameter determines the use of .cab files that can affect application performance. ThinApp sets an initial value that compresses the package files in a .cab file and makes it easier to move the file. The .cab file is in the MSI file. Examples You can modify the MSIStreaming parameter to avoid a .cab file when it slows down the installation process for applications. You can distribute the MSI file and individual executable files in the /bin directory to install the application. [BuildOptions] MSIStreaming=1 VMware, Inc.
Page 100: Configuring Sandbox Storage And Inventory Names
For more information about the sandbox placement and structure, see Chapter 6, “Locating the ThinApp Sandbox,” on page 103. InventoryName The InventoryName parameter is a string that inventory tracking utilities use for package identification. This parameter determines the default names of the project folder and sandbox during the application capture process. The application capture process sets a default value for the InventoryName parameter based on new strings created under one of the following locations:  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall  HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall The thinreg.exe utility and ThinApp MSI files reference the inventory name to determine the product name for display in the Add or Remove Programs control panel. For example, if the inventory name is SuperApp and you install an MSI file or register a package with the thinreg.exe utility, the Add or Remove programs list displays an installed application with the SuperApp (VMware ThinApp) string. ThinApp appends VMware ThinApp to the inventory name to distinguish applications that are virtualized during inventory scans. You can use the same inventory name across different versions of the same application to ensure that only the most recent version appears in Add or Remove Programs list. The applications overwrite each other in the Add or Remove Programs list and prevent you from uninstalling all of the registered packages. To uninstall more than one version, use a different inventory name for each version. For example, use Microsoft Office 2003 and Microsoft Office 2007 as inventory names rather than just Microsoft Office. When you maintain different versions of a virtual application in the same environment, you might want to change the SandboxName parameter to ensure that a new version has isolated user settings in a different sandbox. If you have a package that includes other applications, you might update the inventory name manually to reflect the true contents of the package. For example, if you capture the SuperApp application and the package includes Java Runtime, the InventoryName value might appear as Java Runtime Environment 1.5 instead of SuperApp. The Add or Remove Programs list displays the first application installed within the package. Examples You can modify the InventoryName parameter to Microsoft Office 2003. [BuildOptions]...
Page 101: Sandboxname
SandboxName The SandboxName parameter specifies the name of the directory that stores the sandbox. Thinapp sets an initial value that uses the inventory name as the sandbox name. When you upgrade an application, the sandbox name helps determine whether users keep previous personal settings or require new settings. Changing the sandbox name with new deployments affects the need to create a sandbox with different settings or keep the same sandbox. Examples When you update an application and want to use new user preferences for the application, you can modify the SandboxName parameter to reflect the updated version. [BuildOptions] SandboxName=My Application 2.0 SandboxNetworkDrives The SandboxNetworkDrives parameter determines whether ThinApp directs write operations to a network drive or to the sandbox, regardless of isolation mode settings. When you use this parameter to direct write operations to network drives, the result is the same as setting the isolation mode for the drive to Merged mode. Examples When you want to save space or share files for collaborative work, leave the default setting of the SandboxNetworkDrives parameter to direct write operations to network drives without storing changes in a sandbox. [BuildOptions] SandboxNetworkDrives=0 You can store changes in the sandbox and prevent the user from making changes to network drives. [BuildOptions] SandboxNetworkDrives=1 SandboxPath The SandboxPath parameter determines the path to the sandbox. The path to the sandbox can be relative or absolute, can include folder macros or environment variables, and can exist on a network drive. For advanced information about how ThinApp sets an initial sandbox location or searches for the sandbox, see “Search Order for the Sandbox” on page 103. You might work with the SandboxPath parameter to address local, USB drive, or network needs, to address space limitations in the initial sandbox location, or to move the sandbox to the desktop for troubleshooting purposes. The sandbox path does not include the sandbox name because the SandboxName parameter determines that name. VMware, Inc.
Page 102: Sandboxremovabledisk
ThinApp User’s Guide Examples You can modify the SandboxPath parameter to create the sandbox in the same directory as the executable file. If Mozilla Firefox 3.0 is the value of the SandboxName parameter, you can create the Mozilla Firefox 3.0 sandbox in the same directory that Firefox runs from. [BuildOptions] SandboxPath=. You can create the sandbox in a subdirectory subordinate to the executable file location. [BuildOptions] SandboxPath=LocalSandbox\Subdir1 You can create the sandbox in the %AppData% folder of the user under the Thinstall directory. [BuildOptions] SandboxPath=%AppData%\Thinstall You can store the sandbox on a mapped drive to back up the sandbox or to keep application settings for users who log in to any machine. If Mozilla Firefox 3.0 is the value of the SandboxName parameter, you can create the sandbox in Z:\Sandbox\Mozilla Firefox 3.0. [BuildOptions] SandboxPath=Z:\Sandbox SandboxRemovableDisk The SandboxRemovableDisk parameter determines whether the application can write removable disk changes to the disks or to the sandbox. Removable disks include USB flash devices and removable hard drives. ThinApp sets an initial value that instructs the application to write removable disk file changes to the disk. Examples To save space, you can modify the SandboxRemovableDisk parameter to direct removable disk changes to the sandbox. Depending on the isolation mode for the removable disk, changes to files stored on the disk can reside in the sandbox or on the removable disk. [BuildOptions] SandboxRemovableDisk=1 VMware, Inc.
Page 103: Locating The Thinapp Sandbox
“Sandbox Structure” on page 106 Search Order for the Sandbox During startup of the captured application, ThinApp searches for an existing sandbox in specific locations and in a specific order. ThinApp uses the first sandbox it detects. If ThinApp cannot find an existing sandbox, ThinApp creates one according to certain environment variable and parameter settings. Review the search order and sandbox creation logic before changing the placement of the sandbox. The search order uses Mozilla Firefox 3.0 as an example with the following variables:  <sandbox_name> is Mozilla Firefox 3.0 The SandboxName parameter in the Package.ini file determines the name. See “SandboxName” on page 101.  <sandbox_path> is Z:\sandboxes The SandboxPath parameter in the Package.ini file determines the path. See “SandboxPath” on page 101.  <exe_directory> is C:\Program Files\Firefox The application runs from this location.  <computer_name> is JOHNDOE‐COMPUTER  %AppData% is C:\Documents and Settings\JohnDoe\Application Data ThinApp requests the Application Data folder location from the operating system. The location depends on the operating system or configuration. VMware, Inc.
Page 104 For example, C:\Program Files\Firefox\Thinstall\Mozilla Firefox 3.0  <sandbox_path>\<sandbox_name>.<computer_name> For example, Z:\sandboxes\Mozilla Firefox 3.0.JOHNDOE-COMPUTER  <sandbox_path>\<sandbox_name> For example, Z:\sandboxes\Mozilla Firefox 3.0  %AppData%\Thinstall\<sandbox_name>.<computer_name> For example, C:\Documents and Settings\JohnDoe\Application Data\Thinstall\Mozilla Firefox 3.0.JOHNDOE-COMPUTER  %AppData%\Thinstall\<sandbox_name> For example, C:\Documents and Settings\JohnDoe\Application Data\Thinstall\Mozilla Firefox 3.0 If ThinApp does not detect the %<sandbox_name>_SANDBOX_DIR% or %THINSTALL_SANDBOX_DIR% environment variable, and does not detect the specified file system directories, ThinApp creates a sandbox using the following guidelines in this order:  If the SANDBOXPATH Package.ini parameter is set, the value determines the sandbox location.  If ThinApp completes the sandbox search without any results, ThinApp creates a sandbox in the default %AppData%\Thinstall directory of the user. Only one computer at a time can use a shared sandbox. If a computer is already using a sandbox, ThinApp creates a new sandbox to allow you to continue working until the previous copy of the sandbox closes. VMware, Inc.
Page 105: Controlling The Sandbox Location
Store the Sandbox in a Thinstall Directory on a USB Drive at the Same Level as the Executable File The sandbox in a Thinstall directory located on a USB drive must be stored at the same level at which the executable file is stored. Store the sandbox in a Thinstall directory on a USB drive at the same level as the executable file If the %THINSTALL_SANDBOX_DIR% or %<sandbox_name>_SANDBOX_DIR% environment variables are set, unset the variables. On the portable device, create a Thinstall directory in the same directory as your captured application. The next time the packaged application starts from the portable device, the application creates a sandbox in the Thinstall directory. If the application and sandbox originally ran from another location, such as a computer, and you need the same sandbox on a portable device, copy the Thinstall directory from %AppData% to the directory where the executable file resides on the device. ThinApp no longer uses the sandbox in the original location. VMware, Inc.
Page 106: Sandbox Structure
 Registry.rw.tvr – Contains all registry modifications that the application makes.  Registry.rw.lck – Prevents other computers from simultaneously using a registry located on a network share.  Registry.tvr.backup – Contains a backup of the .tvr file that ThinApp uses when the original .tvr file is corrupted. In addition to these registry files, the sandbox contains directories that include %AppData%, %ProgramFilesDir%, and %SystemRoot%. Each of these folders contains modifications to respective folders in the captured application. Making Changes to the Sandbox ThinApp stores file system information in the virtual registry. The virtual registry enables ThinApp to optimize file system access in the virtual environment. For example, when an application tries to open a file, ThinApp does not have to consult the real file system for the real system location and again for the sandbox location. Instead, ThinApp can check for the existence of the file by consulting only the virtual registry. This ability increases the ThinApp runtime performance. VMware does not support modifying or adding files directly to the sandbox. If you copy files to the sandbox directory, the files are not visible to the application. If the file already exists in the sandbox, you can overwrite and update the file. VMware recommends that you perform all modifications from the application itself. Listing Virtual Registry Contents with vregtool Because the sandbox contains the modifications to the registry, you might need the vregtool utility to view modified virtual registry changes. You must have access to the vregtool utility in C:\Program Files\VMware\VMware ThinApp. A sample command to list the contents of a virtual registry file is vregtool registry.rw.tvr printkeys. VMware, Inc.
Page 107: Creating Thinapp Snapshots And Projects From The Command Line
This information includes the following topics:  “Methods of Using the snapshot.exe Utility” on page 107  “Sample snapshot.exe Commands” on page 109  “Create a Project Without the Setup Capture Wizard” on page 109  “Customizing the snapshot.ini File” on page 110 Methods of Using the snapshot.exe Utility You can use the snapshot.exe utility to create snapshot files of machine states, create the template file for the Package.ini file, create a ThinApp project, and display the contents of a snapshot file. For information about the full procedure to create a ThinApp project from the command line, see “Create a Project Without the Setup Capture Wizard” on page 109. Creating Snapshots of Machine States The snapshot.exe utility creates a snapshot file of a machine state. ThinApp captures the machine state and saves it to a single file to create a project. The snapshot.exe utility saves a copy of registry data and file system metadata that includes paths, filenames, sizes, attributes, and timestamps. Usage snapshot.exe SnapshotFileName.snapshot [-Config ConfigFile.ini][BaseDir1][BaseDir2][BaseReg1] VMware, Inc.
Page 108: Creating The Template Package.ini File From Two Snapshot Files
Examples Snapshot Start.snapshot –SuggestProject End.snapshot Template.ini ThinApp requires all of the parameters. Creating the ThinApp Project from the Template Package.ini File The snapshot.exe utility creates the ThinApp project file from the template Package.ini file. Usage snapshot.exe Template.ini -GenerateProject OutDir [-Config ConfigFile.ini] Examples Snapshot Template.ini –GenerateProject C:\MyProject Snapshot Template.ini –GenerateProject C:\MyProject –Config MyExclusions.ini -Config ConfigFile.ini is optional. The configuration file specifies directories or registry subkeys for exclusion from the project. If you do not specify a configuration file, ThinApp uses the snapshot.ini file. VMware, Inc.
Page 109: Displaying The Contents Of A Snapshot File
Prints the contents of a saved state. snapshot C:\start.snapshot -SuggestProject Generates a ThinApp project by comparing two saved C:\end.snapshot C:\project.ini states. Create a Project Without the Setup Capture Wizard You can use the snapshot.exe utility from the command line instead of using the Setup Capture wizard that runs the snapshot.exe utility in the background. The command‐line utility is useful to package a large number of applications or automate ThinApp project creation. The typical location of the snapshot.exe utility is C:\Program Files\VMware\VMware ThinApp\snapshot.exe. The snapshot process makes a copy of the all registry entries on the system and file system metadata. File system metadata includes path, filename, attribute, size, and time stamp information but excludes actual file data. Create a project with the snapshot.exe command-line utility Save an initial snapshot of the current machine configuration to disk. snapshot.exe C:\Start.snapshot Install the application and make any necessary manual system changes. VMware, Inc.
Page 110: Customizing The Snapshot.ini File
(Optional) Delete the temporary C:\Start.snapshot, C:\End.snapshot, and C:\Template.ini files. (Optional) To generate multiple projects with different configurations, reuse the original Start.snapshot file and repeat the procedure from Step Customizing the snapshot.ini File The snapshot.ini configuration file specifies what registry keys to exclude from a ThinApp project when you capture an application. For example, if you use Internet Explorer 7, you might need ThinApp to capture the following registry keys:  HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Desktop\Components  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\0001\Software\Microsoft\windows\CurrentVersion\Internet Settings If the snapshot.ini file excludes the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections key by default, you can remove this key from the snapshot.ini file to ensure that ThinApp captures the key in the capture process. If you do not customize the snapshot.ini file, the snapshot process loads the file from one of these locations:  Application Data\Thinapp\snapshot.ini This location is the AppData directory of the user.  C:\Program Files\VMware\VMWare Thinapp\snapshot.ini This is the location from which ThinApp runs the snapshot.exe utility. VMware, Inc.
Page 111: Thinapp File System Formats And Macros
“ThinApp Folder Macros” on page 111 Virtual File System Formats ThinApp generates the following virtual file system formats:  Build The setup capture process generates this format from files found directly on the physical file system. ThinApp uses folder macros to represent Windows shell folder locations.  Embedded The build.bat file triggers a build process that embeds a read‐only file system in executable files. The executable files provide block‐based streaming to client computers. ThinApp compresses the file system.  Sandbox Running the captured application generates the read‐write directory structure that holds file data that the application modifies. File modifications that prompt ThinApp to extract embedded virtual files to the sandbox include the following operations:  Changing the time stamp or attributes of a file  Opening a file with write access  Truncating a file  Renaming or moving a file The embedded and sandbox file systems use folder macros to enable file paths to dynamically expand at runtime. ThinApp Folder Macros ThinApp uses macros to represent file system path locations that might change when virtualized applications run on different Windows operating systems or computers. The use of macros enables shared application profile information to instantly migrate to different operating systems. VMware, Inc.
Page 112: List Of Thinapp Macros
C:\Documents and Settings\All Users\Start Menu %Common Startup% C:\Documents and Settings\All Users\Start Menu\Programs\Startup %Common Templates% C:\Documents and Settings\All Users\Templates %Cookies% C:\Documents and Settings\<user_name>\Cookies %Desktop% C:\Documents and Settings\<user_name>\Desktop %Drive_c% %Drive_m% %Favorites% C:\Documents and Settings\<user_name>\Favorites %Fonts% C:\Windows\Fonts %History% C:\Documents and Settings\<user_name>\Local Settings\History VMware, Inc.
Page 113: Processing %Systemroot% In A Terminal Services Environment
C:\Windows\Resources %Resources Localized% C:\Windows\Resources\<language_ID> %SendTo% C:\Documents and Settings\<user_name>\SendTo %Startup% C:\Documents and Settings\<user_name>\Start Menu\Programs\Startup %SystemRoot% C:\Windows %SystemSystem% C:\Windows\System32 %TEMP% C:\Documents and Settings\<user_name>\Local Settings\Temp %Templates% C:\Documents and Settings\<user_name>\Templates Processing %SystemRoot% in a Terminal Services Environment A Terminal Services environment has a shared Windows directory, such as C:\Windows, and a private Windows directory, such as C:\Documents and Settings\User\Windows. In this environment, ThinApp uses the user‐specific directory for %SystemRoot%. VMware, Inc.
Page 114 ThinApp User’s Guide VMware, Inc.
Page 115: Creating Thinapp Scripts
Adding scripts to your application involves creating an ANSI text file with the .vbs file extension in the root application project directory. The root project directory is the same directory that contains the Package.ini file. During the build process, ThinApp adds the script files to the executable file and runs each of the script files at runtime. ThinApp uses VBScript to run script files. For information about VBScript, see the Microsoft VBScript documentation. You can use VBScript to access COM controls registered on the host system or within the virtual package. This information includes the following topics:  “Callback Functions” on page 115  “Implement Scripts in a ThinApp Environment” on page 116  “API Functions” on page 119 Callback Functions Callback functions can run under certain conditions. For example, callback functions run script code only when an application starts or quits. Callback function names include the following names:  OnFirstSandboxOwner – Called only when an application first locks the sandbox. This callback is not called if a second copy of the same application uses the same sandbox while the first copy runs. If the first application spawns a subprocess and quits, the second subprocess locks the sandbox and prevents this callback from running until all subprocesses quit and the application runs again.  OnFirstParentStart – Called before running a ThinApp executable file regardless of whether the sandbox is simutaneously owned by another captured executable file.  OnFirstParentExit – Called when the first parent process exits. If a parent process runs a child process and quits, this callback is called even if the child process continues to run.  OnLastProcessExit – Called when the last process owning the sandbox exits. If a parent process runs a child process and quits, this callback is called when the last child process exits. VMware, Inc.
Page 116: Implement Scripts In A Thinapp Environment
The following script runs an external .bat file from a network share inside the virtual environment. The .bat file makes modifications to the virtual environment by copying files, deleting files, or applying registry changes using regedit /s regfile.reg. Run this script only for the first parent process. If you run this script for other processes, each copy of the cmd.exe utility runs the script and an infinite recursion develops. Function OnFirstParentStart Set Shell = CreateObject("Wscript.Shell") Shell.Run "\\jcdesk2\test\test.bat" End Function Timeout Example The following script prevents the use of an application after a specified date. The VBS date uses the #mm/dd/yyyy# format, regardless of locale. This check occurs upon startup of the parent process and any child processes. if Date >= #03/20/2007# then msgbox "This application has expired, please contact Administrator" ExitProcess 0 end if VMware, Inc.
Page 117: Modify The Virtual Registry
ExecuteVirtualProcess "regedit /s C:\tmp\somereg.reg" End Function Stopping a Service Example The following script stops a virtual or native service when the main application quits. Function OnFirstParentExit Set WshShell = CreateObject("WScript.Shell") WshShell.Run "net stop ""iPod Service""" End Function Copying a File Example The following script sections shows how to copy a configuration file located in the same directory as the captured executable file into the virtual file system each time the application starts. This script is useful for an external configuration file that is easy to edit after deployment. Because the copy operation occurs each time you run the application, any changes to the external version are reflected in the virtual version. For example, if your captured executable file is running from \\server\share\myapp.exe, this script searches for a configuration file located at \\server\share\config.ini and copies it to the virtual file system location at C:\Program Files\my application\config.ini. By putting this code in the OnFirstParentStart function, it is only called once each time the script runs. Otherwise it runs for every child process. Function OnFirstParentStart VMware, Inc.
Page 118: Add A Value To The System Registry
/s command. RegFileName = ExpandPath("%Personal%\thin.reg") Set fso = CreateObject("Scripting.filesystemObject") Set RegFile = fso.CreateTextFile(RegFileName, true) The %Personal% directory is a directory that has Merged isolation mode by default. Construct the .reg file. RegFile.WriteLine("Windows Registry Editor Version 5.00") RegFile.WriteBlankLines(1) RegFile.WriteLine("[HKEY_CURRENT_USER\Software\Thinapp\demo]") RegFile.WriteLine(chr(34) and "InventoryName" and chr(34) and "=" and chr(34) and GetBuildOption("InventoryName") and chr(34)) RegFile.Close VMware, Inc.
Page 119: Api Functions
AddForcedVirtualLoadPath The AddForcedVirtualLoadPath(Path) function instructs ThinApp to load all DLLs from the specified path as virtual DLLs even if they are not located in the package. Use this function if the application needs to load external DLLs that depend on DLLs located inside the package. You can use the ForcedVirtualLoadPaths parameter in the Package.ini file to achieve the same result as this API function. See “ForcedVirtualLoadPaths” on page 75. Parameters Path [in] The filename or path for DLLs to load as virtual. Examples You can load any DLL located in the same directory as the executable file as a virtual DLL. Origin = GetEnvironmentVariable("TS_ORIGIN") TS_ORIGIN is the path from which the executable file is running. You can delete the filename from TS_ORIGIN by finding the last backslash and removing all of the characters that follow it. LastSlash = InStrRev(Origin, "\") SourcePath = Left(Origin, LastSlash) You can instruct ThinApp to load all DLLs in the same or lower directory from where the source executable file resides. AddForcedVirtualLoadPath(SourcePath) This process enables you to drop additional files in the SourcePath tree and have them resolve import operations against virtual DLLs. ExitProcess The ExitProcessExitCode function quits the current process and sets the specified error code. Parameters ExitCode [in] The error code to set. This information might be available to a parent process. A value of 0 indicates no error. VMware, Inc.
Page 120: Expandpath
Returns The expanded macro path in system format. Examples Path = ExpandPath("%ProgramFilesDir%\Myapp.exe") Path = C:\Program Files\myapp.exe All macro paths must escape the % and # characters by replacing these characters with #25 and #23. Path = ExpandPath("%ProgramFilesDir%\FilenameWithPercent#25.exe") This expands to C:\Program Files\FileNameWithPercent%.exe. ExecuteExternalProcess The ExecuteExternalProcess(CommandLine) function runs a command outside of the virtual environment. You can use this function to make physical system changes. Parameters CommandLine [in] Representation of the application and command‐line parameters to run outside of the virtual environment. Returns Integer process ID. You can use the process ID with the WaitForProcess function. See “WaitForProcess” on page 125. Examples ExecuteExternalProcess("C:\WINDOWS\system32\cmd.exe /c copy C:\systemfile.txt C:\newsystemfile.txt") You can run a command that requires quotation marks in the command line. ExecuteExternalProcess("regsvr32 /s " & chr(34) & "C:\Program Files\my.ocx" & chr(34)) VMware, Inc.
Page 121: Executevirtualprocess
ExecuteVirtualProcess("regsvr32 /s " & chr(34) & "C:\Program Files\my.ocx" & chr(34)) GetBuildOption The GetBuildOption(OptionName) function returns the value of a setting specified in the [BuildOptions] section of the Package.ini file used for capturing applications. Parameters OptionName [in] Name of the setting. Returns This function returns a string value. If the requested option name does not exist, the function returns an empty string (ʺʺ). Examples Package.ini contains: [BuildOptions] CapturedUsingVersion=4.0.1-2866 The following line appears in a VBS file: Value = GetBuildOption("CapturedUsingVersion") GetFileVersionValue The GetFileVersionValue(Filename, Value) function returns version information value from files such as a specific DLL, OCX, or executable file. You can use this function to determine the internal version number of a DLL or retrieve DLL information about the copyright owner or a product name. Parameters Filename [in] The name of the filename whose version information is being retrieved. Value [in] The name of the value to retrieve from the version information section of the specified file. VMware, Inc.
Page 122: Getcommandline
MsgBox "This is Version 1.0!" End if GetCommandLine The GetCommandLine function accesses the command‐line parameters passed to the running program. Returns This function returns a string that represents the command‐line arguments passed to the current running program, including the original executable file. Examples MsgBox "The command line for this EXE was " + GetCommandLine GetCurrentProcessName The GetCurrentProcessName function accesses the full virtual path name of the current process. Returns This function returns a string that represents the full executable path name inside of the virtual environment. In most circumstances, this path is C:\Program Files\..., even if the package source runs from a network share. Examples MsgBox "Running EXE path is " + GetCurrentProcessName VMware, Inc.
Page 123: Getosversion
0 Windows NT 3.51 51 BUILD_NUMBER is the build number of the operating system. PLATFORM_ID assigns one of the following values:  Value = 1 for Windows Me, Windows 98, or Windows 95 (Windows 95 based OS)  Value = 2 for Windows Server 2003, Windows XP, Windows 2000, or Windows NT. (Windows NT based OS) OS_STRING represents information about the operating system such as Service Pack 2. Examples if GetOSVersion() = "5.1.0.2 Service Pack 2" then MsgBox "You are running on Windows XP Service Pack 2!" endif VMware, Inc.
Page 124: Getenvironmentvariable
MsgBbox "The package source EXE is " + GetEnvironmentVariable("TS_ORIGIN") RemoveSandboxOnExit The RemoveSandboxOnExit(YesNo) function set toggles that determine whether to delete the sandbox when the last child process exits. If you set the RemoveSandboxOnExit parameter to 1 in the Package.ini file, the default cleanup behavior for the package with is Yes. You can change the cleanup behavior to No by calling RemoveSandboxOnExit with the value of 0. If you do not modify the RemoveSandboxOnExit=1 entry in the Package.ini file, the default cleanup behavior for the package is No. You can change the cleanup behavior to Yes by calling RemoveSandboxOnExit with the value of 1. Parameters Yes No [in] Do you want to clean up when the last process shuts down? 1=Yes, 0=No Examples The following example turns on cleanup. RemoveSandboxOnExit 1 The following example turns off cleanup. RemoveSandboxOnExit 0 SetEnvironmentVariable The SetEnvironmentVariable(Name, Value) function set the value of an environment variable. Parameters Name [in] The name of the environment variable to store the value. Value [in] The value to store. Examples SetEnvironmentVariable "PATH", "C:\Windows\system32" VMware, Inc.
Page 125: Setfilesystemisolation
1 = WriteCopy 2 = Merged 3 = Full Examples You can set the Merged isolation mode for the temp directory. Setfile systemIsolation GetEnvironmentVariable("TEMP"), 2 SetRegistryIsolation The SetRegistryIsolation(RegistryKey, IsolationMode) function sets the isolation mode of a registry key. Parameters RegistryKey [in] The registry key on which to set the isolation mode. Start with HKLM for HKEY_LOCAL_MACHINE, HKCU for HKEY_CURRENT_USER, and HKCR for HKEY_CLASSES_ROOT. IsolationMode [in] Isolation mode to set. 1 = WriteCopy 2 = Merged 3 = Full Examples You can set the Full isolation mode for HKEY_CURRENT_USER\Software\Thinapp\Test. SetRegistryIsolation "HKCU\Software\Thinapp\Test," 3 WaitForProcess The WaitForProcess(ProcessID, TimeOutInMilliSeconds) function waits until the process ID is finished running. Parameters ProcessID [in] The process ID to end. The process ID can come from ExecuteExternalProcess or ExecuteVirtualProcess. TimeOutInMilliSeconds [in] The maximum amount of time to wait for the process to finish running before continuing. A value of 0 specifies INFINITE. VMware, Inc.
Page 126 ThinApp User’s Guide Returns This function returns an integer. 0 = Timeout fails 1 = Process exits 2 = Process does not exist or security is denied Examples id = ExecuteExternalProcess("C:WINDOWS\system32\cmd.exe") WaitForProcess(id, 0) VMware, Inc.
Page 127: Monitoring And Troubleshooting Thinapp
 Step‐by‐step reproduction of the procedure that you performed when you encountered the problem.  Information on the host configuration. Specify the Windows operating system, the use of Terminal Server or Citrix Xenapp, and any prerequisite programs that you installed on the native machine.  Copies of the Log Monitor trace files. See “Log Monitor Operations” on page 127.  Exact copy of the capture folder and all content. Do not include the compiled executable files from the /bin subfolder.  Description of the expected and accurate behavior of the application.  (Optional) Copies of the applications that you captured. Include the server components configuration for Oracle Server or Active Directory.  (Optional) Native or physical files or registry key settings that might be relevant to the problem.  (Optional) System services or required device drivers.  (Optional) Virtual machine that reproduces the defect. VMware support might request this if the support contact is unable to reproduce the problem.  (Optional) One or more WebEx sessions to facilitate debugging in your environment. Log Monitor Operations Log Monitor captures detailed chronological activity for executable files that the captured application starts. Log Monitor intercepts and logs names, addresses, parameters, and return values for each function call by target executable files or DLLs. Log Monitor captures the following activity:  Win32 API calls from applications running in the ThinApp virtual operating system.  Potential errors, exceptions, and security events within the application.  All DLLs loaded by the application and address ranges. VMware, Inc.
Page 128: Troubleshoot Activity With Log Monitor
ThinApp User’s Guide The generated log files can be large and over 100MB depending on how long the application runs with Log Monitor and how busy an application is. The only reason to run Log Monitor for an application is to capture trace files. Trace files are critical for troubleshooting problems by analyzing and correlating multiple entries within the trace file. Troubleshoot Activity with Log Monitor You can use Log Monitor to perform basic troubleshooting. Troubleshoot ThinApp logs Shut down the captured application to investigate. On the computer where you captured the application, select Start > Programs > VMware > ThinApp Log Monitor. To start Log Monitor on a deployment machine, copy the log_monitor.exe, logging.dll, and Setup Capture.exe files from C:\Program Files\VMware\VMware ThinApp to the deployment machine and double‐click the log_monitor.exe file. Start the captured application. As the application starts, a new entry appears in the Log Monitor list. Log Monitor shows one entry for each new trace file. Each file does not necessarily correspond with a single process. End the application as soon as it encounters an error. Generate logs for each trace file you want to investigate. Select the .trace file in the list. Click Generate text trace report. Child processes that the parent process generates reside in the same log. Multiple independent processes do not reside in the same log. ThinApp generates a .trace file. Log Monitor converts the binary .trace file into a .txt file. (Optional) Open the .txt file with a text editor and scan the information. In some circumstances, the .txt file is too large to open with the text editor. Zip the .txt files and send the files to VMware support. Perform Advanced Log Monitor Operations Advanced operations in Log Monitor include stopping applications or deleting trace files. If an application is ...
Page 129 Click Generate text trace report to create a report. You can view the file with a text editor that supports UNIX‐style line breaks. Locating Errors ThinApp logging provides a large amount of information. The following tips might help advanced users investigate errors:  Review the Potential Errors Detected section of the .txt trace file. Entries might not indicate errors. ThinApp lists each Win32 API call where the Windows error code changed.  Review exceptions that the applications generate. Exceptions can indicate errors. Exception types include C++ and .NET. The trace file records the exception type and DLL that generates the exception. If the application, such as a .NET or Java application, creates an exception from self‐generating code, the trace file indicates an unknown module. The following example is a .trace entry for an exception. *** Exception EXCEPTION_ACCESS_VIOLATION on read of 0x10 from unknown_module:0x7c9105f8 If you find an exception, scan the earlier part of the trace file for the source of the exception. Ignore the floating point exceptions that Virtual Basic 6 applications generate during typical use.  Review child processes. Log Monitor produces one .trace file for each process. If an application starts several child processes, determine which process is causing the problem. Sometimes, such as in circumstances involving out‐of‐process COM, a parent application uses COM to start a child process, runs a function remotely, and continues to run functions.  When you run applications from a network share that generates two processes, ignore the first process. ThinApp addresses the slow performance of Symantec antivirus applications by restarting processes. VMware, Inc.
Page 130: Log Format
General API Log Message Format The following message shows a format example for API calls. 000257 0a88 mydll.dll :4ad0576d->kernel32.dll:7c81b1f0 SetConsoleMode (IN HANDLE hConsoleHandle=7h, IN DWORD dwMode=3h) 000258 0a88 mydll.dll :4ad0576d<-kernel32.dll:7c81b1f0 SetConsoleMode ->BOOL=1h () This example includes the following entries:  000257 indicates the log entry number. Each log entry has a unique number.  0a88 indicates the current running thread ID. If the application has one thread, this number does not change. If two or more threads record data to the log file, you might use the thread ID to follow thread‐specific sequential actions because ThinApp records log entries in the order in which they occur.  mydll.dll indicates the DLL that makes the API call.  4ad0576d indicates the return address for the API call that mydll.dll makes. In typical circumstances, the return address is the address in the code where the call originates.  -> indicates the process of entering the call. For the call entry log element, ThinApp displays the input parameters. These parameters are in and in/out parameters. VMware, Inc.
Page 131 ----Timing Report: list of slowest 150 objects profiled --- 8255572220 total cycles (2955.56 ms): |sprof| thinapp_LoadLibrary2 765380728 cycles (274.01 ms) on log entry 21753 428701805 cycles (153.48 ms) on log entry 191955 410404281 cycles (146.93 ms) on log entry 193969 VMware, Inc.
Page 132 019530 0000075c MSVCR80.dll :78131dcd<-dbghelp.dll :59a603a1 *** GetModuleHandleA ->HMODULE=0h () *** GetLastError() returns 126 [0]: The specified module could not be found. Troubleshooting Example for cmd.exe Utility In the troubleshooting example, ThinApp packages the cmd.exe utility with logging turned on. The example shows how you can simulate application failure by running an invalid command. If you request the cmd.exe utility to run the foobar command, the utility generates the foobar is not recognized as an internal or external command message. You can scan the trace file and check the Potential Errors Detected section to find the API functions that modified the GetLastError code. The example shows the C:\test\cmd_test\bin\foobar.*, C:\WINDOWS\system32\foobar.*, and C:\WINDOWS\foobar paths as the locations where the cmd.exe utility looks for the foobar command. VMware, Inc.
Page 133 001538 0a88 cmd.exe :4ad01b24<-IMM32.DLL :7639039b GetFullPathNameW ->DWORD=14h (OUT LPWSTR lpBuffer=*163D60h->L"C:\test\cmd_test\bin," OUT *lpFilePart=*13D8D4h ->*163D82h->L"bin") 001549 0a88 cmd.exe :4ad01b5f->USERENV.dll :769c03fa FindFirstFileW (IN LPCWSTR lpFileName=*1638C0h->L"C:\test\cmd_test\bin\foobar.*") 001550 0a88 FindFirstFileW ’C:\test\cmd_test\bin\foobar.*’ -> INVALID_HANDLE_VALUE *** failed [system probe C:\test\cmd_test\bin\foobar.* -> ffffffffh][no virtual or system matches] VMware, Inc.
Page 134: Troubleshooting Specific Applications
%AppData%\Microsoft\Outlook %Local AppData%\Microsoft\FORMS %Local AppData%\Microsoft\Outlook (Optional) If the subdirectories do not exist, create the directories. Viewing Attachments in Microsoft Outlook Microsoft Outlook creates a default directory to store attachments when you open an attachment for viewing. The typical location is C:\Documents and Settings\<user_name>\Local Settings\Temp\Temporary Internet Files\OLK<xxxx>. The last xxxx is replaced by a random entry. You can view attachments when the viewing application runs in the same virtual sandbox as Microsoft Outlook. External applications might not be able to find the file to display because Microsoft Outlook stores the file in the sandbox. You must use the Merged isolation mode for the directory that stores the attachments. Set up Merged isolation mode to view Microsoft Outlook attachments Add a value to the HKEY_CURRENT_USER.txt file that sets the name of the attachment directory: isolation_full HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Security Value=OutlookSecureTempFolder REG_SZ~%Profile%\Local Settings\OutlookTempxxxx#2300 In this example, 11.0 in the key name is for Microsoft Outlook 2003. VMware, Inc.
Page 135: Starting Explorer.exe In The Virtual Environment
CommandLine=%ProgramFilesDir%\Internet Explorer\iexplore.exe -E  Add the following virtual registry key: isolation_full HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer Value=DesktopProcess REG_DWORD=#01#00#00#00  Add the following entries to the Package.ini file: [explorer.exe] Shortcut=xxxxxx.exe Source=%SystemROOT%\explorer.exe Use this method to browse the virtual file system with a familiar interface and enable accurate file type associations without system changes, especially when using portable applications. You can access shell‐integrated components without system changes. Troubleshooting Java Runtime Environment Version Conflict A conflict might occur if one version of Java is installed on the physical system and another version is included in a captured executable file. Updated versions of Java install a plug‐in DLL that Internet Explorer loads. This plug‐in DLL overwrites virtual registry keys and conflicts with a virtualized copy of older Java runtimes. Prevent Internet Explorer from loading plug-in DLLs Add the following entry to the beginning of the HKEY_LOCAL_MACHINE.txt file. isolation_full HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects VMware, Inc.
Page 136 ThinApp User’s Guide VMware, Inc.
Page 137: Glossary
Glossary Application Link A utility that links dependent applications to a base application at runtime and starts all the applications together when you start the base application. You can use the utility to deploy and update component packages separately rather than capture all components in the same package. Application Sync A utility that updates an application by detecting a new packaged version on a server or network share. You can configure update settings, such as the checking of an update server at certain intervals. ThinApp detects the most recent application executable file and downloads the differences. attributes.ini The file that applies configuration settings at the directory level of the package rather than the entire package. The ##Attributes.ini settings override the overall Package.ini settings. build To convert a ThinApp project into a package. You can build a package with the Setup Capture wizard or with the build.bat utility. capture To package an application into a virtual environment and set initial application parameters. ThinApp provides the Setup Capture wizard or the snapshot.exe utility to create a portable application package that is independent of the operating system it runs on. clean machine The computer or virtual machine, installed with only the basic Windows operating system, on which you capture the application. The Windows operating system version must be the earliest version of Windows that you expect the application to run on. entry point An executable file that starts the captured application. An application might have multiple entry points. For example, the Firefox.exe file might serve as an entry point for a Mozilla Firefox application. The primary data container file can exist within an entry point or as a .dat file. inventory name A name that ThinApp uses for internal tracking of the application. The inventory name sets the default project directory name and appears in the Add or Remove Programs dialog box for Windows. isolation mode A package setting that determines the read and write access to the physical environment. ThinApp has WriteCopy, Merged, and Full isolation modes. VMware, Inc.
Page 138 Log Monitor A utility that captures chronological activity for executable files that the captured application starts.The log_monitor.exe file is compatible only with applications captured using the same version of ThinApp. A Windows Installer container that is useful for application deployment tools. You can deliver the captured application as an MSI file instead of an executable file. native Refers to the physical environment rather than the virtual environment. See also physical. network streaming The process of running a package from a central server. ThinApp downloads blocks of the application as needed to ensure quick processing and display. package The virtual application files that the ThinApp build process generates. The package includes the primary data container file and entry point files to access the application. package.ini The file that applies configuration settings to the package and that resides in the captured application folder. The Setup Capture wizard sets the initial values of the configuration settings. physical Refers to the computer memory and file system in which all standard Windows processes run. Depending on ThinApp isolation mode settings, processes in the virtual environment can access the physical environment. See also native, virtual. postscan To establish an image or snapshot of a machine after you install the application you want to capture. The capture process stores in a virtual file system and virtual registry the differences between the prescan and postscan images. See also prescan, snapshot. prescan To establish a baseline image or snapshot of a machine before you install the application you want to capture. The capture process stores in a virtual file system and virtual registry the differences between the prescan and postscan images. See also postscan, snapshot. primary data container The main virtual application file. The file is a .exe file or a .dat file that includes the ThinApp runtime and the read‐only virtual file system and virtual registry. The primary data container must reside in the same /bin directory with any subordinate application executable files because entry points use the information in the primary data container. project The data that the capture process creates before you build a package. The capture process uses the inventory name as the default project directory name. You can customize parameters in the project files before you build an application package. You cannot deploy a captured application until you build a package from the project. VMware, Inc.
Page 139 A utility that makes incremental updates to applications, such as the incorporation of a plug‐in or a change in a browser home page. The sbmerge.exe utility merges runtime changes recorded in the sandbox back into a ThinApp project. snapshot A recording of the state of the Windows file system and registry during the application capture process. The Setup Capture process uses the snapshot.exe utility to take a snapshot before and after the application is installed and stores the differences in a virtual file system and virtual registry. See also postscan, prescan. snapshot.exe A utility that creates the snapshots of a computer file system and registry and facilitates the prescan and postscan operations during the capture process. Only advanced users who build ThinApp functionality into other platforms might make direct use of this utility. See also postscan, prescan, snapshot. snapshot.ini A configuration file that specifies the directories and subkeys to exclude from a ThinApp project when you capture an application. You can customize this file for applications. template.msi A template for MSI files that you can customize to adhere to company deployment procedures and standards. For example, you can add registry settings for ThinApp to add to client computers as part of the installation. thinreg.exe A utility that establishes file type associations, sets up Start menu and desktop shortcuts, and facilitates the opening of files. You must run the thinreg.exe utility to register executable files. MSI files automate the thinreg.exe registration process. tlink.exe A utility that links key modules during the build process. vftool.exe A utility that compiles the virtual file system during the build process. virtual Refers to the logical file and memory within which a captured application runs. Processes in a physical environment cannot access the virtual environment. See also physical. virtual application An application that you capture to make it portable and independent of the operating system it runs on. virtual file system The file system as the captured application sees it. virtual registry The registry as the captured application sees it. vregtool.exe A utility that compiles the virtual registry during the build process. VMware, Inc.
Page 140 ThinApp User’s Guide VMware, Inc.
Page 141: Index
129 setting up nested links 58 computers storing multiple versions of linked defining a clean system 12 applications 60 using virtual machines for clean systems 13 view of 57 cut and paste operations, ThinApp limitations 49 VMware, Inc.
Page 142 WriteCopy 19 AppSyncExpireMessage 94 AppSyncExpirePeriod 94 AppSyncUpdateFrequency 94 log format 130 AppSyncUpdateMessage 95 Log Monitor AppSyncURL 94 extra options 128 AppSyncWarningFrequency 95 suspending and resuming logging 128 AppSyncWarningMessage 95 troubleshooting procedures 128 AppSyncWarningPeriod 95 using 127 AutoShutdownServices 82 VMware, Inc.
Page 143 MSIDefaultInstallAllUsers 96 package level 24 MSIFilename 97 for Application Link 91 MSIInstallDirectory 97 for Application Sync 93 MSIManufacturer 97 for build output 70 MSIProductCode 98 for file and block sizes 83 VMware, Inc.
Page 144 39 location 20, 105 directory files 13 parameters 100 folder macros 111 search order 103 in a VMware View environment 39 structure 106 installing 13 sbmerge.exe recommendation for clean computers 12 commands 62 requirements for installing and capturing...
Page 145 111 ThinDirect representing path locations with macros 111 extracting and registering 29 using 111 thinreg.exe VMware View, using captured applications 39 defining 40 vregtool, listing virtual registry contents 106 parameters 41 running 41 starting with MSI files 21...
Page 146 ThinApp User’s Guide VMware, Inc.

VMware THINAPP 4.6 Manual

1 Installing Thinapp

2 Capturing Applications

3 Deploying Applications

4 Updating and Linking Applications

5 Configuring Package Parameters

6 Locating the Thinapp Sandbox

7 Creating Thinapp Snapshots and Projects from the Command Line

8 Thinapp File System Formats and Macros

9 Creating Thinapp Scripts

10 Monitoring and Troubleshooting Thinapp

Quick Links

Troubleshooting

Related Manuals for VMware THINAPP 4.6

Summary of Contents for VMware THINAPP 4.6

Table of Contents