AccessDeniedMsg: A message is displayed to the user if they're not entitled to use the package. This works hand-in-hand with PermittedGroups.

Example:

[BuildOptions]
AccessDeniedMsg=You do not have permission to use this application.

AddPageExecutePermission: The AddPageExecutePermission parameter allows legacy applications that don't support a DEP-protected environment, to execute on DEP-enabled operating systems such as Windows XP SP2 and the later versions.

Example:

[BuildOptions]
AddPageExecutionPermission=1 (default 0)

AllowExternalKernelModeServices: ThinApp runtime can start external kernel driver services as long as the file exists on the physical filesystem. The default setting is not to allow ThinApp runtime to launch these external services.

Example:

[BuildOptions]
AllowExternalKernelModeServices=1 (default=0)

AllowExternalProcessModifications: Using the AllowExternalProcessModifications parameter, you can allow the ThinApp runtime to create and run kernel driver services. The service executable file must exist on the physical filesystem.

Example:

[BuildOptions]
AllowExternalProcessModifications=1 (default 0)

AllowUnsupportedExternalChildPrThinApp runtime does not support running 64-bit child processes within the virtual environment. Therefore, ThinApp will by default execute 64-bit child processes outside of the virtualized environment. You can disable this with AllowUnsupportedExternalChildProcesses. When it's disabled, no 64-bit child processes will be able to run.

Example:

[BuildOptions]
AllowUnsupportedExternalChildProcesses=0 (default 1)

AnsiCodePage: This parameter gets its value from the capturing machine. It represents the language (in a numeric format) of your capturing machine. This parameter doesn't allow for language translations.

Example:

[BuildOptions]
AnsiCodePage=1252

AppSyncClearSandboxOnUpdate: AppSyncClearSandboxOnUpdate will delete the sandbox upon a successful AppSync update. The default behavior is to not delete the sandbox.

Example:

[BuildOptions]
AppSyncClearSandboxOnUpdate=1 (default=0)

AppSyncExpireMessage: A message is displayed to the user when a package has expired using the AppSyncExpirePeriod parameter.

Example:

[BuildOptions]
AppSyncExpireMessage=This application has been unable to contact its update server for %expire_days% day(s), so it is unavailable for use. Check your network connection and try again.

AppSyncExpirePeriod: AppSyncExpirePeriod specifies if the package should expire after a certain amount of days of not being able to contact the specified AppSyncURL.

Example:

[BuildOptions]
AppSyncExpirePeriod=30 (AppSyncExpirePeriod=never disables expiration of the Package)

AppSyncUpdatedMessage: A message is displayed to the user after a successful AppSync update.

Example:

[BuildOptions]
AppSyncUpdatedMessage=Your application have now been updated to the latest version.

AppSyncUpdateFrequency: The AppSyncUpdateFrequency parameter decides how often AppSync should check for an updated version of the package. Remember that AppSync will only happen when the package is in use.

Example:

[BuildOptions]
AppSyncUpdateFrequency=0 (AppSync will check for updates every time the Package is launched,default value is 1d)

AppSyncURL: The AppSyncURL parameter specifies the location of update packages, using the AppSync update feature. AppSyncURL supports three protocols—HTTP, HTTPS, and FILE.

Example:

[BuildOptions]
AppSyncURL=file://ServerName/ShareName/NewPackage.exe
or
AppSyncURL=http://www.myUpdates.com/Updates/NewPackage.exe

AppSyncWarningFrequency: This parameter specifies how often the AppSyncWarningFrequency value will be displayed, ahead of the expiration of the package.

Example:

[BuildOptions]
AppSyncWarningFrequency=1d

AppSyncWarningMessage : This parameter specifies the message displayed to the user before the package expires due to the AppSyncExpirePeriod parameter.

Example:

[BuildOptions]
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.

AppSyncWarningPeriod : The parameter specifies how many days ahead of package expiration the AppSyncWarningMessage string will start to be displayed. The frequency of the message is decided using the AppSyncWarningFrequency parameter.

Example:

[BuildOptions]
AppSyncWarningPeriod=5d

AutoShutdownServices : By default, ThinApp runtime will shutdown any services started within the virtual environment when the last non-service process is shutdown. You can disable this feature if you want to keep the services running.

Example:

