We compared hosted virtual desktop infrastructure (VDI) products from Microsoft, Citrix, VMware, Oracle and Ericom and came to many conclusions, but the most important one is this: Setting up hosted desktop sessions in a BYOD world is a complex undertaking.
When a user grabs a device and wants to access a session, the first step is downloading an app for the device, which may or may not have additional configuration steps. Thankfully, most of the client-side apps we tested needed no more than an IP or DNS address name -- and one (Oracle) could do an automated search by an address pre-seeded in the client.
If and where possible, we strongly recommend mandating a VPN connection before linking to a network, but this isn't always possible or feasible. Once a user initiates a session, a connection broker takes the user's request, and after an authentication step, the broker chooses an ad hoc or persistent session.
Here's where things get thick. The session is a live instance running as a virtual machine on the network, therefore, the session must wake up and be a fully functioning member on that network so as to reach its resources and deliver some of the characteristics of the session to the user's remote device. No matter what device they're on or where they are, users want a beautiful analog of what they might see on their desktop at the office.
The user must also be authenticated, often through a local user database, LDAP or Microsoft's Active Directory. Printing resources must be defined. By user or group attribute, an administrator must determine sharing of information in concepts like: do you allow the user to store data away from the host session? Can a user launch a web session on the virtualized and remotely connected session? Is there just one or a handful of apps to use, or is the session wide-open? Does the user get to own the session for the next reuse, thus burning a license?
Indeed licensing issues, and how Microsoft treats Windows licenses, cause VDI makers considerable grief, because of the many licensing plans Microsoft offers, and how VDI sessions might use up available licenses. Careful consideration is required as in some cases, 100 non-persistent sessions could decrement the entire 100-license pool quickly and permanently until the problem is found and resolved.
Then there are session customizations, so that users land with the correct session customizations. The sessions must work well, perhaps in ugly circumstances such as over-subscribed Wi-Fi access points in remote locations.
Uncontrollable events can occur, such as logon storms, when many people must suddenly meet for online meetings using VDI, or other event storms that can task building ad hoc sessions. It's a lot of work. We know because we did it. And there were items we had to gloss, like multi-monitor capabilities (Horizon View has it), constraining video characteristics (shared by most all), super-multimedia (too many device differences), and strict adherence to policies (Active Directory or session-managed).
-- Our Clear Choice Test winner is Citrix's VDI-in-a-Box for its ease of integration, flexibility of both hosted operating systems and variety of clients, and its end-user experience.
-- VMware's re-done Horizon View 5.2 is also very capable and can scale dramatically, but it's more limited in both hosts (Windows) and clients served.
-- Oracle VDI, a combination of Sun and Solaris (or Linux), has potentially more limited use for smaller organizations but does something surprising: it can host non-Windows images. *** Editor's Note: Oracle announced this week that it has ended new feature development for Oracle Virtual Desktop Infrastructure, but customer support will continue uninterrupted and customers can continue to purchase new licenses. Oracle said it will continue to invest in Oracle Secure Global Desktop and Oracle VM VirtualBox software.***
-- Windows 2012 Server is good, yet requires a buy-in to Microsoft's Windows System Center Configuration Manager, and has less client flexibility.
-- We also tested Ericom's PowerConnect as both a connection broker and transport system -- and it rocks. Here are the individual reviews:
Citrix VDI-in-a-Box 5.2
VDI-in-a-Box is a downloaded, then licensed application that functions as a VDI controller. It sits in your data center as a VM appliance, and merrily tosses sessions between either VMware 5.0 update 1+, Microsoft Hyper-V 2008 R2, or Citrix XenCenter 6.1 hypervisor and user devices -- a breathtaking number of them.
You can virtualize host sessions for Windows XP SP3+, but not for non-Windows host operating systems. Citrix uses the HDX protocol, which is an enhancement of Microsoft's RDP protocols.
One final hurdle: you'll need to have a Microsoft volume licensing agreement, so that Windows virtual licensed desktops are available. You can try experiments and proofs-of-concept with trial or Microsoft Developer Network-use Windows licenses, but production systems require Windows volume agreements. A volume license key, or an MAK (license pool service) with a minimum of 25 users in it must be present. A DHCP server is also necessary, along with a data store, and a naming convention for hosted VMs must be considered and chosen.
There's a different download for each supported hypervisor. We tried all three, and they work essentially in the same way: Unzip and deploy. A grid name is initially established, even though that might be just one VDI-in-a-Box server. You can use an internal VDI-in-a-Box-specific user database or connect to an Active Directory. If this is an iterative installation, an actual grid of VDI-in-a-Box hosts is formed by logging in subsequent appliance installations to the initial host.
From there, Citrix glue apps are installed inside VM instances to be hosted. The instances must be built correctly for the environment chosen, and this part is critical. If you clone a bad prototype by having users login, you'll have multiple bad instances of VMs with problems all in seemingly record time. For that reason, and with each clone-able hosted instance, we strongly recommend spending a good amount of time in prototype "draft" instances. When bad instances mutate, they create external help-desk problems and considerable teardown and retrofit under pressure.
Citrix lags only a bit behind VMware's native instance image considerations -- although both companies have extra/optional products that weren't tested for this review. Once one gets the images correctly installed, there is the consideration of how to license these images (if Microsoft's Windows) to permit correct licensing decrementing and pools differentiations for persistent and non-persistent uses -- which have different licensing constraints. Let Microsoft or Citrix explain it to you, if you're unsure.
Citrix also allows VDI-in-a-Box to be configured to prevent resource drainage during event peaks, like morning startup-time, or everyone-in-a-remote-meeting time. We were unable to summon sufficient resources to truly test which of our compared products can withstand the test of both disk and memory-use storms. Citrix-recommended server infrastructure descriptions for Citrix running Citrix VDI are less detailed than VMware, as VMware's construction recommendations are fairly precise. We feel that some of this may come from the fact that Citrix as a connection broker runs with and over several different hypervisor families, which is flexible, where VMware's Horizon View is in a more controlled environment.
We cobbled sample images. This is a comparatively simple process after considerations for the environment where the image will live and be used. VDI-in-a-Box delivered them to our local and remote-based desktops without a hitch. The "draft" images allowed us to choose either Microsoft's RDP protocol or Citrix HDX. HDX is our preference, but is unavailable for Windows 2012 Server logons through the agent that must live inside the host -- for server VDI. Ultimately, on fast links, HDX was felt to be as good as the PCoIP protocol that VMware uses -- although over slower links or those with unpredictable latency, we preferred PCoIP, but we cannot find an exact tipping point where PCoIP is demonstrably better.
We could also choose whether the hosted VMs had use of network/local-to-the-VM or device disk drives, printers, smart cards or other USB devices. We could also limit color depth, which can have a dramatic effect in terms of low speed or high latency connections for performance. You get one monitor device; VMware allows two.
The end-user side of VDI allowed for clear images of Windows 7 and our test product, Office 2010. We were able to obtain Citrix Receiver for iOS, Android, Mac/Linux/Windows, and even our Blackberry/RIM Playbook2. Citrix Receiver seems to play everywhere. Connections we tested from our lab to our network operations center over broadband were easy to effect, and had uniformly high quality. One device, the Playbook 2, went slowly, but we suspect this could be a function of the lack of power in the Playbook 2, as other devices worked well.
As Citrix VDI-in-a-Box works over a number of hypervisor family platforms, and either with its own user database or Active Directory, security concerns are largely outside of the scope of the product, and must be "buttoned down" prior to installation. As most organizations already (hopefully) use best practices, chances for misuse are somewhat limited. This contrasts with VMware's Horizon View model, which uses and dramatically enforces certificate-based security, and we feel a stronger security regimen for Active Directory infrastructure.
VMware Horizon View 5.2
Horizon View is very extensible, fits in VMware's products model, and contains an Active Directory-specific connectivity and security model. There are many optional components to the base installation, and while the stripped-down version we tested was useful and flexible, the others are the secret sauce -- and should be included -- even if this raises the base price of the Horizon View product, we feel. The secret sauce, View Composer, which is optional, allows very strong customization potential, but in our oranges-to-oranges base product comparison, we're leaving it out of our testing equation. Horizon View is expandable and served up beautiful VDI client experiences, and requires both strong VMware and Active Directory expertise to install.
With a few hindsight-driven cautions, Horizon View is vastly expandable, but it's only supported VDI desktop is Windows, just like Citrix's VDI-in-a-Box.
The base Horizon View package allows a wide variety of clients to access hypervised Windows virtual machines, and VMware also optionally permits "ThinApps" to be accessed, although this wasn't tested. The experience for users is flexible and initial connectivity is easy to understand. On the back-end, they're authenticated, and members of Active Directory, where present and needed. Horizon View is glued well to Microsoft's Active Directory and uses strenuous security methods.
We needed a host for ESXi, and the vSphere 5.1 (older versions of vSphere are not supported) Server Appliance. Horizon View Connection Server is a Windows 2008R2 Standard virtual machine/VM, and another instance of Windows 2008R2 Standard is a security server. Optionally, we could add an extra-cost template maker, Horizon View Composer to the Connection Server, but putting them on the same server instance is not recommended for higher-traffic installations.
None of the Horizon View servers can be Active Directory Domain Controllers, and Active Directory Light Weight LDAP services are installed on Connection Servers. The scorecard so far: base-host plus two servers (or more), and base images/templates that will be used to spawn other images used for pools of desktops.
Running optional View Composer requires its own compatible Microsoft or Oracle database. One creates templates of variants of Windows VDI hosts that are customized in various ways. But it's not part of the base kit, so we stop here.
While VMware allows self-signed Horizon View certificates to be used, we found this to be potentially fraught with difficulties and contributed to our sense of product brittleness. A dead/missing certificate can be difficult to re-admit.
We strongly advise using Microsoft's Certificate Authority Services, or better still, an actual root certificate to generate the SSL certificates Horizon View needs from a trusted source. We were able to make self-signed certificates work, but there is pain and suffering involved.
Once certificate issues were sorted, Horizon View had the best overall security of the VDI products we tested, although there are many, many server ports open for things to communicate with each other. Clients connect to Horizon View, and are bound via an SSL relationship and Active Directory security. Where VMware/Teradici's PCoIP protocol is supported in a client and there were no latency issues, the user experience on the client side was very, very good.
Like Oracle VDI, Horizon View could cache memory and storage among desktops and could be optimized to help survive an access storm. We had insufficient resources to characterize the duty cycle of logon accesses that makes this useful when deployed, but we had a strong sense that much detail was given to optimizing storage.
The downsides are mostly administrative. We changed our Horizon View server at mid-test from the lab to our NOC at nFrame. In doing so, IP addresses changed. This started a cascade of difficulties. A server certificate disappeared, causing endless head scratching and the revelation that many VMware Horizon View error messages are vastly inarticulate. Horizon View wants a log file kept in SQL Server or other compatible database -- and not the one used for optional Horizon View Composer.
Lacking that, it's difficult to keep track of events, and coupled with inarticulate error messages, we spent days of downtime researching problems. This is why we suggest 1) using a working CA infrastructure even during a trial 2) have a thorough understanding of what ports are needed on what host to communicate with what. If you're only hosting Windows, and already love VMware, this is the ticket.
If we hadn't seen the forensic dramas, we'd have given Horizon View a slightly higher rating, and we acknowledge that most large organizations will never see the issues and circumstances we found. Horizon View had stellar customization possibilities (more so with optional Composer) and a very good client experience that was consistent on any of the devices we tried, and many are supported. We believe it could grow well for organizations needing a large VDI infrastructure. We were dismayed at its Windows-only VDI hosts, and have scar tissue and bruises from small attempts to change settings. Nonetheless, after a sophisticated installation, Horizon View works -- it's very lovely and rich and extensible.
Oracle VDI is a construction set with two main components. There's Oracle VDI atop x64 Solaris or Oracle Linux, then a working hypervisor infrastructure one chooses to connect VM instances. The served instances could be from Oracle, Microsoft or from other sources -- but not more than one variety. Installation and integration isn't really "automatic" and there are no real "wizards".
As tested, Oracle VDI is aimed at organizations wanting a multi-tenant feel towards VDI hosting. The Solaris underpinnings we tested are well-poised towards multi-tenant partitioning philosophies. Access devices supported include Windows, Mac, Linux, iOS, and Android. Because of some basic limitations, it's good only for organizations that either employ VPNs, or can assure stateless firewalls at both the host site and client site. Oh, and it's not captive to Windows hosted VDI images.
We used Oracle VDI with Oracle's VirtualBox 4.2, although there is Oracle VDI support for most major hypervisors, like VMware vCenter or Microsoft Hyper-V. The Oracle VDI offerings works on Oracle (ostensibly) Unbreakable Linux kernels, Solaris 10 or Solaris 11. We opted to install initially on Oracle Solaris 10, but were offered Oracle 11 and chose Solaris 11.
Choosing Solaris 11 as a host platform was possibly a procedural mistake and slowed us down. Solaris 11 (we used 11.1) is very much different from Solaris 10, and different from mainstream BSD and Linux. Solaris 11 uses ZFS, which is a highly sophisticated filing system that can in turn, be allocated as a substrate for other filing system resources.
Oddly, we couldn't use external iSCSI storage -- a current limitation of Oracle VDI on Solaris 11. Traditional network and configuration management has changed, however, from the containers-based methodology introduced in Solaris 10, into a profile and location-based infrastructure that is poised more towards multi-tenant uses. The changes are jarring and had us referring to Oracle's disjointed and occasionally incorrect documents frequently. Solaris's biggest enemy is its own modularity.
Installation of Oracle 11 can be pre-set by installing a local version of the OS along with pre-configured settings to allow a NOC-deployed host to start up and smile at you. Otherwise, it's remote configuration through ssh into a NOC install. We strongly suggest that potential users of Oracle VDI have a pre-existing support relationship with Oracle, so that repositories are easily available as well.
If not, installers will need to download an eye-popping 7GB of update and app repository from Oracle, assemble it externally, then send it to the server and make its resources available. There were days when we felt like beta testers because we don't have an Oracle support contract. Installation can take place on a single quad-core Intel host with a minimum of 8GB of memory and 100GB of disk -- but you'll need much more to host VM sessions unless you take them from Hyper-V or VMware. Oracle VDI must be initially installed with the firewall off, so we installed it in an isolated network, then later put it onto a production network.
Once installed, we had plentiful options in terms of partitioning resources on Solaris 11.1/SunOS 5.6., and in the end, we allocated most of our test Lenovo ThinkServer for use of VM sessions. After a VDI-install program was run (two minutes) we installed the Solaris edition of VirtualBox 4.2. We also had desktop virtualization options (not tested) that included brokering RDP connections to hosted VMs on VMware, Microsoft's Hyper-V, the Sun Ray Kiosk system, or Microsoft RDP server-farms -- or a generic IP address. All are accessed under the aegis of "providers" where the Oracle VDI app serves as a connection broker between clients and target VDI host infrastructure.
We decided to start simple, with VirtualBox-hosted Windows 8, Windows 7 and LinuxMint 14 instances. We would then access these instances with our many client devices, including an iPad Mini, Toshiba Android and Excite 10 tablet.
It's possible to integrate Solaris 11 with Microsoft Active Directory or LDAP/OpenLDAP directory services for authentication proxy. We used Active Directory for proxy authentication via Kerberos, which took some experimentation, but eventually worked. Kerberos requires time synching, which we discovered we lacked, then fixed. We could also scramble the port used for administrative and user access, which we liked. While we liked the fact that Solaris 11 can be made highly secure and suits multi-tenant installations, we warn that moderately strong Solaris 11-specific skills are needed to perform a clean installation; civilians or even moderately skilled Linux admins will get bruised.
We installed the connection broker, and then pools of persistent and non-persistent desktops. We could choose from Oracle VDI Desktop client templates focused exclusively on Windows XP+ editions, or Microsoft's sysprep -- which is familiar to many -- to pre-load Windows desktops for VDI reuse -- or use a manual installation method for Windows/non-Windows VDI hosts.
We could also import VMs from VMware as well. As things need to be revision synched between VirtualBox and VMware, we don't recommend this without a trial phase. Remember: this is a construction set. VirtualBox-hosted VMs, if they're compatible with Oracle's VirtualBoxRDP/VRDP, offered us more responsiveness and local device options, like USB and sound, than the other protocol Oracle VDI supported, generic Microsoft RDP. We strongly suggest using VRDP-hosted sessions where permitted.
Oracle VDI can be optimized for resource sharing; memory can be shared among desktops to prevent startup-storms from occurring when templates need to be retrieved from disk in order to make non-persistent virtualized desktops. The client experiences, in terms of how it looked on BYODs, was very good, but with Oracle's VRDP, startup is slow. We were happy with the response over broadband, although it seemed noticeably slower than Citrix Receiver clients and Horizon View PCoIP clients.
We then found a problem: the Oracle VDI Client App wanted to hear a UDP reply from the Oracle VDI server. The device client app will wait forever for this reply. And many Comcast routers, home or small business, and many others, shut off inbound UDP by default. This means that Oracle's VDI almost mandates a working organizational VPN, along with the client software to run them on the chosen client device. Lacking that, you won't be able to logon from many public resources unless you can unblock UDP-returns.
We obtained the VirtualBox remote client from the Google Play Store and the iOS client from the iTunes Store. Other clients are available through Oracle web resources. On the VDI hosted VMs, the clients were as sharp and useful as VMware's, just a noticeable amount slower to initially load-up and slower for rapid screen deltas.
Oracle's VDI is seemingly endlessly extensible, but doesn't have the client-side pizazz and incredible device compatibility of either Citrix VDI-in-a-Box, or the dogged security and PCoIP sauce that VMware's Horizon View offers. However, unlike each of these, it's not chained to Microsoft's Windows, but does a respectable job with Windows. Only tenacious Unix/Linux/BSD-driven administrators have the slightest chance of an installation that won't require Rogaine from tearing one's hair out. But that's why you opted for Oracle Support, right?
Microsoft Windows 2012 Remote Desktop Services
Microsoft's RDS is somewhat simple, and implements a connection brokerage to either discrete Windows VM instances hosted on Hyper-V3, or desktop sessions on Windows Server instances. Unlike the old, now obsolete "terminal services/TS" in prior Windows Server editions, RDS mandates a working Active Directory infrastructure, and this precludes non-Windows clients, so far as we can find. VDI-in-a-Box and Oracle VDI don't require Active Directory, but RDS and Horizon View do.
There are two separate services, Remote Desktops/RD (which are server-hosted sessions that generate a desktop that can be accessed by internal/external clients), and VDI-hosted sessions from instances hosted on Hyper-V. Either type of session is hosted under the constraints of Active Directory policies and security underpinnings, and either type may be a persistent or non-persistent session. Microsoft requires one of two types of CALs, user and CAL. Users have the choice of a number of devices to VDI sessions. CALs allow promiscuous use, but the costs aren't much different, and each cost is for a "perpetual license," according to a Microsoft spokesperson. Having Microsoft's Software Assurance may assuage or mitigate these costs depending on your relationship with Microsoft.
It's possible to implement an external connection to access hosted sessions, say from a coffee shop; this requires the RDS CAL External Connector Option, which is another, separate license.
The good news is that once licensing issues are sorted, those familiar with Windows 2012 will be able to follow simple instructions to achieve either type of session -- internally or Hyper-V hosted sessions. We chose to install the appropriate roles, which have two branches, one for an RD gateway to Hyper-V resident hosts, or the other direction, Windows 2012 server-hosted sessions. We also needed to install a server role, Network Policy Services.
Working SSL certificates are required. Microsoft's own certificate authority is adequate, but others that support TLS 1.0 and are built correctly are fine. We used Microsoft's certificate authority. An RD Gateway must also talk with a Network Policy Server, which contains the Central Remote Desktop Policy Access Store/database; a clear path to it must exist, as it's accessed to vet logons. No path, no logon.
Support for BYOD-style clients directly from Microsoft is very weak, although much can be obtained from third parties to work with Microsoft's Remote Desktop Protocol 8, which works on Windows user-device instances. Citrix can play here, but in terms of Microsoft-supported client devices, there are but a handful.
The handful, including the Windows 7 and 8 devices (an older version of RDP is still available for those using Windows XP SP2+) looked as though we were using a native connection. Graphics were fast, and GPU support is available for those needing extreme graphics response, but this wasn't tested.
There is no real heterogeneity in Microsoft's offering; it's Windows or the third-party highway. What were once Terminal Services appear to be slowly deprecated. Our RDS server-hosted sessions were easily accessible and a plainly generic experience. Hosted VDI instances were customizable and crystal clear and finger-snapping fast, and the overall installation was both easy and predictable, but we're becoming very used to Windows 2012 server. If you're a "Windows shop," and you're not going to tax much and sneeze when you hear iOS or Android, stop here.
Ericom PowerTerm WebConnect 5.8
The Ericom PowerTerm WebConnect (PTWC) product is a gateway system for client devices and hosted VM resources. Both the client devices and hosted VMs are vastly heterogeneous, perhaps in the extreme. There are two likely components, a gateway server that is recommended to be hosted in a DMZ zone behind a firewall, with a single port facing the world -- SSL on Port 443. In turn, the gateway server connects through secondary firewalls to internal host resources that include Ericom's AccessNow Server, Ericom Blaze Server, Terminal Services (if desired) and the cabal of user-configured host resource infrastructure that is built and hosted outside of the scope of Ericom's control.
The result is that PTWC is all about optimizing protocol relationships between hosts and guests, and little to nothing about the security, configuration and image management for VDI host instances. Do that on your own. We did.
Additional Gateway Servers can be defined and joined together. Likewise, additional PTWC servers can be licensed and joined together to form load-balanced and redundant grids for extensibility and high availability purposes, but we did not test this. Hosted VDI VM or application services instances are controlled by infrastructure outside of Ericom's domain, but Ericom can perform LDAP, Active Directory or Novell eDirectory proxy authentication.
Once the server is set and configured, user devices running HTML5 in a web browser, Windows XP+, Linux (many versions), Apple OSX 5+ Intel, iOS, Android, Windows CE/XPe, Win7 Embedded, and Google Chromebook can use the Gateway Server through one of three entries.
The entry points are an Applications Portal web interface; the Application Zone that launches apps or desktop sessions via the RDP or Blaze protocols; or AccessToGo. Java is required for all clients except where ActiveX can be an alternative. The PTWC client software is deployed via the gateway using ActiveX downloaders (default for Windows) or a Java downloader -- so Java must be enabled on the client device. Both Java and ActiveX downloads can be customized.
The Applications Portal serves applications as an app server; clients can choose from a selection of them. We could dish-up Microsoft Office, or a game of Solitaire. Full RDS-like sessions, applications, or Microsoft's AppV (if pre-configured and installed) are supported.
The XRDP protocol allows more recent versions of Linux to become VDI host sessions, too, although Ericom manages PTWC through Microsoft IIS-based resources and Microsoft MMC snap-ins. Windows or Linux VDI host brokered sessions are managed through the DeskView Connect Broker Administration MMC snap-in.
The client device experience was very good, and perhaps the equal of Citrix's Receiver. We tested high-res Windows and Linux sessions, and determined the quality to be very good. Many communications protocol settings are available to tailor which protocol is used for what session to which VDI host. As we don't use modems and 56K lines any more, it was difficult to discern much difference in protocol setting in terms of connection quality. Web services, client and application VDI hosting, also was uniformly strong across our sample devices.
Ericom's PowerTerm WebConnect is a very astute and customizable VDI brokerage system. As such, it doesn't have the low-level integration with Active Directory that VDI-in-a-Box and Horizon View does. We needed to craft images and instances almost wholly outside of what PTWC does.
Henderson is principal researcher for ExtremeLabs, of Bloomington, Ind. He can be reached at firstname.lastname@example.org. Lars Johnson is a researcher at ExtremeLabs.com.
How We Tested Hosted VDI
We used two networks, a local lab network connected by a GBE switch to HP, Dell, and Lenovo server hosts with a second network in our NOC connected by Comcast Business Broadband. The NOC, and ISP nFrame 70miles away, is an Extreme Networks Gigabit Ethernet-switched network consisting of HP, Dell, and Lenovo hosts along with an iSCSI-based SAN on a Dell/Compellent Series 30 SAN.
We used various client access devices including iPad Mini (iOS 6.4), Blackberry Playbook2, Toshiba Excite 10 Tablet, Lenovo T530 notebooks running LinuxMint 14 and another running Windows 8, both with virtual machines running Oracle VirtualBox 4.2. We also used an HP m140 Mobile Thin Client device, which runs embedded Windows 7. We accessed tablet devices via Wi-Fi onto our lab network, from our host sessions in our NOC at nFrame in Carmel, Ind. Except for our Windows 2012 Server examination, we used Windows 2008R2 server instances as VM hosts and for infrastructure with Windows 7 Professional and Windows 8 Enterprise Windows instances.
Read more about data center in Network World's Data Center section.