Brian Madden's Blog

Home

Syndication

Past Articles

Does Quest+MokaFive = threat to Citrix?

Written on Apr 18 2011

Filed under: Quest vWorkspace, Client Hypervisors, Quest Software, MokaFive, VDI

9,570 views, 8 comments

by Brian Madden

Last week Quest Software announced that they would begin selling and supporting MokaFive's client-based desktop virtualization product. This means that Quest can now offer a very complete (albeit not integrated) solution to support datacenter desktops (both VDI and TS/Session-based) and client-based VMs (both "Type 2" and "bare metal"). It also means that Quest can now compete against Citrix's "FlexCast" messaging, as offline/local had been the major hole in Quest vWorkspace before now.

Digging into the deal

The deal announced last week essentially means that Quest will resell and support MokaFive's Suite. (If you're not familiar with MokaFive, they have a client-based VM management solution, including image management, disk layering, patching, updating, backup, & remote wipe capabilities. They leverage the VM player/Fusion/Virtual Box/etc. for "Type 2" client-based VMs, and they also have a Linux-based "bare metal" solution.)

At this point the version of MokaFive that Quest will resell and support is basically the exact same thing you can also buy directly from MokaFive. The only real difference is the branding and the licensing (that integrates with Quest's licensing). Well, that and the fact that you can buy it through the Quest channel, and you get 24/7 support from directly from Quest in your own language, etc.)

But from a technical standpoint, there's no integration between MokaFive and Quest vWorkspace.

The Quest MokaFIve Suite, as they're calling it, including 24/7 support, is $299 for a perpetual license or $150 per year for an annual license. (That's the same rate card price that MokaFive has directly. In fact MokaFive doesn't care where you buy it from as they get paid either way. :)

This seems like one of those rare "win-win" deals. MokaFive gets a much bigger channel for their product and now has options for customers who need 24/7 or local language support. And Quest finally has an answer for local/offline use cases and has a more complete offering when competing against Citrix or VMware.

I asked representatives of MokaFive why Quest didn't buy them outright. They said that I needed to ask Quest. So I did, and Quest basically said that they couldn't afford to, saying, "MokaFive has taken $38m in funding, so you can imagine what the price tag would be."

I also asked both Quest and MokaFive whether any money changed hands for this deal. They both said "yes," but neither would elaborate (or even say which company paid which).

Taking a look down the road

So obviously this is a first step. At this point the products are not integrated and Quest is really nothing more than a reseller & support engine. But they have aggressive plans to continue to integrate the two products. And although they're not publicly talking about their plans, we can assume what they might be.

For example, I assume that they'll eventually get to the point where you can use the same disk image for both your Quest vWorkspace VDI instances and your local MokaFive instances. I assume they'll integrate the Quest Windows 7 display protocol extensions (which Quest calls "EOP") into the MokaFive images so you can remotely connect to your clients or "port" your existing VM back-and-forth between the datacenter and a laptop. And I assume they'll integrate the consoles and the workflows (image creation, policies, revocation, etc.) so that admins have a single place to control & provision everything--regardless of the delivery engine. And I assume MokaFive will extend their layering into Quest vWorkspace so you can use the same layering technology for your VDI instances. (That topic actually deserves its own article. More on that later this week.)

But Quest vWorkspace & MokaFive aren't integrated! Isn't that a #FAIL?

I know some will say that since it's not integrated, that's a problem. But come on... Look at XenDesktop. How well are all of their components integrated? XenDesktop and XenApp are not really integrated at all. (Hell, they can't even share the same policies or the same database.) Nor are either of those really integrated with Provisioning Server. And of course if you use XenClient (which is bare metal only--Citrix doesn't have a Type 2 client solution), you have to manage disk images with another tool--XenClient can't use Provisioning Server. So my point is that all the components that make up XenDesktop are certainly not integrated.

Compare that to Quest. With Quest & MokaFive, yeah, you don't get integration between the client-based and datacenter-based desktop options, but Quest's VDI and TS/Session Host products are 100% integrated. (Actually it is literally the same product and same database for both.) And this includes seamless windows to apps from TS or VDI. And Citrix and Quest both approach App-V in the same way (and both integrate better than VMware View integrates ThinApp). Quest vWorkspace integrates with Hyper-V via SCVMM for disk provisioning (and they use "real" Sysprep).

So between Quest & Citrix, they both have areas where they integrate well and areas where there's work to be done. But I certainly don't think that Citrix is very far ahead.

Moving on to VMware, they do a great job with View. View itself is easy to install and fairly well-integrated with the client VM-based mode of operation (called "View Local Mode.") But VMware doesn't integrate with single-published apps from the datacenter. (So you can only connect to complete remote desktops, not seamless apps.) And while VMware claims that View brokers connections to TS / Session Host sessions, you don't get the same experience. For example, connections to TS sessions are RDP-only (no PCoIP, which also means no iPad client support) and you don't get the ThinPrint components they licensed for View when connecting to Terminal Server. (And in fact you don't get any management of Terminal Server through View.) So I don't really consider that View supports TS.

And then there's the problem with VMware's ThinApp. It's amazing technology, but it's far from "integrated" with the rest of the VMware View suite.

So really everyone has integration issues.

The bottom line

