Leave the laptop behind
Application virtualization can make your mobile workforce truly machine independent. Here's how.
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).