Citrix wins virtual desktop interface shootout

Virtual Desktop Interface is becoming easier to do, with potentially killer graphics, reasonable port virtualization, fine-grained administrative control, and with potential hosts other than Windows.

While Citrix XenDesktop/XenApp remains the one to beat, two other VDI platforms we tested, Ericom Connect Enterprise and Parallels Remote Application Server, can provide for the publishing of diverse applications to desktops, while following “the rules” regarding resource accessibility and security.

In testing, we found Citrix leads the pack in terms of overall flexibility, although its vast feature sets can increase support burdens. If price-be-damned and you really want the venerable Full Meal Deal, it’s Citrix XenDesktop/XenApp Enterprise. We found it has almost everything you could ask for in a VDI product.

We found solid extensibility with Ericom Connect, which allows IT managers to create grids of connectivity with no additional licensing costs. This is good for multi-site/multi-tenant organizations.

The easiest entry point was found with Parallels RAS, which is a comparative breeze to install and integrate. It has most of the features found in both of its competitors and a few of its own.

+ A LOOK BACK AT THE 2013 VERSION: Citrix wins VDI faceoff +

The commonality of these three products is that they’re capable of great depth, and in most cases, numerous gradients of feature options. Mostly, their documentation is inadequate, and neophyte admins will need to know something about Remote Access Services before starting.

Part of the problem is the enormous complexity of virtualizing apps plus desktops plus resources and getting everything to run smoothly on a myriad of remote devices, perhaps over a distributed complex network. This is made more difficult by language and international boundaries.

You need to be up to speed with remote access, Active Directory infrastructure, and certificate management. And you need to plan the resources necessary to support the virtualized infrastructure required to do the job.

Securing virtual resources across the open Internet requires more attention to detail, and each VDI package we tested has features that guard against rudimentary host-probing. Certificate infrastructure was most wholesome with Citrix, followed by Ericom Connect, then Parallels RAS.

We tried the full enterprise top-shelf versions of each product, and we caution IT execs that they’ll need to understand the options thoroughly. While each product at its basic will do the basic job, you’ll likely want more, and will need to pay more for the options you want. These options seemed to change over the months that we looked at each product. Enterprise organizations have become used to a somewhat dizzying array of possible options. Here, Parallels RAS and to a lesser extent, Ericom Enterprise Connect have the bliss of simplicity, if with scalability.

Remote roles

Not long ago, it was all you could do to get a remote virtual screen. Microsoft’s RAS and its protocols allowed terminal-like sessions. Then multiple concurrent sessions could be managed, and with the advent of a 64-bit memory map and processor virtualization modes, hypervisor-like virtual sessions and operating system instantiations became possible.

Mobile devices impose new types of OS instantiations, and when publishing apps to mobile devices, session resources can become highly reduced. This reduction in resources, aided by running multiple apps within the same OS instance, then allows publishing apps without dragging a lot of app logic to a remote client/viewer. This also allows app usage on incompatible session devices—like Windows apps on Mac machinery.

Each of the three VDI platforms tested competes with cloud-based apps, made ever-more reliable by Microsoft specifically, as well as others, like Google. Hosted services are a direct competitor, but each of the VDI players has a “secret sauce” that hosted office apps can’t do—yet.

The advent of specialized co-processing boards—GPU arrays that process complex graphics on the host side—enable remote sessions of highly complex graphics apps.

Given decent bandwidth between a session host and a remote client, modernized protocols permit CAD, GIS, and other graphics-intensive apps to be run at considerable distance with only nominal latencies. In the past, latencies made running such programs untenable at best.

The resources for publishing just the app have soared as well. App sources can be anything from traditional Linux and even Mac apps. Sometimes, the app can use added graphics or chipset co-processing, which aids in the remote device perceived response, we found. Other times there didn’t seem to be much of a boost. Much is dependent on the platform, and a session manager’s ability to expose chipset/co-processing resources to the app.

Speed perception can be very important for several reasons, one of which is the nature of support calls and complaints poised when the user doesn’t know if network speed, device speed, or application speed is the crux of finger-drumming complaints. Faster is better.

