One of the big things that came out of last week's Horizon Suite announcement from VMware was that they are recommending different management strategies for physical desktops versus VDI desktops.
For physical desktops, VMware now offers Horizon Mirage (which they got from their 2012 acquisition of Wanova). Mirage adds layering and application management to Windows desktops, irrespective of whether they're physical or virtual. (In other words, Mirage manages Windows, and it doesn't care whether that Windows is on a laptop, a desktop, a VM on a client, or a VDI instance in a datacenter.)
Gabe and I have loved Mirage since the product was launched several years ago and we've said things in the past like, "Yes! THIS is the way to manage Windows!" So when VMware bought Wanova, we were generally happy. The typical "onboarding" of a Mirage into an existing environment is that you install the Mirage agent on a user's existing laptop, it starts scanning and figuring out what's what, then it copies any unique bits up to the datacenter. (This happens continuously as the user makes changes.) Then moving forward, admins can push out or replace certain applications or layers, and if the user ever loses their laptop, they can get a new generic one, install the Mirage agent, and get their environment put back together. Again, very cool!
One of the biggest reasons we love Mirage is because it works with persistent, non-shared desktops. So if you have 500 users, you can have 500 different desktop images. You don't have to virtualize every single app with ThinApp or App-V, and Mirage can support user-installed software, users being their own admins, drivers, etc. Basically Mirage allows desktops to work exactly how they work today before Mirage.
Compare that to the way that many vendors who try to scam you into the whole "shared image" thing. The claim many users sharing a single disk image is easier to manage than each user having his or her own unique image. While it's true that managing 1 image is easier than managing 500, the challenge is that existing desktop environments are built around every user having their own image. If image sharing was so easy, you'd be doing it today (either using using Ghost, or Terminal Server). The reality though is that image sharing requires that your users can't install their own apps and your users can't have admin rights—and that's just not the way that Windows desktops work today in many environments.
So that's why I've always advocated building VDI environments based on the same type of desktop imaging and management as your physical environments. If you blew away your physical desktops every few months with new images, great, then use Linked Clones or master images. But if you image your desktops once and let users customize them from there and manage them with SCCM, fine, but you need to make your VDI environment so it also uses SCCM and allows users to customize as they want.
So for me, VDI is nothing more than a form-factor change for your existing desktops and laptops. VDI has several great benefits, like centralization for business continuity, accessible desktops from anywhere, and desktop portability. If you need this, great, then you should use VDI! But don't try to completely change the way all your existing persistent / personal desktops work. Just rebuild that in your VDI environment and you're all set. (Again, I'm not saying that moving to a single image shouldn't be a goal. That's a fine goal, but it shouldn't have anything to do with your move to VDI.)
How to be successful with VDI? Do *not* create a VDI strategy!
For the past few years at our desktop virtualization seminars (25 cities this year, all free :) and in our book, I've specifically said, "if you want to be successful with VDI, do not create a VDI strategy!"
At first that might seem counter-intuitive, but since VDI is just another way of delivering a Windows desktop, what you really need is a Windows strategy, not a VDI strategy. After all, this has served you well over the past 20 years as you've gone from desktops to laptops to huge powerful machines to small ultraportable weak machines. You don't fundamentally change your Windows management / application / profile / security strategy based on what type of device you're using, so why should you change it just because you add some VDI? In fact creating a brand-new Windows strategy just for VDI is another big reason that many VDI projects fail. As long as VDI is "different" within your organization, it will always be an outlier.
VMware's split strategy
That brings us around to the problem I have with VMware's recommendations around their launch of the new Horizon Suite. Prior to buying Wanova last year, VMware never had a strategy or product for physical desktops. While some might argue that if you used VMware you would always have a split strategy, but I never saw it that way. Like I said, for me VDI is all about the persistent desktops, so if I used VMware View for VDI, then I wanted to use it with persistent desktops. Doing so would mean that my desktops were managed in the same way regardless of how I delivered them. If I wanted to use ThinApp or App-V or SCCM or Altiris or Browsium or AppSense or antivirus of whatever to manage them, I would do that for all my desktops—physical and virtual, since it's completely crazy to manage different desktops in different ways.
But now that VMware bought Wanova, they're saying that Wanova is the way to manage physical desktops. This is great and we love it. But they're saying that you should NOT use Mirage to manage your View VDI desktops!!?! That's crazy! [UPDATE FEB 26: VMware believes this statement of mine is factually inaccurate. Read more here.]
It took awhile for us to understand the reason. When we asked about it they initially claimed it was because the management consoles weren't integrated and that they only wanted to deliver a suite with one console, but then we pointed out that the suite still has plenty of different management consoles once you look at all the components (Workspace, Mirage, Fusion Pro, Workstation, vCenter Operations), so that didn't fully make sense. Then they clarified (a bit on the phone and more fully the next day via email (as Gabe mentioned in his coverage of the Horizon Suite announcement) that it was also because Mirage doesn't have good performance within View, so there are performance issues and while it technically works, they don't recommend it at scale.
Okay, so that sucks, but whatever. Personally I would have thought that the whole point of buying Wanova was so that you could use Mirage for physical and virtual desktops, and I also would have thought that nine months was enough time to get that work done, but I'm not a developer or a product guy so I don't know what it would take. The bigger point though is that now VMware has come out with their own version of Mirage and they're telling customers to use that for physical desktops only while telling them to use different strategies for their View-based virtual desktops.
But that's crazy. Why would a customer want to do that? Because if the Linked Clone / master image sharing works for VDI, why is the customer even using VDI? Why not just use RDSH and get the same functionality for 1/3 the cost? And if the customer is using View for persistent one-to-one images that they have to manage with something like SCCM, then why not just use SCCM for all desktops rather than SCCM for some and Mirage for some?
The more VMware encourages customers to manage physical and virtual desktops differently, the more VDI will be viewed as an awkward cousin of "real" desktops, and that's not good for any of us. So as long as VMware says that using Mirage with View is a "future design goal," then customers should be advised to keep Mirage as a "future purchasing goal."