Like XenDesktop, VWorkspace works with many VM server platforms, including Virtual Iron, VMware ESX/vCenter, Microsoft Hyper-V, Parallels Virtuozzo, and also supports Microsoft Terminal Services. External (meaning remote) access uses a vWorkspace SSL proxy gateway that's installed on a dedicated gateway Windows 2000/2003 server in a physical or virtual machine.

The gateway's ability to use X.509 certificates, trusted root certificates, and certificates generated from the Windows 2000+ certificate authorities was a strong security benefit. Most of the products we tested used either their own authentication or Active Directory's username/password/domain authentication regimen.

Desktop time availability was an additional option that made a lot of sense to us and was unavailable elsewhere.

The vWorkspace product requires Active Directory in place, and requires a number of policy and setup steps to get it running, similar in nature to Sychron OnDemand.

Once installed, the Quest vWorkspace Management Server can then track applications, documents (even Web pages), and the use of desktops; in our case, virtual desktops. From its console, we selected our platform, then created groups of VMs that we could make 'temporary' (non-persistent) or persistent VMs for VDI use. The vWorkspace manager can also create relationships with individual machines (think blades in blade servers), or other hypervised platforms for VDI use.

Clients can connect through the vWorkspace AppPortal, a separately installed application, or via another application called WebAccess. Microsoft's IIS 6+ Web services must be alive, along with ASP.NET and .NET Services 2.0+. We used the AppPortal which works only with 32-bit clients, and logged in via Active Directory authentication.

The clients aren't easy to setup to connect with the vWorkspace server/broker. In order to make it easier, you have to setup something on the default DNS server to point to a "provision.your.domain.here" entry. If WebAccess is installed, it should automatically download a configuration file, otherwise, you must enter the server IP address, and supply username/password/domain name credentials to configure the client to connect correctly to the service provided.

We had difficulty when auto-provisioning the copies of the Windows XP VM that were created. Numerous copies that were created didn't join the domain when launched, and we had to manually join the VM to the desired Active Directory Domain in about 10% of the copies.

The overall responsiveness of the client experience was good, but the YouTube video test showed lots of lags and video/audio synchronization errors. Non-multimedia use, however, was fine and reasonably fast.

OUR VERDICT

The Quest vWorkspace has a larger-than-VDI control plane, and the control provided for VDI use was strong, as were the security considerations Quest gave to the product. Clientside use is good, if poised towards non-multimedia use.