Overview
Quest vWorkspace offers clients on a multitude of platforms making it a natural choice for Thin Clients. Thin Clients typically come in one of three flavours, these are Microsoft Windows CE, Linux and Microsoft Windows XPe. However, some manufacturers have developer their own operating systems, for example Wyse Thin OS and Sun Microsystems Sun Ray.

This article details native vWorkspace client availability from the different Thin Client vendors.

Read the rest of this post »

QShell is a free application to improve the log in experience for vWorkspace users on thin clients and end of life hardware where you want to provide a PC’s like log in experience to a virtual desktop. It can provide a single sign on experience removing the client devices original desktop, start menu, task bar and desktop icons.

Read the rest of this post »

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.

Quest vWorkspace 6.0 introduced a little known yet valuable new commandline option for the vWorkspace AppPortal Clients called the “autodelete” option. Let’s take a quick look at what this option does. If you add the /autodelete parameters to the command to start AppPortal (for example “C:\Program Files\Quest Software\vWorkspace Client\pnap32.exe” /di /autodelete” ) all farm definitions will be deleted and the AppPortal Client will be reconfigured using the auto-configuration feature of vWorkspace. For more information on how to auto-configure vWorkspace clients read this blog post.

Our customers typically use this feature if they want to have central control over configuration of all clients without the need to visit or connect to each client machine. Updating the configuration of 1000’s of clients becomes a breeze using the auto-configuration feature of vWorkspace in conjunction with the /autodelete parameter!

Huy (pronounced “we”) Nguyen, our Sr. Technical Support Engineer has put together a document that details “one way” of how to configure Smart Card Integration (with smooth roaming) for XPe Thin Clients.  Here is the intro:

An End-user walks up to XPe Thin Client, slides Smart Card into card reader.  The End-user enters his/her PIN, gets authenticated against AD and logins to the thin client.  Provision Networks Virtual Access client will automatically launch, authenticate the user against the Connection Broker and based on what the ACL is set to automatically launch the end-user’s Virtual Desktop.  If the End-user’s Virtual Desktop was in a Disconnection State, the End-user will reconnect to that Virtual Desktop.  Once the End-user is done with his/her Virtual Desktop session, all he or she needs to do is unplug the Smart Card from the card reader.

Based on Microsoft GPOs set on the Thin Client OU and VDI OU, the Virtual Desktop will enter into a Disconnected State and the thin client will Log Off.

The End-user can then walk up to a new Thin client, slide in their card and the session will be reconnected and the end-user can continue their session.

The full document can be found here:

Provision Networks Connection Broker SmartCard Integration with Smooth Roaming

Configuration of the Wyse Thin OS (WTOS) is completely controlled via DHCP and ini files on the connection broker, so these devices can literally be taken out of the box, plugged in and they will automatically boot, download new firmware (if available), contact a connection broker, then launch a desktop.

So what needs to be configured in DHCP:

DHCP Option 188 is used to list the addresses of each connection broker, and the XML Communication Port. DHCP Option 161 lists the servers that hold updated WTOS Firmware. Since Provision Networks Connection Brokers can do both of these, once may configure either or both options. In the screenshot above, only option 188 is configured.

On the connection broker(s) browse to %ProgramFiles%\Provision Networks\Wyse. Create a sub-directory named “WNOS” (case sensitive). In the WNOS directory, create two sub-directories, “ini” and “bitmap“

Use notepad to create the two ini files listed in the WNOS directory.

wnos.ini contents:

signon=1
autoload=1
autosignoff=yes
privilege=High
Domainlist=YourDomainName

————————————————–

rdp.ini contents:

Fullscreen=yes
Colors=high
Encryption=128
Experience=15
Lowband=no
Autoconnect=1

————————————————–

To update the WTOS Firmware, copy the new firmware (RCA_wnos) to the WNOS directory, and set “autoload=1″ on the wnos.ini file.

At this point, the basic configuration is completed to connect a WTOS Thin Client to a Provision Networks Connection Broker. If one has multiple connection brokers, list them in the DHCP options and copy the contents of the Wyse Directory to each additional connection broker. There are many options available in the ini files, so detailed instructions are in the documents listed below:

Enhanced Support for WYSE Thin OS

WTOS 6.1 Admin Guide

In a previous post we talked about how you could configure the Quest vWorkpspace client to automatically get configured. The actual configuration is stored in a file called CONFIG.XML. Basically every single client setting can be controlled trough CONFIG.XML. Our support engineer Stephen Yorke provided us with a ton of infomation so this post describes all the different settings that are available, what they mean and what possible values they can have. Use this document as a guideline to create your own CONFIG.XML. Do not use it as a source CONFIG.XML. Use the sample CONFIG.XML located on each vWorkspace Connection Broker at C:\Program Files\Quest Software\Provision-IT as the source for your customer CONFIG.XML.

Read the rest of this post »