Many Many Many time I have been called to diagnose a VMware ThinApp problem specially VMware ThinApp package slowness and all it end up to be nothing more than a problem being caused by an antivirus or anti-malware software that has not been configured according to VMware ThinApp Antivirus best practices. Ah I can see already few of you are shocked there is such a thing out there! OK, now I have told you there is best practices for Antivirus configuration in a VMware ThinApp environment I will go ahead and explain them and where they apply.
Before going into VMware ThinApp Antivirus Best Practices, 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 articles in this series in case you are interested in other VMware ThinApp topic.
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(This Post)
VMware ThinApp Isolation Modes Explanation, Examples, & Video
Let’s get back to VMware ThinApp Antivirus Best Practices. In fact the best practice antivirus policy related to ThinApp deployment is different for each stage your ThinApp package go through. Below are these best practices per stage or location.
- Capture & Build Workstation (CnB): The Capture & Build workstation is the machine where you Capture and Build your VMware ThinApp packages. The best practice is not to have an Antivirus, Anti-Malware or any such product installed on CnB workstation at all. The reason behind that is having an Antivirus on the Capture and Build Workstation can complicate & slow down the Capture & Build process. In some cases it even can cause it to fail or cause the package to become mush more bulkier than it need to. If your company policy is that you have to have an Antivirus software on the Capture & Build Workstation, then make sure you at least disable it during the Capture & Build process.
- ThinApp Project Repository (Shares used for storing ThinApp projects). These are the Repositories/shares that host your ThinApp project folders after the build has been completed. As these are not used to build or serve ThinApp packages to the end-user, having real-time scan on read & write events will not hurt. There for on this one you can keep your normal real-time scan on read & write events scan in place. The main change you would want to ensure on this one is to schedule the on demand scan during non-peak hours. Having real time scan both on read and write running on the ThinApp Project Repository will ensure that your final .exe, .dat, & .msi files are clean and safe to use.
- Locally Installed/Deployed ThinApp Applications. VMware ThinAPP Applications can be deployed locally where it reside on the end user machine. This method usually used when the customer does not have the network infrastructure to handle streaming or if he want to be able to still run the packages offline or when the network is not available. The recommended antivirus policy for such deployment is to enable Anti-virus real-time scan on write events only but not on reads as enabling on read can slow it down dramatically. Further, on demand scan should be scheduled off-peak hours. This policy make sense as usually you would not get infected on a read operation, but on write operation where your packages that being executed now has already been scanned when it was hosted on the ThinApp Project Repository which ensure you are not reading/executing anything but virus clean packages from this location.
- ThinApp Repository (Shares used for accessing applications). The shares serving VMware ThinApp applications to end users should be real-time scanned on write events only, but not on read. Further, on-demand scan should be scheduled off peak hours to prevent VMware ThinApp package execution slowness.
- User Sandbox. When users use ThinApp Application package, any changes made to the application by the user (customization, bookmarks, updates, …) are stored in a location called Sandbox. The default location for the user sandbox is in the user profile. User profile could be stored locally on the machine the user is using or on a centralized share folder to maintain persona. Its different from an organization to another, though the recommended antivirus practice for it is to enable real time scan for write events only, but not on read as that can slow the application dramatically or even cause it to crash in case it write a huge amount of stuff to the sandbox. Some VMware ThinApp packages that write a large amount of data to the sandbox(not a best practice) performance could still be affected by the on write event only real-time antivirus scan, where you might have to excluded it from that as well and just schedule on-demand scan off peak hours. Make sure in all cases that your on-demand scan is running off-peak hours as well.
While many admins ignore the impact of Antivirus configuration in ThinApp environment, it has been proven over and over again the importance of it on how well the packages was build and how it perform. Therefore if you are administrating VMware ThinApp packages, then you might want to try to follow these Antivirus best practices for ThinApp environment as closely as possible.
I hope this help, & as usual please share your thought and questions in the comment area below.
I’m using a clean install of windows 7 Ultimate 64 bit with the latest build of Thinapp 5.1.0-2079447. How do you disable windows defender? I see that in the write mode as an error! I also see a lot of other stuff being imported into the project folder e.g. from the windows directory etc. Is there anything I can add to the Package.ini in the [Buildoptions] to not add to the project?
Since windows XP is no longer supported by Microsoft it will be difficult to do any type of work with Thinapp on that version of windows.
I’d like to really see some tweaks in the Package.ini which can be added to make the Thinapp package smaller and run faster etc.
One thing I see works for me in the;
[Compression]
CompressionType=Fast
OptimizeFor=Disk
[FileList]
ExcludePattern=*.bak,*.msi,*.mst,*.cab,*.msp
The above works for me in terms of compression and making the file smaller.
[Buildoptions]
AutoShutdownServices=1
DisableTracing=1
AutoStartServices=0
The above is some other tweaks I added to the Buildoptions.
And removing the following items from the list in the Package.ini also helps to make the file smaller.
AnsiCodePage=1252
LocaleIdentifier=1033
Thanks in advanced.