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!

QShell is an 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. 

This is program is wirtten by myself and is not an official Quest release and therefore cannot be supported via the normal Quest channels.  You should use this program at your own risk, however if you have any issues or requests I will endeavour to help where possible.

Download the guide here: QShell Admin Guide

Download QShell here: QShell 1.0.6.12

DownloadQShell and AppPortal
DownloadQShell and Internet Explorer

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.

As of the start of 2009 Microsoft have renamed their Thin Client operating Systems. Windows XPe has been renamed to Microsoft Windows Standard Edition and Windows CE has been renamed to Windows Embedded CE.

There are several caveats when embedding the client onto a Thin Client:-

• i) We currently maintain binaries for Windows CE 5 and 6, for older versions of CE we would need to compile a client.
• ii) The Linux client is based on the 2.6 kernel.
• iii) Windows XPe is typically and open OS and has the capability to install applications locally, therefore in theory we should be able to install our 32-bit client onto any vendor’s XPe Thin Client.

Thin Client Manufacturers
There are a multitude of Thin Client vendors in the market place, all of which have their own individual strengths. I have listed the vendors below and covered the functionality they currently offer:

10zig - 10zig offer Thin Clients with Windows CE, Linux and Windows XPe. They ship the Quest vWorkspace 6.x client as standard on their Linux and XPe devices, the V series is a range of devices that are optimized for a VDI environment.
http://www.10zig.com

Computer Labs International - Computer Labs offer Thin Clients with Windows CE, Linux and Windows XPe, they can provide the Quest vWorkspace client on all three operating systems.
http://www.computerlab.com

HP - HP offer Thin Clients with HP ThinConnect, Windows CE, Linux and Windows XPe, they can provide the Quest vWorkspace client on ThinConnect, NeoLinux 3.x\4.x, Windows CE and Windows XPe. In October 2007 HP acquired Neoware, thus integrating their Thin Client portfolio into the HP range.
http://www.hp.com

Igel - Igel Technology offer Thin Clients with Windows CE, Linux and Windows XPe\Embedded Standard. They can provide the Quest vWorkspace client on Linux and Windows XPe\Embedded Standard. Please refer to the separate Igel blog article for more details.
http://www.igel.com

Sun Microsystems - Sun have developed a session script that resides on the Sun Ray Server, this script interacts with the Quest vWorkspace connection broker. The Sun Ray Terminals need to be configured to use a Kiosk Session, they can then connect to a VDI or TS desktop via the Sun Ray Server.
http://www.sun.com

Thinspace - Thinspace have a range of Linux and Windows XPe terminals that include the Quest vWorkspace client as standard. Please refer to the separate blog article on their inclusion of the 6.2 Linux client.
http://www.thinware.it

Thinware - Thinware have a range of Linux terminals and include the Quest vWorkspace client on their devices as standard.
http://www.thinware.it

Wyse Technology - Wyse Technology offer Thin Clients with Wyse Thin OS, Windows CE, Linux and Windows XPe. Windows XPe supports the Quest vWorkspace client and Wyse ThinOS uses its native RDP client to connect to a desktop (VDI or TS) based on a connection allocated by the connection broker.
http://www.wyse.com

Extended client support
The Quest vWorkspace client is available as a Java Client so in theory this could run on any Thin Client offering a Java Virtual Machine. We also offer a U3 Client meaning you can simply copy the files to an XPe based terminal, or a U3 enabled USB stick, and launch AppPortal without having to install it.

Some of the Quest vWorkspace clients do not offer the same functionality as the Windows 32-bit client, it is advised to contact Quest Software or the Thin Client vendor to ensure your functionality requirements are met.

Quest vWorkspace client Installation
If a Thin Client doesn’t offer the Quest vWorkspace client as standard it may be possible to install it yourself. This should be straight forward for Windows XPe as most vendors will supply information to customers explaining how to install applications locally. As for Windows CE or Linux you will need to contact the specific vendor as some vendors will supply a read only operating system that would prevent you being able to install applications locally.

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 »