Throughout the past couple of years, I have written extensively on MED-V v1.0. Now that version 2 of MED-V has been released, many experienced users of MED-V are discovering that while it achieves the same results as version 1.0, there are significant architectural changes as well as operational changes that can be confusing at first if you are unaware of the paradigm shifts. By now, many of you have been able to read and/or experience some of the new features introduced with MED-V v2 including the following:
· Automatic Folder Integration
· USB/Smart Card Redirection
· Dynamic Application Publishing
· Enhanced SCCM Integration
· Shared VHD Support
· Guest Wake-to-Patch
· WMI Monitoring
· Network Printer Synchronization
MED-V v2 is more than just an introduction of new features. If you have previous experience testing or surveying MED-V or currently have a MED-V 1.0 deployment and you are thinking about version 2, please pay close attention to the following changes that are in place for version 2.
The following table lists the differences between the installable components available between versions 1 and 2 of MED-V.
MED-V Policy Server
Image Distribution Server
MED-V Host Agent
MED-V Workspace (Manually Installed)
MED-V Guest Agent (Auto-installed)
VM Preparation Tool
MED-V Workspace Packager
MED-V Management Console
MED-V Toolkit (via the MED-V Host Agent)
In addition to the installable component differences, there are many more paradigm shifts in the positioning, deployment, architectural, and management options of MED-V as well as product improvements.
Client Host Operating System Support
MED-V 2.0 is positioned exclusively as an AOSC (application-to-operating-system compatibility) solution for Windows 7. The sole host operating system supported for the MED-V client agent is Windows 7 and the sole guest operating system support for the workspace is Windows XP.
Virtual PC Engine
MED-V v2 is built upon many of the technologies introduced with Windows Virtual PC (also known as VPC7.) These technologies leverage strong application publishing and presentation virtualization technologies (RDP/RemoteApp) that operate very efficiently and allow the components of MED-V to be significantly streamlined. For this reason, the VPC 2007 (VPC6) engine is not supported by MED-V v2. Given that Windows Virtual PC runs on non-HAV machines now, this makes MED-V v2 even more of a flexible option for a variety of hardware.
Full Desktop Mode
Unlike MED-V v1, where the virtual machine was encrypted and not usable outside of MED-V, the virtual machine in MED-V v2 is unencrypted. The concept of MED-V v2 Full Desktop mode is to actually launch the virtual machine from within the Virtual PC window in the Windows 7 Explorer.
Web redirection is more enhanced in v2 with regards to the flexibility of the URL format. Wildcards, in-page browsing, as well as page-based redirection are supported. This goes for all http:// redirections however; redirection is only host to guest (one-way) in v2.
Integrated Image Distribution
Revertible workspaces, TrimTransfer, and Image Distribution Servers are gone in MED-V v2. The packaging model is different where the image and its corresponding policy are packaged together using standard compression with an installable wrapper. This allows for flexible deployment options including electronic software distribution mechanisms, interactive installation via EXE/MSI, or even through custom PowerShell Cmdlets.
With the MED-V Server component gone in v2, the policy which governs how the MED-V workspace is configured (URL redirection, networking mode, memory configuration, etc.) comes directly from the registry and can be managed indirectly via group policy and/or WMI. The policy is simultaneously pre-staged and packaged with the image using the MED-V Workspace Packager.
Foundations of Application Publishing and Seamless Integration in V2
MED-V version 1 leveraged Kidaro’s foundation technologies to provide for application publishing to the host and seamless integration of the virtual machine’s application experience. This was necessary in version 1 because the underlying Virtual PC 2007 engine (VPC6) did not have a mechanism for application publishing. This changed with Windows Virtual PC in Windows 7. The key technology that enables application publishing and seamless integration support in VPC 7 is commonly referred to as RAIL (Remote Applications Installed Locally). This is the same technology that is used in Remote Desktop Services in Windows Server 2008 and beyond to enable RemoteApps (Remote Applications). RemoteApps are applications that are installed and executed on a Terminal Server or Remote Desktop Session Host Server, but are integrated with the Remote Desktop client machine in a way that makes them appear to be running locally on the client. Instead of launching an application with KidaroCommands.exe, the application is launched by the VMSAL.EXE process and hosted by the RDPSHELL.exe shell process on the guest virtual machine.
The Workspace Packager
The Workspace Packager is also the replacement for the management console as it allows changes to certain workspace configuration parameters if it is already installed on the machine. Since the policy no longer comes from a server source, there is no server to manage.
Steve Thomas | Senior Support Escalation Engineer
The App-V Team blog: http://blogs.technet.com/appv/ The WSUS Support Team blog: http://blogs.technet.com/sus/ The SCMDM Support Team blog: http://blogs.technet.com/mdm/ The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/ The SCVMM Team blog: http://blogs.technet.com/scvmm/ The MED-V Team blog: http://blogs.technet.com/medv/ The DPM Team blog: http://blogs.technet.com/dpm/ The OOB Support Team blog: http://blogs.technet.com/oob/ The Opalis Team blog: http://blogs.technet.com/opalis The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager The AVIcode Team blog: http: http://blogs.technet.com/b/avicode The System Center Essentials Team blog: http: http://blogs.technet.com/b/systemcenteressentials
Will workspace (guest agent) image/vhd reversion ever make a comeback? The ability to restore a MED-V image to it's original state has made V1 a great Internet Isolation/sandbox security product. In addition we never have to worry about guest agent tampering/stability. Without it, we lost the driver for our distribution to our Enterprise. We've been beta testing MED-V for 3 years and every feature we've requested was added to V2 and the only feature that made the product desirable (for us) has been removed.
I agree with above. This feature alone was one of the only reasons for deployment of Med-V. Great for security in a Law Enforcement arena.
To the 2 commenters above, you can use the Med-V administration Toolkit (start by running C:\Program Files\Microsoft Enterprise Desktop Virtualization\MedvHost.exe /toolkit on the client) and either Reset or Rebuild the Workspace. Rebuilding the Workspace will bring it back to it's original state.
The Wake up parms GuestUpdateTime and GuestUpdateDuration work when a user is logged on, How do you send patches to the vhd when the windows 7 user is logged off?