RingCube vDesk 3.2 VDI Edition Creates User Options

The latest offering from RingCube creates a VDI client that can be customized for each user, but still enables pooled licenses, easy updates and centralized control of settings.

• By Logan Harbaugh
• 03/01/2011

Virtual Desktop Infrastructure (VDI) is the latest attempt by IT centralization aficionados to return to the mainframe terminal. Rather than running the OS and applications on a local PC, they're executed on a server. This allows admins to control configurations of the OS and applications, block unlicensed or risky apps, use a pool of licenses, store only the basic OS configuration and in general more easily administer systems.

Users, on the other hand, are often dismayed to find they can't modify their systems -- even to the degree of changing the default view in Windows Explorer or Outlook, or switching to a different desktop wallpaper -- because changes will be deleted at the end of the current session.

VDI that can store individual preferences may require a separate image for each user, which increases the space required, the management overhead and the number of required licenses -- and that negates much of the raison d'etre of VDI.

RingCube seeks to create a solution that offers the best of both worlds with its RingCube vDesk 3.2 for VDI Edition. With version 3.2, for example, pooled licenses may be used to buy 30 licenses for a group of 50 users, knowing that no more than 30 people are likely to be using the software at any given time. These licenses are controlled through the VDI server, rather than being installed individually on each workstation. Pooled licenses require a VDI-type environment, and the usual VDI environment doesn't maintain user settings past the shutdown of any given session.

System Components
The system has three basic parts: the vDesk Admin Server, a workstation to take images and the VDI server. VMware View and Citrix XenDesktop are supported, although other VDI servers that are unsupported but will work include Oracle VDI Core, Ericom PowerTerm, Virtual Computer NxTop and Microsoft Enterprise Desktop Virtualization. The Admin Server can be a Windows Server 2003 or Windows Server 2008. Windows Server 2008 R2 is not yet supported.

The workstation has to be a 32-bit version of Windows XP, Windows Vista or Windows 7. Users can run the vDesk Client in standalone mode on a 64-bit PC that has virtualization support, and also use a Workspace that contains a 64-bit OS; however, running a 64-bit OS through a VDI server such as VMware View or Citrix XenDesktop is not yet supported.

The vDesk client is installed on a client system and used to create an image of that system, which RingCube calls a Studio Workspace. RingCube recommends that the workstation initially be a fresh install of Windows XP or Windows 7, either on hardware or in a virtual machine (VM) running on VMware 3.5 or 4.x, Hyper-V, or another virtual environment such as Xen or a Kernel-based virtual machine (KVM). The company also recommends against installing an antivirus client, saying antivirus should run on the system hosting the image, rather than on the image itself. If this is an issue for admins, the antivirus client can run on the image -- this is just not recommended due to the low-level actions taken by some antivirus clients.

Once an image is taken, it can then be configured as desired, including apps. After everything is set up, the Workspace can be made into a Master Workspace and distributed as desired to users or groups. Depending on which VDI server you're using, you should set up Random Pools for Citrix Xen Desktop 5 or Stateless Floating Pools for VMware View 4.5.

While admins might want to use existing images that include OSes and applications, this doesn't allow the vDesk Client to track the changes made while configurations are changed and applications installed. It's necessary (the first time) to recreate the OS image before it can be turned into a Master Workspace.

Getting Started
The install process is straightforward. The Admin Server installer is run on a Windows Server, which can run on a physical system or a VM. Then the Admin Server is administered via an HTTPS connection over a specific port (9443). Once installed, the Admin Server is connected to Active Directory, and users or groups that will access the Master Workspace are created. The space necessary to store the Workspaces must be set up at this point. This can be done via a network share on a local disk, or on a remote network share on another server.

Next, the vDesk client is installed on the first image system -- a fresh 32-bit Windows XP, Windows Vista or Windows 7 system -- and an initial Studio Workspace is created. Once the Studio Workspace is created, admins can make all the necessary changes to make the desired OS image. As part of configuring the studio, users don't join it to the domain. This is done after the image is turned into a Master Workspace by enabling Domain Join via an Admin Server policy.

Once configuration of the OS image is complete, the Workspace is turned into a Master Workspace via a simple, one-button process. Once created, a Master Workspace can be assigned to users or groups imported from Active Directory. For test purposes and debugging, the vDesk client can launch a Workspace directly from any Windows client system, although the vDesk 3.2 for VDI Edition is intended to be used with a VDI server.

For communications between terminal sessions and VDI servers, the expected protocols are supported: Remote Desktop Protocol (RDP), PC-over-IP (PCoIP) or Independent Computing Architecture (ICA) for Windows XP; and PCoIP, ICA or High Definition User Experience for Windows 7. RDP is not supported for Windows 7. The final step is installing the vDesk Client on the base VM running on the VDI server, and configuring the VM to automatically launch the vDesk Client.

[Click on image for larger view.]

Figure 1. Once a user logs into the vDesk client, it's activated and gives access to a virtual desktop with any applications and settings that the user has installed over the base image.

User Experience
The first time the Workspace is used, end users log into the VDI VM, using a pool that's been configured to launch the vDesk Workspace. They're then prompted to log into the vDesk Workspace to activate it. This process can take up to half an hour the first time the client runs, as all the settings, programs and files are copied from the network share to the local system. After that first time, the process is much quicker -- RingCube recommends that the Workspaces be pre-deployed, in which case the activation process should take less than 10 minutes.

Also after the first time, all changes to the base system made by users are reflected only on their specific Workspaces. They can access that Workspace from any system -- even a portable system that's connected to the network intermittently -- and the image can be checked out before leaving the network, and then checked back in the next time the portable system is connected to the network. This process can be manual and left to users, or admins can designate some users as travelers and force a check-out with each shutdown, though this extends the time to shut down the system. Workspaces can be synced without being checked back in, allowing changes to documents and other settings to be added to the network share.

Workspaces can also be encrypted and exported to USB keys, which allows end users to travel without a company laptop by simply plugging the USB key into any system they use. Once users return and re-sync their USB keys, any changes, documents created and so on are added to their usual Workspace.

RingCube vDesk 3.2 for VDI Edition lets admins have their cake and eat it too, providing the functionality of separate instances of Windows for each user while retaining the pooled licenses and central administration of the VDI model. The cost of $95 per user should be quickly recouped in savings on administration costs -- and also by enabling the use of pooled licenses.