General:
Links:
Build Templates:


Create Temp Folder with "WriteCopy" IsolationMode... %Temp%\##Attributes.ini [Isolation] DirectoryIsolationMode=WriteCopy The sandbox is kept in the following location: %appdata%\Thinstall\$SandboxName$ -or- in the working directory of the package (USB mode): [BuildOptions] SandboxPath=. -------------------------------------------------------------------------------- Thinapp Sandbox Navigation IF IE: File|Open|Browse Navigate To Sandbox, Choose: Command Window Here c:\path\to\sandbox> explorer . # works! c:\path\to\sandbox> start . # does not work -------------------------------------------------------------------------------- The ##Attributes.ini file applies settings at the directory level while the Package.ini file applies settings at the overall application level. The Package.ini setting determines the isolation mode only when ThinApp does not have ##Attributes.ini information. If you need to compress only certain folders with large files rather than an entire application, you can compress files at the folder level with the CompressionType parameter in the ##Attributes.ini file. Compression Mode Stanzas in ##Attributes.ini: [Compression] CompressionType=None CompressionType=Fast Isolation Mode Stanzas in ##Attributes.ini: [Isolation] DirectoryIsolationMode=Full #read and write only sandbox data DirectoryIsolationMode=WriteCopy #read from filesystem and sandbox, write only in sandbox DirectoryIsolationMode=Merged #read and write normal filesystem Merged Allows the application to read resources on and write to the local machine. The advantage of using Merged isolation mode is that documents saved by users end up on the physical system in the location expected by users, instead of in the sandbox. The disadvantage is that this mode might clutter the system image. An example of residue might be first-execution markers by shareware applications written to random computer locations as part of the licensing process. WriteCopy Allow the application to read resources on the local machine and restrict most modifications to the sandbox. For directories and subkeys that have WriteCopy isolation, the application recognizes both the host computer files and virtual files. All write operations convert host computer files into virtual files in the sandbox. Full For directories and subkeys that have full isolation, the applications only see virtual files and subkeys. You can use this third isolation mode from outside the wizard in the project text files. The Full isolation mode secures the virtual bubble by blocking visibility to system elements outside the virtual application package. This mode restricts generated data to the sandbox and ensures no interaction exists with the environment outside the virtual application package. -------------------------------------------------------------------------------- Select the isolation mode to determine which files and registry keys are visible and written by the virtual application you create: • To allow the application to read resources on and write to the local machine, keep the default Merged isolation mode. This means that the application can modify elements outside of the virtual application package. Some applications rely on DLLs and registry information in the local system image. VMware recommends this mode for applications that do not write to system directories, such as Firefox. ThinApp directs write operations to the physical file system, with the exception of the following directories and their subdirectories that redirect write operations to the sandbox: • %AppData% • %Common AppData% • %Local AppData% • %Program Files Common% • %ProgramFilesDir% • %SystemRoot% • %SystemSystem% The advantage of using Merged isolation mode is that documents saved by users end up on the physical system in the location expected by users, instead of in the sandbox. The disadvantage is that this mode might clutter the system image. An example of residue might be first-execution markers by shareware applications written to random computer locations as part of the licensing process. • To allow the application to read resources on the local machine and restrict most modifications to the sandbox, select the WriteCopy isolation mode. ThinApp intercepts write operations to all directories and redirects them to the sandbox, with the exception of the following directories and their subdirectories that redirect write operations to the physical system: • %Desktop% • %Personal% • %SystemSystem%\Spool Regardless of the choice for Merged or WriteCopy isolation mode, ThinApp treats write operations to network drives according to the SandboxNetworkDrives parameter in the Package.ini file. This parameter has a default value of 0 that directs write operations to the physical drive. ThinApp treats write operations to removable disks according to the SandboxRemovableDrives parameter in the Package.ini. This parameter has a default value of 0 that directs write operations to the physical drive. VMware recommends this mode for legacy or untrusted applications. Although the WriteCopy mode might make it difficult to locate user data files that reside in the sandbox instead of the actual system, this mode is useful for locked down desktops where you want to prevent users from affecting the operating file system and registry files. Note Any modification to any virtual element in the captured application package is stored in the sandbox, regardless of the isolation mode setting. If you capture Microsoft Office and use group policies, isolation modes do not affect the application because group policies can apply registry changes only to the physical environment. Virtual and physical registry elements appear as one to the captured application. If virtual entries exist for the registry, the Merged isolation mode cannot affect the application because Microsoft Office resorts to the virtual entries instead of physical entries. If necessary, remove such virtual entries to ensure the application affects the physical system, regardless of the isolation mode. You can use a third isolation mode, Full, outside the wizard in the project text files. The Full isolation mode secures the virtual bubble by blocking visibility to system elements outside the virtual application package. This mode restricts generated data to the sandbox and ensures no interaction exists with the environment outside the virtual application package. ThinApp caches the isolation modes for the registry and the file system at runtime in the sandbox. If you change the isolation mode for the project and rebuild the executable file, you might need to delete the sandbox for the change to take effect. You can modify isolation modes in the Package.ini and ##Attributes.ini files. -------------------------------------------------------------------------------- Entry Points for Troubleshooting If you want to troubleshoot or debug your environment, you can select these entry points during the setup capture process: • cmd.exe – Starts a command prompt in a virtual context that allows you to view the virtual filesystem. • regedit.exe – Starts the registry editor in a virtual context that allows you to view the virtual registry. • iexplore.exe – Starts iexplore.exe in a virtual context that allows you to test virtualized ActiveX controls. Entry points start native executables in a virtual context. Entry points do not create virtual packages of cmd.exe, regedit.exe, or iexplore.exe. Applications that ThinApp Cannot Virtualize You must use traditional installation technologies to deploy the following types of applications: • Applications requiring installation of kernel-mode device drivers ODBC drivers work because they are user mode • Antivirus and personal firewalls • Scanner drivers and printer drivers • Some VPN clients Applications that require device drivers do not work when packaged with ThinApp. You must install those device drivers in their original format on the host computer. Because ThinApp does not support virtualized device drivers, you cannot use ThinApp to virtualize antivirus, VPN clients, personal firewalls, and disk and volume mounting-related utilities. -------------------------------------------------------------------------------- Java Runtime Environment (JRE) A conflict might occur if one version of Java is installed natively and another one is included in a captured executable. This is because newer versions of Java also install a plug-in DLL that gets loaded by IE. This plug-in DLL overwrites virtual registry keys when it is loaded and can conflict with a virtualized copy of older Java runtimes. You can prevent IE from loading plug-ins by adding the following line to beginning of HKEY_LOCAL_MACHINE.txt. isolation_full HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects -------------------------------------------------------------------------------- --------------------------------------------------------------------------------