Updating VMware ThinApp packages is much easier and scale with ease when compared to updating traditional software packages. In fact VMware ThinApp offer multiple ways to update ThinApp Software packages that every environment can find a mechanism that suit their needs. In this post, I will discuss the major VMware ThinApp update mechanisms and the scenario each update mechanism suit best. I have noticed many posts/articles around the web talk about how to use a certain VMware ThinApp update mechanism, but not many that explain when to use that mechanism. In this post, I will work on trying to cover both area how to use a specific VMware ThinApp update mechanism and when to use it.

Before going into each mechanism, its worth mentioning this post is a part of a larger VMware ThinApp series I am creating & below are the links to other VMware ThinApp posts in this series in case you were looking for one of these or interested to read about it as well.

The Magic of Application Virtualization with VMware ThinApp

VMware ThinApp Preparing the ThinApp Capture and Build Machine

VMware ThinApp Deployment Scenarios

Updating VMware ThinApp Packages Mechanisms(This Post)

VMware ThinAPP Antivirus Best Practices

VMware ThinApp Isolation Modes Explanation, Examples, & Video

OK, so let’s look at the different VMware ThinApp packages update mechanism available to you

:

Updating VMware ThinApp Packages with In-Place Updates

Let’s first cover how this procedure work. Let’s assume you have an application already deployed into production and this application is called package.exe

1. Carry out a capture and build for the updated version of the target application, let’s call it package in our scenario
2. Append the package container file (.exe or .dat) with .1 (or highest integer file extension +1). In our case the new package container will be package.exe.1 where next update will be package.exe.2. If you were using .dat then assuming your original package container is package.dat then you should rename your updated one to package.dat.1
3. Copy the update package next to the old package. In our example you will now have package.exe and package.exe.1 in the same folder.
4. As users attempt to launch the previous version of the application, the upgraded version executes.

Its worth noting that ThinApp will always launch the application using the container with the highest integer. Let’s assume you have a folder which contain package.exe  package.exe.1 package.exe.2 if you execute package.exe which is your original package ThinApp will actually launch package.exe.2 which is the latest version instead.

This update mechanism is best suitable for streaming scenarios. Customers who stream applications seems to highly benefit from the in place upgrade mechanism, as it allow them to carry out an upgrade of their packages with ease and without downtime. All they have to do is to copy the file next to the original package and as soon the users close the old instance and open a new one he will be running the new instance. Further, it will allow for an easy fail-back if the updated ThinApp package deemed having a problem, all you have to do is delete the package with the highest extension number and users access will be restored automatically to the earlier version which was never as quick & easy in traditional software deployment. Another way of reverting back to an older version is to copy the older version you wanted and give it a higher extension number, which might work a bit better in many cases as you don’t have to stop all users access due to the newer package being locked and can not be deleted.  It make software updating a breeze. The same mechanism can be used for locally deployed machines, though you will need to watch out for disk space specially in VDI scenarios as the packages will co-exist on all systems where you can end up having 10 copies of the same software on the same machine if you don’t watch out. Further, this method work quite well for both minor and major updates.

:

Updating VMware ThinApp Packages Using MSI

This update mechanism is very similar to the way you do your traditional software update/upgrade. You build the new update package with the same product name as MSI package and you deployed it to your end user machine. The new MSI uninstall the older version of the machine and install the new one. The main different of how this was done in the traditional software world it required many complications to ensure the software is uninstalled and installed correctly, where in the ThinApp world your install and uninstall is nothing but copying the package files to the machine and create the required short cuts which is created automatically during the MSI packaging. To get a package ready for the MSI upgrade you will need to uncomment and set the following parameters as follow in the package.ini and rebuild the package:

MSIProductVersion=1.0   <== Increase the version of the MSIProductVersion for every new upgrade so next one could be 1.0.1

MSIProductCode={xxxxxxxxxxxxxxxxxxxxxxx}

