User manual VMWARE THINAPP 4.6

[. . . ] 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 ThinApp User's Guide You can find the most up-to-date technical documentation on the VMware Web site at: http://www. vmware. com/support/ The VMware Web site also provides the latest product updates. If you have comments about this documentation, submit your feedback to: docfeedback@vmware. com Copyright © 2010 VMware, Inc. VMware products are covered by one or more patents listed at http://www. vmware. com/go/patents. [. . . ] For example, the [Adobe Reader 8. exe] section of the Package. ini file for an Adobe Reader application might have settings that override the larger [BuildOptions] parameters. The applicationspecific parameters show the application entry points that you create during the build process. The [FileList], [Compression], and [Isolation] parameters act as [BuildOptions] parameters, but are grouped separately for backward compatibility reasons. You can add the [FileList] heading manually to the file when you add the ExcludePattern parameter. Parameters that do not apply to the standard sections can reside under any heading. 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. 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. 66 VMware, Inc. 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 EndUser License Agreement display for the package. This parameter addresses legacy EndUser License Agreement requirements. Do not modify the value of this parameter. Examples The RuntimeEULA parameter prevents the display of the EndUser 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> If you rename a clean machine as LOCALHOST before performing the capture process, the Package. ini file activates the VirtualComputerName entry. The virtual application works with this LOCALHOST name because any computer that the application runs on gets this value as the computer name. VirtualComputerName=LOCALHOST If you type a GetComputerName or GetComputerNameEx command, the machine returns LOCALHOST. [. . . ] 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. [. . . ]