Speed, along with peripheral integration between a viewing device and client also becomes very important. If there’s a webcam (interactive video or just video viewing), sound indirection, mouse/pointing device movement, or other interactive peripheral device in a session, support for the device(s) becomes very important.

Citrix is the one to beat with device compatibility, but both Parallels and Ericom aren’t far behind.

Parallels supports HTML5, mobile apps, and VDI for PCs, Macs, and to a lesser extent, Linux — all at a lower competitive cost. But device support is more limited.

Ericom does a similar job (also with limited Linux support), but also allows scale expansion through the use of clustering, and with attachments supports a wide variety of legacy apps.

Here are the individual reviews:

XenApp/XenDesktop Enterprise 7.9

The depth and width of Citrix’s compatible device list, coupled with their virtualize-anything mentality makes them the one to beat in this comparison. There is much organizationally specific customizing and “branding” that can be done, as well. Citrix remains almost hyper-focused on delivering virtualized Windows-based resources to a staggering variety of possible interactive devices.

Before one starts, however, another battle starts that’s become more complex with the varieties of options Citrix offers: licensing, and the implications and gradients of extensibility, which are a function of the Citrix Netscaler line, which we did not review.

The difference between XenApp and XenDesktop is based on the concept of user/device, or concurrent use licenses. You can pick one model, or the other. Citrix goes to great trouble, more than 30 pages to explain the differences and their implications and “stretchyness”.

Architecturally, each organization has to decide which model fits their accessibility needs and budget. There’s a management app to deal with licenses, which might also be tied to other vendor’s licensing, say, Microsoft, SAP, or Oracle using similar “named user” vs. concurrent sessions/users/accesses.

Your legal department may want in on the considerations, along with finance. As both models may involve Microsoft Client Access Licenses (CAL) and application hosting costs, we advise the reader to do the math over the lifecycle of the licenses, hardware, and hosting costs to get a picture of what VDI actually costs. 

We tried XenDesktop on HyperV-3, XenServer 6.5, as well as VMware vSphere 6. There isn’t much difference between installation and use on these varied hosts/hypervisor operating systems. Citrix’s user-device app for remote access is Citrix Receiver, and it supports the same interaction across the five devices we used, including iPhone, Mac, Windows 10, Linux Ubuntu 14.04, and HTML access.

XenDesktop/App integrated well with the Windows 2012R2 Active Directory-based network we used to test, and its connection brokerage via Citrix StoreFront (included and highly customizable) to resources takes place quickly, meaning our sessions were authenticated and proxied to resources we had made, quickly.

The Citrix Receiver, the client side of viewing apps and VDI resources, worked uniformly well across the devices we used to test sessions and apps. The long list of devices supporting a Citrix Receiver is increasing, and the five types we used presented a uniform peripheral support and behavior across Citrix Receiver client devices. We found that if circuit transports have the same base speed, multimedia response is uniform, as well. In other words, we found the Citrix Receiver client behavior has great user experience consistency.

Citrix recommends use of its NetScaler products for widening turf. The atomic unit of administration and focus is the site. A Citrix Site has a delivery controller (running some version of SQL Server), a license server, Citrix Studio and/or Citrix Director (both connection broker/customization links) atop a Windows Server license. Installation of the basics is staggeringly simple, and unlike the other two products compared here, Citrix grabs all of the external bits needed and installs them on the fly, simplifying installation.

We built the site, and used Citrix Studio (included) to create the site, establish the database and logging to work with it, and set the resources that we could build for users. Citrix is glued to Active Directory like Velcro, and we found the resources needed to get our trial apps and desktop configurations developed with little trouble. There are many possible features to virtualize, and we found the process of thinking about the implication of enabling features to be occasionally daunting—usually from a practical support and security perspective. Citrix covers these issues well, and their docs and online help are fruitful.