MSIUpgradeCode={xxxxxxxxxxxxxxxxxxxxxxx}  <== ensure the original package and the upgrade package share the same MSIUpgradeCode.

Below is a screenshot showing a sample of a package.ini for such a package

This mechanism work great for locally deployed ThinApp packages where the process can be enhanced using your current Electronic Software Distribution(ESD). This mechanism is suitable for both minor and major upgrades.

Note: If you don’t care to be in full control, you can skip manually editing the MSIProductCode and MSIUpgradeCode as if left alone (commented out) and only changing MSIProductVersion will work as long as your new package is based on the same project. ThinApp build process will handle the MSI properties..

Updating VMware ThinApp Packages Using sbmerge

Sometime after packaging your application you remember that small setting, update, patch, or plugin that you have forgot to package into your application. SBmerge.exe is the tool that can save you from having to redo the capture and build from scratch. It actually allow you to integrate these new changes with ease in your application. You just run your application, customize it, then sbmerge it and all the updates will be integrated in the package that you can then deploy using ESD or streaming to your end users. This method is suitable to install a plugin, small setting changes, small updates. Although it could be used for major updates, it can get the package to be more fluffy that I would like it to be when using it for major large upgrades. Below is the procedure of carrying out an sbmerge.

1. On the CnB Workstation backup the project folders & its contents of the application you want to upgrade using sbmerge.
2. Launch the ThinApp packaged application from the local copy of the project folder. Then close it.
3. Clear the sandbox by deleting the %APPDATA%\THINSTALL\<AppName> folder.
4. Update the application with the plug-ins, updates, settings, configurations , and modifications. Reboot the application/system as required by the applied updates
5. Ensure that your application is functioning as expected after the update, then close the application.
6. On the command line change directories into your project directory you are upgrading and type C:\Program Files\VMware\VMware ThinApp\sbmerge.exe apply
7. Check the %APPDATA%\Thinstall folder and make sure the <AppName> folder is removed as that indicate the success of the sbmerge operation.
8. Rebuild your project by re-running build.bat from the project folder to build the updated ThinApp Application.
9. Now you can distribute the package using In Place upgrade, MSI/ESD, or AppSync.

:

Updating VMware ThinApp Packages Using Relink.

Unlike other VMware ThinApp Mechanisms this update mechanism does not apply to the software you are packaging, but the Virtual OS(VOS) deployed within a ThinApp package. You might wonder why would this be required. Well, imagine if you have packaged hundreds of apps with VMware ThinApp 4.0.4 and then you required a feature that was only introduced in ThinApp 4.5(ex: running applications captured on XP on Windows 7 machines), relink will make it possible to upgrade your ThinApp package VOS to ThinApp 4.5 gaining all the new features of 4.5 without having to repeat the capture and build process from scratch. Relink make updating your ThinApp package VOS to the latest ThinApp version a breeze. Actually the relink process is as easy as drag and drop as shown in the procedure below:

- You can easily update the VOS of a ThinApp package to a newer one by dragging the entry point of it into the Relink.exe file in the ThinApp Installation folder.

- You can as well do multiple applications recursively by using the following command:  relink [-Recursive] <target> [<target> ...]

:

Updating VMware ThinApp Packages Using AppSync.

VMware ThinApp AppSync is mainly used to update VMware ThinApp packages over a WAN link. AppSync allow ThinApp packages to check for an updated version of the package on an http/https server or file server. If there is an updated version then the application only pull the difference. Though AppSync does not even stop you from replacing an application with a totally different one if you like to do that (lol replace IE package with Firefox for all of your users and watch their faces when their IE shortcut open up Firefox! Yeaha! Been there! Done that!). Let’s look on how to set it up.

- First of all you will need a webserver/fileserver that could serve .exe & .dat files (IIS & Apache work well for this purpose where IIS will require some tuning to allow it to server .exe & .dat files)

- Uncomment & modify the following lines in your package.ini as required

AppSyncURL=https://AppSyncwebsite/folder/ThinAppPackage.exe       <== This should point out to where you have the update package

