A cure for Vista's compatibility blues

Microsoft Enterprise Desktop Virtualization, or MED-V, is the productized version of technology the company obtained through its acquisition of Kidaro in 2007. Slated to ship in the second quarter as part of the Microsoft Desktop Optimization Pack (MDOP) 2009, MED-V provides customers who subscribe to Microsoft's Software Assurance program with a means to integrate legacy Windows applications with the current generation of Vista-based desktop operating systems, including Windows 7.

MED-V accomplishes this by enhancing and extending the virtual machine environment of the company's Virtual PC 2007 product. On the server side, MED-V provides a set of centralized VM image management tools as well as tight integration with Microsoft Active Directory. On the client side, MED-V adds various layers of centrally manageable end-user access controls and authentication mechanisms, plus the capability to run virtualized guest OS applications seamlessly alongside native executables.

[ VMware Workstation is the Test Center's 2009 Technology of the Year award winner for desktop virtualization. See "Virtualization showdown: VMware Workstation vs. Sun xVM VirtualBox. " ]

When I first reviewed MED-V's predecessor, Kidaro Managed Workspace, I found the product to be a compelling solution that could mitigate some of the more common deployment hurdles associated with virtual desktop technology. Since the acquisition, Microsoft has dropped the product's support for VMware images (Kidaro originally supported both Microsoft and VMware VM formats) and refocused the product on delivering legacy application compatibility services to Windows Vista clients.

Virtual PC inside

This latter point is evidenced by the limited selection of guest OS images supported: Windows XP with Service Pack 2 or 3, or Windows 2000 with Service Pack 4. I expect this list will grow to include Windows Vista somewhere down the road, but for now such a configuration isn't supported. Nor does MED-V support any 64-bit guest configurations, a product of its reliance on the anemic, 32-bit-only Virtual PC 2007 as its underlying VM environment.

In fact, if there's an Achilles' heel to MED-V, it's the Virtual PC engine running behind the scenes. Slow and buggy, Virtual PC is unsuitable for all but the lightest of application workloads. It's also a bit dated in the hardware emulation department, with no support for multiple CPUs or even USB devices. This, in turn, can limit a virtualized application's integration with the host OS: If the application can't see that USB-connected drive or dongle, then it may not be able to function properly or, in extreme cases, to run at all. With the Kidaro Managed Workspace product, you had the option of using VMware's more capable runtime engine to host your images. Now that this capability is gone in MED-V, the overall usefulness of the solution has been significantly diminished.

Still, if your needs are modest -- running a legacy accounting package or providing virtualized access to a previous version of Microsoft Office -- then MED-V fits the bill. And regardless of which runtime engine Microsoft uses, MED-V still delivers the rest of what made the Kidaro product so compelling, including the much lauded Trim Transfer technology.

Provisioning VMs

Trim Transfer minimizes the network overhead associated with deploying VM images by first indexing the contents of the client system and then reusing the client-side copies of any common components (DLLs, executables, help files) to dynamically assemble the VM. Depending on how much the VM and host system have in common, this can dramatically reduce the number of blocks the MED-V client needs to download from the server -- a big deal for IT shops with lots of WAN links or otherwise overburdened networks.

I tested the Beta version of MED-V under Windows Server 2008 and Windows Vista. Installation of the server-side components was straightforward, though some of the steps -- such as creating a SQL Database for collecting logging data and manually configuring the MED-V Virtual Directory in Internet Information Services -- could have been automated.

Otherwise, the product worked much like its Kidaro predecessor. I began by creating a baseline VM image, then provisioned it for deployment by specifying various lockdown options (such as blocking clipboard support or access to local drives) and defining the access control list through Active Directory. After that, it was a simple matter of copying the VM image to a shared repository folder and accessing it via IIS and the MED-V client running on Vista.

Overall, MED-V worked as advertised, which is to say that it provided me with a simple way to integrate legacy Windows applications with more modern incarnations of Microsoft's desktop flagship. In fact, my only real complaint about MED-V -- aside from its shaky Virtual PC underpinnings -- is that it isn't part of the core Windows OS. Bottom line: The MED-V management console makes it easy to provision new workspace images for deployment, and seamless integration between MED-V and the Vista host allows users to run virtualized applications as if they were executing locally.

V for all

It's a sad truth that Windows Vista was rejected by IT primarily because it broke so many legacy applications. User Account Control, combined with the inevitable tweaks to various common libraries and kernel resources, has tripped up more than a few Windows XP and pre-XP holdovers. By squirreling away MED-V and its MDOP sibling, APP-V, as part of an exclusive package for volume customers, Microsoft is denying vital relief to the broader community of Windows users, many of whom have stuck with the platform despite the myriad compatibility hurdles such loyalty has engendered. These shops deserve a break, and forcing them to sign up for an expensive and restrictive site licensing program in order to preserve their legacy investments, even as they actively embraced the Windows Vista party line, is simply unfair.

In the end, I'd like to see Microsoft open up MDOP to the public or, at the very least, to make the client portions of APP-V and MED-V available to the great unwashed masses. In my Enterprise Desktop blog, I've called for Microsoft to leverage these two technologies to create a much needed compatibility layer for the next version of Windows, one that would enable the company to move away from the mishmash of legacy Win32 and managed .Net runtimes that plague the current environment. MED-V is a big part of that vision, a fallback solution for those applications that cannot be properly virtualized through file system and Registry redirection alone.

If Microsoft opens up APP-V and MED-V, it'll go a long way toward healing the enterprise IT rift it created with the whole Windows Vista debacle. MED-V is an important technology -- too important to hold out as a carrot for its exclusive volume license customers. Here's hoping that Microsoft does the right thing by making its virtualization technology available to everyone.

This story, "A cure for Vista's compatibility blues" was originally published by InfoWorld.