Techtarget is hosting a webcast that will be about Quest vWorkspace. It will be hosted by Brian Madden (no introduction needed) and Peter Ghostine, the Quest Desktop Virtualization Group CTO. Virtual Desktop Infrastructure (VDI) is generating huge interest from organizations seeking to lower the cost and complexity of managing their desktop infrastructure, but…VDI is NOT the end all be all! Come hear Brian Madden (BrianMadden.com) and Peter Ghostine (Quest Software) on July 30th, 12pm (EDT) as they discuss the future of desktop management being a flexible hybrid approach of physical and virtual to meet the ever-changing needs of diverse user populations. Quest vWorkspace is uniquely positioned to offer you the future of desktop infrastructure and simplified management today via a single product. The competition requires multiple products, if they even have an offering, which means increased costs, complexity, and manageability!

It starts in little over an hour but you can view the recording as well. Use this link.

I recently used the ‘task automation’ feature of vWorkspace to assist with a customer solution. This came in very useful and allowed us to remotely modify the virtual desktops registry; I thought it would be beneficial to share this.

It is possible to schedule a task for a group of desktops or an individual desktop. To access the task automation screen right click a group or desktop and select properties and then task automation. Select new to create a new task, under the task section select ‘Run Program/Script on Computer’ and then under task parameters you can specify the relevant settings. I used this feature to remotely execute regedit.exe and import a .REG file from a network file share. This is simple feature but saved us a lot of work as we had 200 virtual machines that required this registry change.

The screenshot below shows and example of the parameters page might look:

A task can be configured to execute once or can be made re-occurring.

Part of the extensive feature set of Quest vWorkspace is the ability to allow anyone access to vWorkspace hosted applications regardless of their location or client device. To make sure that everyone is able to securely use vWorkspace hosted applications, Quest vWorkspace ships with a SSL Gateway to secure (encrypt) all vWorkspace related traffic. The Quest SSL Gateway uses a server certificate to secure all vWorkspace related traffic. As you probably know, due to the nature of any certificate infrastructure, the ROOT CA needs to be trusted on the client for the connection to be securely established. In production environments this poses no problem at all since commercial certificates are typically used of which the corresponding ROOT CA typically is already automatically trusted.

In POC or test environments however, commercial certificates are used less often. Quest vWorkspace is perfectly able to deal with these so called “private certificates”.  To use private certificates with the Windows vWorkspace client, the corresponding ROOT CA of the private certificate needs to be trusted on the client. If the client machine is a member of the Windows domain that the ROOT CA is in, then the certificate is automatically trusted. But what if you are connecting from a Windows client that is not in the same domain as the ROOT CA is? In that case, the ROOT CA needs to be trusted by the client (manually). Since obtaining and importing the ROOT CA certificate can be somewhat of a difficult task for the average user, Quest vWorkspace Web Access has the ability to help out here.

One of the features of Quest Web Access is the ability to host any kind of download (next to the vWorkspace client). One way to make it very easy for users to trust the ROOT CA of the Quest SSL Gateway server is to host the ROOT CA certificate on the Quest Web Access download page. Here’s how to do this:

1. Obtain the ROOT CA certificate. How to exactly do this depends on your setup and is beyond the scope of this article but this article will most certainly help you out: http://technet.microsoft.com/en-us/library/bb735413.aspx

2. Copy the certificate (make sure it is saved as an .crt file) to the following location on the Quest Web Access Server: “C:\Inetpub\wwwroot\Provision\web-it\clients”

3. Log into the Quest vWorkspace Web Access admin page and create a new download like depicted below:

4. Now when users log onto Quest vWorkspace Web Access they are able to download the certificate right from Quest vWorkspace Web Access:

After you download and install the certificate you can use the vWorkspace SSL Gateway using your private certificates.

Stay tuned for part 2 where we will discuss the same approach for the Java client.