AppSyncUpdateFrequency=0  <== This should tell the ThinApp package how often to check for updates. 0 means it will check for update every time the application is launched.

AppSyncExpirePeriod=0d        <== How long if the package did not check for update it will expire. Setting it to 0 will ensure the ThinApp package has to carry out any available update before running.

- Rebuild the package using the build.bat

- When ever you have an updated package put it on the same path you have setup in the AppSyncURL

- Now when ever you start the ThinApp Application it will download the updated package, though it will run the old one till the new package is downloaded where the new package will be run the next time the package start after the new package was fully downloaded unless you have setup AppSyncExpirePeriod=0d which will force the package to be upgraded before it will run when an update is available.

In case you might want to use a file server rather than an http server then the syntax of the AppSyncURL line will be as follow:

AppSyncURL=file://fileserver/share/folder/myapp.exe

Below is a screenshot of a sample package.ini  ThinApps Firefox package with AppSync enabled.

AppSync Tips:

• Both the original package and the new updated package must have AppSync activated.
• 
An Entry Point cannot have the same name as the Data Container, that might break AppSync as well (e.g. Mozilla Firefox.exe and Mozilla Firefox.dat).
• AppSync will run thinreg.exe on the new updated package if you place thinreg.exe in the AppSyncURL location.

:

VMware ThinApp AppSync update problems/trouble.

I have noticed many people has shared few common problems when using AppSync to update ThinApp packages and thought I will document those in here. One main problem that you will notice the update file coming up with 0 size and the package is never updated although you have done everything correctly. Below are three items to check:

1- Ensure that your webserver support all .exe & .dat files download. Test it manually and ensure you don’t get an error downloading these files from the webserver and do any modification required to allow that.

2- Try a different webserver. Two known webserver that I know for sure AppSync work with is IIS and Apache, where IIS require some modification to allow serving .exe and .dat files. I have tried before Xerver webserver at one client and that did not work for us. It might have required some modification, but we failed to get it working.

3- Ensure that the data-container name of the new package and the old package is exactly the same. As that how VMware ThinApp check if the package update is valid and for the same package or not. I believe this is one of things most people miss and not very well documented catch ya points.

Another complain I hear of ThinApp Admins is that they notice AppSyn is downloading the full package every time when monitoring their ThinApp package folder during update. This is more of a confusion than a problem. Although the files you see in the folder show the updates being downloaded to be of a similar size to the new package, this file was not totally downloaded but most of it constructed from the old package. The build process of the new package when done by AppSync is done as follow. The AppSync first download a hash file of the new package and compare it to the old one the blocks that has been updated it download it from the webserver, blocks which was not updated it just copy them from the local old package. Though it still end up constructing a full package size, most of the things it did not need to download but constructed from the earlier available package.

I hope this help every one find the ThinApp update mechanism that fit his fantasy in this post. If you have any questions or comments please leave it in the comments area below.

VMware ThinApp can be deployed using two main methods streaming or locally deployed. The main difference between the two methods is where the ThinApp Package will be executed from. In the streaming case the ThinApp package will reside on a shared folder, where users access it remotely. In the other hand when locally deploying ThinApp packages the ThinApp package is copied to each of the end point devices and executed locally. Each method can be deployed in few different ways, & has its pros & cons. Some companies rather streaming, some rather locally installed, where others mix and match between the two. Below is a closer look on each of the two main VMware ThinApp Deployment Scenarios.

:

VMware ThinApp Streaming.

In this scenario, the ThinApp executable packages will reside on a shared folder hosted by a windows file server or a storage filer where users access it remotely by accessing it directly by browsing the share folder to it or by a short cut created by the administrator or ThinReg to the executable. The beautiful part of ThinApp streaming that it does not require any specialized infrastructure like other Application Virtualization products in the market. All you require to be able to stream ThinApp Application is a file share where you put the executable and users access it from it. ThinApp Streaming is usually used in VMware View and other VDI scenarios and in environment where sufficient network and storage is available and centralized management/upgrade mechanism is desired.