The possible breadth of virtualized applications can be huge, if sometimes with optional hardware components. We tested the NVIDIA Tesla GPU adapter inside an HPE DL560Gen9 platform. The NVIDIA Tesla serves as a graphics adapter in our use, and permits the heavy lifting of doing combinations of raster/vector graphics inside the host so that virtualized apps under XenDesktop control in the host send almost ridiculously fast rendering.

While we eschew graphics benchmarks, the difference using ESRi (a GIS app) with and without the Tesla support (selectable) hosted then virtualized in the XenDesktop-Receiver circuit through broadband was simply startling to us. A side-by-side comparison of desktop app with, and without GPU support reminded us of the speed difference between an ISDN modem link and GBE.

Citrix was the only member of the group tested that supports this board, which is compatible with other hosts, but must be mated specifically to each hardware platform supported. For the narrow number of use cases that need whoppingly fast graphics, we’ve seen nothing faster, protocol-enhanced or not. The work is done in the host, not otherwise enhanced by a protocol, as has been done elsewhere.

We accessed our virtualized resources, as with others, in this comparison, from devices both in our lab (connected via broadband), but also at random locations like famous chain coffee shops, home offices, and in motels with bad Wi-Fi—the kind where you know everyone’s watching NetFlix instead of paying for TV.

We didn’t experience any session crashes on any device, except for our Samsung S3s, but we also cannot guarantee our telecom providers adherence to “the rules” as regards to DNS and session shifting. Receiver as an access method was very uniform as a virtualized screen to apps or desktops.

+ RELATED: Free download: A get-up-to-speed guide on VDI +

Citrix XenApp/XenDesktop hides much of its sophistication behind wizards that we found practical for delivering both apps to persistent/non-persistent desktops with even the latest Windows 10 builds, mutable as they are.

As Microsoft adopts more Linux-ish traits, we expect Linux apps and window managers/desktops to be found as virtualized resources. Our sense was that Citrix is ahead of the competition when virtualizing and presenting Linux resources. We like that we were in a very mature platform that behaved predictably. Predictable is good.

Parallels RAS 15

Of the three products tested, Parallels RAS was the most easily configured, yet has most of the features we expected—including the second longest list of supported host virtualization sources and client devices. We published apps, desktops, and shared resources quickly.

Parallels acquired the 2x RAS platform (along with MDM assets) in early 2015, then coupled the 2x platform with virtualization and cross-platform glue of their own, producing what is now Build 15 of Parallels RAS.

Unlike Citrix XenDesktop/App, Parallels runs on Windows 2003-2012 R2 servers and needs a variety of integration steps for the Windows server host operating system, depending on its vintage. Herein lies a catch: Don’t use older servers to host Parallels RAS.

We suggest that Windows 2008R2+ should be chosen as a host platform for Parallels RAS for security and integration reasons, also that these versions use Microsoft RemoteFX protocol, which behaves much better than the RDP protocol of prior versions and makes Parallels HTML5, VDI desktops, remote apps, and shared resources more responsive. During the middle of the review process, we received a Best Practices doc that helped us immensely and changed our expectations and outcomes.

+ MORE: Parallels Desktop 12 for Mac Gives Mac Users More Windows Functionality +

Parallels also uses Microsoft CALs (Client Access Licenses, required) and has clients for Windows 7SP1+, Mac OS, Android, iOS, certain versions of Linux, and ChromeApp for ChromeOS/Chromebooks. Like Citrix, we found strong uniformity in the behavior of proxied remote sessions through Parallels RAS.

The Microsoft-baked RemoteFX transport for data between host and client is important, and is enabled through Windows Group Policy Control, and therefore an installation requires administrative access to Active Directory policies. If the recommended settings aren’t enabled via Group Policy, then client/viewer peripheral support drags with lots of intermittent latency, rendering multimedia apps useless even on connections with much bandwidth.

The Windows Server Remote Desktop Feature also improves remote desktop latency dramatically. Why these weren’t a part of the installation procedure in the docs is a mystery, but these selections make a tremendous difference.

Like Citrix Receiver clients, Parallels client apps are available from typical online app store sources, and can also be sent as a link, but lack some of the customizations and “branding” permitted by Citrix and Ericom. Android and iOS client apps installed quickly.

