Ericom Software have announced a number of solutions to allow organisations to deliver VDI access to a wider range of devices. Ericom joined a number of other vendors such as 2x, Citrix and Quest, in offering a free mobile client – AccessToGo – which is available on the iPad, iPhone, iPod Touch and Android tablets and phones. AccessToGo supports RDP and VMware View, but also Ericom’s Blaze RDP accelerator and Ericom’s own PowerTerm WebConnect client.
Perhaps more importantly, Ericom have also announced the general availability of their patent-pending HTML5 client, AccessNow. AccessNow provides web-based access to a range of RDP based virtual desktop solutions – be they hosted desktops such as VMware View or session based desktops in Microsoft’s Terminal Services/RDS.
With Apple’s iPad driving the rise of the tablet as a corporate device, the focus of virtualised desktops has a renewed emphasis on the martini factor: application and desktop delivery anytime, anyplace, anywhere. While Citrix’s marketing department could well be getting misty-eyed, it is true to say that the mobility and agility that newer devices – not only Apple’s iPad, but Google’s Chromebook or Cisco’s Cius, even user’s own personal computers, can offer organisations savings through reduced office space and greater productivity.
Yet, supporting a range of devices can itself be a headache. How do you manage the end device’s access software? How do you enable secure access? Can you give your users flexibility and mobility to access their desktops from anywhere?
In this article, we take a look at the issues of supporting a range of devices and consider the advantages and disadvantages of a browser based client, such as Ericom’s innovative AccessNow.
Why Not Just Write Another Client?
To be fair – AccessNow is “another client”. An HTML5 client. With AccessNow, Ericom have worked to deliver a more “universal client” and are the first to offer a generally available solution in HTML5.
An advantage of virtual desktops is that they allow you to provide access to applications and data without installing corporate applications and data directly on the end device: a very secure solution. The remote protocols also allow it to be a “bandwidth lite(r)” solution: an accessible solution.
However alluring the Martini factor is, you do need to drink-in the factors responsibly. Access relies on the end device having the appropriate client software. This gives a number of challenges:
- How do you maintain the client between devices so that the user experience is consistent and reliable?
- How do you deliver that client?
- How do you manage that client’s settings?
- How do you ensure access and authentication is secure?
Creating a client for each device is time consuming and complicated. Microsoft solve the solution for RDP access by supporting any device .. as long as it is running a Microsoft Desktop OS. It has been left to third parties to support a wider range of devices. In the past, Citrix has been at the forefront of supporting wider client access, but other vendors are matching support for Android, Blackberry, iOS, Linux, OSx etc. Web based clients have been available before – but such clients also suffer from a common issue – what access privileges do you need to install the components? What browsers are supported? What client OSes? Supporting a range of devices is complex and costly to develop and maintain in addition, there will be a delay when a new device type comes out while the ongoing popularity of that device is assessed.
Java was hailed as the solution to such issues. Write a Java client and then each device simply needs Java. A Java client runs within the Java runtime, a Java client can be centrally deployed via a browser. The Java client will be the universal solution! Huzzah!
Apple’s iPhone changed the smartphone industry and the iPad changed the tablet industry – but iOS does not support Java. Neither does Android. A Java component would allow a wide range of software to be run on these devices, yet that software would run outside of market-place offerings – reducing “quality control”, “security” and “revenue opportunities”. A browser based delivery mechanism for remote access should not rely on additional applications to complement the browser’s built-in functionality.
HTML 5- This Time Its Multimedia
HTML5 is the latest revision of the HTML standard. As of the time of writing, it is still a work in progress. HTML5’s core aim was to improve the language with support for the latest multimedia – but still be readable.
The death of the desktop at the hands of the Internet has been hailed many times, and likely will be again. I for one will welcome our new application and data delivery overlords; when they come. Pure browser based application delivery itself has a number of issues. Browser compatibility and support for standards (IE6/IE7/IE8/IE9 anyone?) , the requirement to have ‘helper’ applications installed (such as Adobe’s Flash, Oracle’s Java or Mircosoft’s Silverlight ) – can combine to make application delivery with browsers almost as complex as ‘traditional’ applications.
That said, not all applications are browser based. Corporations still have a range of applications that rely on running in a Microsoft OS environment.
With its far richer language HTML5 could reduce application delivery complexity and natively allow greater breadth of application delivery via a browser interface. At the same time, with a HTML5 remote client you could maintain access to applications that are yet to be ported to a pure web based delivery mechanism.
AccessNow for the science part
Ericom are the first to deliver a product that provides access to Windows applications and desktops running on Windows Terminal Services/RDS / VMware View platforms directly from Chrome, Safari, Internet Explorer (with Chrome Frame plug-in), Firefox, Opera and other browsers with HTML5 and WebSocket support, without any plug-ins required. Ericom AccessNow has three components:
- The AccessNow server (a WebSocket server) which is installed on the RDP/View hosts.
- (Optional) Ericom’s Secure Gateway Service that provides secure, encrypted remote access to desktops and application
AccessNow: Notes From the Field
I’ve had a chance to field-test the service – putting up a Microsoft RDS server in “terminal services mode” and installing the components as defined in the architecture described above.
I found the process of configuration and installation straightforward for the simple environment I had. However, the default configuration assumes that the user understands what resource they are connecting to. This may work well for small environments, or for a limited number of users, but for large environments AccessNow will have to integrate into a wider interface that allows users to access generic resources (e.g. Windows 7 Desktop, Accounts Application) rather than explicit resources.
I used all the components mentioned, including the secure gateway. This was because – without that component users would have to be able to access additional ports beyond http/https: the network connectivity at their location may prevent this.
Performance was acceptable for application based work. Full multi-media delivery was less acceptable. I only tested the simple RDP connectivity with no Blaze optimisation. In that plain RDP environment the HTML5 client struggled displaying news videos for example in comparison to native RDP. That said, this is v1 and I enjoyed the reminisce of what an early terminal services access experience was like. You can have a look at the experience on the following videos
This video shows a logon session using Chrome running in a win32 environment
What was perhaps most intriguing, was the range of HTML5 experiences from browsers. IE9 requires a chrome component installed, Firefox and Opera both need configuration changes. Of all the browsers tested only Safari and Chrome worked without change.
You may be asking, “do you have access to cut and paste, to client resources (such as printers, USB drives, cameras)?”. No – not in this current release. It is fair to say that not all users require such connectivity but again, v1.0.
The AccessNow HTML5 client is not as feature rich as more traditional remote desktop clients, but it is low maintenance from an administrative point of view and does offer the possibility of a wide simple access using simple and cheap netbook/notebook/terminal environments.
Anytime, anyplace, anywhere?
Virtualised desktops allow you to provide access to your resources on devices not controlled by your organisation, or sat within your buildings. Ideally everyone has the same access method, using the same device with the same client. In reality, there is a business-need to utilise a range of devices appropriate to the business function at the time.
Ericom’s AccessNow product can and does deliver access to RDP based sessions (be they Microsoft RDS, VMware View, etc) within an HTML5 browser. This does provide a standardised access method from a range of devices. But, that range is not ubiquitous today although this may of course change in the future. In the first instance, those devices need to support and have installed an HTML5 client. In the second, they currently need to have a physical keyboard. You will likely require the Ericom’s Secure Access Gateway: it would be interesting to test other SSL VPN solutions such Juniper or F5, or even Microsoft’s Unified Access Gateway.
Still, with AccessNow Ericom are the first to deliver an HTML5 client. An HTML5 offers the option of organisations delivering access to services not only from personal devices, or kiosk terminals, but from the growing range of devices that have a browser as their core OS such as the Chromebook. At the moment, this is a free trial for the RDP client and for VMware View – I’d recommend a look. n terms of licensing, AccessNow for is priced either per named user or concurrent, or as a Software-as-a-Service offering. If you already have a PowerTerm WebConnect license, AccessNow is included as a client for PowerTerm WebConnect at no additional cost.