Before going into each mechanism, its worth mentioning this post is a part of a larger VMware ThinApp series I am creating & below are the links to other VMware ThinApp posts in this series in case you were looking for one of these or interested to read about it as well.

The Magic of Application Virtualization with VMware ThinApp

VMware ThinApp Preparing the ThinApp Capture and Build Machine

VMware ThinApp Deployment Scenarios(This Post)

Updating VMware ThinApp Packages Mechanisms

VMware ThinAPP Antivirus Best Practices

VMware ThinApp Isolation Modes Explanation, Examples, & Video

Back to the VMware ThinApp Deployment Scenarios. Below are some advantages and disadvantages  of streaming ThinApp packages when compared with locally deploying it.

:

VMware ThinApp Streaming Advantages:

- VMware ThinApp allow centralized management as all packages are served from the same location

- In place upgrade/update to packages ease packages upgrades/updates without requiring any downtime.

:

VMware ThinApp Streaming Disadvantages:

- VMware ThinApp Streaming increase the importance of Network/storage availability. If your Network or storage is not available, your applications will not be available to your users.

- VMware ThinApp Streaming performance highly dependent on your network/storage performance. You will need to make sure that you have a sufficient storage/network that can deliver streamed packages without affecting your end user experience.

:

:

VMware ThinApp Locally deployed

In this scenario ThinApp Packages are deployed locally to each Endpoint. ThinApp packages can be deployed to Endpoint using many different methods. Electronic software
distribution (ESD) like MS SCCM, IBM Tivoli Software Distribution, Flexerasoftware and the same can be used to deploy ThinApp packages. Actually you can use the exact same methodology you have traditionally used to deploy your software packages through MSI, which mean you don’t have to change your method of deployment. That in turn reduce the cost other wise would have been spent on buying the new ESD as well training your team on using it. As an alternative methods, you could push the software to your end users through an Active Directory script where others like to give them to end users on a memory stick so they can use them on any machine they have access to. Each enterprise deploy the packages to their end point depending on their needs. Below are some of the advantages and disadvantages of locally deploying ThinApp packages.

:

VMware ThinApp locally deployed Advantages:

- As the packages deployed locally to the endpoint devices, availability of them is not dependent on Network/Storage or any other infrastructure component availability.

- The performance of locally deployed ThinApp packages more resemble traditionally installed application performance.

- They can be deployed utilizing the same mechanism used to deploy traditional software packages, which reduce training cost.

:

VMware ThinApp locally deployed disadvantages:

. Unlike streaming package management/updates/upgrades is decentralized though can be better managed through ESD software.

- Software will be required to be updated or replaced on each machine the packages was deployed to.

:

:

Which VMware ThinApp Deployment Scenario fit you environment?

Well, it depend on what you are doing. If you have an infrastructure that can handle streaming and you would like to have a centralized management/upgrade/update of your software packages then streaming can be your best choice. Else if your infrastructure can not handle streaming or you desire to still use the same deployment mechanism your team has been already trained on then the locally deployed mechanism could be your best choice. Further, the size of the application could govern which method you use as streaming large applications can overload your network if you don’t have the efficient bandwidth required. In most environments I have seen, they have mixed and matched between the two deployment methods based on their needs.

I hope this help you figure out which method you want to use to deploy your ThinApp packages, & I would love to hear your feedback of how you are currently doing it in your environment.

In a previous post( The Magic of Application Virtualization with VMware ThinApp), I have shown how to create a virtualized Mozilla FireFox using VMware ThinApp and how easy the process is. If you still not sure what ThinApp is or you just want a quick idea about how it works, then please make sure you read my previous post first( The Magic of Application Virtualization with VMware ThinApp). Though if you want to get a more optimized package then there is more guide lines to follow. In this post, I will document what you need to do to create a good machine to capture & build the ThinApp packages on. Following this article will help you build better ThinApp packages faster and give you a bit more repeatable results.