Windows and Mac client access sessions were easy to initiate, and these stayed resident, waiting for our commands. We worried about cached credentials being alive, and recommend that users be instructed to logout when sessions are finished. Cached credentials might be seen as a security risk.

When using an RAS session of a Windows desktop, we had sizing issues both on Mac clients and Windows remote clients, but they weren’t too bothersome. On an Android tablet, things were slightly worse, but then better on an iPad 2. The differences between behavior and window sizing, as well as multimedia response on clients, are small.

The Parallels Web Portal administrative page allowed us to select and enforce SSH and secure-HTTP protocols, and can enforce transient sessions, where no information is stored on the client device. We could not ascertain whether a rooted device could expose temporary client files in the form of “tmp” or cache files, however. Our instinct would have us prefer pages where the strongest security default choices are made, forcing administrators to take ownership of less-secure settings.

Publishing apps and desktops requires systems infrastructure configuration—at least for the hosts and inbound/outbound firewalls, as is typical for VDI/app publishing. Parallels UI/UX makes comparatively short work of it, and we liked that most transport ports can be scrambled—their port addresses changed, to slow down security probers.

There was however, great difficulty when dealing with troubleshooting issues, and we didn’t have the confidence that we could track them down as easily as with XenDesktop or Ericom Connect. Indeed one headscratcher was totally missing from the support site, and client access troubleshooting error messages could not be found. We experimented and overcame all issues, but were troubled by the absence of what we considered to be critical support/help desk information as regards to troubleshooting and error handling.

The client side, although comparatively limited to Citrix’s Receiver offerings, was consistent and easy for us to install, using Parallels or an app store as the access method. Client-side automation of the installer can be accomplished but client/device app “organizational branding” is limited. This means that sending and scripting client-side manipulation is a bit more difficult, but not impossible.

In terms of scalability, we had the sense that Parallels RAS is likely to find strong use in small-medium, multi-locale operations. It seemed poised to target Citrix’s “low-end” in terms of pricing, but pricing will be complex for any of the three products we tested, depending on options used.

Parallels RAS is a rapidly deployable, capable application and desktop VDI platform. It’s the fastest way to get from A to B in this comparison, has great potential for smaller organizations whose customizing needs still need addressing, but may not need the breadth and width (and potential costs) of XenApp/XenDesktop.

Ericom Connect 7.5.2

Ericom Connect has a higher technical entrance point, meaning that the denominator of planning, install and admin skills needed to be initially higher than Parallels RAS. This ultimately pays, we found, as Ericom Connect has high flexibility in terms of both configuration, and the all-important remote device experience.

Once installed and configured after much study, however, Connect 7.5 offered us remote desktops via VDI or HTML5, and apps were easily delivered from Windows— although Linux narrowly so.

The Connect universe surrounds a grid app, which lives inside of a Windows server license, which is in turn very dependent on Active Directory. In multi-domain constructions, connectivity to all of the participating domains, trusted or not, is required.

A Connect Deployment Guide gives some architectural guidance as to planning infrastructure, how Active Directory fits in (everywhere), and how to dedicate resources in terms of partitions of the grid.

Grid resources and dependencies for which machines will be logged to what resources are the next concern, as this defines accessibility, multi-tenant constructions, down backup/restoration plans.

The grid is made alive through the use of a Connect Business Logic app, which performs dependency checks, configures the grid, and reports constituent services health to an Admin Console and Dashboard.

All this is important because once the grid is setup, it can handle many users (even with dynamic Active Directory external references), but the grid itself cannot be changed architecturally unless we brought the entire grid down.

This means halting the entire enchilada, quickly making a change, then restarting the grid. Restarting didn’t take long for us, but it wasn’t easy, either, and we didn’t test it with 5,000 to 10,000 users, who would have faced session restarts including authentication cycles.

