MED-V V2: Charting the changes
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.
General Component Differences between V1 and V2
The following table lists the differences between the installable components available between versions 1 and 2 of MED-V.
Component |
MED-V V1 |
MED-V v2 |
MED-V Policy Server |
Yes |
No |
Image Distribution Server |
Yes |
No |
MED-V Client |
MED-V Client |
MED-V Host Agent |
MED-V Workspace |
MED-V Workspace (Manually Installed) |
MED-V Guest Agent (Auto-installed) |
VM Preparation |
VM Preparation Tool |
MED-V Workspace Packager |
MED-V Management Console |
MED-V Management Console |
MED-V Workspace Packager |
Diagnostics |
Kidaroreport.exe |
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.
URL Redirection
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 https:// 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.
Policy Source
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: https://blogs.technet.com/appv/
The WSUS Support Team blog: https://blogs.technet.com/sus/
The SCMDM Support Team blog: https://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: https://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: https://blogs.technet.com/operationsmgr/
The SCVMM Team blog: https://blogs.technet.com/scvmm/
The MED-V Team blog: https://blogs.technet.com/medv/
The DPM Team blog: https://blogs.technet.com/dpm/
The OOB Support Team blog: https://blogs.technet.com/oob/
The Opalis Team blog: https://blogs.technet.com/opalis
The Service Manager Team blog: http: https://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: https://blogs.technet.com/b/avicode
The System Center Essentials Team blog: http: https://blogs.technet.com/b/systemcenteressentials