Before going into preparing the ThinApp Capture and Build machine details, its worth mentioning this post is a part of a larger VMware ThinApp series I am creating & below are the links to other VMware ThinApp posts in this series in case you were looking for one of these or interested to read about it as well.

The Magic of Application Virtualization with VMware ThinApp

VMware ThinApp Preparing the ThinApp Capture and Build Machine(This Post)

VMware ThinApp Deployment Scenarios

Updating VMware ThinApp Packages Mechanisms

VMware ThinAPP Antivirus Best Practices

VMware ThinApp Isolation Modes Explanation, Examples, & Video

Before talking about how to build and optimize your ThinApp Build and Capture machine (CnB), you will need to understand a bit more about the process of Application Virtualization with VMware ThinApp. The way VMware ThinApp build a Virtualized application is as follow:

1- ThinApp Capture the system before installing the application. It scan which files and registry records are there on the system before you installed your application

2- You install your application

3- ThinApp Capture the system after installing the application and figure out which new files and registery points has been created by your application and take that and package it in a single executable.

- Use a clean Vanilla install OS. Looking at the process above, you probably had figured out that the cleaner and closer to vanilla install the Windows machines you are creating your ThinApps on the better. The less junk you have installed on the machine the faster your pre-scan and post-scan will run, but that is not all to it. If you have an application dependency which was already installed on the system before the pre-capture process, this dependency will not be captured in the package which will cause your ThinApp Application to fail. For this its best to use a clean Vanilla Windows installed machine rather than a machine you have already installed a ton of stuff on. The less stuff installed on the machine the better. Actually you should only install the OS and Windows Security updates(No IE7/IE8 or media player or the similar updates to be installed, no other program or items upgrade to be installed). Don’t install Antivirus, firewall, Intrusion detection or prevention system on the VMware ThinApp Capture and Build machine as these can interrupt the success of the process. Actually beside the required Windows Security updates don’t install any thing unless if you are running on a Virtual machine then install VMware Tools or equivalent for the VM to function.

- Use the lowest OS utilized in your environment. To make the ThinApp package compatible with all the different Windows variation in your environment, you will need to capture it on the lowest version running in your environment. This seems to be Windows XP SP2 in most environments. Windows XP SP2 with Win Installer 3.1 is normally my choice for the Build and Capture machine where I will only install Windows Security updates to it(Again No IE7/IE8 or Media player to be installed from Windows update site as they are not required)

- Use a Virtual Machine for your Capture & Build Machine. Although you can build ThinApp packages using a physical PC, I would definitely recommend using a virtual machine. If you look at the previous point, you always want to capture your package on the cleanest and most Vanilla installed operating system possible. If you create one of these then install one application, when you want to package the next one you will want to be able to revert back to the earlier vanilla install OS state before the installation of the first application. Snapshots technology available in most Virtualization platforms(VMware Workstation, vSphere, & the same) make that task a breeze. You will only have to build your Capture and Build workstation once and make it ready with all the optimization required, then you take a snapshot. Build your package then all you have to do is revert to your snapshot to make the machine totally ready for packaging your next application rather than having to build the Capture and Build machine from scratch or use annoying imaging software to achieve the same  if you were to use a physical machine.

- Configure the system to Basic Behaviors. The below few Windows customization setting are highly recommended for your Capture and Build machine.

• Remove the Wallpaper & any screen saver used by the system
• Use Windows Classic Style
• Change Windows Visual effects to “Adjust for best performance”
• Disable Windows Firewall
• Disable Windows Updates
• Change your Folders settings to:

- Show Hidden Files & folders
- Unhide Extension for known file type
- Unhide protected operating system files

• Set Driver Signing to IGNORE for system (Recommended) (If using Windows 7) (Gpedit => user configuration => System => Driver Installation => Code Signature for Driver)
• Clear out all %TEMP%, C:\TEMP, C:\WINDOWS\TEMP, and other misc folders and Recycle Bin

