Partager via


MED-V V2: Charting the changes

imageThroughout 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

clip_image001 clip_image002

Comments

  • Anonymous
    April 06, 2011
    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.

  • Anonymous
    April 10, 2011
    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.

  • Anonymous
    May 31, 2011
    To the 2 commenters above, you can use the Med-V administration Toolkit (start by running C:Program FilesMicrosoft Enterprise Desktop VirtualizationMedvHost.exe /toolkit on the client) and either Reset or Rebuild the Workspace. Rebuilding the Workspace will bring it back to it's original state.

  • Anonymous
    July 08, 2011
    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?