Just as a quick heads-up, for those of you that were not aware yet, recently we released MR2 (Maintenance Release 2) for Quest vWorkspace Web Access 6.2. Be aware that this is an update specifically for the Web Access component of Quest vWorkspace 6.2, not for other components of Quest vWorkspace. Next to the necessary hotfixes, there’s also one cool updated feature in there.

This updated feature allows you to hide a vWorkspace Web Access download from unauthenticated users. As with many features in vWorkspace, this makes a lot of sense. For example: you might only want to make client software, company certificates or other downloads (because vWorkspace allows you to host any download you need to your users) available to your - so authenticated - users and not to anyone that happened to come to your Web Access page.

Since MR2 fixes a fair amount of issues, we strongly recommend to everyone using Quest vWorkspace Web Access 6.2 to apply it. Before you do though, please read through the entire associated release notes.

MR2 (Maintenance Release 2) for Quest vWorkspace Web Access 6.2, as always, can be downloaded from the download section of vWorkspace.com under the “hotfixes” section.

One of the unique features of Quest vWorkspace is our User Profile Management. Quest vWorkspace User Profile Management (previously known by the module named Metaprofiles-IT) when implemented in concert with Microsoft Group Policy Folder Redirection provides a stable alternative to Roaming Profiles. Often referred to as Hybrid User Profiles, it allows users to retain administrator approved portions of their user profile, (typically stored in the registry) whereas everything else, including the local user profile is discarded at logoff. Users My Documents, Desktop, Application Data and optionally Start Menu are typically redirected to network file shares using Group Policy (they can also be stored using Quest vWorkspace User Profile Management), whereas the vWorkspace User Profile Storage Server manages settings that are imported to and exported from the User Registry Hive (HKCU). This unique combination provides for lightning fast logons (typically 10 seconds, or 1 -2 seconds longer than a local profile), lower data storage requirements, and a stable working environment that looks and feels personal to the end user. The cool thing is that you can create a Managed Profile for Terminal Servers users, Virtual Desktop Users, Blade PC users or all of the above!

Quest vWorkspace User Profile Management data is stored on the vWorkspace User Profile Storage Server in an encrypted manner so there is no easy tampering with user data. This does however also mean that the user data cannot be opened by administrators for troubleshooting. Sometimes administrator do need to view the Quest vWorkspace User Profile Management data. There is an easy way to do this, should you need to:

1. Go to the  vWorkspace User Profile Storage Server and locate the  vWorkspace User Profiles directory (C:\Metaprofiles for example).
2. Copy the profile that you want to troubleshoot. Profiles are stored with SID as the file name. You could use a a tool like PSGetSid to determine what SID translater to which user.
3. Rename the copy from .grp (for per-silo settings) or .gbl (for global settings) to .zip
4. Now open the .zip file and you can look inside the Quest vWorkspace User Profile Management data to perform your troubleshooting. It should look like something like this:

All the folders (like Desktop in the screenshot) you see are the folders that are configured for inclusion in the Quest vWorkspace User Profile Management configuration.

The file “dir.txt” contains all of the files inside the folders that are synchronized as part of the Quest vWorkspace User Profile Management configuration.

Finally and probably most importantly “reg.xml” stores all of the registry keys and values that have been configured for inclusion in the Quest vWorkspace User Profile Management configuration.

Please be aware that this method should only be used for troubleshooting purposes. Changes to the Quest vWorkspace User Profile Management should always be made through the vWorkspace Management Console in the Quest vWorkspace User Profile Management configuration. Directly editing the profile is not recommended nor supported.

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.

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

Using Quest vWorkspace Web Access is a very popular way to provide users with a single consolidated entry point to all their applications and desktops. Here’s a tip to make it even easier to use Web Access.

The default URL for Web Access is http://<webservername>/provision/web-it . Not exactly the easiest URL to make users remember. Here’s how to make life a little easier. The first method uses aspx (which is our best practice)

1. On the Windows Server 2003 webserver add default.aspx as a default document. Refer to this Microsoft article on how to do this exactly. The short version is to just open the IIS manager and from the properties of the websites, select the documents tab and add default.aspx as a default document (try using the “move up” button if it does not work for you):
   
2. Create a file called default.aspx in the root of your IIS webserver (c:\inetpub\wwwroot) with the following text:

   <%@ Page Language="VB" %>

   <% Response.Redirect("/Provision/web-it") %>

Alternatively, you could Java to achieve the same goal. To use Java:

1. On the Windows Server 2003 webserver create a file called default.htm in the root of your IIS webserver (c:\inetpub\wwwroot) with the following text:

<noscript>

<meta http-equiv="refresh" content="5; URL=provision/web-it">

</noscript>

<script language="JavaScript">

<!--

var sTargetURL = "provision/web-it";

function doRedirect()

{

    setTimeout( "timedRedirect()", 0 );

}

function timedRedirect()

{

    window.location.href = sTargetURL;

}

//-->

</script>

<script language="JavaScript1.1">

<!--

function timedRedirect()

{

    window.location.replace( sTargetURL );

}

//-->

</script>

<body onload="doRedirect()">

</body>

</html>

Whatever option you use, when this is done users are redirected to http://<webservername>/provision/web-it when they just enter the name of web server in the address bar of their internet browser. You could be even smarter with this and create a DNS record or alias for the Quest vWorkspace Web Access server and allow users to come to the Quest vWorkspace Web Access webpage by just entering something like “wa” into the address bar of their browser. How’s that for easy?

Just as a quick heads-up, for those of you that were not aware yet, recently we released the first hotfix rollup pack for vWorkspace 6.0 (affectionately called Hotfix1). It fixes a fair amount of issues and we strongly recommend to everyone using vWorkspace 6.0 to apply it. Before you do though, please read through the entire associated release notes. The release notes, next to the bugfix list, has important instructions on how to apply the hotfix rollup pack. Especially customers using Quest Web Access should read the release notes carefully.

Hotfix Rollup Pack 1 for vWorkspace 6.0, as always, can be downloaded from the download section of vWorkspace under the “hotfixes” section.

If you ever read about the history of the Provision Networks division of Quest Software you’ll know that Provision Networks was originally a spinoff out of a Citrix Platinum reseller. The spinoff was a result of years of creating tools that helped people solve problems that Citrix did not allow them to solve. I recently re-discovered a feature in our product that is a perfect example of this: the App Wizard. The name does not do it enough justice because it allows you to bulk-publish applications in just about every way you can think of. Let’s take a short look at some of the features of the App Wizard.

Read the rest of this post »

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.