- Shutdown the machine before taking snapshot. If you end up following the recommendation and use a virtual machine, then after preparing it and optimize it with the above settings and any desired settings its recommended to shutdown the VM prior to taking a snapshot as this will save you from having to snapshot memory as well ensure your machine is snapshot in a consistent state.

For those of you who already know ThinApp, this article might not be of a great interest though keep checking back as I am planning to write few more advance ThinApp articles in the upcoming days. If you have not heard of ThinApp or just heard a small whisper here and there about it or about Application Virtualization then keep reading. For some time I have thought everyone has heard of ThinApp, but after visiting few customers around as well talking to my friends at different large vendors I have discovered that ThinApp & Application Virtualization are still a hidden treasure.

For those who is familiar with VMware ThinApp, it is worth mentioning this post is a part of a VMware ThinApp posts series I am creating. Below are links to the rest of the series in case you are interested in other more in depth VMware ThinApp topic.

The Magic of Application Virtualization with VMware ThinApp(This Post)

VMware ThinApp Preparing the ThinApp Capture and Build Machine

VMware ThinApp Deployment Scenarios

Updating VMware ThinApp Packages Mechanisms

VMware ThinAPP Antivirus Best Practices

VMware ThinApp Isolation Modes Explanation, Examples, & Video

OK so before I talk about Application Virtualization & VMware ThinApp let’s ask few questions:

Have you ever wanted to take any application like Firefox, Chrome, MS Office with you on a thumb drive?

Have you ever wanted to run an older application at your newer Windows 7 machine & was hit by the error it was not supported or it did not work at all?

Have you ever wondered why you have to install applications rather than click on them and just run them?

Have you ever wanted to run two versions of Internet Explorer, Microsoft office, or any other application at the same machine?

Have you ever wonder why your PC was much faster when you just bought it than 6 months down the road?

If you answered any of the above with yes, then all you are looking for is the Magic of Application Virtualization which at VMware we call it VMware ThinApp. VMware ThinApp allow you to have your application encapsulated into a single executable file. Let’s take an example. Imagine that I can give you a file called firefox.exe and what ever machine you run that file on you will be able to access Mozilla FireFox browser on it without installing it. More fun imagine you can take that file with you on a thumb drive and run it on any Windows machine directly from your thumb drive without even copying it to that machine. Imagine you can put that same exe file into a share folder and allow multiple users to click it from their PCs and all of them get access to Mozilla FireFox browser without installing it or even copying it on their PCs. Imagine if I can do the same for most known applications like MS Office, Java, Adobe Acrobat, Chrome, Internet Explorer, and even in house developed applications. That is exactly what Application Virtualizaition and in particular ThinApp Allow you to do. What make it more fun, that creating these applications with ThinApp is much easier than most people would imagine. Further, as you don’t have to install these software to run them, you will not have to clutter your registry which is the main reason why your pc slow down with time. Yes, you can keep your PC run as fast as new for ever with ThinApp!!

Before talking about how you create a ThinApp Application, lets look at a video showing its usage.

Another Video I have created to show how you can run conflicting applications at the same time. In this video I show Internet Explorer 6 run aside with a Virtualized Internet Explorer 7, & Internet Explorer 8. Yeah crazy if you never heard of VMware ThinApp, but VMware ThinApp make it possible. You can repeat the same for office or any other application as well. Enjoy the video:

VMware ThinApp Creations Procedure:

Below are the steps on Creating a ThinApped version of your application:

1- Download ThinApp 4.7 from VMware Website from under products => VMware ThinApp => Download Trial. You might require a VMware account to do that, which only cost you a minute of a free registeration.
2- Install VMware ThinApp 4.7 on your machine which is straight forward and step by step is showing the video below.
3- Run VMware ThinApp Capture

4- Install the application you want to virtualize(Firefox in our example) just as you would install it on any other machine.
5- Run the VMware ThinApp Post Capture