So will the Quest/MokaFive deal impact Citrix & VMware? Probably not. Those who love Citrix love Citrix. Those who love VMware love VMware. And poor Quest definitely suffers from a mindshare problem with it comes to Virtual Desktops. Their products have always been technically strong (at least for datacenter-based desktops), but with both Citrix & VMware ratcheting up the "local VM" rhetoric over the past year, this was a big hole in Quest's offerings, and this MokaFive deal is a big help for them. (And we'll see how fast they can execute their integration roadmap to get some true integration.)

What do you think?

Comments

Daniel Bolton wrote re: Does Quest+MokaFive = threat to Citrix?

on Mon, Apr 18 2011 3:10 AM

On the whole a pretty good move if you ask me...

www.quest.com/.../Quest_vWorkspace_and_MokaFive_Integration.pdf

Michel Roth wrote re: Does Quest+MokaFive = threat to Citrix?

on Mon, Apr 18 2011 6:08 AM

That looks like a roadmap to me! :-)

Srini Gurrapu wrote re: Does Quest+MokaFive = threat to Citrix?

on Mon, Apr 18 2011 11:32 AM

This is a very good move. Finally the market is accepting that Offline [client virtualization] vs VDI are not either/or situations, but customers need both to meet the needs of their users.

In fact, I believe the market need is "Integrated Offline VDI" so that users have the flexibility to access their desktop locally on their desktop -- or use it in the VDI mode when they dont have their laptop with them or use it from a device like iPad [non-PC device] etc.

We @ Virtual Bridges enable this using a combination of technologies:

* Portable Hypervisor -- same hypervisor that runs on both VDI server and client-side hypervisor. No need to worry about image conversions etc.

* Same Desktop Image -- You create the image once and the same will be used and managed on both the client and the server. In fact, one customer told us that having different images for client and server means that customer now has to manage 2 desktops for every user.

* Ability to sync the profiles or documents between the client and the server -- to deliver a portable personality across VDI and client sessions.

I believe that with Quest/Mokafive, Virtual Bridges, Citrix, VMware recognizing the need for "Integrated Offline VDI" -- I think this will be a major deployment mode soon. Of course, Citrix has some work to do to get there. :-)

Srini

Jon Rolls wrote re: Does Quest+MokaFive = threat to Citrix?

on Mon, Apr 18 2011 12:08 PM

Some excellent speculation by Brian there, and as Dan has posted above, a roadmap along those lines is now public.

If we can join the worlds of hosted and local VDI with a single VDI image, with reach to PCs and Macs, and even console integration I think we'll be very strongly placed.

gpoguy wrote re: Does Quest+MokaFive = threat to Citrix?

on Mon, Apr 18 2011 5:14 PM

From a pure marketing perspective, it *sounds* like a good story. If you think about it from a customer perspective, I'm not so sure. As far as I can tell, each technology takes a fundamentally different approach to solving "desktop virtualization", including everything from how images are managed to how applications are delivered. So, If I'm a customer who has a large mobile population that really has a need for an offline virtual desktop, why would I choose a combined vWorkspace/Moka5 solution (especially when they are not integrated)? If I don't have such a need, what would compel me to complicate my environment by deploying "a little" Moka5?

In any case, isn't all this really about getting the applications to the user that they need, regardless of where they are at? If so, then it seems like an awful lot of work (buying such a non-integrated, combined solution) to go through for that end-goal.

Happy to be convinced otherwise, but not seeing at the moment.

appdetective wrote re: Does Quest+MokaFive = threat to Citrix?

on Tue, Apr 19 2011 12:02 AM

Overall I like the move. I think to compare Apples to Apples, VMware should be worried the most. This is a far superior solution to what ACE AKA local mode offers. However still good for VMware as it runs best of VMware Workstation.

Clearly Quest is getting the Citrix Flexcast messaging as can be seen from their marketing. VMware for some reason doesn't know how to tell the story the same way.

Some good Twitter debate over the last few days on this topic. I have always liked the Moka 5 management story. I agree with push back that Type 2 is not going to be a mainstream use case, however this is the kind of the management that is needed to broad Type 1. NxTop are close also and may be a better alternative. Unclear as @harrylabana pointed out in a tweet what the Quest NxTop vs. Moka 5 story is. Customer buy two management systems?

It will be telling to see what both VMware and Citrix announce this year in terms of management improvements for their respective solutions. I suspect they will built and it will be less capable that Moka 5 but they don't care. That pisses me off!

I wonder if Moka 5 has effectively signed their death warrant to be cut out of any future deal that would allow other to manage XenClient. NxTop I am sure would love to position themselves to take advantage. But will they, or will the Quest + NxTop still make sense moving forward. Hmmm...

appdetective wrote re: Does Quest+MokaFive = threat to Citrix?

on Tue, Apr 19 2011 12:03 AM

Clearly Quest is getting the Citrix Flexcast messaging as can be seen from their marketing. VMware for some reason doesn't know how to tell the story the same way.

Paul wrote re: Does Quest+MokaFive = threat to Citrix?

on Wed, May 4 2011 9:40 PM

Didn't mean to hijack the topic...

But speaking of threats to Citrix... have you ever heard a product called GraphOn Brian ? Seriously considering it as an alternative to citrix.

What do you think of it ?

(Note: You must be logged in to post a comment.)

If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.