(For more resources related to this topic, see here.)
The capture and build environment
You cannot write a book about a packaging format without discussing the environment used to create the packages. The environment you use to capture an installation is of great importance.
ThinApp uses a method of snapshotting when capturing an application installation. This means you create a snapshot (Pre-Installation Snapshot) of the current state of the machine. After modifying the environment, you create another snapshot, the Post-Installation Snapshot. The differences between the two snapshots represent the changes made by the installer. This should be all the information you need in order to run the application. Many packaging products use snapshotting as a method of capturing changes. The alternative would be to try to hook into the installer itself. Both methods have their pros and cons. Using snapshot is much more flexible. You don't even have to run an installer. You can copy files and create registry keys manually and it will all be captured. But, your starting point will decide the outcome.
If your machine already contains the Java Runtime Environment ( JRE ) and the application you are capturing requires Java, then you will not be able to capture the JRE. Since it was already there when you ran the pre-install snapshot, it will not be a part of the captured differences. This means your package would require Java installed or it will fail to run. The package will not be self-contained.
The other method, monitoring the installer, will be more independent of the capturing environment but will not support all the installer formats and will not support manual tweaking during capture. Nothing is black or white. Snapshotting can be made a little more independent of the capture environment. When an installer discovers components already installed, it can register itself to the same components. ThinApp will recognize this, investigate which files are related to a component, and mark them as needed to be included in the package. But this is not a bulletproof method. So the general rule is to make sure your environment allows ThinApp to capture all required dependencies of the application.
ThinApp packages are able to support multiple operating systems with one single package. This is a great feature and really helps in lowering the overall administration of maintaining an application. The possibility of running the same package on your Windows XP clients, Windows 7 machines, and your XenApp servers is unique. Most other packaging formats require you to maintain one package per environment.
The easiest method to package an application is to capture it on the platform where it will run. Normally you can achieve an out of the box success rate of 60 — 80 percent. This means you have not tweaked the project in any way. The package might not be ready for production but it will run on a clean machine not having the application locally installed.
If you want to support multiple operating systems you should choose the lowest platform you need to support. Most of the time this would be Windows XP. From ThinApp's point of view, Windows XP and Windows Server 2003 are of the same generation and Windows 7 and Windows 2008 R2 are of the same generation.
Most installers are environment aware. They will investigate the targeting platform and if it discovers a Windows 7 operating system, it knows that some files are already present in the same or newer version than required. Installing on a Windows XP with no service pack would force those required files to be installed locally, and therefore captured by the capturing process. Having these files captured from and installation made on Windows XP rarely conflicts the running of the application on Windows 7 and helps you achieve multiple OS support.
Creating a package for one single operating system is of course the easiest task. Creating a package supporting multiple operating systems, all being 32-bit systems is a little harder. How hard depends on the application. Creating a package supporting many different OS and both 32-bit and 64-bit versions is the hardest. But it is doable. It just requires a little extra packaging effort. Some applications cannot run on a 64-bit OS, but most applications offer some kind of work around. If the application contains 16-bit code, then it's impossible to make it run on a 64-bit environment. 64-bit environments cannot handle 16-bit code. Your only workaround for those scenarios is whole machine virtualization technologies. VMware Workstation, VMware View, Citrix XenDesktop, Microsoft Med-V, and many others offer you the capability to access a virtualized 32-bit operating system on your 64-bit machine.
In general, you should use an environment that is as clean as possible. This will guarantee that all your packages include as many dependencies as possible, making them portable and robust. But it's not written in stone. If you are capturing an add-on to Microsoft Office, then Microsoft Office has to be locally installed in your capturing environment or the add-on installer would fail to run. You must design your capture environment to allow flexibility. Sometimes you capture on Windows XP, the next application might be captured on Windows 7 64-bit. The next day you'll capture on a machine having JRE installed, or Microsoft Office. The use of virtual machines is a must. Physical machines are supported but the hours spent on reverting to a clean state to start the capture of the next application makes it virtually useless.
My capture environment is my MacBook Pro running VMware Fusion and several virtual machines such as Windows XP, Windows Vista, Windows 7, Windows 2003 Server, and of course Windows Server 2008. All VMs have several snapshots (states of the virtual machine) so I can easily jump back and forth between clean, Microsoft Office-installed and different service packs and browsers. Yes, it will require some serious disk space. I'm always low on free disk space. No matter how big the disks you buy are, your project folders and virtual machines will eat it all. I have two disks in my MacBook. One SSD disk, where I keep most of my virtual machines, and one traditional hard disk where I keep all my project folders. The best capture environments I've ever seen have been hosted on VMware vSphere and ESX. Using server hardware to run client operating systems make them fast as lightning. Snapshotting of your VMs take seconds, as well as reverting snapshots.
Access to the virtual machines hosted on VMware ESX can be achieved using a console within the vSphere client or basic RDP. The only downside I can see to using an ESX environment is that you cannot do packaging offline, while traveling.
The next logical question is if my capture machine should be a domain member or standalone, this depends, I always prefer to capture on standalone machines. This way I know that group policies will not mess with my capture process. No restrictions will be blocking me from doing what I need to do. But again, sometimes you can simply not capture an application without having access to a backend infrastructure. Then your capture machine must be on the corporate network and most of the time it means that it has to be a domain member. If possible, try putting the machine in a special Organizational Unit ( OU) where you limit the amount of restrictions.
If at all possible, make sure you don't have antivirus installed on your capturing environment. I know that some enterprises have strict policies forcing even packaging machines to be protected by antivirus. But be careful. There is no way of telling what your antivirus may decide to do to your application's installation and the whole capture process. Most installer manuals clearly state to disable any antivirus during installation. They do that for a reason. Antivirus scanning logs and all that follows will also pollute your project folder. It will probably not break your package but I am a strong believer in delivering clean and optimized packages. So having an antivirus means you will have to spend some time cleaning up your project folders. Alternatively, you can include areas where the antivirus changes content in snapshot.ini, the Setup Capture exclusion list.
Entry points and the data container
An entry point is the doorway into the virtual environment for the end users. An entry point specifies what will be launched within the virtual environment. Mostly an entry point points to an executable, for example, winword.exe. But an entry point doesn't have to point to an executable. You can point an entry point to whatever kind of file you want, as long as the file type has a file association made to it. Whatever is associated to the file type will be launched within the virtual environment. If no file type association exists, you will get the standard operating system dialog box, asking you which application to open the file with. The name of the entry point must use an .exe extension. When the user double-clicks on an entry point, we are asking the operating system to execute the ThinApp runtime. Entry points are managed in Package.ini. You'll find them at the end of the Package.ini file.
The data container is the file where ThinApp stores the whole virtual environment and the ThinApp runtime. There can only be one data container per project. The content in the data container is an exact copy of the representation of the virtual environment found in your project folder. The data in the data container is in read-only format. It's the packagers who change the content by rebuilding the project. An end user cannot change the content of the data container. An entry point can be a data container. Setup Capture will recommend not using an entry point as a data container if Setup Capture believes that the package will be large (200 MB-300 MB). The reason for this is that the icon of the entry point may take up to 20 minutes to be displayed. This is a feature of the operating system and there's nothing you can do about it. It's therefore better to store the data container in a separate file and keep your entry points small. Make sure the icons are displayed quickly. Setup Capture will force you to use a separate data container when the size is calculated to be larger than 1.5 GB. Windows has a size limitation for xecutable files. Windows will deny executing a .exe file larger than 2 GB.
The name of the data container can be anything. You will not have to name it with the .dat extension. It doesn't have to have a file extension at all. If you're using a separate data container, you must keep the data container in the same folder as your entry points.
Let's take a closer look at the data container and entry point section of Package.ini. You'll find the data container and entry points at the end of the Package.ini file. The following is an example Package.ini file from a virtualized Mozilla Firefox:
[Mozilla Firefox.exe] Source=%ProgramFilesDir%\Mozilla Firefox\firefox.exe ;ChangeReadOnlyData to bin\Package.ro.tvr to build with old versions(4.6.0 or earlier) of tools ReadOnlyData=Package.ro.tvr WorkingDirectory=%ProgramFilesDir%\Mozilla Firefox FileTypes=.htm.html.shtml.xht.xhtml Protocols=FirefoxURL;ftp;http;https Shortcuts=%Desktop%;%Programs%\Mozilla Firefox;%AppData%\Microsoft\ Internet Explorer\Quick Launch [Mozilla Firefox (Safe Mode).exe] Disabled=1 Source=%ProgramFilesDir%\Mozilla Firefox\firefox.exe Shortcut=Mozilla Firefox.exe WorkingDirectory=%ProgramFilesDir%\Mozilla Firefox CommandLine="%ProgramFilesDir%\Mozilla Firefox\firefox.exe"-safe-mode Shortcuts=%Programs%\Mozilla Firefox
A step-by-step explanation for the parameters is given as follows:
Within  is the name of the entry point. This is the name the end user will see. Make sure to use .exe as your file extension.
The source parameter points to the target of the entry point, that is, what will be launched when the user clicks on the entry point. The source can either be a virtualized or physical file. The target will be launched within the virtual environment no matter where it lives.
The ReadOnlyData indicates this entry point is in fact a data container as well.
This specifies the working directory for the executable launched. This is often a very important parameter. If you do not specify a working directory, the active working directory will be the location of your package. A lot of software depends on having their working directory set to the application's own folder in the program files directory.
This is used when registering the entry point. It specifies which file extensions should be associated with this entry point. The previous example registers .htm, .html, and so on to the virtualized Mozilla Firefox.
This is used when registering the entry point. It specifies which protocols should be associated with this entry point. The previous example registers http, https, and so on to the virtualized Mozilla Firefox.
The parameter Shortcuts is also used when registering your entry points. The Shortcuts parameter decides where shortcuts will be created. The previous example creates shortcuts to virtualized Mozilla Firefox on the Start menu in a folder called Mozilla Firefox, as well as a shortcut on the user's desktop.
[Mozilla Firefox (Safe Mode).exe] Disabled=1
Disabled means this entry point will not be created during the build of your project.
Source=%ProgramFilesDir%\Mozilla Firefox\firefox.exe Shortcut=Mozilla Firefox.exe
Shortcut tells this ent;ry point what its data container is named. If you change the data container's name you will have to change the Shortcut parameter on all entry points using the data container.
WorkingDirectory=%ProgramFilesDir%\Mozilla Firefox CommandLine="%ProgramFilesDir%\Mozilla Firefox\firefox.exe"-safe-mode
CommandLine will allow you to specify hardcoded parameters to the executable. It's the native parameters supported by the virtualized application that you use.
There are many more parameters related to entry points. The following are some more examples with descriptions:
[Microsoft Office Enterprise 2007.dat] Source=%ProgramFilesDir%\Microsoft Office\Office12\OSA.EXE ;ChangeReadOnlyData to bin\Package.ro.tvr to build with old versions(4.6.0 or earlier) of tools ReadOnlyData=Package.ro.tvr MetaDataContainerOnly=1
MetaDataContainer indicates that this is a separate data container.
[Microsoft Office Excel 2007.exe] Source=%ProgramFilesDir%\Microsoft Office\Office12\EXCEL.EXE Shortcut=Microsoft Office Enterprise 2007.dat FileTypes=.csv.dqy.iqy.slk.xla.xlam.xlk.xll.xlm.xls.xlsb.xlshtml.xlsm. xlsx.xlt.xlthtml.xltm.xltx.xlw Comment=Perform calculations, analyze information, and visualize data in spreadsheets by using Microsoft Office Excel.
Comment allows you to specify text to be displayed when hovering your mouse over the shortcut to the entry point.
ObjectTypes=Excel.Addin;Excel.AddInMacroEnabled;Excel. Application;Excel.Application.12;Excel.Backup;Excel.Chart;Excel. Chart.8;Excel.CSV;Excel.Macrosheet;Excel.Sheet;Excel.Sheet.12;Excel. Sheet.8;Excel.SheetBinaryMacroEnabled;Excel.SheetBinaryMacroEnab led.12;Excel.SheetMacroEnabled;Excel.SheetMacroEnabled.12;Excel. SLK;Excel.Template;Excel.Template.8;Excel.TemplateMacroEnabled;Excel. Workspace;Excel.XLL
This specifies the object types which will be registered to the entry point when registered.
Shortcuts=%Programs%\Microsoft Office StatusBarDisplayName=WordProcessor
Users can change the name displayed in the ThinApp splash screen. In this example, WordProcessor will be displayed as the title.
Icon allows you to specify an icon for your entry point. Most of the times ThinApp will display the correct icon without this parameter. You can point to an executable to use its built-in icons as well. You can specify a different icon set by applying 1 or 2 and so on to the icon path, for example, Icon=%ProgramFilesDir%\Microsoft Office\Office12\EXCEL.EXE,1
The most common entry points should be either cmd.exe or regedit.exe. You'll find them in all Package.ini files but they are disabled by default. Since cmd.exe and regedit.exe most likely weren't modified during Setup Capture, they are not part of the virtual environment. So the source will be the native cmd.exe and regedit.exe. These two entry points are the packagers' best friends. Using these entry points allows a packager to investigate the environment known to the virtualized application. What you can see using cmd.exe or regedit.exe is what the application sees. This is a great help when troubleshooting.
If you package an add-on to a natively installed application, the typical example is packaging JRE and you want the local Internet Explorer to be able to use it. Creating an entry point within your Java package using native Internet Explorer as a source, is a perfect method of dealing with it. Now you can offer a separate shortcut to the user, allowing users to choose when to use native Java or when to use virtualized Java. ThinApp's isolation will allow virtualization of one Java version running on a machine with another version natively installed. The only problem with this approach is how you educate your users when to use which shortcut. ThinDirect, discussed later in this article, in the Virtualizing Internet Explorer 6 section, will allow you to automatically point the user to the right browser. There are many use cases for launching something natively within a virtualized environment. You may face troublesome Excel add-ons. Virtualizing them will protect against conflicts, but you must launch native Excel within the environment of the add-on for it to work. Here you could use the fact that many Excel add-ons use .xla files as the typical entry point to the add-on. Create your entry point using the .xla file as source and you will be able to launch any Excel version that is natively installed. When you use a non executable as your entry point source, remember that the name of your entry point must still be .exe. The following is an example of an entry point using a text file as source:
[ReadMe.exe] Source=%Drive_C%\Temp\readme.txt ReadOnlyData=Package.ro.tvr
Running ReadMe.exe will launch whatever is associated to handle .txt files. The application will run within the virtualized environment of the package.
The project folder
The project folder is where the packager spends most of his or her time. The capturing process is just a means to create the project folder. You could just as easily create your own project folder from scratch. I admit, to manually create a project folder representing a Microsoft Office installation would be far from easy but in theory it can be done. There is some default content in all project folders. Let's capture nothing and investigate what these are.
During Setup Capture, to speed things up, disable the majority of the search locations. This way pre and post scans will take close to no time at all.
Run Setup Capture.
In the Ready to Prescan step, click on Advanced Scan Locations....
Exclude all but one location from the scanning, as shown in the following screenshot:
Since we want to capture nothing, there is no point in scanning all locations. Normally you don't have to modify the advanced scan locations.
After pressing Prescan, wait for Postscan to become available and click on it when possible, without modifying anything in your capturing environment.
Accept CMD.EXE as your entry point and accept all defaults throughout the wizard.
Your project folder will look like the following screenshot:
The project folder of a capturing, bearing no changes, will still create folder macros and default isolation modes.
Let's explore the defaults prepopulated by the Setup Capture wizard. This is the minimum project folder content that the Setup Capture will ever generate. As a packager you are expected to clean up unnecessary folders from the project folder, so your final project folder may very well contain a smaller number of folder macros. Folder macros are ThinApp's variables. %ProgramFilesDir% will be translated to C:\Program Files on an English Windows installation but the same package running on a Swedish OS the %ProgramFilesDir% will point to C:\Program. Folder macros are the key to ThinApp packages' portability.
If we explore the filesystem part of the project folder, we'll see the default isolation modes prepopulated by Setup Capture. These are applied as defaults no matter what default filesystem isolation mode you choose during the Setup Capture wizard. This confuses some people. I'm often told that a certain package is using WriteCopy or Merged as the isolation mode. Well that's just the default used when no other isolation mode is specified. A proper project folder should have isolation modes specified on all locations of importance, basically making the default isolation mode of no importance. The prepopulated isolation modes are there to make sure most applications run out of the box ThinApped. You are expected to change these to suit your application and environment.
Let's look at some examples of default isolation modes.
%AppData%, the location where most applications store user settings, is by default using WriteCopy. This is to make sure that you sandbox all user settings.
%SystemRoot% and %SystemSystem% have WriteCopy as their default isolation modes, allowing a virtualized application to see the operating system files without allowing it to modify C:\Windows and C:\Windows\System32.
%SystemSystem%\spool representing C:\Windows\System32\Spool has Merged as its default. This way print jobs will be spooled to the native location, allowing the printer to pick up the print job.
%Desktop% (user's desktop folder) and %Personal% (user's document folder) have Merged by default.
When ThinApp generates the project folder, it uses the following logic to decide which isolation mode to prepopulate other locations with. The same logic is used within the registry as well.
Modified locations will get WriteCopy as the isolation mode
New locations will get Full as their isolation mode
The Package.ini file
Package.ini, found in the root of the project folder, is the project wide settings file. Here you can apply configuration changes that will be applied to the whole project. Many parameters are prepopulated in Package.ini. Some are default ThinApp values and some are from your choices made during Setup Capture. I prefer to change very few of the defaults in Setup Capture. I'd rather change my project settings within the Package.ini file directly. There are quite a few Package.ini parameters you can use, though not all of them are listed in Package.ini by default. I will explain the parameters that are included by default. A complete list of Package.ini parameters are found in References of this book. Package.ini is structured in different sections. [BuildOptions] is the section where you'll find most of the parameters. This section's parameters will be applied project wide, that is, to all of your entry points within the project. [FileList], [Compression] , and [Isolation] parameters act as the ones under [BuildOptions]but are in different sections for backward compatibility reasons. You must place a parameter in its correct section. Luckily, a clear majority of the parameters will live under [BuildOptions]. Then you have entry point-specific sections, [EntryPointName.exe]. These sections' parameters are only applied to that particular entry point. Only a very few parameters can be used both in [BuildOptions] and under [EntryPointName.exe]. Most default parameters are commented out in the Package.ini file. You can activate the parameter simply by deleting the semicolon in front of the parameter, saving your Package.ini file, and rebuilding your project.
Let's have a look at the Package.ini file in our Mozilla Firefox project folder.
CompressionType must be located under [Compression]. It supports two values, None or Fast. The None value offers no compression of the files within your package. Fast will, since Version 4.5 of ThinApp, by default only compress non executables and DLLs. For performance reasons, ThinApp will leave executables and DLLs uncompressed. You can change this behavior using OptimizeFor=Disk.
DirectoryIsolationMode specifies the isolation mode used on the filesystem if no other isolation mode has been specified for that particular location.
This indicates the start of the build options section.
AccessDeniedMsg=You are not currently authorized to run this application. Please contact your administrator.
This is the message displayed to the user if they try to run a ThinApp package using Active Directory group membership for protection, and the user is not a member of the correct group. It works together with the PermittedGroups parameter.
This identifies which version of ThinApp was used to capture this project.
This is where the output of your build process will be.
SandboxName=Mozilla Firefox (3.5.2)
This is the name of the sandbox used. All entry points within a project share the same sandbox. They are all running within the same virtual environment. Each project must have their own sandbox. You should have one sandbox per user and package. You cannot have two active users or packages sharing the same sandbox. The sandbox will be locked by the first user/package launched.
InventoryName=Mozilla Firefox (3.5.2)
This is the name of the package. It will be displayed in numerous locations, for example, in Add and Remove programs. It will be picked up by inventory tools and is used to prepopulate the Package.ini parameters using the name of the package, for example, SandboxName and MSIFilename.
This specifies which icon will be displayed in the application store of VMware Horizon Application Manager.
;PermittedGroups=Administrators;Remote Desktop Users
This is used to lock down the package so that only members of listed Active Directory groups are allowed to execute the entry points of this project. You can use PermittedGroups on a per entry point basis as well. The machine where you run build.bat must be a domain member in order to pull the Security Identifier (SID) of the group. The package will contain the SID of the groups, so when executing it on clients no query will go to the domain controllers, but the locally cached credentials will be used to authorize the user. Instead of entering a group name you can provide the SID of the group. This allows you to build on a machine not being a member of the domain. Using SIDs allows for a package to support multiple domains with no trusts between the domains. This parameter works together with the AccessDeniedMsg parameter.
This activates the possibility for your package to delete the sandbox when the user shuts down the application.
This allows you to delete the sandbox on each launch of an application.
By default, removable disks and network drives are not sandboxed. Activate it to change the behavior.
By default, child processes are loaded within the virtual environment of the package calling the child process. There are different methods of calling another process. One is to use COM. VirtualizeExternalOutOfProcessCOM specifies if a process called via COM should be loaded within the virtualized environment (default) or not. This parameter together with ChildProcessEnvironmentExceptions is often used in order to support integration between virtualized application and natively installed applications.
;OptionalAppLinks=plugins\*.exe ;RequiredAppLinks=\\server\share\*.exe;c:\abs\path\file.exe VirtualDrives=Drive=c, Serial=647c820d, Type=FIXED ;VirtualDrives=Drive=a, Serial=00e20ba8, Type=REMOVABLE; Drive=c, Serial=647c820d, Type=FIXED; Drive=d, Serial=647c820d, Type=CDROM
ThinApp can virtualize drives. By default C: will be active as a virtual drive. This allows ThinApp to present the same C: serial number to the application no matter on which machine the package executes. By default Package.ini is prepopulated with all of the local drives of your capturing environment, but disabled out. Make sure you only have one active VirtualDrives parameter in your Package.ini file. Minimum required values for VirtualDrives are Drive and Type. You do not have to specify a serial number. If you want to virtualize a CD-ROM and add some files on the virtual CD-ROM, you will have to specify the virtual drive in Package.ini first.
VirtualDrives=Drive=c, Serial=647c820d, Type=FIXED; Drive=X, Type=CDROM
Then you must create the folder macro (%Drive_X%) representing the virtual drive within your project folder. %Drive_X% is shown in the project folder in the following screenshot:
Drive_X is the folder macro representing your virtual drive using X: as the drive letter.
The virtualized X: is only present in the virtualized environment.
You can virtualize the computer name within your virtual environment. Package.ini will save the computer name from your capturing environment. Some applications will use the computer name and therefore break portability. Another method of allowing portability for such an application is to name your capture machine LOCALHOST. This way, all application references to the computer name will use LOCALHOST.
You can specify the specific regional settings within the virtual environment. This helps deal with applications changing their behavior depending on which region the operating system has.
Wow64 can sometimes help a 32-bit application to run on a 64-bit operating system. More on capturing on 32-bit and running on a 64-bit OS is available in the Some packaging tips section in this article.
If you captured the .NET Framework on a Windows XP machine, you can, by activating this parameter, tell the ThinApp runtime to discard the virtualized .NET Framework and use the system one instead when running on Windows 7. This would allow your package to contain an older version of .NET. The old version would be used on Windows XP but not on Windows 7 (Windows 7 cannot use older versions of .NET).
This parameter allows the package to report successful executions to a VMware server for quality assurance. You can disable this feature with the value 0.
By activating this parameter, the packaged application will not receive any DDE messages from the operating system. This can help you run multiple instances of the same application.Often DDE is used to keep new instances of already loaded applications from loading. This is to preserve memory on the clients. But DDE is often a bad thing if you want to run multiple versions of an application, for example, one instance of Excel Version 2003 and at the same time Excel 2007.
;-------- Horizon Parameters ---------- ;AppID=genid ;NotificationDLLs=HorizonPlugin.dll
These two parameters will enable the VMware Horizon Application Manager management of the package. Add these two parameters to enable Horizon management in projects captured using old versions of ThinApp. Learn more on Horizon management of ThinApps later in this article.
This indicates the start of the entry point section. Entry points were discussed earlier in this article in the Entry points and the data container section.
Isolation mode considerations
You can change isolation modes for folders by modifying the ##Attributes.ini file within it. This is shown in the following screenshot:
If the folder within your project folder does not contain a ##Attributes.ini file, simply create one using Notepad or copy one from another folder.
You can change isolation modes on a per-registry sub tree basis using the isolation_merged, isolation_writecopy, or isolation_full parameter in front of the registry location, as shown in the following screenshot:
When you package an application it is important to find out which isolation modes are required within the project to get the behavior you want from your package. A packager must test run the package and explore the sandbox. This allows the packager to get to know the application and to know how it behaves as a ThinApp package. Typical things of interest are as follows:
The initial launch size of the sandbox
Whether the sandbox size will grow by using the package and by launching it several times
No temporary files bloat your sandbox
You can delete the sandbox after exiting the package
A good practice is to make sure the sandbox is as small as possible. This will make the sandbox easier to roam if you are using roaming profiles. In general, there is never any reason to allow the sandbox to grow beyond control. A good ThinApp package, from my point of view, is the smallest possible package creating the smallest possible sandbox. Some applications open files with editing ability without really needing to. If these files are located within the virtual environment, they will end up in the sandbox. There is not much you can do about this. But sometimes you can create a mix between the physical elements (registry and filesystem objects) and virtual elements. For example, you can choose not to sandbox user settings by Using the Merged isolation mode on %AppData% and all its subfolders. The benefit of doing this is that your sandbox will be smaller and you can more easily manipulate the settings accessing the native location. The downside is of course that not all changes made by the package are included in one portable folder. I don't prefer one model over another, as both offer their pros and cons. The most important thing is to understand that you have the option.
A question I often get is whether an application packaged using ThinApp supports Group Policy Objects (GPO) or not. The answer is simple, both yes and no. GPOs are simply registry keys. You know by now that ThinApp is able to virtualize registry keys and is able to fully isolate native keys. By capturing on a non-domain member, ThinApp will by default create a package that will allow GPOs to be applied to the virtualized application. If you capture on a domain member, you risk capturing some parts of the registry where GPOs are located. Then your package will have fixed GPO settings, that is, when changing your network GPO settings, the package will not see those changes. You can decide to fully isolate the GPO part of the registry so that no GPO settings will be available to the virtualized application.
The following is a list of the isolation mode settings needed to make a ThinApp package unaffected by GPO (by default the virtualized application will honor GPO settings).
HKEY_CURRENT_USER.txt isolation_full HKEY_CURRENT_USER\Software\Policies isolation_full HKEY_CURRENT_USER\Software\Microsoft\Windows\ CurrentVersion\Policies
HKEY_LOCAL_MACHINE.txt isolation_full HKEY_LOCAL_MACHINE\Software\Policies isolation_full HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\ CurrentVersion\Policies
Another important thing to consider, when packaging an application, is its integration with other applications, especially locally installed applications. Let's say you virtualize Internet Explorer (IE). Using the package IE, you click on a Word document hosted on a web page. That document will be downloaded into Temporary Internet Files. When downloaded, IE will contact Winword.exe and request it to open the file that just got downloaded. The folder in this example is what I call a hand-over-folder . Hand-over-folder is not a generally used term. I've made it up myself. But it explains quite well what the folder is used for. The hand-over-folder is of greatest importance when it comes to interaction between virtual applications and natively installed ones. It can also be of importance when two virtualized applications, not having been AppLinked, need to interact as well.
If the hand-over-folder is using the WriteCopy or Full isolation mode, then the download in our Internet Explorer example will be sandboxed. Internet Explorer only knows about the normal path to Temporary Internet Files, that is, C:\Documents and Settings\User\Local Settings\Temporary Internet Files. Virtualized IE has no idea that the correct physical location of the hand-over-folder is actually C:\Documents and Settings\UserName\Application Data\Thinstall\Internet Explorer\%Internet Cache%. When Internet Explorer passes over the path to Winword.exe, it will be the wrong path. Winword.exe will execute and try to access the file, but in vain. It cannot find the file and you are left with an error message stating the file cannot be accessed. The workaround is to make sure that all hand-over-folders are using Merged as their isolation mode. That is to say, go to the hand-over-folder inside the project folder and change the isolation mode in the ##Atributes.ini file to Merged.
In this article, you have learned the packaging process. You have also learned about virtualizing Internet Explorer and using ThinDirect. We have discussed the defaults in Package.ini and some best packaging practices.
Resources for Article :
- FAQ on Virtualization and Microsoft App-V [Article]
- Tips and Tricks on Microsoft Application Virtualization 4.6 [Article]
- Installing Zenoss [Article]