6- Run the Build Package
7- Find your ready virtualized package under C:\Program Files\VMware\VMware ThinApp\Captures\firefox\bin
8- Run your package or take it with you on a thumb drive or put it on a share folder where many people can use it all at once.

Below is a video showing the process of building thinapped Firefox that was showing in the earlier video in this post. This video show the process in an easy step by step process and is completed in less than 10 minutes. Please note the same steps can be repeated to most applications available in the market today to obtain a portable Virtualized copy of these applications. Its important to remember this video was only meant to show the process as quickly and easily as possible without going into optimization & best practicees details which will be covered in future posts.

Happy ThinApping. And if you liked this post and videos please make sure you share it on what ever social media(twitter, facebook, digg, reddit, stumbleupon) you are on or at least leave me a comment below.

ThinApp Isolation Modes is one of the really nice settings that not many has explored. Most people who has built a ThinApp Package using the easy VMware ThinApp GUI will really not need to worry about changing the VMware ThinApp Isolation Mode in the Package.ini as the ThinApp packager GUI ask you if you want to allow the thinapped application to write to folders and files out on the physical file system the ThinApp application run on or not allow it to. What is happening in the background is that the GUI is just changing the Isolation mode in the background.

Before going into Isolation Modes, its worth mentioning this post is a part of a larger VMware ThinApp series I am creating & below are the links to other VMware ThinApp posts in this series in case you were looking for one of these or interested to read about it as well.

The Magic of Application Virtualization with VMware ThinApp

VMware ThinApp Preparing the ThinApp Capture and Build Machine

VMware ThinApp Deployment Scenarios

Updating VMware ThinApp Packages Mechanisms

VMware ThinAPP Antivirus Best Practices

VMware ThinApp Isolation Modes Explanation, Examples, & Video(This Post)

Back to VMware ThinApp Isolation Modes. OK, so if I am saying the default option is normally more than enough and we already know how to use that what is the point of this post. This post is to show the extra modes & usage cases for them. Few days back one of my friends (Customer at the same time) had a tough requirements of his management for a ThinApped application. He is presenting an application through ThinApp to many users in his organization, where this application was originally written where a user can actually export the report to a file as well import data. Originally the way the application worked was not a problem for him, as the type of employee who had accessed to the application was highly restricted and they needed to be able to import and export files. Now the bank my friend work for wanted to start offering the same application to other type of users, but they want to ensure that they only can display the data, but can not import or export it from the system and they wanted to avoid having to rewrite the application or have to develop a second versions without the import and export feature. The solution was easy. All he had to do is just ThinApp the application with Full Isolation Mode which will not allow the ThinApped Application to read or write to files/registery on the physical system. I don’t see these cases everyday, but I see them often in banks and other firms with higher security concerns. So below is a quick simplified explanation of the VMware ThinAPP Isolation Modes:

- Merged: Allow both read and write to files & registery on the host system. (A good mode if your application need to write to files or registery on the system EX: Microsoft Office)

- WriteCopy: Allow only read of files & registery of the physical system, but not write to it. The write will be done to files in the sandbox of the application, where these files only exist when you run the application (A good mode for applications which only need to read host system files/registery, but not write to them.)

- Full: It means its fully isolated where it can not write or read to files & registery on the host system, but it will only read and write to virtual files that only exist in the sandbox of the application itself and only accessible through the application when you run it (Just like our friend application for the bank discussed above).

Further, the two modes you choose from in the ThinApp Capture GUI are as follow:

- Modified Merged isolation mode

The default file system isolation mode in the Setup Capture wizard is Full write access, or modified Merged.

The modified Merged isolation mode in the Setup Capture wizard allows users to write to any directory except for specified system directories. This is recommended for applications that you trust.

OK, so if you want one of the modified modes then you can do that through the GUI but if you need one of the other ThinAPP Isolation Modes then you will need to change it directly in the Package.ini file. An example of the Syntax is below: