eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
VMware’s ThinApp 4, the first version to ship since VMware acquired Thinstall in January 2008, can, if properly configured, make life easier for IT administrators by easing Windows software conflicts through the magic of application virtualization.
Where desktop virtualization involves hosting entire desktops, from virtual hardware straight through to operating systems and applications, products such as ThinApp eliminate application conflicts in Windows systems by isolating application files and registry settings on standard Windows clients. As a result, application virtualization is better distributed and more offline-friendly than centralized, server-hosted desktop virtualization, and requires less overhead than do locally run, PC-based desktop virtualization solutions.
VMware ThinApp and competitive products, including the beta version of Microsoft Application Virtualization 4.5 and Altiris SVS (Software Virtualization Solution), differ significantly from regular application packaging tools in that they can stream an application package to a sandbox that they create on the end-user system so that the application executes without interfering with other programs that may already be installed.
For the most part, ThinApp performs its core application virtualization role effectively, by virtue of an efficient application packaging mechanism and distribution system that makes virtualized applications available to end users from a network share or USB drive. Once I got the system up and running, VMware ThinApp did a good job of distributing applications without the need to perform extensive regression testing to check for conflicts with other applications (or even older versions of the same product).
However, in eWEEK Labs’ tests, proper configuration proved more challenging than it should have been. In particular, I found ThinApp 4’s impressive new AppSync application update features impaired by a clumsy user interface and lacking in good documentation. Many of my VMware ThinApp test problems could be rectified with a couple of pages of documentation. Assuming that these omissions are corrected, desktop administrators should put VMware ThinApp on the short list of application virtualization tools to consider.
VMware ThinApp was released on June 10, costs $5,000 for the server and includes a copy of VMware Workstation, which is handy for creating the clean clients needed for application preparation, and 50 client licenses. Additional client licenses are $39 per endpoint.
VMware ThinApp in Action
My VMware ThinApp test environment consisted of a VMware Workstation installation made up of two Windows XP Service Pack 3 systems and one Windows 2003 server. The server hosted Microsoft’s IIS (Internet Information Services) and served as my update Web site. One of the Windows XP systems was my clean build system where I used VMware ThinApp to prepare my test applications (WinZip, Firefox and Microsoft Office 2003). The other system was my installation target.
The basic process I used for deploying Windows applications using ThinApp should be familiar to anyone who has used application packaging products in the last 10 years. Starting with a clean install of the Windows OS that matches one’s production image, and using equipment that closely approximates one’s installed hardware inventory, a desktop administrator uses ThinApp to take a snapshot of the registry, DLLs and other files on the clean system.
After completing this step on one of my test systems, I installed the application I wished to virtualize (I tested with WinZip, with Firefox and with Office 2003) and then allowed VMware ThinApp to capture the differences. ThinApp then packaged these differences, along with some ThinApp-specific client software, into either an .msi or an .exe that I could deploy to my test clients.
After I created my packages, I edited the .ini files associated with each package to direct them to a Web server on my network every minute for updates to the package. Be aware that any autoupdate feature in an application should be disabled as it will likely interfere with VMware ThinApp’s attempts to keep product versions up to date.
VMware ThinApp was able to create an executable version of each of these applications that checked for updates, successfully installed the delta between the two versions and executed the updated version of the all three test products on my end-user systems.
App-Sinking
The trick to getting this working was navigating the setup vagaries of AppSync, the new feature through which application packages check for updates, and through which these updates stream down to their intended clients. As implemented today, desktop managers should tack on at least several days of consulting to get VMware ThinApp 4 working correctly, or wait for VMware to smooth out the wrinkles before deploying.
The documentation for AppSync is quite sparse and in many cases incomplete. I spent several hours over a period of days on the phone with VMware staff trying to figure out why my test applications weren’t updating.
It turned out that the .ini file associated with the older version of the test application must match the .ini file of the upgraded version of the application. This is not documented. The reasoning makes sense. In order to assure that the user gets the correct update, VMware ThinApp checks both .inis for a match. This does mean that desktop administrators will have to remember to retain the same name when preparing future application packages.
Undocumented behaviors aside, the product’s AppSync functionality is exposed through a weak UI. Doctoring the .ini files means editing text files by hand to make a series of changes to indicate the location of the update file, the update-checking frequency and the optional warning message to display in case updates go awry. VMware officials told me that an improved configuration UI is being considered for a future update to the product.
Also problematic is the lack of a central console to show desktop administrators which end-user systems have been updated and, more importantly, which update attempts have failed. I would also like to see a central policy administration mechanism for determining the update frequency and license status of deployed ThinApp packages.
Finally, VMware ThinApp requires a Web server to distribute AppSync updates to users but provides no information on how to set up this functionality. Other VMware products that rely on Web-accessible components, such as VMware’s Virtual Center, should serve as a model for future ThinApp development. In the meantime, desktop administrators may have to seek out the help of their Web development cohorts to complete the setup of AppSync.
eWEEK Labs Technical Director Cameron Sturdevant can be reached at csturdevant@eweek.com.
