HKCU Windows RUN "\\emerald\thinstallvs\Setup Capture.exe" "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ {3B706083-4BDC-4597-B72A-0ABBF3458F05}.snapshot" 11.5mb - 12mb %AppData% %Common Programs% - all users\start menu\programs %Desktop% %drive_c% - Files that have changed on the drive %NetHood% %Personal% %Profile% %ProgramFilesDir% %SystemRoot% %SystemSystem% set THINSTALL_BIN=%CD% %COMSPEC% /k captures\%x%\build.bat cd captures\%x%\bin Running build.bat creates a directory named "bin" Changing the hard drive to 'Independent-Nonpersistent' causes all changes to the virtual machine's hard drive go to a separate temporary virtual disk file. When the machine is powered off the file is discarded. The benefit of this is the ability to always return to a clean machine state by simply power cycling the machine. Additionally you power off the virtual machine, rather than wait for shutting down, without triggering a disk scan (or corruption) on the next boot. Adjust the virtual machine to suit your environment. You may need to change some setting to fit your work place environment, such as network connection settings. Remember to keep the virtual machine in 'Independent-Nonpersistent' mode until you know the changes you are make work. Then Power down the machine, remove the 'Independent-Nonpersistent' mode, Power up, make the changes, Shut down the machine, and return to 'Independent- Nonpersistent'. This technique will minimize the impact of using the machine while not in 'Independent-Nonpersistent' mode. Remember to use Start > Log Off, (not Power off) while not in 'Independent-Nonpersistent' mode, since this may trigger a disk scan upon the next boot. Thinstall We recommend using a clean PC to capture application installs because installers which skip files that already exist on the PC. If the installer skips files, they will not be included in the Thinstall project and the application may fail to run on other PCs where the files do not exist. What is a clean PC? A clean PC is a PC which has Windows base OS installed and nothing else. In a corporate environment where you have a base desktop image, the base desktop image is your "clean" PC. In such cases the back desktop PC may already have some components and libraries installed (for example .NET 2.0). When you capture a package on a PC which has .NET 2.0 already installed, .NET 2.0 will not be included in your package and the application will then only run on PCs which have .NET 2.0 already installed. What version of Windows should I use for capturing? We recommend capturing on the lowest platform you plan to support for your users. In most cases this will be WIndows 2000 or Windows XP. Most packages captured on XP will work on 2k, however in some cases Windows XP comes with some DLLs which Windows 2k does not have and they will be excluded from the package if the application normally installs these DLLs. File locks are maintained on running thinstall applications thus the EXE file cannot be deleted until all users have closed their running instance. Thinstall will run the highest level application name in a sharepoint such as myapp.exe will run myapp.1 if it is present, or myapp2 if it is present (the documentation does not show .EXE at the end of the filename). Do not delete myapp.exe while in production hours because user shortcuts point to this file. The directory where the application is located should be write protected due to some applications self updating by dropping a new version of itself in the working directory. Sandbox considerations When you release an upgrade to an application, you can control weither the user continues to use their old settings by keeping the sandbox name consistent in your package.ini file. By deploying a new application version with a new sandbox name, each user will create a seperate sandbox and start with a fresh install maintaining isolatied settings. By deploying with the same sandbox name, user's will keep their old settings. Isolation Modes The following Isolation modes can be applied to subdirectories and registry subkeys. WriteCopy - System elements at this location will be visible to application If a system element and virtual element exist at the same location, the application will see the virtual element. - modifications to virtual elements go to sandbox - modifications to system elements go to sandbox - New elements will be created in the sandbox Merged - System elements at this location will be visible to application If a system element and virtual element exist at the same location, the application will see the virtual element. - modifications to virtual elements go to sandbox - modifications to system elements go to system - New elements will be created on the system Full - System elements at this location will not be visible to application - modifications to virtual elements go to sand box - system elements cannot be read or modified - New elements will be created in the sandbox Thinstall has 3 different isolation modes, which are automatically determined by SetupCapture. SetupCapture has a few simple rules for determining what isolation mode to apply to a registry subtree or directory during capture. - If the application created a new directory or registry subtree during it's install (on a clean PC), the isolation mode is set to Full Isolation - All other directories and subkeys will default to WriteCopy Isolation - User-specific storage areas like the Desktop and My Documents, are set to Merged Isolation so the application has direct write access to these locations Note: Network shares are not affected by isolation modes, read and write operations to network shares occur unchanged by Thinstall. The name of a sandbox (SANDBOXNAME) is specified in the package.ini file prior to build. Default Location of Sandbox If a local sandbox could not be found as described above, Thinstall will place the sandbox in the user's Application Data folder under a directory called Thinstall. i.e. c:\documents and settings\USERNAME\application data\Thinstall\SANDBOXNAME If the user's Application Data folder is stored on a network share, the application's setting will automatically migrate when the same user logs in on another machine. Local Sandboxes (Running from USB Flash) When the location of the sandbox is the same directory as the application EXE, we call this a "local" sandbox. Local sandboxes allow user settings to be loaded and saved an external storage such as USB Flash without regard to which user is currently logged onto the computer. You can control the location of the sandbox by using environment variables, if you do not specify environment variables Thinstall will search for the sandbox using the following rules: 1. Look in EXE's directory for a directory called SANDBOXNAME. This is useful if you want to run an application from Flash or external media but you have multiple Thinstall packages in the same directory and you want some to use a local sandbox. 2. Look in the EXE's directory for a directory called "Thinstall". In this case, the sandbox will be loaded/saved to Thinstall\SANDBOXNAME. This is useful if you want to force all Thinstall packages in a specific directory to be local. Controlling location with Environment Variables You can control the location for a specific Thinstall package or for all Thinstall packages. For specific apps, the location can be controlled by setting the environment variable: SBNAME_SANDBOX_DIR=c:\somepath where SBNAME is the value specified as the applications's SANDBOXNAME in the package.ini file To control the location of the sandbox for all Thinstall applications, the following format is used: THINSTALL_SANDBOX_DIR=c:\somepath