Leave the Laptop Behind

Time to Hit the Beach

One area where VM-based solutions hold an edge over application virtualization is in the initial setup process. Whereas installing an application into a VM is typically the same process as installing it on a physical machine, effective sandboxing takes some trial and error, especially when you're attempting to capture and virtualize multiple applications.

In my case, it took a little over a week of testing, tuning, and tweaking to get my fully functional mobile workspace purring just right. This included multiple aborted attempts at capturing applications where something -- a missing library, a hidden encryption layer -- tripped me up. The .Net Framework 3.5, in particular, was a tricky one because the virtualization software I was using -- VMware's ThinApp -- kept creating too many entry points into the package. I fixed this by combining everything in a single executable: DW20.exe.

Speaking of virtualization software, I evaluated the current state of the art from all three of the leading app-v providers -- Microsoft, Symantec, and VMware -- and ended up settling on ThinApp for three main reasons.

First, ThinApp doesn't require an agent. While not so much an issue for corporate deployments, the agent requirement for Microsoft Application Virtualization and Symantec SVS made them no-goes for my extreme hardware-independent mobile computing scenario. As in the hotel kiosk scenario, there are just too many situations in which you will not be allowed to install a custom agent on the borrowed PC. This is especially true in locked-down computing environments where the idea of installing a bunch of foreign kernel mode components onto a sensitive system is about as acceptable as surfing porn at your desktop during lunch.

Second, ThinApp is platform/version/architecture independent. The entire ThinApp virtualization layer is contained within the sequenced executable. It runs entirely in user mode like a normal application, and this, in turn, allows a ThinApp-hosted application to execute unmodified across multiple Windows versions. It's also the only current solution that supports x64 versions of Windows, a fact that once again rules out its 32-bit-only competitors.

The third reason is sheer simplicity. The ThinApp capture process is by far the most intuitive of the bunch (though SVS is a close second). I was able to successfully capture most applications on the first try, and working with the capture data is easy because it is all stored in folders on the capture machine's local disk.

Using a combination of ThinApp and VMware Workstation 6.5 Beta, I was able to construct a comprehensive mobile workspace that served my requirements for productivity, development, and online research. Included in the mix was Microsoft Office 2007, Microsoft Visual Basic 2008 and Visual Web Developer 2008 (the Express Editions), Firefox 3.01, and Windows Live Writer (for maintaining my Enterprise Desktop and Windows Sentinel blogs).

Visual Studio 2008 was, by far, the most difficult to virtualize. For starters, the commercial version proved impossible to encode due to some sneaky encrypted shenanigans on the part of the Visual Studio installer. My solution was to fall back to the free Express version. Although far from ideal, Visual Studio 2008 Express would at least provide me with an IDE in which to debug my ASP.Net code.

All of these applications were stored together in a single folder structure on a 250GB Western Digital portable USB hard disk. Total space consumed: 2.5GB. (Try that with a VM!) Launching the applications was a simple matter of navigating to the correct folder and double-clicking the program's icon. No other setup was required, and the initial application load time was uniformly excellent -- certainly faster than launching a full-blown VM and light-years ahead of installing the applications locally.

I can offer a few other tips and techniques to make the journey more bearable:

Use volume licenses where possible. Microsoft Office, in particular, is a pain due to its product activation logic, which, despite being sandboxed, insists on running each time you move to a new system. A volume license key does the trick by suppressing the activation routines. Just be sure to enter it at the first screen of the installer during the capture process.

Create an alternative entry point for maintenance. A virtualized application runs within its own isolated environment. As a result, configuring and maintaining components that exist within the environment but are accessible only from outside the primary application's UI can be challenging. That's why I recommend adding a back door into the virtualization layer, typically by including a copy of the Windows Command Processor (CMD.EXE) as part of the virtualized image. I can then launch this virtual command line and make changes to objects that are stored within the sandbox -- for example, adding/removing add-ons for my virtualized copy of Firefox. And because the installer is running within the sandbox, the add-on stays with my application as I move from system to system.

Use VMs to test new sandbox configurations. When it comes to trial-and-error development, a good Virtual Machine Manger is your best friend. The ability to roll back changes made to a VM disk image is a godsend when prototyping new virtualization scenarios. I typically keep two separate pristine snapshots on hand under VMware Workstation. One includes the base OS and the ThinApp Setup Capture utility; the second has ThinApp and the .Net framework installed (for applications that require .Net in order to install).