This means: get things right, and schedule minor changes for a scheduled downtime (or face unhappy users unaccustomed to app instance crashes and the need for re-authorization/logon/authentication). There’s an additional laundry list of items that Ericom Connect needs to have installed in the server prior to bringing up the grid, including MS SQL Server, various .Net services, and considerations for how trusted domains will work when grids are installed and accessed via non-trusted domains. Yes, we did them, one piece at a time, grumbling, until all of the external puzzle pieces were in, up, and alive.

Once we got the infrastructure design correctly configured and brought the grid up, we could publish desktops of varying clients, which use Ericom’s Blast protocol (no relation to the one that VMware uses) to target devices. The user experience is understandable to configure, customizable (but not in the extreme), and was consistent across devices.

Unlike the other two platforms reviewed here, Ericom has explicit instructions on how to connect into Amazon Web Services or Microsoft’s Azure cloud, including how to setup and use a rented instance/license of MS SQL Server. This is VDI-as-a-Service, but we did not extensively test this.

Ericom can host Linux sessions through its grid, currently limited to Ubuntu 14.04.3 using xrdp, and Qt libraries. We needed to add Active Directory auth, and chose Power Broker Identity Service for authentication to the grid. We were able to get XFCE working as a Window Manager, but other UIs did not do well in terms of screen size and window management metrics. Accessing our single instance over a tablet was not joyful, even at broadband access speeds, but we did not deep-dive into adjustments that may have made more astute connections, just followed suggested defaults.

Ericom supports port scrambling, making hosts more difficult, but certainly not impossible to port-probe successfully. We were offered good suggestions (sometimes more like urges) to use DMZ-based hosting, so as to add layers of penetration resistance, good reminders. Ericom Connect makes good use of certificates, and provides good warnings regarding making clones for VDI terminal session hosting—so as to keep things both patched and certificates “fresh” for session services. It does not, however, provide certificate banking/repository services innately. RADIUS protocol authentication as a proxy to Active Directory is also supported, but we didn’t test this.

Ericom uses an admin console for Connect not unlike the one used by Parallels RAS. There are green, yellow and red lights indicating various elements of health. Sometimes we had a comfort with what red and yellow actually meant, but as there is an enormous variance in possible connection scenarios, we didn’t get a feel that we could immediately troubleshoot/diagnose problems easily, and Ericom docs and help screens aren’t especially helpful in this, as they didn’t design some of the construction—we did. Researchers: heal thy self.

We had a feeling that the Ericom Connect components would suit the needs of large department to enterprise-class installations. It’s very Windows-centric, but has made small steps toward hosting Linux resources as well—although we felt as though it were an experimental feature, confined to very finite Linux support. This said, the client side of the experience was solid, and the admin side would meet most needs. Internationalization was solid; Ericom is an Israeli company.

How We Tested VDI

We used XenServer 6.5, VMware ESXi 6, and Microsoft Windows Hyper-V3 (Datacenter Server 2012 R2) hosts utilizing either vendor-supplied VMs payloads, or installations on Windows 2012R2 DataCenter hosts for VDI hosts on a Gigabit Ethernet network switched by Extreme Networks Summit Series L2/L3 Switches, then onto a core network connection at our NOC host, Expedient, in Indianapolis/Carmel, Ind.

Clients included Windows 10 (native on Samsung and Lenovo notebooks, also on VMs), Macs (Macbook Air, Macbook Pro running OS X 10.11), iPhone (5C running iOS 9.X), Android (Samsung Galaxy Note and S3), and a Toshiba Chromebook. These were run over Comcast/XFinity broadband, as well as a Wireshark-monitored connection at a coffee shop in Bloomington, Ind., known for its mercurial network demands.

We published Windows (Paint, ESRi GIS, Word, Media Player), two Linux apps (Gimp and Thunderbird) and two Mac (iPhoto and iTunes) applications where products permitted.

We attempted to use native VDI clients where possible, and additionally, HTML5 access where products permitted this. Firefox, Safari, Chrome and Edge browsers were used on notebooks and a Chromebook; Chrome and Firefox on Android, and Safari browser on iOS9. We used our own Apple Push Notification Certificate where appropriate.