For the IT worker, the phrase “desktop mobility” has many meanings. It can mean having a laptop computer. It can mean keeping all your data in the cloud so that you can access it at any time and from anywhere. It can even mean downsizing your work environment to fit on a PDA or a smartphone.
In each of these cases, a common denominator still applies: the need to carry with you one or more devices with which to access your applications and data. However, with the emergence of virtualization technology, it is now possible to take your complete working environment with you — including all of your applications and data — on something as small as a USB stick.
The idea of a mobile virtual machine is not new. Both VMware and Microsoft (via its acquisition of Kidaro) have been promoting this model for some time. What’s different today is that you can achieve many of the same goals — machine independence, the ability to conduct business travel sans laptop — without resorting to the often limiting confines of a VM.
Thanks to the magic of application virtualization, you can now place all of your key work-related programs and data onto a portable device and access them directly from any Windows-based desktop, with the full fidelity and performance of the local machine. It’s the ideal solution for situations where a zero-footprint runtime scenario is required, such as using a kiosk PC in a hotel lobby or working at a locked-down desktop in a secure environment.
Of course, to create virtualized applications, you need an application virtualization solution. For the enterprise, that means either Microsoft Application Virtualization (formerly SoftGrid), Symantec SVS Pro (formerly Altiris), or VMware ThinApp (formerly Thinstall).
Microsoft’s solution is free to Microsoft Software Assurance Program customers. Even better, Symantec SVS is free for personal use. Unfortunately, the solution best suited for extreme mobility scenarios, ThinApp, is the most difficult to come by — at a starting price of $6,050 for 50 client licenses.
In this article, I’ll show you how to build a fully functional, virtualized environment that runs from a USB key or portable hard disk, requires no software installation of any kind on the hosting client PC, and leaves no trace once you’ve disconnected your media.
When you consider the possibilities for true device independence, not to mention the obvious advantages during a disaster-recovery scenario, I think you’ll agree that application virtualization can and should be a key factor in any enterprise’s long-term mobile computing strategy.
Fun in the sand
It all begins in the sandbox. Incorporating concepts pioneered years ago by distributed computing enthusiasts, application virtualization uses sandboxing to isolate changes made by a running application and redirect them to a specific, reserved area of the local file system.
The first step is capturing the application’s installation procedure. Often referred to as “sequencing,” the process typically involves some form of wrapper utility that invokes a virtualization layer (usually a file system redirector with some additional monitoring components) and then prompts you to execute the application’s installer.
As the installation proceeds, the sequencing utility records the changes it makes to the system and builds a virtual map of what needs to go where — in the file system and Registry — in order for the application to execute. This map is then used to splice in the now virtualized application components at runtime to create the illusion that the application is properly installed, thus allowing it to execute normally.
Once the application has been sequenced, all further instances of it execute within the virtualization layer, where any additional changes — for example, modifying options or otherwise personalizing the application — continue to be sandboxed and redirected to the reserved storage.
Depending on the level of isolation provided by the application virtualization platform, this sandboxing process can capture some or all changes made by the application, merging them with the local file system at runtime. A good example would be a word processor — the document you save to the local disk might be allowed to pass through the virtualization layer, while changes to the spell-checking or auto-formatting options would typically be redirected to the application’s private sandbox.
It’s this combination of sequencing and redirecting subsequent changes to the sandbox that makes application virtualization so attractive from a mobile computing standpoint. Because the application runs within the virtualization layer, the components it requires and the changes it makes to them at runtime are isolated from the underlying host system.
Add to this the potential sandboxing of personalization changes (and in some cases, data files generated by the application) and you begin to see how this could provide a mobile user newfound flexibility. With everything kept together in the application’s sandbox, you can literally move from system to system, plugging and unplugging your workspace as you go.
Such an approach — using application virtualization to isolate and abstract the workspace from the host system — has a number of natural advantages over the more familiar virtual machine model. For starters, there’s less overhead. Though virtualized in terms of its interaction with specific files and shared resources (such as the Registry), a sandboxed application still executes natively as if it were any other locally installed application.
This means that the application runs with the full performance and fidelity of the local machine, including access to hardware resources such as printers, faxes, and even acceleration via DirectX. It also means that the application can be configured to leverage existing shared libraries — for example, a sandboxed .Net application being able to access a locally installed (that is, not sandboxed) copy of the .Net framework.
By contrast, a VM-based workspace incurs an immediate performance penalty simply because the virtualization layer is much deeper and must host an entire operating system along with the desired application. Anything that the application requires — drivers, frameworks, shared libraries — must be installed within the VM, adding to its memory requirements and disk footprint.
And unlike sandboxed applications, VM-hosted applications don’t reap the benefits of local hardware acceleration, except in the rare case of VMware Workstation, which achieved support for hardware acceleration only recently.
The ultimate argument, however, in favor of sandboxing over VM hosting has to be the raw simplicity of deployment. With a sandboxed application, in most cases you simply launch an executable file and start working. With a VM, you need to install, at minimum, some kind of playback application and then hope that its various pass-through mechanisms support the local hardware environment.
If the PC is memory constrained or if you don’t have permission to install software (the kiosk/locked-down desktop scenario I noted earlier), you may be out of luck. Sandboxing overcomes this hurdle. Few Windows PCs will have trouble loading a simple executable file — assuming, of course, you can attach your portable media to the system.
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).
Build your castles in the sand
My extreme app-v scenario is a great start, but still far from perfect. For example, some applications still freak out when I move from XP to Vista (Outlook, I’m talking to you). Others exhibit unusual quirks, like the time I tried to virtualized Internet Explorer 7.0 only to discover that the finished executable couldn’t recognize a typed URL in the address bar (though bookmarks seemed to work fine).
So the machine-independent lifestyle isn’t without its glitches. However, when I contrast the prospect of working around a few quirks against the advantages of leaving my eight-pound XPS “notebrick” at home on Mauritius during my next 30-plus-hour trek back to the United States, I’ll take the quirks any day. There’s something poetic about the idea of having my whole world in the palm of my hand. Or is it in my right pants pocket? Coat pocket? Tucked into my sunglasses case? Oh, who cares — I’m free!
