Why I don't like MED-V

In American football, there's an expression which says, "If you're gonna rough the kicker, rough the f***ing kicker!"

In American football, there's an expression which says, "If you're gonna rough the kicker, rough the f***ing kicker!" (Those who've seen our videos know this is one of Gabe's favorite sayings. See the footnote at the end of this article if you don't know what it means.) This expression also applies to Microsoft MED-V and perfectly captures why I don't like it.

MED-V, if you're not familiar with it, is Microsoft's solution to application compatibility for enterprises using Windows 7. Available as part of MDOP, MED-V is a Windows XP virtual machine that runs locally on your Windows 7 desktop. The idea is that if you have apps that don't work in Win7, you just run them in a hidden Windows XP VM which provides seamless links into the Win7 host. The MED-V technology is based on Microsoft Virtual PC as well as some capabilities that Microsoft got when they bought Kidaro back in 2008.

So far so good... sounds reasonable, right?

I still don't like it.

The problem with MED-V

MED-V introduces a whole new instance of Windows onto your clients. This is a new instance that you have to manage, deploy, and secure. And make no mistake: it's a lot of work.

Now to be clear: I am 100% comfortable with the concept of deploying client VMs as a type of desktop virtualization. In fact I even like Type 2 client VMs! I like the concept of getting the benefits of VDI (central management, ease of patching, users can't screw things up) without the huge back-end datacenter requirement of VDI. So client-based VMs rock! Woo-hoo!

The problem with MED-V, however, is that you you go through all the trouble and pain of setting up and deploying and managing a second Windows instance to run in a VM on your clients, but then you only use that VM for application compatibility!?! What a huge waste!

If you're going to go through all the trouble to deploy a client VM solution, then you should leverage the crap out of it! If you run a VM on a client, you should use it for every app that's able run locally. Remember, every additional app you can run on your client (whether streamed to the host, in a VM, whatever) is one less app you have to run in your datacenter. And computing resources on clients are way cheaper than those in the datacenter. (Not to mention you get native performance, graphical capabilities, rich peripheral support, etc.)

So don't do all the hard work of building a client VM infrastructure to only use it for app compat!

By the way, if you want to get management benefits of VDI while leveraging distributed client capabilities, check out the products from MokaFive, RingCube, Virtual Computer, Virtual Bridges, or Wanova. All of these let you do real client-based VMs which can be used for more than just app compatibility.

*Footnote: For those outside the US who don't know the meaning of this statement: "If you're gonna rough the kicker, rough the f***ing kicker!" This is from American Football. Just after the kicker kicks the ball, he's in a very vulnerable position since is leg is so high in the air, so there's a rule that applies a penalty for any player on the other team that hits the kicker just after he kicks. This penalty is called "roughing the kicker." The only catch is that the penalty is the same regardless of whether the kicker is roughed a little or a lot. So the thinking is, "Hey, if you're going to incur the penalty anyway, no sense just lightly bumping the kicker... you should give it everything you've got and make sure he limps off the field!"

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I will (quite predictably) agree with your overall point that just looking at client-side VMs as an app compatibility play is missing a big opportunity.

I will add that even for OS migration and app compatibilliy scenarios, a type-1 approach provides some fairly significant advantages.

In a world where you have adopted a type-1 architecture, you can move XP and Win7 in/out interchangably.  So, if you have legacy apps that only run on XP, you simply:

- Leave XP exactly as it is.

- Deploy Win7 alongside it (with complete independence).

- Just click a button the day your legacy app works with Win7 and the XP VM goes away.

Much cleaner and simplier than replicating a native XP envrionment as a VM on top of native Win7.

This is a bit academic for XP->Win7, since very few if any companies deployed XP originally on client hypervisors.  However, it is a good example of how by linking your Windows 7 migration with a move to a type-1 client hypervisor architecture, you will set yourself up very well for the next migration while also getting all of the management benefits of desktop virtualization in the meantime.

Doug Lane

Virtual Computer, Inc.


We've had the expression "you might as well be hanged for a sheep as a lamb" ever since the days when you could be hanged for stealing either ... well before anyone invented Gridiron (or even America).


> If you're going to go through all the trouble to deploy a client VM solution, then you should leverage the crap out of it!

You can. Just because Med-V is sold as an application compatability solution, doesn't mean you are limited to installing apps which are incompatible with Windows 7.

You can install any application which can run within a virtualized instance of Windows.


MS killed Kidaro and now want to charge for inferior features. They never understood the use case. Stupid chick in charge sold it internally as a way to accelerate Win 7. Stupider execs signed off on it, and somebody even stupider seems to have promoted stupid chick sense. No wonder Ray Ozzie wants out........ Stupid company that is too big to do anything innovative. Everything boils down to the lowest common dog sh1t. The emerging world of the desktop will hopefully kill them finally or they will be forced to change. Ready the memo stupid people of MS and fire the horse sh1t management that is still stuck in the dark ages.