MED-V V2, V1, or XP Mode?

It looks like both MED-V v1 and v2 will be around for the remainder of the Windows XP support lifecycle. Because of this, I often I get asked the question, “Which version of MED-V should I be using?” as well as “Why should I be using MED-V instead of Windows XP mode?” The following table lists the differences in the basic feature set between versions 1 and 2 of MED-V. This decision making relies on comparing several factors. You also have to take into consideration that MED-V v2 was a complete re-engineering of the product. There is no direct upgrade path between MED-V v1 and v2.

 General Feature Differences between MED V1 and V2

This table focuses on the Primary feature changes and enhancements that drove development of the MED-V/Windows 7/Optimized Desktop Strategy. These include features added into the product as a result of customer feedback for version 1.

Feature	MED-V V1	MED-V v2
Policy Source	XML-based from Server	Local Registry (can be deployed by policy)
Authentications Source	AD	AD
SSO Support Host-Client?	No	Yes
SSO Client-Workspace	Yes	Yes
Workspace Support	Persistent and Revertible	Only Persistent

General Component Differences between V1 and V2

If you are an experienced MED-V v1 users, you will need to be aware of  some functional component differences. 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

Differences that Affect Enterprise Decisions

There will be many customers who have been surveying MED-V for enterprise deployments. Many may have looking at MED-V version 1 and are trying to determine whether MED-V v1 or MED-V v2 is suitable. The following chart outlines many factors that determine adoption in the enterprise. Use this to help you make that decision.

Feature	MED-V V1	MED-V V2
Client Host OS Support	XP, Vista, and Windows 7	Windows 7
VPC Engine	VPC 2007 (VPC 6)	VPC7  (Non VT requires Patch)
URL Redirection	Basic (Bidirectional)	Host-to-Guest only
Full Desktop Mode	Yes	Only through VPC
Reporting (SQL)	Yes	No
Policy Source	Server (XML)	Registry/GPO
Seamless Integration	Yes – Manual	Yes – Automatic
Application Publishing Foundation	Kidaro	RDP/RemoteApp
Console	Yes	Yes (Workspace Packer)
Integrated Image Distribution	TrimTransfer/BITS/Pre-Staging	Pre-staging Only (ConfigManager Integration with DCM)
WMI Support	No	Yes

 The Feature Comparisons between XP Mode, MED-V V1, and MED-V v2

Finally, how both MED-V v2 and v1 stack up in comparison with XP Mode is outlined in the table below. XP Mode is designed to be a consumer solution while MED-V is for the enterprise.

Feature	XP Mode	MED-V v1	MED-V v2
Seamless Application Compatibility Environment	X	X	X
Host/Guest Folder Integration	X		X
USB/Smart Card Redirection	X		X
Dynamic Application Publishing	X	Manual	X
Custom XP Image		X	X
Domain Joined		X	X
SCCM Integration		(Bridged)	(Bridged and NAT)
IE6 Web Redirection		Bi-Directional	Host to Guest only
Shared VHD Support		X	X
Guest Wake-to-Patch			X
Automated First-Time-Setup		X	X
Packaging/Configuration Wizard		X	X
WMI Monitoring Interface			X
Network Printer Syncing		Steve Thomas	X

MED-V: Published Batch Files/Command Scripts Should use Internal Start Command to Call

Whether you are using MED-V versions 1.0 or 2.0, batch files or published batch files (or command scripts) with MED-V should be approached in the same manner. Essentially, when you are publishing any script using *.BAT or *.CMD extensions, you may find the parent command window never closes when spawning the external command.

For example,

If you were to run the following batch file:

call \\NETWORK\FOLDER\FOLDER\FOLDER\master.bat
%SystemRoot%\explorer.exe “\\NETWORK\FOLDER”
exit

The end result would be an open explorer window with a parent command prompt window remaining open until explorer is closed.

This is a design issue with command processing and batch files when using default syntax.

To resolve this, replace the last command by pre-pending a start command to it to make the window disappear.

Use the following syntax:

call \\NETWORK\FOLDER\FOLDER\FOLDER\master.bat
start %SystemRoot%\explorer.exe “\\NETWORK\FOLDER”
exit

MED-V v2: Documents Folder Opens up Very Slowly

If you are using MED-V and you find that the user’s “My Documents” folder is very slow when launching from workspace, you need to verify the deployment strategy used because seamless folder integration between the host and the guest is one of the great improvements in the latest release of MED-V.

Chances are if you experiencing this in v2, it is due to the latency of network-based redirected folders for the “My Documents” folder. Either the “My Documents” folder has been redirected to a network drive on a remote server or it has been redirected to the host drive via SMB (UNC path to the host name of the MED-V Client host.) In the case of the latter, even though the drive mapping is to the host, it is using the SMB protocol which is treated like a network redirection.

In previous releases of MED-V, these workarounds were the only way to seamlessly synchronize the documents folder between the host and the guest.

In version 2 of MED-V, instead of leveraging the VPC network stack for folder redirection, it uses the RAIL/RDP method of folder redirection by relocating the guest documents folder to the local host via RDP (\\tsclient\c\etc.) This will drastically improve performance when moving files between the guest and the host. Do not apply group policies for folder redirection to XP workspace or manually redirect the My Documents folder. If integration components and folder redirection was enabled in the underlying VPC configuration, MED-V will automatically provide the RDP-based synchronization between the workspace and host documents folder.

MED-V: Support for Multiple Drives within MED-V

Support for multiple drives and volumes within a virtual PC (workspace) used by MED-V will depend on the version of MED-V being used. MED-V v2 only supports the use of one fixed disk volume within a single virtual hard disk (VHD.)

It is technically possible to use more than one partition/volume within a single virtual hard disk but it is not recommended if it can be avoided.

MED-V v1 supported the use of multiple virtual hard disks (VHDs.) In addition, MED-V also supported multiple volumes (drives) as well as the use of the SUBST command to mount drive letters to local directories.