[BuildOptions]
AutoShutdownServices=0 (default=1)

AutoStartServices : Normally, all virtualized services will start upon package launch. This may be quite time consuming, so you might want to consider disabling the auto-start of services.

Example:

[BuildOptions]
AutoStartServices=0 (default=1)

BlockSize : You can change the default block size used when compressing the package. The default block size is 64 KB. Valid block sizes are 128 KB, 256 KB, 512 KB, or 1 MB. You can change the block size for individual folders within your project by adding the BlockSize parameter to the folder's ##Attributes.ini file.

Example:

[Compression]
BlockSize=128k (k means KB and m means MB, e.g. 1m = 1MB)

CachePath : CachePath is the location of the ThinApp package cache. The cache location is where virtualized fonts will be copied to in the physical environment prior to activation. This parameter can be overridden with the help of the %THINSTALL_CACHE_DIR% environment variable.

Example:

[BuildOptions]
CachePath=C:\ThinAppCache (default is the user's local profile)

CapturedUsingVersion : CapturedUsingVersion indicates which version of ThinApp is used to capture the application. You should not delete the parameter.

Example:

[BuildOptions]
CapturedUsingVersion=4.7.1-677178

ChildProcessEnvironmentDefault : By default, all child processes will be loaded within the virtual environment. Sometimes, this slows down the load process and you might want to consider loading child processes externally. Most of the time, you only want to load certain processes externally. In those cases, use the ChildProcessEnvironmentExceptions parameter instead.

Example:

[BuildOptions]
ChildProcessEnvironmentDefault=External (default=virtual)

ChildProcessEnvironmentExceptions : ChildProcessEnvironmentExceptions are used to add exceptions to the ChildProcessEnvironmentDefault parameter. Often, you leave ChildProcessEnvironmentDefault as the default, loading child processes virtually, and add the specific processes you want to load externally as ChildProcessEnvironmentExceptions. We separate processes by using a semicolon.

Example:

[BuildOptions]
ChildProcessEnvironmentExceptions=WINWORD.EXE;EXCEL.EXE;POWERPNT.EXE;OUTLOOK.EXE;MOC.EXE

CommandLine : CommandLine is used to add hardcoded parameters to your entry point's source executable.

Example:

[Entry Point Section]
CommandLine="%ProgramFilesDir%\Mozilla Firefox\firefox.exe" -safe-mode

Comment : Comment is specified per entry point, and determines what will be displayed when the user hovers the mouse over a shortcut to the entry point. If nothing is specified, the path to the entry point is displayed.

Example:

[Entry Point Section]
Comment=This is your default browser

CompressionType : The CompressionType parameter specifies if you want to compress the package or not. Back in the Thinstall days it was not only compression on and off, we were also offered None, Fast and Small compression. No one really used the Small algorithm so when VMware acquired Thinstall, they got rid of the Small option. By default, only files other than executables and dlls are compressed. You can change this behavior by using the OptimizedFor parameter. You can add CompressionType to a project folder's ##Attributes.ini file to compress only that folder.

Example:

[Compression]
CompressionType=Fast (default=None)

DirectoryIsolationMode : DirectoryIsolationMode specifies the default filesystem's isolation mode. The default isolation mode will be used if no isolation mode has been specified on a location. Valid parameters are WriteCopy or Merged. You should not use Full as your default directory isolation mode because you would probably hide too much of the native system from the package.

Example:

[Isolation]
DirectoryIsolationMode=WriteCopy

DisableCutPaste: Using this parameter will disable the ability to copy/cut and paste information out from the package.

Example:

[BuildOptions]
DisableCutPaste=1 (default=0)

DisableCutPasteMsg: This parameter specifies the text that will be pasted instead of the original data when using DisableCutPaste=1.

Example:

[BuildOptions]
DisableCutPasteMsg=Administrator has disabled Cut and Paste for application %ls

Disabled: This parameter is used to specify if an entry point should be created or not.

Example:

[Entry Point Section]
Disabled=1 (0 will create the Entry Point)

DisablePrinting: By using this parameter you can disable printing from a package. The end result, that the user can't print, is very similar to using the HidePrinters parameter.

Example:

[BuildOptions]
DisablePrinting=1 (default=0)

DisableRegistryTransaction: With ThinApp Version 4.5, the way the ThinApp runtime stores the virtual registry within the sandbox was changed. In Version 4.5, the registry is stored using a transactional log. This should make the sandbox more robust and less likely to become corrupted. The legacy method uses a flat file with a backup file containing the last known good version. At times you can have a performance issue when using the new format, especially when storing the sandbox on a network share. If this is the case, try using the legacy method instead. I don't recommend that you change this setting on all of your packages; it's something you should decide on a package-by-package basis.

Example:

[BuildOptions]
DisableRegistryTransaction=1 (default=0)

DisableTracing: This parameter will disable the possibility of using the Log Monitor to debug the execution of the package.

Example:

[BuildOptions]
DisableTracing=1 (default 0)

ExcludePattern: ExcludePattern will allow you to exclude certain files and folders from being compiled into the package. This way you can keep the installer cache within your project folder, but keep them from bloating your packages. Please note that ExcludePattern uses its own Package.ini section called [FileList]. You can add the parameter into ##Attributes.ini files as well. This way, the exclusion will only be active on that specific folder.

Example:

[FileList]
ExcludePattern=\.cab,\.msi

ExternalCOMObjects: By default, ThinApp will keep virtualized COM objects virtual. If you suspect that an application implements COM objects that are incompatible with ThinApp runtime, you can have them load externally, outside of the virtualized environment. This is quite rare, and more or less only implemented when you have an issue and you're told by VMware support to use this feature. The parameter uses the CLSID keys.

Example:

[BuildOptions]
ExternalCOMObjects={8BC3F05E-D86B-11D0-A075-00C04FB68820};{7D096C5F-AC08-4F1F-BEB7-5C22C517CE39}

ExternalDLLs: Using the ExternalDLLs parameter, you can specify virtualized DLLs that should be loaded by the system rather than the ThinApp runtime. This is very handy if your application uses DLLs thatThinApp runtime doesn't support, for example, DLLs requiring hooking.

Example:

[BuildOptions]
ExternalDLLs=one.dll;another.dll

FileTypes: The FileTypes parameter will tell thinreg.exe what file type extensions to register to the entry point.

Example:

[Entry Point Section]
FileTypes=.htm.html.shtml.xht.xhtml

ForcedVirtualLoadPaths: The ForcedVirtualLoadPaths parameter tells ThinApp runtime to load physical DLLs within the virtual environment. This parameter is useful when an application must load external system DLLs that depend on DLL files located in the package.

Example:

[BuildOptions]
ForcedVirtualLoadPaths=%ProgramFilesDir%\LocallyInstalledApp\LoadMe.dll 

HidePrinters: The HidePrinters parameter offers the same end result as the DisablePrinting parameter, that is, the end user can't print from the packaged application. HidePrinters will hide all printers for the virtualized application.

Example:

[BuildOptions]
HidePrinters=1 (default=0)

Icon: The Icon parameter will allow you to specify an icon for your entry point.

Example:

[Entry Point Section]
Icon=%ProgramFilesDir%\Mozilla Firefox\MyOwnIcon.ico
or
Icon=%ProgramFilesDir%\Mozilla Firefox\firefox.exe,2 (Icon supports specifying specific icon within a file.)

IgnoreDDEMessages: You can block DDE messages from getting passed into the virtualized application. By default, DDE messages are passed from the operating system into the virtual environment.

Example:

[BuildOptions]
IgnoreDDEMessages=1 (default=0)

InventoryName: Setup Capture picks up the value of InventoryName during the capturing process. Setup Capture investigates the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall registry keys to learn the name of the application captured. If you capture multiple installers in one capture, you will probably have to modify the InventoryName parameter to reflect the true application name. InventoryName is used to prepopulate many Package.ini settings, such as SandboxName, MSIFilename, and many more. InventoryName is also used to populate the Add or Remove Programs window when registering the ThinApp package.

Example:

[BuildOptions]
InventoryName=Mozilla Firefox (3.5.7)

InventoryIcon: InventoryIcon is the application icon displayed on the Horizon Application Manager's workspace.

Example:

[BuildOptions]
InventoryIcon=%ProgramFilesDir%\Mozilla Firefox\firefox.exe,0

IsolatedMemoryObjects: The IsolatedMemoryObjects parameter can help when two applications, using the same shared memory object, conflict with each other. One example can be when you have one version of the application natively installed and another version virtualized.

Example:

[BuildOptions]
IsolatedMemoryObjects=*outlook*;Some Other Object

IsolatedSynchronizationObjects: The IsolatedSynchronizationObjects parameter allows you to isolate synchronization objects, for example: OpenMutex, CreateMutex, OpenSemaphore, CreateSemaphore, OpenEvent, and CreateEvent. If you have an issue and find any of these in the Log Monitor trace you might want to try isolating synchronization objects.

Example:

[BuildOptions]
IsolatedSynchronizationObjects=*outlook*;Some Other Object

LoadDotNetFromSystem: If your package includes .NET Framework, you can tell the package to discard the virtualized .NET and load the system .NET Framework on Windows 7 machines. This way, your package containing an older version of .NET can support both Windows XP and Windows 7.

Example:

[BuildOptions]
LoadDotNetFromSystem=Win7

LocaleIdentifier: LocaleIdentifier is a numeric ID identifying the language (locale) and will affect the layout and formatting of your virtualized application. By default, the locale of your capturing environment will be in your Package.ini.

Example:

[BuildOptions]
LocaleIdentifier=1033

LocaleName: The LocaleName parameter displays the name of the locale when you capture an application. This parameter is not added to Package.ini by default.

Example:

[BuildOptions]
LocaleName=en-EN

LogPath: The LogPath parameter specifies where the Log Monitor trace file will be created.

Example:

[BuildOptions]
LogPath=C:\Temp

MetaDataContainerOnly: The MetaDataContainerOnly parameter indicates that the entry point is only used as a data container.

Example:

[Entry Point Section]
MetaDataContainerOnly=1

MSIArpProductIcon: MSIArpProductIcon specifies the icon displayed in the Add or Remove Programs control panel window.

Example:

[BuildOptions]
MSIArpProductIcon=%ProgramFilesDir%\Mozilla Firefox\firefox.exe,0

MSICompressionType: You can decide to compress the MSI file content to preserve disk space. Supported values are None or Fast.

Example:

[BuildOptions]
MSICompressionType=None

MSIDefaultInstallAllUsers: This parameter specifies if the ThinApp generated MSI should be installed machine wide or per user.

Example:

[BuildOptions]
MSIDefaultInstallAllUsers=0 (Default are 1, 2 will first try to install machine wide but if not able to revert to per user installation.)

MSIFilename: When this is activated within your Package.ini file, the ThinApp build process will generate an MSI file to be used for deployment of the ThinApp package. The value of the parameter specifies the name of the file generated.

Example:

[BuildOptions]
MSIFilename=Mozilla Firefox (3.5.7).msi

MSIInstallDirectory: MSIInstallDirectory specifies the name of the folder where the ThinApp package will be deployed. By default, the name of the folder includes "(VMware ThinApp)". This is to make sure it won't conflict with any natively installed versions of the same application.

Example:

[BuildOptions]
MSIInstallDirectory=Mozilla Firefox (3.5.7) (VMware ThinApp)

MSIManufacturer: The MSIManufacturer will populate the manufacturer property in Add or Remove Programs when registering the package. The default value will be whatever company name you used when registering your capturing environment.

Example:

[BuildOptions]
MSIManufacturer=Peter Björk

MSIProductCode: Setup Capture will generate a unique Globally Unique Identifier (GUID) to identify the application deployed to your clients. Together with MSIProductVersion, it allows Windows installer to update already deployed packages with new versions. Normally, you should leave this parameter unmodified.

Example:

[BuildOptions]
MSIProductCode={FA347819-9E28-3A88-BB20-46E3F1435C94}

MSIProductVersion: MSIProductVersion is used to identify a new version of the package. If you raise the number, the build process will automatically create an update package capable of uninstalling previous versions of the package and deploy the new version automatically.

Example:

[BuildOptions]
MSIProductVersion=2.0 (default=1.0)

MSIProperty.: With MSIProperty. you can add your own properties to the MSI file generated by ThinApp.

Example:

[BuildOptions]
MSIProperty.MyCustomProperty=AnyValueYouWant

MSIRequireElevatedPrivileges: MSIRequireElevatedPrivileges specifies whether installing the MSI file requires elevated privileges or not. If required, the user will get a UAC prompt on Vista or newer operating systems. Installing per user only should not require elevated privileges.

Example:

[BuildOptions]
MSIRequireElevatedPrivileges=0 (default=1)

MSIStreaming: This parameter was called MSIUseCabs in previous versions of ThinApp. MSIStreaming tells the build process if it should include the package in the MSI file it generates or keep the package files outside. When the package files are stored within the MSI file, the filesystem is virtualized within the MSI file. This makes it impossible to use MSI editing tools like Orca to change the MSI file. If you keep the package files outside the MSI file (MSIStreaming=1), it will be possible to modify the MSI file using a traditional MSI editing tool. When using VMware View Manager to entitle ThinApp packages, MSIStreaming=1 will allow for a streaming deployment.

Example:

[BuildOptions]
MSIStreaming=1 (default=0)

MSIUpgradeCode: The MSIUpgradeCode parameter works together with the MSIProductVersion and the MSIProductCode parameters to identify if an MSI package is an update to an existing deployment. You can often leave this parameter unmodified, only changing the MSIProductVersion parameter, and the build process will automatically generate an update MSI file.

Example:

[BuildOptions]
MSIUpgradeCode={8A07FD29-1500-3A60-27AD-C761175F7F79}

NetRelaunch: NetRelaunch was introduced as a workaround to Symantec Antivirus interfering with the streaming of ThinApp packages. Nowadays, NetRelaunch is activated by default. When active, the package will relaunch itself upon streaming. This way, only a small part of the package will be accessed and therefore scanned by your antivirus initially. I know no real reason for changing this parameter. Just leave it as default. What you should do is to make sure to disable on-access antivirus scanning of your ThinApp repository.

Example:

[BuildOptions]
NetRelaunch=1 (this is the default value)

NotificationDLLs: When using the NotificationDLLs parameter, the ThinApp runtime will call a third-party DLL to provide notification of events, for example, startup and shutdown. This parameter is used when using Horizon Application Manager for entitlement.

Example:

[BuildOptions]
NotificationDLLs=HorizonPlugin.dll

NotificationDLLSignatures: The NotificationDLLSignatures parameter works hand-in-hand with the NotificationDLLs parameter to verify the signature of the DLL. If the DLL lacks the signature, ThinApp runtime will not load the file.

Example:

[BuildOptions]
NotificationDLLSignatures=VMware, Inc.

ObjectTypes: ObjectTypes will specify which COM object types thinreg.exe will register on the local operating system when registering a package. Setup Capture will pick up any object types registered during your capturing process and add the information to your entry point section.

Example:

[Entry Point Section]
ObjectTypes=Word.Application;Word.Application.12;Word.Application.8;Word.Backup.8;Word.Basic;Word.Basic.8;Word.Basic.9;Word.Document;Word.Document.12;Word.Document.8;Word.DocumentMacroEnabled;Word.DocumentMacroEnabled.12;Word.Picture;Word.Picture.8;Word.RTF.8;Word.Template;Word.Template.12;Word.Template.8;Word.TemplateMacroEnabled;Word.TemplateMacroEnabled.12;Word.Wizard.8

OptimizedFor: This parameter goes hand-in-hand with the CompressionType parameter. Using OptimizedFor, you can change from the default behavior of only compressing files other than executables and dlls. OptimizedFor=Disk will compress all files. The downside of compressing all files is decreased performance. The package will launch slower if all files are compressed. Compressing all files will also disable the ThinApp runtime's memory sharing functionality.

Example:

[Compression]
OptimizedFor=Disk (default=Memory)

OptionalAppLinks: OptionalAppLinks will activate AppLink functionality in your package. OptionalAppLinks will integrate to the child packages found but will allow for package launch if no AppLinks can be found.

Example:

[BuildOptions]
OptionalAppLinks=C:\Program Files\Java Runtime\java.exe

OutDir: The OutDir parameter specifies where the output from the build process will be stored.

Example:

[BuildOptions]
OutDir=bin

PermittedComputersSIDs: PermittedComputersSIDs specifies which computer SIDs are allowed to execute the package. It works similar to PermittedGroups, but is computer-based rather than user-based.

PermittedComputersAccessDeniedMsg: This parameter specifies the message displayed to the end user if their computer isn't allowed to launch the ThinApp package.

Example:

[BuildOptions]
PermittedComputersAccessDeniedMsg=Your machine is not entitled to run this application.

PermittedGroups: PermittedGroups is used to protect your packages. Only a user, who is a member of the Active Directory groups specified with PermittedGroups, will be able to use the package. The parameter supports adding the group's SID instead of group name. PermittedGroups can be applied package wide and/or per entry point.

Example:

[BuildOptions]
PermittedGroups=ThinApp Users
or
[Entry Point Section]
PermittedGroups=Mozilla Firefox Users

PermittedGroupSIDs: PermittedGroupSIDs can be used to specify an Active Directory group's SID for protecting a package.

Example:

[BuildOptions]
PermittedGroupSIDs=Enter the group's SID

PreventDllInjection: PreventDllInjection prevents a DLL from being loaded into a process when another process is calling SetWindowHook to set a global hook using the DLL.

Example:

[BuildOptions]
PreventDllInjection=1 (default=0)

ProcessExternalNameBehavior: By default, the original process name is hidden by the ThinApp runtime. This will allow most whitelist security products to work with ThinApp packages. The reason is that the name in the process list is the same as the filename on disk. You can change this using the ProcessExternalNameBehavior parameter.

Example:

[BuildOptions]
ProcessExternalNameBehavior=Original (default=WhitelistFriendly)

Protocols: Protocols specifies which protocols will be registered to an entry point. Setup Capture will pick up the protocols registered during the capturing process.

Example:

[Entry Point Section]
Protocols=FirefoxURL;ftp;http;https

QualityReportingEnabled: The QualityReportingEnabled parameter specifies whether the package will deliver anonymous data to VMware or not. QualityReportingEnabled=1 will send data to VMware.

Example:

[BuildOptions]
QualityReportingEnabled=0 (The package will not deliver any data to VMware)

QualityReportingTag: The anonymous data passed to VMware using QualityReportingEnabled=1 can be tagged to identify the origin of the package. This is done using the QualityReportingTag parameter, and to my knowledge it's only used within the ThinApp Factory. More information about ThinApp Factory can be found here: http://labs.vmware.com/flings/thinapp-factory.

Example:

[BuildOptions]
QualityReportingTag="ThinAppFactory"

ReadOnlyData: This parameter specifies the file that is the data container. There can only be one data container per package.

Example:

[Entry Point Section]
ReadOnlyData=Package.ro.tvr

RegistryIsolationMode: The default registry isolation mode is always WriteCopy. Using the RegistryIsolationMode parameter allows you to change the default isolation mode.

Example:

[BuildOptions]
RegistryIsolationMode=Merged (default=WriteCopy)

RemoveSandboxOnExit: This parameter allows you to wipe the sandbox clean on every exit of the package.

Example:

[BuildOptions]
RemoveSandboxOnExit=1 (default=0)

RemoveSandboxOnStart: RemoveSandboxOnStart is a new parameter. Like its sister parameter; RemoveSandboxOnExit, it will delete the sandbox content. RemoveSandboxOnStart will delete the sandbox on each start of the Package. This can be handy if you want to make sure the sandbox is always cleared. Using only the RemoveSandboxOnExit parameter might not be enough. If the packaged application crashes, RemoveSandboxOnExit will not receive a correct exit code from the application and will therefore not delete the sandbox.

Example:

[BuildOptions]
RemoveSandboxOnStart=1 (default=0)

RequiredAppLinks: RequiredAppLinks will activate AppLink functionality in your package. RequiredAppLinks will deny package launch if it cannot access the AppLink package.

Example:

[BuildOptions]
RequiredAppLinks=C:\Program Files\Oracle Client\OracleClient.exe

ReserveExtraAddressSpace: The ReserveExtraAddressSpace parameter specifies the amountof extra address space to reserve for the captured executable file.

Example:

[Entry Point Section]
ReserveExtraAddressSpace=512K

RetainAllIcons: To save disk space, ThinApp removes unused icons from the package. You can decide to keep the icons if needed.

Example:

[Entry Point Section]
RetainAllIcons=1 (default=0)

RuntimeEULA: RuntimeEULA is probably the least used Package.ini parameter you will find. Activating RuntimeEULA will display the VMware ThinApp EULA when launching the package. VMware doesn't require that you display the EULA so I honestly do not see any point in ever activating the parameter.

Example:

[BuildOptions]
RuntimeEULA=1 (default=0)

SandboxCOMObjects: You can modify the SandboxCOMObjects parameter to make COM objects, registered within the virtual environment, visible outside the virtual environment. By default, virtual COM objects are not visible in the physical environment.

Example:

[BuildOptions]
SandboxCOMObjects=1 (default=0)

SandboxName: The SandboxName parameter specifies the name of the sandbox.

Example:

[BuildOptions]
SandboxName=Mozilla Firefox

SandboxNetworkDrives: By default, network drives are not sandboxed. You can activate sandboxing of network drives using SandboxNetworkDrives=1.

Example:

[BuildOptions]
SandboxNetworkDrives=1 (default=0)

SandboxPath: This parameter specifies the location of the sandbox.

Example:

[BuildOptions]
SandboxPath=C:\Sandboxes

SandboxRemovableDisk: Removable disks are not sandboxed by default. This parameter allows you to change this behavior.

Example:

[BuildOptions]
SandboxRemovableDisk=1 (default=0)

Services: ThinApp allows virtualized services to be registered, and thereby starts during the boot of the operating system, on the native system. The service still lives within the virtual environment. To be able to register a service natively, you need to activate the service as an entry point and activate the service parameter. The value of the Services parameter is the name of the service. Setup Capture will grab information on any services registered during the capturing process and prepopulate your Package.ini file with the correct values. The service entry point is disabled by default. You must register machine wide in order for the service to be registered correctly. This means using thinreg.exe with the /a switch.

Example:

[Entry Point Section]
Services=Apache2.2

SetVirtualModuleFileNameInPeb: SetVirtualModuleFileNameInPeb=0 (default) sets the entry point file path in Process Environment Block (PEB), and applies it to all virtual child processes. When using SetVirtualModuleFileNameInPeb=1 (default value in ThinApp Version 4.5 – 4.6), PEB contains the virtual EXE's file path, which doesn't exist on the physical operating system. This means Windows Explorer can't always find the correct icon to use. You should very rarely have to use this parameter.

Example:

[BuildOptions]
SetVirtualModuleFileNameInPeb=0

Shortcut: The Shortcut parameter tells the entry point in which file the data container is stored.

Example:

[Entry Point Section]
Shortcut=Mozilla Firefox.exe

Shortcuts: The Shortcuts prameter is used when registering a package, and specifies where shortcuts will be created.

Example:

[Entry Point Section]
Shortcuts=%Desktop%;%Programs%\Mozilla Firefox

Source: The Source parameter identifies the target of the entry point, that is, what will be launched within the virtual environment. The source can be located either within or outside the virtual environment. The source does not have to be an executable as long as the file type extension is registered to an application.

Example:

[Entry Point Section]
Source=%ProgramFilesDir%\Mozilla Firefox\firefox.exe

StatusbarDisplayName: With the help of the StatusbarDisplayName parameter you can change the application name displayed in the ThinApp splash screen.

Example:

[BuildOptions]
StatusbarDisplayName=Mozilla Firefox

StripVersionInfo: By default, the ThinApp package will keep the entry point target's version information and add them to the entry point. You can strip the version information using the StripVersionInfo parameter.

Example:

[Entry Point Section]
StripVersionInfo=1 (default=0)

ThinDirectWhitelistOnly: The ThinDirectWhitelistOnly parameter allows you to specify whether or not a browser package should redirect back to the default browser. The default behavior is to redirect the user to the default browser if visiting any URL not ThinDirected to the package.

Example:

[BuildOptions]
ThinDirectWhitelistOnly=0 (default=1)

UACRequestedPrivilegesLevel: You can modify the UACRequestedPrivilegesLevel parameter to specify which privileges your package requires on an operating system supporting User Account Control (UAC). Possible values are: asInvoker (default), requireAdministrator, or highestAvailable. highestAvailable will use the highest privilege possible avoiding UAC prompt.

Example:

[BuildOptions]
UACRequestedPrivilegesLevel=highestAvailable

UACRequestedPrivilegesUiAccess: This parameter specifies access or no access to protected user interface elements. Possible values are false or true.

Example:

[BuildOptions]
UACRequestedPrivilegesUiAccess=false (no access to protected elements)

UpgradePath: UpgradePath is an interesting parameter. When using in-place update it will be used to specify where the package searches for updated versions of itself. If your package uses AppSync, UpgradePath will be the location where the AppSync cache, log, and update package is stored.

Example:

[BuildOptions]
UpgradePath=C:\Updates

Version.: The Version. parameter populates the version tab of the entry point's file properties with custom information.

Example:

[Entry Point Section]
Version.AnythingYouWant=VeryImportantValue

You can add your own file version properties. The Package.ini settings of the previous picture are asfollows:

[Mozilla Firefox.exe]
Source=%ProgramFilesDir%\Mozilla Firefox\firefox.exe
ReadOnlyData=Package.ro.tvr
Version.Peter=Testing

VirtualComputerName: ThinApp can virtualize the hostname. This is handy when the packaged application refers to the hostname where it was originally installed. Virtualizing the hostname can help in making the package portable. Another workaround may be to capture the application on a machine using LOCALHOST as the hostname. The default behavior is to pass the native hostname to the virtualized application.

Example:

[BuildOptions]
VirtualComputerName=MACHINE1

VirtualDrives: ThinApp can virtualize drives. By default, the C-drive of your capturing environment is virtualized. This way, the serial number of the C-drive is virtualized. This helps in making some legacy applications portable. VirtualDrives uses a couple of parameters to define the virtual drive it creates. Drive= specifies the drive letter of the virtual drive. Serial= specifies the serial number of the virtual drive. Serial= is not required. Type= specifies what kind of drive ThinApp will pretend that the virtual drive is. Possible values are REMOVABLE, RAMDISK, CDROM, and FIXED. Your package can only have one VirtualDrives parameter active. You separate each virtual drive with a semicolon.

Example:

[BuildOptions]
VirtualDrives=Drive=a, Serial=00de1968, Type=REMOVABLE; Drive=c, Serial=647c820d, Type=FIXED; Drive=d, Serial=647c820d, Type=CDROM

VirtualElevation: VirtualElevation=1 means the ThinApp runtime will lie to the app and tell it that it's running as an elevated process. VirtualElevation=0 means ThinApp runtime will pass the true elevation status to the application. So this is a bit different from UACRequestedPrivilegesLevel, which really affects the elevation status. VirtualElevation only affects what ThinApp runtime will tell the process.

Example:

[BuildOptions]
VirtualElevation=1

VirtualizeExternalOutOfProcessCOM: VirtualizeExternalOutOfProcessCOM specifies if ThinApp will run an external process, called by using COM, within the virtual environment or not. By default, such a process is run within the virtualized environment.

Example:

[BuildOptions]
VirtualizeExternalOutOfProcessCOM=0 (default=1)

WorkingDirectory: The WorkingDirectory parameter specifies what will be the working directory for the application launched. If not specified, the working directory will be the location of the package.

Example:

[Entry Point Section]
WorkingDirectory=%ProgramFilesDir%\Mozilla Firefox

Wow64: The Wow64 parameter tries to simulate a 32-bit environment when the package is running on a 64-bit operating system. If your 32-bit application has a problem running on a 64-bit system you can try to activate this parameter. It will only help a few applications but is still worth trying.

Example:

[BuildOptions]
Wow64=0

XYZ=AnyValue: You can add anything to Package.ini and it will be accessible via vb-scripting or the ThinApp SDK. This way, you can pick up custom settings with your script.

Example:

[BuildOptions]
MyNameIs=Peter_Bjork

AppID=genid: AppID is a unique application identifier used by Horizon to be able to track and manage the package.

NotificationDLLs=HorizonPlugin.dll: The NotificationDLLs parameter tells the ThinApp runtime that it has to ask the HorizonPlugin.dll for entitlement before allowing execution of the package.

HorizonOrgUrl=http://www.MyHorizonXYZ.com: The HorizonOrgUrl value should point to your Horizon Workspace URL. When specified, the end user will be presented with a link to download the Horizon Agent, if it's not already installed on the same machine that the ThinApp package is executed on.

VersionID=: VersionID is used by Horizon to identify updated versions of already managed packages.